Good point mentioned by @VinWijNL: Developers (and probably testers, too) don't care that much about the cost of fixing a bug, but do care that fixing is easy. A very good reason to make fixing easier & find bugs early. #agileTD#DayOne
And last, but certainly not least Miroslava Nikolova made me (re?) post a message on a piece of cardboard that circled around at the Agile Testing Days 2009.
I think it is still valid and covers the spirit of this very conference and the attitude of everyone taking part so well.
Here’s the plain text (and if you know who’s the original author, I would really like to know who they are):
We are a community of professionals. We are dedicated of our own continuing education and take responsibility for our careers. We support each other in learning and advancing our craft. We certify ourselves.
— Unknown author(s?) at the Agile Testing Days 2009
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.
Ernie Miller presented “How to Build a Skyscraper” at Full Stack Fest 2015 in Barcelona, a talk that was not actually about building skyscrapers. He rather described lessons that can be learned from building skyscrapers. One of the ‘pro tips’ he presents is this: “A solution that seems unremarkable to you might just change everything for others. (so share what you build)”
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):
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
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)?
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.
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.
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! 🥳
I’m looking for a new software testing project in a team that allows (or expects) remote work and uses Ruby and/or Rails. Getting to use Elixir is a bonus. Limited travelling is possible.
