From a tester's point of view when do we say that a product is stable?
Is the product still stable when it contains a known bug?
asked Oct 28, 2015 at 5:56
-
The answer depends on how you use the information. Does "stable" mean "ready to be released", or "ready to be put in maintenance mode", or something else?– user246Commented Oct 28, 2015 at 11:48
-
from my understandings "stable" means ready to release...– sameer joshiCommented Oct 28, 2015 at 13:02
-
It depends on the severity of the bug, and the nature of the bug. You're writing a banking application and its is absolutely flawless except for one teeny tiny bug. All deposits are credited double. Is the application "stable"? // Stable to me means bug free enough that it can be released - to the customer or to the testing group.– MaxWCommented Oct 28, 2015 at 18:31
Add a comment
|
7 Answers
I would call a software that runs consistently without crashing as stable.
To answer the second question, yes a 100% bug free software is a myth (if i may).
There still can be numerous bugs which are hidden and to name a few :
- Bugs of implementation.
- Bugs of unclear specification.
- Bugs of poor documentation.
- Bugs of misunderstood requirements.
- Bugs of portability
- Bugs of testing
So that's a reason why we have bug trackers, reports and subsequent releases.
Testing a product and using a product is always different. Bugs might not really block the using of the system. Products mature by using them and by then fixing critical defects that are found. This leads to a stable and solid software product.
Stable often means something different in software development, it means the products behaviour does not change anymore. Its users can trust that patches/bugfixes will not change the behaviour of the software. Also read this blog which explains the difference between stable (release) and stable (mature).
From a testing perspective I would not use the word stable, rather "shippable" or "releasable". I always question what can we do to get more confidence in the product so that it can be shipped. If I cannot come up with more realistic effort to increase quality lets ship-it or push it to user acceptance. The users should tell you if it stable enough to put in production.
answered Oct 28, 2015 at 6:53
-
I feel ‘stable’ terminology or its definition does vary between different organizations as well (even though I never thought it would), I feel the above isn’t the correct answer. Stable make more sense from a software testing perspective than from development. Firstly, having my Business rules or requirements frozen is the step one towards having a stable product (keep in mind only that doesn’t make a stable product). <--continued in the comment below--> Commented Oct 30, 2015 at 1:14
-
In any model out there waterfall or agile or something else, a build released by development team has to be certified as ‘stable’ by automated acceptance tests or manual ones (which is done by a functional tester) and only then it’s considered ready for even a Beta release. Well, also patches are never meant to change software's complete behavior nor are bug fixes. Ironically if a patch changes software’s functionality shouldn’t it be called a subsequent release and not a patch (just wondering)? The blog shared in the answer above is one way to look at it but needn’t be the correct one. Commented Oct 30, 2015 at 1:14
-
That is the problem with all terminology. Often it can mean multiple things. But stable is used in the software industry as a branch which is feature frozen, unstable is current development. I would pick another term for a product in a releasable state and not re-use the word "stable". Commented Oct 30, 2015 at 7:51
There are no universal criteria for when a product is ready to release. You make that decision in the context of your business goals and your customer's expectations. A first-release website for uploading cat photos will have very different criteria from a mature banking application.
And who decides what those criteria are? There may be isolated, dysfunctional companies where the tester makes those decisions, but everywhere else, it's a group decision, because no single person knows the whole story. The people who talk actually talk to customers -- sales, customer support, marketing -- will have a better sense than the tester for how risk-averse your customers are. The technical people -- the developers, testers, and operations staff -- will have a better sense for the impact of a problem. Some selection of those people will decide when the product is ready to release.
-
Good answer. "ready to release" is a business decision. Commented Oct 28, 2015 at 18:33
I would say that a product is stable when it is obsolete - cynical but often true (40 years of experience as a software engineer / architect).
-
So a product is not ready to release until it is obsolete?– user246Commented Oct 31, 2015 at 17:23
-
-
@JustARandomGuy then what should we say "product ready to release" Commented Nov 5, 2015 at 5:29
-
1@sameerjoshi As per all the answers out there i believe the word 'stable' can be used or misused across different instances. I feel term 'shippable' is more closer to ready to release than 'stable'. Commented Nov 5, 2015 at 5:36
I don't think that there is an application free of bug but i can say that this application is stable when if there is no performance problems with it and the major and critical issues covered
It bit tricky question & also give you chance to how confident with your answer in that moment, and bring a light on your work ( how you tested ) ..... Waterfall As a Tester if you not notice any issues/bug those effecting the
- Application business logic - no issues on all level
- Functionality - not effecting to end users in critical way
- UI/IX - no critical issues
- Performance is - ok
Then you can say "product is stable"
SCRUM If you are in SCRUM methodology, then its a collective responsibility to say that product is stable or not to Product owner.
-
we are following SCRUm methodology please tell me what is "collective responsibility ?"from what point we decide product is stable. Commented Oct 28, 2015 at 13:05
Have used this criteria to measure software stability in the past:
- The known, unfixed bugs are "Acceptable"
- The rate of new (Critical/High/Medium/Low/etc.) bugs is below an "Acceptable" level.
In both cases, "management" decides the definitions of "Acceptable"
These definitions are used because you can never know when you've found all the bugs. The rate of new bugs is a SWAG as to the number of still-unknown bugs.
This is just one definition of software stability. All sorts of other criteria are/can be used to determine if/when the software should progress to the next step.
