QA Friendly Agile

I wrote this piece because i was having trouble with understanding the Agile process that our development team were trying to use from a QA point of view. My QA team were struggling to make sense of when and what they should be testing and what input they should be having on the process as a whole.

I was thinking of 5 main points when i was trying to develop this updated process:

  1. Better visibility for QA on things that they can directly test (A Feature) and things that the develop would be better off testing with some input from QA (A Task)
  2. Input from the developer on the test plan and cases that the QA would like to use
  3. Trying to get QA involved at the beginning and making sure that QA and Dev can be working on a feature in parallel, meaning QA will have all their ducks in a row ready to test the feature as soon as it’s finished being developed.
  4. Pushing down as much of the testing to the unit test level where automation is much cheaper and more reliable.
  5. Getting a feature that is in the best shape for QA functional tests. By having good unit tests to find issues before it gets to the QA functional test stage we should find less issues.

How to do it?

We need a ticket for each feature (these might be users stories in some cases), it would be made up of tasks which are at the component level, each of these tasks should have a set of unit tests, these tasks can then flow thru the process with only a small amount QA involvement as the developer will have written the unit tests and if all these pass that task is QA passed.

Once all the tasks associated with the feature ticket have passed QA then we as QA can get involved and test that feature, this will probably be done at the UI level and we can then create some UI level automated scripts. We can also create an agile test plan  for what we are going to test in that feature and run this by the dev whilst the tasks that make up that feature are being coded and tested by the developer. This will help use to work in parallel.

The QA will know that they have to have a full set of tasks (Which will be associated with the feature ticket) passed QA before they start testing the feature.

One of the benefits of this will mean that we push much of the testing down to the lowest unit test level, this should mean that when we come to test the feature we should find less issues as the tasks that make up the feature have been tested using a good set of unit tests. This should mean that the QA is faster and leaves more time for getting the environment requirements and test data sorted and for automated tests to be created at the UI level to test the feature.

I would see the issue logging process as being the same as it is currently after QA is done, so create a new bug ticket and pop all the issues found in there and put this in the sprint backlog.


So to sum up this is how i see this working:

  1. Feature A ticket created (Should include a UI element)
  2. Task (Would probably not have a UI element) tickets created that are required to implement feature A and linked to the feature A ticket.
  3. QA checks the feature makes sense to them then writes agile test plan for feature and can start to write the test cases for the feature and also work out any test setup / data that is required.
  4. QA reviews test plan with Developer and updates as necessary.
  5. Developer works on each task ticket, works with QA to validate the testing they are doing and the unit tests created, task tickets move along the board and end up in QA Passed during the course of the sprint. This can be happening at the same time as step 3 and step 4
  6. Once all the linked task tickets have passed QA, the QA can start running the test cases they have already written (In step 3)
  7. Once manual tests passed QA can automate a regression test at the UI level
  8. Feature is then DONE


Postit  for features are placed on the sprint board at the start of the sprint, as each associated task is worked on a posit for that task is placed on the board. Feature tickets remain in development doing until all the subtasks have reached QA passed on the board. Once this has occurred feature ticket moves to QA doing.

See image below for a process flow diagram.

QA Friendly agile process - New Page