“How easy is it to build a QR Code Generating Website?”
​
After 3 weeks adhering to California’ Shelter in Place mandate, this message from a colleague was refreshing. I quickly responded to him saying that it was relatively easy to build. In the back of my head, I was thinking that this would be a great example to build upon my Automating Agile presentation from 5 years ago (https://youtu.be/kBGxM5M49TI)

In the new version, I want to apply the lessons I’ve learned over the course of my career with some of the technology and tools that I’ve become proficient in. There are three important lessons that I want to incorporate as I build the QR Code Generating Website.

Lesson 1: Traceability
Years ago, I worked at a great start up that eventually went public. It was there that I learned the power of Behavior Driven Development (BDD) and the importance of tracing functionality to business requirements. As part of my responsibilities, I was the interface for the auditors to review product requirements, test cases/reports and defects. Traceability was a big part of my life then.

Lesson 2: Accountability
As my career matured, I began going up and down the “silos” of the various development organizations to ensure that code delivered to me was done with high quality. A lot of that time was spent reviewing basic unit, integration and functional tests. Eventually, it would include reviewing performance and security testing results. Thanks to tools like Jenkins and Sonar, I was able to do a majority of my reviews in a single application. This helped make my traceability efforts accountable for everyone on the projects.

Lesson 3: Manageability
Managing all these software development activities required the need for collaboration tools like JIRA. Out of the box, JIRA is a great tool to manage your day to day tasks. If there is a need to provide information in a ticket that cannot be accomplished with the existing set of fields, JIRA provides the capability to add custom fields to a ticket. This has been both a blessing and a curse to the agile process (A topic for another time). The other challenge, which JIRA can handle well, is actually managing the requirements that make an epic/story/task become a reality.

Getting Started
After creating a project in JIRA for the QR Code Website, I want to focus on how my epics and stories would help me to build the website while still accomplishing my traceability, accountability and manageability wish list. In short, I want to demonstrate that:

• The business requirement is clear
• The evidence of testing is clear
• The completion of a story/epic is clear
• The functionality of the story/epic in production is clear

The Epic
My goal is to have a basic functioning website, nothing very fancy. In the spirit of the feature file, I used the description field of the JIRA ticket (Epic) to create the first epic:

In true BDD style, I placed in the description field the standard narrative outline:

As a <person/role who will benefit from the feature>
I want <the feature>,
So that <benefit or value of the feature>.

Instead of customizing JIRA, I decided to include the acceptance criteria in the description field as well. More on that in a later story.

​One thing to note about the acceptance criteria is that I did not follow the convention of using the Given, When, Then pattern. The reason is that it will be covered in the feature file that will drive the automated tests to validate my epic. Instead, I’ve mapped the acceptance criteria to the two scenarios in my feature file. The scenarios contain the Given, When, Then format.

The format of the JIRA epic, along with the feature file, highlights the traceability between the requirements in JIRA and the tests written in the feature file.
Accountability is handled by the use of the pronoun, ‘I’. When the sprint team reads the epic and feature file, the use of the pronoun ‘I’ will make the team accountable in completing the epic. In this case, the team consists of me playing the role of Product Owner, Developer, and QA. Therefore, I will be accountable for the entire project.
Considering that this is a small epic, managing this effort will be easy. Next time, I’ll break down the grooming of an API story to support this epic, diving further into defining the acceptance criteria and how it translates back to tests to achieve the finish product in BDD fashion.

Traceability is one of the key tenets for accountability.  One of the easiest scripts I've had to write helps me to manage what my testing scope is going to be from release to release.

This script that I'm going to share has been helpful in getting a clear picture of what is potentially in the next set of code for testing.

Assumptions:

• There is a release branch to compare against the current release candidate in git
• Use or plan to use labels in JIRA as an identifier to manage stories
• JIRA Issue numbers are part of the commit message

Here's the workflow that I've devised (first version):

1. Compare the log differences between the last release branch and the current release candidate
2. Extract all the JIRA issue numbers from the result of number 1
3. Process and update the stories with a given label

​Comparing Git Logs

To get log of the current branch, simply type:

Assuming, that you have the latest commits, it is easy to compare the logs of two files by running this command and placing the results into a file.

The one thing it doesn't do very well, is if you had to do a hotfix in production after the fact.  It is still okay, as it will remind the tester to test that "critical" hotfix to insure that we didn't break it again.

Once you have the file, it is a matter of parsing the file and updating the JIRA tickets with the appropirate label.