While anyone who has automated her testing knows you can't create repeatable automated tests from unstable data, it did not dawn on this week's columnist—self-proclaimed automation lobbyist Linda Hayes—that this issue cripples manual testing as well. Read on to share her epiphany.
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.
We like to think that being late on one task isn't so bad because early and late completions will average out over the course of an entire project. If you flip a coin 1,000 times, it will land on heads about 500 times and on tails about 500 times. If your project has 1,000 tasks, about 500 will finish early and about 500 will finish late, right? Wrong--and many project plans are sunk by this common misperception.
Agile projects draw testers out of the background and into the spotlight. Testers play a distinctive role and drive product development by creating acceptance tests before any code is even written. Johanna Rothman sets the stage and explains the benefits of giving testers their chance to shine.
Software developers often view version management tools and techniques as a necessary evil. This is particularly true of developers practicing agile techniques. However, version management, can be an aid to agility rather than something that gets in the way.
With Extreme Programming, programmers are taking responsibility for writing their own unit tests. What work does this leave for testers? Some people think that XP saves costs by eliminating the need for testers. Does programmer testing really take the place of tester testing? In this column, Bret Pettichord offers ways for testers to provide value to XP teams.
A recent StickyMinds column criticized the new Agile development methods as bad for business. The column generated many reader comments, and prompted this response from industry veteran Cem Kaner. Read on for his defense of iterative approaches.
XP teams have the right to do their best work. On the other hand, customers have the right to specify and pay for only the quality they need. How does one reconcile two potentially conflicting points of view? Is quality negotiable? If so, how do we go about negotiating it? This paper will explore the following questions: Is quality negotiable? How can we negotiate quality? What are internal and external quality, and are either or both negotiable? What's the XP tester's quality assurance role? How far should testers go in helping the customer define acceptance criteria?
Is your organization doing Extreme Programming or one of the other agile methods? Are they considering it? Before you jump on the latest methodology bandwagon, you should make sure you're not just giving your developers a license to hack. Karl Wiegers provides some insight into how agile development models can be misused and how you can ensure that your process improvement effort has the best chance to be effective.