Subscribe via RSS Feed

Author Archive for Ketan.Patel

Quality Assurance: Band-Aid Fix or Vaccine Cure to Software Projects

The Vaccine Approach to a Software Development Project: Quality Assurance as a Value Added Partner

Syringe-1Last week, I talked about the risks that go hand-in-hand with the Bandaid approach to software quality assurance.  With the vaccine approach, software quality assurance is not seen as overhead or a bottleneck. Instead, it is a value added partner that brings transparency and visibility in software development predictability.

Significantly different than the Band-Aid approach, in the vaccine approach the software quality assurance team is dedicated, full-time participants within software development teams.  They are co-located and work collaboratively with both the business and developers.  Acceptance criteria is defined in collaboration with the business and integrated with requirements.  This provides significant advantage over the “Band-Aid” approach to testing, both within projects and across the enterprise application portfolio.

The Vaccine approach to software quality assurance provides more than operational benefits. It strengthens both the delivery team and the quality assurance function overall.  Being embedded with and dedicated to a development team, software quality assurance people are immersed in the business problem as well as the solution while it is being developed.  Being fluent in the application, a tester is more likely to recognize the difference between an application failure and an environmental or situational blocker, and better prepared to correct the situation.  As a result, they are less likely to raise false defect reports that create “noise” that masks the state of application quality and impairs team efficiency by wasting other people’s time in disposition.

This approach also protects quality assurance leaders.  When able to work only part-time in any given project, software quality assurance can do little more than produce testing artifacts and perform tactical execution. Working in full collaboration with a project development team, however, allows the software quality assurance team to gain deep business knowledge.  A quality assurance team that is immersed in the problem domain is in good position to be IT knowledge workers.  This makes them better business problem solvers, and stronger participants in IT solution delivery overall.

Engaged Participant vs. Disengaged Auditor

The intended deliverable of any IT project is a technically sound, functionally fit business solution.  This is achieved through the engaged participation of all IT disciplines, including infrastructure, requirement, development, and quality assurance.  By only playing the role of auditor, the quality assurance team is a disengaged member of the solution team that certifies an application as production-ready.  Alternatively, by collaborating from the early stages of the software development lifecycle, and executing quality assurance continuously throughout, the software quality assurance team works as a value-added partner that directly contributes to an increased understanding and gradual evolution of a business solution.  Ultimately, this approach increases both the value of software quality assurance and the return on IT investments.

What steps can your team take to move from a bandaid approach to a more holistic approach to software quality assurance and testing?

Photo Credit: Andres Rueda

Quality Assurance: Band-Aid Fix or Vaccine Cure to Software Projects

If Quality Assurance is intended to be a vaccine to projects, then why is it so often being used as a Band-Aid?

BandAid-1In our daily life, we take preventative measures such as flu vaccines early in a season to avoid, eliminate, and/or to reduce chances to get sick. This is similar to QA being part of a software development project early on in order to reduce defects and minimize project duration and cost. Unlike a conventional testing approach–which merely reacts to whatever has been designed or developed and frequently is perceived as interfering with development)–QA’s role early in the Software Development Cycle helps improve predictability and makes development faster, and less aggravating.

During my career, I have seen QA teams that are “shared resources” supporting many projects simultaneously rather than dedicated to specific projects.  Huge armies of QA teams execute defined test cases/scripts to test and certify an application once development is complete.  Because QA team members lack application familiarity and test only at the end of the development lifecycle, they require significant execution support. Often, the feedback they provide is late in coming and often inaccurate.

The Value of the Vaccine Approach

Compare this to a vaccine approach where the QA team is dedicated for the duration of the software development project and testers are co-located with the business and development team.  Because they collaborate with the development team on formulating acceptance criteria and engage in testing continuously through development, they can spot the commonly-overlooked showstopper problem. Now, QA feedback is considered as timely and relevant and a value added partner in delivery. This increases the efficiency of the software development process and the effectiveness of solutions produced.

We all have our examples of exciting projects turned into nightmares. Creeping deadlines, tsunamis of defects, applications that fail to deploy or performance bottlenecks that just cannot be found. Unfortunately, these kinds of situations always occur at times when they are least welcome – right before the project deadline, during the holiday season or when you had planned that nice weekend getaway. Most of these nightmares can be eliminated if QA is considered a vaccine for the project lifecycle rather than a Band-Aid fix.

The Risks of the Band-Aid Approach

There are many operational risks with Band-Aid approach.  It assumes that the test cases are of high quality, and that feedback is timely and actionable.  These are unwarranted assumptions.  Like any IT artifact, test cases may be ambiguous or confusing to testers (of poor technical construction) or they don’t test what needs to be tested (of poor functional construction). Since QA leads are shared across several applications, there are chances for error in writing test cases.  Being part-time on every project, the QA team is forced to work independently from the development team.  Test cases/scripts are often written to abstract specifications in the early stages, before software is ready to be tested, and executed in much later stages of a project once development is complete.  They are not written in conjunction with the development of the software, or in full collaboration with development.  Also, the development team is often not made aware of specific QA and UAT acceptance criteria, nor does it receive testing feedback, until very late stages of a project.

There is financial risk as well.  This approach emphasizes unit-cost efficiency of test execution over a holistic approach to quality assurance.  On a test-cases-that-can-be-executed-per-person basis this model looks attractive, but to be cost-effective, there must be low overhead of execution.  The greater the effort required to stage testing activity (e.g., with test data or instructions to carryout testing), or to interpret the results of testing performed, the greater cost of execution.

What approach does your IT organization have to QA?

Next week, I will take a closer look at the benefits of a more holistic, Vaccine approach to QA and testing.

Photo Credit: Guerrilla Futures | Jason Tester