I have spend 2 years in manual testing , 2 years in web automation testing and 1 year in software development across various tech stacks in various companies.

Nobody denies the fact that testing is the key ingredient for quality software development. I would go one level up and say these words

“Well Planned Testing is the only ingredient required for building best software products”

What is testing?

Given a certain input, When an action is performed, Then the outcome should match as expected. Plain and simple to explain.

Testing takes place at various levels of software development project. The more detailed the tests and each level , the better the software. At some levels the tests can be like “Verify that a string becomes camelCased upon calling a method named uppercase . And the tests can be like Verify a mail is received by recipient after sending a mail to a valid emailId” .

Test Pyramid is a well known concept of how to plan testing of a complex software project. A key part of the pyramid is AUTOMATION. And people to do automate the tests at every level , however the tests priority and tests ownership is the least at the peak of pyramid. And when regression sets in, questions are raised on this layer of tests by management.

Here is my RANT on why automation of the peak layer fails.

• Automation scenarios are listed out by QAs (good thing) , but implementations are done as PET PROJECTS.

• Pet Projects are written by using an arbitrary technology and since not all QAs are technical , not all of them get involved.

• The automation tests does the intended job and it provides a great sense of regression security , but the code lacks production code standards since it is pet project.

• The writer wouldn’t have spend time on learning clean code and neither the fellow colleagues get involved in learning it (specially manual testers) . Even if some other QAs get involved, the quality never increases because they don’t spend full time on it.

• One fine day the writer leaves the company, and the tests would fail in the CI and no one takes ownership of it. More features are added the tests break, but nobody maintains.

• Meanwhile a new QA who knows a bit or programming joins in. A regression happens in the software and the blame goes to the QAs for not maintaining automation tests.

• This new QA rises up and scans the existing automation test. He may or may not know the tech stack, but maintaining seems hard to him. Then he starts his own PET PROJECT and re-writes the test-cases.

Things that “PEOPLE THINK” could have prevented the re-write.

• Creating a dedicated automation testing group. This won’t work out because in the agile world , teams tend to be small and QAs tend to be less as well. Even if a manager creates a dedicated automation team , the members rarely pay attention to the functionally of the product. This happens because their success is determined by the number of cases translated rather than having a deep understanding of the product and no brainstorming in creating the correct suite of automation cases. This leads to mindless automation and huge suite of test cases . Violates the Test Pyramid

• Developers only writing automation suite. The same problems of the above point exists. Along with that the developers feel like “this code” is a second class citizen job (just because it doesn’t go to production) , and nobody wants to pay attention to it since devs fear that their career would change.

Test automation gets treated as a second class career, sadly.

Back to the title of the article, whose job is it anyway?

First, test automation SHOULD NOT be treated as a pet project . Even if someone starts as a pet project, they should not go beyond 2 scenarios. The pet project should be presented infront of management and senior developers and need to be presented as a case that the project needs to be treated in the same way as a production code , and any engineer should be able to support it as and when required. An OATH taking ceremony needs to be done.

Next, assuming the team comes to a consensus regarding the tech stack to be followed, taking a leaf from pair programming, a QA too should pair with a developer. The developer role can be rotated on periodic (sprint basis).

Following are the advantages of pair programming.

• Pair Programming makes sure that knowledge exchange happens. QA will be the driver, Dev would the navigator.

• The developer makes sure that code quality remains high

• The rotation of developer makes sure that even if a QA resigns, the tests at least can be maintained until the next QA steps in.

• The automation tests slowly becomes the savoir of the masses for devs . They will make sure that these tests are run against their commits.

• The QA on the other hand improves his own coding skills.

• Finally the QA , who does the manual testing, also brainstorms in making the right choice of test cases and follow the test pyramid.

Well that was my idea , I would like to know what others think about it.

May be question still remains.

Test Automation — whose job is it anyway?