top of page

Test Automation Quadrants

Being a Test Automation Lead, it's always challenging to bring team members on the same page to agree on the Test Automation framework. And that’s where I came up with this Test Automation Quadrant where I thought of taking S.W.O.T principles, especially Strength, Weakness & Opportunities into the account. I asked the whole team (including developers) to stick one post it note in each quadrant based on their preference. Once everyone was done with this exercise. We discussed and took some actions out of it.

Interestingly, it worked for my team and quickly we identified the gaps and it help us to take a decision and some actions as a Team. So here is the First Look of the Test Automation Quadrant:

Scripting Language

Being in a very challenging and fast/continuous delivery environment. It’s very important to identify which scripting language could be used to automate the tests. The key is to go with a scripting language that testers are familiar with, but something developers are comfortable too, or at the least they know the basics. The advantage is when any Test Automation complication arises. The whole team is able to help.

This quadrant gives opportunity to expose any learning curve as well. In one of my examples, Testers were comfortable with Java and Developers were comfortable with JavaScript and also in Ruby. We decided to go with Ruby as its light weight in comparison to Java.

And as an action, we arranged a couple of Ruby sessions/brown bags to testers from Developers.

Test Execution Environment


This is quadrant is again very important, helps to identify the nature of the project and its requirement to run the tests against.


For example, our web client was heavily user facing and our tests has to run on multiple OS’s browsers and Device browsers.


There were post it notes about Selenium Grid and VMs station and the budget for the environments and who will take responsibility to maintain the test environment. After discussing from these points (mentioned above). We took action to explore cloud based testing environment as its cheap and maintained and looked after by the cloud environment.


Frequency to Run


This quadrant again is very important, helps to identify the nature of the project and its requirement to run the tests against.


For example, our web client was heavily user facing and our tests had to run on multiple OS’s browsers and Device browsers.


There were posted notes about Selenium Grid and VMs station and the budget for the environments and who will take responsibility to maintain the test environment. After discussing from these points (mentioned above). We took action to explore cloud based testing environment as its cheap and maintained and looked after by the cloud environment.


Reporting


In this quadrant, we discussed about two types of Reporting mechanism which could add massive value, one for management and one for the team to look into the failing tests and provide a fix if it is a bug.


We took action to send an email after every run to the team members (excluding managers).


And Test Automation Report, which shows % of failing and pass for the release purposes.


In summary, this approach has helped our team identify the gaps and to bring all the team members to the agreement (Collaboratively) for Test Automation.

Let us know your thoughts/ comments on this page or via email itqaworld@gmail.com

26 views0 comments
bottom of page