Developers Compliance to Test Automation
Published by adel on Friday, April 11, 2008 at 8:22 PMA TestSquad reader sent me an email asking:
Is there a verification process to help validate that application developers comply to test automation requirements during their application development?
Usually we just give the requirements and expect application developers to comply but when you are doing the automation scripts already, some things are still skipped. I am looking for a process that will help them comply.
e.g. automation requirement: name tables as xxxx
I have to admit that answering such a question is not easy. How can you guarantee that development activity is compliant with a subsequent test automation? How does the developer's code affect the success of your test automation?
1 month ago, i was considering Selenium RC to automate a Java web application. Unfortunately and for a reason, automation was not introduced till a late stage in the project. So as soon as we started recording scripts, a problem emerged: the development team did not give an "id" attribute to the numerous html elements. And this forced us to use some workaround; unnecessary if if the QA automation effort was introduced from day one. This is relatively a simple scenario that could be solved using workaround, but i am sure the impact can much more severe for complex projects.
So a corollary answer for the original question is "continuous collaboration between developers and testers from day one in the SDLC" and that naturally leads us to Agility.
I like to use LinkedIn for tough questions. Here's the best answer i got from Greg Akins
I don't think there is an easy answer to this. One issue is
that there is a responsibility for the developer to not only create
features which are requested by the customer/business, but also to
ensure that the features are are created in a way that supports the
test process. It's my experience that the incentive to do the latter
is somewhat limited.
However, having spent time writing and designing Selenium and FIT
tests on smallish team, there was a long learning period associated
with getting the team to understand how the application needed to be
designed to support testing. I'd definitely suggest working side by
side with your developers, and iterating frequently while you're still
expecting frequent "failures" in the dev/test process
I would love to her your personal experience :)
Devise a test plan.
1)High level:
Start with a chart - structure chart of the modules, this will help with test coverage(completeness)
2) Low level:
Use a traceability matrix/table to link all requirements to a test case.
Then build the test scripts for all the test that are needed.
The first thing which testers should always do is to be engaged and tell developers what they need. If they are part of the software design process they should make sure that the needs of test automation are articulated/captured in meeting minutes. As with other issues testers should be on top of/aware of what developers are doing. Usually for automation developers should be amenable to helping testers (more than with other issues). For example if a defect requires a major architectural change late in the cycle, you may face developer resistance. Enhancing automation ability is usually much less difficult.