First, I would suggest that estimating and understanding risk should be a shared activity (include developers, PMs, other stakeholders). While QA often understands a fair bit about some of the risk associated with software work, "scheduling risk" and other concerns that may not fall on QA should usually also be considered. Bringing in more roles will often ...
The idea of risk based testing is that your context defines what the risks might be. What is important to me is not necessarily important to you. So there won't be a checklist that will work for everybody.
Having said that: you might find this HTSM explanation useful. To guide your thinking about what could be risky in your situation and what area would ...
I'd look more at things from a quality assurance point of view, not a quality control point of view. For example, how sure are you that the requirements you've been given are the right requirements? How sure are you that there aren't requirements that are missing?
Then, for the requirements, I'd focus more on things you can't/won't test. For example, let'...
Yes, but it depends of course.
Transfer the risk to someone else to handle.
If this someone handles the risk for you adequately this seems perfectly fine. In a company you should be able to trust when you delegate something to someone it gets handled satisfactory.
Ignore and accept the risk.
This is perfectly acceptable for example when the effort of ...
Undocumented features are BUGS
It doesn't matter whether the undocumented functionality appears harmful or not, it is still a bug for the following reasons:
Because the functionality isn't documented, there is no traceability.
Lack of documentation means that harmful consequences are much less likely to be found (if testers don't know it's there, they can'...
Testing is the process of evaluating a product by learning about it
through exploration and experimentation, which includes to some
degree: questioning, study, modeling, observation, inference, etc.
Therefore, the level of risk-based testing you will deep depends on the techniques you use to question, study, model... the product and what ...
From this article:
"In pragmatic terms, "risk tolerance" is nothing more than a
reflection of a given decision-maker's attitude in a given decision"
In my own head, I have always thought of it - much in the way the article does - as, "D.A.D"
D - Define
A - Assess
D - Decide
What do you want to accomplish? What value are you adding? ...
First - couple of my thoughts about regression risk assessment
Any brief assessment implies pretty low level of accuracy
Personally I do not see much value in assessing regression risk briefly. What is that?
Is it a probability of regression issue? If yes, how do you use that information? Say we estimate 15% probability of we will get regression here, so ...
How to handle it?
First of all,
I am assuming that the requirements have not been documented for this functionality.
So, proper requirement analysis+ impact analysis (on intended functionality) should be done before testing team can estimate for this hidden/undesired functionality under question:
Now if the organization decides to go ahead with it then ...
In my personal opinion, one classic example of unexpected functionality is Easter eggs.
Easters eggs introduce unexpected functionalities ranging from printing developers name to the standard output to leaving a backdoor only known to a few developers.
As a general rule, an unexpected functionality is introduced by either a coincidental mistake or hidden ...
While in theory it's appealing to have the same dependencies and their versions for many apps, in practice this often is not feasible. If each app has its own release cycle it's hardly possible to sync them. May work for 2, but good luck synching 10 apps.
So you need to embrace the fact that dependencies are different and they update from time to time. But ...
Personally, I'd prefer to have only one level of any given package in use (or one in development and one in production, if you're going to be moving to a new level of code on the next deployment), as it reduces your vulnerability surface in the case of security bugs (I'm thinking of things like the recent bash and imagemagik issues here).
With that said, ...