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 ...
Tying cash rewards to metrics like bug counts is always a very risky business, one that is almost certain to introduce dysfunction.
I never want people on my QA team to have to worry about their bonus when I just want them to be doing the right thing.
Imagine you are the tester working with a single developer (who happens to be your best friend) on a ...
It absolutely is not valuable to measure bug count per hour of dev time. It is especially bad to measure bug count per hour for individual devs.
Devs on more complex or difficult code will generally have more bugs/hour than devs working on cleaner, more straightforward code. Similarly, devs will produce more bugs/hour at the end of a long workday than ...
When someone asks me to do something and I have questions about what they want, I go back and ask them. That's the most direct way to get an answer.
As a manager, I would want these fields:
description, i.e. what's the issue and why it's a problem
amount of risk if not fixed
level of effort to fix, including testing effort
associated bug ...
It depends, and there are no industry standards.
Seriously. Any metric can be gamed (and will be, if you use it for assessment). I'm not aware of any standard approaches, not least because the teams are - or should be - evaluating themselves regularly and looking for ways to improve their own processes (if they aren't then they're probably using SCRUM-but......
There is no definitive guide without narrowing the context dramatically.
What you are searching for has no universally-accepted set of metrics. If you search for web quality metrics, you'll find millions of hits full of personal opinions, or what matters most to selected individuals.
If you are trying to promote your technology, the right thing would be to ...
In addition to what everyone else has said, metrics used for performance bonuses are a seriously bad idea in the software world.
Metrics are helpful as a descriptive tool, but that's about it in my view.
Here's some of the reasons why:
every software project is different. That means that even if all the
same things are measured, comparisons won't be ...
This is process related - nothing you can solve as regular QA tester.
Your QA manager need to talk to DEV manager how to improve communication between devs, QA and customers, and how to track relevant info to gradually improve your whole process.
Bug tracker is just one part of it. But as QA, you cannot make developer enter a bug to tracker, or do anything - ...
By the success of the company.
Buy-in for QA will need to come from the top rather then the justification being looked for in data.
You will, over time, be able to point to things like
some major bugs prevented from reaching customers
performance issues anticipated and planned for
unusual bugs discovered for certain conditions
more new customers
At my current workplace, we don't distinguish between different ways that bugs are discovered. If a developer expects the test team to test the bug fix, they log it. If they don't expect the test team to test it, they don't log it. They understand there actions have consequences, and so they make that decision carefully.
We never penalize anyone for ...
In all honesty, my experience is that there are no best practices anywhere, even in something like code duplication. There are only principles that work to guide practice, and practices that are good in some circumstances.
You don't mention whether you're working with automation code or application code: depending on the automation method and tooling, it's ...
Can you prevent code with known bugs from going out? If you can't actually control the thing being measured, it's a bad metric.
What if the right thing for the business is to release the code, with bugs, to get it out faster so users can start benefitting? Sometimes having some software is better than none (but not always!). If the metric could ever ...
In addition to user246's suggestions, I'd also recommend looking at these areas:
presence/absence of unit tests
effectiveness of unit tests (that is, do the unit tests cover more than the code paths - they should be covering all the potential logical boundaries as well)
presence/absence of higher-level automated tests (including system, API, GUI, ...
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 ...
Coverage is always coverage related to some model. This often gets skipped over, which leads to much confusion "you said you had 100% coverage so how come there's a bug?!"
When you're looking at unit tests, then it's possible to use code coverage as an indicator (there are tools that can measure what percentage of the lines in your code are exercised when ...
I have personally found that the more you can reduce the overhead of developers fixing bugs before the code hits the main source branch the better off you are. I generally use a rule that as soon as a bug will be seen by or could effect someone else then it must be logged.
This allows testers and developers to pair together as part of a pre-checkin review ...
Agile teams are cross-functional teams. They estimate the work from design to delivery often on a story based level. This includes the testing work, since testing should be part of the definition of done.
Story points are the relative size of the complexity of the task at hand. Read more about estimating with relative sizes in this blog.
I as a tester part ...
Test Efficiency is a measure of the relevance of the bugs being reported. A low efficiency would imply that the test team are reporting many bugs that aren't worth fixing. This is pretty limited, and simplistic.
I've had better success with a pie chart that shows the "resolution" for all of the resolved bugs. This shows the resolution categories like "...
Black box approach in and of itself is specifically designed to come from the user perspective backwards. The difference between black box and white box testing is knowledge of the underlying code and components.
Therefore when you are prepping for black box testing you should be coming from the user perspective who utilize the application. This is any ...
As Kate says NO
The common term for kind of metric from those with experience is:
A bad metric
I'll go even further and say any kind of bug count is likely to be gamed
The industry has done thngs like this is the past, e.g. 'lines of code to measure productiviuty'. You can imagine where that leads! Although maybe how few lines would be good? NO! That would ...
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 ...
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".
The problem with known performance metrics is that it changes behaviour. Not necessarily in the way you'd imagine.
When the plague was going on in Europe, rewards were set up for people catching/killing rats and presenting the bodies. Pay per carcass, nice and simple right? Until people worked out they could breed rats and make more money that way...
I'm a workmanlike Tester who's had the good fortune to work with some excellent people over the years. When I hire people, there are some key characteristics I look for:
Eye for detail
This is the obvious one. Testers need to be able to see the little details that others miss. You know those Facebook questions? The ones that go:
Spot the mitsake : 1 ...
% of Rejected Defects - makes sure your QA really understands what he is doing.
Time to test a feature - how long does it take the QA to actually test a feature
% of Escaped defects - how many defects were found by customers post a release
Usability grade of your system
I'd also count how many enhancements requests your QA is opening - making sure they also ...
Metrics are useful, but they should be supplemented with subjective judgement. It's useful to have something measurable to use as the basis for management decisions such as promotions, raises, and bonuses. Of course any metric can be manipulated to defeat its purpose, so a competent manager will use their own subjective judgement too.
The bonus formula ...
I would suggest you look at their
Scope of testing, (white box / black box) test aspects, App store testing, versioning, Security testing, memory usage and usage of best practices (mind maps, automated tools, carriers etc..)
Tools used / Automation Efforts
Previous projects in similar domain / expertise
Meaningful Measure of Number of ...
There are the following types of test coverage criteria:
criteria based on explicit test case specifications
criteria based on statistical methods for random test data generation
criteria based on mutation-analysis
All criteria except the first one are non-structural.