top of page

Create a Proof of Concept before going full throttle with your automation

Starting an automation effort for a project that has no automation whatsoever is always a fun and challenging experience. But you need to clearly understand what the goal and specifics of your project are, to achieve success in the automation effort. Before jumping into writing the first automated tests, you need to gather some information, perform some analysis, and build a Proof of Concept, to make sure you picked automation tools that really work on your product.

Once you established the tools, programming languages and frameworks, you should create a Proof of Concept project. Simply because, on paper, your choice might seem the right one but, sometimes, some of the chosen tools will not work as you expect them. Either because there are too many interactions between different types of systems involved in the end-to-end test scenario, or because the automation tools do not work on a technology your product uses.

Creating a Proof of concept should be rather straight forward. You should create a new code project from scratch (and by project I mean a project you would normally upload to your desired code repository, like Git), or use an existing one in which you can perform additional setup, without breaking any existing testing. You should set up all the dependencies as per the official documentation of your frameworks. And then you should proceed to building the actual demo tests. What to keep in mind:

  1. A proof of concept is not a fully functional project. Many setup parts can be omitted at this step. For example, if you don’t have a requirement regarding what browser you need to use, you can just do the setup for a preferred browser. Afterwards, if the POC proves to be successful, once you actually use it to write the full suite of tests, you can do the setup for all other desired browsers. If you do have a requirement for some specific browsers to be supported, you need to implement all the required utilities for enabling them, because you need to prove you can automate tests for all the mandatory browsers. The proof of concept needs to have a minimal but functional setup (it needs to cover the minimum mandatory requirements).

  2. You need to automate a few full scenarios. This means that you need to demonstrate that you can perform end to end tests throughout the system. And by end to end I mean whatever an entire user flow throughout the system under test is, or whatever tests have the most steps.

  3. You need to automate through all the technologies you need to test. If you need to create tests for the Database, the browser front-end, videos and an API, make sure you cover all these aspects with at least one test. In the proof of concept, you need to prove that the solution you proposed (the tool, framework) can handle testing the required technologies.

  4. By performing the proof of concept, you can determine whether all the tools or frameworks you propose for the automation solution can work together to realize an end to end user flow. If not, then you need to evaluate either other tools, structure your tests in a different manner, or drop some parts of the testing all together, documenting why you cannot automate those parts.

Recent Posts

See All

Creating an Architecture for Your Automated Tests Writing Automated Tests in Small Increments 4 Times Your Automation Passed While Bugs Were Present Now That You’ve Created Automated Tests, Run Them!

This week my newest article was released, this time on how to use Log4j to log relevant test automation information:

bottom of page