Even the best planned software quality assurance (QA) process can meet issues when implemented and needs to be changed. In this article, Richard Ellison proposes a process to review your assumptions and improve the implementation of your software testing activities.
Richard Ellison, The QA People, http://theqapeople.com/
Irving Washington once said “Great minds have purpose; others have wishes. Little minds have subdued by misfortunes but great minds rise above them. [1]
You have been asked to modify your software testing process. Your plan is perfect and you have sign off from senior management (after way too many conversations). Without question once you go to implement your process something will end up not working as expected. It could be the number of manual hours is increasing or your automated scripts are not maintainable. Course correction is an expected part of any software development process, so it is only reasonable to think you will have to look at some changes for a new process. As you will have to make some modification, I have defined a few guardrails that can be used as an approach for what to do you do when your tasks are impacted by deliverables that are not properly met. The process listed below allows you to review task assumptions, review accountability, reevaluate schedules and monitor and control activities through the improvement process.
Scope
If you have the opportunity, try to implement your software QA process in a small scope with minimal risk for the company or your external projects. The usefulness of a pilot for the process implementation cannot be understated. It allows you to work out the kinks in the process without annoying your testers, your managers and your customers. This is not always possible and when you run into issues you can use the following approach.
Reviewing Task Assumptions
When reviewing the tasks in the project plan or work breakdown structure, you will need to define the assumptions that are based around the tasks. One method that can be used to do this is brainstorming with the team and communicate the assumptions, display the assumptions and make inquiries around the expectations for this assumption.
Before you do anything else you must remove the blame from the equation. The first component is to allow an environment in which assumption can be reviewed. The communication of any issue can easily be focused on the resource where the root cause originates from. It is more fruitful to review the issue from a process standpoint. Address the process issue through the brainstorming sessions and the resource issues should be address in a separate setting. [2] Also take inventory of the impact of group formation within the created assumptions. If you are implementing a distributed software testing model or anything that that requires new resources be added to a group, you will have to assess the status of the team and where they are at in the four stages of group formation.
Display the Assumptions and Review Alternatives
You can review the individual tasks and process with the goal of defining incorrect assumptions after the structure and the goals of the changes required are set. The specific tools used are dependent of the implementer. Once the process and tasks are reviewed you will next perform action assessment. When looking at the assessment, the goal is to define a recommendation in a reasonable time. It is always best to go with the old quote from an unknown author: “A good decision today is better than a great decision tomorrow”.
Review Accountability
Once these process and tasks are reviewed, the roles and resources must be looked at to measure accountability. This will be used to define role activities, time, cost and dependencies. You can use a prioritization matrix to review activities that are due. After that your timeline will have to be adjusted for scheduled activities. The schedule should have clear defined milestones that will have to be tracked. It is important that all resources are aware and have accepted the milestones and have also signed off of the method that will be used to track tasks. This will include the frequency and method of communicating status.
References
1. John C. Maxwell, The Maxwell Daily Reader 1st edition, Vol. 1,Thomas Nelson, page 85
2. Gregory E. Huszczo, Tools for Team Leadership 1st edition, Vol. 1, Davis Black, page 127
About the author
Richard Ellison is the Director of The QA People. The QA People is a company focused on creating social mobility through software development with a focus on offering opportunities for people from various backgrounds to enter into software testing positions through workshops and online classes and certifications. Rich has worked as a QA and Project Manager Consultant in various industries such as health care, insurance, automotive and financial. His current book “How To Be A Tester” is available on LeanPub at https://leanpub.com/howtobeatester.
Great article. Straight forward approach for root cause analysis and a few nice reminders.