One of the biggest challenges when you are testing alone is making realistic estimations when it comes to testing and testing related deliverables. I've been bitten by this many times over the years, sometimes greatly overestimating how much time something will take. More often, though, it's the underestimation that's the real killer.
I keep asking myself why I feel that I so regularly underestimate the time it takes to do certain tasks, and really, there are two answers. The first is that my natural enthusiasm tends to buoy me and make me feel really aggressive in my predictions. That's not necessarily a bad thing; enthusiasm can help drive a lot of initiatives and be a great tool for focus and clarity of purpose. The problem tends to be compounded by the fact that life rarely works exactly as we plan. We get distracted. People come into our work areas and ask questions. We want to be helpful and contribute to the team. All of these things take a bite out of our schedules, and if we have not adequately planned for them, they will bite into our testing time, and we will not be working at our peak ability and efficiency.
So for my friends out there who don't really have anyone else to help balance out their estimations, here's a few things that you may find helpful...
Five Hours == One Day: Seriously, commit to this, and you will become much better at making your estimates be realistic and improve your chances of being on target. Five hours means just that; the most focused, directed, in the zone time you will be able to get and sustain in any give work day is about five hours, and that's at the outside edge. Many days, it will be less. Why? Think about the commitments you have during the day. Do you read email? Write test plans? Need to create reports? Have a test script that needs to be modified? Have a meeting you need to attend? Have phone calls to return? Have a chapter in a book you'd like to finish so you understand that new testing technique you've heard about? Every one of these things is valuable and important in its own sphere... but every single one of these robs you from your main focus, which is testing.
Even if you manage to completely minimize or avoid every one of these distractions, you will still only be really fresh and effective for those five hours. Beyond that, fatigue sets in, and then mistakes get made. Yes, even us testers make mistakes. So resist the urge to push much beyond the five hour rule.
Beware Perpetual Overtime: This can be a way of life in a lot of organizations. I understand it, and I have lived through it many times myself. There is, of course, Crunch Time, when the end of a cycle and a solid push is needed to get over the hump. Just about every project deals with that in some way or another. What I'm referring to is the perpetual 11 hour days, every day, for weeks or months on end. Some believe that this is a way to get the maximum test coverage in a short period of time. It's true, tests are performed, and a lot of hours of testing are logged, but is that testing high quality testing, or is it people going through the motions because they are exhausted, burnt out and totally dragging along? To Army of One testers, I ask you NOT to buy into this mode of thinking. Be willing to stand up and say "This is not effective! I cannot do my best work under these circumstances!" It'll take some discipline and some willingness to deal with blow-back, but you will be grateful you took the stand early. Your management will also be grateful when they come to see that the long term quality is better because you are fresh and focused rather than tired and listless.
Use Your Development Resources: Be willing to sit with the developers and ask them "how long does it take you to code these modules? What are some of the things you are considering for testing these?" No, you are not asking the developers to do your work, but you are asking for their insights and their impression of what the product will ultimately do. Armed with this information, you can make better estimates as to how long it will take to accomplish certain tasks.
Know That You Can't Test Everything: Without blowing it for anyone who hasn't taken the Foundations Course offered by the Association for Software Testing, there's a module called "The Impossibility of Complete Testing". Heresy, you say? Nope, absolute truth. In fact, within some simple programs, those that have nested for loops for example, there are more test cases than can be completed by a tester working night and day for a century. You will not be able to test everything exhaustively. You will be lucky to get 10% of all possible avenues an application could branch. Still, if that 10% is the 95% the customer most cares about, then make that 10% count! Put everything you've got into it, test as thoroughly and with as much focus as you can, but at the end of the day realize that you will never get all testing done. Getting the most important testing done to a "pretty good" level is way better than most software will ever be tested. Don't be a defeatist about it, but realize this going in.
Test estimation is a challenge for everyone, whether you have a team of many, or an Army of One. It's difficult at times, but with repeated effort and practice, you will get better at it. Just make sure to remind yourself not to over-promise, because nothing feels worse following such a promise than under-delivering.
No comments:
Post a Comment