When I started my first QA job, it was my third career. At that point I had been in IT (with a side of document control) and a help desk technician was my second career. Each position taught me something about myself and dealing with people. I learned how to deal with angry people by being calm, how large companies handle desktop machines, and what 24/7 up time means on your personal life.
I wasn’t a great listener.
One of the hardest things to learn in my early career and something I was still working on when I started in QA was to listen. To stop talking with my voice and my mind, and actually listen. Listening is a key activity in testing, management, and life. Everyone can teach you something, despite themselves. Stop thinking that you know what the other person is trying to say. When I really listened, I found issues with the applications that would have been lost by reading just a ticket. Listening to the conversation going on between developers and the business helps you find gaps and assumptions.
Ask questions, not to hear your voice, but to hear the need.
When it comes to testing, tickets are a great starting point, but can often be incomplete. This can be for many reasons, but more often than not it is because of assumptions. Everyone has a set of assumptions when they start writing a ticket. That’s one reason why the “Expected Results” section is crucial. It displays an assumption about the behavior. User stories don’t always convey the end results well, so asking questions is critical to understanding what is intended. Also as a side note, do be afraid to question the “Expected Results” in a bug, sometimes it’s not a bug, but a misunderstanding of functionality.
These are just a couple of the things I’ve learned while being a tester and then a QA Manager. These are a good starting point and two things that I continue to practice.