Answer: No.
Ok, ok…admittedly, that statement might be harsh. It was intended to cause an emotional stir and prompt discussion with an anecdotal comment. Any team is obviously able to develop and release code without involving QA. Perhaps the makeup of the team doesn’t allow for a QA resource; either for budgetary reasons, alternative project needs, or even due to team dynamic. However, doing so has its risks. There may be gaps in expectations beginning with ideation and will compound greatly as the product matures. Ultimately, the product may not come remotely close to meeting the customer’s needs. Let’s explore the opportunities for Quality along the process of software development.
Quality in Design
During this phase, typically the business analyst will create a handful of options to present to the business in order to fulfill their need. This may include wireframes, mockups, or prototypes. This is perfect timing to flex some Quality muscles. How will each option need to be tested? What are the technical limitations of each solution? Will any maintenance be needed more for one solution over another? How many users will touch this solution and what are their technical abilities (are they proficient at using a web browser or do they struggle with copy/paste)? Seeking answers to these questions will help the team focus on a direction and provide a foundation for quality in product delivery.
Quality in Requirements Gathering/Refining
Now that a direction has been agreed upon by the business and the team, additional details will be collected to help the team work toward production-ready code. Usually these details present themselves in the form of requirements or acceptance criteria that the solution must meet. Here’s another perfect place to dig for more Quality opportunities! Since the details are refined, the test scenarios should also be refined from any testing notes gathered in the design phase. Are there any usability issues to consider? What edge cases are possible? Is a fail safe needed, or how should users be presented with errors? What about scalability, performance, or even information security requirements? These and other questions, no matter how obscure, can be asked to help guide the team in gathering more accurate requirements and thoroughly authored test scenarios before development begins.
Quality in Development
Developers are released into the wild…put the hands to the keyboard and watch millions of lines of code begin to take shape. Now is the time to get to know your developers. Engage in a conversation to understand their style. Do they carefully analyze the task or just plow through the work? If you have a question, will they take time to help you understand, or will they dismiss you? What about the proverbial question “Can everything be tested?” If not, consider having a mini code review or simple discussion, depending on technical ability of the reviewer. What bugs have previously manifested, either in the same project or the same functional unit of code? Has any product support documentation been constructed in case of future production issues? Answers to these questions will not only guide the testing effort, but may also inspire the developer to perform the task with a deeper level of attention.
Quality in User Acceptance Testing
Here’s the final sign off before ascertaining production readiness. The manual, automated, and regression tests have all passed. But before declaring optimistically “nothing can go wrong now!”, take a step back. How many sign offs should be obtained and what level of documentation is needed? Do the acceptance testers consist of business partners, beta testers, or both? Do they have access to a more appropriate set of test data than what was available in the lower environments? If an issue is found, should the team whip up a quick fix, add a more complete fix to a future iteration, or negotiate priorities to include a more complex fix in the current iteration? Who is going to be the point person for coordinating the testing and providing product feedback to the team? This information will provide faster feedback cycles moving the product closer to an approved state of application readiness and a successful go-live.
Quality in Release
Finally! The code is ready to ship. The deployment plan is established (or is it?). The release team is included on all communication and knows the exact timing on when to proceed with their tasks. What will be tested in production, if anything, and by whom? Are there any dependencies by other teams releasing code at the same time, and is there a risk of regressing another team’s code? There has been a lot of effort put in by the team so far to get to this point. Don’t waste it on a flubbed deployment.
Quality in Support/Post-Release
Day one was a success! Will day two be equally successful? Despite all of the efforts leading up to a successful delivery, issues will manifest with subsequent use of the product. Are there triage steps in place to address any production issues that arise? Which team will be the first line of defense to handle those issues? If the product was designed to integrate with functional components from other teams or vendors, are triage steps in place for those integrations? Can the business partners investigate and handle the issue themselves, or should an issue be escalated directly to the development team? Any support handled by the development team may delay new feature delivery in the current iteration due to time spent in researching, remediation, and testing of a fix for the triaged issue. Keep in mind that this may also affect regression suite test coverage, which could further increase testing scope and effort.
Final Thoughts
Notice there isn’t a section titled Quality in Testing–that’s because Quality encompasses much more than Testing. In many situations, QA is not the sole decision maker, but is simply asking questions to help guide the team. The entire team should be making decisions collaboratively. While the QA role may specialize in testing, they shouldn’t stop there. In the spirit of Agile, they are empowered to ask questions throughout the development process. The entire team is responsible for quality. Although a project or team may not have someone in a dedicated QA role, it is imperative that a team adopt a QA mentality to achieve accuracy and efficiency in product delivery.