CIO / Director

We live in interesting times. Knowledge is available at our fingertips, no matter where we are. Social networks enable communication around the world. However, along with these marvels of the information age come weapons of mass distraction. With so many things competing for our attention—and so little time to focus on real work—it’s a wonder we get anything done at all. What does this mean for testers? A common belief is that only focused concentration leads to productive work—and conversely, that distraction causes procrastination and stifles creativity.

Software runs the business. The modern testing organization aspires to be a change agent and an inspiration for quality throughout the entire lifecycle. To be a change agent, the testing organization must have the right people and skill sets, the right processes in place to ensure proper governance, and the right technology to aid in the delivery of software in support of the business line. Traditionally, testing organizations have focused on the people and process aspect of solving quality issues.

When working on test automation, it seems that even though you have done everything right—good architecture, efficient framework, and good tools—you still don’t make progress. The product Seretta Gamba’s team was to automate had become so successful that anyone with even a little domain knowledge was sent to the field while those left on the automation team didn’t really know the full application.

Current Test Process Improvement (TPI) models have proven to be a mismatch when used to assess testing in an agile context, since it is significantly more difficult to describe how to become more flexible than it is to describe how to become more structured. So what’s missing in the current models and how can we help organizations improve their testing in an agile environment? Jeroen Mengerink introduces a systematic model to improve the testing in agile software development.

The demand to accelerate software delivery and for teams to continuously test and release high quality software sooner has never been greater. However, whether your release strategy is based on schedule or quality, the entire delivery process hits the wall when agility stops at testing. When software/services that are part of the delivered system or required environments are unavailable for testing, the entire team suffers. Al Wagner explains how to remove these testing interruptions, decrease project risk, and release higher quality software sooner.

No one wishes to see himself as different or treat other people differently because of his uniqueness. Unfortunately, we are frequently judged and our skills presumed based on our ethnicity, beliefs, politics, appearance, lifestyle, gender, or sexual orientation. Our professional success and our projects’ success can be derailed because of lack of understanding, stereotyping, or fear. Our professional environment includes us all―brown, black, white, tall, short, male, female, straight, gay, extroverts, and introverts.

We QA professionals know that the ideal is to build quality into a product rather than to test defects out of it. We know about the overhead associated with defects and how costs grow over time the later in the development process we find defects. If prevention is better than cure, shouldn’t we invest more time and effort in preventing defects? Kirk Lee shares the things we testers can do before coding begins to keep defects from being created in the first place. Kirk explains how to involve QA at the very beginning of the development process where prevention is most valuable.

With the behavior-driven development (BDD) methodology, development teams write high level, plain natural language tests to describe and exercise a system. Unfortunately, it is difficult to develop BDD tests that encompass all interfaces and write tests that can be reused in multiple scenarios. Specifying BDD tests to run as part of different test scenarios without duplicating work frequently requires substantial effort and rework. But Cucumber provides a robust framework for writing BDD tests.

Teams are a fundamental part of the way we all work. Understanding the ins and outs of team decision making makes us better employees, better co-workers, and even better people. As developers and testers, we continuously make decisions. Most decisions are based on how the decision maker perceives the information at hand. That perception is driven by many factors including cognitive biases—the mental shortcuts we use that lead us to simplify, make quick decisions, and ultimately mess up when we’re trying to attack new problems.

Load testing is often one of the most difficult testing efforts to set-up—in both time for the deployment and cost for the additional hardware needed. Using cloud-based software, you can transform this most difficult task to one of the easiest. Charles Sterling explains how load testing fits into the relatively new practice of DevOps. Then, by re-using the tests created in the load testing effort to monitor applications, the test team can help solve the challenges in measuring, monitoring, and diagnosing applications―not just in development and test but also into production.

Today, organizations are rapidly deploying mobile versions of their customer-facing and internal applications. With the prevalence of more agile-based approaches and the challenge of an ever-increasing diversity of devices and OS versions, testers are being asked to accomplish more testing in less time. Rachel Obstler shares how leading enterprises are improving the efficiency of their mobile testing using automation, and how they identify the right processes and tools for the job.