Suffering for Success One of the most valuable services a QA group provides is preventing failure. Ironically if the group succeeds at this, QA might find themselves unpopular or out of a job. Linda Hayes reveals how typical methods of measuring success can actually cause failure. Especially if success is achieved at the loser's expense. |
||
Building an Independent Test Group Are you attempting to start an independent test group or increase the scope and value of your present group? After building a highly effective thirty-person test group, Scott Eder reflects on the three major areas where he focused and the challenges he faced along the way. Take away sample work scope and purpose statements for your test group, and learn how to set realistic expectations at all levels within your organization. Find out the key processes that Scott implemented immediately to get his team off to a good start.
|
Scott Eder
January 31, 2005 |
|
Detecting Great Testers before the In-Person Interview 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. |
||
TimeLine Postmortems We should use project postmortems to improve our software process. But few teams do, and fewer teams reliably learn from project postmortems. You can introduce postmortems to your team easily with a timeline postmortem process. If you are already doing postmortems, a timeline-based approach may improve your results.
|
Seth Morris
January 9, 2005 |
|
Not Your Father's Test Automation 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. |
||
Keeping Secrets Test data has long been a challenge for testing; privacy legislation, identify theft, and the continued trend towards outsourcing has made it even worse. Just establishing and maintaining a comprehensive test environment can take half or more of all testing time and effort. In this column, Linda Hayes adds in the new and expanding privacy laws that inevitably limit your testing options. Yet from the quagmire of laws and company standards, better testing can emerge. |
||
Bumper Stickers for Testers Why is software testing perceived as dull? How many other jobs can list "crash," "hang," and "death march" in their daily vocabularies? In this week's column, Harry Robinson encourages testers to embrace a little pride and excitement in what they do, and Harry has just the mottos for bumper stickers that announce Tester Pride. Author's note: Feel free to add your own favorite slogan in the comment section at the end! |
||
Thinking Inside the Box The problem with urging outside-the-box thinking is that many of us do a less-than-stellar job of thinking inside the box. We often fail to realize the options and opportunities that are blatantly visible inside the box that could dramatically improve our chances of success. In this column, Naomi Karten points out how we fall victim to familiar traps, such as doing things the same old (ineffective) way or discounting colleague and teammate ideas. Thinking outside of the box can generate innovative and ingenious ideas and outcomes, but the results will flop when teammates ignore the ideas inside the box. |
||
Talk Talk Talk Managers need to talk about goals, strategy, and mission. Managers need to talk about how daily work keeps the business humming. Esther writes about how important it is for managers to also ask questions and listen. |
||
Developing a Requirements Team Forming, Storming, Norming, and Performing. No, they are not a law firm, but the stages of team development proposed by Bruce Tuckman in 1965. I wish I had known about this model much earlier in my career. If you haven't encountered it before and want to help your requirements team, read on. |
Pages
Upcoming Events
Jun 02 |
AI Con USA Bridging Minds and Machines |
Sep 22 |
STARWEST Software Testing Conference in Anaheim & Online |
Oct 13 |
Agile + DevOps USA The Conference for Agile and DevOps Professionals |