Links to 
Guest Book
Articles, Opinions and Comments

Criteria for Effective Testing

It’s a sad truth about testing software that it can be done on a very, very low level. While in software development you need some basic skills such as programming languages and logic to do your job, everybody who is able to push a mouse is also able to do some kind of poor testing, i.e. following step-by-step instructions outlined in a detailed test plan, which is based on some basic requirements. But isn’t testing more than filing tests cases, counting bugs, do some statistics and push a mouse? Won’t you need more than some unskilled testers and a manager who does the administration part? I think there is much more.. and I will try to define some – surely not all – criteria for good and professional testing.



The nineties of the previous millennium were the big time of Software Development Methodologies – and although now there’s more emphasis on small, fast and agile processes, the Methodologies are still alive. I suggest an unusual approach to review and assess Methodologies: why not write down a list of basic requirements? We (hopefully) agree on requirements for software to be developed and create more or less detailed specifications; why not doing the same for Methodologies or any other kind of ”silver bullet”? And because not only software is buggy, there’s no justification to believe that Methodologies are free of bugs as well – especially if you are a skeptical software tester.


The Ruins of Code Castle

How to make good, well-structured and (nearly) bug-free software has been known now for a long time: after collecting and analysing the customers requirements and transforming them into a comprehensive and crisp specification, you start system and component design (accompanied by detailed reviews), followed by an accurate coding and a nitpicking testing phase. But in real life this well-organized and tidy painting-by-numbers style of creating software is a nice fairy-tale, often some kind of fantasy and horror novel is a more appropriate metaphor: ...


About Software Quality Assurance

The following article - the eldest and longest one of this home page - reflects upon my experience while testing software in a “traditional” waterfall-like development environment - and it suggests a project- and team-based approach in order to create software in a more flexible and effective way. Although it’s the eldest part of this homepage and most ideas aren’t new from today’s point of few, I still like it..


Writing Test Cases

Reporting Bugs