What is the context here ? Let me give you a typical scenario on a project in an Enterprise company: a project to be delivered with a timeline of 6-12 months. Development team consisting of developers, business analysts, quality analyst and a Scrum master. Why this blog, probably because we want to talk about the past impacting our present, yeah kind of ! If you see
In the above team composition, we tend to differentiate only quality analysts to be consisting of both manual and automated testers. Now that we brought up the differentiation, have you noticed the team composition ? Yes it’s an unbalanced team fewer automation engineers who focus only on writing automated test suite and maintaining it. And majority of manual testers daily creating tonnes of documentation which they will only consume and kind of treat that as one of the most important piece of artefact in the project.
By the way I am not against writing test cases ! Shown above is how the typical team composition would look like. Green one is the automation QA and balanced by bunch of manual QA.
The problem is not the team composition, it arises when we start fiddling around with expertise of some people. Manual testers are good in exploratory testing and that is how we should be utilising their experience on project. What generally happens is we want to revolutionise the software testing by making everyone do automation. And so it happens in the process that someone sells the idea of keyword driven framework, or some excel driven framework !
Recalling one of our past experience of working with an IT major, what we saw was totally frustrating ! The QA manager had bought into this kind of solution and went ahead asking some folks to build the solution accordingly or purchased a tool which promised them building Rome overnight ! Probably one of the selling point there is also getting the manual testing team write the automated scripts and there by increasing the throughput of testing team. Also we need to understand that there is no magic framework on earth which will help you increase your coverage faster.
This is not just a scene in one company, in fact we found a pattern that where ever the test team is isolated and has a mix of manual and automated tester we found the same situation. What is wrong with this solution approach ?
- Diluting the quality of your test code
- Everyone goes on a spree of adding the number of test cases
- Test Coverage goes for a toss
- No easy way of integrating with CI
- No real feedback on developed code
- Maintenance of test solution increases exponentially
- Compromised Exploratory testing as everyone is busy doing automation
- Not a scalable solution
Well you can surely add up from your experience but these are the few which we felt are the basic things which get screwed up when you adopt Keyword driven tool or framework to speed up automation.