In an ideal world, everyone would be responsible of ensuring the quality of their own work, meanwhile, these are some insights from a QA’s mind in case you want to start getting more involved with the area.
Get involved
Our work is not only spending time focused on QA functions, we should also spend time with our teammates figuring out how to improve the development process. We work side by side reporting to the same people, being measured by the same metrics and contributing to the success of the entire product, for example:
If we planned 5 features on the sprint and had 20 escaped defects, that would not be the developers’ fault or QA’s fault, that is a teamwork result and we all should be looking forward to improving.
We should get involved with helping web developers to deliver the product within the estimated timeline, detecting any issues that might obstruct the function and release of the product or even affect the user’s experience.
Wonder why
It is in our nature as human beings to get mad when things don’t work as we expected. If we can’t meet our goals or we get constant interruptions when using software or web pages, we tend to feel frustrated and leave aside what we’re doing.
Contrary to this, as a QA, our reaction must be wondering: Wait! What just happened here? What was I doing right before it took place? Can I reproduce it? Does it happen frequently? What happens if I go this way instead? Should I dare to…?.
As a QA, we must approach things from the end user’s perspectives and think negatively to spot errors and risk. Software developers and designers tend to focus on ‘happier paths’ thinking that everything is going to result fine and the user will follow a straight line, which is not always the case.
Look for clarity
For each feature, we should know exactly what are the desired inputs and outputs. For a QA, this means understanding and being clear about the expected behavior (including the corners and edge cases of each functionality).
Once you have this clarity and a complete list of specifications for your project, you can create a set of testing scenarios based on the targets, each specification should result in either unit or integration-level tests that ensure appropriate outputs for each behavior.
If you know for sure how it must behave, then you can try your hardest to overload, sabotage, or destroy it, it would take time to have this understanding, but in the end, it will have fewer failures and will save the team from maintenance and hotfixes. Remember that once the code is live, the current behavior becomes the default and it could be difficult to roll back.
Be creative
Being creative helps to discover the user’s workflows that deviate from the path. Not always customers treat features in the way that we expect, that’s why when are doing the exploratory test, we find alternative answers going the wrong way, performing functions incorrectly, clicking repeatedly or introducing numeric and alphanumeric characters on inputs.
“Testing is an infinite process of comparing the invisible to the ambiguous in order to avoid the unthinkable happening to the anonymous.” – James Bach
Something helpful I have found to do is brainstorming. This helps determine different scenarios that can ensure that the end user won’t receive a disappointing product that will crash while being used. The more time you spend thinking about these scenarios, the better you will become at spotting them ahead of time.
Report
When filing bug reports consider it must be clear enough to help others understand the real issue, make sure to include information about what you see (be detailed in what went wrong) and what you expected to see. When an issue is discovered:
- Check if someone else has reported the issue before.
- No matter how big or small an issue is, always report it.
- Provide solutions if possible, besides the bugs scenarios also provide the needed behavior of a feature.
- Take your time to add relevant information, screenshots, descriptions, steps, or videos.
- Retest, when an issue is being fixed, take as much time as needed to make sure it doesn’t happen anymore.
In conclusion, knowing how to perform software testing is just not enough. Yes, you must have the ability to craft testing scenarios, understand different testing approaches and write bug reports, but one of the major requirements for a QA is to have good communication with other peers (both verbally and in writing).
A QA has to convey accurately and clearly the message to their teammates and it should also have the urge to know more, therefore self-learning is also one quality you must look for.
