‘Back in the day’…in our old forum we ran a forum discussion asking the software testing community for 99 ideas of what software testers could do to become a better tester.
We collated the list of answers and produced an ebook 99ThingsEbook.pdf (3.2 MB).
We’d like to do it all again! Whilst some answers are still relevant, others are not so much. Can we do better? Have we become smarter and wiser as a testing community?
Add your response to this forum post and we’ll collate them once we have a long enough list.
Stop treating developers as the enemy. I still see this mentality, and it’s unproductive, causes unnecessary conflict, and just outright needs to stop. We all work together on modern teams to make the product shine.
Try to fix a bug yourself, even if it’s been around for years. You gain a new understanding of not only the process to code something, you also get to experience exit and entrance amigos from a new perspective and you get to learn how to write tests as a developer would, allowing an in to see what tests are covered. Also it allows you to get in the code review process, something that would be awesome if all testers could be involved with.
Never stop learning. At the end of every day I ask myself the question: “what have I learned today?”
No matter how small, every day there is something you’ve come across that you didn’t know the day before. All these little (and big things for that matter) “learnings” will make you a better tester.
Read Git commits. As someone who comes from the ‘manual’ side of the coin there is importance in knowing what goes into the code when a produt is tested. Git commits are snippets demonstrating how the code is changed for the purpose of bugfixing, new features or refactoring, all of which are useful as a tester to figure out where the risks might be.
They also tell you more how a developer works and where they might be focused. This is especially useful if your teams work with code reviews and so you might catch on to possible mistakes or how other developer’s insight might catch bugs before you even have a line of code to test.
Finally they tell you how to prepare for the tests you will be running in your evaluation as a tester of their code. Sometimes there might be something else that wasn’t on the Jira ticket that might allude to either a potential bug or feature…
When a feature is given to the team for development, testing and deployment, as a tester, analyze - Why do we have to do this feature in the first place? What are we trying to solve by doing this? What is the big picture of doing this small feature - how can we connect the existing dots (features) with this feature we are developing to make things better? Can you get first hand information from your managers or anyone else to get an answer to these questions?
By doing this we as testers will not just look at a web page as a set of web elements, a feature as a testable work product, but we’ll also look at it as a problem solver - a solution that someone is trying to figure out.
Advocate Usability - this software is (usually) going to be used by a fellow human being so chances are that the text being in two different fonts is going to annoy them just as much as it’s annoying you right now.
Build strong relationships with the programming team. It can be hard on the developer when you keep sending their ticket back and telling them that it still isn’t good enough, but if you have a good working relationship, you are less likely to create any tensions. Also, they can be really useful when you are trying to understand error messages and you can learn from each other. They will only help you if you are on good terms to begin with.
This! I can’t believe how hostile the testing and programming teams can be and it is really sad. At the end of the day, they both want the same outcome - a good, working system. It isn’t hard to be kind.
Increase information transparency => Look for ways to make people know more about all aspects of the project without having to wait for date/milestones, big delivers, or having to ask people directly. Thus, you will enable others to detect risks and problems earlier and more often.
(Sounds almost like a manager job, but I think a tester should pay as much attention as a manager in the team’s dynamics)
Apply testing to itself to become a better tester:
Test your testing methods. Test your tools, your team, yourself (but never other people - they notice). Test your test code and your automation (if any). Test your bug reporting and your other communication.
Learn and practice your craft: read books, blogs, magazines; attend trainings, courses, conferences; talk with colleagues, join tester’s networks and so on.
Share your knowledge.
Reflect your activities, your results, your role, your skills, your behavior.
Be aware of your responsibilities, your order and your limits.
Train your communication skills: train to listen, to ask constructive questions, train to discuss and argue in a positive manner.
Be friendly, be positive, be supportive - be the person you want to have in your team.
Be open minded, be curious.
Be patient with yourself and with your colleagues.