Though ‘Fail Fast, Fail Often’ is a commonly misinterpreted phrase, in a positive opinion of the person using the phrase, it is supposed to mean that there should be a quick feedback loop such that errors are caught quickly and frequently. And, creating such a feedback loop means that there should be sufficient resources to enable quick turnaround to learn from the failures and make the system ready to fail and come back up again.
Implementing Fail Fast, Fail Often
Fail Fast, Fail Often not only means the ability to fail, but it also means the ability to rectify just as quickly and any number of times. Achieving this means putting in systems that can speed up processes and allow for quick feedback. It is only when you have the ability to resolve failures in a minimum amount of time that the ‘fail fast, fail often’ mechanism works.
At present, there are multiple tools and products available in the market that aim to cater to a pain point and make the process easier. But because not all products and processes are the same, the same tools cannot cater to all the needs to establish ‘Fail Fast, Fail Often’. Hence, according to the product and the specific processes followed, thorough research needs to be done on what tools should actually be used.
Fail Fast, Fail Often during Software Development
In the Software Development world, Testing is an important process because that is what decides if the software can be released into the market. Testing is also of various types and is done at different stages of software development. Testing is just like a feedback loop at every step to uncover any issues before moving to the next stage in the SDLC.
For eg. Let’s say during the Design Phase, the Developer created a design for which development will be done but soon after a tester figured out a bug in the design. This would hamper the software quality in a real time scenario. Here, the Design failed but the feedback was quick so was the defect fix. Hence, in the next step, this error will not be repeated.
Similarly, just after the development is complete, there will be a short round of testing called smoke testing that verifies that the happy path works. This also gives a good quick feedback at the earliest and bugs can be handled at short notices.
Test Automation and Fail Fast, Fail Often
After the test cases are designed and the software is developed, it is test automation that matters. If the number of test cases that are automated is more, there is a better probability of catching any introduced bug with any new build. But for the feedback to be configured for every check-in and build, there needs to be a continuous integration system in place. After the continuous integration is put in place, the process that is followed is as below:
- The new code is checked in to the repository
- The code is compiled and built
- If the build is successful, test cases are executed.
- After the test case execution, a complete report of the successes and failures of the test cases is sent via email to the concerned people/the team
- If there is any failure, the bug is identified, the feedback is sent and the issue fixed followed by rounds of regression testing. Again, the process starts from Step 1.
When all the possible steps above are automated, the time for feedback reduces by a great deal and when the test cases are run every single time, some code is checked in, the “fail fast, fail often” methodology is realized.
In terms of test automation, the execution of the test suite after every check-in is the major contributor to fail fast, fail often. Thus making it work at its best becomes important. One way is to enrich the test suite with all types of test cases including the complex ones and the edge cases. This can be achieved if along with the testers, other stakeholders are also involved in test case creation.
For eg. The client knows of the critical scenarios that can never fail for them, the project manager knows of the errors that need to be caught before the build reaches the customer, the developer knows the intricacies of the product and will know what parts will be impacted by any feature change. If all of the knowledge along with that of a tester is unified and put into place as automated test cases, the ‘Fail Fast, Fail Often’ system will surely work as it is supposed to. A tool that allows for scriptless test automation and relaxes the learning curve is the way to go here.
Resolution after failure
When there are changes in the code, changes in the test cases will be needed too. The answer to this is a tool that modifies the test cases according to code changes and makes maintenance easier. Testsigma is a tool that uses AI at its core. Here test cases can be written in simple English using NLP and AI adapts itself to new changes automatically.
Another challenge in the software world is the technology and methodologies that change every other day. Keeping up with these changes is essential for the companies otherwise they face the threat of losing out on the competition in the market. Here again, a Unified test automation tool like Testsigma comes to rescue where it helps maintain the test cases using the AI and provides integration with third party tools. In addition to local devices‘ execution, it also provides cloud hosting for all test cases as well as a dedicated device farm to run those test cases on. So the cost of investing in the procurement of any new devices in the market that needs certification is reduced.
Thus, enabling your testers with the latest tools in the market with the least amount of effort and keeping your test cases up to date and good on coverage will help your software development process to fail fast, fail often via well-defined test automation.
Business vector created by freepik – www.freepik.com
