If performance is crucial for product success, you probably need pretty advanced tools to measure various aspects of your product, to find all bottlenecks and time thiefs. For all other software, performance is just very important, and you might get by with lightweight test methods. You may, or may not have quantified performance requirements, but […]
The Tester’s Pocketbook by Paul Gerrard is not a great book, but it is very good. It covers fundamentals of software testing, and contains a ton of good ideas that will help you in your testing effort. I also like it because it is one of few books on testing theory that focus on the […]
If you want to seriously improve your bug reporting skills, read up, or take, the BBST Bug Advocacy course. If you want to start by improving bug report title/subject/summary; read Lessons Learned in Software Testing, no, 83, or this blog post. Many people will only read the title, so it is important to make it […]
While sifting and sorting the ISTQB Glossary 2.1 I finally found a couple of terms which definitions were both correct and useful: 1. deliverable – Any (work) product that must be delivered to someone other than the (work) product’s author. Good, because it puts focus on the fact that you are creating the deliverable so it […]
Henrik Emilsson has convinced me that skilled software testing is based on invisible mental models that help us see what can be tested. If we can make these visible, we can sharpen our skills, and also teach testing more effectively. Here follows a simple example I used in class, that shows that by switching between […]
Here are some small, free, nifty tools I use now and then: FreeMind – to model and communicate WinMerge – to diff or merge files or folders Process Hacker – to monitor resource usage Process Monitor – to monitor registry and disk activities InCtrl5 – for installation testing (what happended to Install Analyzer??) Fiddler/Wireshark – to see […]
I see humility as a very good virtue. It is something I have failed miserably at, partly because it is easy to think something is bad just because there are many problems. I think it’s a common fallacy for many ambitious testers – you are last in line, maybe with lower status, you want to […]
Status reporting of testing activities is extremely project-dependent. The needs of when and how and what will differ every time. Maybe that’s why there’s so little good writing about status communication; you have to make it up every time. Templates are out of the question, and I believe examples will mislead you as well. You’re […]
Generic test report: DateTime ID Author Time for writing report Time maintaining scripts for generating report Application Under Test Areas tested For each area: Blockers Testers Tester mood Tests planned Tests executed Tests passed Tests failed Tests remaining (untested+fail) Bugs found, per priority Old bugs status (priority, severity, tester, assignee, days active) Bug resolution aggregation […]
– I saw you tested “42”. How come you didn’t try “43”? – That’s obvious. It would be the same. No need to test something that would give the same result. – OK, so I guess you are familiar with equivalence partitioning? – Beg your pardon? It is quite often said that testers don’t know […]