Agile – Is it a Panacea or a Placebo?

It is true that the fundamental twelve principles of Agile Manifesto (n.d.) have helped many projects succeed in organizations. These results are evident in the increasing 61% of agile practitioners promoting the adoption of Agile in organizations, as noted by the 7^th 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 it 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 testing the software with the goal of identifying 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 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 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

Principles behind the Agile Manifesto (n.d.). Retrieved February 13, 2013, from https://agilemanifesto.org/principles.html

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