Our Tap In Partner Parasoft cooked up this nightmare-inducing, Halloween themed piece; it was originally published on their excellent blog.
With Halloween rapidly approaching, let’s take a quick look at some of the top things that are killing software testers…
Accelerated Release Cycles
In response to today’s demand for speed and “Continuous Everything,” the software delivery conveyer belt keeps moving faster and faster. Considering that software testing has long been a thorn in the side of the software delivery process, it’s unreasonable to expect that simply trying to speed up an already-troubled quality process will achieve the desired results. (I Love Lucy fans: Just think of Lucy and Ethel at the candy factory, struggling to keep pace as the conveyer belt starts putting out chocolates faster and faster.)
If there’s never enough time allotted for testing, it’s probably a sign that your organization needs to reassess its culture as it relates to building and testing software. In most organizations, quality software is clearly the intention, yet the culture of the organization yields trade-off decisions that significantly increase the risk of exposing faulty software to the market.
Poor Quality Code From Development
Testers are hired to perform advanced testing, not chase after defects stemming from simple development mistakes which could (and should) have been caught during implementation. If the development team consistently applies development testing practices such as unit testing, static analysis, and peer code review to ensure that code meets expectations before it progresses to QA, that reduces the number of avoidable defects that QA has to spend time identifying, reporting, then later re-verifying. This is not only increases the team’s overall velocity, but also allows testers to concentrate on the already-daunting task of developing and executing their test plans within the very limited available timeframe.
Realistic Test Data
Access to realistic test data significantly improves the effectiveness of a test suite. Good test data and test data management practices will increase coverage as well as reduce risks However, developing or accessing test data can be a considerable challenge—in terms of time, effort, and compliance. Copying production data can be risky (and potentially illegal). Asking database administrators to provide the necessary data is typically fraught with delays. Moreover, burdening dev or QA with this task moves team members beyond their core competencies, potentially delaying other aspects of the project for what might be imprecise or incomplete results.
Some organizations have found that simulation technologies such as service virtualization reduce the horror of test data management.
Access to a Complete Test Environment
With multiple dependent systems, a complete and realistic test environment is nearly impossible to stage. Developers, QA testers, and performance engineers commonly face:
- Systems that are impractical or too complex for test labs
- Divisional and political boundaries that limit access to resources
- Inaccessible 3rd party/partner systems and services
- Scheduling constraints that limit testing to inadequate, inconvenient windows
- Missing/unstable components
- Evolving development environments
Attempting to resolve test environment access constraints by building out a staged test environment or virtual test lab can be extraordinarily expensive. In many situations, building such an environment with staged application instances and virtual test labs can be technically impossible—for example, when the dependent application is a third-party application, a complex system (like a mainframe) hosted by another division, or an application beyond the “geo-political” boundaries of the group executing the tests. Even when building a “complete” test environment is feasible, configuring and maintaining all the dependent applications involves a high ongoing operational cost.
The unfortunate impact: testers can’t test. Recent studies show that 64% of testers currently spend little to no time creating automated tests and only 50% of expected test plans are completed due to test environment access constraints.
If you’re trying to escape this tester-killer, service virtualization might provide you a safe refuge.
