On TestWorks Conf I had the opportunity to facilitate a workshop on Exploratory Testing with Maaret Pyhäjärvi. It was great and I learned so much that day! My head was spinning with all the new insights and I felt very inspired. One thing that Maaret said that is so important is: “you are responsible for your own learning”.
A bit of story time. After this day with Maaret, I felt like a very obvious piece of a puzzle fell into place (ah, hindsight, how I love thee). In my career, I only had one year of learning about testing and then I started giving trainings and workshops myself. Nobody really taught me how, I just did it because the circumstances were there. And now, about three years later, I feel like I can’t go back into ‘student mode’. I don’t know why or how I reached that conclusion, because it’s complete nonsense, of course! You can be a thought leader, workshop facilitator or just really good in your craft and still be in ‘student mode’ sometimes. (I would even argue that it is really good for you to be the student once in a while, it reminds you to stay humble.) Continue reading
I remember going to the Agile Testing Days last year and seeing several people working on the big sketchnote of the conference. I was really impressed by their drawing skills and thought “wow, I could never do that”.
I decided to get into sketchnoting as well. I went to a half-day workshop on Visual Thinking here at my client and it was so much fun! They taught us some basic tips and tricks to get into sketchnoting. I still think I’m not good at all, but all you can do is practice, practice, practice.
So, here are my first attempts at skechnoting. I made them at the TED-style knowledge sharing event at my company Xebia. TED talks have the advantage that they are quite short, so you only have limited information to go from. Continue reading
I was in a meeting where a developer said: “every test is a form of waste”. Coincidentally, this meeting was about how the build was taking too long because the tests were slow, so I can see how the connection was made in the mind of the developer. It must be the tests, right?! What a waste (a waste of what actually? Time, money, effort?). However, I think this is a fallacy and I would like to use this blogpost to explain why.
In my career in IT I have heard remarks from some developers in different shapes and forms about how testing is wasteful: it takes too long (“I have spent 3 hours developing the functionality, now I have to spend 6 hours writing tests, how stupid!”) , it is boring, tests are flaky and besides: after all the effort put into making the tests work there are still bugs! Gosh. Continue reading
There are a couple of misconceptions when it comes to an agile way of working. Some people still believe you don’t need documentation (seriously, that myth has proven really hard to debunk). I also notice that a lot of focus is on automating everything when it comes to testing. I think that is a noble goal, but you will never be able to automate all testing tasks, since the ‘real testing’ happens inside a human brain.
So, even in an agile context it is a good idea to have some kind of test strategy. By this I explicitly do not mean a test plan. You know, those 50 page documents that nobody ever reads. An agile test strategy should be short and concise. It should explain to people who matter how you are going to approach testing in your context. It is also a good way to think about testing with your team.
I use terminology from earlier blog posts about biases. If you have missed those posts, read part 1 here. I explain the terminology there. In the second post I wrote about the Anchoring Effect.
Let me state the ‘bad news’ up front: you cannot fully avoid the confirmation bias. That’s actually a good thing, because if you could you wouldn’t be human. We jump to conclusions (with System 1) when our assumptions are likely to be correct and a mistake is acceptable. For example, when you meet a new person you immediately judge him or her based on stereotypes, what type of clothes the other person wears, his/her posture, etcetera. This happens so quickly that you cannot stop it.
However, jumping to conclusions can be a bad thing when the situation is unfamiliar, the stakes are high and when there is no time to collect more information . This screams ‘testing!!’ to me. We are often dealing with unfamiliar situations, the stakes are high and we usually face a deadline. How do we deal with this? Let’s explore what the confirmation bias has to do with testing. Continue reading