In the spirit of Halloween, we thought we'd bring some of your favorite Halloween-themed software testing blogs back from the dead (as well as invite you to a new live Halloween webinar).
1. What’s Killing Software Testers?
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 cconveyor belt starts putting out chocolates faster and faster.)
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.
2. Software Testing Demons That Service Virtualization Can Exorcise
Ever had a frightful encounter with the following testing demons? They tend to lurk around complex interconnected systems, just waiting to wreak havoc by forcing you to delay testing, work at dreadful hours, or make distressing trade-offs on the completeness of your testing.
1. Evolving Incomplete Systems
You're ready to test the part of the system that you're responsible for, but you can't really exercise it unless you interact with other system parts that are still evolving—or not yet even implemented.
2. Inaccessible Systems
This includes those dependent systems available for testing only from 3am – 5am on Saturday morning. They're a close cousin to the evolving/incomplete systems: the reason you can't access them is different, but the impact on your testing is the same.
3. Third-Party Access Fees
Pay-per-use fees for cloud-based or shared services such as payment card processing, credit checks, etc. might be an expected expense for production usage. However, these costs can escalate quickly for continuous testing or high-volume performance testing.
4. Other Teams Working on Shared Test Environments
It can take hours or sometimes even days to get a test environment configured exactly how you like it—then another team comes in and re-configures it to suit their needs. You can't blame them, but it's frustrating nevertheless.
3. Software Quality Stats Scarier Than Halloween
What’s scarier than all the ghouls, ghosts, and goblins you’re likely to confront this weekend? If you're in the software business, you'll probably end up with more nightmares from the following stats than from any Halloween horrors.
- Only 50% of developers/testers are using Continuous Testing within DevOps. 29% aren't using it yet, but plan to. 21% have no plans to start. (Capgemini, Sogeti and HP World Quality Report 2015-2016.)
- 35% of testers report that they spend more than half of their week not testing. 46% want to spend significant time creating automated tests, but 64% currently spend little to no time on it. (Software Quality Engineering survey.)
- Over one-third of developers don't think their companies perform enough pre-release testing. 56% estimated that their last significant software bug resulted in an average of $250,000 in lost revenue. (Electric Cloud survey.)
4. What's Frightening? Test Environment Access
Across the industry, the level of QA awareness of (and access to) system dependencies associated with the application under test is truly frightening. Test environment access constraints have become a significant barrier to delivering quality software efficiently:
Agile and parallel development teams inevitably reach deadlocks as different teams are simultaneously working on interconnected system components — and each team needs to access the others' components in order to complete its own development and testing tasks.
Performance test engineers need to test vs. realistic transaction performance from dependent applications (third party services, mainframes, packaged apps, etc.), but it's often unfeasible to set up such conditions.
End-to-end functional testing is stymied by the difficulty of accessing all of the necessary dependencies — with the configurations you need to test against — at a single, convenient, and lengthy enough time.
What's even scarier is that a recent Test Environment Access study found that, as a result of such test environment access constraints, testers had time to execute only 50% of the expected test plan on average...
Live Webinar — The Legend of Software Hollow: Defeating the Headless Horseman of Faulty Applications
We're also hosting a live (well, as "live" as it gets on this day) Halloween webinar: The Legend of Software Hollow: Defeating the Headless Horseman of Faulty Applications.
Software defects are like the headless vengeful spirit of yore terrifying customers and laying waste to all that cross its path. How do you rein in quality issues that affect the safety, security, and reliability of your applications? You can take the Brom Van Brunt approach and attempt to test quality into the application using brute force. But without applying process-based policies, it’s only a matter of time before faulty software rears its ugly...uh...neck?
The Ichabod Crane-like alternative is a much more effective way to banish software defects forever. In this special Halloween webinar on Monday, October 31, 2016, 11:00 a.m. - 12:00 p.m. PDT, we’ll discuss how an automated application of software quality activities can help you survive releases as the Headless Horseman of software quality issues attempts to ride through your application.
Examples of preventable defects that commonly degrade software quality
Automating static analysis to improve safety, security, and reliability of your applications
Combining static analysis with metrics, coverage, and data from other quality activities to demystify potential problems with your code