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.
Lisa Crispin explains in this article how CI has become an absolute necessity for any software development team in this day and age. For those who have yet to fully embrace CI, this article gives you some great reasons you should, along with some helpful resources to get you started.
There are two distinct roles in many software projects that are involved with testing: developers and testers. Should they take the same approach to testing, or are there some principles that apply to only one of the roles? What should they do to coordinate their work? Danny Faught went through an exercise to compare and contrast and found that the questions he couldn't answer were as interesting as the questions he could answers.
As a test professional in waterfall, I was used to getting the code much later and buggier than I expected and being under tremendous pressure to finish my testing before the go-live date hit. Then one day, I found out that there was a better way. Testers could be involved much earlier in the lifecycle, they could participate in requirements and design decisions as they happened, and the code could actually be unit tested before I received it! Heaven? Nope, agile.
Exploratory testing—questioning and learning about the product as you design and execute tests rather than slavishly following predefined scripts—makes sense for many projects. But does it make sense for agile projects? In this column, Johanna Rothman examines how exploratory testing might work on an agile project.
One characteristic of agile development is continuous involvement from testers throughout the process. Testers have a hard and busy job. Jeff has finally starting to understand why testing in agile development is fundamentally different.
Staged integration versus continuous integration—which does your team prefer? Can't decide if one is better than the other? In this column, Johanna Rothman explains that you can create the perfect blend of the two. Developers and testers benefit from frequent builds, but be careful with how much you build. Build too much or too little and a project could topple.
Resumes only tell a portion of a candidate's story just like caller ID doesn't always reveal the caller's complete identity. Screening candidates over the phone can help extract more of the person's story if you ask the right questions. In this column, Johanna Rothman shares phone-screening techniques she uses to detect great potential testers. This process of elimination saves her valuable time and ensures only qualified candidates make it to the in-person interview.
If you think that test automation is mostly about executing tests, then you're missing out on a big opportunity. Or rather, you're missing a lot of small opportunities adding up to a big one. Consider this: stop thinking about test automation as merely executing automated tests, stop thinking about test automation as something you need expensive tools for, and start discovering automation you can implement in a couple of days and usually with extremely inexpensive tools or tools you already have available. In this week's column, Danny Faught and James Bach suggest taking a more Agile approach to test automation.