This presentation is a set of tools that has helped me during my personal journey as a tester. These tools have help me grow in my reasoning about the challenges I’m faced with on my daily task. My way of reasoning evolved into a set of tools that I refer to as ”My Mindset Toolkit”. Hopefully they can be helpful for some of us.
Good Stuff Happens in 1:1 Meetings: Why you need them and how to do them well
Developing and Sustaining a Tester's Mindset
1. Presenting:
Vivien Ibironke Ibiyemi
@ European Testing Conference,
February 9-10, 2017, Finland
Twitter: @vivienibiyemi, Linkedin: Vivien Ibironke Ibiyemi, Facebook: Ronke Ibiyemi
Email: ronkeibiyemi@gmail.com, vivien.ibiyemi@houseoftest.se
2. A way of reasoning that determines behaviour, outlook and
mental attitude of a tester, programmer or project manager
towards testing of PUT(Program/Device Under Test).
@vivienibiyemi
3. The reasoning that is needed in questioning & investigating
the PUT.
@vivienibiyemi
5. Everyone working with the PUT needs a level of test 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
6.
7. Delivery of a quality software starts with each role recognizing
the importance of contributing their quota to testing.
8. The question I ask myself from time to time is how can I keep
growing my test mindset and reasoning?
@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
16. • 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
18. • 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. But I need to test it.
Ok…
I sent you a link to a build in,
can you just review in git and
merge to master branch.
Oh my God this tester
wouldn’t believe me
anymore.
There is no need to
test, I only made an
insignificant change.
Programmer Tester
21. • 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
23. Often times this is what it looks like …!
No, I tested it in unit test and it
works …I think it’s a problem with
your environment… oh I see, that’s
not a bug, it’s a feature.
I found a bug in your SW,
it’s very severe bug…
Tester
Programmer
The feature does
not work…
Oh, that feature, … it’s
not implemented yet…
@vivienibiyemi
26. • 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
developer’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
developers.
• Be a friend but don’t
compromise your integrity.
@vivienibiyemi
27. I found a bug, in the same code that
you said you tested and I shouldn’t
bother testing.
Oh no, but I tested
it in unit test…
Oh my God this tester
wouldn’t believe me
anymore.
Programmer Tester
@vivienibiyemi
28. • 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,developer.
• People often say don’t trust a developer but I will say trust
a developer but don’t trust the developed code.
@vivienibiyemi
29. • Never merge a code based on ’’it was just a
small change, it will not break anything.”
• Never merge a code based on how good the
developer is. No such thing as perfect
programmer in the world of software
development.
• I let the developer 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
30. • 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
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
36. • 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
43. Tester: I found a major
failure in your code, will
write an error report!
Programmer: hmmm.. , I
will handle it in a fix that i’m
currently working on. No
need for a bug report.
Oh my God, I must
silence this tester, PM
must not know about
this bug…
Tester:
44.
45. ”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
46. • There could be something valuable in that unhappy
face of the developer, project manager etc
• 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 issues on time.
• Be transparent, be honest, be cautious. Dare to
report issues found close to release. Dare to find
many issues.
47.
48. • 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:
• Gain knowledge, target getting best tools on
time. Better tools, better testing, better
quality.
49. • 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.
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 in time is needed.
53. Tester: Bug, bug,
bug...I found a bug!
Programmer: Ok, do
you have logs
Oh my God this tester
is so annoying and
wasting my time!
54. • 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.
55. ”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.”
56.
57. • 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.
58. Who gets the blame most of the time? It’s mostly
the tester!
59.
60. 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
61.
62. Tester: Bug, bug,
bug...I found a bug!
Programmer: Ok, do
you have logs
Oh my God this tester
is so annoying and
wasting my time!
63. • Never start the DUT 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!
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 I will say the tester’s mindset defines how a tester, programmer, project manager adapts his or her mind or reasoning in relating with the testing of the PUT (Program /Device Under Test) and every thing that is connected to its development like test activities, programmers, project managers, team members as etc
It requires:
the tester continuously answer the question ”how do I want to relate to the PUT and everything connected to it’s existence (including humans) in order to effectively provide valuable information that’s needed for making decision about the quality of the PUT”.
the programmers, test lead and project managers to continuously answer the question ”how do I want to support testing thereby enhancing release of a quality product?”
Project manager: https://www.projectsmart.co.uk/img/project-manager-blackboard.png
Reasoning: http://bankers-adda.com/wp-content/uploads/2015/04/Reasoning-2.jpg
Programmer: http://www.improgrammer.net/wp-content/uploads/2015/05/Best-Programmers-Of-All-Time.png
http://www.geekpause.com/upload/2015/11/clever-programmer-2.jpg
http://cdn.techgyd.com/2015/02/programmer.jpg
New
https://cdn3.iconfinder.com/data/icons/medical-8/512/mind-512.png
https://upload.wikimedia.org/wikipedia/commons/e/ed/Got-an-idea.png
Imagine a relay race, a baton that drops or is handed over in pieces. It takes time for the next runner to pick the pieces. That’s how testing is. For every loose document, bad requirements, bad codes etc, the consequence trickles down on testing and it takes time to pick the pieces and quality is at risk for each of these. The tester is expected to fix it but remember we have varying expertise and skills.
http://l.yimg.com/uu/api/res/1.2/75UasY3nD2.._3PiYm0c_g--/dz0wO3NtPTE7YXBwaWQ9eXRhY2h5b24-/http://media.zenfs.com/en/homerun/feed_manager_auto_publish_494/61becfc3da3db2738d9abe9d92f51642
http://i.dailymail.co.uk/i/pix/2016/08/18/16/375E06EF00000578-3747226-image-a-26_1471534174221.jpg
https://static01.nyt.com/images/2016/08/19/sports/19RELAYweb2/19RELAYweb2-superJumbo.jpg
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.
Curiosity is a quality related to inquisitive thinking such as exploration, investigation, and learning, evident by observation in human and animal species.
7W +1h: works better in continuous integration?
Mind map the 7W+1h and answer the questions.
Story:
Issue found and was to be discarded. ….
Inquiry learning: http://sybasigns.com.au/images/products-poplets/questioning-word-wall.jpg
What, why etc: https://www.ksvpro.vn/media/blog/7baaeb1d987b7b49b81f98ee8f5599c6.jpg
Curiosity is a quality related to inquisitive thinking such as exploration, investigation, and learning, evident by observation in human and animal species.
7W +1h: works better in continuous integration?
Mind map the 7W+1h and answer the questions.
Story:
Two scenarios of use:
1. when I find bugs
2. Testing without requirements.
Inquiry learning: http://sybasigns.com.au/images/products-poplets/questioning-word-wall.jpg
What, why etc: https://www.ksvpro.vn/media/blog/7baaeb1d987b7b49b81f98ee8f5599c6.jpg
Two scenarios for this:
1. when you get a new piece of software.
2. When you find a bug that is been discarded but you think it’s important.
Bug, bug, bug, bug...I found a bug!
Stories: Melisa in AK98 and Melisa in prismax new group.
Mike’s handling of me and the other team members meanwhile I had more difficult task.
Adding people in the middle or tail end of a project.
Root cause analysis
Bug, bug, bug, bug...I found a bug!
Bug, bug, bug, bug...I found a bug!
Look for reference
Bug, bug, bug, bug...I found a bug!
https://www.youtube.com/watch?v=brpkjT9m2Oo (fixed versus growth mindset)