Why testers know best...

Because testers ask questions when they don't understand
Because testers think about what can go wrong and not how it should work
Because testers are not dedicated to go live in time
Because testers still want to go live in time more than finding bugs that don't matter
Because testers love finding bugs that matter
Because testers don't have much advantage in telling 'I told you so'
Because in the end, if a problem is not fixed in time, the tester suffers from that so they are driven to find issues and defects early
Because testers don't have 'babies' to protect and therefore are the least biased people in the project
Because testers have a critical technical eye for detail and understand what business wants in the same time

Forming Storming Norming Performing

We kicked off with a team of completely diverse people, starting a project that was going to be the biggest challenge most of us ever faced.

The first months of the project where more difficult than any previous other project I had been working on. Finding out our places in the project, how we would fit to the puzzle, was for everyone one of the biggest challenges. At first conflicts were avoided, and specific tasks were not performed. Later on, some of us got caught up in quarrels and fights and after months of hard work, as a team, we contributed to late and poor quality delivery.


After a couple of months of suffering, we learned on a team building event that this is so very normal. After that we found that by good leadership, team members are being carried trough different phases in a model of a team-building process.
The model I'm talking about is the model of Tuckman and considers the Forming, Storming, Norming and Performing phases in team building.

If you ever get a chance to look at your own team from a distance, you'll definately recognize this model and if you're manager of a leader of a newly created team, you definately need to know these things if you want to improve your team atmosphere and quality of delivery.

Forming

The team is assembled. Team members don't know each other well and tend to act independently. There is no real group-feeling.  Conflict is avoided. Team members have a need for guidance.

Storming

Team members start to take their positions in the team. This process often leads tentions between team members and contradictive ideas.

Norming

Team members are aware of the need of rules and methods. Those rules and methods are defined within the team. The common objectives become clear and the required roles are divided over the team members. The team with all team members take responsibility for the delivery of the objectives.  The risk during the Norming phase is that the team loses either their creative spirit or the drive that brought them to the Norming phase.

Performing

The team is working together harmoniously to achieve the common objectives. The team is working independently and makes collaborate decisions. Performing teams are identified by high levels of independence, motivation, knowledge and competence.



Unfortunately, many teams never make it past the Storming phase. However I dear to say that we made it at least to the Norming phase as a team, yet we still have a lot to deliver...

Bug Fix Bingo

How to dynamically turn frustration of testers into positive energy?


Bug Fix Bingo
Developers seem to return with interesting reasons why a bug is not 'really' a bug.
Testers on the other hand, need to understand that developers don't produce code but create art-work.

Now, tester, when you come back from a soft-skill-battle with the developer where you finally, without hurting their feelings, were able to make them aware of this little mistake they made, you can return and have a little prize as a reward for your empathy and communication skills.
In stead of getting frustrated and going back to your PC with a head-ache, you will be allowed to participate in the Bug Fix Bingo.

To the developers: Please don't take it too personal. This Bug Fix Bingo keeps your testers sane and in the end, those bugs really need fixing.
The game was created by K. J. Ross & Associate ( http://www.kjross.com.au/page/Resources/Testing_Games/)

Let's get rid of the safety net

 I couldn't possibly say it better than Gojko did... but I can write about it.

What Gojko came to tell us in the Eurostar conference of 2011 was that with software testing as we see it most - A phase of executing test cases after the product development phase has ended - does not contribute to quality.
It contributes to building a safety net for developers, managers, and even testers.


Since testing is done after development, developers get encouraged to become lazy as they don't need to make sure that their development still really works.

Testing should not be about

• Logging defects that developers actually already know about. When for example simple client side field validations don't work, developers could know before a tester knows.
• Waiting for a product to start testing and designing tests against a formalized analysis, to cover our asses instead of the product
• Answering business on their requests instead of providing what they really need
• Assume that all requirements and designs are clear and correctly defined

Testing should be about

• Helping analysts and developers by showing them how things can go wrong during design, development and delivery
• Providing what business needs instead of what business wants
• Help non-testers be better at testing
• Test the complex and critical parts of a product
• Find the real requirements and share them with all team-members
• Being part of a team that is jointly responsible for the quality of the delivered product

 

View more presentations from gojkoadzic

Beware of inattentional blindness while testing

What's "Inattentional blindness"? and what does it have to do with testing?
I got advised about inattentional blindness by a colleague tester, who got it from another colleague tester, who got it from another colleague...

This turns "Inattentional blindness" into a Test-Myth!

Before I say anything further about it, I would like you to watch the very short video below and carefully follow it's instructions.

(Don't read below the movie yet, as it will contain spoilers)

Have you been surprised? There are different explanations for the reason behind it. (http://en.wikipedia.org/wiki/Inattentional_blindness )

• Conspicuity - The ball draws your attention.
• Mental Workload - You need to count so you focus on counting only
• Expectation - You expect only passes to see and focus on the passes only and block other content
• Capacity - You see this movie for the first time and you're not used to these exercises. You're not used to do this.

Now, what is in it for a tester? The key message is:

When you focus, DON'T FORGET TO DE-FOCUS!


This is what you do when you execute pre-scripted test cases:

• The test needs your attention - if you pass it, you better be sure about it! - Conspicuity
• You need to focus on preparing the correct data and executing the correct steps - Mental Workload
• You expect only a defect against what you are testing - Expectation
• Especially during the first run, you're not yet used to go trough the procedural steps - Capacity

It's important to achieve a goal, to pay attention and to be focused on what you're doing.
It is equally important to look around at the things you did not prepare test scripts for and find the bugs.


How can we do this?

• If you feel the urge to prepare test scripts - don't detail them into descriptive test steps. Leave yourself some space to find alternative paths. Describe your paths on the moment of execution.
• Per functionality, give yourself a time-boxed moment of time to look around in the application and find out about what you forgot about.
• Put a post-it on your screen saying "de-focus" as you will forget from the moment you try to remember.