developsense.com developsense.com

Breaking the Test Case Addiction (Part 1)

Recently, during a coaching session, a tester was wrestling with something that was a mystery to her. She asked: Why do some tech leaders (for example, CTOs, development managers, test managers, and test leads) jump straight to test cases when they want to provide traceability, share testing efforts with stakeholders, and share feature knowledge with testers? I’m not sure. I fear that most of the time, fixation on test cases is...

developsense.com developsense.com

On Red

What actually happens when a check returns a “red” result? Some people might reflexively say “Easy: we get a red; we fix the bug.” Yet that statement is too simplistic, concealing a good deal of what really goes on. The other day, James Bach and I transpected on the process. Although it’s not the same in every case, we think that for responsible testers, the process actually goes something more like this: First, we ask,...

developsense.com developsense.com

Very Short Blog Posts (28): Users vs. Use Cases

As a tester, you’ve probably seen use cases, and they’ve probably informed some of the choices you make about how to test your product or service. (Maybe you’ve based test cases on use cases. I don’t find test cases a very helpful way of framing testing work, but that’s a topic for another post—or for further reading; see page 31. But I digress.) Have you ever noticed that people represented in use cases are kind of…...

developsense.com developsense.com

Oracles Are About Problems, Not Correctness

As James Bach and I have have been refining our ideas of testing, we’ve been refining our ideas about oracles. In a recent post, I referred to this passage: Program testing involves the execution of a program over sample test data followed by analysis of the output. Different kinds of test output can be generated. It may consist of final values of program output variables or of intermediate traces of selected variables. It may also...

developsense.com developsense.com

Very Short Blog Posts (25): Testers Don’t Break the Software

Plenty of testers claim that they break the software. They don’t really do that, of course. Software doesn’t break; it simply does what it has been designed and coded to do, for better or for worse. Testers investigate systems, looking at what the system does; discovering and reporting on where and how the software is broken; identifying when the system will fail under load or stress. It might be a good idea to consider the...