DevOps QA Perspective – Deep Dive into Real life Scenarios – 02

This series is intended to understand QA challenges in context with DevOps. Please refer to my first post on the following link;

Recap

• Three buzzwords of DevOps. Cultural shift, Automation, Tools and Tools!
• There are diverse viewpoints on role of QA.
• Process & cultural shift is not enough translated to actionable tasks primarily due to lack of clarity on governance and processes.

Clearly overall focus solitary has been on tools and focus from QA perspective is limited to automation leading to impression that only automation testers have a role in DevOps. If you are one of those, hold your thought and read this article and the series. This article would touch upon delivery models to assess whether QA has any role to play in new scheme beyond automation.

Over decades enterprises have built their IT systems, there have been transformation programs to move to strategic architecture. In context of DevOps ‘strategic’ is now being seen as legacy. Let’s evaluate some of the challenges and complexities;

Let’s look at typical QA challenges adapting DevOps for large enterprises. Large businesses would have built complex IT systems (architecture) and a change would lead to impact on multiple systems. Following example is taken from a real life scenario masking actual references to organization and specific requirements. Intent is to draw attention to QA complexities.

Diagram 1

Notes:

1. Above picture represents a specific way in which Epics, User Stories and acceptance criteria has been defined. There may be variation depending upon organization using the model. For example “Acceptance Criteria” may be replaced by “Sub features”.
2. Although actual definitions are much more complex, an attempt has been made to simplify for the sake of understanding.

Although, the above diagram is simple and self-explanatory, it’s elaborated below to draw attention to specifics from QA perspective.

• There are six epics identified by business/product owners to be developed and deployed.
• Because of scale and complexities involved these epics have been split across three scrum teams (Scrum 1 , Scrum 2 and Scrum 3)
• Acceptance criteria for each user story has been clearly defined. Looks, hunky dory for DevOps till now.

One of the important aspects of DevOps buried under tools is process for identifying clear dependencies and mind map is the best way to visually represent it. This being a real life example, let’s refer to dependencies identified for epics and user stories. For simplification number of dependencies have been reduced and dependencies for Epics and User stories have been shown separately in two separate diagram below;

Diagram 2

Elaborating diagram despite being presumed self-explanatory;

• These are the same six epics identified earlier being delivered as part of a larger business objective called “Project 1”. Just a representation has been changed.
• This diagram identifies dependencies. Epic 1 above is dependent on Epic 3. This means unless Epic 3 is built Epic 1 cannot be developed and tested.
• Another point to note here is that Epic 1 is part of Scrum1 and Epic 3 is part of Scrum2.

The same mind map can be drilled down further to identify dependencies at user story level.

Diagram 3

Elaborating Diagram 3

• Epics that have been identified as dependent have been zoomed out in Diagram 3 to identify specific dependencies.
• Feature3 of Epic1 is dependent on Feature2 to Epic2. Sounds, confusing, refer back to Diagram3.
• Thus “Feature2 of Epic2” has to be built and tested prior to “Feature3 of Epic1”.

Having understood the dependencies, let’s now wear a QA hat and analyze what actions needs to be taken to ensure end product is fit for purpose;

• Of the above six Epics 2,4,5 and 6 can be built and tested independently. This is a happy path scenario most of the DevOps guru’s quote from QA perspective.
• Epic 1 and 3 are interdependent. In addition to complexity these are split across different scrums. Imagine a scenario now where only testers are involved testing their part within respective scrums and deploying in production. A level of integration and overarching view of multiple scrums is very important to avoid a disaster.
• From test automation perspective, it’s limited to unit tests. Note epics are interdependent and split across multiple scrums and thus tests needed beyond unit testing need to have overarching view of all the scrums.

Let’s go back to points where we started this article

Don’t forget this series is focused on QA & hence all references to tools have been made from QA perspective & does not comment on build, deployment, configuration management, container and any other tools being used as part of DevOps.

Hope you like this article, if not share your views. Waiting to hear from you.