The role of Quality Assurance (QA) is creating a bit of a buzz these days, because even as teams and budgets are shrinking, the demand for better quality is increasing. The chilling repercussions of service disruptions caused by software flaws warrants interest even at the executive level: “Nobody’s madder than me about the fact that the website isn’t working as well as it should,” said President Obama when HealthCare.gov went down last year due to software defects.
The HealthCare.gov situation is an excellent example of IT companies treating QA as an afterthought. When quality assurance is the core component of software development, it guarantees the end-product is developed to meet client requirements, provides a satisfying user experience and has fewer defects. But QA teams that take a strategic and automation-driven approach toward quality assurance are disappearing rapidly. This is unfortunate because we know that without QA, when the inevitable software defects show up later in the development cycle, companies are forced to break the bank fixing them, causing revolts within the development team and slowing down the entire process. Development testing malpractices, poor QA strategies, broken organizational hierarchy and insufficient collaboration among developers, operations teams and QA have consistently led to the poor quality of end products.
And despite experiencing compelling consequences of costly break-fix cycles that prompt sweeping process changes from overburdened QA professionals and passive aggressive developers, companies continue to neglect the critical role of quality assurance when it matters most. Ironically, development shops aim to sprinkle quality onto applications right before the release phase instead of implementing necessary changes proactively throughout the development cycle from inception through implementation.
In this context, the following QA practices go a long way toward improving software quality, especially as organizations readily embrace the DevOps movement to facilitate effective software development and operations while maintaining superior quality and user experience.
These practices are:
- Make QA a technical part of the team: QA Tams should no longer be focused on manual functional testing. They should be technical ( ex IT or Development ) and focus their efforts on automation, and testing strategy. They then become the facilitator of quality. In some organizations they even re-name QA to Quality Engineering QE
- Defining Quality to Meet Requirements: Avoid unrealistically perfect expectations and focus on a satisfying user experience within the given resources and time frame.
- Measuring Simple Quality Metrics: Consider quality metrics that are highly visible and quantifiable so software defects are exposed early in the development cycle.
- Optimizing Team and Individual Goals: Incentivize quality assurance as part of goals in order to reinforce the desirable behavior of ongoing quality improvements and control.
- Being Specific about Requirements: Defining and understanding requirements helps development teams move in the right direction when corrected efficiently with proactive involvement of QA teams.
- Testing Smarter: Focus automated regression testing on high-risk areas such as critical software functionality and use exploratory testing tools like Applitools to test new functionality with how the effort to write test cases.
- Leveraging Automation Tools: Mundane testing and manual administration tends to consume significant time and budget resulting in their neglect at the beginning of software development cycles. Automate boring web-based administration tasks with the killer browser automation tool SeleniumHQ and automate visual testing of your application on multiple platforms with Appitools to save valuable resources.
- Communicating, Collaborating and Optimizing: Bringing QA teams onboard at the beginning of the software development cycle is critical to the success of the DevOps strategy. The operations and development teams must consider QA as a process the entire shop is responsible for rather than the responsibility of dedicated teams that are never involved during early development stages. Quality assurance is essentially a team sport that DevOps teams must treat as an integrated component of the software development lifecycle in order to enable continuous delivery.
There are a few rising stars we can look to as examples. You may have seen my post on Acorns—a young startup that has put an emphasis on QA from the outset. Their QA team is as comfortable collaborating and contributing to application development as any other team on the project. Apple is another, although admittedly cliché example, of deliberately putting QA front and center for all atomic application and DevOps teams. Both companies are able to focus less overall on QA execution because it is everyone’s job—including the front-end developers. A side effect of this shift is that the team is more strategically focused on building test case strategies and building and vetting automation processes.
Quality assurance and development testing have expanded beyond their traditional definitions in the fast-growing DevOps culture where development shops are prepared to embrace the movement, but still treat QA as a secondary (or even tertiary!) goal. Even the latest trend of moving QA to front-end developers requires QA teams to morph into the QA police and facilitators, as well as creators of the automation and QA strategy. Only when this is in place can QA teams optimize the critical influence of quality control and assurance throughout the software development lifecycle.
