Meeleetester

We all have been reading headlines and articles about cars that have been recalled due to certain failures, and the numbers of cars that needs to be delivered to local car shops are always quite high. A quick Google search shows articles like BMW recalls 300.000 cars , Kia recalls 500.000 cars , Fiat recalls 4.8 million cars , this list could be as long as you want it to be. Recently Tesla's model 3 were tested by Consumer Reports , a nonprofit organization providing product ratings and reviews, and they ended up not recommending this model due to issues with Tesla's stopping distance which were almost 50 meters when braking at about 100 km/h. This was far worse than any contemporary car tested by the magazine and about 2 meters longer than the stopping distance of a Ford F-150 full-sized pickup .  Tesla, instead of recalling this model, which has more than 400.000 pre-orders (at this point I was not able to find out how many were already sent out from the factory), they p...

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 ...

We all have heard about the leaning tower of Pisa , mostly known for its unintended tilt. I had the opportunity to visit the tower some years back and was actually surprised by the surrounding site around the tower, the Cathedral, the Baptistry, and the Monumental Cemetery. In my eyes these parts of the " Piazza dei Miracoli " were much more astonishing in beauty than the tower of Pisa, but I have never heard about these parts in Pisa. Having my "tester" hat on, I soon realized that I only had heard about the most famous mistake in construction history, and that the town was mostly known for this mistake, overshadowing the beauty of rest of the site. A quick overview of construction of the tower Construction of the tower occurred in three stages over 199 years, starting in 1173. The tower began to sink after construction had progressed to the second floor in 1178. This was due to a mere three-meter foundation, set in weak, unstable subsoil, a design that was fl...

One of the first questions that I usually hear from testers, when talking to other testers is "Which tools do you use <to do something>?". During our local meetups here in Norway, conferences or larger gatherings, or even at work between teams, this questions seems to be quite central and important to many testers, judging by how many times I have heard it. Some tools could improve and broaden your "testing-repertoire" but even though one should not be too dependent on a given tool or be tool-centric, this toolbox can be quite useful, and I seldom hear that someone mentions it when talking about tools used for testing. The toolbox that I'm aiming at here is the Developer Tools toolbox that are bundled with all major browsers. I usually mostly use Chrome, so that is why I will, very shortly, present how and why I use the tools in the Chrome Dev Tools, but you'll find either all or most of the features/functionality in other browsers as wel...

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...