Testing people's nerves while striking for quality

a QA perspective

A slightly irreverently view

on 3 of the actors

that determine project success or failure:

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

But the Code grew up

and the expectationsand the level

Then, the first project failure appeared

and the creation was not perfect anymore

So, the Market

created the Quality Assurance

to protect quality as long as the bugs exist

meaning: until the end of the soft

Can you love someone who keeps looking for your defects?

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

Working with professionals

Good QAs add confidence

Poor QAs add stress

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

Anyone can test

It depends on what do you understand by testing

"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

Staying in business is like solving a puzzle

The huge importance of having a good PM

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)

Assume the consequences of your decisions

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 :)

Don't forget that testers and developers have the same work program

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!

QAs are the MAIN responsibles for keeping the product safe

Don't give up easily to this role!

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

The journey to quality starts with each of us

Passes through our mistakes and limits

And finishes where the lessons learned allow us to reach: