Better Software Magazine Articles
 |
Reloadable Test Data-O-Matic Reloadable test data takes more time up front (as compared to on-the-fly data creation), but saves blood, sweat, and tears in the long term. It also virtually eliminates "works on my machine" bugs, creates a more intricate and realistic environment, and is the first step on the road to test automation. |
Tanya Dumaresq
February 26, 2009 |
|
Lucky and Smart Charles Darwin was certainly a great scientist, but his career and his discoveries were also strongly influenced by serendipity and luck. What could this great explorer and scientist teach us about testing? |
||
|
Lessons Learned in Close Quarters Combat Few would think that the tactics employed by military and law-enforcement Special Forces to breach buildings under siege bears any relation to software project teams. After a number of weekends training with ex-military and ex-law-enforcement Special Forces—just for fun—Antony Marcano draws a surprising parallel between the dynamics of modern Special Forces "room-clearing" methods and the dynamics of modern software development teams. |
||
|
Cover or Discover? Excellent testing isn't just about covering the "map"–it's also about exploring the territory, which is the process by which we discover things that the map doesn't cover. |
||
|
It's in the Way That You Use It Rapid testers don't think of test automation merely as something that controls a program and checks for some expected result. Instead, we think of test automation as any use of tools to support testing. With that definition in mind, it may not be the most obvious automation tool that is the most useful. |
||
|
Out of the Rut Are you bored? Do feel as if all you do is repeat heavily scripted tests and as a result you aren't learning, discovering new problems, or finding bugs? These nine heuristics can help you get out of your rut and take back control of your testing process. |
||
|
Learning the Hardware Lessons Systems and software aren't just about correctness; they are also about solving problems for people. According to the context-driven software testing movement, a problem isn't solved if the product doesn't work. Michael's experience in a hardware store drives that lesson home. |
||
|
Is There a Problem Here? Suppose you were testing an application that you had never seen before with no time to prepare, no specification, no documentation, no reference programs, no prepared test cases, no test plan, and no other person to talk to. How do you know that what you are seeing is a bug? |
||
|
What Counts? In the testing business, we are infected with counting disease–we count test cases, requirements, lines of code, and bugs. But all this counting is an endemic means of deception in the testing business. How do we know what numbers are truly meaningful? |
||
|
Rock, Paper, Scissors: How Testers Uncover Hidden Requirements The requirements process is not a linear one. In this article, Michael Bolton helps you get in the game by showing how the elements of the requirements process–reference, inference, and conference–interact and influence each other. |
Pages
Recommended Web Seminars
Featured Resources
Visit Our Other Communities
CMCrossroads is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.