How can Fresh tester estimate their tasks when a sprint starts?

Hello everyone,

I hope you all had a nice day.

I previously asked for advice on “Need Advice for a Fresher Manual Tester,” and I received many good suggestions. I really appreciate all of your support; it’s a great motivation for me at this time.

However, I’ve realized that as I start to research “Estimation Skills,” I’m still confused about it. I often wonder how much time I need to estimate a task accurately, and I’m unsure how long such a task will take to complete without underestimating it.

I still remember when I joined a project, and the sprint started; I made a significant mistake with my estimation, and my boss was not satisfied with that.

Can you provide some methods, resources, or anything I can refer to in order to improve this skill before I return to work?

4 Likes

Sorry, that’s a huge orange flag. Having a supervisor who doesn’t understand how estimations work and what their purpose is, how it takes time to calibrate each time not only a newcomer to the project but a newcomer to the field of competence arrives, on top of that one that’s so close to the project and short-tempered that they immediately feel the need to communicate their “dissatisfaction” is a baaaad sign.

Estimates rely on three pillars:

  1. One’s experience
  2. Relativity
  3. Purpose

You will not know how long things take if you haven’t already done them a hundred times. You will not be able to give an absolute estimate of a tasks’ complexity in some units like “minutes of required work”, but only a relative estimate of “this is bigger/smaller/roughly equal to this other task that I’ve estimated in the past”. The purpose of estimating work (in scrum at least) is to be able to roughly predict whether a change will be finished within 2 weeks or a month, not to hold engineers accountable and express dissatisfaction if estimate misses.

A cynical solution is to overestimate everything and surprise the boss with shorter execution time, so they get to express their satisfaction. :nauseated_face:

1 Like

On a more practical note, please give some more context. Do you work in a team? A dev team? Do you work in scrum? How are your tasks estimated? What is the measure you’re using? Is there a meeting for that where the team estimates tasks at the same time or are you supposed to do that individually?

1 Like

Thank you for your suggestion. Let me give you a brief description of the context. I work with a team that previously had no testers, and now I am the only tester here. We have a meeting called ‘Start Sprint’ every Friday after two weeks. During this meeting, everyone picks tasks and estimates them together. My tasks are not related to the developers on my team because I am assigned tasks that have not been implemented yet, while the developers are working on different tasks. I’m not sure if you understand what I’m saying, but the lack of a tester position in the company has led to confusion in the testing process.

Even if you are assigned certain tasks, surely there would be a plan that tells you which testable tasks would be ready from the devs within a given sprint.
Generally a tester would have a planning and a testing task. The idea being that while the dev team works on something, the testers plan their testing in parallel.
If they are assigning you tasks that are not related to anything that’ll be done by the devs in upcoming sprint(s) then there’s a problem with the sprint planning in itself.

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!

My tasks are not related to the developers on my team

There is an important sense in which your tasks are related to the developers on your team. Your tasks will depend on their actions, and their tasks will depend on your actions. Just because they’re separated on a whiteboard or something doesn’t make this not true. As a new tester it’s tempting to see existing processes as something that must be correct, but remember that you are the first tester they have ever seen and they know less than you do about it. There may be a better way to do things for the project, and to better help the developers. Remember to be seen to support these people, as you’ll have a much easier time when you’re valued by people you depend on.

If you’re the only tester then you will be the only one to advocate for changes to the testing process. It may be worth talking to your boss about responsibility. It could be better to think of testing as part of development, and share the estimates. Talk to the devs you work with about better helping them.

Consider your problems carefully, so that you can approach solving them properly. For example you will struggle to make estimates for functionality you have no access to. Perhaps you could work with developers to test as they build the product. Perhaps you could have access to early builds so you can get an idea of risks and complications, or give early feedback, or ask questions earlier in the process.

I am assigned tasks that have not been implemented yet

If you want to estimate stuff before you see it you may want to test against any designs you’ve seen. Get invited (or invite yourself) to design meetings, and review design documents. You’ll start to find that you have important questions to ask or needs to ask for. You can test a design document, looking for risks. The HTSM is a really good tool to help with this, allowing you to think more thoroughly about a product and make notes about what you might need to look at.

E.g. a new, upcoming feature might be a new search function to search a list of users. You will probably want to know if this is a third-party search function (therefore likely tested by someone else first) or if we’re going to write it. If we’re going to write it you might want to know what fields it searches against (first name, last name, etc). You might need a test database to set up your own test data. You might need access to a copy of the user database to see how users tend to be stored. You will likely ask, in a kind and understanding way, why we need a search function and what value it has to users, so that you can check that we build something that provides that value. You may want to ask about automation hooks in the program so you can inject data quickly. You may think about different kind of risks - SQL injection, for example, which is a useful thing to mention if nobody else thought of it.

Then the test ideas that might come to you during testing, like testing for empty string input, case sensitivity, error messages you may need and how to display and cancel them, pagination, how it behaves with huge data sets, if it needs to work with non-english characters, etc.

This does a few things. It puts your ideas in the heads of developers so they make programs without these bugs in it so the bugs never even reach your later testing (you can share your test and risk ideas with them digitally to help them guide their development, if they’re willing), and it allows you to better guess how long it’d take you to test the functionality to your own satisfaction. It also exposes how complicated testing a simple-sounding thing is to the people you work with.

If you are not sure of estimating a task it is usually okay just to say you don’t know. If that’s valid, e.g. because you’ve never worked on anything like this at your company, or you don’t have the required skills then that will be accepted and other team members will help to get you in a place where you are comfortable with estimating. If it’s because the requirements are not detailed enough, then it’s good to point that out, and come back to them when the detail has been added. Also, consider learning estimating skills.