Archives
Sapient Testers of India!
Submitted by James Bach on Tue, 24/11/2009 - 01:28.There’s something important going on in India. It’s called Weekend Testers. It seems to be the beginning of a truly Indian version of the Context-Driven School of Testing. It’s a sapient testing insurgency!If you are a tester in India (or you aspire to be) and you want to be a GOOD tester, then you should [...]
2010 Test Management Summit - 26/27 January 2010
Submitted by Paul Gerrard on Tue, 24/11/2009 - 10:10.REGISTRATION FOR WORKSHOPS (26TH) IS CLOSED | |
| WORKSHOP PROGRAMME (Word) | SUMMIT PROGRAMME (Word) |
| WORKSHOP PROGRAMME (PDF) | SUMMIT PROGRAMME (PDF) |
| The FOURTH TEST MANAGEMENT SUMMIT will take place on Tuesday 26th and Wednesday 27th January 2010. |
Our Generous Sponsors are:Original Software and SQS UK, Microsoft UK, Facilita and nFocus |
Why Is Testing Taking So Long? (Part 1)
Submitted by michael.a.bolton@gmail.com (Michael Bolton http://www.developsense.com) on Tue, 24/11/2009 - 21:55.If you're a tester, you've probably been asked, "Why is testing taking so long?" Maybe you've had a ready answer; maybe you haven't. Here's a model that might help you deal with the kind of manager who asks such questions.
Let's suppose that we divide our day of testing into three sessions, each session being, on average, 90 minutes of chartered, uninterrupted testing time. That's four and a half hours of testing, which seems reasonable in an eight-hour day interrupted by meetings, planning sessions, working with programmers, debriefings, training, email, conversations, administrivia of various kinds, lunch time, and breaks.
The reason that we're testing is that we want to obtain coverage; that is, we want to ask and answer questions about the product and its elements to the greatest extent that we can. Asking and answering questions is the process of test design and execution. So let's further assume that we break each session into average two-minute micro-sessions, in which we perform some test activity that's focused on a particular testing question, or on evaluating a particular feature. That means in a 90-minute session, we can theoretically perform 45 of these little micro-sessions, which for the sake of brevity we'll informally call "tests". Of course life doesn't really work this way; a test idea might a couple of seconds to implement, or it might take all day. But I'm modeling here, making this rather gross simplification to clarify a more complex set of dynamics. (Note that if you'd like to take a really impoverished view of what happens in skilled testing, you could say that a "test case" takes two minutes. But I leave it to my colleague James Bach to explain why you should reject the concept of test cases.)
Let's further suppose that we'll find problems every now and again, which means that we have to do bug investigation and reporting. This is valuable work for the development team, but it takes time that interrupts test design and execution—the stuff that yields test coverage. Let's say that, for each bug that we find, we must spend an extra eight minutes investigating it and preparing a report. Again, this is a pretty dramatic simplification. Investigating a bug might take all day, and preparing a good report could take time on the order of hours. Some bugs (think typos and spelling errors in the UI) leap out at us and don't call for much investigation, so they'll take less than eight minutes. Even though eight minutes is probably a dramatic underestimate for investigation and reporting, let's go with that. So a test activity that doesn't find a problem costs us two minutes, and a test activity that does find a problem takes ten minutes.
Now, let's imagine one more thing: we have perfect testing prowess; that if there's a problem in an area that we're testing, we'll find it, and that we'll never enter a bogus report, either. Yes, this is a thought experiment.
One day we come into work, and we're given three modules to test.
The morning session is taken up with Module A, from Development Team A. These people are amazing, hyper-competent. They use test-first programming, and test-driven design. They work closely with us, the testers, to design challenging unit checks, scriptable interfaces, and log files. They use pair programming, and they review and critique each other's work in an egoless way. They refactor mercilessly, and run suites of automated checks before checking in code. They brush their teeth and floss after every meal; they're wonderful. We test their work diligently, but it's really a formality because they've been testing and we've been helping them test all along. In our 90-minute testing session, we don't find any problems. That means that we've performed 45 micro-sessions, and have therefore obtained 45 units of test coverage.
Let's suppose that we divide our day of testing into three sessions, each session being, on average, 90 minutes of chartered, uninterrupted testing time. That's four and a half hours of testing, which seems reasonable in an eight-hour day interrupted by meetings, planning sessions, working with programmers, debriefings, training, email, conversations, administrivia of various kinds, lunch time, and breaks.
The reason that we're testing is that we want to obtain coverage; that is, we want to ask and answer questions about the product and its elements to the greatest extent that we can. Asking and answering questions is the process of test design and execution. So let's further assume that we break each session into average two-minute micro-sessions, in which we perform some test activity that's focused on a particular testing question, or on evaluating a particular feature. That means in a 90-minute session, we can theoretically perform 45 of these little micro-sessions, which for the sake of brevity we'll informally call "tests". Of course life doesn't really work this way; a test idea might a couple of seconds to implement, or it might take all day. But I'm modeling here, making this rather gross simplification to clarify a more complex set of dynamics. (Note that if you'd like to take a really impoverished view of what happens in skilled testing, you could say that a "test case" takes two minutes. But I leave it to my colleague James Bach to explain why you should reject the concept of test cases.)
Let's further suppose that we'll find problems every now and again, which means that we have to do bug investigation and reporting. This is valuable work for the development team, but it takes time that interrupts test design and execution—the stuff that yields test coverage. Let's say that, for each bug that we find, we must spend an extra eight minutes investigating it and preparing a report. Again, this is a pretty dramatic simplification. Investigating a bug might take all day, and preparing a good report could take time on the order of hours. Some bugs (think typos and spelling errors in the UI) leap out at us and don't call for much investigation, so they'll take less than eight minutes. Even though eight minutes is probably a dramatic underestimate for investigation and reporting, let's go with that. So a test activity that doesn't find a problem costs us two minutes, and a test activity that does find a problem takes ten minutes.
Now, let's imagine one more thing: we have perfect testing prowess; that if there's a problem in an area that we're testing, we'll find it, and that we'll never enter a bogus report, either. Yes, this is a thought experiment.
One day we come into work, and we're given three modules to test.
The morning session is taken up with Module A, from Development Team A. These people are amazing, hyper-competent. They use test-first programming, and test-driven design. They work closely with us, the testers, to design challenging unit checks, scriptable interfaces, and log files. They use pair programming, and they review and critique each other's work in an egoless way. They refactor mercilessly, and run suites of automated checks before checking in code. They brush their teeth and floss after every meal; they're wonderful. We test their work diligently, but it's really a formality because they've been testing and we've been helping them test all along. In our 90-minute testing session, we don't find any problems. That means that we've performed 45 micro-sessions, and have therefore obtained 45 units of test coverage.
| Module | Bug Investigation and Reporting (time spent on tests that find bugs) | Test Design and Execution (time spent on tests that don't find bugs) | Total Tests |
| A | 0 minutes (no bugs found) | 90 minutes (45 tests) | 45 |