While the industry is realizing the importance and criticality
of a proper test automation practice in delivering world class software, but
still it is very rarely looked as a ‘profit center’. The moment ‘cost center’
word gets associated with a practice all the ‘eagles’ of the world decent to
look at ‘measures’ to ‘save’ cost and run with ‘bare minimum’. The ‘required
focus’ to ‘criticality’ ratio still remains miserably poor. To augment the lack
of ‘desired focus’ it is often tried to be supplemented with the ‘available’
and sometimes the ‘available and not so useful’. The result: an inconsequential,
mediocre, fragile, maintenance intensive, unreliable automation practice. It
barely does the job for an abysmally low percentage of targeted functions which
results in low usability and low confidence of stake holders. Under tremendous delivery pressure and customer escalations there is no choice but
to organically boost the manual testing team, work overtime etc... etc…. The
story goes on and on, release after release.
The problem is not only on the planning and focus front but
also on the available or appropriate talent pool front. While manual resourcing
challenges are a different ball game which need to be addressed with the right
approach there are readily available technical solutions in market and community which if
employed with right customization can turn out to be the perfect fit for the insurmountable
in-house problem since ages.
‘Agile’, dependable, extensible, cost effective, rapid in-sprint
test automation is very difficult to achieve without having a proper extensible
automation framework in place. Most teams rely on internal development/automation
teams for development, enhancement, and customization of frameworks backing test
automation efforts. However the framework is a complete product in itself which
requires commensurate product development focus. Again because of the cost and
possibility of the product to fail, most orgs shy away from setting up such a framework
development team. So if we do not want to develop then the only options are to look at the market or go to the community. As a community and or practice matures
it is likely to churn out some reliable solutions which can be customized and
adopted.
But if you go out hunting in the market you need to be
very clear of what your ‘exact’ need or requirement is. Unless you are clear
with your requirements you are highly likely to pick up a misfit or a solution
for another problem which you do not have to solve.
So what is the requirement? Let us take the high level
requirement as ‘‘Agile’, dependable, extensible, cost effective, rapid in-sprint
test automation’.
So how to achieve this? A framework or a solution which is ‘easy to use’, ‘does not require huge learning curve’, ‘easy to write tests as in English-words/KWs’, ‘handy reporting and logging’, ‘platform or application agnostic’, multiple interfaces (API, Command, GUI), data-driven, decoupled test assets, and integration with CI. If you are planning to build, keep these features in mind. Even if you are not planning to build there are other solutions…
Since we have setup the boundary requirements, now we can proceeed to the next steps... I will try to touch other aspects and solutions in upcoming series…
So how to achieve this? A framework or a solution which is ‘easy to use’, ‘does not require huge learning curve’, ‘easy to write tests as in English-words/KWs’, ‘handy reporting and logging’, ‘platform or application agnostic’, multiple interfaces (API, Command, GUI), data-driven, decoupled test assets, and integration with CI. If you are planning to build, keep these features in mind. Even if you are not planning to build there are other solutions…
Since we have setup the boundary requirements, now we can proceeed to the next steps... I will try to touch other aspects and solutions in upcoming series…
To be continued…. Stay tuned... J