It is true that the fundamental twelve agile principles (http://agilemanifesto.org/principles.html)
have helped many projects succeed in organizations. These results are evident
in the increasing 61% of agile practitioners promoting the adoption in Agile in
organizations, as noted by the 7th annual state of agile development
survey conducted by Version One. But, several agile purists focus on some of
the buzzwords, such as the Test Automation, making as though Agile is the cure-all
for all business problems.
Those in the technical world may understand the famous statement, “Not all
business problems are nails to use the same hammer as the tool,” when common
object request broker architecture (CORBA) was initiated to introduce by Object
Management Group (OMG) the communication between software components regardless
of the underlying language used to develop them. However, it is interesting
that some agile practitioners are inclining towards test automation as a cure-all (panacea) treating
all test cases alike.
Testing requires two basic requirements namely verification and
validation. Verification is the process of evaluating test cases, test scripts,
requirements or user stories to ensure that the process of testing is going to
ensure that the required functionality is present to meet the user
requirements. The focus of verification is on the process and is therefore an
improvement process oriented towards assuring quality (QA). But, validating is the
ongoing approach to test the software with the goal to identify defects. These
defects could be traced to the faulty code, inaccurate design, incomplete or
ambiguous requirements, misinterpretation of the requirements, or a combination
of these factors. Validating therefore aims at controlling quality (QC).
So, test automation can definitely help in the validation to ensure
that every incremental build is tested for the new features but also for the
previous features. It is therefore not a placebo but is not a panacea for all
business problems. Depending upon the unique business requirements, some
requiring can’t be easily automated even if technology can allow it. For
instance, testing the human interfacing with the interactive voice response
(IVR) at various points in the call flow to check for the disposition code,
checking for the line breaks in the email, or the accidental mix up of Far
Eastern Asian Language characters because languages such as the Chinese,
Japanese, and Korean share a common base do benefit from manual testing.
It is therefore important to evaluate what is the business need in test
automation and identify areas that can lead to efficiency gain. Redman and Nielsen
(2013) very nicely paraphrased Deming in the Harvard Business Review article suggesting to carefully select the right process
to automate explaining “… automating a process that produces junk just
allows you to produce more junk faster". Deming might have inferred
this long before the agile was conceived but some golden principles do stand
the test of time.
References
Redman, T.C.,
& Nielsen, D. (2013). Computerization in Health Care Demands High Data
Standards. Harvard Business Review. Retrieved February 28, 2013, from http://blogs.hbr.org/cs/2013/02/computerization_in_health_care.html
2 comments:
Would like to share my thoughts on this -
While I certainly agree with Dr Sriram on this - there is a subtle difference in the way I look at this.
The main advantage of the automated testing in Agile is the confidence it gives the team in turning around a change request.
There are plenty of stories in software development where a component or a module or a function is NOT touched by anyone due to the fear of breaking some functionality.
This fear is tackled in a very powerful manner by automated tests which can perform regression.
There is of course a limitation in that this depends on the code coverage achieved by the test cases - this in turn depends on the amount of time that a team can spend on this.
Apart from this - one other good concept is that the testers automate most their work having some free time to perform tests which cannot be done using automated tools such as usability of the UI or look and feel of the UI etc.
Sanjay,
Thanks for your response. I certainly relate to your viewpoint and don't disagree with you. But, I think there is an organizational imperative to ensure that the tools and training are provided for agile teams to reap the benefits. What are your thoughts on this?
Post a Comment