testing people's nerves - a qa perspective
DESCRIPTION
Testing People's Nerves - A QA PerspectiveTRANSCRIPT
Can you love someone who keeps looking for your defects?
From tester to great tester: stairway to Hellven
Working with testers: great expectations, soft reality
QA - The GenesisAt first it was the Code
and everything was good...
for the first level and expectations
Learning from mistakes
Have a clearer view on different projectsand project management types
Comparing and concluding
Learning to become a team player
Learning to appreciate the proffesionals
Seeing successfull projects
Seeing failed projects
Making mistakes
Maturity
We are creators, they just are - seeing the value added by testers
You need somebody to watch your back if:
You' ve missed implementation cases
The code didn't work as expected after deploy and you had to use "it works on my machine" magic words
The code you deployed broke up existing functionalities
You don't have enough time to both implement and test
There is a relevant difference between what you had to create
and what you created
Do testers only find bugs or they also create them? - trusting the professionalism/ knowledge of the tester
The fear to lose control on the code and investigate false issues created by testers
Analize the risk before allowing somebody to access the DB, code or change the environment
But allow your testers to grow up and learn, sharing might be scaring, but is caring
I'm doing something more interesting now
If the less interesting thing is a testing blocker,this may delay the testing and affect the release
Make sure you won't have stay to repair the consequences, instead of going to the already planned vacation
This issue is not relevant
The user' s perspective may be different: priorities, expected behavior
What may seem obvious to you may not be so obvious for a non-IT person
The only actions the user's won't do are theones not allowed by the application
The tester has to be stick to user's requirements, even when these are annoying
"This is not a Bug" story
Raise a flag to the client, describe the case
Estimate the added effort, if extra coding is necessary
The concern for a fully functional product is thekey of remaining on the market
Incomplete specifications don't justify a crashing or risky application
Working with testers: great expectations, soft reality
Having good QAs and Devs is not enough for obtaining a quality product
Delivering quality is a more complex process
It's almost impossible to succesfully finish a complex project whithout a good Project Manager
Keep the pressure away of the team (as far as possible)
Identify the risks and avoid or minimize them
Make distinction between critical and non critical requests and changes
Push back unreasonable requests and changes
Be reasonable with both the client and your team
Be ready to justify the project decisions (and have enough diplomacy and arguments)
Treat your team as mature people, explain when is necessaryand, at some point, they will behave as mature (hopefully)
Know your team, people's skills, their strong and weak points
Give the explanations at time. You'll have to do it anywayOnly the moment will be worse
The number of sorries you can use with a client is limitedDon't waste it !
Good PM / bad PM - a QA perspective:
Testing, such as development, requires time
Testing can't allways recover the development exceeded estimates
However , thank you for your trust :)
Some clients think that, once the code is implemented, the process is completeBut they still expect for quality
Explain that the testing step is mandatory, not optional
(Hopefully, you consider it mandatory, as well)
Don't suppose that the client accepts a lower quality product when he asks for a faster deploy
As long as he pays for QA, he expects quality
Make sure that you raised the quality risks in written
People tend to forget or change jobs. What remains is the experience of a poor quality product you've delivered
Protect your client by showing the risks of his decisions
Do NOT suppose that he fully understand the consequences of his requests
Quality does not depend only by the value of QAs or developers in the team
But also by the way PM facilitates the work and maintain the pressure at a reasonable level
From tester to great tester: Stairway to Hellven
Good Testers:
Clarify aspects by asking the right questions
Are not only testers, but also good analysts
Help the team to identify issues from analysis & design phase
Have both diplomacy and determination
Give confidence in product's quality
Search for quality and not for bugs
They DON'T like finding bugs!
Push back when there is pressure that generates high risk for the product
Escalate the risks and make sure they are properly understood
Protecting product's quality = Respecting your team's work
Every team has the QAs it deserves
In the end, great teams are made from people who:
Respect each other
Strive for excellence
Have fun while working together
Have trust that the others do their best
Are ready to help when needed