Fibonacci series is just one example for estimation efforts. Some teams also use series as below:
1, 2, 5, 8, 20, 40, 100, ....
1, 2, 4, 8, 16, 32, 64, ....
The idea is to use an exponential scale for estimating efforts.
The reason is the larger the story point, the more uncertainty there is around it and the less accurate the estimate will be.
They reflect that the degree of uncertainty grows as you look further out and at bigger tasks with more dependencies.
For example, today you can be reasonably confident about how much effort is needed for a small task. You may be highly confident that you can finish it within a day, and, critically there is little uncertainty about the factors involved. So ...
When a new project development starts in an organization when does the testing role come in?
It depends on the company, industry, development approach, etc.
Two commonly referred to methods for development are Waterfall and Agile
In Waterfall you do the testing once the development of a feature is done.
In Agile you do the testing before* and ...
For estimation, the following aspects should be taken into account:
Domain knowledge of the team and the requirements.
Risks associated with the project.
the software life cycle followed by the project.
There are a number of techniques which can be used for test estimation, namely:
3-Point Software Testing Estimation ...
Testers have a role in every phase of a project (be it waterfall, iterative, or full on agile):
Project planning - ensuring proper consideration is given to procuring and setting up of test architecture, and for both testing and resolving faults found during testing.
Requirements gathering/setting - testers can help ensure the requirements are described and ...
I lean toward involving Test from the beginning. When building something, if you don't support ways of testing it from the beginning, you end up having to rip it up and add that later. This hurts the company.
Let's discuss "testing".
As a developer, I consider test to be essential feedback, many kinds of tests to be important, and the Test department ...
Common estimating methods include numeric sizing as well like 1 to 10 or sizes like XS, S, M, L, XL, XXL, XXXL or Fibonacci sequence 1, 2, 3, 5, 8, 13, 21, 34, etc.
The reason for using the Fibonacci sequence is to reflect the uncertainty in estimating larger items. A high estimate usually means that the story is not well understood in detail or should be ...
Spoiler: No scientific reason.
Fibonacci grows very fast, so people will have fewer options before reaching enormous values; thus it incentivizes breaking work down in smaller pieces.
If the smallest typical work takes 1 hour, a big piece may take 8, 9, 10, ..., 16, ... even 32 hours.
However, if the smallest piece of work takes 1 story point, and they ...
It depends on the methodology of SDLC we are using, ex: if it is agile development with continuous-integration in place,then it should take 30 percent of development time.
Like 15 days development of sprint, then time taken for testing should be 4.5 working days, if key features of applications automated.
It also depends number of QA resources involved ...
A notion I don't see in any of these answers is that in a simple 1-10 range, people can get bogged down in whether something is a 3 or is it really a 4? And what if another person thinks that it should be a 2 instead of a 3?
By using a Fibonacci sequence, you eliminate a bit of that "hair splitting".
Posted about this just recently. Reference to the original is at the bottom.
Suppose you want to know how long a task will take. You take a look at the problem and estimate that it will be one hours worth of difficulty/complexity. At the end of the hour it's not done. You've realized something about the problem and it's as if you are starting over....
This question is answered in a blog post by Jeff Sutherland (co-creator of Scrum). It's rooted in a US Department of Defense study on estimation.
Rand researchers then studied the effect of the numbers estimators can choose and found a linear sequence gave worse estimates than an exponentially increasing set of numbers. There are some recent mathematical ...
We estimate in relative complexity using Fibonacci points, as a Tester I compare the following complexities to give my overall gut-feeling effort in points, compared to recent delivered features.
I consider the following, from top to bottom:
Testing complexity: How hard is test automation, do we have technical test debt, time to configure the system under ...
I think that estimation should be given by people who will eventually do the work. That means every role gives and estimate and you put them together.
It will always be a bit innacurate, but to me, it still seems much better than when someone else who does not do my type of work estimates how much I will spend on something. The room for error seems bigger ...
I think the effort depends on the definition of "done".
If QA is included in the definition of done, meaning a user story is
marked as done only if QA is completed then the effort should
include both development and testing efforts
If the definition of Done is "Qualified for QA testing" then only development and integration/unit test is considered
If, you ...
II would like to ask that you genuinely try to answer/estimate every question I ask before reading on. The goal of this answer is exactly to make you understand how humans tend to estimate something when they don't know the exact answer. There's no better teacher than your own mind.
Because it reflects how humans instinctively think about things
Mike Cohn says in his book Agile Estimating and Planning that he originally used 1, 2, 3, 5, 8, 13, 21 as his sequence until a client said to him "You must be very confident to estimate the size as exactly 21 and not 20 or 25". He realised that 21 was too precise, so he changed it to the vaguer value 20.
8 is bigger than 5 and smaller than 13. It's ...
It is a convenient mathematical sequence whose growth is approximately exponential and not too steep
It is the only mathematical sequence whereby tasks may be split into 2 tasks whose estimates are the two previous numbers in the sequence, and such splits may be repeated until all subtasks have size 1
I think the main reason is because it easier to estimate in relative sizes. This is smaller or larger compared to that. If you look at different buildings from a distance, you could say that one is twice as large, but getting the exact height correct is much harder. For Agile work this means, if that took 2 days, this other thing of similair complexity will ...
A reason that wasn't yet mentioned is that it supports well to split a task / user story into two (non-equal) smaller ones - an 8 splits into 5 and 3, etc.
Of course, the same is true for combining them (if the numbers were consecutive).
The short version: If possible go through your organization history and look at total test time for each project and total development time for each project. From this you can calculate the average and typical dev/test ratios.
The long version: It depends on the organization, the development methodology in use, and many other factors including how much ...
I need a set of broad guidelines that my company can use to generate
test estimates around these general principles
Instead of trying to come up with magic formula factors, it would better to use historical estimates and actuals, tempered by smart people using their intelligence.
Find a past project that is similar to the new project.
Think about the ...
Some of the things I look at are:
Standalone or Not - test effort tends to be less if the new functionality is a standalone application rather than a new feature of an existing application
Internal Complexity - Something that does a lot of things will generally need more time than something that does a few things.
Edges and Integrations - Something that has ...
Yes, I would take previous test cycles and number of defects with this team, product or developer in a account. If it is new team/product make a guesstimate based on your previous experience.
I never had a test run where I didnt find a defect, or struggled with the configuration, infrastructure, and or setup to be able to start testing.
This estimate ...
You should first ask yourself what is "testing". If you refer to manual/automated testing of the implementation then it cannot start before development or part of development is done.
However, referring to testing in such a way is rare nowadays. The Quality Assurance should already take place when the analysis/specification is being done and they should ...
When a new project starts in an organization, when does the testing role come in?
It definitely depends. Often too late if you ask me. In my world the ideal timing is right at the start of the project. The earlier the better. There might not be a lot of hours spent early but they can be very valuable. The testing role can help in making the requirements ...
I'd say you (almost) always need to count with some additional time spent on defects. Whether or not you specifically say so (as in creating a special task for it), it's a different question.
I was asked to provide estimates on how long the tasks would take in QA standpoint. Should the defects that might be encountered be considered?
I can see at least ...
It's dependent on many things, I haven't encountered any tools. I'm curious if there are any. We generally end up around half the time it takes for development. However this can be drastically different depending on features. Is it localized into 4 different languages? How many different platforms does it run on? Does it need to connect to multiple different ...
I always like to advocate my 33% rule for Agile software development.
The cycle contains three major parts (which should be used in parallel if possible)
Requirements, design, user stories and other documentation
Coding (with SOLID patterns)
Testing (including unit-tests, integration tests, end-2-end tests and continuous-integration)
If you do not spend ...