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.
There is a saying about how to make software: First you make it work; then you make it good; then you make it fast. If you have working test automation, and if your test automation is finding bugs, then the next step is to make your tests run fast. This article talks about handling two things you will need to address to make that happen: users and processes.
Structure marking is a programming technique that defends data against damage, especially from software bugs. It adds flags to data structures and checks them at each use to detect damaged data immediately.
Testers are always facing a time crunch. As part of a recent assessment, a senior manager asked, "How long should the testing really take? It takes our testers from four, five, six, to thirty (insert your number of choice here) weeks, and we need it to take less time. Why can't it take less time, and how can we tell what's going on so we know how much testing we need?" In this column, Johanna Rothman answers with a timeline. By estimating how many testing cycles will be needed, plus how long each will take, she can map out the entire testing process. From this viewpoint, she is able to pinpoint where the process can be streamlined thus reducing the time spent testing.
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.
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!
Recently I overheard a conversation between a test analyst and a business analyst about how a function should be tested. The response from the business analyst was, "If it is not breaking the application, it must be working fine!" Testing staff comes across such scenarios where a part or functionality of the application under test is not "testable." The tests they carry out are not conclusive enough to say that the functionality is working as specified. In this week's article, Ipsita Chatterjee defines testability and looks at the benefits of incorporating it in the products. Also discussed are simple ways to monitor the incorporation of this non-functional requirement in the software development life cycle and a few industry myths about testability.
Your test group has an abundance of data but what does it mean to developers, project managers, or senior managers? In this column, Johanna offers a solution for delivering information to all of your customers in one place, that will be as handy as your car's dashboard.
Powerful new development technologies such as model-based code generation will overwhelm test teams that continue to create tests by hand. It's time for testers to put their own productivity into a higher gear. Harry Robinson tells you all about it in this column.
The choice of the right test techniques is critical to achieving a good return on the test investment. Some tests happen before we can even run the software. Some tests involve analyzing the structure of the system, while others involve analyzing the system's behavior. Each technique can involve special skills and particular participants, and might appropriately entail the use of tools-or not.