The ACT Framework is more than a mere list of recommended processes, procedures, and team members. It also includes core values that are essential for effective implementation of the Framework.
These four values should remain on the minds of everyone who participates in developing and testing software:
- Make quality everyone’s responsibility
- Put quality first
- Embrace failure
These guiding principles should influence the work and behavior of everyone in the organization who will be adopting the Framework.
Make Quality Everyone's Responsibility
There is an obvious reason why software companies employ quality assurance professionals: software defects are costly.
In the best cases, defects only cost money. Some defects delay product releases, resulting in the loss of potential customers. Other defects are discovered after product release, resulting in the cost of repairing defects, notifying customers, and perhaps even issuing a financial recompense for the damage done.
In more serious cases, software defects can not only put a costly burden on developers and QA staff, but also cause damage to a brand. And in the most serious instances, defects may put human lives at stake.
The Cost of Defects
It is difficult to calculate the exact cost of a defect as it really depends on the severity of the defect (is it a minor typo or does it affect someone's well being) and the scope of the affected users (1 user vs millions). However, the 1-10-100 rule is a widely accepted concept on the relative cost of the defect. The rule states that prevention is a factor of 10x less costly than correction and a factor of 100x less costly than failure.
The 1-10-100 Rule may not be precise or scientific, but it holds a certain intuitive value. Any software development team will understand that fixing a bug will be much easier 10 minutes after the code is checked into the repository than it will be after the software application has been released to the market and downloaded by 50,000 customers.
The Role of Quality Assurance Professionals
With the 1-10-100 rule in mind, it makes sense to invest more in quality assurance than to spend on the cost of failure. When it comes to quality assurance, it’s best to have as many qualified minds as possible on the task. Quality should be the responsibility of everyone in the company, from testers and developers to product owners, management, and the C-suite. This is not to suggest that C-level executives should put everything aside and sit down to test a product before release. More likely, their main contribution will be to make an adequate investment in testing procedures and tools.
This also does not mean that testing professionals are superfluous. Testing professionals have highly valuable and specialized skill sets and experiences. As such, they should be responsible for leading the charge for better software quality. The need to continually promote the importance of quality in case the message is lost due to time pressures. They need to set up the right testing process to balance quality and speed to market. They need to educate the appropriate stake holders to ensure that a release decision is based on clear metrics on the risk of a release.
Put Quality First
Although it's becoming less common that testing is done at the end of a product release cycle, this core value is part of the ACT Framework to re-emphasize the fact that quality needs to be present at every stage, from budgeting to operations. There are two major reasons towards involving testing earlier:
The first reason is that, according to the earlier-cited principle that bugs get costlier to fix at later stages of development, companies are costing themselves money by catching defects in later stages of development. The second reason, though psychological, could be just as costly: by scheduling testing for the very end of the development cycle, teams are sending the message that product quality is an afterthought—and that testing is somewhat akin to hastily proofreading an email before clicking Send.
It is easy to extrapolate from this situation how testers may hesitate to do their jobs fully. After all, at late stages of development, there is often intense pressure to release the application. No tester wants to be the bottleneck who, by alerting developers to problems, delays the release of a potentially lucrative piece of software.
If software development teams are truly going to put quality first, they must be convinced of the value of making quality a priority. For high-level decision-makers, financial arguments will speak loudest. They must become convinced that the cost of their quality initiatives is reasonable when compared to the improvements enabled by these initiatives.
Any decision-maker, then, should be able to recognize the tremendous cost savings—as well as protection of brand image and potential saving of human lives—involved with investing in quality. Quality, then, should not be a process saved for the end of the development cycle, but rather, should be integral in all stages of development.
It would not be overstating the case to adopt the motto, “Test early, test often.” In fact, quality should be built into every process of an organization:
- Budgeting. Whether the testing budget is based on teams, projects, or value streams, organizations must ensure they allocate appropriate testing resources and acquire appropriate testing tools. The budget discussion should include the cost of upskilling manual testers into automation specialists/SDETs (Software Development Engineer in Test) and bridging the compensation gap between developers and testers.
- Planning. Organizations must ensure that the release schedule builds in adequate time and resources for testing.
- Product requirements. Product owners need to put thought into where applications can fail and how to prevent or mitigate failure. Since product owners may not have the experience of skill sets in identifying the risks in a product requirement, leveraging the quality assurance professionals can greatly help in this early stage.
- Architect and design. Development teams should try to design the system to ensure that it's easily testable, whether it is to build APIs to simplify testing or to create hooks to make automation easier.
- Development. Development teams should use methodologies such as TDD and pairwise coding to keep quality at the forefront.
- Release. Testing typically ends after the product is released. The assumption is that everything that needs to be tested has already been tested before the product is released. However, there are many cases where a test passes in the pre-production environment but fails in the production environment because of configuration, data, or other factors. If a company finds a defect before their customers do, then they can fix it before it affects their business.
If quality is everyone’s responsibility, then it stands to reason that everyone involved in the development cycle should be working together on quality processes. That’s why collaboration is another core value within The ACT Framework.
Businesses in every industry already know well the value of collaboration. In one Stanford University study, those who collaborate were more likely to persist in a challenging task, to enjoy the task, and to perform well on the task.
Software developers, too, understand the value of collaboration. The Agile development methodologies, which continues to gain popularity, revolves around collaboration between development teams.
This is not to say that everyone in an organization will be on board with collaboration. There are often significant obstacles to collaboration. Some team members may fear that if they share their knowledge freely, they will become less valuable to the organization. Others may have specific development processes they want to defend as their “territory.” People with these kinds of hang-ups tend to build silos that make it harder for the rest of the team to exchange ideas freely.
The best response is to create an environment that encourages collaboration. Here are some suggested steps:
- Set common goals that will drive the desired business results.
- Communicate the goals and expectations often.
- Invest in collaboration tools such as Slack, Microsoft Teams, etc.
- Celebrate and reward successful teamwork.
- Foster honest and open communications.
- Foster sharing of knowledge, insights, and even resources.
- Agree on a common definition of done, and then live by it.
Consider the failures outlined at the beginning of this article. The companies involved lost billions of dollars, suffered seemingly irreparable brand damage, and even endangered human lives. Failure is generally seen as a bad thing. Nobody likes to fail. When we encounter failure in a corporate setting, our instincts are usually to punish the people involved.
If organizations are going to succeed with The ACT Framework, they must shift their mindset so that instead of punishing failure, they embrace it. Failure is inevitable when organizations try new things. If organizations never try new things, they will never innovate. Thus, organizations that want to innovate must be willing to fail. The key is to get comfortable with failing at small things and to fail at the right time and to learn from those failures.
Testing is the business of finding failure. This is why software testers are often seen as the “bad guys,” and their results can be met with hostility and defensiveness. Nearly every development organization can recall hearing a developer argue at length that a particular bug is not really a bug—or if it is, it is a trivial one that will not affect the functionality of the application.
This mindset needs to change - testers should be seen as facilitators of innovation. Why? Because they make it OK to fail. Developers can take chances, knowing that testers will prevent innovations from taking a project off the rails.
Each software failure that’s caught within the development cycle is a potential lesson. We can learn from these mistakes in ways that help us to do better in the future—but only if we are willing to put egos aside in the interest of learning. Organizations can encourage this learning by regularly scheduling retrospective sessions in which teams share their failures and successes. Even production incidents should be reflected upon as soon as they happen. They can contain a great source of information organizations can use to reflect, change, learn and grow.
If it is fair to say, “Test early, test often,” then it is certainly fair to say, “Fail early, fail often.”