Just recently, I found myself complaining for the lack of validations being done on a particular project’s email address fields. But on second thought, perhaps it just wasn’t obvious which were valid email addresses and which ones weren’t. Most of us would only know the format of an email to be email@example.com. During newbie training or whatever it is that passes as project training, we weren’t exactly trained to identify valid / invalid email addresses even though we encounter email address validation in almost all projects.
Similarly, there are other functionalities that we encounter in nearly all projects that we work on — login, logout, registration, activation, upload of file, saving of a file, etc. For these functionalities, we have routine test cases (mostly if not totally undocumented) that we usually try out. In the course of finding more bugs across several projects, our set of routine test cases grows. I reckon these reusable test cases ought to be kept and tracked in some sort of a test matrix (fancy way of saying list or table of test cases) as they can help you when you need to test/retest some similar function, and they’d be especially helpful to newbies who may not have tested such functions ever.
I suppose preparing these test matrices could be even made into an exercise for newbie training. For instance, we can ask them to identify what values they would try out for testing a field that accepts only integers. Afterwards, whatever one misses and another one finds can be shared among the trainees. Usually, it’s making mistakes and learning from them that etches better into memory.
Anyway, this might be something worth suggesting or looking into. It would be nice if this could be crowdsourced over the interwebs, or even among the testers in the office.
There’s in an email thread in our office discussing a problem with the unit test plans of our newbie testers. Our senior tester raised that the newbies’ test plans seem to have been directly ported from the functional specs. That didn’t sound good. There’s a saying that the devil is in the details. And our functional specs usually just offered the high-level, logical design. If they had indeed simply transcribed the fspecs into test cases, then they might be missing critical test cases. Another problem raised was that the stringent standards compromise the efficiency of the test plan preparation. Now, with the level of details they are putting into the test plan, I worry whether they’ll actually use those plans during test execution.
I reckon that just as we try to make our programs usable, we should also do the same for our test plans. We must recall that the test plan is a tool, a guide. It should help us testers rather than inhibit us from doing out jobs efficiently. On the other hand, we also have to consider that sometimes the test plan is a deliverable. But for what exactly do the users want the unit test plans for? Knowing this would help us determine the level of details that we put into the test plans. There’s got to be some ground in between wherein we satisfy user requirements AND still manage to come up with a more maintainable, more usable, more efficient test documentation. Not finding that common ground can only be wasteful. Now if only I knew how. =/
The Triangle Test is considered as a classic exercise for devising test cases. This was devised by Glenford Myers whose name should be vaguely familiar to the testers. His name pops up at least once in the tester training material, but he is more known for authoring “The Art of Software Testing.”
Anyway, in this exercise, you are supposed to test a very simple program.
The program reads three integer values from an input dialog. The three values represent the lengths of the sides of a triangle. The program displays a message that states whether the triangle is scalene (no equal sides), isosceles (two equal sides), or equilateral (three equal sides).
So try out listing your test cases. Give it about 30 minutes to an hour.
I found this old article while I was googling / wikipedia-ing. Although much of the items listed are already covered in our standard test cases [at company name], this article can just serve as a reminder.