Test Manager

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.

And now for something completely different. Monty Python's Flying Circus revolutionized comedy and brought zany British humor to a worldwide audience. However, buried deep in the hilarity and camouflaged in its twisted wit lie many important testing lessons—tips and techniques you can apply to real world problems to deal with turbulent projects, changing requirements, and stubborn project stakeholders.

Far too often, agile transformations focus just on development teams, agile frameworks, or technical practices as adoption strategies unfold. Often the testing activity and the testing teams are left behind in agile strategy development or worse yet, they are only along for the ride. That’s simply not an effective transformation strategy. Join experienced agile coach Bob Galen as he shares the Three Pillars Framework for establishing a balanced strategic plan to effectively implement agile quality and testing.

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.

Many projects implicitly use some kind of risk-based approach for prioritizing testing activities. However, critical testing decisions should be based on a product risk assessment process using key business drivers as its foundation. For agile projects, this assessment should be both thorough and lightweight. PRISMA (PRoduct RISk MAnagement) is a highly practical method for performing systematic product risk assessments. Learn how to employ PRISMA techniques in agile projects using risk-poker.

If users can’t figure out how to use your mobile applications and what’s in it for them, they’re gone. Usability and UX are key factors in keeping users satisfied so understanding, measuring, testing and improving these factors are critical to the success of today’s mobile applications. However, sometimes these concepts can be confusing—not only differentiating them but also defining and understanding them. Philip Lew explores the meanings of usability and UX, discusses how they are related, and then examines their importance for today’s mobile applications.

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.

On large enterprise projects, the user acceptance test (UAT) is often envisioned to be a grand event where the users accept the software, money is paid, and the congratulations and champagne flow freely. UAT is expected to go well, even though some minor defects may be found. In reality, acceptance testing can be a very political and stressful activity that unfolds very differently than planned.

Many organizations are introducing test automation only to discover it is more difficult than they anticipated. The fact is that good test automation requires good coding practices. Good test automation requires good design. To do anything else will lead to spaghetti code that is hard to maintain or update. If you’re new to coding or new to automation, it is difficult to know where to begin. Join Cheezy as he describes and demonstrates lessons he has learned while helping numerous organizations adopt test automation.

With the increasing market demand for “always on” high performance applications, many organizations find that their traditional load testing programs have failed to keep pace with expectations and competitive pressures. Agile development practices and DevOps concepts of continuous delivery cause old load testing approaches to become unacceptable bottlenecks in the delivery process.

Know any testers who have bugs opened more than a year ago and still sitting in their defect queue? More than two years ago? Three? The fact is that many software development efforts are focused on delivering new features and functionality, leaving workarounds in place for bugs released in prior versions of applications. Often these defects seem relatively minor—we all have some workarounds for customers—but these are still bugs and ultimately should be dealt with.

In agile projects, when the cycle from ideas to production shortens from months to hours, each software development activity—including testing—is impacted. Reaching this level of agility in testing requires massive automation. But test execution is only one side of the coin. How do we design and maintain tests at the required speed and scale? Testing should start very early in the development process and be used as acceptance criteria by the project stakeholders.

Application performance is the first aspect of quality that every customer experiences. It can mean the difference between winning and losing a customer—between a 5-star app and a 2. No matter how sexy your application is, if it doesn’t load quickly, customers will turn to your competitor. Quality is core to agile, but agile doesn’t mention performance testing specifically. The challenge is that generally user stories don’t include the phrase “…in 3 seconds or less” and developers just focus on developing.

Studies show that at least half of all software defects are rooted in poor, ambiguous, or incomplete requirements. For decades, testing has complained about the lack of solid concrete requirements, claiming that this makes our task more difficult and in some instances—impossible. Lloyd Roden challenges these beliefs and explains why having detailed requirements can be at best damaging and at worst can even be harmful to both testing and the business.

Planning, designing, implementing, and tracking results for QA and test automation can be challenging. It is vital to ensure that any tools selected will work well with other application lifecycle tools, driving the adoption of automation across multiple project teams or departments, and communicating the quantitative and qualitative benefits to key stakeholders. Mike Sowers discusses his experiences creating an automation architecture, establishing tool deployment plans, and selecting and reporting tool metrics at a large financial institution.

Today’s test organizations often have sizable investments in test automation. Unfortunately, running and maintaining these test suites represents another sizable investment. All too often this hard work is abandoned and teams revert to a more costly, but familiar, manual approach. Jared Richardson says a more practical solution is to integrate test automation suites with continuous integration (CI). A CI system monitors your source code and compiles the system after every change. Once the build is complete, test suites are automatically run.

Are you frustrated by the false expectation that we can test quality into a product? By the time an application is delivered to testing, our ability to introduce quality principles is generally limited to defect detection. So how do you begin to shift your team’s perceptions into a true quality assurance organization? Susan Schanta shares her approach to Shift Quality Left by performing ambiguity reviews against requirements documents to reduce requirement defects at the beginning of the project.

DevOps is gaining popularity as a way to quickly and successfully deploy new software. With all the emphasis on deployment, software quality can sometimes be overlooked. In order to understand how DevOps and software testing mesh, Glenn Buckholz demonstrates a fully implemented continuous integration/continuous delivery (CI/CD) stack. After describing the internals of how CI/CD works, Glenn identifies the touch points in the stack that are important for testing organizations.

Many companies develop strong software development practices that include ongoing testing throughout the development lifecycle but fail to account for the testing of security-related use cases. This leads to security controls being tacked on to an application just before it goes to production. With security controls implemented in this manner, more security vulnerabilities will be found with less time to correct them.