BugCoin

Experience Reports, Software Testing

Bitcoin has been around for some time now. In a nutshell: it’s a currency that is generated by software which was created by humans. It consists of 0’s and 1’s and is only as valuable as people deem it to be.

288_european_mantis_cf1 Guess what! So are bugs! Hopefully, they weren’t generated on purpose though… but they can be extremely valuable as a currency. Treat the following as a heuristic, it won’t work in every project and in some contexts it might even be hazardous.
It’s usually better to report bugs in a dry, clear manner while keeping the stakeholders feelings in mind. It’s important that you don’t antagonize anyone on your team, for that will impact your testing for the worse.

Sometimes, however… There’s moments and situations in which it is helpful that you have a certain power to influence the bug-flow. Either by increasing the priority, describing the bug more clearly so it gets picked up earlier, having someone implement a quick fix as a favor… There’s a ton of ways to influence this bugaboo and people might benefit from it. Sometimes you find your pockets bulge with BugCoin. Whilst pondering on this concept I found that I have:

  • Bartered bugs as salesware on a market in order to adhere to contracts;
  • Have complex bugs fixed fast as a powerplay show to prove effectiveness;
  • Pinned high amounts of bugs on a wall to show problematic quality;
  • Used bugs to get buy-in with stakeholders.

Most of the times, the easiest way to show added value as a tester is by finding important defects fast. There are cases where your insistent searching is dismissed as it being “just-your-job”.
Showing a handful of BugCoin can sway many people, just make sure they know its value. In my currenct context, this is how we get things done. Today I spent a few hours searching for a mysterious bug for the accounting department. I’ll make sure they’ll know where that coin came from. 😉 I’m sure this will come in handy sooner or later.

Kolb’s Testing Cycle

Software Testing

We’ve all been done a terrible wrong.

I wasn’t born at the time, but it must’ve been somewhere in the 60’s, when the first ‘software tester’ was named as such.
How did this came about? I can only imagine.
As so many innovations it was probably a scheme to make money where there wasn’t initially any.

From the first tester on, us professionals were branded “Tester” and no finer name exists. Because Testing is such a broad an interesting concept, that it’s really more of an aspiration, a goal than a thing you can fully master.

BUT! Somehow, through time, in people’s perception, the word “testing” degraded. Is it because it is associated with unwelcome surprises? Is it because everyone sometimes does it and can do it? Or maybe testing doesn’t invoke much imagination, digressing in a ‘checking culture’?

Testing is in the same league as “Playing”. A child can play with blocks and dolls, a group can perform a play at a theater. Everyone can do some form of playing. Sure, not everyone can play the piano. Everyone can learn though, if they are willing. Learning, just as testing and playing, is key.
This is an important similarity I would like to make.

Learning and Testing

One can not test, if you are not willing to learn. One can not learn if you don’t test.
They are not exactly the same, but they are immensely congruent.

Testing and learning have virtually the same process.
The chart in this post visualizes Kolb’s Learning Cycle and is part of every teacher’s education.
Everyone, while learning, is considered to go through each of the four stages.
You can begin at any stage, but will eventually complete the cycle. You’ll also spend more time on one or two of the stages as that will be your personal preferred learning style.

learning-kolb

 

 

I’m more of a do-er, focusing on Concrete Experience. This is how a typical test cycle usually goes for me:

 

1. Get hands-on experience with the product;
2. While or afterwards create some kind of mindmap of what I experienced;
3. Analyze where and how I could important defects fast;
4. Go back and find those buggers..

See how Testing and Learning go entwined? We could be named ‘Software learner’ or ‘Software player’ just as well. However, neither of those evoke any more awe than ‘tester’ in the general perception.
Personally, while I can’t effectively master testing as a whole, I can learn about it and hope that one day, I’ll be truly worthy of the name “Tester”.

We’ve all been done a terrible wrong.
We’ve been given a job title we can’t possibly fulfill.

 

Motivating intelligence

Software Testing

“Even if you’re not a teacher, be a teacher”
-Tim Minchin

Teaching, Learning, Mentoring, Listening, Coaching, Advising.
These continuous verb forms are ingrained into the testing field so heavily, it feels as if it is the single most valuable skill a tester should have.

A willingness to learn and to question, is perhaps more valuable than the cliché ‘attention to detail’ which you find on the top of 90% of testing vacancies. This latter has shifted a bit though, to automation.

As a youth, I aimed to become a teacher of English and Informatics to educate teenagers. During the few years I spent training to become a classic teacher, I found myself growing ever so bitter against the current school system. After a few years that kept me tormented over either “pursuing that certificate and walking between the lines” and “Quitting, but facing a life of uncertainty”, I passed a milestone. That milestone being a second consecutive fail.

It felt as if I had lost everything, but freed me up to take matters into my own hands.
That’s when I came into testing.
Where I felt imprisoned in the academic world, I found a second wind in the private business.

Freed from curricula and exams, you can pursue just about anything. Drop it, leave it some months and pick it up again, however you like.

I believe I’ve gotten in contact with many more intelligent people, who are willing to share knowledge, learned more and studied more in a year of working, than my 4 years of higher education.

The choices trap

There are many people who face a lifetime of possibilities. I believe it is a sickness of today, that we raise our children to always keep our options open. I believe in shutting doors. We can’t progress if we can’t find peace in choosing.

A few months ago, a friend asked me to contact his sister, who found herself in the same situation I was in. I haven’t ever seen her, but since last December we had regular contact through mails and skype. I sent her books, gave her exercises and followed her progression, giving feedback on anything she sent my way.

She’s been working as a test consultant for a month now. I was ecstatic! It felt good to give back.

Per Sholas, Speak Easy, Weekend Testing, uTest, Software Testing Club… Are organizations that are focused on teaching and learning both, specifically for software testing.

Whether you find yourself in the same situation, you can reach out and you will be helped. It helps when you try to produce literate sentences and expect only as much time from others, as you put in yourself.

If you wish to enter the Testing craft, but doubt you’ll like it/have the qualifications/need help with a job interview, don’t hesitate to contact me.
You don’t need paper to prove your intelligence, you need only demonstrate it.

 

The Team Concord Triumph

Experience Reports, Software Testing

At the current project we face plenty of challenges. The staunchest is probably that the team can’t adhere to deadlines and management can’t get a grasp on the ‘why’ of it.

We move in bi-weekly sprints, working toward a deadline that has been set by… well… someone higher up, based on something they know that we don’t. I suppose.

I don’t mind tight deadlines. They can be a valuable tool, if used responsibly. But be aware that there’s a great many horrific problems with deadlines, if they are not.

  • Frequent tight deadlines aren’t real deadlines anymore. They don’t represent anything anymore.
  • To whom is the deadline important and what for? We don’t know. Do you? Tell us!
  • Why should the team care? Tell us!
  • Too tight deadlines diminish hope. Too loose deadlines encourage sloth. Are you willing to bet on hitting that sweet spot?

It’s not the lack of respect for deadlines that’s the problem though. It’s the perception that the team doesn’t work hard enough. Not hard enough to match the expectations.

Right now, in my context, these deadlines are used as a heuristic. They are there, just like the time registration, the burndown chart and some other, less popular, procedures to keep track of one thing: Time.

It is believed, that if management can get a hold on time and apply the right amount of pressure, the team will function at 100%. That being 8 hours a day, constant coding.

I find that there are at least two things wrong with that approach.

1. A team’s productivity and motivation isn’t intensified and certainly not sustained by having your team under the pressure of having to adhere to rigorous charts and metrics.
2. A focus on time will result in less qualitative work and the team as a whole will eventually suffer.

If taken too far, these procedures produce nothing but a beating stick, fearfulness and extra time spent cheating the system.

And boy, can you cheat the system. We’ve all seen those movies in which a tyrant tries to find a certain person or group but his seemingly faithful subjects work against him and hide the lot?
It’s somewhat like these movies, a whole team can support, carry and submerge each other’s discrepancies.

Needing to help someone, having to fix your local environment, being called to a quick meeting,… All are good explanations on why you weren’t able to finish that task. It’s a sign of a good team when all its members protect each other.

Facing this challenge, my advice would be to find another way to motivate (like stressing the value their work brings). Or suggest to do some expectation introspection.

As a tester, you can find subtle ways to influence this situation. During planning, I point out all the little stuff that is overlooked but carves daily chunks from your schedule.
When asked the question: “How long will you need to test this” (which is asked still way too often) I answer that “It depends on many uncertain parameters”, of which I then give the shortlist: Quality of the product, availability of developers/functional people, the stability of the environment, # time available at the time, # of bugs found,…

Slowly, but (hopefully) steadily, awareness will grow that there is a great lot more to software development than writing code. We’ve got this team that more resembles a group of friends. That’s a great basis to work from.

Tasting Let’s Test’s Rock Legends

Conferences, Software Testing

Smokescreens, AC/DC and a semi-headbanging James Bach.

This is how this edition of Tasting Let’s Test Benelux was introduced. Picture it.
I found this to be the catalyst for the day that followed. A conference took place of which an energetic crowd, a rock-n-roll setting, a ‘Testing laboratory’ bar and local talent were its primary ingredients. I reveled in their knowledge.

Harmony in the Testing-Checking provocation

There’s much to read about the distinction made between testing and checking. Mostly, when James Bach and Michael Bolton talk or write about this subject there is an unspoken, unintentional subliminal message that Checking is Testing’s smaller, less important brother. In his opening Keynote, James wished to address this. Which he did marvelously. By taking the distinction a step further and mixing it up with deliberate and spontaneous checking/testing he explained that checking and testing both happen constantly during testing sessions. Neither are of less importance. They are both inherent to our testing.

He demonstrated this by replaying and commenting on a testing session. He called this phenomena a ‘testopsy’ which in itself was an enlightening way of evaluating/training testing.

The devil’s machinery

I’ve played quite a few “tester’s favorite games” since the day James Bach conjured up his bags of dices. These did not prepare me, however, for puzzle 17. James Lyndsay has, next to a certain rock icon flair, a wicked intelligent mind, which I suspect, he only uses to devious ends.
… and teaching.

I spent 90 minutes on a puzzle with four inputs and two outputs. Later on, it was made clear that the puzzle consists of 3 lines of code. Moreover, some people had solved the puzzle in under 5-ish minutes.
It took me four different models of visualization, five pages of notes and uncountable discarded hypotheses, before I managed to solve it.
“Of course”. After solving a puzzle, everything immediately becomes apparent, simple even.

It is, however, the struggle that teaches us the most. Lyndsay framed this process so well that I didn’t feel too bad about spending as much time on a, in hindsight, easy puzzle.

These are but two experiences from a day filled with pleasant interactions, new people and refreshing stories.
Thank you!