Imagine this building. Part of it is ready and there seem to be people living there or doing all kinds of things. Part is being renewed and expanded as we speak. The house is an establishment that provides a kind of service to people. So naturally there are persons involved that have very different interests depending on the situation they’re in.
One disturbing thing is, that the house is said to be standing on an old burial ground and there are people who believe it’s haunted. It’s one theory, that people have, why the construction work of the new parts only very slowly advances, why parts of the old building keep cracking, creaking and breaking and why even some of the people have reportedly been killed while being in the house.
It’s one theory.
I am the private detective they hired to sort out that mess – my client wants to know if there is any truth in these allegations. My task in this case is to interview witnesses, speak to my informants, try to collect and preserve evidence. My mission is to unearth information, so that my client may make a more informed decision in the stated matter. That’s all I am allowed to say in this case; for now.
Tomorrow I may have a different case with different tasks and different nested missions.
***
Similarly a software project may be one big case or a collection of several smaller ones, but in spite of that I have to sort out a mess.
But just as a private detective doesn’t enforce the law and provides the client, who may be one person or even a group, merely investigatory services, I as a software tester don’t enforce decisions about “the stated matter”. I serve my client/-s and aim to provide them investigatory services to attend to their desires and needs.
***
This short train of thought was inspired by Michael Bolton’s blog post “What Is A Tester?”.
What are your thoughts on that subject? How do you sort out your testing-mess?
It was Friday the 13th exactly one week ago. I was sitting at work trying to clear my head from the terrible hangover that kept me away from being productive. We had a hot-fix release scheduled for that day and I struggled with designing my testing for a bug-fix-script that finishes running and stopped workflows when all the tasks in them are actually already completed. But this is another story.
This story here is about the hangover. You see, there are actually many different kinds of hangovers. Hangovers caused from alcohol, eating, sleeping, substances, flying. People tell me that you can even have a hangover from too much sex. There seems to be always a component that is either abused, overused or just bad for your body and mind. My hangover on Friday the 13th was caused by too much context-driven energy.
This may sound eyebrow-raising to you, so I’ll elaborate on that a little. The night before Friday the Estonian context-driven testing community (I’m not sure there are any other testing communities in Estonia) held their traditional “Testers’ Night Out” event (there is even a non-trending hashtag for that on Twitter). This time eight testing enthusiasts from four different companies, connected only through the appreciation towards the craft, sat around the table in a local establishment and for several hours indulged in, what can only be called, battle of wits.
The subjects discussed ranged from personal topics to current work related problems to seemingly abstract questions about the existence of testing. Following is a small glimpse at the main themes raised during the evening (thanks go to Helena Jeret-Mäe for “logging” our thoughts):
- Do you remember the first thing that you consciously tested after becoming aware of software testing?
- Do you remember the first thing you tested using skills of testing before you became aware of such a thing as software testing?
- How many schools of testing are there and why does that matter?
- What’s the difference between a test manager and a test lead?
- Will your skills decay if you only do your job and won’t pay attention to theory?
- What’s the percentage of time to spend on theory vs practice to be a good tester?
- How dangerous is road hypnosis and cruise control in testing?
- Is that my fifth drink coming up?
- How do you test this and how do you find out about what I need?
But back to the hangover and the underlying causation – too much context-driven energy. With some people you just can’t have a “normal” discussion, where you present experience, pseudo facts and shallow arguments to advance the evening and have a good time without the need to explain, argument and rethink. No, with some you have a good time while everything is a challenge.
It’s not even so much about the topics that were discussed but more about the way answers and questions were being processed that evening. In a need to explain why I felt like I did the morning after, a quote from an article I recently read seems suitable. Hopefully it will help you understand better what went on.
“[…] briefly, critical thinking is defined as […] the “engine” that drives how we decide what to do or believe in a given context. Critical thinking comprises behavioral tendencies (e.g., curiosity, open-mindedness) and cognitive skills (e.g., analysis, inference, evaluation).”
Quitadamo, I. J., Faiola, C. L., Johnson, J. E., & Kurtz, M. J. (2008). Community-based Inquiry Improves Critical Thinking in General Education Biology. CBE Life Sciences Education, 7(3), 327–337. doi:10.1187/cbe.07-11-0097
It was exactly this accumulation, on the threshold of Friday the 13th, of immense levels of curiosity, open-mindedness, and use of cognitive skills, which made it such a marvelously fascinating experience for me. And if you ever have a hangover from too much context-driven energy, just try to cure it with testing something. It’ll get you right back on the track.
Thank you sincerely for taking the time to read this and thank you to the participants who made that awesome night happen:
Grete Näpits, Helena Jeret-Mäe, Heiki Roletsky, Martin Ulst, Martti Kebbinau, Oliver Vilson and Rasmus Koorits.
Till next time,
Siim Sutrop
P.S Do you remember the first thing that you consciously tested after becoming aware of software testing? You’re welcome to drop a line in the comments below.
PEST 4.5 was my first PEST participation. I liked the theme a lot. I like using mind maps for writing down ideas for testing. I hoped to get inspiration to continue using visualization in my work. There were five participants there.
There were four topics to choose from:
- How to display current situation – Feature/Area vs. Bugs/Severity
- How to display current situation – Test Coverage
- How to display current situation – New Feature/Area vs. Risks/State of bugs
- How to display current situation – Current State of the Product/Project
For each topic we needed to consider two aspects:
- Current state,
- Iterative
- Trends,
- History,
- etc.
There were four bug categories described:
- Major,
- to be fixed for next release (Next),
- hard to reproduce (HtR),
- Small.
The task was to create a visualization (as easy to grasp as possible) that showed what was OK, what was not OK, which features were new, etc.
We were given an electric bicycle, to choose any part of, as our product. I chose the tracking of cycling. We didn’t need to concentrate on specifics of the example (electric bicycle), we could use abstraction. I created three representations for my topic – Current state of the Product/Project.
First Representation
My first representation was a list really. I tried playing with different colors.
I used:
- gray for project name
- purple for new features,
- black for old features,
- red for major bugs,
- orange for the bugs to be fixed for next release (Next),
- pink for hard to reproduce bugs (HtR),
- brown for small bugs,
- green for when the feature was OK.
For each feature I added information about the number of bugs of certain category (Major, Next, HtR, Small) that were not yet fixed. I also added information about the bugs (what the bug was about). I realized early on that a list would be too much written words at once (so not easy to grasp), but it helped me to figure out which information to display and as it turned out, also which colors to use.
This is how it looked:
First Representation
Second Representation
I then thought: what about drawing something, e.g. rectangles.
I divided the features between two columns – new features in one and old features in the other. I used the same colors as in the first representation.
Under each feature name I added the number of bugs found during testing. The number of bugs would expand to give a short description of the bug(s).
Each feature had a rectangle around it. The color of the rectangle represented whether the feature was a ‘go’, a ‘no go’ or a ‘so-so’:
- only green – go,
- only red – no go,
- a mixture of green and red – so-so:
- green as the top side of the rectangle – a bit more towards ‘go’
- red as the top side of the rectangle – a bit more towards ‘no go’
This is how it looked:
Second Representation
Third Representation
Then I thought I would do another representation and use a mind map for that. I used the same colors as in the first and second representation.
The idea was, that you have the features visible at first (i.e. only the first level bubbles). When you want to see bugs related to the features, you need to open corresponding sub-level bubbles. After looking at the image for a while I decided to add smileys to have a more ‘apparent’ visual sign ( 
– go, 
– no go, 
– so-so). I got the smiley idea when I remembered Sami Söderblom’s track from 2012 Nordic Testing Days.
This is how it looked:
Third Representation
… the questions time arrived. During that Kristjan pointed out that I only have features on one level and suggested that features could be partitioned and their state displayed like this:
After the presentation
On the image red indicates ‘no go’, green indicates ‘go’ and yellow ‘so-so’.
So, did I get inspired? Yes, I did.
[Go check out the same post and more at Kadri-Annagret’s blog.]
Nordic Testing Days 2014 was my first bigger conference about software testing and I loved it. I would like to start by thanking the organizers for giving me such a great experience.
I was there for two days during which I listened to many interesting tracks and talked to some stunning people. I am rather new in the field but as Pete Walen in his track about leadership said – the less you know the more you’ll learn. So I consider myself very lucky.
My first track was held by Dan Billing who talked about security testing. I had always wondered how people get into security testing – are they just natural born hackers or how they learn it without pissing everyone off all the time. Dan gave some great tips on how get started and showed some tools for practicing different kinds of attack methods without doing a DROP-ALL on your customer’s test environment database.
Stephen Janaway, loved him. I wrote ‘So positive and fun’ and ‘CATS-best presentation’ to my notebook. I really wanted to be friends with him. If only all co-workers were so nice to each other and every office had a kitty-corner, no-one would ever get frustrated… well… maybe the cats. But back to the real world. He reminded me about using my emotions as heuristics during testing – I often tend to forget that and just ignore my emotions. Also the emotions I have when I start testing affect my work, so I have to be aware of them. Of course – be nicer to co-workers. And make my boss put cat wallpaper on the office walls.
My favorite track was by Gitte Ottosen. She talked very enthrallingly about being a pragmatic tester, and how she uses her classical test school background in a context-driven way. Everything she said just made so much sense to me. Some projects may need certified people. Formal documentation is useful in larger projects when you need to communicate your work to many people, classical testing school teaches how to do that. Standards help organize work in large scale projects. But most of all I liked her though that classical testing school and context-driven testers actually are one testing community with overall the same goal. As I myself have been trained to be a context-driven, mostly exploratory tester and all I know about classical school are some stories I’ve been told about the “dark side”, then it was great to learn that classical school might also give me useful tools. I’m going to look into what kind of certificate training is out there. If I have time, I’ll create a blog post of my research results.
During the conference I tried to find some people who could tell me more about classical school and people who are working according to its dogmas. I walked around and asked people from different companies to describe how they work. As I expected then different companies use different methods for test planning and management, but everybody agrees that testers should have as much freedom as possible when it comes to test design and execution. I was a little disappointed that I was not able to find any proof of the “dark side”.
The first keynote of the second day was Anto Veldre. His talks are always so much fun as he kind of mingles between the real world and totally crazy paranoid conspiracy world. But I like it when someone comes and just slaps me in the face with stuff that I thought to be rather sci-fi. It makes me see beyond the cute kitten videos on Youtube and reminds me to be more of a critical thinker.
Erik Boelen gave a fun presentation about mobile testing. Turns out that as mobile app functional testing can be pretty similar to web app testing, but when it comes to performance and cross-platform integration it is so much more challenging. Does the app even load on different platforms, how does it work in different language environments, how does it act on jailbroken phones, what happens when someone calls while the app is running and so on. Got some great tips for the future. And Erik is just such a nice and fun guy.
Iris Classon was the last keynote speaker. I loved her speech about her journey from a fitness expert to a Microsoft certified programmer. But even more I loved her. She seemed to have mastered the art of being a woman in the software development world. And in the context of impressing people she is a great example of how certificates can help with that. She also reminded me to push myself more to try new things. Which is actually what I am kinda doing now – you just read my first blog post.
Estonian 3rd Context-driven Testers Peer Conference
Date : 23-25 November 2012
Place: Tallinn, Pärnu mnt 139 (detailed description later)
Theme: “Kickstart learning by teaching!”
It is all about teaching testing. Be it teaching testing to new testers, or programmers, manager, students, etc. It does not have to be about testing in general but could be about a specific area/skill of testing. For example:
- How I got business-analytics to do Session Based Testing
- How I convinced managers to stop doing silly measurements
- How I cleansed developers of bad habits in unit testing
- How I failed teaching students in university
- How I failed the ISTQB class
In addition to experience story, one needs to present a short testing exercise which should be around 10 minutes in length. It could be a puzzle, trick question, origami, or physical feat, etc as long as it is related to testing skills.
Content owner: Kristjan Uba
Questions can be email to : info@testerstower.com
Fourth Episode – Hands on testing : Configuration Tour
Summary:
In this episode we’ll use Configuration tour to learn about and test the spiritual successor to classic UFO X-COM game : Xenonauts. We will find some crashes and other problems and give a hands-on presentation of the tour. Also we’ll call it the fifth episode in the show, due to the retake of the third, but it really is fourth.
Black Box – tour based testing – “Testability tour”
Test target is a game: Xenonauts.
Add your questions to the comments or send them to live(at)testerstower.com
Third Episode – Hands on testing : Testability tour (Updated link to the retake of the episode).
Summary:
Last time we talked about lot of test design stuff, this time we are actually looking into one. This is a pilot episode, done live. We are looking into making the content and video quality better.
Black Box – tour based testing – “Testability tour”
Test target is a game: Path of Exile
Links from the show:
The little black book on test design: http://www.thetesteye.com/papers/TheLittleBlackBookOnTestDesign.pdf
Add your questions to the comments, they will get answered! Or send them to live(at)testerstower.com
The third (and final) post of results of PEST2.
Who are the key members of a team?
It soon was agreed that there are no key concrete members – like developers, project managers or such. Every member of a team is important, no-one should be just a blind follower. It emerged that there are roles that need to be filled in order to make a team work. Additionally, the roles are not tied to specific person, but can be taken up by any member, according to circumstances. And the roles can differ depending on the actual goal of the team. Continue reading »
This is the second post of PEST2 results.
What makes your team tick? (if you are one-man-army then what would make a team tick)
Recent Comments