Language as a medium

Software Testing

Communicating is one actor, the sender, trying to get something across to another actor, the receiver using any possible medium.
That “something” is the message, undefined as it is. This complete procedure is completely dependent on both of the actors, not just the sender or receiver.

There are tons of reasons how this can go wrong. I.e. emotional and attitudinal barriers can interfere.
Only a day ago I had to cool down a heated discussion between family members. A discussion that started largely because one person understood a word to mean one thing, while the other party meant the other.

Language and any form it comes in, (spoken, written, body,… language) is a very liable to miscommunication. Think about emoticons. These filled a huge gap in the Instant Messaging mania a decenia ago. Before these small yellow faces reared their expressive heads, kids would lose BFF-status because they couldn’t add a :), and a 😡 was interpreted.

For language to work you need both the sender and the receiver to try their hardest to interpret the message as it was meant by the other party.
Even then, other stimuli and  noise can derail communication between the two.

This became, again, painfully clear this past sprint.
Context: Since deadlines are still king, and teams are ought to focus on “what’s visible for the customer”, other important non-visible tasks are postponed. This included Unit Tests and ‘focus on quality’ in all forms.
My two colleagues and me, who do all of the testing tasks, weren’t all to happy with this decision. We informed management that, if focussing on the deadline and trying to reach it by neglecting quality tasks, risk would go up, quality would go down and more time would have to be investing in righting a product that was built timely, but crooked.
They understood, but stayed on course. Straight ahead but slightly starboard to those rocks on the horizon.
Language had failed.Bugboard

We saw only one thing we could do: If we fear for bad quality, we have to find out just how bad things get and report.
We found bugs by the handful and pinned them on the wall. They did not like that.

Past retrospective, we were asked feedback on why so many bugs were on the wall and if the team could do anything to mitigate the time lost on bugfixing.
We had our answer ready.

Sometimes, we have to hit a wall, or distant sea-rocks, to realize the stars weren’t showing us the right course. Sometimes, we hit that wall together and sometimes we have to let others hit a wall.

It might not be the easiest or most pleasant of the media to be used for communication, but it’s definitely one of the more effective. Be sure to interpret it right and learn a thing or two.

Identity Crisis

Experience Reports, Software Testing

Everybody’s a tester.
Product owners, developers, stay-home moms, anyone who buys any kind of application,…
You have tested some kind of complex application before. Some of us do it professionally, others subscribe to a Crowd testing program and even others just buy an app, toy around with and discard it after seeing the first sign of issues.

If testing is so easy that anyone can do it, why are there still professional testers?
Just pick a person from the street, give him the specs and say: “Now Cross-check this with what we’ve made. You can read can you? Can you click? Alright, you’re set!”

A friend and me had a very detailed discussion today about testing in ‘an agile project’, without much further context.
He’s working as an iOS developer and my experience is mostly in big, slow, complete business solutions. There is quite a difference in perspective, but these kind of discussions are always interesting.

Apparently, in the projects he works in, there are no full-time Testers, nor functional or business analysts,… There are however a few ‘Proxy’ people working on these projects. To me this sounded completely foreign, but I assumed this was another word for a kind of Product Owner. The description kind of matched. A proxy is an FTE who writes the User Stories and specs, checks with the customer and tests the application.

The reason these people are called Proxies and why they do just about anything but develop is that they are easily replaceable. One proxy falls ill? Another leaves the company? No matter, we’ve got more lined up.

Resource = Resource
I find this disturbing. I see no added value in having everyone so easily replaceable and generalist. If I’d had to be this omnipotent IT-wizard that body-shifts from product owner to change manager to developer to tester to developer and back to tester and so on,… I’d be terrible at everything. There’s a reason why I became a professional tester and I am content to be one.
I’m terrified of a Proxy writing code for the specs she agreed to with the customer and afterwards testing it. (This sounds awfully 1960-ish to me.)

People are not easily interchangeable. It always comes at a cost of knowledge, convenience, team spirit, time and budget…
Imagine good old Larry who you’ve been working together with for 1,5 year, occasionally shared meals with and who you’d ask all questions regarding finance functionality to.
Now imagine him leaving the firm and being replaced by Anna, who’s worked in a bank for 20 years and has a unibrow. Are you sure you’d work with her as smoothly as with Larry?
Even a change within a project requires a flip in mindset, or maybe even in skillset if it requires you to switch language (Java –> .net?) or from technical to functional. It is incredibly tiring and time inefficient.

When talking purely theoretical, it’s easy to look at your colleagues as 40-ish hours a week. But it’s wrong.
You can very well be called a Proxy. You can even be a Proxy. Hell, I’ve been a Proxy for a few months. But I know I’m not a good Functional Analist. I know I’m certainly not a developer.

You are not your job description
I am first and foremost a tester, but can fulfill coördination tasks, analyst tasks, Client management tasks and many more, if required. I also know that I can not efficiently do development tasks, or Test automation that goes further than a replay, nor will I do ‘Testing tasks’ that some people would expect of a ‘standard testing profile’, such as writing test cases with test steps for every single thing you can think about.
Take advantage of the different people in your team, don’t categorize them by their job title.

I’m not saying I’m against the idea of Proxies, nor will I advocate specified roles per person are the way to go. I do believe that both could work in different contexts and that some kind of combination of the two will surely work as well.