A few years ago I wrote a post on getting started on a testing project. I’ve learned a few things since then and wanted to share an updated checklist for what new testers on a project need and some good starting questions when you, as a tester, are new on a project
It seems to me that there’s an increasing demand to hire people who can write test automation, or at least are “technical testers”. For more on what this term means, check out this article on the Ministry of Testing.
For the purposes of this blog post, I’m going to say that “technical testing” means someone who can go and test beyond the UI (User Interface). This means they can probably do the following:
- They can test against APIs
- Look under the hood and see network requests
- Understand code and what it does – maybe even write test automation
Here’s a step by step guide on how to write a bug report /defect report.
- Why are we writing a bug report?
- So there is a record of the behaviour
- So that the bug gets fixed – for the bug to get fixed we need to provide clear enough information so the developer can act upon it and the product owner/manager etc can decide how to prioritise this bug and if it should get fixed.
First, what is a heuristic?
A heuristic is a guideline, it is fallible.
Therefore, it will give you a good idea of what behaviour you should see BUT it isn’t definitely what should happen – it\’s up to you to confirm that the behaviour you are seeing is correct.
In a previous blog post I shared a step by step guide on how to test without requirements/little requirements. But I figured it’s good to share my most used test heuristics that I use for testing without requirements.
- Consistency with History
- Consistency with User Expectations
- Consistency within Product
1. Consistency with History
2. Consistency with User Expectations
A feature or function should behave in a way that is consistent with our understanding of what users want as well as their reasonable expectations. (Source: developsense)
Example: Signal, messaging app.
In the first photo:
I expect that the “Search/Sök” functionality searches for both contacts I have as well as messages containing the search string. For example: “And..” would find a contact called Andreas as well as a sentence “I have coffee and tea”
I expect that the pen icon in the top right corner means I can create a message
I expect that the camera icon means I can take photos once I tap it. If I haven’t yet given permission to the app to access my camera or photos, then a pop-up should appear
In the second photo:
I expect tapping on the X on the top left means I exit the camera view
I expect that tapping on the two arrows means it switches to selfie mode
If I were to be part of a project that was building a messaging app and was focussing on the camera functionality, I would ask myself – what do I expect to happen?
I sometimes find Consistency with User expectations can start to blend into Consistency with Comparable Products when I test. (Consistency with Comparable Products: Using other products as a rough, de facto standard against which our own can be compared. Source: Developsense)
If i was testing against the Consistency with Comparable Products heuristic, I would ask myself: “What do other messaging apps have? How does the camera functionality work on other messaging apps?”
3. Consistency within Product
The behaviour of a given function should be consistent with the behaviour of comparable functions or functional patterns within the same product unless there is a specific reason for it not to be consistent (Source: developsense)
Example: Allrecipes, a recipe browser
To some extent this behaves as I expected as I see the breadcrumb which helps me find where I am on the website, but on the /desserts page it is lower down the page, on the actual recipe page, the breadcrumb is at the very top. See screenshots below
Have you ever wondered, how do I test my fixes/changes on my local machine on IE 11?
Or in general, how do I test my fixes/changes on my local machine, when I don’t actually have that browser on my laptop?
I started on a new project a few weeks ago and thought it would be a good idea to share a checklist for what new testers on a project need and some good starting questions when you, as a tester, are new on a project
Checklist for what new testers on a project need (Note, your project may not include all of the below)
The Experience Report was given by Wil McLellan, who spoke about how he started up EPIC and how his communication skills enabled him to do so. It was a powerful Experience Report that many people found inspiring. Not only this, but we learned some valuable tips as well on communication.
3 Ways to Improve your Communication Skills
1. WIIFT – What’s In It For Them?
A valuable acronym that Wil taught us was WIIFT: What’s In It For Them? When you are in a negotiation or are holding a meeting, it is important to ask yourself this question in order to figure out where the other person is coming from?
- Why should they listen to you?
- What are you offering them, they would benefit from?
2. Build Rapport
If you build rapport with someone, it means they are more open to your ideas. An effective way to do this is through mirroring.
Wil described three ways, through which you can mirror someone:
- Body Language – When they lean in and cross their legs, you lean in and cross your legs. When they place their arm on their hip, you place your arm on your hip.
- Verbal – Take note of the tone, speed and volume at which they talk, then attempt to match it.
- Commonalities – Find things in common with someone. Do they like football? Mention that you currently play as a Striker in your local football club.
3. Aim for a Win-Win Situation
When you negotiating with someone, remember that you want everyone to win. Do what you can to make this happen and steer the conversation in that direction.