QA Automation in Agile

In many IT organizations, in the recent years, the buzz word is Agile. One of the advantageous of Agile, is the feeling that all team members are updated with action items, while committed to deliver (at a "good enough" quality) for every single day of the sprint. Although some doubts the efficiency of Agile, others insist to implement it through all SDLC steps including QA.

As QA analysts get involved in an early stage of the SDLC, it is not uncommon among IT management to believe that QA automation team as well, has to be part of the early stages of SDLC sprint meetings. Very often, in IT organizations, QA Automation engineers lack the knowledge of the business (as oppose to SMEs and manual QA Analysts), or, are not being provided with accurate/low level description of Manual Test cases steps. Therefore, attending Scrum meetings at an early stage of the  SDLC, may assist in providing them with that important knowledge. However, while no code of the newly developed part of the product is ready to be tested, QA Automation engineers cannot start to develop their automated scripts library.

With an understanding of that challenge, how else can automation engineer be part of Agile and sprint activities?

In some IT organizations, where there is an awareness of that problem, a decision has been made, to have QA Automation engineers participating in a later phase of the sprint meetings, where some code is ready to be tested - often being referred to as 'One Sprint Behind'.

Is this ready to be tested code, a good candidate for automation? - Not necessarily.

As all QA Automation engineers are aware of, one of the most important criteria for automation manual test case, is the stability of the tested code and prediction for high frequency testing execution - or simply put, a regression (or smoke) test. The very first group of people to identify that need and recognize a manual test case to become part of the regression (or smoke) library, are the SMEs and the manual testing analysts.

With the basic understanding of that concept, it is inevitable to reach the conclusion of - A separate QA Agile implementation with 2 participant bodies only: SMEs/Manual test analysts and QA Automation engineers. This type of Agile implementation, is almost completely disconnected from the other teams Agile sprint cycles.

While having their own Agile bubble entity, the 2 participant bodies will manage their sprint cycles the following way:

1. Grooming of manual test cases repository and presenting the business flow by SMEs to QA Automation Engineers.
2. Selecting the manual test cases candidates to be automated (associated to their original User Story)

3.  Assigning points to each one of the User Story/Manual test cases based on Level      Of  Effort - LOE.  

Within QA Automation engineers team:

1. Assigning each one of the user stories (or few of them) to team members based on its LOE.
2. Scripting 1st draft of an automated script using a pre-existing framework.
3. Team Internal code review.
4. Scripting 2nd draft of an automated script using a pre-existing framework.
5. Presentation to SMEs/Manual tests analysts.
6. Obtaining sign off from SMEs/Manual tests analysts.
7. Including the automated script in an execution batch of Regression (or smoke) scripts.