Category: Testing

Physics And Testing

At a number of conferences I attended in the past, people connected several fields to software development in general and testing in particular, which (at first) seem unrelated.

Since then, I pondered this for a while (read: more than 4 years). With my background in physics, I see a number of parallels to software testing. This is also a great opportunity to answer a question I get asked frequently: How did you enter software testing, given your background in physics?

Physics

Let’s start with a definition for physics:

Physics is an experimental science. Physicists observe the phenomena of nature and try to find patterns that relate these phenomena.

— Young, Freedman. “Sears and Zemansky’s University Physics: With Modern Physics”. Pearson Education.
Also see the wikipedia article on physics.

The patterns that relate those phenomena are the theories (or laws) of physics. They are models that describe an aspect of reality. None of these models is complete, in the sense that it describes everything. There is no one physical theory that explains everything. A nice view of the landscape of physical models is shown in the image by Dominic Walliman (see sciencealert.com for details):

The landscape of physical theories, see
Dominic Walliman’s ‘Domain of Science’ video on YouTube

In physics (as in science in general), experimental results and predictions  created by models are compared, in order to find out how a model does not match observed behaviour. This is important: Experiments can only ever invalidate a model, but not generally confirm its correctness.

Software

To me software systems are models, too: Even though they may represent reality closely, a software system is not the thing it represents.
Peter Naur described the relationship between theory building and programming in his paper ‘Programming as Theory Building’ (Microprocessing and Microprogramming 15, 1985, pp. 253-261).

Testing

My mental model of software testing is very similar to the one of physics: I see software systems as partial implementations of aspects of a real expected behaviour. In my view testing a system means it and comparing observed results with expectations.
The expectations may come from requirements (written or otherwise), previous experiences with similar systems (i.e. another web application from the same company) or other sources.

There are many approaches to testing, in a similar way to the many approaches to physics. Some of them work good in one area but not so well in another. What kind of testing is done, heavily depends on the kind of the software system: Testing embedded software used in medical devices is drastically different from testing, say, a text editor.

Science

It is interesting to go one step further, from physics to science. The Cambridge Dictionary defines science as

the intellectual and practical activity encompassing the systematic study of the structure and behaviour of the physical and natural world through observation and experiment

https://dictionary.cambridge.org/dictionary/english/science

With a different wording, this seems to fit software testing as well:

Software testing the intellectual and practical activity encompassing the systematic study of the structure and behaviour of software systems through observation and experiment.

The definition with a different wording

To me, many very basic principles of scions in general and physic in particular apply to software testing, too. And that’s why I think that my physics background is very helpful in software testing.

Now, I interested in this: What is your background and how does it help you in software testing (especially if your background is not in computer science or software engineering)?

Looking For A New Project

It’s time to find a new project!

What I’m looking for is a role as an agile software tester in a team that really strives to improve on agile techniques in both, testing and programming. I’m interested in learning more about DevOps, continuous delivery and automation, including but not limited to test automation.

Travelling in Northern Germany or Denmark is fine and a possibility to work (partially) remote would be lovely.

Technically, a project using Ruby and/or Rails would be fantastic. In case the team is working on steps to also use Elixir, that would be a bonus.

More about my previous work is available over at ‘work with me‘ as well as on my Xing profile.

‚Agile Testing Condensed‘ — A Review

Agile Testing Condensed‘ is the 3rd book by Janet Gregory and Lisa Crispin. As the title already indicates, it’s a short book – the print version has about 100 pages. Luckily, I got a printed version at the Agile Testing Days 2019 in Potsdam and had it signed.

The book covers the important topics of testing in an agile context on a high level. For details it regularly refers to the other books ‘Agile Testing‘ and ‘More Agile Testing‘ (to which I contributed a section). One topic the book returns to regularly is the ‘Whole Team Approach’. I like this first of all, because to me this is the core part of agile testing. In my experience, it is this aspect that troubles teams. And second of all, I this is great, because the details described in the other books, can, at times, make it hard to see this overarching relation.

If I had to name one thing that might be improved, that would be the size of the images. To me, they came out a bit too small to be easy to read. Since I also bought the ebook (where I can zoom the images), that’s not a big deal.

I highly recommend reading ‘Agile Testing Condensed’ to everybody who is looking for an overview of the topic or who likes to have a reference at hand to quickly look up a certain aspect.

Calling Me Names — New Labels

After a one year break, I was back to the Agile Testing Days this year (2019). Damian Synadinos gave a great keynote “More Than That“, where he explained, that we are more than ‘just’ testers. We can also be: parents, programmers, trainers, musicians, comedians… The list is long. This got me thinking about labels and titles I’ve put on (or used) myself.

In another talk Tobias Geyer shared his thoughts about wizards & witches (from Terry Pratchett’s series of novels about the disc world) in “Wizards, Witches and Testing” and in it he compared the witches and wizards of the disc world to testers and programmers. Given this input, I clearly identify myself as a witch.

During the breaks, I kept thinking about which labels I could put on myself, especially some that may be a tad bit far-fetched: Since I have some bits of high-tech implanted in my body I could be labeled as a cyborg, technically.

Following a similar thought: If one consumed blood of other people, that make one a vampire. And I did, during an operation last year, I thankfully received a transfusion.

Hmm, a vampire cyborg. There must be more positive sounding labels!

Then, there was a “AgileTD Late Night Talk Show” hosted by Daniël Maslyn. I was invited as a guest to speak about my cancer treatment I went through during the last year and a half. Daniël labeled me as a Jedi Knight, for having gone through this. Thank you! “Jedi Knight” — that’s a label that sounds much more positive! 🥳

"IT DEPENDS" Certified Practitioner

Also during the conference, I became a certified practitioner of “It Depends”, thanks to the exam by Gitte Klitgaard. Very nice, too!

And just after the Agile Testing Days, I took and passed the exam to become an  Agile Testing Fellow

Other than that, since 2013 I occasionally become SuperAgilePerson.

A tiny part of @Stuartliveart‘s sketch note from Agile Testing Days 2015

Let’s combine all those labels:

Cyborg Vampire Agile Testing Fellow
It-Depends Practitioner SuperAgilePerson Jedi Knight Witch

Oh, what a title! I won’t use all of those labels all the time, certainly not on a business card. 😉

What are your labels and titles?

Agile Testing Days 2019: A Keynote

I’ll be giving a Keynote at the Agile Testing Days 2019 in Potsdam, Germany: “Being Lucky”.

Stehpan's Keynote at ATD: Being Lucky

Here’s the abstract:

Good fortune can be influenced, so let’s do it.
Do you think a little more luck in your life could help?
Someone at the Agile Testing Days once noticed that I seem to be a particularly lucky person. This made me ponder: Am I lucky? When? How often? Where? I also asked myself, whether it’s possible to influence luck.
Episodes, some from this very conference right from the beginning in 2009, illustrate how luck can strike. However, it doesn’t necessarily feel like a lucky moment at the time it happens. It may actually feel embarrassing and stressful. These stories also provide some heuristics to help you become more lucky.
Lesson learned: While luck can’t entirely be controlled, it might in fact be shaped in our favour.

Agile Testing Days 2016 — Part 6: Conference Day 3

For the 3rd conference day, I’d like to mention two highlights: Ida Karine Bohlin‘s “The Tinder Project—How To Test The Right Swipes” and Gojko Adzic‘s keynote “Snow White and the 777.777.777 Dwarfs“.

Ida introduced Tinder, an online service to meet people. It can be used to find someone to have a chat at an airport or meet a lifetime partner. She described how she applied her testing knowledge to search for a partner on Tinder. The compilation of acceptance criteria  was hilarious already, including a good dozen aspects from handsome (but not weak) to strong enough so he could help with heavy luggage at airports. She presented the testing quadrant for identifying test approaches she applied and a testing pyramid to be used. To me, the topic of agile testing was very well presented, the talk was very funny and entertaining. Well done, Ida! I believe it would make a great keynote to introduce the topic of agile testing at a conference!

Gojko presented some aspects, that he believes will change the world of testing in dramatic ways. Two of the reasons for these changes are the ever decreasing cost of computation in general (e.g. by  services such as AWS Lambda), and the decreasing time needed to fix issues after production defects are found.

When applying a micro service architecture, the single service can be tiny — Gojko talks about a few dozen lines of code. With so little code, finding the cause of a bug is typically easy. (At least a lot easier than in a code base containing hundreds or thousands of lines.)

Let me finish with just one tweet about this talk (there are many more on Twitter):

Due to Gojko’s presentation there was a whole new session dedicated to “Gojko’s Future” during the unconference day that followed this 3rd day of Agile Testing Days 2016. But since that’s another day, I will cover it in the next blog post.

%d