Clarity about your role in the project will help you negotiate it to
avoid the confusion & unreasonable expectations.
You are the headlight of the project
The information you find will be used to take the critical decisions. Light up the road and show what is out there.
Your mission drives everything you do
Know why you are testing and set your mission based on the purpose of testing. Check if your testing mission is aligned in with the interests of your clients
You serve many clients
A service role like testing will require you to serve clients such as PM, Programmers, Marketing, Technical writers, Support, Management, The User) with different needs and interests. Reports and information you provide should be helpful and supportive enough for them to know and fix problems and take informative decisions. Know who matters and whom you serve.
You discover things that will “bug” someone whose opinion matters
Report and inform your clients about “anything” that threatens product value
Find important bugs fast
- Test changes things before unchanged things
- Test core function before contributing fun
- Test changes things before unchanged things
- Test core function before contributing functions
- Test capability before reliability
- Test common situations before esoteric situations
- Test common threats before exotic threats
- Test high impact problems before low impact problems
- Test most wanted areas before areas not requested
Run with the programmers
Your shortest, quickest and informative feedback loop about changes will support and help programmers work efficiently.
Question everything, but not necessarily out loud.
Questioning will feed your testing flame. Ask questions without overwhelming or putting people in a defensive position. Self questioning will also bring you more insights.
You focus on failure, so your client can focus on success
Focusing on failures increases the chances of finding problems and get them fixed to make the better and successful product in the marketplace.
You will not find all the bugs
You may find significant bugs, but understand that you can’t test every different situations and find every bug.
Beware of testing “completely”
In your communications, always be clear and explicit about what it means to have testing completed or finished or done. This will be your safety net and stakeholders will stay aware and informed.
You don’t assure quality by testing
Testing a broken software does not make you a quality guardian. As testers don’t create quality, never act as the only person concerned about product quality.
Never be the gatekeeper
Whether to ship the product or not is a responsible decision which testers are not equipped or authorized to make. As testers you should not control the release decisions, but if you have to, share that responsibility with other team members
Beware of the not-my-job theory of testing
Testing is not just finding and reporting bugs, and you would need to explore and look into usability & requirement problems, data quality and supportability concerns. Tester’s job is to make the team aware about anything that reduces the product value. Be adaptive.
Beware of becoming a process improvement group
Process improvement requires a team efforts. As team involves people, it often ends up hurting feelings. As a tester or test team you should avoid becoming the process criticizer.
Don’t expect anyone to understand testing, or what you need to do it well.
Your client and team members might not understand the testing and how their choices, actions impact the testing process. Make them aware by explaining what you need and why you need it to do your job better.
Initially I made the above notes using Canva tool in infographic format, but as it was a bit time consuming so from now onwards I would just work with blog posts only. Better use time in reading more and decorating less.
