Meeleetester

This year I attended my second EuroSTAR , in Haag, the Netherlands. Last one was 5 years ago in Gothenburg, so it was about time to re-visit this conference. The conference lasted 4 days, where the first 1,5 days were workshops, and 2,5 days of conference, talks and key notes - with a lot of social happenings and expo during the breaks. We were 5 in total from my company that attended the conference. Monday First day I attended a whole day workshop with Michael Bolton, "Analysis for Testers", which was very educative and reminded me to keep looking at the big picture and context of what we are testing. There were a couple of assignments that we did in the classroom, in groups, and while they could appear to be easy and straight forward, they created quite a lot of debate among the participants. Even though all in all this workshop was educative and fun, there were some improvement points that I will suggest for Michael, like having more group assignments during the middle ...

For a long time, at least over the last decades, testers have been implicitly considered to be responsible for testing the service that is developed. After each development cycle, which lasted many weeks and months, followed a cycle of testing, which lasted for some weeks, and then the service was released to production to the end-users. If the version happened to contain any serious bugs, testers were usually "blamed" for not discovering this during the test phases. But why was this a common (mis)understanding for a long time, and perhaps still is in some companies? Why are not developers blamed for introducing the bug in the first place, product owner for not being specific enough when explaining what the end-user wanted, or was it the end-user that was unclear in his or her description of the feature? Why do we even bother pointing fingers on a specific role? At the end, the end-user or the customer is always right. If they experience an issue with the service that you c...

Most blogs on test automation are about how to add more and more tests to your automation suite, but rarely does anyone mention that you also should consider removing automated tests, especially those that do not provide any value. If you are on a new and relatively fresh project, you probably focus most on adding automated tests across different layers, focusing on automating regression testing certain parts of your service that you create. As your service mature, you probably have built up a good chunk of automated tests and you keep on adding more and more automated tests as new parts are added. Now instead of 10-15 minutes, your test suite perhaps need 20-30 minutes to run, and it becomes heavier and heavier to regression test new code. (This can probably be solved by other means of course, but consider this an example, there could be more reasons why you have a test-heavy delivery pipeline) Seldom does one consider the possibility of removing tests, not only in order to reduce...

This week I have been looking a bit into whether language(s) we speak, shape the way we think? Being raised up bi-lingual from the age of 8, where I spoke mostly Bosnian and Norwegian with a good addition of English, this is quite an interesting topic for me personally. Inspired by a talk from Lera Boroditsky from TEDWomen 2017, who had done a lot of experiments on this, here is what I found out. If you find this interesting, I encourage you to take a look at the presentation, many examples that I mention here are taken from her talk. 7000 languages, different way of thinking? There are about 7000 languages, each different from one another, in many ways, different sounds, different vocabularies, not at least different structures, to mention a few differences. Whether a language affect how we think has been debated throughout the centuries. "To have a second language is to have a second soul", stated Charlemagne, which is quite a bold statement suggesting that language is ...

So where to shift now that testers are part of reviewing the business cases, participate in creation of user stories and backlog grooming, have the ability to use monitoring in different environments, and everything in between, meaning participate in different parts of the software development and delivery life cycle? Well, I think that we could benefit a lot from trying to look at where we generate mistakes. If we sum up the development life cycle, regardless of how often you release, or whether you follow a  waterfall, agile, or devops approach, it all starts with some ideas, business cases, requirements on a higher level, before going into the process of refining the requirements, developing, testing and releasing the changes to the end-users. We previously shifted left and right trying to mitigate and correct issues that occur along the way in the process, without looking into where these mistakes originated. All of the ideas or requirements start in someones mind, with all...

Some time ago I read the book "Thinking Fast and Slow" by professor and Nobel prize winner, Daniel Kahneman, which is about the biases in our intuition, that we assume certain things automatically, in an instant, without having thought through them carefully. In many situations it is perfectly fine to act instinctively, but in others we should activate rest of the mind. In this blog post I will try to relate some of the topics that he touches upon in his book, to our field of software testing and development. My initial idea was that I would fit most of the topics into this blog post, but upon revisiting the book, I feel that there are way too many topics of interest covered in his book, and by going into all of them, this blog post would most likely result in another book, rather than a blog post. So I will only cover some of the topics. If you have not read his book, find it and set aside some time to read it. Read it fast and slow, it is truly an amazing book with a...

"Up to date" can probably be debated as development in our field change quite fast, and what was ground braking yesterday, fast becomes old news today. I try to read as much as possible, and this usually vary from week to week, day to day due to other obligations, but I squeeze in some hours each week. This is mostly done on the evening, on the way to and back from work, and at work when I have 5-10 minutes until a meeting starts, and I can not start on anything new, I spend that time picking up a blog post or two, and traversing through it. There is a set of blogs I follow, these are mostly from other practitioners in the field software testing / development. All of them are organized in different folders in Feedly , which I use to aggregate the blog posts, news, and other information. Here is a screenshot of the structure that I have. Testing folder contain most feeds from about 50-ish sources, and I have separated some of the blogs into AutTesting (Automated Test...