Best Practices in Agile for QA
Quality Assurance in Software Development is not like testing the product by covering the business requirements but is like what QA process you are implementing and is it generating the ROI. Nowadays in the software industry, the client is always looking for frequent and iterative deployments. If you are a QA person then you are expected to test a system that has frequent requirement changes or new requirements coming rapidly that leads to frequent code changes. As an ideal QA resource, you need to involve from the first day to the last of the release cycle, by making sure all the team members and clients are on the same page throughout the development and testing.
By implementing Agile in our daily practice we can gear up the QA process, we can program and execute all testing activities for the different development Phases. There are many ways to implement agile, I am here talking about Scrum. In the scrum often organization follow the 2 to 3 weeks iterative release which is called the Sprint. Below are a few points that will be very helpful for any QA person to increase productivity in Agile.
Raising the Story point in the sprint planning
Deciding the story points is the primary task before picking any User Story. Being a QA you put up the story point by making sure that all your testing activity will be completed within the time limit. You can calculate the story point by going through the story in-depth and by analyzing the impacted areas. Some time it may possible for the Dev team it is a one-liner change but the impact is on all the modules of the system, in that you need to be very careful while proposing story points. Deciding the story points based on the Fibonacci sequence is the most popular way, here we raise the story point using the Fibonacci numbers, 0, 1, 1, 2, 3, 5, 8, 13, 21. If the story size is large then likewise we select the number in an ascending manner.
Prioritizing the story/requirements of the sprint
In any active sprint, we have to work on multiple stories and bugs, at this time deciding the priority for each task can be very challenging, being a QA you can consider the below points while Prioritizing.
- Make sure that all the major changes should be picked in the early stage of the sprint so that the testing can be finished in the defined time and in case if any blocker issue comes then we have sufficient time to tackle that.
- While picking the story for a particular sprint make sure that you choose the optimum combination based on the priority. Eg. If you are having ten stories then five should be a medium priority, three should be low and two should be a high priority.
- In the starting make sure that you are picking the spill-over items of the previous sprint.
Tracking the backlogs
The product backlogs often have some new user stories, change requests by the client for existing functionality likewise, we have some pending items in the backlogs that we have not picked yet due to other ongoing developments. Being a QA it is your key responsibility to keep looking at the backlogs and need to talk over with developers and clients as well so that if we have the bandwidth in the current or coming sprint then the items can be picked from the backlogs and it also helps you to get rid of from the more number of the backlogs.
Attending the Stand-up meeting on a daily basis
Daily stand-up meetings are important for keeping the Agile Team on the same page by providing quick updates to the rest of the team. Being a QA you should always be on the front-end by updating your work status and your blockers if you have, making sure that you have regular communication with the Dev team to achieve all the development is meeting the business requirements. Oftentimes the daily scrum meetings are of 15 minutes, generally, the discussion is around the below three points.
- Which task you have worked yesterday?
- Which task you are picking up today?
- Do you have any blockers?
Work jointly with the Client
It is one of the key responsibilities of a QA person to constantly communicate with the client and providing his/her testing experience about the system. Also, you can suggest any new idea or any improvement that can make the project ease of access to the users. You can plan the demo if any requirement is completed and speak to the client that after this new code change the system behavior will be in a different way and take the feedback to confirm these changes are meeting their requirements or not also you can ask if they need any new addon on this, and you can plan for the same before the release.
Attending the Retrospective meeting
As a progressive QA resource, make sure that you should always be attending the Retrospective meeting and putting all your experience/feedback about the sprint, you can describe your experience by Following below three criteria.
- What went well in the Sprint?
- What could be improved?
- What went wrong?
You need to make sure that whichever blockers/issue you have faced in the last sprint if again it comes in the new Sprint then you have the solution for that and you can continue your assignment.
