A reader sent me email with this question: “We have a group of four people (3 developers and a tester). We work on 4 products, releasing one about once a month (each product is released once a quarter). The developers are devoted to one product when they’re developing, but have to fix problems immediately if […]
© 2005 Johanna Rothman. This column was originally published on Stickyminds.com Partway through an assessment, the senior manager asked me, “How long should the testing take?” The answer to the senior manager’s question is, “It depends.” If you do test-driven development, there is rarely more than an iteration’s worth of at-the-end testing. When I coach
I’m reviewing my students’ updated plans for their projects. One team originally wanted full unit testing on the code as it was created, but added (my paraphrase) “if the project is late, some unit testing will be acceptable.” I responded that the farther behind the project was, the more review and testing is required.
When I do assessments, invariably someone says to me, “JR, how long should the testing really take? It takes our testers (4/5/6/30 insert your number of choice here) weeks, and we need it to take less time. Why can’t it take less time and how can we tell what’s going on so we know
Take a look at these links: Tricks of the Trade, thanks to Dave Liebriech. When I was a tester, I read the code (this tip is far down on the list.) I’m not sure the developers appreciated my questions, but if I didn’t understand something, I asked. Here’s a tip I learned for people
Imagine you’re a fly on the wall in a readiness review meeting—a meeting of the project and senior managers to see if the product is ready to release. Senior manager: “Where are we with the testing?” Test manager: “Oh, here’s the defect data and the test data and…” Senior manager: “No, tell me where we
In the last few weeks, several people have asked me how much rework is normal. Well, if you’re working in a test-driven development environment, you probably have very little rework. My estimates for the few real test-driven projects I’ve seen is that they spend about 10-15% of their time on rework (finding problems and
I’ve been at the STAR conference this week, and Cem Kaner’s keynote talk yesterday discussed the idea of extended random regression testing — take all your programmatic tests, and run them in random sequences for a long time. You’ll find defects you cannot find just running the tests by themselves. Here’s the logic behind this
I’m sure you’ve heard conversations like this: Senior Manager: “Candace, I know you said you needed twelve weeks to test this release, but we’re really in a jam. I need you to release sooner. What can you do for me in six weeks?” As much as you might like to say, “Um, not much,” that’s
In this issue of Better Software, I have the featured article, No More Second Class Testers! and Frank Patrick has a great article, “Promises and Prescriptions, How the Theory of Constraints can help cure common project ailments.” I can’t give you a URL to Frank’s article, but maybe in a month or so he’ll