Don’t test the reused code tested previously – you will have more time to test new code. This heuristic for a black-box tester is basically all the idea of this blog – one I was creating for a week … I started this as blog about techniques, but wanted to be clear about grey box. A research on the term ended quite a long story below. If you don’t care about it – scroll down to the last chapter describing the techniques.

When I’m teaching new testers I use (specific chapters from) Black Box Software Testing course by Cem Kaner and James Bach. Those are great materials. However there are some topics not covered to an extent that I would like to (probably because of the specific of software we are creating in our company). For instance multi-edit heuristic and environment-specific handling tests. Maybe those topics are more in grey-box than in black-box, but for sure they are not the only topics of grey-box...

If you live in a small country like me, you may or may not need to travel too far to get to testing conference. There is an annual Latvia test conference and I know numerous conferences in Sweden. Although I don’t like to go to conferences too much, I try to learn about them and their content as much as possible. Here I share what I know about my region conferences and hope to learn more from you.

Once upon a time I cared about tester certification. I’m tired to be. There is but one lesson I learned - just as scripted and exploratory testing are two extremes of all the possible testing approach, there process-oriented and people(skill)-oriented test management styles. And it does matter which one your manager is… I don’t like to work with process-oriented managers – this is something to remember when new opportunities will appear either within my own organization or outside.

I’ve seen testers recommending The Art of War or Weinberg books which are not about testing at all. I’ve also seen performance testers recommending knowledge of probability theory, statistics and modeling principles. I don’t apply this knowledge in performance testing myself – well at least not directly. I never think about things like distribution function, mean deviation, etc. Do you? Don’t I ?!

This morning I realized that last Friday I did something that seems very simple to me, but may not be for young people not used to DOC (or at least windows95). I run a bat file test.bat containing following lines:

:loop
copy test\*.* import\*.*
sleep 600
goto loop

The same documents get copied into import directory each 10 minutes (600 seconds=10minutes). I was testing server who is able to pick up files incoming into this folder. It is quite typical to have such services to automatically process faxed documents and email attachments. But you could replace copy command with your process execution call or anything.

I never used mnemonics. Never say never... Here is my own mnemonic. Double RANDOM stands for ReadRights AalternativeAccess, NoNetwork, DesynchronyzedData, OutOf(whatever resource), MinMax(installation). Depending on context (e.g. reliability requirements, etc.) I spend more or less time trying to emulate system states unexpected by developer and thus unhandled by code.

Recently I’ve found my (sever years old) presentations with a lot of defect metrics and analysis. Only one slide I am proud of still – the percentage of “cancelled” bugs (drilled-down to percentage of reject reason: duplicated, not repeatable, etc.). What I like about this measure that it is direct – I’m really interested to keep the number of rejected bugs low – yes I’m interested in testers not reporting them in the first place.