DevOpsThoughts Rabbit

DevOpsThoughts Blog Post Series:
1. About DevOpsThoughts
2. DevOpsThoughts Rabbit
3. Arhitecture of DevOpsThoughts Project


 

 

Introduction

User Stories & Product Backlog Items (PBIs)

Test Cases

Use Case Scenarios

Basic Mockups

PhotoShop Designs (PSDs)

Website Components (HTML, CSS and JavaScript)

Storyboarding

HOL 3: Identity with Azure AD and Office 365 APIs

Conclusion

 


 

Introduction

As already explained the first post of this series About DevOpsThoughts, which is describing the basic idea behind the project and it’s giving the higher perspective of it, the DevOpsThoughts Rabbit is the first project in DevOpsThoughts Blog Post Series. It represents and e-commerce website, which was built with the usage of different technologies, such as  ASP.NET MVC 5, Microsoft SQL Server 2014 and Modern UI Tools & Frameworks, like Twitter, Bootstrap & FontAwesome.

Further, in this post, I’ll describe more detailed all the development steps, which were considered and implemented in the process of the project creation.

User Stories & Product Backlog Items (PBIs)

 

User Story is a description of a specific functionality from an end-user perspective.

Product Backlog Item is a single unit of work, here we mapped each user story to a PBI, so a PBI is a user story plus acceptance criteria, priority and tags.

For each user story, we develop a Product Backlog Item (PBI), assign proper tags to it based on publicity (Public/Private), main actor (Visitor/Member/Vendor/Admin) and workflow type (Basic/Advanced), then we add its Acceptance Criteria. Each Acceptance Criteria Consists of two main parts:

  • Action Criteria: Are the options available for use and system respond to it.
  • Input Validation Criteria: Used only when there is an input form being used to clarify each input type, boundaries, and importance.

All PBIs are made on two levels:

  • Initial PBIs: Contains each PBI’s Title, Order, Tag, and Description (Description is the user story).
  • Detailed PBIs: Contains the initial PBIs content with enhancements to maintain consistency, plus the acceptance criteria.

All BWF PBIs are added to the source control in plain text format, so we can quickly trace any changes to it.

Below is the sample for Vendor’s login Initial PBI.

Initial PBI

Another sample for Vendor’s login Detailed PBI.

Detailed PBI

Test Cases

Test Cases are very important for Behavior-driven development (BDD), In DevOpsThoughts, we have test cases written on three levels:

  1. Conceptual Test Cases

Conceptual Test Cases are the most abstract form of test cases made with conceptual input only for purpose of conceptualizing the flow itself.

  1. Functional Test Cases

Functional Test Cases made for testing the application functionality without discussing UI elements or UX, just making sure the application outputs the suitable output when some input is provided.

  1. Usability & Functional Test Cases

Usability & Functional Test Cases are the most detailed test cases, it cares not only for functionality as functional test cases but also for the way application responds to user actions from user experience (UX) and user interface (UI) perspective.

Use Case Scenarios

Use Case Scenario is a list of user actions and system response to it. In DevOpsThoughts, we map each PBI to a single use case scenario. Each scenario has the following:

Related PBI: The related PBI name & Id.

Main Actors List: A list of all actors involved in the specified use case.

Pre-conditions: A list of all conditions that must be met before the use case starts in order for the use case to be valid, example: Vendor has been logged into his account.

Basic Flow: or what we call sometimes Happy Path is the normally expected flow for the use case with the default system settings, where the use case is expected to succeed as per main actors expectations.

Alternative Flows: If available, alternative flows of a use case are the flows where main actors expectations are not met yet.

Post-conditions: A list of all conditions that must be met after the use case ends in order for the use case to be valid, example: Order was saved in the application.

Also as in PBIs, use case scenarios are divided into Initial and Detailed use case scenarios.

Initial Use Cases: Have the above structure, but with more abstraction level, so not much attention was given to the details, but to make simple process outlining.

Detailed Use Cases: Have the same structure as the initial use cases, but with more details, like the input/output information and user controls available.

Below is the sample for Display Products List Initial Use Case Scenario.

Initial Use Case Scenario

 

Another sample for Display Products List Detailed Use Case Scenario.

Detailed Use Case Scenario

 

Basic Mockups

Mockups are very basic UI representation used to deliver an abstract format of the expected to UI design to a UI developer from end-user or product owner perspective.

Making Mockups

Mockups are usually made using a basic photo edition application like MS Paint or Paint.NET.

Level of Details

Mockups usually represent only an abstract view of a web page, Only spaces occupied and by which elements, doesn’t include icons, content nor colors.

PhotoShop Designs (PSDs)

Based on Test Cases, Basic Mockups, and PBIs, the final PSDs are made for the Project, A PSD file is a Photoshop Design file which can be edited later, PSD files are kept up-to-date with any modifications made to the UI.

Level of Details

PSD Designs are made while keeping attention to details. We can – from a logical point of view – look to the Basic Mockups as initial designs, while the PSDs are the detailed designs.

Below is a sample for the Final PSD Design for the homepage, and it’s identical with the screenshot for the homepage at the very beginning of this readme file.

Final PSD Design for the homepage

 

Website Components (HTML, CSS and JavaScript)

Web site components are simply the source code for UI, alongside with any elements used in the UI such as images, icons, and libraries. The Website components aren’t only used for Rabbit, but the same is used for other versions of the project which is using the web as a presentation layer. Developing the website components uses PSDs as an input, each PSD is converted – as it is – to be a separate web page. We gave much importance to utilize and minify all of the UI source files. After each PSD is converted, it is reviewed on two levels

External: Which is making sure that the web page matches 100% the provided PSD.

Internal: Which is checking for source code quality, readability and if the code is minified.

Storyboarding

A Storyboarding is an illustration of a user interaction with application story, not to be confused with user stories, in storyboarding we use visual images arrayed together for user interaction with the application to represent. Storyboards are easier to be remembered than other written Test Cases, as it shows the real UX, not just some text about it. In DevOpsThoughts we use Microsoft Office’s PowerPoint, which allows develops to make an animated representation of User interaction with application UI quickly with higher quality. If we look to the PSDs and Basic Mockups as a User Interface representation, we should consider Storyboarding to be the User Experience Representation.

Conclusion

This post, as the second one in the blog post series about DevOpsThoughts Project, is covering many details from the project development perspective.  It’s explaining for which purpose certain steps were developed, but it’s not explaining yet how they were developed and used in this project. The next post in this series will cover the Design and Architectural point of view of the project.

Share This: