Using real life test stories, I will present to you examples of mindset tools that I have identified, how I have used them to optimize collaboration in software development teams, become a valuable team member and a skilled tester. I will further propose a model that can help individuals develop their own mindset tools depending on the type of environment and product being developed.
4. A way of reasoning that determines behaviour, outlook and mental attitude of a
Tester, Programmer or Project manager towards testing of PUT (Program /Device
/Product Under Test).
@vivienibiyemi
5. The reasoning that is needed in questioning & investigating the PUT.
@vivienibiyemi
7. Delivery of a quality software starts with each role recognizing the importance of
contributing their quota to testing.
@vivienibiyemi
8. Everyone working with the PUT needs a level of Tester’s Mindset for us to deliver
a quality software!
Tester
Programmer
Project manager
Other team
members
Estimate of Test/Tester’s Mindset needed for different Roles
@vivienibiyemi
9. If your only tool is a hammer then every problem will look like a nail.
@vivienibiyemi
10. Hence the need to tweak my mindset for different test task.
• Different Task,
• Require Different Lenses,
• Viewed at Different Angles,
• With Different Mindsets.
@vivienibiyemi
15. • Users will experience the product using their 5 senses.
• Human beings are exploratory in nature.
• To help your reasoning about the PUT, gather information
on how the users could use the PUT
@vivienibiyemi
17. • Consider Quality of the testing that was previously done.
• Consider ”pressured tester possibility”.
• We see differently, reason differently and have varying expertise.
• Consider so called ”insignificant changes”
@vivienibiyemi
19. • There seem to be some value in laziness hence the name ”Lazy
Tester’s” mindset tool.
• There are bugs we might never find except we test like the Lazy
tester!
• I don’t have to be lazy but switching to this mindset will get things
done!
• Explore what the lazy tester does. They explore the software
in ways that hard working testers don’t!
• Explore talents in your team. Don’t write off ”lazy testers” –
Test lead Tweak
@vivienibiyemi
21. Sometimes this is what it looks like …!
2. I tested it in unit test and it
works in my environment …I
think it’s a problem with your
environment…3. I found a bug in your
SW, it’s very severe bug…
Tester Programmer
1. The feature does not work
on the build you gave me…
3. Oh, that’sa feature
not a bug …
@vivienibiyemi
24. • It’s my responsibility to make
sure my role is understood .
• I’m here to help, I’m here to
make you shine: Show it! Make
it obvious!
• I’m here to make the
programmer’s day!
• It’s my responsibility to ensure
an atmosphere of common goal.
• My goal is to provide stakeholders
with valuable information hence…
• I do everything morally right to
build a good relationship with
programmers.
• Be a friend but don’t compromise
your integrity.
@vivienibiyemi
25. 1. The feature that you told me
not to test because you already
tested it in Unit test is failing…
2. Oh no, but I
tested it in unit
test…
3. Oh my God this
tester wouldn’t
believe me anymore.
Programmer Tester
@vivienibiyemi
26. • A sceptical approach to testing can significantly improve the
quality of your work.
• ”It’s a minor change, it won’t break anything” is a bait for the
integrity of your work, don’t fall for it: tester, programmer.
• People often say don’t trust a programmer but I will say trust a
programmer but don’t trust the developed code.
@vivienibiyemi
27. • Never commit a code based on ’’it was just a small change, it
will not break anything.”
• Never commit a code based on how good the programmer is.
No such thing as perfect programmer in the world of software
development.
• I let the programmers know I trust that they will do a good job
and I’m here to uphold that trust.
• Though we are tight on time, I appeal ’’please can you give me
more time…?”
@vivienibiyemi
28. • Have the willingness to go the extra mile
• Become valuable, nobody jokes with the words of a valuable tester.
• You can’t afford to test for fun. Let every PUT that passes through
your hand get an opportunity to receive input for improving quality.
@vivienibiyemi
29. • Never ask a tester to merge a code based on ’’it was just a small
change, it will not break anything.”
• Never ask testers to merge a code based on how good you are as a
programmer. No such thing as perfect programmer in the world of
software development.
• Focus on becoming valuable because when you are, people know
that you will always do a good job. It’s OK to find bugs once in a
while in your code.
@vivienibiyemi
35. • 7W+1h: dare to ask why, where, what, what if, which, who, how,
as you test in order to learn, explore or investigate the software.
• Have an open mind. Do not take things for granted.
• Question why certain things are the way they are when they seem
awkward.
• Be a good listener, quietness often helps, think before acting or
asking.
• Pay attention to the “little bit off”. They might be your gold mines.
• Be willing to get out of your comfort zone.
@vivienibiyemi
37. • Those little promptings might actually be important. Do not
ignore especially if it’s an area of risk.
• Don’t get your brain locked up to automated test and
written test cases!They have limitations.
• Shut off the negative ”ifs” learn from the past and move on.
• Think like the user.
@vivienibiyemi
39. A bug report that is missing the head, legs, and everything that could make the reader understand
that what is being described is a bug is like throwing away most valuable treasure.
This act reduces the worth of a tester and robs the stakeholders of valuable information -Vivien Ibironke Ibiyemi
@vivienibiyemi
40. 1. Tester: Bug, bug,
bug...I found a bug!
2. Programmer: Ok,
do you have logs
4. Oh my God this
tester is so annoying
and wasting my time!
3. I don’t have
logs but it’s a bug!
@vivienibiyemi
42. • Never start the PUT without turning on the logging even if you are
”joke testing ”.
• Clear, informative, not unnecessarily worded but convincing bug
report (Bug Advocacy).
• Think like the person who will read and act on the report (include
the head, legs, and eyes of the bug.)
• Imagine how the users will use the feature and craft the bug report
in the same manner
A bug report that cannot be understood is a dent on
the efficacy of a tester’s job!
@vivienibiyemi
43.
44. • You have a composition of varying skills and expertise. We see
differently and we reason differently.
• Identify individuals talents and strength and harness that in
allocating them.
• Never use the same yardstick to measure competence and value.
• Beware of motivation killers: lack of appreciation, unequal
treatment, measuring testers based on how many bugs they find
and programmers based on how many bugs is found in their
code.
• Gain knowledge, target getting best tools on time. Better tools,
better testing, better quality.
@vivienibiyemi
45. • Don’t be a PM pleaser. Tell them the truth.
• Have a buffer. Give feedback and show appreciation. Let your testers
own or be recognized for their contribution.
• Don’t add up resource at the tail end of the project. If you need to, you
must include the learning curve of the new members in your
calculation of how long it will take to be done.
• Be hands-on. Take interest in learning the product and technical
things.
@vivienibiyemi
51. Each of these role must coordinate together and you need a mindset that works
with the understanding of the goals of each role.
@vivienibiyemi
52. Tester: Bug, bug,
bug...I found a bug!
Project Manager:
Come on Tester, today
is release day!
Oh no, this tester
lacks a business brain.
The only thing he
knows is bugs!
Understanding the psycology of each role and what’s most important on time.
@vivienibiyemi
53. • Test with an understanding of the goal of each role on the project.
• Test with an understanding of the cost implication of slipped
deadlines.
• Communicate with clarity of impact on stakeholder’s business:
describing issues from a user perspective is useful a lot of times.
• Advocate for bug conviction.
• Observe valuable evidences to prove the bug guilty and expose the
severity of the crime.
• Find important bugs on time.
@vivienibiyemi
54. Who gets the blame most of the time? It’s mostly the tester
and sometimes the programmer!@vivienibiyemi
57. Tester: I found a major in
your defect in your code, I
will write an defect report!
Programmer: hmmm.. , I
will handle it in a fix that i’m
currently working on. No
need for a bug report.
Oh mine, I must
silence this tester, PM
must not know about
this bug…
Tester:
@vivienibiyemi
58. ”Sometimes life hits you in the
head with a brick but don’t loose
faith” - Steve Jobs
”Your most unhappy customers
are your greatest source of
learning” – Bill Gates
@vivienibiyemi
59. • There could be something valuable in that unhappy face of the
programmer, project manager etc they are your customers.
• Accepting criticism is a path to Mastery,
• Be sure, be alert, record and document things.
• Be willing to accept no for an answer.
• You can be wrong.
• Don’t be loose on your communication. An email could safe your
face!
• Find important defects on time.
• Be transparent, be honest, be cautious. Dare to report issues found
close to release. Dare to find many issues.
@vivienibiyemi
60. ”Don’t let the noise of others’ opinions drown out your own inner voice.
And most important, have the courage to follow your heart and
intuition. They somehow already know what you truly want to become.
Everything else is secondary.”
@vivienibiyemi
62. • Do not easily give up on bugs that you
know can significantly affect quality
even when it's thrown at your face.
• Fight the fight, ensure that you were
heard and understood.
• Don't forget to put some kind
of documentation in place.
• Keep moving, don’t give up!
• It’s Ok to be wrong but focus on
becoming valuable.
@vivienibiyemi
If testing is questioning a Program Under Test (PUT), if testing is investigating a PUT in order to gain useful information about the product’s quality (James Bach) then we can define a tester’s mindset as
Hence all roles in a software development project must cooperate together and everyone needs a mindset that works with an understanding of the goal of each and theirs’.
To keep my mindset flexible and help me look at things from different angles, I put a label on the mindset approaches that I find useful and I call each labeled mindset a ”Mindset Tool”.
: how will they touch, what do they feel and how will they possibly react when they touch, taste, smell and hear sounds from the product.
Often times this is what it looks like
https://cdn.psychologytoday.com/sites/default/files/blogs/36200/2014/05/151746-154990.jpg
There is need to change the mindset on our projects never to perceive people as infallible, we need to stop judging developers by how many bugs is found in their code. It’s the nature of codes to have bugs,
I set up this mindset as soon as I start up in a team. This puts in a lot of confidence in the developers and helps them settle down to do a good job.