The first Agile Manifesto value is…
“Individuals and interactions over processes and tools”
While reading this recently, something radical occurred to me. If I practice said value to its fullest, I can stop worrying about how to document everything I test, and start relying on my own memory.
I hate writing test cases. But the best argument for them is to track what has been tested. If someone (or myself) asks me “Did you test x and y with z?”, a test case with an execution result seems like the best way to determine the answer. However, in practice, it is not usually the way I answer. The way I usually answer is based on my memory.
And that, my friends, is my breakthrough. Maybe it’s actually okay to depend on your memory to know what you have tested instead of a tool (e.g., Test Director). But no tester could ever remember all the details of prior test executions, right? True, but no tester could ever document all the details of prior test executions either, right? To tip the balance in favor of my memory being superior to my documentation skills, let me point out that my memory is free. It takes no extra time like documentation does. That means, instead of documenting test cases, I can be executing more test cases! And even if I did have all my test case executions documented, sometimes it is quicker to just execute the test on the fly than go hunt down the results of the previous run (quicker and more accurate).
It all seems so wonderful. Now if I can figure out how to use my memory for SOX compliancy... shucks.
Popular Posts
-
After attempting to use Microsoft Test Manager 2010 for an iteration, we quickly decided not to use it. Here is why. About 3 years ago we ...
-
I recently read about 15 resumes for tester positions on my team. None of them told us anything about how well the candidate can test. Her...
-
Data warehouse (DW) testing is a far cry from functional testing. As testers, we need to let the team know if the DW dimension, fact, and b...
-
The first time I saw James Whittaker was in 2004 at an IIST conference . He dazzled us with live demos of bugs that were found in public so...
-
Many testers have chosen to make their jobs stressful by taking on more responsibilities than they should, obscuring their skills with those...
Blog Archive
Labels
- Teamwork (70)
- bugs (54)
- process (52)
- software testing career (32)
- writing tests (27)
- questions (26)
- Managing Testing (19)
- automation (16)
- Tools (14)
- language (14)
- testing metaphor (11)
- STPCon (7)
- Test This (7)
- test blogs (7)
- CAST (6)
- heuristics (5)
- Don't Test It (4)
- STARwest (4)
- metrics (4)
- Data Warehouse Testing (3)
- Silliness (3)
- Stareast (3)
- Podcast (2)
- Kanban (1)
- Lightning Talks (1)
- Presentations (1)
- Testing Related Ideas (1)
Who am I?
- Eric Jacobson
- Atlanta, Georgia, United States
- My typical day: get up, hit the gym, listen to public radio, drink strong coffee, perform virgin software tests, break for lunch and a Euro-board game with the devs, log more bugs, walk the dogs, enjoy a meal with Melissa, an IPA, and a Netflix, look forward to a weekend with a cave trip or woodworking project.

RSS
Interesting post. All in all, you wouldn't want to remember all the test results for your tests in the last month, and have people call you up every time they need to know the results as well, would you? I'm sure you could put your memory to remember much more useful info and let the machines handle the obvious.
ido,
You're right. That is a huge flaw in my plan, my test data would not be public and I would have to waste my time answering questions.
The only thing I would have going for me is that in practice, people rarly ask what was tested. Usually, they judge my tester abilities by how well the software works. This is a good thing!