Learning
Everyone makes mistakes in estimation. Software projects are unpredictable, and testing even more so.
As you learn about new important risks that will take more of your time than you thought it would. Same if a product is more buggy than you thought, or more complex than you predicted.
I think the best thing to improve is to continue learning the product. The more you learn the more you understand how long things will take.
Intake & Recon
One way to help estimation is to run what I call an intake session and recon session before you make an estimate. When Iâm testing something new I tend to do it in stages (where appropriate); intake, recon, capability, then deeper testing.
Intake is where you come to understand the mission of your work, look at the scope of it, ask any important questions that you have.
Recon is where I explore the product, and note down anything that stands out. You are not testing to find problems, you are testing to learn the product - make the product look as good and capable as you can by just walking through it in the most obvious ways. As you go, look for risks like complexity, well connected functionality that depends on other functionality (or is depended on by other functionality), things with precise and exacting requirements, things that appear to have a lot of bugs, things you struggle to understand so will need time to learn, and so on. These risks are where youâre likely to want to spend time testing. All of this will help you to learn what testing something is going to be like, and therefore where you might need more time.
100%
Also donât attempt to be âcompleteâ. You will not cover everything. Testing is an infinite performance that you could, in theory, perform forever, even on the simplest of programs. Real testing is about sampling - trying to get a few, varied approaches and techniques applied, and looking to test against risks that are important to people. You can note down testing that you havenât done, and even report on it so that your test clients also understand whatâs not done. Perhaps it doesnât need to be done, or can be done later. You can evaluate that, which will get easier as you learn whatâs important.
Communication
Another thing to talk about is making promises. When you make an estimate all you can do is make a good-faith promise to do your best. You can talk with a boss about why you felt the need to go over-estimate. You can update a boss if you think youâre about to go significantly over estimate. You can discuss with a boss whether or not they want you to put in the effort to test a particular risk or if they think the money and time are better spent elsewhere. Either that boss will love you because youâre on board and easy to manage and they feel informed, or they will ignore you and stop bothering you because youâre forcing them to manage the project when they donât want to. They canât be dissatisfied if they were informed of the issues and risks and had to make decisions about test effort on their project.
Ask your boss what theyâd like. Why are they disassisfied? What upset them? Why do they need the estimates? Is your test schedule more restricted than you thought? Is the schedule tight right now? Are they just annoyed at the surprise, and need more hand holding? Perhaps you need to negotiate with what you can achieve vs the time you have. Each human is different and, like it or not, your job will involve working with them. Having a positive working relationship where you show a willingness to support your test clients is invaluable.
You could also mention that you are new to the project, and are still working out the areas of high risk, what techniques and tools are best, where the complex areas are, and that will reduce the accuracy of your estimates. You could work with your boss to see what would make them feel more comfortable, and what level of risk they are comfortable with. One way to make software more testable is to care less about the quality of it - if it doesnât have to be good then we donât have to test it that much.
Communication to you is also important. What are the changes that are coming up? When is the product available for test?
Where you spend your time
Itâs worth thinking about what things in testing cause delays, so that you can communicate them better. You spend your time doing three things: testing something, supporting testing something and not testing something.
Testing something is where you are designing experiments, exploring and learning.
Supporting testing something is where you are writing notes, filling in documents, exploring and reporting a bug, setting up your product/environment/platform, getting replies to related questions, writing reports and so on.
Not testing is where you are taking a break, talking about unrelated things, waiting for a new product version, going to unconnected meetings, getting interrupted by people about other things, and so on. Interestingly, not testing something is also where you are testing something else. Sometimes you will find a new risk or area of a product or something that distracts you and you might go off on a tangent. That tangent may be important, but also might be something to do later rather than now. You can note it down as possible future testing.
From this you can see where your time is spent. You could even write down the time you spend on subject vs off subject, and the on-subject time broken down into setup time, testing time and bug investigation/reporting time. This is based on the metrics from session-based test management. However, as noted in that very article, this is a lot of admin work that will also take time away from your testing, so weigh that against the value of it.
Finally
You will build this over time. If your boss feels that bothered, try to discuss with them how to solve problems in the future. Offer to communicate updates to estimations, or discuss your findings in more detail. You can report on the product, how you tested it, the problems with testing it (risks, costs, blockers, needs, recommendations), and why youâre confident about all that.
Donât be discouraged by bad feedback. Itâs less about your ability to estimate and more about your bossâs feelings, which you can talk about with them. Itâs reasonable for someone new to say theyâre still learning how long things will take for a particular project, and good for them to say theyâll work with management to improve this and better communicate. You will also improve your estimating, even if you donât try, simply by being exposed to how long your process typically takes. Then, as you improve your processes you can get even more testing done for your time.
Best of luck!