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,
There were four bug categories described:
- to be fixed for next release (Next),
- hard to reproduce (HtR),
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.
My first representation was a list really. I tried playing with different colors.
- 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:
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:
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:
… 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:
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 : email@example.com
Fourth Episode – Hands on testing : Configuration Tour
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).
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 »
Continue reading »