The Kanban method is widely used in the software world especially when it comes down to contexts with frequent priority shifts and change requests. One of the ideal use-cases for Kanban is QA and generally all sorts of quality activities. In this article, we are going to explore a sample QA Kanban board structure and a few configurations that will help a QA person utilize the benefits of a great Kanban software system like Kanbanize.
QA Kanban Board Structure
Let us quickly go through the board and comment on the key points.
The stages of the board are as follows:
- Ready to Test – this stage of the process is for tasks/features that have been completed by the development team and that are ready to be tested. The WIP limit is 10, because there may be bursts of completed tasks coming from development. If the WIP limit of 10 is reached, the development team should not push more work to the QA Kanban board.
- In Progress – this is a global In Progress column with a couple of sub-columns.
- Regression Testing – the first stage of the process is regression testing. This is where a lot of automated tests are being run to ensure that no bugs have been introduced in existing functionality.
- Functional Testing – this is where new features are being tested. As tests for new features are not yet automated, this is usually manual testing or a combination of both manual and automated testing.
- System Testing – a step where end-to-end scenarios are being run. It is always a good idea to run end-to-end tests before releasing to production, as smaller test cases focused on a particular functionality do not always detect major integration issues.
- Load Testing – the final step in our process where load/soak/performance tests are being run. Having defined KPIs that your performance should never go below is a must-have for enterprise class software. Each release needs to be certified and all regressions in performance must be detected/fixed.
The swim-lanes (horizontal columns) can be utilized to contain tasks for two different products or projects. Another application of the swim-lanes could be to indicate priority, person, classes of work, etc.
What to do with features that fail testing?
There are several strategies here. One would be that you keep the items on the board while you submit issues in the developers’ support board. Another would be to move the task back to the developers’ board and label it as failed. Later on, you can get reports based on the number of retests needed before successful.
This is how your distribution chart could look like based on the number of retests a given feature passes through:
Give Kanbanize a try with your QA team and let us know how it works. We would be more than happy to help you!