Many testers don’t know how to say the word NO.
– They don’t know how to say They CAN’T take that additional task and still meet the project’s original schedule.
– They don’t know how to say They DON’T have enough information to estimate how long it will take them to test the product.
– They don’t know how to say that The product should NOT be because they have not finished running the tests that cover the relevant features.
– They don’t know how to say They WILL NOT accept the build because the developers didn’t run their sanity tests.
– They don’t know how to say that The testing phase of the project WON’T finish on time because non of the previous milestones was met according to schedule.
Are you a YESaholic?
I know about these problems because I used to have them myself, “Hello, my name is Joel and I am YESaholic“.
For those of you who never heard about this term, a YESaholic is a person who is addicted to saying YES and can’t say NO when asked if he can do something.
I admit it, I don’t like saying NO when asked for help. I like to take-on all challenges and be the best of palls to all my coworkers, and this attitude usually lands me in hot-water for accepting more tasks that I can handle or for taking responsibilities that are not mine.
Back when I started my testing career I could not understand how it was possible to work under all the pressure of being a tester:
– Providing estimates to features I couldn’t understand based on the information provided to me.
– Trying to run all the tests and finish on time, even when the builds where delivered weeks late and with quality bellow any level of expectation.
– Helping every sales person, support engineer and developer in their tasks but never accounting for this work when planning my testing schedule.
– Working nights and weekends when developers where not even around to help me troubleshooting the bugs as I found them.
– Taking ownership for all the bugs and accepting to release the product even when I had not finished my testing cycles.
Providing a good service doesn’t mean saying YES to everything
After thinking hard about it I understood the problem was not in the testing tasks but on how I was approaching my job as a Tester and a Test Manager. I always felt that testing was a service to be provided to the rest of the organization and as such it was my job to SAY YES WITH A SMILE.
My task was not to make everybody happy, but to provide visibility into the product and project we are working on. Uncovering issues, providing feedback into the areas where the development should focus their work, and helping product owners and project managers to decide whether the application was on track based on its release objectives and schedule.
The only way to do this is if we take our job with the top most seriousness and we learn to say NO when we need to.
You need to say NO when you don’t have time to help someone else. You can say YES, but only if you delay the task you are working on and the project team agrees with this delay.
You need to say NO when someone asks you if it’s OK to deliver a build late or to receive it even if no sanity tests were run by the developers. Or you can learn to say YES, but make sure the project teams knows that the schedule is no longer valid.
You need to say NO when asked not to run a set of tests in order to meet the schedule. Or say YES, and make sure everyone understand the risk for deciding not to verify a specific area or feature in the system.
You need to learn to say NO when you cannot say YES confidently, and understand there are times when saying NO is the most professional thing you can do. It doesn’t make you a bad team player, a bad tester or a bad friend.
Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.
Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.
With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.