Category: TestBash

The 99 second talk I didn’t do – “We are all Humpty Dumpty”

At the end of every TestBash conference there are the infamous 99 second talks. A chance for everyone in the audience who wants to deliver a message to get on stage. For many it’s their first time on stage and a spark for taking the next step.

As I planned for my third 99 second talk, I wanted a message that I can deliver in 60-70 seconds, so that I have time to speak slow and not hustle, like the last times. And I wanted to finish well in time to not loose my conclusion at the end to the nasty sound from Mark’s mobile. And as I’m way more nervous on stage for a 99 second talk than for a normal talk, this time I even prepared my text in advance in writing, not only in my mind. And thanks to the always amazing Damian Synadinos, who generously spent some of his time, I even got an ad-hoc review.

But as I went through it again and again, I always ended up between 90 and 95 seconds. So I decided to skip it and post it here instead. So, this is what I wanted to deliver on stage in Brighton, but didn’t have the guts to do it:

I want to talk a minute about semantics – the meaning of words.
In “Through the Looking Glass” by Lewis Carroll, Humpty Dumpty tells Alice about “glory”, but Alice is confused and doesn’t understand. Alice asks Humpty Dumpty: “I don’t know what you mean by ‘glory'”
Humpty Dumpty smiled “Of course you don’t—till I tell you. When I use a word it means just what I choose it to mean—neither more nor less.”
Sounds familiar?
Closed communication systems like software development teams tend to use words as they like. Which is okay for me, as long as you have a shared understanding in the team. But think about someone new joining the team. Is there ambiguity in your glossary? Is there room for misunderstanding or shallow agreement?

Even if you don’t like discussing about semantics, because you think it’s a waste of time. Try to do it every now and then, try it for yourself if you want. For more complex statements I like to use a technique my good friend Damian Synadinos showed me which he calls “Definition Dissection”. Just take a statement and look up every word in the dictionary. Try to continue by looking up the words that come up in the definitions you found and rearrange them. Continue until you’re happy with the precision.

In my experience, way too often, especially if English isn’t your first language, you will find out that the meaning of the words you use don’t match the intention you use them for.

So you can continue to use them, but being aware that they are imprecise or even wrong. Which will help you when you have discussions with outsiders.

Or you can start to exchange the words you use to get more precision in your everyday language.

It’s the awareness that counts!

And at this point I want to express my deep respect for all that got up on stage and delivered their message! In time or not.

Advertisement

Shift X – Why are testers not happy where they are (put)?

My statement: “Testers don’t seem to be happy where they are (put) in the software development life cycle (SDLC).”

After TestBash Manchester there was an Open Space on October, 22nd. The topic I choose to put on the schedule was “Shift X – Going up- or downstream?” My motivation to choose that topic was that in two talks during the conference we heard – again – about testers on the move.

There is (sadly still) the widely spread opinion and teaching that the testing performed by testers happens when development is done to ensure conformance to requirements before software goes to the customer for acceptance or into production. Testing as an activity is too often underestimated and hard-wired to performing test cases on a finished piece of code. And testers world-wide are trying to leave their profession behind to advance in other roles in the SDLC.

In Manchester I was able to discuss this topic with Duncan Nisbet, Ash Winter, Del Dewar, and Matthew Bretten.

My short summary of the discussion is, “we want to provide more value!”

We split the topic in three areas “Shift Left”, “Shift Right”, and “Where are we now”.

“Where are we now?”

As testers, waiting for devs to finish their work, we might have been able to review or at least read the requirements and prepare our test cases to cover the requirements’ functionality, reporting our job done with pass/fail rates. Do we have influence on the requirements? We can be lucky if we are co-located with the team and not sitting in our silo all by ourselves, not speaking of being in a different country and time-zone. Often we have minimal feedback from production and with that no information about the added value of the feature we just tested. Though we more often than not get the bug reports from production. But does the fact of no bug reports from production for a feature automatically explain that the feature was adding value?

For us it it was relatively clear, that in the position the classical tester is set, the amount of value they can provide is not too much, at least not enough. And what happens when mankind is not happy where they are? They go on the move.

Shift Left

Like the salmons in Alaska, as Duncan showed us the day before, there is a lot testers can provide value with when moving upstream in the SDLC. Our points were to help get a shared understanding of the upcoming stories and start the learning journey earlier. The earlier we provide valuable input for others, the bigger the impact. One rather explicit point was to also start tasks like performance testing earlier to uncover trends in performance before it’s too expensive to change.
There is an urge to show that testing is a valued function and help the team to perform it in the most helpful way.

Shift Right

In approaches to deliver stories faster we enter the DevOps world, where everything is optimized to fast and safe deliveries, where information from production is highly valued. Testers can help to analyze log files, signals and trends on production, to understand better how the product is actually used and deliver these information to decision makers throughout the team.

Shift Out

This approach we didn’t discuss in Manchester, but it’s what we often see in our industry. Testers are looking for ways to provide more value in software development. All too often they move to positions like project management, business analysis, development, and so on. Too often we (the testing profession) loose a good tester that way, sometimes we get a good project manager, analyst or developer in exchange who knows about the benefit of good testing.

Summary

There are many places in the SDLC where good testing can increase value, benefit and quality of information. We, who know that, need to raise the awareness of that fact with testers and all other project participants alike. We need to show testers how they can deliver better value, and get more influence in the development of a project or product. This can happen all the way from an idea (or “desirement” as Duncan called it) to observing in production. And we need to show business analysts, architects, developers, project managers, operations folks, and management, that testers can have the necessary abilities to support all throughout the SDLC, not only in that one spot. That way companies and projects can also provide valuable positions for testers to grow and advance their skills, providing value, being accepted as partners by all, and not seeing the move to other positions as only way to advance.

The five of us, who sat together in Manchester, are in projects and positions where the benefit of testers is seen and accepted. We know that it’s possible! But we also know many examples from our own experience where testers are locked up in the SDLC at the place where we didn’t want to stay.

Other sources on the topic:

Jesper Ottosen wrote only lately about the ways to shift: