Every team's objective is to deliver a high-quality function with excellent features/applications/services that customers love and do quickly. One approach to meet this objective is quickly changing course when something isn't working instead of continuing down the wrong path. This technique is known as failing fast.
Of course, the same approach must be applicable when we, as QA Engineers, introduce Test Automationin our projects, but we will try to expand this concept of failing fast and translate it into learning more.
Automation testing can seed confidence in delivering software and improve the team's capacity to develop high-quality applications in the fastest and most efficient way achievable. Furthermore, it eliminates the need to compromise or choose one set of priorities over another (Exploratory Testing or other Testing approaches). Instead, it allows teams to balance confidence/coverage and speed/efficiency.
Failing when Following the Traditional Model
If your approach is going to fail, you want to realize that as soon as possible. As QA Engineers, we are human beings; and we make human mistakes. Cognitive errors include:
- Choosing the wrong market.
- Forming bad partnerships.
- Selecting the wrong tool.
- Choosing the unfair process.
- Not understanding our customers.
When we focus on the person who proposes an idea and invests in their plan, we expect them to figure out all the answers. But, of course, we need to work with the person proposing the idea and understand where is that strategic plan coming from. How do we know if it is the right one? Are people being honest? Is the person accepting gaps or deficiencies?
When we focus on the idea rather than the person or persons in charge of implementing it, we can make the unknowns known more. Figuring out what an idea's failure points might be is a better way to help organizations prepare for things that are out of their control; some might be the person's failure points a unique perspective and experiment in the admonition hubris.
SUGGESTED READ -
Understanding the fail-fast principle
The principle of failing fast is either the best thing since personal computers or nothing but a useless thing. It depends on your company's size and your team's cohesiveness. For example, suppose your team members have a strong working relationship and are well integrated with everyday work company-wide. In that case, you already have a good foundation for this particular agile thinking.
Fail fast is an agile principle that encourages experimentation to reach the desired outcome. What is experimentation? It's not throwing stuff at the server to see what causes a failure; it is a thoughtful examination of a problem with a solution that leans more on experimentation than proven methodologies.
Test Automation Fail Fast Flaws
The challenges of failing fast tend to arise as you continue with this practice. Test Automation could be expensive, and people and resources are expensive. Mistakes can be very costly, and the benefits of this approach tend to feel less important.
Thomas Edison once famously said, "I have not failed 700 times, not failed. I have succeeded in proving that those 700 ways will not work. When I have eliminated the ways that will not work, I will find the way that will work." It is at the core of the problem; experimentation is not failure but an exercise in learning.
Imagine some innovative company culture tending to fail and fail fast as the key to rapid learning. In Test Automation, it could sound like a piece of terrible advice and the wrong approach, especially if you are using other people's money (Perhaps the QA budget). But, it probably works in the end, as we can conclude from experimentation, for example:
- Select the right tool after running multiple PoCs and understanding our necessities.
- Choose the right Test Automation strategy after seeing the results (The real value, delivering applications/services with high quality).
- Understand our customers and add customer-centric scenarios to our Test Automation scripts.
- Implementing the exact Test Automation process helps shorten our project’s lead time.
Companies should embrace the end in mind and develop action plans and solutions to counter potential failure points. Instead of filling cracks with the endless PoCs or Experimentation processes, fill them with a solid, concrete technique to address possible failure. And if your organization, team, and customers concentrate on preventing failure points, we will end up closer to the vision of success and actually might find some hidden opportunities.
Test Automation and How to Success`
The reason to grow is that we have more fuel to advance; we don't get a car simply so we can buy more gas, and test automation is the same. Test Automation, like a car, is more valuable to all members when it takes us somewhere we would otherwise be unable to go.
“What failed” it’s now “what did we learn today.”
The key to success in automated testing is to help people work smarter. First, recognize what the automation test can do and be equally aware of what it cannot do in your project/company (The expectations must be precise). Then, it helps you make valuable decisions in the most critical areas, for example, identifying areas to be automated, understanding how it should be done, and who should work on it.
What fascinates me the most about test automation is its relationship with all other aspects of the development cycle. Besides quality and productivity, which are apparent, test automation is also related to the product's architecture, business processes, organizational structure, and culture. Test automation is a liaison into all of these aspects. Of course, all of these aspects affect test automation.
As the thumb-up rule, consider the following during your Test Automation process:
- Make the cost of running the ever-growing regression test suite minor(Parallel Testing can be beneficial).
- Keep the test scripts very easy to maintain
Keep in mind as part of the success and learning part of test automation is merely automating a process you already have in place (Quality Assurance process); automating a good process shows how faster that process can be. Conversely, automating a flawed process amplifies its weaknesses. We want to find failures in our system; automating a lousy process could be fatal as it could find other losses unrelated to our applications/systems.
Most people get wrong about persistence. Persistence doesn't mean repeatedly doing what's failing (Automate flawed processes). Remember the adage about the futility of doing the same thing repeatedly and expecting different results? The goal isn't to fail fast. It's to learn quickly. We should celebrate the lessons from failure, not failure itself.
Failing fast requires a great company culture where the teams have the space to fail but can learn something from each failure. That enables the team to succeed faster the next time (Sometimes, failing too much is not an option, and it could be horrifically expensive).
The real value of Test Automation, no matter the Automation tools in place, is faster delivery of higher quality applications. Therefore, failure, as the first principle, must never be an option.