> What one programmer can do in one month, two programmers can do in two months - Fred Brooks

## Introduction

As per [Wikipedia](https://en.wikipedia.org/wiki/Estimation): “**Estimation** (or **estimating**) is the process of finding an estimate or approximation, which is a value that is usable for some process even if input data may be incomplete, uncertain or unstable.”

The estimation can be valuable and very useful when answering [two questions](https://www.guru99.com/an-expert-view-on-test-estimation.html) that a client or project member can have:

1. How long will it take this to be tested?
2. How much will it cost?

### What QA can estimate?

The most common things a member of the QA team can estimate are:

- **The whole project (testing part)** - QA as part of the development team can provide an estimation for each of the project phases where QA is or should be included. The estimation of the whole project can be done either as a ballpark estimation or later improved and better estimated with details for each phase.
- **Writing project test documentation (test plan/strategy/test cases)** - one of the biggest challenges for every QA team member is to have clear and understandable testing documentation. Since this testing action needs time to be completed, it’s always a good idea to consider estimation for this part.
- **User story/task** - software testers can and will provide estimation for tickets (user story/task) that they will work on. The task is the smallest piece of the project that a software tester can provide an estimation for.
- **Testing methods** - the testing on the project will most probably be conducted using different methods such as Regression testing, Smoke testing, Load testing, Exploratory testing, etc. Each of these testing techniques requires separate estimation, and it’s a good practice when they are planned to provide estimation for them. As time passes and the project evolves, the estimation of these testing techniques can be revisited, and a reestimation can be provided.
- **Writing automated tests** - another testing activity that can be estimated. To have a better and more precise estimation, the estimation of this portion of the testing can be done either by the Test Automation Engineer or by a more senior Lead Test Automation Engineer in the team.
- **People** - another vital part in the Software Testing Life Cycle that a QA (most likely experts like QA Leads and QA Managers) can and should estimate. To get what's best for the client and the project itself, the initial estimation of the number of the QA team members that will be part of the project is crucial. Later that number of people can be increased or decreased as the project and client demand.

These things are key factors and depend on each other to deliver quality software that will be useful and can be considered a benefit for users around the world.

Some authors, in theory, are adding one additional component that QA can estimate: the cost. But taking into consideration that we in Infinum have excellent managers, Leads, and Business Development teams, we will leave that part to them :).

## How to estimate?

It is never easy to provide an estimation. With experience, you can learn how to deal with it and provide more accurate estimation, but the moment when providing estimates can be very stressful. This section is meant to guide you through the whole process of estimation and how to make it easy for you and your team.

- When providing an estimation, even if that means ballpark estimation, as a QA team member, it is an excellent practice to be the last one to give the estimation. This means that you will have an overall view of the estimation of other teams, and that way, you will be able to do the easy math (for example, 20% of the dev’s estimation) to calculate the QA effort easier.
- Take the important things into consideration. The following things are crucial to come up with a precise number of hours you will need:
- Available working days (exclude the weekends and public holidays),
- Employees’ short or long leave (sick days, vacations),
- The available resources for the project (documentation from the client, people available to do the job).
- If you need to provide an estimate for a group of people (for example, for your team), consider their knowledge and experience level (seniority). Software testing is one of the most dynamic areas of IT, whether related to manual or automation testing. If you are not sure that anyone from the team has the experience and/or knowledge on the same or similar projects, you can always have a team meeting and discuss so you can provide a more accurate estimation. One final thing here is the change of the people in the team. If someone from the team leaves the team for any reason (starts to work on other projects, sick leave, etc.), a reestimation should occur accordingly. Again their knowledge and experience (the seniority level) should be considered when reestimation occurs.
- Project scope is probably one of the most important things to know and consider before making your final judgment related to the estimation. For example, suppose you know that this is only the MVP phase of the project, and the client requires only basic testing to be conducted and performed. In that case, you should not insist on adding a considerable number of points/hours in the QA estimation due to some “known and well-established QA practices”.
- Although the estimation process is one of the hardest things to do, please DO NOT waste too much time calculating and planning the estimate. In the next section (Tips & Tricks for better and improved estimation), you can find some valuable tips that can speed up this process.

## Tips & Tricks for better and improved estimation

Estimating is not an easy thing to do. Especially if you are dealing with some not-that-easy people and clients. However, the following tips should help you when it's your turn to provide an estimation:

- **Ask for advice** - we as a QA team care for each other, so you can ask anyone for advice. The more experienced colleagues will always be there to help you.
- **Think big - act properly** - consider the project's scope and focus on the critical things clients asked us to develop. As long as you know the mission, you will learn how and when you can deliver. Sometimes it is beneficial to break down the functionality into smaller pieces to provide a more accurate estimation.
- **Avoid giving estimates on the fly** - sometimes, clients can ask for an ad-hoc meeting or 1-on-1 call with you. On this call, they will probably shoot the requirements and ask you for an estimate. Even though it is good and maybe a plus for you, please avoid giving estimations on the fly. Try to ask politely for some time to think about the request. If the client insists on providing the estimate at that moment, ask questions and ask for available resources (for example, documentation related to the subject) so you can get as much information as possible.
- **Be realistic** - no one knows your abilities as you do. So, please be realistic when you provide an estimate on a task. One of the things that clients respect is how accurate you are with your estimation.
- **Add some buffer time** - it is always a good practice if you add some buffer time. Not always things are going as per plan. Sometimes you will need more time to test functionality or finish the regression so the buffer time can come in handy. Adding buffer time can "buy" you additional time. But again, as we previously mentioned: Be realistic!
- **The estimation is only yours** - it is nice to know the project's scope and the people that will be part of the project, but when it comes to estimation, know that the estimation is only yours. If it is not otherwise required and stated before, you will provide an estimate only for your part of the work. Whether you are a manual or automation software tester, you need to focus only on estimating the amount of work. That way, you will let others know how long it will take you to (re)test a ticket, find valid test data, perform regression, etc.
- **"Shoot" the questions and doubts in time** - if you have any questions or doubts, ask them at the right time. If you do not know or are unsure who to ask, a good practice is to bring the question you have to the next Daily meeting. Never leave the questions for later. They will not have the same meaning as if you asked in time, or worse, you will forget them.
- **Plan the future** - planning your vacation or any other life event is a good practice if you plan the future sprint. Take a look at the tickets that will be part of the next sprint and see if you have any questions regarding them so you can set them on a table at the right time.
- **Rely on the past** - when using your knowledge on a project, try to incorporate the experience you gain throughout the current project.
- **Reestimate if needed** - try to stick to your estimation as much as possible. In the early phases (first few sprints), mistakes in estimates could occur frequently. So make sure to revisit your estimate and, if possible and needed, re-estimate. On the other hand, if there are significant changes in the requirements and you already provided an estimation, bring this to your team lead and make sure to negotiate the reestimation with the client. Additionally, a reestimation should occur if someone is changed and replaced by other QA team members (for example, switching to other projects, sick leave, etc.)

## Popular estimation techniques and methods

When it comes to methods and techniques that can be useful in the process of estimation, there are quite a large number of them. For some of them, some authors published books. However, in this section, we will mention and explain some of the most popular estimation techniques:

- **Planning Poker** - consensus-based technique used to define the size of the User Stories in Scrum by all team members. It uses the Fibonacci sequence to "name" the values of the cards in the game (1, 2, 3, 5, 8, 13, 21, 34 ...). There is a person known as a Moderator who considers the estimated points and opens and leads a discussion regarding the estimated issues. Once the whole team agrees on a particular point(s), that becomes the User Story point(s) required to complete the functionality described in the task.
- **Work breakdown structure (WBS)** - breaking down the project into smaller modules and sub-modules that will allow the software testers to provide an accurate estimation. Sometimes to have more details and even more accurate estimates, the sub-models can be broken down into smaller pieces known as tasks. You can perform the WBS technique in 2 ways:
- As per [Wikipedia](https://en.wikipedia.org/wiki/Top-down_and_bottom-up_design), a **top-down estimating model** (also known as *stepwise design* or *stepwise refinement*) is an estimation technique where an overview of the system is formulated, specifying, but not detailing, any first-level subsystems. A top-down model is often specified with the assistance of "black boxes", which makes it easier to manipulate. This means that you estimate the overall scope of work by identifying and estimating the major elements of the work.
- **Bottom-up estimating model** - as per [Wikipedia](https://en.wikipedia.org/wiki/Top-down_and_bottom-up_design), "... is the piecing together of systems to give rise to more complex systems, thus making the original system's subsystems of the emergent system". One advantage of this approach is that you can repeat it until the app/system is built. Contrary to the top-down estimating model, you make estimations of the overall scope by combining the estimations of smaller chunks of work (tasks, features or similar) into bigger groups.
- **Comparison-based estimate** - it’s an estimation technique that is based on historical data. The experience from the past where we worked on a similar project can be really helpful when we will provide an estimation using this technique. To master this technique, use only the relevant information and data from the past you are familiar with and you have access to. Additionally, when using this estimation technique, be careful with aspects that differ; do not neglect them in a way that affects the pace of accomplishment.

If you want to learn more about Agile estimation and planning, you can read [here](https://www.netsolutions.com/insights/how-to-estimate-projects-in-agile/) or read the book *Agile Estimation and Planning* by *Mike Cohn*.

**NOTE:** At Infinum, as a QA team, we are not strictly using 1 or 2 techniques. The basic principle of estimation is left to the tester's experience, knowledge, and creativity, as well as the project structure as part of the Agile methodology.