Hello everyone, I’m new here, and a fresher in software testing.
I have about a year and a half of experience in learning and practicing manual testing.
But still it’s hard for me to learn these things:
how to know what to test correctly?
what are the criteria that something has a good quality?
when to tell: ok, that meets the criteria for further production?
I know that there are other roles to answer to my last question, but at the moment, I started working in a small company where I closely collaborate with the developer and he asks me these kind of things…
Normally the first thing and most basic thing is the set of requirements that are to be followed while working on a user story/task. If the requirements have not been written down and finalized from a product owner, then you must stop everything to do that.
Assuming there is a set of requirements, there begins your start of testing. Each word in that requirement document tells you what to test.
Your requirement doc is just 1 test oracle and the internet is your friend. You can do your own research about best practices and norms that suit the context of your requirements.
E.g. Any input field always has to have some sort of max character limit, some error messages, some valid/invalid input type.
So as per your questions:
Question 1: Test oracles (other examples of similar functionality) and your own critical thinking will answer this
Question 2: This is an intersection between question 1 and 3
Question 3: Your boss/product owner/requirements engineer knows the business needs and what the customers want or what is envisioned by the top bosses. So that and a bit of your own critical thinking is what will work.
Hi @matea, that’s an awesome question and not something that’s taught a lot!
When knowing what to test we want to consider “what does good look like for the thing we’re working on” and “what risks are there that this won’t work how we want”?
What does good look like?
In order to support our team and be pragmatic, we want to test to a level of “good enough” rather than having too high of a bar for quality. This means working with the team / product manager / company to ask them how good they want their product (or feature):
Should it error handle?
Should it be usable and accessible?
Should it be secure and performant?
Should it be maintainable, deployable and releasable?
Does good enough mean a level of automation tests and observability?
When you have a target for what “good” looks like, then you can start thinking about what testing is enough.
Risks to the product
We test to reduce the risk that something will go wrong or that we build the wrong thing. Sometimes we’ll have detailed designs and specs that tell us a lot about what we want but team’s don’t have time to capture everything in documentation; which leads to uncertainty and a higher likelihood that we’ll build something wrong. We can mitigate against that by working out the ways in which something could go wrong (identifying the risks) and then testing for them.
There’s lots of risk analysis techniques like risk storming, critical analysis or breaking things down and looking at component risks.
We can work with our teams to prioritise what risks to test for and timebox them to ensure our testing is important.
We can talk to our teams about what we have / haven’t tested to see if we all agree that enough testing has happened.
This risk analysis can be done alongside the testing for any requirements we have to look for ADDITIONAL testing we might want to do (or exploration).
As you get more experience doing all this, it’ll become more natural to “feel” or know what to test and how much is enough. But even with experience, it’s important to work with the team (especially the Product manager) to agree on what’s enough.
There are many definitions of quality. A popular one is, “quality is value to someone who matters,” from Jerry Weinberg. This isn’t without flaws but, again, it can be a good place to get you started, thinking about who a person that matters is in your context, and what value looks like to them. Is value delivered? Are there things which detract from the value?
As for meeting criteria, acceptance criteria is a classic one for basic requirements. Unfortunately, this isn’t provided a lot of the time for whatever reason, and simply meeting all the acceptance criteria doesn’t mean something is good quality. Although you might not be the final decision maker on something being released, being able to provide a recommendation based on your test results and best judgement can be helpful. A lot of this comes with experience - both in testing and with the SUT. Something that might help you is to imagine yourself as different people - users, business people, prospective customers, support teams. Would this be acceptable to them? Can they do the things they want, to achieve the results they need? What complaints would they have? What would stop them from using this product? It might also be interesting to turn the question back to the developer and start a discussion.
I hope that helps! Have fun on your testing adventure
Thank you @hananurrehman , @cakehurstryan , @cassandrahl for your answers!
It’s really relieving to see that it’s natural to have so much questions and doubts in the beginning.
I might say that I’m on a right way with exploring, putting myself in a different roles, do lots of regression tests and that it is important to ask any questions that I have (and not to think maybe it’s a stupid question to ask…).
For now I don’t have much experience with documenting things, researches, thoughts and bug reports, so I must work on that part.
Still, when I start searching on the internet about one thing, and I end to the tenth thing, I get scared that I don’t know a lot of things… but I guess that’s the way…
Again thank you for sharing your thoughts and experiences.
Questions are great! And you’re right, it can be hard when you don’t want to look stupid, but if it’s not clear to you, it probably isn’t clear to someone else either.
And I can totally understand - even with eight years’ testing experience, all that’s out there to learn can sometimes be overwhelming for me too. At some point I decided two things - to let go of the idea that I can read / watch / research all the things, and to focus on what I need to know now and in the short-term future. The rest will still be there for me if / when I need it.
Many factors are being considered while deciding what to test, but the most important is the business requirement. Testing goals should always align with the business requirement and the focus should be on testing those as a priority. One of the seven basic principles of software testing states that even if the software is free of bugs, if it doesn’t meet business requirements then it is of no use, and works truly in the actual world. Apart from business requirements, we also have to take time & budget into consideration while deciding what to test because we have limited resources. Thorough risk & analysis can also help in better understanding what should we test and what we shouldn’t test.
I’m now focusing on learning API testing, and it’s definitely easier when you are focused on one thing.