A Proof of Concept in Automation testing deserves a thorough preparation and implementation to verify the automation venture. Once it is done right, the QA team can leverage valuable insights to have timely adjustments for the application of automation testing.
Proof of Concept (POC) is a broad technical term used in various industries. Teams and companies use a POC to prove that their idea works in real-world environments. A POC is crucial in the decision-making process because its results can be informative enough to point out potential issues before they happen.
For example, imagine that you are calling for investment on your potential business idea. However, investors hardly believe in plain words unless you have evidence for your success. This is when a POC is necessary to showcase your action plan in a small scale environment.
POC in Automation Testing is usually conducted when the team wants to adopt a new automation testing tool. As a part of the first phase of the automation transformation, the team may consider implementing a POC after evaluating and selecting an automation tool.
Although QA teams may have spent a lot of time on tool evaluation, an Automation Testing POC is the final step to test and challenge all the assumptions. There are certain aspects related to automation that a well-designed POC can help verify, including:
- The difference between manual testing and automation testing in terms of outcomes and test quality
- The capability to meet the testing requirements of the automation tool
- What can and cannot be tested automatically
- How much automation testing saves compared to manual testing
- The predicted ROI of test automation in the long run
- Hidden issues of the projects that require changes
Implementing an automation solution takes time and considerable monetary resources. Instead of jumping right into that process, conducting a POC will get the plan audited in a short time with much less effort.
As mentioned earlier, stakeholders are the other group that needs a clear POC in addition to QA teams. Without the POC, business owners and investors may venture blindly into the unknown.
Regarding financial viability, which is crucial for all businesses, and automation testing POC shows decision-makers if the planned automation solution is viable and brings out healthy ROI. This is also an excellent way for investors to evaluate better the projects that they are about to invest in.
With all these significant benefits, a POC ensures that teams and businesses will take the best advantages of automation testing, not eroding them.
Decide the scope of work used in the POC
- It is unnecessary to cover all test cases of the project in a POC. Instead, the team should pick up some of the most critical test cases. They can be core functions of the software or features that end users will be most interested in.
Know the benchmark
- The team should be able to benchmark the POC results against the current testing state. Knowing the current baselines will help with the comparison later on.
Demonstrate both automation and manual testing
- It should be shown in the POC that there is no degradation in the test quality delivered by automation.
Have at least one failed test case to test the functionality of the tool
- Ideally, a POC needs to have at least one test case that fails, meaning it results in finding a software defect. A proper automation testing tool must find out the flaw in such cases.
State areas that can and cannot apply automation
- Although the POC aims to prove the automation tool’s necessity, it needs to show areas in the testing workload that cannot be automated.
Expected outcomes for the POC
- Setting up a set of requirements for the POC in advance will help analyze the results after completion. There are some key factors that an automation testing POC should highlight:
- Is the automation tool able to automate all the intended features of the desired application?
- Can the automation tool run on all browsers required by the project?
- Will automation call for change in-app implementation?
The standard template for an automation testing POC varies on a case by case basis. In general, it should cover:
- A set of requirements for the POC outcomes
- Candidates of the POC (Selected automation tools in this case)
- Project requirements
- Pros and cons of each automation tool according to the project requirements
- POC results
After conducting a POC, there are three possible scenarios for the team to take into consideration.
- The tool satisfies the project requirements —With this result, the tool can be considered feasible for real-world implementation. However, if there are any issues found during the execution of POC, they should be carefully assessed in order to make changes accordingly.
- The tool does not satisfy the project requirements —In this scenario, the automation transformation must be either canceled or postponed for further evaluation.
- The tool partially satisfies the project requirements —This situation requires the team to have more data to be able to make final decisions. Usually, the team can opt to revise their project requirements.
For the first scenario, the POC stated the automation tool’s feasibility and got approved by the management team, the next step is to work on a pilot project.
Basically, a pilot project creates a real-world environment to test a solution with minimum expenses. In automation testing, a pilot project is necessary to challenge the approved POC when it is applied in reality.
A standard pilot project for test automation should include these five steps:
- Defining test cases for pilot
- Developing automation framework
- Scripting and executing
- Maintaining automation scripts
Once the automation testing POC and pilot project are completed, their results come into practice. With insights gathered from the POC, the decision-maker can have a better data-driven approach to their automation transformation process.