The Core of the Testing Role

This is the second of a couple of “The core of X” -articles that give you -my- ideas on what I think of X. The attempt is to cut away all that surrounds the term and show its core for what it truly is. The essence of it all.
Take from it what you will, love it or leave it. In any case, I would invite you to share what goes around in your head and what you feel while reading. Feel free to correct me or engage in discussion. We’re here to learn.


There’s Always Testing

Independent Test Teams, Dogfooding, Bugbashes, agile Testers, Test Jumpers,… or testing by any other name. There’s always some testing going on in a software project. It might even not be called testing, but it’s there.
It’s in those moments of critical thinking just before someone says “hey now, wouldn’t that shortcut our registration process?” or “Woah, I never thought about it in that way.”

When one ‘thing’: a piece of code, a requirement, a document,… is changed and passed from one person to another: that’s an opportunity for doing testing.
This isn’t always done by a professional tester. Au contraire.
Whether it’s a formalized or accidental process, there’s people jumping in and out of “The Testing Role”. Adding value because of it.

“Everyone tests, but it’s a skill not many professionals care to practice.”

The Core of the Testing Role = Mindset + Skills + Attitude

Be you a tester, developer, analyst, schoolboy or astronaut, to take up the Testing Role effectively, you need to be aware of these three different aspects.

Mindset

Most professionals are focused on Building. Adding, accelerating, stabilizing and all that improvement goodness. At one point or another, these professionals will need to test each other’s improvements. Having that builder’s mindset while doing so is a lousy way to go about it. It’s the equivalent of a mom cheering on her son on the football field:

You want to see them succeed. Confirmation bias and inattentional blindness play their part: Your feedback will be limited.

A tester’s mindset is often seen as a negative or destructive way of thinking. It’s focused on Risk. What can go wrong? How can this be abused? What haven’t we thought of?

It’s about thinking differently. It’s about being engaged with the product with the intent of finding problems.

Getting that mindset consistently right is probably the most important part of this role, yet also the easiest to discard. The path of least resistance doesn’t lead here. It goes everywhere but here, with a rather sharp turn.

It’s a Skill

There’s a lot of different skills involved in testing.

  • Critical thinking
  • Systems thinking
  • Modeling
  • Risk Analysis
  • Quick learning
  • One’s own expectations management
  • Inter- and intrapersonal skills.
  • Technical insight

Just like any other craft, it might look easy for the unwitting and unpracticed. To become a master though, it takes hours, days of mindful practice.

Attitude

Don’t care to practice”. That did sound quite harsh, right? It was intended to be. Attitude, to me, is the defining characteristic for a tester.

  • It makes you speak up in planning meetings to go against popular opinion.
  • It has you fighting for a bugfix you think is important.
  • It gives you fresh ideas to go through the same high-risk functionality over and over.
  • It helps you be different in a world where sameness is worshiped.

Just like Mindset, which is about thinking differently, Attitude is too easily dismissed as part of the Testing Role. Being adamant about quality can be perceived as difficult or not-a-team-player behaviour. I’ve worked with many people who don’t want to bother learning about testing for those exact reasons. It doesn’t make you popular.


Recap

Anyone can take up the Testing Role. Whatever else you do, it takes these three things to be successful at it:

Mindset – Thinking differently when looking at solutions and problems.
Skills – Have the tools to analyse, find, plan for and report risks and issues.
Attitude – The resolve to be consistently different and defend underrepresented notions.

Doing that context switch isn’t easy, isn’t evident and takes practice.
While many people do this role & mindset switch daily, most of the time it is lacking. Practice, investigate and learn how to do it well.

Two Conferences of the East

East of where? Why, Belgium of course. Where else would you place the center of the universe?

I’ve written about several conferences before, such as TestBash & Eurostar. It occurred to me that all previous gatherings were placed North of my hometown, that’s to say, until a few weeks ago. A new wind called my name.

After surviving the far and cold North, where I made friends around warm campfires and was taught the dance of ‘socializing while balancing a beer’, my steel winged carriage pointed another direction.
My next adventure lay East. To the haven city of Gdansk and the Transylvanian valley of Cluj Napoca.

I would tell you of my ride across the hills where I battled three packs of wild Romanian dogs, or the dance of fire that initialized me into the ranks of the Polish testing army. But that would be largely exaggerated and are best told at a bar.

None the less:
Two more conferences have been scratched of my bucket-list since then: Romanian Testing Conference & Testing Cup.

18422195_1543969875622917_3589158990241473518_o-900x720.jpg

TestSphere’s workshop: “The Quest for the Ultimate Test Story” in action

The Romanian Testing Conference

Imagine being picked up at the airport in a very expensive Audi. Imagine the driver telling you he arranged a bike for you (you like biking, btw). Imagine that during the ride you oversee a valley filled with houses and old church towers but green hills all around. Imagine a slight hill in that valley with a grand hotel of marble on top.

That’s the first encounter I had with RTC. They had everything planned for me, the bike, the hills, the hotel, my evening dinner and the scenery was groteske. I mean that in the best possible way.

The conference itself was inside the many rooms of the hotel and for several days it was bustling with a 300-400 headed enthusiastic and diverse group of testers.
What struck me about this crowd is that it is much younger and much more evenly distributed across gender. And the hunger for knowledge… Dear lord were they thirsty.

The people I talked to were very eager to hear my stories, were inquisitive, well spoken and remarkable.

I am greatly impressed by the organisation, the participants and the group of speakers that assembled. I would be remiss not to mention I will fondly look back upon the time spent exploring the city with Ard Kramer & Elizabeth Zagroba and Nicola Owen, Mike Noggens, and Keith Klain.

C_pFjsZXcAEcmPC

Andrei Contan receiving his prize for telling the Ultimate Testing Story

Testing Cup

I’m a sucker for Poland. Over the last 3 years, I’ve visited these greener pastures a good 4 times. But this time I was reminded that I had been visiting some of the wrong sides. Gdansk is more modern than any other city I visited in Poland by a long shot.

Upon arrival in the old town I was rejoined with Zeger, Andreas, Ard, Marianne and Johan. From that point on, everything went into light speed. That was the moment the stars became white lines flashing in my peripheral view and the limits of the universe became in reach.

I didn’t look back.

dbyon5xwsaacpiq.jpg

It was the second year that Testing Cup grew larger than ‘just their testing competition’, which was incredible, make no mistake. Last year they experimented with several international speakers and this year they invited a larger group.
As a team we immediately set forth to gather all speakers in a whatsapp in a “got to catch ’em all” kind of style.
This medium was the center of much, much absurd humour and self mocking. I loved it. You may find a selection of shared pictures at the bottom of this post.

Much like in Romania, we found a large amount of young, knowledge-hungry and diverse selection of Poland’s best testers.
They demonstrated that in the competition and in our workshops with witty remarks and colourful stories.

Two particular moments will haunt me until years to come:

The party was a surge of positive energy. Having drinks on the beach, standing barefooted in the Baltic sea, enjoying the view of a spectacular fire show and dancing until well in the night in good company.
The party was amazingly good, which was noticed in the sheer number of attendees that trickled in much later than intended the next day.
The first day we had 40 participants (the cap) in our workshop, the second one we had 9.

Another impression about how greatly the attendees LIVED this conference was all the way in the end when the champions of the competition were announced.
I saw a Software Tester run in the middle of the Gdansk football arena waving a huge golden cup above his head. I imagine he felt like Ronaldo. His face showed pure pride and happiness. The crowd was enamored.

Aftermath

What I witnessed at both conferences was a strong organization and an exceptionally large number of volunteers. Even though it felt like they weren’t there, that’s exactly what their strength was. They supported us, carried us and led us to have the best of times. We didn’t have to worry about a thing.
That’s Joanna Mocko, Maciej Chmielarz, Andrei Contan, Andrei Ghinescu, Radek Smilgin for you.

As a speaker, I recommend these conferences with the highest of regards.
Say hi when you’re there. I will be too.

DCBnkCiXkAASuXt

 

The Core of Automation (Regression Checks)

This is the first of a couple of “The core of X” -articles that give you -my- ideas on what I think of X. Take from it what you will, love it or take offence. In any case, I would love to hear about what goes around in your head and what you feel while reading. Feel free to correct me or engage in discussion. We’re here to learn.

First things first: Language. For this blogpost, when I say Automation I mean a set of Anti-regression checks. Whether they’re on the Unit, Integration, API, UI,… any level, they’re all the same here. There’s usefulness in dividing them by purpose, use or whatever, but it’s not here. I use ‘checks’ where you may expect ‘tests’. That’s fine. The important thing is the point, all else is for a different time.
Behold, das Point:


The core purpose of Automation is NOT about
finding bugs, saving time, getting to market faster or bringing value faster.
It’s about
Stability and Reliability.

Now don’t get me wrong. The red stuff is greatly helped by what’s in green, but it is not and should not be the main focus.

Should your project not care about Stability and Reliability and only about going to market faster or saving time, you can just as well not write any checks.
If you want to find as many bugs as possible, automation is a rather inefficient way of looking for them.

Your checks are about minimizing the risk that comes from working with multiple people on the same thing. Because… inevitably, someone will make an error. That’s human nature. Ideally, you want your Regression Harness (or Automation Check Suite) to warn you of that error. This way, when a team has a good set of checks, it’ll keep a personal “oopsie-doozie” from becoming a whole-team “WHO THE HELL BROKE OUR STUFF AGAIN?!”.

When you engage in any form of automated checking, know that your focus should be on Reliability and Stability. It will lead you down the good path. The one of continuous integration, saving time, having to do less firefighting and having more control as a team.

I’ve seen people talk about metrics of automation and mention: number of bugs found, time saved, number of deploys per day, number of checks ran,…
These are rather unhelpful.
As a Team member, when it comes to metrics, I’d love to outweigh:

Time lost fighting instability + Energy wasted on firefighting + motivation loss while investigating problems + friction between team members
VS.
Time invested in building a regression harness + problems still occurring after the effort + Effect on team-cohesion and sense of purpose.

Hard to do, right? Though it could be better worded, that’s the only metric that counts for me.
(Though I might be interested in the other metrics sometimes, those moments are rather circumstantial)
Notice, though, the difference of mindset of investigating problems as individuals and building a solution as a team.


But… where does Testing fit into that strategy? In my opinion: Not necessarily.

While Testing can certainly help come up with interesting ideas on improving your check harness, it doesn’t have to be part of it. However:

The information that Testing provides from looking for unexpected, extreme and abusing behaviour can greatly support your automation.

I do believe that Testers should make the occasional step into this territory, just as much as I encourage anyone to make frequent and valuable role-switches. Yet the main focus of the Tester role is on providing valuable information that might have been overlooked, the team was unprotected against or misunderstood.
Make no mistake, if your product is rather complex there’ll be things missed, erred and overlooked.

Also… I’ve yet to meet a tester who didn’t think her project or business is simple.


TL;DR:  Regression checking automation is about Stability and Reliability. When done well and consciously, the result can evolve to be: Less bugs, time saved firefighting & problem-solving, going to market faster and adding value faster. A Tester isn’t necessarily an agent in this process, but the information she provides can be invaluable.

IMG_20160725_125941We all need stability. Sometimes more than other times.

Concerned about boxes

Trump, Brexit, Le Pen, The Testing Community, Women in IT, The future of Testers, LinkedIn articles and retweets.

Here’s what scares me the most about recent (and less recent) developments around these examples:

I don’t know who’s making all this happening.
Me, and almost everyone around me apparently share the same views.
Yet there’s an overwhelming number of people working against us.
Who are these people?
Why are their views different and why aren’t we hearing each other?

I often feel like I’m in a huge echo chamber. I keep getting the same things in my twitter-feed, slack channels, fora, mails, magazines,…

As a middle-class, white, European,… , non-religious,… , extravert, male, … , who tries (vehemently) not to be a dick, I look around and genuinely wonder: How could Trump ever get elected? Nothing in the media ever mentioned it to even be remotly possible.
I’m shocked that the UK voted “leave”, because I’d seen nothing but pro-stay voices all day. I’m getting a very one-sided view and it’s not helping anyone.

This happens every day:

  • I glance over a forum thread and think: “This discussion,… again?!”
  • Pull open a Slack channel and see someone replying: “What do you exactly mean by Test Cases?”
  • I click on a link about a new idiotic thing Trump did and can barely keep myself from screaming: “THEN HOW THE HELL DID HE GET ELECTED?!”
  • Open a “Testing is dead” article and find out that it actually means the opposite.

I’m seeing the same thing again and again. I wonder why nothing is changing.


There’s boxes everywhere: Racism is a problem. Sexism is a problem. Classism is a problem. Extremism, in all its different forms, is a problem. Most -isms are problems.
You’d think we’d all know by now. Hell, there’s enough examples to teach us.

But we like hearing the same thing. We like being right and having no conflicts.
Nice, simple, easy. Bliss.

After going through a very painful cynic stage, I realized that I need to get out of my echo chamber more. As much as I love the people near to me, it’s detrimental to all of us should we not pursue diversity. Even the diversity we may not like.

That’s what testing is, right?
Learning new things, new views, new ways of thinking, having a different mindset,
And using that information
To increase the chance of having better ideas, beliefs, thoughts for you
and people around you.

In my eyes, repetition, conformism,  truly is the enemy.
Everywhere.

 


An interesting thought I had whilst rereading: in our testing field, at least we’re having the discussions. We have various media which we can largely control. Fora, slack, twitter,… We should cherish that and draw upon its potential. Find the people we’re not hearing. Find out what they have to say… and learn.

IMG_20160804_124355

TestSphere, The Making Of

The day was 17th of April, 2015 that I mailed Rosie of Ministry of Testing with an idea I had. The question I posed was whether a Testing Tarot Card deck would be something the community would be interested in.

Rosie had thought of something similar before and wanted to work with me on it.

I wanted to create a tool that is generic enough to suit most contexts and can guide testers to find new and exciting ways to approach the product under test.
I started developing something that eventually took the form of a Testing Tarot set.
– Beren

(italics are snippets from actual conversations.)

Phase 1: A Testing Tarot Card deck. – April, 2015

So cards have two sides:
One side is always printed with one/same logo/design.
The other side is printed with the character.
– Rosie

I had already created a list of concepts that would spark inspiration for your testing and connected this with a Tarot-style character.
This is an extract of how that looked:

list

Spreadsheet Keywords – Character – Image description

The next step was finding someone who could draw beautiful characters and designs for the cards.
After contacting several people, we found out that this would be very, very costly.
So we decided to go with someone from Fiverr.com who we’d heard good things about.


After completing about 20 drawings for us, she took 175$ and then vanished into thin air. We had less than half a card deck in a particular style which we couldn’t build on further.
Rosie had invested that money for nothing.

That was the first blow.site

Phase 2: The App – November, 2015

While waiting for the characters to come in, I had created a website to give a better overview of the card deck. This drove me into playing around with colours, logo, icons and a name.
Asking advice from people around me, I found someone who wanted to build this into an app.

To help inspire you, TestSphere doesn’t just give you an objective.
It offers an elaborate explanation of the objective and
gives several examples of how to test the objective.
– TestSphere pitch

 

At that point, we were a year later already. January 2016.
I hadn’t heard as much from Rosie as she was busy with the many other projects. In retrospect, she was right to do so, because I was still searching.
Even if I didn’t know that about myself at the time.


That same month, I was lucky to join 25 other testers on a peer conference: DEWT 6.
I pitched the concept, the website and the app to them.
They felt it had potential, but that it wasn’t quite there yet.

While they were offering constructive criticism, help, support and ideas, I was feeling demoralized. A stone had formed in my stomach.

That was the second blow.

Phase 3: The Card Game – Februari, 2016

Driving home again, I started to get new ideas. Back to basics. A card deck that wasn’t a fluffy fortune telling game, but a useful tool of learning and knowledge sharing.

Again I rethought the list of concepts, form and design of the card deck.
I introduced different dimensions and investigated more concepts to add to the deck. Real, useful and specific test related concepts that have the potential to get testers passionately talking and thinking.

Here’s an example of 9 cards of the first version of TestSphere: pat-3

happycard3

more-concepts

The focus shifted from fortune telling and test ideas to learning and knowledge sharing.


I pitched the new idea at TestBash Brighton as a 99-second talk and that was the moment it got picked up in earnest.
Rosie wanted to get it ready for TestBash Manchester. Marcel Gehlen tested out the game and offered a boatload of feedback.

In total: We liked the cards very much, we have some ideas how we can integrate them in our team / work and we think they add value. For gaming purposes we wanted more rules. If you ever come up with a stricter gaming rule set we are happy to try that out for you.
– Marcel Gehlen

Phase 4: TestSphere – Oktober, 2016

We further expanded on the cards, with examples that approach the concepts from different angles.
A real designer from MoT, Thomas Harvey, joined in and made it look awesome.

3-feelings23-feelings21

This is a product that can be used in many different ways and taps into your experiences, potential and creativity.
Whether you are an experienced developer or junior tester, this game will have you dig deeper and learn from each other.

TestSphere brings out the potential in you.


Phase 5: The Crowdfunding platform – Januari, 2017

We’ve come this far together. All the people who stood by me, supported me and offered advice and work:

Rosie, Marcel Gehlen, Melissa Eaden, Thomas Harvey, Dwayne Slootmans, Bert Lerno, Ben Van Daele and my wife.

Ministry of Testing have invested £20,000 for design, printing and handling.
In order to make that money back, we’ll need to sell about 1,000 card decks.
At the moment of writing, we’ve sold 220.

You can help us take this story further.
Inform your manager, your development team, your marketing team. Get them excited about TestSphere.

Get it at the Ministry of Testing Store.testsphere-15_1024x1024

Phase 6: ???

The App, revisited?
An extension on the Ministry of Testing Dojo, a great library of real life stories?

All we know is, this is far from over. We’re taking this further!

A Tale of Two Conferences

The past few weeks have been hectic for me. Hell, the last 6 months have been.
And it doesn’t look to be cooling down though, with Test Sphere needing a lot of new and uncharted attention.

I take this time to reflect upon the two conferences I’ve had the pleasure of speaking at:
Test Bash Manchester and EuroStar 2016 in Stockholm.

Similarities

The goal for both conferences was to meet as many people as possible, participate in discussions and learn from them, see what the hot subjects are in Testing and introduce Test Sphere to as many people as I can.
I was alone for both, but knew people at each conference. This enabled me to move between groups, but also gave me a ‘safe place’ to return to when fatigue strikes.

I was going to participate in every meetup, every extra activity and fill the glass to the brim.


Test Bash Manchester

I drove up to Manchester. That’s a 10 hour travel from Belgium,but god, England is beautiful in Autumn. Even from the highway you can enjoy the orange-and-yellow branded leaves that fill the landscape.

Once I arrived at Old Trafford, I called Richard and he invited me to join him at a bar.
The plans he and Rosie have for Ministry of Testing are incredible and I couldn’t help but wanting to participate in it.

And that’s the beauty of Ministry of Testing and Test Bash. You feel like one of the organizers. It’s completely up to you: Step up, take any of the chances that are given to you and you’ll be supported by the community to do more and get to the next level.
Test Bash makes everyone valuable. It makes everyone feel like a part of something greater. A community of testers that feels inclusive, open and exceptionally warm.

I drove back in one stretch, arrived late in the evening but still felt energized to last for days. That’s what Test Bash does to me.


Eurostar Stockholm

It’s huge. There’s so much going on I feel I’ve barely scratched the surface.
I stayed in Stockholm for 5 days and try to do as much as I possibly could. But having to choose between 4 different talks left me feeling as if I was losing every time.

The talks I attended were generally very interesting and I’ve taken away quite a few explicit ideas for my day-to-day work and probably more ideas that aren’t as concrete, but will re-surface when the need arises. Especially Alexandra Sladebeck and Liz Keogh‘s talks and ideas resonated with me.

There are so many big names in testing speaking and attending that I was seeing stars. Because I wanted to spread the good word of Test Sphere and looked for a few apostles to do so too, I approached most of them and tried to convince them to do workshops with the cards.
These Testing Stars are incredibly friendly and always up for a chat. They are interested in what you have to say and will give you things to think about.

This is the big advantage of EuroStar over Test Bash: Tons of opportunities and there is a much broader reach.

But this has a negative side too:
There is a central hall where most time is spent. It’s filled with vendors and companies that seem completely disconnected with what’s being talked about in the sessions.
It is my interpretation that this central hall fixates on Repetition in testing and that most talks advocate for Diversity and Variation.
That frightens me. Especially as Jon Bach revealed 50% of the attendees of his talk considered themselves Test Managers.

The late night activities proved to be exactly what I imagined them to be. Good food, drinks, discussions, getting to know each other better and forging relationships.


To summarize

Test Bash made me feel at home, welcomed and valued. EuroStar gave me the impression I was certainly welcome but still a newcomer and was ‘on my way to become a member’.
Both feelings are good. One gives me a safe environment and the other challenges me.

I left EuroStar with many questions and things to consider, such as the state of our craft vs. the state of the testing market and why I want to become a speaker. Test Bash made speaking feel like a natural next step.
Asking questions and introspection are necessary, feeling encouraged is too.

Both conferences offered a ton of ideas to consider and many opportunities to act on. Workshops, collaborations, job prospects and possible sponsors for Test Sphere.

And to the question of “why I signed up to become a speaker in the first place?”, the answer is: People.
Anything I do and want to do well is because of my love for good and honest people.
I need that, in order to feel happy.
I want to move forward with teams and grow everyone around me by any means necessary.
To achieve this, I first have to meet all these wonderful people.

Such as Marcel and Ard:

cvsjwtxwaaa9mwz unnamed

We-Were-Testers

I’m writing this from my hotel room in Stockholm, after attending and conferring at Eurostar 2016. I’ve thoroughly enjoyed it and was able to meet so many different and passionate testers from places I didn’t even know had testers.

But this experience was somewhat spoiled by something completely different.
Here’s a few things that get me all riled up: Pokémon that run away and injustice. (amongst other things)

Today I’m complaining about injustice.

The Context

This injustice comes from a source that I had hoped valued integrity and transparency as much as it marketed to be: We-Are-Testers.com. (WAT)
They provide a service, like many other crowd testing companies, that links a customer with specific needs to a number of testers who are willing to jump at the opportunity to test something new AND make a few extra bucks while doing it.

I welcome this idea as it offers me the chance to do some extra testing, but also get some pocket-money to spend.
This mission, I had two days time to test an application on an Iphone and come up with linguistic issues in it.

Pretty easy right? Especially because all the Dutch text I had to review seemed to be copy pasted from a Google translate service.

However, some constraints hindered me: Only two days of testing were foreseen and the first day I spent an hour trying to install the app, only to find out the configuration of the install thingy didn’t work for me. An admin from WAT had to correct this for me.

The second day I was able to test for two hours before the deadline.
I logged 18 bugs, which would amount to maximum 144 EUR.

how-to-report-bugs

All required fields were filled in, as per agreement. Steps, expected outcome and actual outcome were all given as well as any other required fields. (How else would I be able to submit the bug?!)

Later, the next day, mails came flying in. INCOMPLETE, INCOMPLETE, INCOMPLETE.

Wait a second, there seems to be something wrong…
I hadn’t included screenshots.
Ok, I agree that a screenshot is pretty handy to have in most bugs.
HOWEVER, in this context, with two hours time to find as many bugs as possible, making, uploading, downloading, linking,… screenshots would heavily cut into my bug-finding time.

Steps, the name of the screen where the bug was found, the actual text and what it should become had to be more than enough for meager text issues.

In any case, for the three hours of work I wouldn’t see a penny.
And me being me, I kind of want to make a problem out of that.

Gathering evidence

payment-policy how-to-report-bugs

The Discussion

I contacted the moderators and spokespeople from WAT, who are generally really nice guys and girls, to ask them to look into my situation.

Argument 1: Their website’s “Payment Policy” doesn’t mention Screenshots are a requisite for payout. It specifically says attachment only if relevant.

Argument 2: The mission’s “How to report a bug” doesn’t mention Screenshots are a requisite for a complete bug.

Argument 3: If Screenshots are a necessity for this project, please please please make the input field for screenshots a required field?

This is a clear miscommunication, so I gave them time to find out how they’d handle my situation.
Today I heard that I wouldn’t get a dime for my efforts, that it was unfortunate but that it was virtually my own fault.

reply

My point is not whether screenshots should or shouldn’t be added to bugs.
My point is that WAT is telling me I should not be paid because I didn’t adhere to a rule that I can’t find anywhere in their Terms of Agreement, Payment Policy, FAQ or Mission Description.

They did offer four extra hours to insert the screenshots. At noon. While I’m at work. Thanks a lot!

They argue that the devs need screenshots, but frankly, that’s not my problem.
WAT provides a service to the devs. I provide a service to WAT.

WAT should carry the burden of handling communication errors on their part,
And I shouldn’t be the one to suffer from the gaps they leave.

I’m pretty sure those bugs will be fixed in the next version. But regardless of that, not paying people because of rules applied by a third party seems kind of illegal to me.

If you don’t agree, let me know.

remuneration

Consult the TestSphere

Last Friday was TestBash Manchester and I’ve enjoyed it thoroughly.
The talks are inspiring, the organisation is impeccable, facilitators are the friendliest people ever and then there’s the people that attend:

All these speakers, listeners, organizers, attendants,… make you feel right at home.
They are what make every edition of Test Bash legendary.

This time, I got the privilege of meeting a whole ton of them while handing out a new card game Rosie and me put together.

testsphere

 

TestSphere: The tool

TestSphere is an idea that has been worked on for two years, has seen 5 different implementations and eventually came alive as a 100-card card deck.

A hundred cards, each featuring one keyword that has something to do with testing.
This keyword is further explained with:

  • A category:
    • Quality aspects
    • Techniques
    • Heuristics
    • Patterns
    • Feelings
  • A slogan
  • Three examples of how this keyword could impact your testing

That’s it! One hundred cards full of test-vocabulary and inspiration.
Can you already imagine how you could use that?

testsphere

TestSphere: The Ice Breaker

Step 1: Spot a lone tester
Step 2: Walk up to them and draw a random TestSphere Card i.e. “Equivalence Partitioning”
Step 3: Ask: “How has “Equivalence Partitioning” affected your testing? Do you have a story or experience to share about that?

What follows is that person thinking a few seconds and eventually give you an interesting story that is the beginning what possibly is a good discussion on that keyword.
Another thing that could happen is the person not understanding what you mean. This gives you the opportunity to practice explaining your testing.
Either way, you’ll have started a discussion where you can coach, teach and learn at the same time.

Additionally: Just keep the cards on your desk at work. Developers, Business people, Managers who come to your desk will say “Ooh, shiny colours! What’s that?”.
Before you know it, you’re teaching your coworkers a thing or two about testing.

testsphere

TestSphere: The Game

Step 1: Find a group of 4 to 8 persons
Step 2: Divide the deck by category (20 cards each)
Step 3: Depending on the experience of the group: reveal one or more cards
Step 4: As soon as one person can think of a story that features all revealed cards he or she knocks on the table
Step 5: Tell the story
Step 6: This person takes the revealed cards as full points
Step 7: Other people can also tell their stories to get unrevealed cards for half points.

The person that gets X points first or most points by X time wins.
Easy right? You’ve just gotten a whole group of people thinking deeply about their previous testing experiences and put those experiences to verse.

Additionally: After or even during the game identify opportunities for coaching and helping the others. Point them to resources or people who might help them get more insight.

testsphere

TestSphere: The Unblocker

So you find yourself bored, blocked, sad or stuck?
The best thing you can do at those times is learn something new.

Draw a random card.
Can this idea infuse your testing in a new way?

  • Have you tried the “too many” heuristic?
  • Have you tested the “Accessibility” Quality Aspect?
  • Could you try doing some “Pair Testing” Techniques?
  • Try exploring your product by applying “force” in creative ways.
  • How would an “Irritated” or “Angry” user use your application?

Additionally: If you don’t know the word on the card, or feel you don’t know if well enough: try to find more opportunities of learning about the concept!

testsphere

TestSphere: Unlimited Possibilities

Job interviews, Brainstorming, Lean Coffee, Analysis tooling, Visual connecting concepts together, Exploring opportunities for personal growth, Storytelling without using keywords, Generating random Test Persona, Re-categorizing the whole thing and connecting the words using different logic,…


TestSphere has been deliberately kept free from rules. I believe testers are creative enough to find use cases on their own and decide for themselves which ones are valuable and which are not.

The only constant is learning from stories and experiences. From your own and from those around you.

We’re not quite ready for mass distribution. We’re still feeling out the market.
However, there will be an option to pre-order one or more decks in the future.

Be sure to hear about it at: @TestSphere

cvxoqo7xeaanmez

Software Intelligence

In preparation for my Eurostar Conference talk, I’ve been researching quite a bit into learning behaviour, experiential learning and social behaviour. More CGJungspecifically, the ideas of: Jung, Piaget, Dewey, Lewin & Kolb.

Each on their own they already offer a wealth of knowledge. Combined… well, it’s been an interesting year so far. So much information, so much to process.


This post is not about what I’ve learned, it’s about what is currently going through my head and what I need to put to pen.

Reflection

Triggered by all that research, I’ve been doing a lot of introspection lately. Who I am, what I want to achieve, how I fit in the project puzzle and what I find important in my working environment.

Some examples of recent milestones that pushed me to my current mind-set:

  • My fellow tester and me have both done an MBTI test and discussed the pains and gains of our professional relationship based on the results.
  • During retrospectives we’ve been asking directly for feedback of how the team might benefit more from our efforts.
  • A team member called me ‘just a tester’ and I had to tackle that. Even though it was said ‘in good fun’ you can’t accept such remarks lest they become reality.
  • I’ve made a list of all the activities I do, how important I think they are, how important I think they are for the team and how much time I spend on them.

The result of that list is that I spend 1/3rd of my time on actual testing. Another third is spent supporting the team in various ways: Communicating, coordinating, prioritizing, delegating, increasing involvement for team members,…
The last third is reserved for change management, monitoring, communicating with business and more activities that are more business and project management facing.

Am I a software tester? Absolutely.
Am I an important point of contact for business? Yes!
Am I a team psychologist? At times.
Am I a coach, quality advocate, release manager, gatekeeper,… ? Yes, whenever the project needs me to be one.

What do you call all this?

This way of thinking leads me to believe that Software Testing is not the best way to describe our efforts. At least, for my current context it isn’t.
Every day I ask myself: “what can I do today, that brings the most value to the team I can possibly achieve?”. The answer to that question is only 33% of the time: Software Testing.

Personally, I think my role would better be described as Software Intelligence.
A person or team with a wide range of skills that changes and adapts to achieve its core mission: “finding important information quickly”.

This draws a parallel with Military Intelligence. An organisation that uses absolutely any means necessary to get the information they need in order to report to decision makers.
They have people in the field, machines that are monitoring, recruits from outside groups that help them and work closely together with other military defence organisations…

Similarities

Software Intelligence is a group of activities that encompasses Testing, Checking and any other tasks that fall on you in your current context.

For example, I have scheduled contact with a person from business who plays a big role in how our product is perceived. During those meetings, I’m mindful of the information I give him, as too much might influence his perception of our work and I try to gather as much information from him by (hopefully) asking the right questions.
I’m the spy who contacts the informant.

Another one. Through the network of users who favour me, I’ve come to know about a big and mysterious problem in production. A quick fix was rolled out, but we have no idea what caused the issue in the first place. For the time being we installed a lightweight but reliable monitoring tool that alarms us when action is required.
I’m the creator of a monitoring satellite.

There’s plenty of other parallels and probably some differences too.
However, Software Intelligence makes a lot more sense to me.

I’m not advocating for a large scale shift of job titles, we don’t need that. I only feel that Testing as an activity is a big part of my job, but that Tester doesn’t correctly describe my role in the team.

When I listen to and read many stories of other testers, I’m inclined to believe many are in the same situation.

homer-intelligence

Are Test Cases Dead (…yet)?

It’s been a while ago since Rosie asked us this question. (http://www.ministryoftesting.com/2016/04/test-cases-dead-yet/)

You can find multiple answers there from testers around the world and the sheer number and diversity of answers continues to baffle me.
Ask any tester for a definition or an explanation of what she does and you’ll get a different answer.

The same is true for designers, developers, analysts and probably any job that requires intellectual and creative thinking.
But why are we different? I don’t see any people in other roles questioning the definition of their craft, or pondering how they should explain themselves to others.
Yet we do so on a weekly basis.
Every week there’s a new blog post, Tweet, Slack discussion or Forum thread about who we are, what we stand for or should stand for and how we can explain or do things differently.

I’m no exception to this. I’m searching for my own answers, trying out different things and experimenting with what I can find or come up with myself.

Are we so misunderstood and mistreated that we have to devise new ways and machinations to seem valuable and become respected? Some of the practices we still cling on to have mutated over the years and have become fetishes.

I have come to believe that Test Cases are such tricks.
To me, Test Cases are a step by step description of a scenario, and in the end an expected result.
Someone, somewhere, needed a way to present the work of his or her testers in easy-to-swallow, countable pieces. That’s nothing preposterous. If you boil it down enough, (and forget all the interesting stuff) testing becomes an overload of information in this scheme:

“If someone does X, Z happens.”

Which is the lowest level possible of an requirement, user story, expectation, or whatever you wish to call it.
Essentially, you get a huge list of check results, but with the actual outcome, instead of an expected.

If you look at testing this way, Test Cases make perfect sense.
Additionally, over the years Test Cases have gotten many different reasons to justify working with them.

  • Newby testers can execute them and learn from them.
  • They can be used to document the product.
  • They can be used to manage the state of the product.

I, however, think they’re a special kind of torture. If ever I get sent below to do the devil’s bidding, it won’t be an apple just out of reach that torments me. No, it’ll be a Test Case management tool that never gets filled.

Over the past projects I’ve participated in I’ve frequently been asked to do Test Cases. Here’s a couple of experiences:

Project 1
Problem:
Testing of a Healthcare device that freezes mid visit. They asked me to analyze the documentation, create test cases and then test to reproduce the error.

I ignored these instructions, simulated a visit on the device and found the error 5 minutes after getting my hands on the tablet. Test Cases were filed afterwards and never read.

Solution:
The combined testing effort for this project was 0,5 day. The only thing I contributed was providing information on where a most critical bug that was threatening the project could be found. Nothing more, but I did it in a couple of minutes.

Project 2
Problem:
Project was failing, product was riddled with bugs. They asked me to analyze the documentation, create test cases and then test to find as many bugs as possible.

I ignored the instructions, started exploring, learning, modeling and logging all the bugs I encountered. When I thought it was needed, I documented some behavior in Test Case format. The Project Manager was happy, but that’s about all I have to show for the effort of writing those scenario’s.

Solution:
We found all kinds of bugs fast and were able to rapidly learn what was important to the client.

Project 3
Problem:
Project was failing. There was a severe disconnect between Users and Development team. No testing was done and when the client saw the product for the first time, it was a fiasco.

I was asked to read documentation, write Test Cases, test and log bugs.
However, in this case, the firm I was working at would get ‘points’ for doing any of the following per module: Write Test Cases, Execute Test Cases and Provide a Test Report. The more points we got, the more we could bill.
We put in an immense amount of time to create the scripts and making them executable. Afterwards, we’d pass/fail them in such a way that it’d be enough to get the “done” state and get the points.
In hindsight, we put in a lot of effort to adhere to rules that brought us no extra value except for the analysis work we did.
We could’ve worked faster and better if we hadn’t had to invest time and energy in a task that brought us nothing.
Oh, and yes, we’ve had newby testers and users execute the scripts. The format taught them nothing except to follow a script. They did not know WHY they were doing them.
The things used to manage the state of the project, were the important bugs.

Solution:
What eventually brought success to the project, was a close understanding and coalition between business and testers.

My Conclusions.

I have yet to come across a context where Test Cases are the single best solution to a problem. In my experience, they divert from the essential tasks.
Rapid information gathering, learning and reporting combined with good working relations with your stakeholders trump just about anything else.

When writing scripts I feel brain-dead, a monkey doing monkey’s work. It feels like I’m wasting my time. I know nobody is interested in the scripts themselves. They might feel more assured if there are several Test Cases, but that’s a false sense of security.
And I haven’t even started executing them. Imagine having to do half a day’s work by a step by step instructional script. Again and again. Day after day.

I want to be a creative, intelligence worker that has my stakeholders best interest at heart. I want to protect them from unwelcome surprises and support my team to deliver true value.
I want my way of working to reflect those goals, to hone and to strengthen them.
Be it in Charters, Mind Maps or Checklists.

Test Cases are dead… to me at least.


bring-out-yer-dead