Kanban Testing Process
Our team has no separation between development and support, and we work for Kanban. This methodology allows us to combine support (that is, tasks that appear unexpectedly and that need to be completed urgently) and tasks from the backlog that are planned in advance.
The testing process is part of the development process. It should be effective so as not to delay the release of ready-made functionality in a productive environment. To do this, we strive to constantly improve it.
To properly evaluate the effectiveness of the testing process and its improvement, it must be described and communicated to the team. The description of the testing process helps to make the testing process understandable and transparent for the whole team and reduce the amount of uncertainty in everyday work. During the execution of tasks, changes are made to the testing process according to the PDCA method (this is an abbreviation formed by the words Plan-Do-Check-Act , also known as the Deming Cycle):
- Plan work changes or trials to improve.
- Do it. Try the planned activities in a small work area of importance.
- Learn. Learn the results. What did we manage to find out?
- Act. Implement or discard changes. Repeat the cycle, perhaps in a changing environment.
To visualize the development process, a board is used in Jira, in each column there is a limit for tasks simultaneously taken into work. When an urgent task or a blocker for a task appears, it can be returned to the backlog and take a higher priority task at the moment.
Kanban has daily - a daily discussion that is conducted by looking at tasks, rather than the work of specific people, as in Scrum. The discussion begins with the most important one - the right column, then move to the left, answering the question “What prevents us from moving the task to the next column?” . The most valuable tasks are on the right side.
So, let's move on to the testing process itself:
We have several test stands, as well as feature stands where new functionality is being tested. Testing of urgent tasks takes place on a feature-stand with the subsequent calculation in prod.
For scheduled tasks, cards with tasks/bugs go from the left to the right.
In steps, this happens as follows:
- When working on a task at the stage of grooming or at the implementation stage, QA writes a checklist of checks for the functionality that is at the implementation/discussion stage.
- When the Bug (errors)/Task (tasks) on the Kanban board becomes Verify (verification), the tester assigns the task to itself so that it will not be taken into use by another tester.
Verification is performed on the feature stand (a separate stand for the developer) or the dev stand (general development stand), which is indicated in Bug (errors)/Task (tasks). If nothing is indicated, you need to look at the attached merge_requests and determine where the code is laid out.
- If errors were detected during the verification process, the task is transferred to the Reopen status (rediscovered) with a comment + print screen + playback steps (if necessary) + logs (if necessary).
- 4.If no errors were found during the verification process, then:
- A test script/test cases is added to TestRail (test documentation management system).
- The checked Bug (errors)/Task (tasks) is transferred to the status of Business acceptance (acceptance by the business customer).
- After verification by the business customer, the task goes into the Done status (done). If the business customer transfers the task to Reopen (rediscovered), the testing cycle repeats.
- After the appearance of more than 4 Bug (errors)/Task (tasks) in the Done status (ready), the developers perform the calculation of the release of the candidate for UAT - acceptance stand.
- A smock test is performed on a checklist and autotests regression testing are launched.
- Bug (errors)/Task (tasks) are checked in Release status (the task is ready for release), included in the release candidate for UAT - acceptance stand.
- After checking the Bug (errors)/Task (tasks), we translate into the Closed status (closed).
- Check the version on the mob. devices - Android, iOs (we pay special attention to layout).
- If there are no bugs with the status Blocker (blocking) and Critical (critical) when checking the release candidate, the release candidate is laid out on PREPROD (preprod stand) by the developer/DevOps.
- On PREPROD (preprod stand), the functionality turned off on the UAT (acceptance stand) is checked. If all is well, then there is a calculation on the PROD (prod stand).
- After receiving a message about the release of the candidate for PROD, QA (testing team) performs smock testing (quick verification of the main functionality) on the industrial circuit.
P.S. If you have any questions about the testing process, I will be happy to answer your questions in the comments !.