Is testing about checking against system requirements, or is it about exploring the software? In this article, Elisabeth Hendrickson explains a valuable truth often clouded by this debate—good testing takes advantage of both of these approaches.
Inspired by the success of India’s Weekend Testing movement, Michael Larsen saw a need for a group closer to home. The Weekend Testing Americas chapter invites testers from across the Western Hemisphere to join an informal, distributed group of their tester peers to learn and perfect their craft.
My team is in the middle of one of the hardest projects—we call them "themes"—we’ve ever tackled. We’re a high-functioning agile team that has helped our company grow and succeed over several years now—we “went agile” in 2003. Here’s one thing I know for sure: No matter how many problems you solve, new challenges will pop up.
Lisa Crispin dives into the "we're all in the same boat" theory and explains how it can't be more true in the software development world. From the need for common goals to going beyond taking responsibility for the team's actions, each team must know that you're going to fail or succeed together.
Your developers are already working feature-by-feature in iterations, but your testers are stuck with manual tests. How do you make the leap to agile testing when the nature of agile's iterative releases challenges testers to test working segments of a product instead of the complete package? In this column, Johanna Rothman explains that the key challenge resides in bringing the whole team together to work towards the completion of an iteration. Only then will the testers—and the entire team—know how to transition to agile.
For those who believe there has to be one right way to do something, especially in software development - there can be. But that one way isn't likely to come from a single individual. Through collaboration and teamwork, some of the greatest single ideas have evolved.
Testers who point out project risks are often perceived as "negative" thinkers. Software test consultant Fiona Charles (an optimist by nature and a pessimist by trade) writes about how a culture of unthinking optimism pervades our organizations and our society, and describes some of its detrimental effects on software projects.
Subject matter experts (SMEs) serve important roles on a project and are especially pivotal during the testing phase. In this week's column, Dion Johnson explores how SMEs positively and negatively affect testing and what you can do to make sure you have the right amount of SMEs on your testing team.
In this article, Lisa Crispin recalls a time when testers alone were solely responsible for software quality, and compares that to more modern thinking where collaboration between developers and testers is king. Software quality is everyone's job, sometimes it takes independence to get there.
Untruths about software testing are common. Managers, programmers, and other people on software projects don't always mean to deceive. Quite often, they fool themselves into believing what they want to believe. But sometimes they lie deliberately and even pressure testers to lie. And testers can also practice deceptions and self-deceptions of their own. In this column, Fiona Charles describes four categories of common deceptions and self-deceptions in testing and outlines what testers need to do to address them.