How do I test?

I'm a musician, that shall make me a better tester

2020-06-17T12:12:00.000+03:00

"I'm a musician, that shall make me a better tester." This is what James Bach said at Swiss Testing Day 2012 in Zurich. (Here's a video clip from that talk) The title of the talk was "Buccaneer-Tester: Winning Your Reputation". Now, I'm quite familiar with James' work and the Secrets of a Buccaneer-Scholar is sitting in my bookshelf. I know something about what he's talking about. You don't need to have qualifications or degrees. You don't need all the fancy certificates and diplomas. What you need is to be a constant learner and have a curious mind.
Anyhow, I want to talk to you about featuring myself as a testing musician. Since I think I know music and testing, they could have similar features.
Note to reader: When I say "song", I mean it as an activity. Let me explain. The song contains many elements to it and it would be difficult to say "I play guitar, bass, drums, keyboards, sing, growl, scream, etc." A song is not a thing per sé, but a sum of activities that are inherently combined. There wouldn't be a song without activities.

I play music - I test software

I play music as professionally as possible. I might not be the top-notch of musicians at the moment, but I have my ambitions. Reality is what it is and I have just so much time left to be the best. I practice every day (at least every other day). I don't know every technique and I suck at some. Sometimes I fail at even the most simple stuff, but I don't stop. I play it until I get it right. Sometimes I need to "fake it until I make it", just to seem professional until I can be at that level. This means I need to practice twice as hard. My musical background isn't just playing, but all other aspects of music are equally important. Sometimes my focus is on learning, sometimes it's in playing, sometimes I compose.

I compose music - I plan my testing

I plan my songs beforehand in a way that it is easier to implement than when the actual playing starts. Planning songs can be as detailed as I want. The most important thing is that the level of planning suits the purpose. When I'm in a group of talented musicians and everyone knows their s**t, the implementation of music is easier and might not require that much planning. Here's where my approach might differ from others': my style of music isn't the only style. My songs are usually progressive punk where brute force meets intricate note passages. That is why some aspects of my songs have detailed parts and some are exploring and learning the songs. It all depends on multiple factors: instruments, people involved, schedule, arrangement, mood, previous experiences, you name it. In essence, composing music depends on multiple things, and all you can do is to come as prepared as possible, but be open to change.

I learn new songs - I learn new techniques

I need to be better at composing and playing, so I must learn new songs all the time. This might mean I need to learn my own songs, my band's old songs, or songs from other musicians. I have quite a broad taste in music and it is nice to know some classics. It is also nice to know some newest stuff from bands I like. Listening to a song and trying to learn a song from only hearing it isn't my thing. I need to make notes (sic) or search for chords online, etc. By watching someone play the song and then watching it multiple times in slow motion also helps. What I'm trying to say is that not every song is the same and needs to be approached differently. A Frank Zappa song "Black Page" takes a bit more than just listening to it, but a Green Day "Basket Case" is from the other end of the spectrum. If I want to learn something, I do what needs to be done to learn it. Also, other musicians can help me when I'm stuck or need coaching.

I listen to music - I follow other testers

Just like learning new songs, I listen to music just because I enjoy it. I hear new things happen in songs like the style of singing, rhythm figures, time signatures, you name it. And when I do, I might want to incorporate something similar to that into my songs or my style of play. One of my band's songs needed a bit of a kick so I borrowed a bass line from Flea from RHCP. One song I did had a 13 eights time signature at one point and the rhythm was inspired by a bolero song I heard from the radio. So I am inspired by songs and musicians AND I steal stuff. But when I steal, I try to promote the one I steal from. I am standing on the shoulders of giants to be where I am. Sometimes someone will hear my songs and steal from me - and I think it's a compliment.

I teach my songs to my bandmates - I coach testing to others

When I have heard or composed a song, I try to share it with my bandmates. These coaching sessions might spark new ideas for both of us. Sometimes teaching is pointing to a literary source or a YouTube video. Sometimes I hand them a music sheet I composed or something I played on tape beforehand. I might even sit next to them and play it myself to them and then have them try it. I teach in a way that resonates with both of us. The teaching might be for just one or the entire band, whatever suits the situation best. It is usually really difficult to convey a complex piece with moods, passages, arrangements, or the like. But you teach them the best you can. Usually, the result is that they come up with something I wouldn't have even thought of.

I play gigs - I speak at conferences

When I have worked hard to come up with ideas and songs, I want the world to hear them. I want to be on stage and perform. And I LOVE IT! I was born to be on stage. The thing is that you can't go on stage doubting yourself. You practice your songs, you practice performing (beard-moshing, stuff between songs, dance maneuvers) so you are nice to watch, you come up with material that people want to hear. Or not. Sometimes you need to be able to hop on stage with minimal preparation. And when it happens, you kneed to know your s**t! You practice even though you have no gig coming, you hone your skills all the time.

I record an album - I write about testing

At times I have something concrete enough to publish. Spending time and money to hone and produce something is satisfying. At this point you harness all your skills, all your time and effort spent composing music, all your time arranging music, all your confidence from gigs. The record is a picture of your devotion to the craft. It is your baby and you finally let the world marvel your creation. The produced piece can be small or gargantuan, but it's out there.

It's all in the context

One hard part of being a progressive-punk musician is that sometimes everything gets changed because something doesn't fit. I cannot prepare myself for every situation.

Here's an example: I have come up with a piece having listened to progressive metal, jazz, classical music, electronic disco music, spoken word poetry, and K-pop. I have made lyrics that are beautiful, meaningful, poetic to the point of tears with euphemisms. The time signatures and tempo changes make the song sound like it drives pure oxytocin into your heart. The 17 eigths and 3 fourths dance together with polyrhythms in Spanish gypsy scale playing with semitonal harmonics. I then record a demo at home with tears in my eyes and take the demo for the band. "Ummm... Yeah... No... How about we do 230 bpm 4 fourths with three chords. You can have a G# in the bridge, 'cuz you're such a prog-man. And then write some lyrics about the government or stuff."

You adapt to changes.

I am a musician and a tester. I am a better musician because I am a tester, and I am a better tester because I am a musician.

HUSTEF 2019 – Conference at a Glance

2019-10-25T20:47:00.000+03:00

Hi all! It’s time for the next post regarding this year’s conferences. I’ve been (with my good friend and colleague Jani Grönman) invited to speak at three conferences this year: TestCon Europe at Lithuania, HUSTEF in Hungary and Quest for Quality in Ireland. My plan was to share my thoughts about all these conferences, but unfortunately, I had to skip TestCon blog post due to scheduling issues. The review is already underway and it’ll be added here as soon as possible.
I’m rating the talks based on my personal opinion, which means that they might be totally different from yours. AND I haven’t seen the talks yet, so the results might be totally different once I get to see some of them. The process is the same as in my previous “At a glance” posts. Look here for instructions.

This is Conference at a Glance – HUSTEF 2019!
What I have heard through grapevine is that the conference is highly valued in Hungary and the premises a gorgeous. I can’t wait to see the venue and the city of Budapest. From Hustef.hu web page:

“HUSTEF is one of the premier conferences in Europe for practitioners in all areas related to software testing. The conference was founded in 2011 by the members of the ”Hungarian Testing Board” with the aim to have an annual platform where the best from the software and IT R&D sector can exchange information about new developments in the industry. HUSTEF has grown to be one of the biggest software testing events in Europe, with more than 670 attendees from all over the world attending the 2018 conference. HTB is the local representative affiliate of ISTQB accrediting thousands of software testing engineers who share a belief in the power of innovation and a desire to be leaders in the field of testing.”

The talks and workshops vary from technical talks to practical, from AI to think like a tester. This is the kind of place where I want to be! Let’s see what we have ahead of us. I want to say that I am really biased towards intelligent testing thus making it difficult to see good in some of the talks.

Keynotes (There seems to be quite a lot of those)

Tariq KING - AI for Software Testing: The Ultimate Journey

In the last blog post I wrote, I mentioned Mr. King’s talk. There will be quite a lot of talks about AI and it is a big thing in software testing now and in the future. I believe this is going to be an experience report that describes Ultimate’s ways of working. Since I will dive deep into AI and ML in Q4Q-conference week after HUSTEF, I see this as a nice introduction.

Short time value: ** (The opportunities to learn and create some basic knowledge in AIST is a good thing. To take these lessons to my daily work at the office doesn’t seem likely now. At least without a proper introduction to the subject.)
Long-time value: (I think the long-time value comes from somewhere else. My current company isn’t going to adopt these AIST principles any time soon.)
Steal-ability: (My skills and the nature of my current workplace I see very little to incorporate to my work nor do talk about it in the foreseeable future.)
Challenge-ability: ** (The role of “intelligent testing” isn’t to be lightly brushed aside. AIST is a tool and it is useful in its own domain.)

Philip LEW - From Tester to Thought-Leader: The 8th Habit of Highly Effective Agile Testing

An interesting topic in general. The skills development is something that I and Jani will do a talk about. If this talk describes the skills themselves, we talk about methods to deliver those skills to the team. Also, since Mr. Lew knows quite a lot about coaching, I see a lot of similarities in our way of thinking (and maybe in the contents of our talks).

Short time value: *** (Skills and ways of thinking are what I’m interested about and I think he can deliver a lot of valuable information.)
Long-time value: *** (The habits of being effective as a learner are something that everyone should have. Learning is the most important feature of a tester!)
Steal-ability: *** (I’m SO going to steal ideas from this topic! Luckily it is on the first day, then I can refer to it in our talk.)
Challenge-ability: ** (The problem (the only problem) with this talk is that I might be so biased towards thinking this is so awesome talk that I accept any ideas presented.)

Dionny SANTIAGO - Surviving the AI Testing Apocalypse

Although this is also something that will be a topic at Q4Q, I think this is an interesting topic for me personally. I’m not worried about the coming of AI. I’m worried about the hype and attitudes it brings with it. AI is a tool like that serves a purpose. When agile testing came with a strong focus on automating tests, testers were worried they run out of jobs. Adapting is a key thing here. I don’t see every tester having to be able to code an AI but learning how to use it as a tool. Hopefully, this talk will shed some light on that area.

Short time value: ** (A thought-provoking things once again. Being able to talk about the pros and cons of AI is valuable.)
Long-time value: ** (Being able to “keep my job when AI takes over” is a good skill. Not being a traditional engineer with a technical skillset, I need the skills to help me get through the Judgement Day without Arnold.)
Steal-ability: * (I might include some of these things in my talks about testing skills and skills development.)
Challenge-ability: ** (It might be that the talk doesn’t help me in the way I think. The “surviving” might be focusing solely on developing technical skills to some level. I can do that, obviously, but I am seeking different help and ideas.)

Jennifer BONINE & Janna LOEFFLER - The Life of a Tester: From Once Upon a Time to Happily Ever After

Am I hearing more AI and ML talks? This seems a bit similar to Dionny Santiago’s talk about keeping your QA job after AI is released to the world. The animation makes this an interesting keynote. I’ve known Janna Loeffler for a couple of years now and I know she can deliver a killer talk with visual aids. The animation might prove really valuable in learning about the subject. I and Jani keep saying that quality is not made by the testers but by the whole team. I think this presentation taps into that. Quality IS everyone’s responsibility!

Short time value: ** (The survival theme keeps popping up in the conference. I hope this supports and gives new views on the subject.)
Long-time value: ** (“Writing my own story” is important in these times of change. This talk should change my views in the long-term.)
Steal-ability: ** (Although I cannot steal the animation, I’m sure I can make some of the ideas my own. Life as a tester needs constant adaptation and having a long term plan is always a good thing.)
Challenge-ability: ** (When talking about AI again, I see possibilities of colliding with my ideology of having intelligent testers and using AI as a tool. Let’s see what happens…)

Talks (Only 6 this time)

Prashant HEGDE - Revolutionize Your Testing Strategy with MindMap Driven Testing

I started using mind-maps over ten years ago and I even gave a talk about it at Nordic Testing Days in Tallinn in 2012. The use of mind-maps has changed my thinking and the way I report and take notes in my testing. In agile testing, reporting should be agile as well. I’ve found it useful to do that on a mind map. Apart from reporting testing, I use mind-maps to model the context and the product. It helps me to understand the system as an entity instead of separate functions etc.

Short time value: *** (Being able to hone my skills in using mind-maps is really useful for me. The insights I’m expecting might inspire me to write something down on how I use them nowadays.)
Long-time value: ** (Having a background in using mind-maps in the past might not bring that much new stuff, but perhaps it helps me look at things from a different perspective. At least it should inspire me to use them in more efficiently in the future.)
Steal-ability: *** (If I see a technique or hear an idea in this talk, I will most definitely use it to my advantage.)
Challenge-ability: *** (Knowing quite a lot of the subject, I’ll be able to challenge things that don’t fit my view of the world. Though I don’t totally disagree, I try to help Prashant make more out if his use of mind-maps by offering my own view.)

Jeremias RÖßLER - Test Automation without Assertions

Ok… Silver bullet test automation tool, eh? I might be overly critical and I’m sure my biases are at work here. I have an allergy to snake-oil test automation. The topic sounds like a tool advertisement. Hopefully, it is more of a technique or an approach to testing instead of offering one tool to solve all problems. I’m sorry Doctor, but we might not have joint ground in this subject.

Short time value: ** (My company is always looking to improving test automation. I might be able to offer a solution for them to assess. Perhaps we can find a use for it.)
Long-time value: * (Knowing about things always help to develop as a tester. Being able to talk about Recheck most definitely helps me when discussing keyword-based test automation.)
Steal-ability: (I see very little things to take as my own or develop it further.)
Challenge-ability: *** (I expect to see things that contradict my views. It might be more useful to have a proper talk outside the conference room so that I won’t spoil the event for those who find it useful.)

Aleksandra KORNECKA - Cognitive approach to software quality

I’m a soft skills person. I like thinking, emotions, communication, etc. skills that are not necessarily engineering skills. This talk might help me develop my skills in those areas and be able to talk about them.

Short time value: *** (I should be able to use these skills in my work quite easily very soon. On a weekly basis I need to coach people using these skills and teaching them.)
Long-time value: *** (Knowing these skills most definitely helps me be a better coach.)
Steal-ability: *** (I see large potential in developing this topic further with my previous knowledge.
Challenge-ability: * (Not knowing too much of the research side of things might make it quite difficult to challenge ideas.)

Vojtěch BARTA - Customer Testing and Acceptance

At my company and in my role as a coach we quite often train acceptance testers and customers to do some testing. This can be in the form of accepting the system and paying the bill, some form of validation to lay the blame for defects or contract violation or some other. Acceptance testing always requires a mission which we try to achieve. The talk seems to cover most of the issues I am facing in agile testing in our company. How to make people understand the importance of UAT?

Short time value: *** (We have a lot of coaching cases coming up and I feel that this could drastically improve the value of our work.)
Long-time value: *** (I’ve been on the customer side doing the acceptance along with other testers, so these skills also help me in my future assignments to test from the end-user/customer point of view. Also, knowing more about acceptance testing helps me educate our sales teams to make better proposals and have them involved them development throughout the lifecycle.)
Steal-ability: *** (I’m SO going to steal as much as I can from this talk. The fact is that I can incorporate this knowledge into my previous knowhow and be a better tester and a coach.)
Challenge-ability: ** (Since I know quite a bit about this topic, I feel that I have loads to say about this. I’m keen on seeing the results and can Vojtěch include all the important things in his talk.)

Janna LOEFFLER - On the Shoulders of Testing Giants

Just like Janna, my philosophies are molded by these Giants. Michael Bolton, James Bach, Cem Kaner, Jerry Weinberg, etc. are the bedrock of my testing self. These views are then affected by people like Elisabeth Hendrickson, Huib Schoots, etc. I have my feet firmly on the shoulders of there magnificent individuals.

Short time value: *** (As a story I’m sure I get loads of ideas and remember to be thankful to those I work with. The talk might not have a “thing” to take home, but it most certainly will make me think of all the people I look up to.)
Long-time value: * (I’m not sure if there is a long-time value here. I expect a story and something to make me think. I might find it easier to acknowledge the influences, but at this point, I feel this is more of a short-term thing.)
Steal-ability: ** (“Stealing” this might be hard but talking about it can be a bit easier.)
Challenge-ability: * (I am on the same lines as she is. You need to appreciate the people that influence you. Maybe even say it to them occasionally.)

Shekhar RAMPHAL - Five Levels of API Automation

API testing is an important thing in testing. I’d say a basic level of test automation is API automation. Asserting calls is fairly simple and can be done on almost any language and testing tool there is. It’s nice to hear a talk about making test automation easier. I think it’s good for “dummies” like me.

Short time value: *** (A more detailed understanding of API testing is good to have. Even if I can’t do automation per se, I can use the knowledge to coach developers to do better tests.)
Long-time value: ** (Skills like this will be beneficial in every kind of testing in this era. AI and similar tools require knowledge of API testing.)
Steal-ability: * (To further develop this is a bit too difficult for me, but I believe I can incorporate this into my daily work.)
Challenge-ability: ** (I have some prior knowledge of the area and I have healthy critical thinking towards automation. The API testing can (and should) be used wisely.)

There you go!

Well, that’s my view on a few of the talks and keynotes at HUSTEF 2019 conference. Like I said before I’m not saying I attend all these talks, but I feel they might be good candidates for my itinerary. I encourage all of you to comment on what are your views about these talks and other talks as well. If I happened to comment on a talk you’re presenting, please give me a comment. It would be lovely to hear from all of you!

Quest for Quality 2019 at a Glance

2019-08-08T13:08:00.000+03:00

Hi all! It’s been a long time since I’ve posted anything on my blog. I’ve been busy with various things, but I have now decided that it is a good time to share some thoughts about the forthcoming fall. I’ve been (with my good friend and colleague Jani Grönman) invited to speak at three conferences this year: TestCon Europe at Lithuania, HUSTEF in Hungary and Quest for Quality in Ireland. My plan now is to share my thoughts about all these conferences.

I am not an expert with some of the subject matter of these talks I’m about to rate (in my Angry Bird scale) and I am sure I misunderstand a whole lot based on the description on the website. As the title says, this is a glance. It is not a comprehensive analysis. I have described my process in more detail in this post, but here’s the gist of it:

I will grade topics using 0-3 stars per area, in FOUR areas:
• Session value – short time span (How much can I get out of the session tomorrow – next year?),
• Session value – long time span (How much can I implement o my work and teach to my colleagues, my community?),
• Steal-ability (How much of it am I willing to borrow and further develop to make it better and, more importantly, make it my own?), and
• Challenge-ability (My past knowledge on the topic and my willingness to challenge the session contents.)
I’ll choose the sessions as follows:
• Choose two sessions from each day based on my interest in the title
• Choose one session from each day that I pick randomly

This is Conference at a glance - Q4Q 2019!

The conference is mostly about AI and ML, but my talk “Test Coaching” has been chosen to add a more general perspective to the technical set of talks. I will write about test coaching either here or some other platform, but I try to remember to update this post to link to that post.

The concept of AI replacing tester is absurd. As a tool to do better testing, a tester will most definitely benefit from new ideas and tools in the toolbox. I promise not to be judgmental about the topics, but I am most certainly biased towards a non-technical approach to testing and I might be over-critical with some topics. Bear with me, though. This is subjective after all. 😉

One thing to note: I haven’t met most of the presenters, so my rating is based on the bio and my quick research of that person.

Keynotes (There seems to be quite a lot of those)

Tariq King - AI-Driven Testing: A New Era of Test Automation

As a context-driven and holistic tester, I am keen on learning about new things to boost testing efficiency and reliability of information testing provides. The way Tariq talks about AI as a tool is fascinating. I’m fascinated to see live demo how the bots work. I mean, they might work on their own, but the practical application to software testing is what I want to hear. I hope I get answers on how can I use AI in my daily work IN PRACTICE.
• Short time value: * (The implementation of this is not yet in my immediate agenda. Let’s see…)
• Long-time value: ** (The topic is very interesting and if I cannot implement it immediately, I can at least share my views on it.)
• Steal-ability: - (The description offers more questions than answers, so the steal-ability is a mystery now. My technical abilities might hinder me taking the topic to the next level, but let’s see.)
• Challenge-ability: ** (I am sure I can find things that rub me the wrong way. As a tester rooting on using one’s brain to test, outsourcing thinking to a machine sounds dangerous and reckless.)

Pallavi Kumar - When AI Meets Software Testing

The keynote description leaves a lot in the dark, but I guess it follows the same track Tariq sets in his keynote. The future of testing always intrigues me. It also frightens me to some degree. Based on the background of Pallavi Kumar, she uses AI in various other purposes, including mental health (which is close to my heart).
• Short time value: * (I hope to catch some good ideas but implementing them in my daily work seems a bit distant. I am, however, very intrigued about hearing her talk and maybe chatting with her afterward on practical applications of AI in mental health.)
• Long-time value: ** (The future of testing is an interesting topic, but I fear this is a praise to AI. Like Tariq’s talk, I should be at least able to talk about it. Also, I feel the effects of mental health makes me want to hear this talk.)
• Steal-ability: - (Same as Tariq, basically.)
• Challenge-ability: - (I don’t see “un-challenge-ability” being a bad thing. This should be purely about new insight on applications of AI.)

Michael Clarke - “Robots Took My Job!”: Where do Testers Fit In A Future Fueled by AI & ML

Michael’s view about AI and ML is quite close to mine. Where does AI & ML leave testers? I want to hear more about this. Since Michael doesn’t seem like your run-of-the-mill technical engineer, I feel he’s a kindred spirit. Him being a sole tester in a team resembles my work as a tester for the last few years. I most definitely wait for this talk.
• Short time value: ** (Talking about the importance of human tester is important and I totally agree with that. I will most definitely get a lot of ideas from this talk in the short and long run.)
• Long-time value: ** (Like I mentioned, this will be a great talk for me.)
• Steal-ability: ** (The topic is close to my heart. As a holistic tester I will further develop this idea to benefit my company and the testers in my community.)
• Challenge-ability: * (I feel there could (and should) be things I don’t agree with. I hope the talk shows that humans are the ones doing the testing. AI is just a tool!)

Yasar Sulaiman - Will Artificial Intelligence Take Over QA Jobs?

There are quite a lot of talks about testers losing their jobs. In my talk, I talk about a way to keep the testers up to speed with their skills, hence I don’t see us losing our jobs. Yasar talks about evolving testers and I think it supports my talk quite nicely. There is always a threat of people losing their jobs but adapting to change is the key to having a long and stable career.
• Short time value: ** (To be able to talk about the evolvement of the tester to fit today’s testing industry is a key element to my job.)
• Long-time value: ** (In the long run I might be able to advise the skill set needed to perform specific tasks in various projects. There are quite a lot of domains that can benefit from AI as a tool for a tester.)
• Steal-ability: * (Same as Michael Clarke’s talk, the topic is close to my heart. Maybe I can develop this further.)
• Challenge-ability: * (Same as Michael Clarke’s talk essentially. Let’s see where the talk leads us.)

Jason Jerina - The Future of Quality Assurance: A Path for A.I & Human Intelligence

First, I thought “Yet another keynote about the future of testing.” but it seems this is more about tool hype. Tools and automation are a tricky subject for me. I fear that the IT community starts to think the tools are snake-oil that solve all testing problems. When we add the AI to that, the thinking of a human might get forgotten and its importance lost in the cogs of technology.
• Short time value: - (I feel I don’t get too much in the short run for I see quite a lot of technology hype in this keynote. There might not be that much to implement in my current job.)
• Long-time value: * (I will be able to talk about AI and ML on a larger scale. The value of that is currently lost to me.)
• Steal-ability: - (I have no intention of stealing this subject unless it turns out to be more than a sales pitch for automation.)
• Challenge-ability: *** (I’m sure I won’t agree with most of the stuff. I will most definitely try to challenge the ideas represented.)

Rhealyn Mughi - Robots Are Here; What Can We Do To Keep Up?

Yet another keynote about the future of testing? The topic, however, guides the audience to keep up with the technology and robots. Rhealyn Mugri also talks about the impact, which is nice to hear. We’ll have to see if this keynote promotes intelligence over tool-hype.
• Short time value: - (I don’t see too much short time value since this is more about the future of testing. The guidelines might come handy in the long run.)
• Long-time value: ** (The guidelines and talk about rapidly evolving industry are useful information.)
• Steal-ability: - (I don’t yet see anything steal-able, but we’ll have to see. The future is always interesting, but I don’t see how to make this topic my own.)
• Challenge-ability: * (Is this more about robots in general or how they affect testing? I feel there might not be that much talk about testing. If there are no practical applications to implement the guidelines for testing, I will challenge the usefulness of those guidelines.)

Talks (Only 6 this time)

Zachary Attas – Services: How to Test Them When You Have The Keys to The Castle

Ah! Test strategy – my favorite. I feel that people underestimate the value of a good strategy. The focus is usually writing a document and burying with the rest of the plans in some dark corner of the project library. End-to-end testing and test automation both sound interesting. I work at Solita and we use a lot of integration and E2E automation. It is nice to see what possibilities this talk provides to make our tests better.
• Short time value: * (I might not be the one writing the code, but I feel that this talk helps me aid others to create better tests.)
• Long-time value: ** (In the long run, I might be able to help teams generate a good strategy for integration testing. This is vital to my role as a coach.)
• Steal-ability: ** (I try my best to understand the details of the talk. The strategy will be the main part that I am interested. How to generate strategy is my favorite part of learning to test.)
• Challenge-ability: * (Not knowing too much about the technical aspects of integration tests, I might not be the best candidate to challenge most of the content. I do feel that the strategy generation part will be my focus and I will see if there are things that sound odd to me.)

Shama Ugale – Testing Conversational AI

The idea of testing conversational devices is intriguing. I can see the difficulty in it and the techniques to do so need to be carefully thought of. I haven’t been involved testing such systems, but I see a progression towards that area in many fields, such as infrastructure maintenance, elderly care, phone advising, etc. Besides, I use these devices at home, so it is intriguing to know how these devices are tested.
• Short time value: * (While the topic is very interesting, I can’t see the near-future application of this kind of testing.)
• Long-time value: ** (In the long run, I might able to consult teams and customers to test these devices or services. I’m sure these skills are transferable to other approaches of testing.)
• Steal-ability: * (Having rather limited technical skills currently, I don’t see too many opportunities to adapt and build upon this subject.)
• Challenge-ability: - (The topic is new to me thus I don’t see much challenge-ability in this topic. I believe however that topic is interesting enough to overcome that.)

Maik Nogelsen – Testing VR; The Trinity Of Testing

Maik sounds like an esteemed figure in software testing. I expect a lot from his talk and chatting with him. His work in German testing community sounds awesome. Anyhow, his topic on the VR sounded quite interesting. I read an article about Fallout 4 the difficulties of testing the game. I became interested in the possibilities and difficulties of VR testing but haven’t had a chance to hear more about it. I think this is a great opportunity to learn more about it.
• Short time value: *** (I may not be able to implement the techniques or the methods to my daily work, but I am keen on learning about it.)
• Long-time value: * (Like I said before, I might not be able to implement this topic to my daily work, so it might not generate that much value in the long run.)
• Steal-ability: * (While I might not be able to “make it my own” I’ll learn how things are done in the real world.)
• Challenge-ability: - (The topic is new to me thus I don’t see much challenge-ability in this topic. I believe however that topic is interesting enough to overcome that.)

Sunder Shyam - AI Techniques To Improve Software Testing

The topic sounds quite ambitious and quite hard to grasp. I’m not fully sure if the talk is about solving the oracle problem or introducing a new idea called TDP (never heard before). They don’t seem to be the same thing. I might be wrong, but the description sounds a bit unclear. I’ll assume the topic is about solving the oracle problem with AI testing AI.
• Short time value: ** (Solving the oracle problem is applicable to various other areas other than AI. Testing in general benefits from knowing more about the oracles. This could be immediately transferred to my current work.)
• Long-time value: * (This helps me understand the AI testing (and AI doing the testing) and the problems that AI can solve in development.)
• Steal-ability: * (The vagueness of the description makes it hard to determine the aspects I could further advance. Test automation applications might be the most direct useful things for me.)
• Challenge-ability: * (I believe the challenging will be easy when moving from AI world to human intelligence world and applying the skills to oracles in human testing.)

Milan Gabor - Security Testing For n00b Testers?

I have been keeping security testing at arm’s length due to it being highly technical craft. Lately, I’ve come to realize that my job as a coach is somewhat like those doing security assessments and analysis. Where I show the problems in testing practices and skills, sec-testing shows problems in programming practices and skills (perhaps in platforms, tools, etc.). I have always had some curiosity, but the first step is a hard one to take. I hope this talk kickstarts my thirst for sec-testing.
• Short time value: *** (I’m a n00b! The first steps are very valuable to me getting a grasp of what security testing is and can be.)
• Long-time value: ** (On a long run I can be more certain when talking to my coaching clients about the importance of security testing.)
• Steal-ability: * (In this case “making it my own” isn’t about stealing this but making it a push to the right direction.)
• Challenge-ability: - (With quite a narrow knowledge on the subject but great enthusiasm, I see myself being happy to become a non-n00b.)

Jörgen Damberg - The Luxurious Development Future – With The Obstacles In The Rear View Mirror

My work is situated in a highly agile world with loads of CD/CI-pipelines and test automation, I’m intrigued by hearing more about AI and CD working together. Knowing the obstacle and how to move past them helps me coach teams in a way that immediately brings value to their daily work.
• Short time value: ** (This subject and the skills are quite transferable to my work immediately.)
• Long-time value: ** (On a long run I can coach teams to enhance their CD/CI pipelines to make their life easier.)
• Steal-ability: - (Building my own version of this talk is quite farfetched.)
• Challenge-ability: * (While I know a fair bit about CD/CI and the problems we have, challenging Jörgen and helping solve the actual problems.)

There you go!

Well, that’s my view on a few of the talks and keynotes at Q4Q conference. I’m not saying I attend all these talks, but I feel they might be good candidates for my itinerary. I encourage all of you to comment on what are your views about these talks and other talks as well. If I happened to comment a talk you’re presenting, please give me comment where might I be mistaken. It would be lovely to hear from all of you!

BR,
Pekka “Testing pastor” Marjamäki

Test Strategy in 10 minutes

2017-01-25T14:57:00.001+02:00

This post covers both the workshop I did on test strategy at Solita as a part of the Testing Tuesday and the extempore workshop I arranged at the Nordic Testing Days in 2015. While both had the same agenda, they were vastly different. (Why this post is published now is because it had converted into a draft which I noticed only now.)

The one at Solita

The workshop was not supposed to be a slide show, like none of the workshops arranged at Testing Tuesday. Once again I drew stuff on the white board and let rip. I started by describing testing strategy quickly. Then we discussed about project elements, product elements and quality aspects. These were loosely based on the Rapid Software Testing models. The audience gave ideas on what kind of elements we need to take into account when choosing a test strategy. There is no comprehensive list on what we came up with, but we had a whole lot of ideas ranging from schedules to "pissed-offness" and expected user behavior.

After we covered most of the areas, I split the audience into three groups. They all were supposed to create a testing strategy in ten minutes. The product I chose was a web shop that sells knick-knacks and mails them to people. After ten minutes I had three completely different strategies.

The first one was focused solely on money. They mapped out every aspect that could hinder the income of revenue and prioritized them according to importance to the "owner" of the store.

The second one was a "software engineer approach". That group mapped out all the aspects that were important to different kind of engineers. There was an aspect of security testing, transaction testing, happy day testing of known processes and some complementary approaches. There was no prioritization but there was definite focus on tools and know practices.

The third one was focused on business processes. They mapped out as many user stories as they could and dissected them to steps. They then tried to figure out what kind of a prioritization would make sense to test the processes.

In 10 minutes we had three outstanding drafts of testing strategies. All of them had different approaches and they the strategy supported the focus they had chosen. They were not comprehensive, nor should they have been, but they were "good enough" to start testing the most important thing as soon as possible. We discussed the fact that when combined these three could actually complement each other. In a coffee break, we can create a draft of a strategy and even introduce that draft to a potential customer to explain our strategy to test their product.

All in all, the workshop was a success, since it spawned a new way to think testing strategy. I never thought I could choose a simple focus like "money" as the guideline of my testing. It does reveal the importance of talking to stakeholders to understand their values and needs. Without any templates or predetermined practice every team could conjure an awesome strategy which seemed even executable after they explained what they thought.

The one at Tallinn

Feeling confident on the outcomes of the workshop, I agreed with Helena Jeret-Mäe that I would do an extempore workshop during a coffee break of the Nordic Testing Days (see here). The workshop was supposed to be on the last day. I dragged a white board to the hallway near sofas and gathered people to do the exercise. I was able to gather a couple great minds of software testing on the sofa including Erik Brickarp and Santosh Tuppad. The workshop started by me explaining the idea and then I gave the same task to them: "Generate a test strategy in 10 minutes."

The problem was that the pro testers weren't too happy with the vagueness of the context. They wanted to know more about the product, more about the stakeholders, more about the project. In the end we didn't actually generate a context map for the product (plus some testing strategy elements).

The best outcome for me was (once again) to observe experts in their work and how the dynamics within a group actually work. Also the lack of structure was something they pointed out. Erik mentioned that we could have described four key aspects of the product and then figure out how to test those. Where the first three groups I had at my office all chose a focus, we had none. We could have spent a few minutes in the beginning to define where we would like to focus (even an arbitrary focus) and then create a strategy based on that. There were hints of focus surfacing when they interviewed me about the product, but none that was chosen as the key thread.

What next?

Having had two vastly different workshops on the same subject, I think it makes sense to arrange these even more. The original idea to this came from Fiona Charles at EuroSTAR 2013, but I think we approached it quite differently. I am planning to do these extempore workshops at every conference I attend, since it makes sense to give people a chance to try their skills at this. Every time I get a huge amount of pointers, ideas and lessons learned. I would think that it is the conversation that ensues rather than actually creating a strategy that counts.

The key lessons learned in both sessions were:
- The dynamics in the group determine a lot what kind of strategy is created
- Know your stakeholders!
- Choose a focus as a skeleton and then fatten it up
- Don't over-do it! Ten minutes might be enough to start testing the most important thing.
- Have some structure, but keep ideas flowing

When you see me at a conference, come ask when am I gonna pop out the white board. It might be the next coffee break. ;)

- Peksi

Mushroom-picking heuristic

2017-01-23T14:32:00.000+02:00

Imagine this: You are in a forest and you are trying to find juicy mushrooms. You'd like to find some porcini, black chanterelle, maybe some yellow bearded milk-cap. Edible mushrooms nonetheless. Before you go, do you need something? Perhaps the following:

the calendar which shows different mushroom appearance into your local forest (not too close to habitat because mushrooms ingest heavy metals)
maybe some research on what the mushrooms look like that you are trying to find (also pictures thereof so you don't pick something poisonous that looks vaguely like edible mushrooms)
some knowledge on how to pick mushrooms (pick them up intact and one piece either by twisting or pulling)
maybe choose the weather when you go mushroom-picking (the mushrooms should be rather dry when being picked up)
prepare the mushrooms as soon possible (remove sand, pine needles, moss, etc)
use proper tools (a knife, a brush, a basket instead of a plastic bag)

These are things that you might want to consider when going out for mushrooms. Now, these are all preparatory things, bits of knowledge you might want to have before actually going to the forest. Obviously you can go without knowing these things, but you may end up with no mushrooms or worst case poisonous bastards like amanita or cortinars. The trip to the woods might have been productive nonetheless - you got fresh air and some exercise, maybe you had a good chat with a fellow mushroom-picker. Not all unprepared trips are totally worthless, but you need some preparations to achieve good results.

How does this translate to testing? You prepare yourself to the testing task by doing almost same things you do when you go mushroom-picking. Like so:

You check the schedule for the most convenient time to do specific kind of testing. (In January you might want to ice-skating instead of mushroom-picking, which might still be fun.) If you're doing usability testing, you might want to choose a time when there is something someone can actually use. When doing penetration testing you might want to pick a time when there is something to penetrate. Cuz if you choose the timing badly you might not achieve the best results. Also checking the schedule gives you clues on how to time-box the testing.
You might want to research the subject of testing. What should you be looking for, what things you expect to discover, what are the risks that are already known. Perhaps you want to learn more by exploring the product, by trying things, playing and clicking around, banging the keyboard with a shoe. You might have pictures of the GUI or architecture schematics, maybe a person to help you go about the product. Like mushroom-picking, you can stumble on interesting things, but to recognize the important, the critical, the alarming stuff you might need to do some research.
You might need knowledge on how to do software testing. By clicking around without a purpose might not be good testing. A good tester has a skillset that she utilizes to perform good testing. It is also important to know the domain, how to perform testing in that particular product/domain/service.
Choose the weather when you go testing... Urhm... Testability and configuration, choose the best starting conditions, datasets, timeslots, loads, etc. to achieve the best testing performance and to find interesting things. You might want to do testing when the backend is performing poorly or the network connections are bad. Maybe choose a dataset that is production like or maybe it should be a fuzzing test to generate weird data to the APIs.
Prepare your mushrooms. Deliverables! You should take notes on your testing performance. This is to help you steer your testing, generate ideas that couldn't yet be executed, dot down risks and bugs you find. You can then explain to other people what you did, why you chose to do specific tests and checks, what did you find. If needed, prepare a useful report on the testing you did.
Use proper tools. Testing is about using tools, obviously. Most important tool is your brain! Use it. Also use tools to help do things that are difficult or time-consuming, keep your concentration while testing. Use scripts when they are useful, record your screen, have quick note taking equipment. Use other people! Two brains are sometimes better than just one... A person can be a tool!

(This is not comprehensive list in any case. You might want to take other context variables into account to achieve the best result when you actually go testing.)

I'm now in the woods with my wellies on, my trusty 'shroom-basket, a J. Marttiini mushroom knife, and a backpack willed with sandwiches, a “Book of Mushroom and Black Magick”, coffee and some chocolate. Maybe a map, a compass, some survival gear if I get lost in the woods. I want to be prepared and tooled up. How the hell do I find those mushrooms?

This is where a Lévy Flight heuristic kicks in (a heuristic mentioned by James Bach at CAST 2014). It is an algorithm by which animals (and humans) go foraging. "When defined as a walk in a space of dimension greater than one, the steps made are in isotropic random directions." says Wikipedia. Essentially doing something in one spot until you move to other area to do something there. So, I stand on the road and head to the woods. I try to look for sweet spots in the woods, like decaying fallen trees, dry mossy areas under pines or furs. If I have dome my preparations correctly I look for these areas and I might know where to find them. So I start roaming in the woods and stumble on an area that has something interesting. A fallen tree! Yay! Maybe I'll find some black chanterelle there. So I look closely at the area and spend time there, perhaps picking some mushrooms or just scouting the area for clues where I might find some. After a while I head to a new location keeping in mind where I am in the forest.

So I move around the wooded area in a pattern that tries to achieve the best coverage of the important areas. The pattern might seem random, but I have a mission which I am trying to fulfill with the choices of direction to wander. When I am halfway on my walk, I might want to go towards the road so I don't end up too far when the sun goes down. I spend time on areas that are either rich in mushrooms or interesting places in themselves. Maybe I learn something while scouting for porcini, something about birds or types of moss I tread on. Maybe I note down areas that have some other mushroom that I am not intending to pick (you don't want to mix mushrooms in the same basket - I don't know why...). I take mental notes, maybe write stuff down, mark places on my map. All the while trying to achieve a goal I set for myself before I went foraging. On my way back I stumble on an abandoned building. Cool! I might take a look inside and maybe I find something interesting. Maybe an old newspaper or a book? I might spend time there even though I was set out to pick mushrooms. This is interesting new place and I want to know more of it. So I deviate from my initial mission and investigate the building. It's apparently someone's old home and its walls have sunken in to the ground. Maybe the architecture of the pre-WW2 era interests me, maybe the newspaper has some information from the "ye olde times". Maybe the book has a letter tucked in between the pages. I allow myself to deviate because this might be more important than mushroom-picking.

Back to the testing world. The woods turn into APIs, GUIs and code. The moss becomes the date on which I tread on. The mushrooms... They're not bugs, if that's what you thought. Mushrooms are information, relevant information. It can be about a behavior that is annoying the user, an error message in the wrong place, a risk that needs to be communicated to the stakeholders. There might be bugs, but there is so much more. The you go foraging in the software you can apply the Lévy Flight heuristic either by accident or purposefully. It is called focusing and de-focusing. You focus on some area to find interesting things for some time. Then you move to other area. If the area you first stumble upon is hugely rich in things waiting to be discovered, you might spend most of your time there. Or you might just stop there briefly and look for more important things to discover.

You start with a mission and you head out to accomplish that mission. You take notes and notice things. You investigate things that look and feel important. You forage information on the product under test.

Here's a scenario that might give clues to choosing mission for your foraging. On Monday you wonder if you should go picking mushrooms. It's a fine day, but instead of going head first into woods you barely know, you go investigate. You take your dog with you and go scouting the forest. You find a batch of blueberries and eat a few. Oh, they're so nice! The dog, Rover, eats some also. On Tuesday it rains. Bummer! So you decide to go to a shop and buy some equipment for the trip as soon as the rain stops. You decide to get a basket that has compartments for different mushrooms. You didn't even think of it before talking to the shop keeper who's apparently an expert on the matter of picking mushrooms. Great find! On Wednesday you are called to the office for an important meeting. A nice, sunny day wasted in meeting. No time for foraging today. On Thursday you get your gear, your dog and head out to woods. You check the sweet spots you discovered on Monday and pick delicious mushrooms and even some blueberries. On Friday you make delicious mushroom stew with some potatoes and carrots. Then, to top it off, you make a blueberry pie. All the recipes for these you checked online but used your own twist to make them your signature dishes. A perfect way to start a weekend.

To sum it up, Mushroom-picking heuristic is a two-fold heuristic:
- First it is a preparation heuristic. It helps you create a mind model that allows you to plan for the up-and-coming testing session, testing phases, etc. To an acceptance testing session one might prepare differently than to a security testing phase. Nonetheless testing needs preparation and a good way to tackle the preparation is the Mushroom-picking heuristic. You should make the preparing heuristics to match your own context. Think of tools, background knowledge (oracles), time-frames and constraints, people attending the sessions, bug reporting procedures, facilities, etc.
- Second it is a testing management - a steering heuristic. It helps you move from one focus area to another. Focusing and de-focusing is one aspect. With note-taking you can keep track on the areas you have covered and to remind if there's need to return that area. Keep in mind the Stopping-heuristics so you won't get stuck too much in one area.

The Mushroom-picking heuristic is not comprehensive nor should it be. It is a model that might work or you may find it useless. Perhaps you might try it and give me feedback on how it worked and how I should improve it. It is a work in progress.

Have a tasty spring!

- Pastori

"Thinking like a tester" workshop

2015-07-14T14:15:00.000+03:00

As I have mentioned before, we have this round of workshops under the concept of Testing Tuesday. I have already covered two of the latest workshops as blogposts. This one is an attempt to cover the first of the seven, a workshop called "Thinking like a tester".

Why did we talk about thinking?

I like to think that there is no testing without thinking. If thinking isn't involved, it is not testing. Machine doesn't think, thus it just checks. Human challenges, observes, infers, models, etc. all the time while looking at a test object. A human tester thinks. That is why we need to practice different ways of thinking. It's like exercising a muscle, but the muscle is our brains.

There are number of different ways to think, many of them overlapping, and we should try to perfect those skills. It is valuable to recognize different patterns of thinking to be better able to solve problems. Testing is essentially problem solving, since we try to notice things and then afterwards try to figure out if this observation might be an issue. By having multiple tools in our tool box we don't have to rely on just one way of thinking ("When you have a hammer, all you see is nails.") and that makes solving the problem much easier.

My goal with this workshop was to introduce a few different mechanics of thinking to the audience and have them use that mechanic to perform an exercise.

What did we cover?

We were able to cover three exercises. The first two exercises were borrowed from improvisational theater. The first one was "reinvent the wheel".

I split people into groups and gave them the assignment to create a method for transportation. The only things given to them were the fact that the context in which they were supposed to solve the problem didn't have a wheel yet. They weren't supposed to create the wheel but create an alternative, as effective method of transportation. The thing was a bit difficult since I told them to start every sentence in their brainstorming with "Yes, but". This was an effort to make people challenge the already agreed.

People started to do the exercise but it seems that they didn't fully see the point of that exercise. My attempt was to make people challenge the assumptions and the ideas already on the table, thus making it an exercise in critical thinking. I might have missed the mark slightly, but people did have fun. I noticed that people required a leader in their group and some catalyst to provoke the challenging. I visited the groups and challenged their ideas by asking a question and then replying to their answer with a "yes, but" phrase. That stirred the pot slightly. I believe it became an exercise on team dynamics more than thinking patterns.

After 10 minutes we debriefed the ideas they came up with and moved on to the next task, "Reinvent storing".

Once again people worked in groups. The task was to invent a method to store things without using shelves or stacking things on top of each other. They once again had two facts about the context: There was no concept of shelves or stacking, and they had to begin an idea by saying "Yes, and". This was supposed to be an exercise on creative thinking, finding new ideas based on the old ideas, accepting what is already decided and building on that.

The task was more fluent than the first one and it spurred some crazy contraptions to store items, from pulley-operated platforms to portable black holes. There was certainly creativity in the air! Once again I felt that the exercise fell a bit short, and people did have questions on how they related to testing.

The third exercise was a bit shorter because it took so long a time to debrief the first two tasks. The third one was an exercise on lateral thinking. I explained it on a broad level, then I gave them a problem which they were to solve using lateral thinking.

The story was something like this: There is a merchant who owes money to an evil man who is in love with the merchant's daughter. The merchant can't pay the dept. The evil man proposes a wager. He puts a white and a black stone into a pouch. If he pulls out a white stone, the debt is forgotten. If he pulls out a black stone, the debt is paid in full AND the daughter is forced to marry the evil man. There seems to be a 50/50 chance. However, the evil man changes the white stone into another black one.

I asked the groups how would they solve the problem so that none of the participants lose their face (i.e. is revealed as a liar, is forced to marry, gets killed, etc.). The task was once again pretty difficult since the premise was so vague. I then had to answer a lot of clarifying questions about the problem before groups could actually start working on their solutions. They managed to think outside the box on many occasions. The ideas were quite feasible, I think.

What was the most valuable thing to me?

Having done three exercises on thinking, I realized that it was just a scratch of the surface. I thought I had time to do a "Thinking fast/slow" exercise but everything went by so fast. The essential thing might have been just having fun with my coworkers, making them do something out of the ordinary, promoting testing as a thinking activity as opposed to a technical task that creates test cases run on some virtual server.

The tasks were obviously quite difficult, but it gave a good ground work for the next workshops. The people were the essence, not me blabbering in the front (although I like that also). The more workshops I held, the more attendee driven it became. I facilitated, they provided the material.

What would I do next?

Since there will be another "tour" for the Testing Tuesday, I will refine this workshop. I will explain in more detail what the task is and arrange more time on people to explain what the connections to testing could be. Instead of making it a lecture I give the mic to the attendees on why would it be important to think. Maybe I'll try to add some other thinking exercises, like "Think like a freak" and the "Thinking fast/slow".

I am thinking on doing a blogpost on the lateral thinking, since I find it really important skill. I believe few of my community colleagues have already done that, so I might have to take a different approach on that. We'll see.

Anyhow, this was the workshop on Testing Thinking. If something wasn't clear or you have ideas how to make the workshop better, drop me a comment.

- Peksi

Testing technique workshop

2015-07-07T10:17:00.000+03:00

The last part of the Testing Tuesday’s “Test Pistols Tour” was a workshop about testing techniques. The original plan was to have a list of techniques and then exercise to learn those techniques. The scheduling caused us to change our approach because we had no time to create environments for exercises.

So, I turned to the community.

When I dragged my but to the conference room I was expecting just a handful of people, 3 or 4, but eventually we had 7 people. I think there was a bit of a tour fatigue in the air, since this was the seventh workshop. I had seven brave soldiers at the meeting room.

“I have changed the rules!” I said. “I ain’t gonna tell you about testing techniques. You’re gonna tell me about testing techniques.”

Now the plan was the following: Pair people up, make them test something and describe their testing. Then discuss what kind of a problem they were trying to solve with their chosen approach. Sounds simple enough. I was a bit uncertain if people could describe their testing to a level from which I could derive a technique. The challenge was thrown.

I told them to open Word. The assignment was to test the “Find and replace” functionality and describe to you pair what you did and why. I asked some questions from the teams during the 10 minutes of testing we did and made them focus on actually telling why they chose to do something. After the ten minutes, we started talking about how the testing was done. These are the key points we came up.

Hot-key testing

The first team started to describe what they did by explaining how they searched for the functionality. They were trying to find different ways to access the functionality. They found out that on different operating systems the hot keys vary. More so, the hot keys are customizable thus enabling different combinations. “Ctrl+F” was the easiest way to find the function, because it happens to be the same on many other software also (comparable product and familiarity to user). On Mac there wasn’t a “Ctrl+F” so the hot key was a bit difficult to find.

Based on their approach to using the hot keys we gathered that the technique can be used on many Windows based software (and why not Mac based, but I don’t have the experience to use hot keys quite yet). The commonly known hot keys like “Ctrl+C / V / X / Z“ etc. are quite easy to test. The tests are quick and cheap, very generic thus making the technique quite useful.

Premise variance testing

When the group was trying to find different ways of accessing the functionality (hot keys, context menus, sidebars, ribbons, etc.) I asked if it changes the behavior of the functionality when you access it from different origin points. If you change the premise, can the functionality change?

We started to think if we could apply it to various other solutions and products, and we came up with “premise variance testing”. When one changes the premise condition to a function, there might be changes in the behavior. This kind of technique can be derived also into a “step variance testing” where you mutate a single or many elements within the process.

Help testing

When one team was trying to figure out how the function worked, they pulled up the manual. The help can be quite simple for experienced user but it acts as an oracle on many occasions. During help testing one can testing the help itself against the product and test the product against the help. In either case, one acts as the test object and the other as the oracle.

This technique could be derived into all kinds of oracle material testing. We can test against oracles that are used by various stakeholders, e.g. requirements or design documentation. We test the product and ask “is this ok?” and we then try to solve the problem by referring to the oracle. We might have an oracle (e.g. human oracle telling how it should work) and then test the other oracle based on the new knowledge (the human oracle disputes the written document). The “Help testing” might become “Oracle testing”, but the name doesn’t give me good vibes. ;) A help could actually be any material that helps us do testing.

Data roundtrip testing

A team was testing replacing a word with gibberish and then replacing that back to the original value (“Pekka” -> “ASDFGH” -> “Pekka”) and they wanted to know if the same amount of entries are changed. So basically the idea was to revert the original data without actually reverting the state. Mathematically I think this is called “inverse function”. First we apply the normal function followed by the inverse function. Roundtrip actually means that you return to where you started from.

We had a discussion if the “roundtrip testing” is actually a generic thing that can be done to a state also. It is possible to revert the system to previous state without any information whatsoever about the state that was visited. This might actually be a problem in itself, but we chose to narrow our testing technique to mere data.

Minimum data

We did find some testing ideas while describing techniques and I think this was worth mentioning. A team wanted to test with as little data as possible. That is a one variable of premise variance testing where we solely focus on varying the data instead of the states. This testing can be the defaults form testing, testing without any inputs (NULL, n/a, whitespaces, etc.), removing metadata, etc. and it can find bugs in the exception handling logic.

Conclusion

All in all, the testing techniques we found have already been described in other sources, but these made sense to us and felt important. The terms are more tangible than “product tours” or some techniques found in books. We defined the terms and we learned how to describe them in a language that suits our context.

I know that at least the premise variance testing stuck. I have used it a few times now to describe what I do. It makes sense to repeat this exercise again with a different depth. Then uncover new, undescribed techniques and make them part of our tool box. After there has been a handful of these sessions, we might have enough skills to describe our testing to any stakeholder in a language we share and understand.

Sadly that was the last of the Testing Tuesday workshops on this tour. There will be another tour in Helsinki, and I shall write up as much as possible from those sessions.

- Peksi

What happens when a wannabe rockstar does a lightning talk?

2015-06-23T15:00:00.000+03:00

"Are you f***ing ready to rock?!"

The crowd is wild. The stage is lit. The announcer get on the stage.

"Ladies and gentlemen! Are you ready for the coolest rockstar in the world?" The crowd roars its approval.

"Are you f***ing ready to rock?" The crowd goes wild...

Ok. That's not how it happened for me. That is what I wanted to happen, when I did my lightning talk at the Nordic Testing Days 2015. Actually, it went something like this:

Helena Jeret-Mäe get's on the stage. "Next we have Pekka Marjamäki on the topic of Testing Tuesday", she says. Then I get up from the floor and walk in front of the room full of people. I have my hat full of badges, my Superman t-shirt, suspenders handing down, all cool and ready to rock the place.

"OK, people!" I start my performance. I divide the room into two groups. "The group on this side shouts 'TES' and the group on this side shouts 'TING'. Ready? Tes-ting! Tes-ting!"

The crowd starts shouting. They shout "testing". "Louder!" I shout. The room is roaring for a minute or so! Then at it's peak, I silence the crowd and start my talk on Testing Tuesday.

Testing Tuesday doesn't sound that weird. It is a concept me and my colleague Petri Sirkkala from Solita came up with. It spawned from a need to teach testing at my company. I will explain how it goes in detail (accompanied with a video, perhaps) in a later post. In the Nordic Testing Days 2015 I briefly introduced the concept. It is 7 weeks every Tuesday, each week having a workshop of it's own and helping our colleagues with their testing problems. The most recent blog post is a write-up of the 6th Testing Tuesday workshop. Apart from actually helping people test, strange things happen during the Testing Tuesdays, e.g. us two testing dudes walking around the office shouting "Testing Tuesday" and playing Sex Pistols from an old cassette player, or posting testing problems on a white board in the hallway.

The main goal of Testing Tuesday is to promote testing and to sow seeds of interest into people who aren't yet that much into testing. The second goal would be to help people in their testing related challenges. The third one is to have fun.

I think my objective at the Lightning talk was to convey the energy and enthusiasm we pour into the Testing Tuesday. The attitude to fight against poor practices, the bravery to stand up and challenge, the eagerness to improve. Honestly I can't remember what I actually said during the talk, I had so much fun. I do believe that people got the key points out of my talk.

Be open about your passion towards testing.

Share knowledge and help others.

Be brave and have fun.

"We want more! We want more!" The crowd shouted after my talk... At least I wanted it to. Alas, it didn't...

- Peksi

Bug handling workshop

2015-06-18T08:45:00.000+03:00

I am running a thing called "Testing Tuesday" at the office. The concept is simple: Sanctify Tuesdays to software testing. This comes in form of helping project teams to test by helping them solve their testing related problems, promoting testing in every possible way. And to top it all, an hour workshop on some testing related topic. I will do a proper write-up on the subject later, but I wanted to share the coolest thing that happened during the 6th (out of 7) Testing Tuesday. The topic was "Bug handling" and the results were really awesome!

A week before this workshop we had a testing oracle related workshop, which I then promoted on twitter. I had classified three bugs and I mentioned those in my tweet. I then had a tweet exchange with Michael Bolton about classification.

That discussion made me want to redefine my Bug handling workshop, since I saw that people I work with, me included, might have quite a different approach to handling the observation we make and receive about the product we work with. So after talking to Michael on Skype I decided to do the following:

Have people define a bug handling process from the very beginning to the very end. Then plot it out, draw diagrams, etc. to explain it. Then focus on the difficult parts and try to enhance the process.

So we started by defining where does "bug handling" start. I started by saying that it starts from the moment there is code, but I was corrected. Bug handling, or observation handling, starts with the first indication or deliverable of work. That might be the requirements documentation, project plan, or whatever tool that is used to run the project. It can be unwritten requirements. It can even be an idea! From the very beginning we start testing and observing the subject. It is those observations that might require handling.

Based on the purpose and the need, we define the way we report, write down, take notes, etc. If we are talking about testing ideas, the observations could be about the idea or the repercussions thereof as statements voiced out. When testing a software, observation may be something you see, hear or feel, that you write down or record. A bug report is a description of your observation, which is then used in various ways to help understand the observation.

https://commons.wikimedia.org/wiki/File:Magnifying_glass_icon_mgx2.svg

"Observation is the active acquisition of information from a primary source. In living beings, observation employs the senses. In science, observation can also involve the recording of data via the use of instruments. The term may also refer to any data collected during the scientific activity." - Wikipedia (Observation)

It is these observations that we then start to analyze. It can be done in many ways. An observation as a bug report can then be inspected to its validity. Analysis might require communication with the stakeholders, tools, classification algorithms, etc. It is these actions that we employ to analyze the observation. It can be a snap decision or statistical analysis. Whatever is done during the analysis, there is an outcome. The outcome might be to trash the bug report, invalidate the observation, classification of the issue, pigeon holing an inference, describing a behavior in a more concise way, etc. Analysis creates something out of the observation.

Based on the analysis, there might be an action to deal with the observation. It can be a change in code, adding something to a document, building a new tool, fixing a leaking pipe, redefining an argument, etc. There might not be any actions towards the original subject of observation, but perhaps to the process with which we test and challenge. There might even be some actions to make the observation or the analysis different. Maybe a process improvement, learning a new skill, etc. Actions might require on the sub processes and further actions. In the end, however there is a follow up on the actions.

The follow up usually happens after the action. The follow up depends on the observation in a sense that there might be a need to reconstruct the situation in which the observation happened. There might be a need to refer to the earlier version of the subject under test. There might have even been a shift on the subject based on the analysis. And the action itself dictates the follow-up and the magnitude and the nature of it. The follow-up might require regression testing on a bug finding, another round of reviews, rerunning the test automation suite, rethinking, etc.

These four basic action became the guiding principle in all our testing processes.

Observation - Analysis - Action - Follow-up

But it wasn't enough. Every single bit of these actions required supporting activities. Observation required note taking, testing skills, tools, etc. Analysis requires processes, practices, domain knowledge, etc. During our workshop discussion I picked up some key words that were used. I then generated two clouds: The core activities & the supporting activities. The core activities are not enough on their own. The context states what kind of supporting activities are needed to make the core valuable. The supporting activities are of no value without the core, but the core loses value without any supporting activities.

Here are some of the things we came up.

Like I mentioned, all this is useless without the context. Every scenario requires a context that states the most useful way to approach the "bug" handling. Pair review requires different supporting activities than Beta testing, but they both have the core activities. The tools that are used might differ: you can use post-its, JIRA, QC, email, surveypal, etc. to communicate your observations. During the analysis those observation might be enveloped by a tool to create virtual stickers and notes. There might even be a template that is used to report an observation. Those observations might be classified, prioritized, trash or whatever. Based on the analysis at some point in time, something might be done. When I say might, it means that it is possible that an observation is lost and not acted upon. You can call it an "action" if an observation gets lost, but it is philosophical. Let us assume that every observation has an action. The action might require communication, changing something, tools, practices, processes, people, etc. Those actions then have follow-ups. That follow-up can be enveloped in the same tool that it was when it entered as an observation. It can even have a process of its own.

To conclude, there is no best practice to handling observations. Not every observation is a bug. Not every bug needs to be handled the same way. What was the most valuable thing I got out of my workshop was "mind the context!" Think of the value of your process to stakeholders. Think of the needs that need fulfilling. Think of the feedback loop. Think of the people involved in different tasks.

That is all today.

- Peksi

First thoughts on people and bravery – Nordic Testing Days 2015

2015-06-07T17:09:00.000+03:00

Nordic Testing Days 2015. Three days of tutorials, tracks, workshops. Three days of people. Three days of awesomeness. One might think it is a cliché but a conference is nothing without the people.

The first thing on day one, at breakfast I saw Kristoffer Nordström. My Swedish friend with a knack for python. After that moment I knew the conference couldn’t be anything more than pure awesomness! Then I met Guna Petrova and Helena Jeret-Mäe at the registration. Those women (among the other organizers) are the beating heart of the conference. Then everywhere I went, new and old faces. There was so much energy in the air I could breathe in testing and conquer the world with it.

That is how it feel to attend a conference: you feel everyone’s energy and be empowered by it. Santosh Tuppad (whom I met during a coffee break on the first day) said the same thing. The people around you give you energy. If the people just happen to think alike, they can give you much more! I have no idea what is the scientific basis on that, but I think it has something to do with brainwaves, facial expressions, and false belief that there is anything scientific around it. ;) At least I felt like a king.

Now that the conference is over, I am spent. I think me having a nagging cough ate part of my energy, especially on the third day (and Cards Against Humanity until 3am had nothing to do with that). I was able to gather enough energy to pull an extempore workshop in the hallway during the coffeebreak where we tried to develop a testing strategy for a webshop. It became a crowd magnet and we had huge fun doing it.

What was the topmost thing for me as a delegate and not as a speaker (although I did my best to speak out whenever I could – the tutorial, workshops, lightning talks, the hallway), I felt that I was a promoter of bravery. Bravery to speak out. Bravery to challenge. Bravery to be challenged.

I think being a software tester is about being brave. We stand on the podium in conferences and we spill our guts in front of people. Rob Sabourin was almost in tears at his keynote. Erik Brickarp admitted failures and even arrogance in his track. People make mistakes and they get up to talk about them. It is bravery to ask questions from the audience. It is bravery to ask “Huh?” when one doesn’t understand.

So, I’m going to be brave. In everything I do, I shall try to be braver than the next guy. I shall show that I have the guts to do things, swim against the current, challenge. Maybe then other people have it easier to be brave also, even a little bit. Maybe I can show example and lower their threshold. In the following 12 months that bravery shall take me in to every possible event where I can speak up.

As for the future, the following might make it as blog posts (I haven’t fully decided yet):

My lightning talk on Testing Tuesday (TES-TING! TES-TING!)
My workshop on Test Strategy in 10 minutes (We didn’t make a testing strategy at all)
Kristjan Uba’s tutorial (Rogue Legacy to win!)
Blood sausage testing (don’t ask… or ask Sami Söderblom)
Context dependency (based on Bill Matthews’ and Ilari Agaerter’s tracks)
Cards Against Humanity (I just want to write something really clever on this)
Naked Tester (I hate you, Richard, for injecting this idea inside my head!)

The conference is over. The lights have gone out. In the end, everyone’s tired but excited. I want to thank the following people for great discussions throughout the conference: Sami Söderblom, Kristoffer Nordström, Erik Brickarp, Santosh Tuppad, Richard Bradshaw, Jekaterina Krivega, Kristjan Uba and Ilari Henrik Agaerter.

I want to thank the organizers of the Nordic Testing Days 2015 for every single thing they did! The light dancers, the magician, the games, the venue, the food, the drinks, the people! I will see you next year! I promise!

Test Pistols live forever!
- Peksi

Intelligent practices of software testing

2015-05-13T12:51:00.000+03:00

Intelligent practices of software testing

(This was first published at dev.solita.fi)

Note! I am not using the term “best practice” here. Intelligent practice is something that helps people develop their practices into more suitable for their need. We actually should stop using “best practice” term. Instead we should use whatever helps us solve the problems at hand. The problem solving should come from people and their skills. Influences should be taken from everywhere! Practices should be molded to facilitate problem solving in YOUR context.

Very well. I came up with the following guidelines to help create a better testing environment for me and my colleagues. I am not trying to invalidate your practices that have been found to be best fitting for you. You should keep the practices you deem appropriate for your context. I encourage to revise your practices based on my own findings. It is up to you to change what ever you see reasonable, if anything.

Fight ambiguity with openness and communication

A few examples on ambiguity:

The (written) requirements are vague and ambiguous at best. Usually they are out of context and/or vacuum packed. I remember ISTQB mentioning that “It is testers’ right to deny ambiguous requirements”. I believe it is the testers’ obligation is to address this as soon as it is found. And by addressing I mean talk with people. “I cannot figure out how the system should work. I found out that it works like this. Is this OK to you? If not, can you help me determine how it should behave?”
The test cases are not concise. If we are to perform good enough testing we need to do testing. Writing test cases might be testing – executing test steps from a test case might be testing. This all depends on the skills of the tester. If the material we base our testing is poor, we need to be open about it. If we feel that we cannot do good enough testing, something needs to change. That change comes from talking about the issues, being open about the difficulties.

If something is not clear, make it clearer. Find the information, people, resources that helps you make it clear. Learn from difficulties and be open when you face them. Hiding problems rarely leads to anything positive.

Fight ignorance with eagerness

Ignorance comes in many forms. One can claim she doesn’t know enough about the product to test it. Ignorance might paralyze us. Tasks can be daunting and we might procrastinate because we do not know some specific thing about the subject.

Enter eagerness! Try Proof of Concept type of actions. Try sandboxing the test area. Try having fun. Try getting a group of people who might already know about the domain, the product or the like, and test with them. Try walkthroughs. Try anything and everything to solve the problem. Be eager to to solve issues. If you can't solve them, be eager to get issues solved. Ignoring issues rarely leads to anything positive.

Fight über control with good-enough documentation and reliance to skills

Sometimes the aforementioned (ambiguity and ignorance) might lead into not trusting our ability to do proper testing. That might lead into a form of control that requires a vast amount of documentation and reports. There is a three-fold solution to this, I believe: rightly timed planning, unburdening reporting and reliance to people ability to the best possible job. When it comes to testing, people usually ask for test plans, test task descriptions (of various levels of detail) and test reports.

When doing good testing, it requires some planning to remove inefficiencies. That planning should be done in advance, albeit on a higher level. We must be able to plan our testing while we test, because we learn about the product, the project and everything surrounding us while we test. By timing our planning in sync with our testing, we can react to changes and discoveries more efficiently. The planning should happen as close as possible to the actual execution of the plan. Documents and plans deprecate quickly when new things are added. For example, Rapid Software Testing encourages planning and designing tests during testing. I have found out that a brief planning session before testing session is usually in order to be able to tackle the most important topic during that testing session.

We are chosen to perform the tasks because people expect we can do the task. There is little reason to stupefy the intelligent people that do things for us. Writing test cases, that basically make our brains redundant, is stupefying. In fact, it is stupid to write something that creates stupidity. “Stupid is as stupid does.” In order to be intelligent and harness out intelligent to our testing, it is wiser to write inspiring testing documentation. Missions, threads, ideas, broad descriptions, etc. encourage the use of our brains. I’d say “skill before process” and encourage to constant learning and teaching. Autonomy increases motivation see this post to do the best possible job. Critical thinking enables you to challenge your biases. Lateral thinking helps uncover possible issues. Thinking is the key, not the process or tools.

We also need good reporting off of our testing. Reports may be bug reports, testing transcripts, etc. An important thing to remember here is to focus on relevance and sufficiency of our reporting. The report should be a tool to improve and to facilitate discussion within our testing, development and/or project management. Thus I feel that reporting should be done in ways that support our cause, not because we want reports to begin with. Tools may vary from video recordings and screen captures to notebook scribbles. Anything is fair game as long as it supports the cause.

Fight measuring and quantification with reliance on feelings, observations and communication

Numbers are cryptic. Numbers can be interpreted in as many ways as there are people interpreting. Let’s say we have 100 test cases from which we have run 90. A clueless test manager might say: ”Only 10 more and we’re done”. An intelligent tester might say: “It seems we have 10 scripts to look at, but what else do we need to take into account?” Quantifying test cases (or bugs for that matter) is ridiculous. It is like counting unicorns! How many unicorns can fit into a cubicle?

A better approach to test case counting might be counting the time spent testing. Time is uniform in magnitude. Hour is as long in Finland as it is in New Delhi. What is the size of a test case? Few can tell. Measure what is worth measuring and what is objective.

If this is measuring our progress, how do we measure coverage?

We might want to ask “why we measure coverage” and then choose the metrics based on that. One good coverage indicator is a list of items in the product under test that we have touched. If an area is touched multiple times, we could be fairly certain that it is covered well enough, and we know the areas that are untouched. The human feelings come to play here. If a tester or a developer feels that some area is of poor quality, then we should play that feeling and test that area some more. A test case doesn’t tell how confident the tester is - talking about findings with the stakeholders might demolish the false confidence and lay ground for confidence based on actual findings and behavior.

Whatever you choose as your method of measuring, talk about it. The numbers are devious and one should ALWAYS talk about the coverage and confidence instead of using numbers to /prove/ why something is good. I support creating a measurement strategy that is little or no burden to the actual tester, and then use those findings to steer testing to the right path instead of proving something. Be critical about numbers because they can fool us easily. Be intelligent and critical on what and how to measure.

Summary

To summarize, my intelligent practices for software testing might include the following:

Fight ambiguity with openness
Fight ignorance with eagerness
Fight über control with good-enough documentation and reliance to skills
Fight measuring and quantification with reliance on feelings, observations

There might be more and I shall keep looking. The most important thing about these practices (or statements or whatever one might call them) is to communicate with people. Discuss your expectations and goals in testing. Discuss procedures and skills, how they can be improved. Whatever challenges you face, communication is the first step to solving the problem. An umbrella practice might go something like this:

Fight <choose challenges> with <choose solutions> and communication

If you feel I need to clarify some of the practices, give more examples or add a fundamental practice to my list, please drop me a line. I’m more than eager to discuss. ;)

I quit my job, sold my apartment and started doing what I love - TESTING

2015-04-29T00:33:00.000+03:00

People might have been wondering (or somewhere deep inside I hope they have) what has been going on in my life. I have been intentionally silent for a while now. I ain't silent no more. I believe the hibernation has been my salvation. I have been able to regain my passion and my confidence. This post is a short review of my year 2014. I'll describe some of the events that changed me and my attitude towards my career. I'll describe what made me lose my passion for a while and what made me regain it.

The beginning of 2014 was tumultuous time for me. I had done the EuroSTAR2013 talk and I was hugely perplexed by the amount of the positive feedback and the intensity of the criticism. I decided it would make sense to lay low for a while and reflect what I had done. I came to understand that I had been flying on my own hype. I didn't deliver what I had promised, I made grand plans and told about them like I had already done them. I needed to set my feet back to the ground. And it was hard.

A lot of personal changes have been happening in the past year. Among the changes a divorce. I now see how much relationships with close ones can affect ones decisions subconsciously. I must say that there were more good times than bad. However the beginning of 2014 set in motion a set of events that lead into my new found passion towards testing and coaching.

I realized during the summer of 2014 that I was utterly and completely isolated and desolated in my home, in a strange city. I cannot say how much of my discomfort came from waxing and waning depression. I do know that after getting out back to my home town, I have felt healthier than ever. So what I did, perhaps on the spur of the moment, I quit my job and moved away from Helsinki. I am actually still trying to sell the apartment I own with my wife, but I live in a 2 bedroom apartment now with my daughter. So basically I packed my things and left.

I was thinking for weeks that I regret the decision, and I might have for a while. Without a job, I found myself in school trying to educate myself with the ins and outs of Pervasive Computing at the Technical University of Tampere. I had some baits in the water waiting for a prospective employer to bite. And when finally Solita decided to give me a chance, I was relieved.

#High6 will be flying at NTD2015 in Tallinn

So, there I was once again, trying to motivate myself to study something that didn't give me the “thrills”. I mean, I like programming and scripting, I like the technology and all. I just… I am a square peg in the round hole, when it comes to formal education. The worst thing is that I keep hearing this “you should really stay in school, cuz you need the degree to get a proper job”. I feel guilty for those kind of comments. The most successful people I know or look up to aren't those who graduated from schools and universities (although they might have degrees), but those who followed their dreams. I know it sounds immature and possibly silly, but I feel I am being made homogeneous in the school.

I have realized my motivation is intrinsic to the core. It is almost narcissistically selfish, but when I follow my own reasons I get results. My motivation, it seems, is pleasure. I want the pleasure of feeling admiration. I want to do things that make me feel good. If I feel bad, I rebel, I fight against the restraints until I depress and collapse. To be able to function, I need to find things that I feel good about.

What happened then was quite miraculous. I started working at Solita to pay my bills and support my mind-numbing studying (which I also sucked at, in addition to despising my inability to study). I was just a consultant (a testing specialist) in a project, trying to find my place and role in the organization. Or that’s what I though. The environment was… magical. It made want to be a beacon of light. I saw people willing to listen to my insight on testing. I saw people seeking my company to chat about some testing problems. I was like “I found my people!”

Me talking about "How to make anyone do anything" at Solita

I've worked there half weeks for two months, until in April I started to do full week. To this day, I have been coaching three all-developer teams to test, manage their testing with Session Based Test Management, and more projects are lining up to use my services. Also I have been able to share my knowledge on coaching for my colleagues, invited to facilitate classes that are still to remain secret. This all and more. This all feels like I have regained my wings and I can fly again.

Long story short, I found my passion I thought I had lost. There is no reason anymore to fly under the radar.

I'm back - loud and ugly as ever! ;)
- Peksi

Nordic Testing Days 2015 – Conference at a glance

2015-04-13T16:36:00.001+03:00

Just to keep the momentum going, I shall tackle the Nordic Testing Days 2015 in a similar manner I did the Let’s Test. I chose the two conferences for they’re close by and I wish I could attend either or both of them this year. The real reason is that I want to keep writing, now that I have momentum. This is

Nordic Testing Days 2015 – Conference at a glance

The Nordic Testing Days 2015 is the fourth of its kind. Having had the privilege to attend the first of its kind as a speaker, I have a special kind of attachment to it. I did a full blown evaluation of the sessions I attended while I was at the conference 2012, but I shan’t do it this time. The conference is a 3 day spectacle with tracks, tutorials, workshops and more. I’ll choose the sessions as follows:

Choose one session from each day based on my familiarity of the speaker
Choose one session from each day based on my interest in the title
Choose one session from each day that I pick randomly

Those should total 9 sessions. I’ll choose 2 random key notes to accompany those.

I will use a heuristic grading system (introduced here) to determine what would be the best session for me. I will grade the stuff with Angry Birds ™ grade – 0-3 stars per area – on five areas:

Person-to-person (How will the person and his/hers work affect/inspire me or the people I know?),
Session value – short time span (How much can I get out of the session tomorrow – next year?),
Session value – longs time span (How much can I implement to my work and teach to my colleagues, my community?),
Steal-ability (How much of it am I willing to borrow and further develop to make it better and/or mine?), and
Challenge-ability (My past knowledge on the topic and my willingness to challenge the session contents.)

Keynotes

Mart Noorma’s “ESTCube-1: Testing in Space”

Intergalactic journey ahead. I would pay money to contribute to something that eventually goes orbiting the Earth. Alas, I cannot yet. Soon, perhaps. I know next to nothing Estonia’s space program, but I think this keynote requires some background checks to be able to get everything out of the keynote. Since I followed Philae landing (they had some Finnish technology there also) I am keen on hearing more on the subject.

I must admit I haven’t heard of Mart Noorma, but I think he’s not that loud on the testing scene. What are the key values here might be the inspiration to reach the stars. The short time value might be high-ish but I cannot see too much long term value in this. I might be the wrong crowd for this session, but I’m expecting inspiration and insight from Mart Koorma.

Although this keynote might be hugely inspirational, I see very little in the light of challenging or stealing ideas. It’s a shame, actually, for I am an avid science follower. The thing is that I might be expecting more of a testing approach to the keynote and less of a technical story. Experience report working in difficult situations is always good, but I don’t see myself as the optimal audience for this.

Person-to-person:
Short time value: **
Long time value: *
Steal-ability:
Challenge-ability:
Total: 3/15 stars

Rob Lambert’s “Why Remaining Relevant Is So Important”

Why is it important to stay relevant? I mean, Rob is obviously going to answer that, but why make a keynote of it? Don’t we all know, if we fossilize we are, out in the next round of layoffs? What is the big deal? What I feel Rob is trying to say is we need an attitude change. The relevance comes from want to thrive and be the best. If you’re the one who’s always on the cutting edge of technology, skills and thoughts, other people want to be like you! You become the beacon people look up to.

Rob Lambert is one of the most influential people in the testing scene. His blog was one of the first ones I started to read as a budding tester. I have met him once in person, and he’s a warm, easily approachable character. The problem is that should I have more time on my hands, I’d be more keen on approaching him with my ideas on managing testing. Alas, I have not.

Staying relevant has far-reaching influence. It brings high long time value to the company and to myself. The ideas sound like easily adaptable and with genuine examples the value might become even greater. Short time value might be in form of planning ahead my skillset. With this session and Alexandra Casapu’s “Examine Your Testing Skills” session at Let’s Test 2015, I see no reason why one couldn’t stay relevant to their company or their community.

Person-to-person: **
Short time value: **
Long time value: ***
Steal-ability: ***
Challenge-ability: *
Total: 11/15 stars

Wednesday

Kristoffer Nordström’s “Taming the Terminal-based Applications and Testing Them” (based on familiarity to speaker)

Kristoffer was the guy that inspired me into taking my Pythonian skills forward. His lessons in “Python for testers” and many more inspire many. He’s a great sport and I wish I could attend his tutorial at the conference. If the session has anything close to what I expect off of him, people will be having a hoot!

After reading the description, the tutorial seems quite useful to me. When I was doing testing at F-secure I ran into terminal-based application every once in a while, I might even have created some tooling with Python. This tutorial strikes that particular nail in my skill repertoire.

The values right now are mediocre, however, since my current job description doesn’t touch terminal based stuff. I would have rated this very differently a year ago, I must admit. Also being one of the few testing specialist at the office, I think I wouldn’t be the guy to be teaching this to developers. I could benefit from having a better understanding of testing frameworks and tools, better confidence in my skills, and have a good time at the session. Also, since I have some experience, I could challenge Kristoffer to make him hone his material to perfection. ;)

Person-to-person: ***
Short time value: **
Long time value: **
Steal-ability: *
Challenge-ability: **
Total: 10/15 stars

Kristjan Uba’s “Let's Learn: Experience Learning through Gaming” (based on interest in the title)

Gaming. My favorite way of learning. If we’re going to play games and learn from testing, I think this session is worth its weight in gold! …at least to a procrastinator and a child-minded person like me. The values are both immediate and long lasting, if done properly: one starts to seek out the games mentioned to play with their friends and colleagues, besides those games can spawn entire new epiphanies on some other testing related area.

I don’t Kristjan Uba from before, but I bet he’s the kinda guy I would get along really well. He sounds enthusiastic, innovative and funny, the kind of a person I like spending time outside work with. Perhaps, should I miss the opportunity to join, I can badger him to play some of the games on some other occasion.

Person-to-person: *
Short time value: ***
Long time value: **
Steal-ability: ***
Challenge-ability: *
Total: 10/15 stars

Robert Sabourin’s “Just-In-Time Software Testing” (random pick)

Ok. Rob has been on my radar from the beginning of my testing career, yet I know next to nothing of him. He’s one of those “one-star-should-be-three-stars” kinda fellas. I am aware of this “just-in-time” method, from some blog post in the past.

The description made me hum in pleasure. That is something, not only I want, but I need. As a professional tester I need to be able to make snap decisions about prioritization, change of focus and moving people to test the right thing. With content like that on a tutorial, I see no point to sit this one out! The values of this sessions are far reaching and immediate! These are the things I must educate my colleagues with, my community should be aware of this, and my work would vastly benefit from the skills and knowledge this tutorial gives.

For I know quite little about the subject to begin with, I see a lack of challenge-ability for me. Maybe a quick 1-on-1 with Rob might get me into the mood. Perhaps a blog post or two to limber my mind...

Person-to-person: * (I wanted it to be ***)
Short time value: ***
Long time value: ***
Steal-ability: ***
Challenge-ability: *
Total: 11/15 stars

Thursday

Sami Söderblom’s “If James Bach and Mary Gorman had a baby, how would it test?” (based on familiarity to speaker)

Mr. Happy Monkey himself talking about… WHAT? Biology? Child birth? Intercourse? I have to say if he hadn’t been picked based on me knowing him, I would have chosen the session based on the title. Sami Söderblom is a good friend of mine. He’s a whiskey-junkey, a cat-photographer, a father, an explorer and a good friend. We have a history through my whole testing career, from my first big testing project to this day. He’s the “three-stars-should-be-the-milkyway” kinda fella.

I must say I’m on pins and needles what the session is about. The description says: “FITCODES”. I’m sold. SFDPOT has been my guideline through my recent testing career. At the Turku Agile Days 2012 I modeled the testing of speedos using the SFDPOT. This week we did testing exercise on testing whatever found in one’s pocket using SFDPOT. To advance the heuristic that has been the lifeline for me is something I really, REALLY, would like to see.

The values, for me, are huge. Should I be able to use the heuristic in my everyday work is a great benefit. In addition to this, to be able to help others test their software better, to design better tests, to manage testing in a better way, make the session even more valuable. To learn how Sami came up with the heuristic is a good steal-able. To refine it to suit my particular needs would be awesome. And, since I know quite a lot about the subject, challenging would be the cherry on the cake.

Person-to-person: ***
Short time value: ***
Long time value: ***
Steal-ability: ***
Challenge-ability: ***
Total: 15/15 stars

Beat that! No pressure, Sami. ;)

Stephen Janaway’s “Why I Lost My Job as a Test Manager and what I Learnt as a Result” (based on interest in the title)

Test coach, he says. I think I like him already. The transformation to Test Coach has been my goal during this year. Teaching people on how to test and make them better at what they do. If Stephen can help me achieve that, I’d be happy as a hippo.

I actually don’t know Stephen from the past, but with his attitude towards coaching, I bet we can hit it on. Value coming out of his “shift to coaching” session could become quite valuable for me with my ambitions and goals, but to all traditional test managers. When I came to my current work place, I told I wanted to be a coach, but I have yet to find my focus and methods in implementing it.

To more easily understand Stephen’s session, I feel I must read the blog post first. Maybe then I can be able to challenge him in a better way.

Person-to-person: *
Short time value: **
Long time value: ***
Steal-ability: **
Challenge-ability: *
Total: 9/15 stars

Erik Boelen’s “Acceptance Testing At Its Best” (random pick)

I’ve heard some experience reports on the subject of coaching end-users to test the acceptance of a product. They have all been educational, but seemed to be lacking some punch - the methods to implement the procedure to one’s own context. I have never heard of the speaker before, but I fresh blood to the Testing Arena is always a crowd pleaser. ;)

This seems like a good session for those battling with limited testing resources and acceptance testing stuff. I see a lot of material I would like clarification to and some areas where challenging might be in order. Values are unpredictable here. Since I work closely to projects and the project management nowadays, I see some intersections to my work. This might be a huge value to a test manager of any kind. I cannot say.

Person-to-person: *
Short time value: **
Long time value: *
Steal-ability: *
Challenge-ability: **
Total: 7/15 stars

Friday

Erik Brickarp’s “Going Exploratory” (based on familiarity to speaker)

Erik. My man! He’s been around for a while. I was introduced to him by a hint from James Bach few years ago for paying the RST course from his own pocket. Anyone to do that is a personal hero of mine. He’s a great thinker, a fine coachee – fine and dandy bloke on all fronts. I’m really excited to see him in person since he has evaded me the few times I’ve attended conferences in the past.

So, Erik’s gonna talk about how he switched from rigid testing process into an exploratory one, failed, learned, tried again, repeated, succeeded. This is something that I want to do! I think my key takeaway is the sandboxing. In my recent project I have drastically changed the process with constant deliverables. This means more freedom in the execution but rigid documentation. I think Erik can give me a couple of good tips how to make the process less painful and more appealing to… the client. (You wer thinking I was gonna say “opposite sex”, weren’t you?)

I definititely see value in this. Short time value comes mainly from the insights that I can implement as soon I hit the desk after the conference and long term effects can sprout an inspiration where I combine my learning to what Erik gives. Very valuable in deed.

Person-to-person: ***
Short time value: ***
Long time value: **
Steal-ability: ***
Challenge-ability: **
Total: 13/15 stars

Radomir Sebek’s "You don't need to be a musician to test music production software" (based on interest in the title)

Music is close to my heart. I compose various kinds of music, hence I have an interest in both the industry and the tools of trade. Combine music and testing – I’m hooked. Although I have never heard of Mr. Sebek, I am keen on hearing what he has to say.

The whole concept is intriguing, having to quickly learn a vast domain to better test it. I think that is the core of software testing in general – fast learning, adapting, moving focus and prioritization based on learning. I want to examine his methods of approaching the subject. The coaching aspect (as in using testers with various backgrounds and influencing them) is also interesting. I am intrigued what kind of methods have been used in the influencing. Experience reports like this are usually difficult to challenge, but usually highly steal-able.

Person-to-person: *
Short time value: **
Long time value: **
Steal-ability: ***
Challenge-ability: **
Total: 10/15 stars

Ilari Henrik Aegerter & Ben Kelly’s “Ben and Ilari's Spectacular Testing Circus” (random pick, honestly!)

Like I mentioned in my earlier post, I have spent some time chatting with Ilari. He has coached me on different things. Ben Kelly has been on my radar, like many testers, but I haven’t yet figured him out. It seems I am compelled to read his blog a few times before I go chat with him.

The session itself is a puzzle (pun intended) since it can contain many things. Interactive games, puzzles, cool problems, etc. are the salt of testing skills. I bet this is a session where I shall spend at least an hour or two, since I just like to challenge myself. I expect to be challenged and to be able to challenge other testers and maybe increase some skills while having fun.

Person-to-person: ***
Short time value: ***
Long time value: **
Steal-ability: ***
Challenge-ability: **
Total: 13/15 stars

Conclusion

There are many sessions that I didn’t tackle although they might be worth gold. If you feel (as a speaker) that I should tackle yours, drop me a line. I’m also eager to discuss my choices with the people I rated.

It seems that I am attending the Nordic Testing days. I shall be there with my beard flowing and throwing #high6’es to people. ;)

Varsti näeme!
- Peksi

Let’s Test 2015 – conference at a glance (from a distance)

2015-04-01T19:42:00.000+03:00

Just to get up again and write something, I decided I’d do something I’ve done before. I really want to join the Let’s Test 2015, but it seems I cannot. This blog post is similar to those I’ve done before for it is a “Conference at a Glance” kinda thing. So this is

Let’s Test 2015 – conference at a glance (from a distance)

It seems the conference is a 3 day thing with 2 key notes, 33 sessions or various kind. Since I’m a lazy person, I shall do the following:

Tackle both key notes
Choose one session from each day based on my familiarity of the speaker
Choose one session from each day based on my interest in the title
Choose one session from each day that I pick randomly

That should bring me to a total of 11 sessions that I try and grade. If you (as a conference speaker or as anyone else) feel like I should do more, just ask me in the comments section. I try and keep it simple.

I will use a heuristic grading system (introduced here) to determine what would be the best session for me. I will grade the stuff with Angry Birds ™ grade – 0-3 stars per area – on five areas:

Person-to-person (How will the person and his/hers work affect/inspire me or the people I know?),
Session value – short time span (How much can I get out of the session tomorrow – next year?),
Session value – longs time span (How much can I implement o my work and teach to my colleagues, my community?),
Steal-ability (How much of it am I willing to borrow and further develop to make it better and, more importantly, mine?), and
Challenge-ability (My past knowledge on the topic and my willingness to challenge the session contents.)

Ben Simo’s “There was not a breach – There was a blog”

Based on the description on the webpage, I quickly came to think I should have done something like that. I should have started blogging about something that is affecting major public. Like the Finnish Railway renewal or something else of a similar matter. Having not thought of the idea, I shall keep my eyes open the next time something big comes up. So “Thanks Ben for giving me a great idea. Don’t mind me copying it in the future!”

As we’re talking about a keynote here, I don’t think during-session-challenging will occur. As this is kind of an experience report, I feel I can absorb huge amount of wisdom and ideas from it. If only reading through the description gave me so many ideas already, attending the keynote might blow my mind. Alas, it might not happen. So my head is safe for now. Challenge-ability might be a bit low, but if you think the challenging as in self-challenging, things I can challenge in my own thinking processes, ways of working, how I present myself to others. On those parameters I see a lot possibility to challenge.

On that note, the steal-ability just went through the roof. As for long term value, I believe that short term value comes from bringing the conversation to the coffee tables for those who are not American nor have the exposure to HealthCare.gov. The long term effects lie in the the steal-ability I mentioned before. If I can introduce some public service kind of attitude towards my own behavior, it’ll really make a difference.

P2P-level is a bit tricky. Ben has been on my radar for years. I’ve been following him and reading his blog sporadically, but I never really came to realize how much of an influence he has been. There hasn’t been too much communication between him and me save for a few tweets now and then, or some random facebook comments to each other’s posts. I must say I should have been more in his face about stuff. I shall change that and get to know him better!

As for score (should I be at the conference I would attend the keynote whatever it might be):

Person-to-person: * (I wanted it to be ***)
Short time value: *
Long time value: ***
Steal-ability: ***
Challenge-ability: **
Total: 10/15 stars

Antti Karjalainen’s “Detecting the Heartbleed Vulnerability”

The description might not provoke my vastest interest, but I was part of the Heartbleed scene in a sense. While working at F-secure I heard about it weekly during the “hip season”. I didn’t particularly have anything to do with fixing nor working with it, but I was there to spread knowledge about it.

The thing is, I am the kinda guy who shies away from über cool tools, fancy technology and protocols. I have some interest in security testing, fuzzing and analytics, but I’m more comfortable to leave those to the people who know them better. When it comes to knowing what fuzzing does, I’m comfortable in what the Wikipedia says. That is to say with no disrespect towards the fine men and women who dapple with such technologies. Hats off to all of you!

P2P is a challenge for me, since Antti is a Finn and I might have run into him at some other conference. I can’t put my finger on it, however. I have never talked with him about fuzzing nor about tools (“the shying” and other excuses). The thing is, I don’t think I could talk with him about the fancy stuff. I might have a few cool comments like “that looks cool” or “whaddaya know”. The thing is, however, that I cannot say for sure. I wish there would be a common ground on which we could build a conversation and then work from that.

The short term value might be in form of an interest into fuzzing tools. Or to some yet unknown aspect of fuzzing I could use in my testing. I feel that the topic is so tool/technology oriented, I might not get enough. It also affects the long term value for I don’t think I am capable of transferring that knowledge to my community or colleagues. I don’t say there won’t be any inspiration during the keynote – I might change my way to think testing and tools.

And since my knowledge on the technology and the tools are so diminutive, I feel the steal-ability and challenge-ability are scored low also. This isn’t to say that Antti doesn’t rock most of the listeners’ world! I believe that he is the kinda guy we need more of. Just like Ben, helping regular people with their daily lives is what counts!

Person-to-person: *
Short time value: *
Long time value: *
Steal-ability: **
Challenge-ability: *
Total: 6/15 stars

1st day sessions:

Ilari Henrik Aegerter’s ”A Tester's Walk in the Park” (based on familiarity to speaker)

Ok. Having read the description, I’m torn in half: A session without a clear outtake or a fountain of good ideas. I don’t know quite yet. I do appreciate that the problem solving is the key to it, but are we talking about artificial, abstract problems like “where is testing going”, or concise practical problems like “how can I convince my manager to pay my trip to Sweden”? The uncertainty intrigues me in a way that I wouldn’t dare miss this session. If we can coax people like Michael Bolton or Ben Simo to join in with their problems, it can be a hoot. It could be a hoot with just me, Ilari and three guys I don’t know. The thing is “I don’t know”.

I have spent some time chatting with Ilari. He has coached me on different things, latest today (the April 1st 2015) on how to approach a testing communication problem. I know this guy and I like him. I have to admit I haven’t paid too much attention on his whereabouts the last 18 months, but I reckon that all will be changed.

The value of the sessions is a tricky one. I cannot say what value I can get for I don’t know the contents that well. On short term it might arouse good conversations and comradery between the people attending. Experience reports in the form of problem solving might be a good take-away. In longer time span, the technique itself might be a good thing to learn. The introduction of philosophical thinking and approach to software testing is actually quite intriguing. Challenging the session might be a tough one, since it feels like an experience report of a sort.

Person-to-person: ***
Short time value: **
Long time value: **
Steal-ability: **
Challenge-ability: *
Total: 10/15 stars

John Stevenson’s ”A Journey Towards SelfLearning” (based on interest in the title)

WOW! This sure sounds cool! A sessions in a form of a game show! Count me in! I am interested in learning and how people learn. I am a continuous learner myself and I think it is time to up that interest in me once again. If this session could make my learning more structured, I would get more out of the time I have at hand.

I know next to nothing about John Stevenson, but lately I have spotted some of his tweets. He could be one to chat more deeply about learning. Him and James Bach might be a good dinner guests if I wanted to talk about learning and teaching. Since I hope to be a teacher of a sort someday, I think they could give me valuable ideas.

The value I see from this session is vast, both long and short term. While stirring me short term, it could make me think about my life on a longer run, my education and my striving towards being a teacher (though Finnish teachers are paid really poorly). Since I know something about learning, I think I might even be able to challenge John on his ideas. Though I don’t think I can introduce any particularly new and fancy to his curriculum, I might be able to increase the value of the session by making him express thing in different ways to be more easily approachable.

Person-to-person: *
Short time value: ***
Long time value: ***
Steal-ability: **
Challenge-ability: **
Total: 11/15 stars

Louise Perold ’s "Non-violent Communication" (random pick)

Well well well. NVC. I must say I had need for those skills today when I argued with a developer on why the test cases written for manual execution are a poor excuse of a test automation. I did seek some coaching from Ilari (like mentioned before) but I wasn’t able to convey my point to him in a way that would have left both him (the dev) and me in a mutually enjoyable place of mind. Having said that, Louise’s session might be the one for me.

I don’t know her at all, though I might have traded tweets in the past. I’m intrigued meeting her, though. Should I not be able to come to conference, I really want to talk to her about Mortimer J. Adler’s book “How to Speak How to Listen” which I’m reading sporadically now and then. Also what I found out from Daniel Pink’s book “To Sell is Human” might contribute to the Non-violent communication.

Values from this session might be really high in short term and long term. I might not be able to transfer them to my community in a way Louise could, but I bet the example and behavior might influence my co-workers and other people as well. My knowledge on listening and conversation skills might enhance the challenge and steal –abilities, but I would have to let the time indicate what’s beneficial and what’s not.

Non-violent starring would be as follows:

Person-to-person: *
Short time value: ***
Long time value: **
Steal-ability: **
Challenge-ability: **
Total: 10/15 stars

2nd day sessions:

Laurent Bossavit & Michael Bolton’s ” "Defense Against The Dark Arts” (based on familiarity to speakers)

Critical thinking, they say. Very well. I would expect something like this from Bolton and Bossavit. Given Laurent’s book “Leprechauns of Software Engineering” it is about time to teach us Earth dwellers them skills to tackle possibly harmful (and perhaps even rigged) information.

I know both of the speakers and I love spending time with them. Both incredibly intelligent fellas with excellent ideas and views of the world. It seems almost a loss that I might have to miss their workshop. But I shan’t weep! I find their session really intriguing so I might badger for a coaching sessions should I need to miss the event.

As for value of the session, I see high value altogether. Critical thinking skills and the practical application of it are worth gold in the testing industry. Whatever I can bring home from that session would be valuable material for my colleagues in ways to think critically.

Since I have some former knowledge on critical thinking, I feel the challenge-ability is high. Also I see that the whole session is about challenging, I feel compelled to challenge much of their material. Steal-ability is high in a sense that I want to educate my colleagues on that particular subject.

My god, I’m looking at quite a session:

Person-to-person: ***
Short time value: ***
Long time value: ** (it’s really 3 stars, but I cannot give the highest score yet)
Steal-ability: ***
Challenge-ability: ***
Total: 14/15 stars

Huib Schoots’ “How to be an Explorer of Software” (based on interest in the title)

Mr. Schoots talks about creativity? The guy who had a conference sessions in which he mostly played music talks about creativity? I think this is the stuff everyone needs to see. The title pushed me in a quite different assumption on the contents of the session. I thought that it would be about hands on exploring something, but since the description kinda gave the impression that it’s about how we document and observe, it actually fulfills the title quite well. Interested I surely am.

Huib is a great fella and he could be one of the top 3 reasons for me to attend. He is the bloke that makes people smile on their worst day. All that and a world-class tester! Say no more! I have seen Sami “the Monkey” Söderblom talking about exploring, read (the beginning) Elisabeth Hendrickson’s book on exploring, so it would be nice to see another take on the subject. The value is hard to define, since I feel the values are more personal than community wide spreadable thoughts. To be able to more concisely test and document a software is a great skill to have.

To challenge Huib is something I think he would enjoy more than anything, so I think I must get in touch with him and get my hands on the material if I can’t attend. I might also be able to steal something that I later present something as my own, but I ain’t gonna let him know. It’s hard to put a finger on the stuff that I’d like to steal, but I bet there are loads of stuff.

The exploration of stars…

Person-to-person: ***
Short time value: ***
Long time value: **
Steal-ability: **
Challenge-ability: ***
Total: 13/15 stars

Erik Davis’ "Effective Practice Manager" (random pick)

A practice manager. That’s a new term for me. Based on the description I didn’t get what is a practice manager. Is it like a skill coach or a competence manager? Either way I feel this is an experience report with some educational features. Oh it’s an experience report with discussion. Maybe we have some cool practice manager problems we can help solve for him. Challenging might come to play while there’s a discussion in the session, but I do know so very little about the subject beforehand.

I was intrigued by the “increase their own impact at work” bullet point. That is something I want. I want autonomy and to see my own passions and skills realize in my daily work. In that sense this session might be a good catch. It would definitely have long term effects but I couldn’t get the short term value out of the description. Maybe it lies in the “whatever else comes out of the discussion”.

I don’t know Erik at all. He might be one of those blokes who have avoided my radar so far. Based on his personal description I think I he would be the guy to get to know. Maybe I’ll ask him for a beer at the evening activities. His interest in educating testers and building their skill set is something I want to do also.

Person-to-person: **
Short time value: *
Long time value: **
Steal-ability: **
Challenge-ability: *
Total: 8/15 stars

3rd day sessions:

Jari Laakso’s ”Security Testing” (based on familiarity to speakers)

Before I have even checked the description on Jari’s session, I must say I am intrigued by this. He is my first touch on security testing on my Finnish blog years back. Unfortunately, I haven’t met the guy. I know he’s intelligent and capable tester, but I haven’t been in contact him for some time. Maybe I have to rekindle that connection to get the latest.

Ok. The description. Very well! Hands on security testing! Where do I sign? This is like one of the essential stuff that people are asked to when doing exploratory testing. SQL injections are in every text book on testing, but this guy actually shows how to do that. Nice! I can see the value skyrocket! The thing is, to be able to share this knowledge I should know even more about the subject. I might lack the interest in security testing in general, so I might not be able to teach these skills to others (I’d ask Jari to do it for me).

To challenge him might be difficult due to the fact that we are talking about technical stuff once again. Things like cross-site scripting are founded on protocols, REST-calls and whatnot, and I don’t feel I can challenge him on those. I might wanna try, tho. ;)

Person-to-person: ***
Short time value: ***
Long time value: *
Steal-ability: *
Challenge-ability: *
Total: 9/15 stars

Alexandra Casapu’s “Examine Your Testing Skills” (based on interest in the title)

Hands on testing and discovering our testing skills. I like it. In EuroSTAR test lab I had the chance to dapple with Mr. Lyndsay’s machines and I really want to have another go! Besides I’m interested in how my skills map out. I don’t know Alexandra, but I’ve heard of her. She is one of those people I want on my “meet these people in the Testing Scene” list.

The idea of having various non-technical skills to help you with testing is interesting. I would like to know other peoples’ skills and if I can borrow their passions and learn what they know. I’d be able to steal ideas from the participants and from Alexandra. Very nice! Since I have been doing some reading on skills, I might be able to challenge her and my previous views quite easily. And skills practicing in practice is always something to take home to.

Person-to-person: **
Short time value: **
Long time value: **
Steal-ability: **
Challenge-ability: **
Total: 10/15 stars

Scott Barber’s ”Experiencing Product Owners” (random pick)

Random in deed… Scott, if you’re reading this, you might want to check the description on the website. ;)

A big star on the effort, though.

Conclusion

Having surpassed the pain of starting to write again, I feel joyous on how I managed to rate 10 (Scott’s doesn’t count) sessions on five heuristic parameters. The toughest thing is ahead of me, though. I need to convince someone to pay my trip to Sweden.

Vi ses!
Peksi

Doodling exercise

2013-11-13T18:14:00.000+02:00

I was at the EuroSTAR conference 4th November in James Bach’s tutorial. I had not attended a full day training, talk or tutorial for a long time and my mind was still a bit rigid. I had a blast listening to James, but I noticed that from time to time my mind began to wonder. I started doodling on my note book. I didn’t pay attention. I was sitting between Laurent Bossavit (https://twitter.com/Morendil) and Kristoffer Nordström (http://contextdriven.blogspot.fi/). I know those guys are brilliant minds and I was actually a bit ashamed for doodling and losing my focus. So I doodled “in secret”.

At the coffee break I talked to Kristoffer about doodling and he explained it to me something like this: When listening to the talk and engaging one side of your brain, the other side starts to get bored. It begins shouting “Booooooring! I wanna do something creative!” and it makes you lose focus. Kristoffer told me to keep on doodling as part of keeping your focus. I did after that and I was able to keep my focus and come up with some more or less important ideas about testability and rapid test management – which was James’ topic on that day.

Kristoffer challenged me to write a blog post about doodling within one week, but I wasn’t able to tackle it before. Now I am, so I conducted an exercise. I tried to take notes on something that I have little or no interest in and tried to keep my focus on the job by trying to take notes and occasionally doodling. I did this by watching the most tedious video I can find from Youtube and I tried to summarize it using my doodles and notes. I chose “Intelligent Design and Creationism in the Classroom” (http://www.youtube.com/watch?v=x2qIAjtrNdY). It’s a 40 minute talk about something I try to stay away – religion and the teaching thereof. Here’s what I managed to do:

I started watching the video and thought there would be some fundamentalist talking about religion with such a zeal I couldn’t finish watching the video. Actually I couldn’t, because the video broke for some reason at 10:36. I did however rethought my previous attitude towards the video.

The beginning of the video was actually quite concise and gave things out in a quite unpassionate, to-the-point kind of analysis. I got a better understanding on why legislations on religion and marriage are the way they are. The context, I believe, requires some understanding of the government process and immigration policies. Also as a Finn, some of the things felt odd, like narrowing the gap between church and government.

More on the exercise. I tried to use doodling to keep me focused, but actually I had no trouble focusing. Taking notes was time consuming so I veered towards pictures to remind the topic that was talked about. It gave me something of an emotional attachment thus making the notes more understandable and clearer. The problem with this exercise was that it wasn’t authentic. I tried to make notes for the sake of note taking. I could formulate questions about the topics I doodled about, and in that sense I might have already felt that I must doodle about topics that I have some interest in already. I am keen to find out more about the “10 Commandments monument vs. non-Christian monument”.

As a conclusion, doodling is a good way to focus AND de-focus. I was able to shift my focus from the talk to the topics I got interested in. Also the doodles highlight the important stuff. Underscoring, circling, etc. make the text more dynamic and one can more easily find the areas of interest from the notes.

Thanks for challenging me, Kristoffer. It was a good thought exercise in addition to making me want to learn more about doodling. I still have a long way to go in note taking, but at least I know where to turn to get better exercises on note taking.

- Peksi

Note to self: read the following before going to the next meeting, session, conference or tutorial:
• http://sunnibrown.com/doodlerevolution/bootcamps/visual-notetaking-101/
• http://www.eurostarconferences.com/media/149386/alan-richardson_virtual-conference.pdf
• http://erik.brickarp.se/2012/10/practice-1-note-taking.html

Conference at a Glance, part II – My glance on the Tuesday AM tutorials

2013-07-12T14:28:00.000+03:00

This is the second part of my series of posts about EuroSTAR 2013 conference. I apply the same method of evaluating as I did previously, so read the “My glance on the Monday tutorials” before this post, if you haven’t done that already.

Ian Rowland’s “Thinking Outside The Locks”

I have not heard of Ian Rowland, but I must say I’m intrigued. A magician? The biography in EuroSTAR page makes me want to know more about this fellow. In fact, I googled his name and got to his website. I’m really looking forward to see Ian do his stuff. I would guess that humor is involved in addition to mind blowing approach to thinking outside the box (or locks as he says).

To be honest, I think critical thinking, unconventional approaches, non-rational thinking are the tools of my trade. I would be able to use those both daily and they would make me become a better tester both short and long term.

I would recommend this to all my colleagues. In fact I’ve been thinking about a 30 minutes workshop on out-of-the-box thinking and using unconventional methods to solve a problem. If I get enough ideas for my workshop I might just do a workshop, and I hope Ian can help me generate ideas for it.

To be honest, I can’t think of anything to disagree from the summary of the tutorial, so I might not be able to challenge him. I’m curious to see how the methods he uses actually project to software testing. I might steal some of the details and trick he uses to my own work, like I mentioned before.

The tutorial seems very interesting as a light weight beginner for the conference (even better after a full day of Monday tutorial), but is this the best option out of the cast of many great speakers? I would be the one doing a half day tutorial on the subject, considering I don’t have that much experience in coaching out-of-the-box thinking.

After the smoke clears and the magician bows, I would like to see/hear/learn about implementing the skills and theories Ian shows to us. Theory is good and all but I would like to see results in testing craft to be happy with the tutorial.

On my Birdy scale, Ian Rowland’s “Thinking Outside The Locks” would scale as follows:

Person-to-person: **
Short time value: ***
Long time value: **
Steal-ability: *
Challenge-ability:
Total: 8/15 stars

Prof Harry Collins and James Bach’s “Using Sociology To Examine Testing Expertise”

I think I said enough of James Bach on my previous blog post, so I will concentrate on Prof Collins. I find his resume quite impressive. He has (co-)written books that we testers should (I haven’t) be reading including the “Tacit and Explicit Knowledge” and “Rethinking Expertise”. I am eager to hear what he and James Bach have come up with. The duo of unschooled (but not untaught) and a University professor could spell doom to us mere mortals. I’m truly eager to hear their tutorial.

I am really eager to listen to stuff about meta-knowledge (or knowledge about knowledge). I do not, however, see a short term benefit from it. It will eventually develop my sense of self analysis. I’m very interested in any studies about testing and testing methodologies and this tutorial taps to that – using the tacit knowledge in addition to radiant expertise.

I don’t know straightaway how I could harness the tutorial for the benefit of my fellow testers. If the tutorial addresses social tacit knowledge, I could be able to make the company benefit from acknowledging that knowledge.

I am keen challenge the fact that there are skills that no person possesses but a group of people. Let’s say I invite a group of people to my house and I want to learn Chinese. None of these people know Chinese, but as a group we might be able to possess the skills to communicate in Chinese? Am I on the right path here? Or are we talking about more-than-sum-of-its-parts mentality, where we all would know just a little Chinese or a language close to Chinese?

I would refrain myself from teaching this. Maybe I could mention and guide people to seek for material appropriate to this experiment. I have no previous knowledge in this kind of study as I lack the university background.

Just like in Ian’s tutorial I would like to see/hear something that I could implement to my own work. What do I do with the information about what skillset does the teams have?

On my Birdy scale, Harry Collins and James Bach’s “Using Sociology To Examine Testing Expertise” would scale as follows:

Person-to-person: ***
Short time value:
Long time value: **
Steal-ability:
Challenge-ability: **
Total: 7/15 stars

Peter Zimmerer’s “Questioning Testability”

I begin to wonder what people think about me as a community member when I don’t know most of the people making presentations and more importantly tutorial speakers. This pre-analyzing the tutorials also helps me to familiarize myself with the people so I could recognize them at the event location in Gothenburg. I believe I have a lot to talk about with Zimmerer from all kind of things, but I believe we can make a conversation out of his topic also.

Testability is a freaky subject for me. I might be living in a bubble where we almost automatically plan our products with testability in mind. We aim to make the testing as fast and efficient as possible, so this tutorial might not give me too much in short term. I do believe that testability is one of the key things to enable efficient testing, so I more than recommend this tutorial to everyone!

I do believe that I could benefit from revolutionary points of view, which I hope Peter will provide. At some point when testability becomes more a worry for me, I might need the skills. Also the ability to promote testability could be important for me in this company. At some point the leading testability evangelists might leave the company, so we need as much tacit knowledge on testability as possible.

I’m expecting a lot of practical examples to be able to share myself (possibly after altering them to my own flavor). In that sense, the stealability is quite high in tutorial. I would focus mostly on practical appliances of testability, because testability as theory is quite trivial. People seem to have trouble in understanding how they can make stuff happen in practice.

When it comes to questioning, the words “step-by-step” rose a red flag. Is this method an omniscient, all-encompassing process? I hope this tutorial doesn’t turn into “do this and everything will be fine” but into “apply these skills where it’s reasonable”. If I am to join the tutorial, I will definitely challenge

On my Birdy scale, Peter Zimmerer’s “Questioning Testability” would scale as follows:

Person-to-person: *
Short time value: *
Long time value: **
Steal-ability: **
Challenge-ability: **
Total: 8/15 stars

Anne-Marie Charrett’s “Coaching Software Testers”

James has mentioned Anne-Marie a couple of time in our conversation and praised her coaching skills. Then again, I must admit that I have not made myself too familiar with her work. I’m looking forward to seeing her and possibly having a chat at some point. Hopefully she’ll be able to donate some of her time to me.

Actually the coaching method described here is something I have already done a few times. First James Bach coached me using the Socratic Questioning and then I used it to coach Erik Brickarp, Jari Laakso and Aleksis Tulonen among others. The amount learning on BOTH parties was phenomenal. I would love to gain more skills in this area to be able to continue my journey as a coach. This is something that both my colleagues and my fellow crafts(-wo-)men will benefit. I have some skills to begin with so I will employ them in future to the benefit of all, including me.

Having said that, I will try to steal as much as possible from this session and to mold it to my own. I recommend this session – yes, without having yet attended it, but having faith in it like in no other! Coaching skills are paramount on testers skill set if they ever want to become true professional.

I find it hard to challenge this on two reasons: I would consider myself as a member of coaching congregation and I would find it hard to challenge something I have unquestionable faith in. I am willing to try challenging for the sake of argument, but facing Socratic Questioning arguing for argument’s sake might be my downfall.

On my Birdy scale, Anne-Marie Charrett’s “Coaching Software Testers” would scale as follows:

Person-to-person: *
Short time value: **
Long time value: ***
Steal-ability: ***
Challenge-ability: *
Total: 10/15 stars

James Christie’s “Questioning Auditors Questioning Testing”

James Christie (How many people called James are presenting in this conference?) is one of those that fall on the same category as Anne-Marie – I would love to talk to them for what I have heard from my fellow community members – but I have never delved into James’ work in-depth. Maybe I can sneak into his lunch table and steal a minute to talk about testing. ;)

In the past, I was working in a company where an audit was held. I was part of a group that coached the people getting audited to answer the questions correctly to appease the auditor. Wrong approach to audit – we do not always act according to the documented process but according to our best knowledge on the situation. The audit was about the documentation. The auditors were held in so high authoritarian position that they were not challenged – I was not allowed to talk to the auditors. ;)

I don’t see a short term benefit on this tutorial, however. I’m not currently in a position to be part of audits currently at F-secure. We do have security audits and the like, but I have yet to be invited to one such event. I might benefit James’ tutorial if I focus on questioning instead of auditing. If the scope wouldn’t be so narrow as to concern only audits, I would find it more beneficial to my current work.

If I could combine questioning to other areas, like specific levels of testing (unit, module, etc.) I could be able to teach or coach other testers and programmers to question their work more efficiently. So long term benefits could outweigh those of short term. More so, I don’t know where my life takes me so having some skills in challenging auditors might be my thing in the future.

I have such limited knowledge on auditing as such, so I find it difficult to disagree with questioning. Usually the person being questioned could benefit from the questioning too. I have been in a situation where I learned more by being challenged than by acquiring book knowledge on the subject. Like I said earlier, I would like to see tracks on more general questioning, arguing and challenging. This tutorial might answer some questions I have, but I’m not sure at this point.

On my Birdy scale, James Christie’s “Questioning Auditors Questioning Testing” would scale as follows:

Person-to-person: **
Short time value:
Long time value: **
Steal-ability: *
Challenge-ability: *
Total: 6/15 stars

Pradeep Soundararajan & Dhanasekar Subramaniam’s “Context Driven Mind Mapping”

I know Pradeep from tweeting with him and reading his blog. I also have followed the progress of Moolya for some time and I’m really impressed in their success. I’m also looking forward meeting Pradeep and Dhanasekar in Gothenburg to talk about mind mapping and all testing related stuff. I’m glad that Pradeep is hosting two sessions at the conference so I can join at least one of them.

I’m a bit of a mind map enthusiast myself so this tutorial is almost tailored for me. I find a lot of things here that are almost exactly from my workshop year ago from Nordic Testing Days 2012. I do believe that I have a lot to learn on both using the mind maps and hosting workshops. In short term, I would like to learn the most effortless way to utilize mind mapping. I tend to procrastinate during the testing, so if mind map can keep me focused, I would be on cloud nine. I also see mind maps as the tool of the future for it utilizes the brain instead of some arbitrary tool.

This tutorial would be worth stealing in its entirety and then I would go on promoting the ideas and practices to my company and to my peers in the community. In the long term, mind maps could help make exploratory testing both understandable and credible to stakeholders with minimum effort on documentation. I have already played around with the thought of decompiling the mind map into coverage charts by scripts, so this might even further automate the documentation of exploratory testing.

As for challenging, I know where I was stumbling in my workshop so I might tap into those subjects. First would be the content-switching during testing from the mind map to the software under test. If the mind map requires another window in addition to database browser, Unix log screens, browsers, standalone tools, etc. the content-switching becomes a burdening factor in the long run. Second would be the “free form” of the maps, which could result in inconsistent ways to report. I’m curious to see how Panda and Commander can tackle these. :)

I would recommend taking the Monday tutorial by James Lyndsay and combining it with this to make an awesome combo of exploratory testing and modeling. I haven’t yet decided which to attend, but if you, dear readers, should consider this combo really hard.

On my Birdy scale, Pradeep Soundararajan & Dhanasekar Subramaniam’s “Context Driven Mind Mapping” would scale as follows:

Person-to-person: ***
Short time value: **
Long time value: **
Steal-ability: **
Challenge-ability: **
Total: 11/15 stars

Afterword

Once again I have not yet decided which to attend. There seems to be 2 top dogs right now, but I cannot yet say which to attend. I might even change my mind right before the session if other community members talk me to join a session other than what I would have chosen.

Anyway, I have quite a task ahead of me to plow though the conference tracks one by one. But be assured, I will go through as much as I can.

Also, I got interviewed to EuroSTAR community spotlight. I thank Emma Connor for the interview, and wish her and every tester out there a great summer!

- Peksi

Conference at a Glance, part I – My glance on the Monday tutorials

2013-07-08T13:52:00.000+03:00

The EuroSTAR 2013 is knocking on my door. It's about time get some scribbles to my blog about it.

Quick word about what I’m doing here: I’m trying to get my thought on paper both to ease my burden of choosing the talks which to attend and also to write out my thoughts before the conference (as after the conference I might have a bit of a "information hangover" and I'm not that keen to write on stuff I didn't attend). If you think I have mistaken, misinterpreted or been outright wrong, please comment and discuss about it. I also encourage all the speakers, who I mention here, to comment on my expectations. I might be off by a mile on what the true content of the tutorial is, but please correct me if I’m on the wrong track.

I will also try a heuristic grading system to determine what would be the best session for me. I will grade the stuff with Angry Birds ™ grade – 0-3 stars per area – on five areas:

Person-to-person (How will the person and his/hers work affect/inspire me or the people I know?),
Session value – short time span (How much can I get out of the session tomorrow – next year?),
Session value – longs time span (How much can I implement o my work and teach to my colleagues, my community?),
Steal-ability (How much of it am I willing to borrow and further develop to make it better and, more importantly, mine?), and
Challenge-ability (My past knowledge on the topic and my willingness to challenge the session contents.)

This doesn’t mean that 0 stars would mean “I hate it”, instead I’m looking for personal value against my beliefs, biases, former knowledge and worldview. I’m not saying that I won’t attend a low scored session, no, I might change my mind after talking to people at the conference and to the speakers. So I encourage you to talk to me about your session and comment what I have written about you.

James Lyndsay’s “Insights Into Exploratory Testing”

As a first thought, James Lindsay isn’t the one person that I recognize as my personal idol. He ought to be, because I read his blog once in a while, but I haven’t really gotten into his stuff. I love the blog series in which he describes different ways to manage exploratory testing! Kudos for that! However, I think I need to see him in person to suck in the charisma that he might have. After that I might regard him as my Top-3 testers. Right now, he’s a bit of a mystery man to me. And I always mix him for James Whittaker! *grin*

I’ve done exploratory testing a while now, so to answer the question: “What’s in it for me for tomorrow/this year?” I think hands on testing practices could be a remedy for my “sohpomoristic” (I have knowledge, but not enough experience implementing my knowledge to practice) way of approaching testing. The analyzing nature of the workshop could help me be a better tester on a daily basis. I was struck by a realization on few pair testing sessions with people who I really look up to. They were so much better hands-on testers that I, but they had high expectations on my skills.

Because I need to bring something back the “Ye olde Sweatshop” at Helsinki, I need to look for stuff that are good for my colleagues. The nature of the workshop could sprout some lightning workshops or sessions with my testing fellows, so I’m keen to see how to run a successful workshops with different backrounds of people. I’m also keen to see how I can use my skills to use attacking and exploitation in my everyday testing, ‘cause I work at a security software corporation. So I might be able to bring that home with me. Over all, all the things in exploratory testing might be good for my colleagues. The focus in my company should continuously veer towards exploratory approach. This workshops could give a lot – that’s for sure.

As I always tend to look on the bright side of life, I do want to be able to challenge James
and his topic. So what areas might be prone for me disagreeing? Workshops usually bring new course to the testing buffet, so I would have to taste the dish before being able to make hard decisions about it. I can’t say what would be the areas where I would disagree but I would definitely ask about how you could implement exploratory approach on a company that uses mainly test case driven approach. Let’s say there’s a company that uses only outsourced testers and they have one test analyst whose job is to design proper tests for that group of testers. How could one use exploratory approach to make their testing more efficient, creative and manageable?

What could be the next step after having this workshop? Personally I would try this on a larger scale. Oh! That’s a good question to James: “How will I be able to scale this up? How do I manage a team of these explorers?” Personally James Bach workshop could answer some of these questions. If it was somehow possible, I would attend to both workshops and then combine then seamlessly together. The next step would be to combine Lyndsay’s techniques to a broader audience and to organizations where testing is still in baby shoes (i.e. über controlled, test case driven, hierarchial, to name some).

I have one more thing to say. Mr. Lyndsay, if you happen to be at Gothenburg on Sunday evening, I would like to have a pint or two with you and talk about testing and your workshop. I might not attend it as there’s so much to choose from, but I’d like to talk to you about this particular workshop. You can give me a shout at Skype or Twitter, if you want to. ?

As for James Lyndsay’s Monday tutorial “Insights Into Exploratory Testing”, I would score like this:

Person-to-person: **
Short time value: **
Long time value: **
Steal-ability: **
Challenge-ability: **
Total: 10/15 stars

James Bach’s “Rapid Test Management”

Personally, I know James Bach and I’ve spent some time with him face-to-face. I attended his RST class on 2012 and the Rapid Testing Intensive course. I was exhilarated to be invited to the course as a special guest and it was one of the most joyous events of my end-year of 2012. I had the opportunity to have dinner with James and to get face-to-face coaching. He’s a radiant person who some people misunderstand as angry or frightening – choosing to see behind the façade gives you the opportunity to see a multi-dimensional, empathic person who’s a power to Testing craft all around the globe. I know it sounds like I’m secretly in love with him, but trust me: he can turn your world upside down.

As for the Monday tutorial, I feel the topic is slightly too narrow for me. I did learn a lot on the RTI course last year and I think this tutorial might repeat some of the stuff that I learned that year. For short time value the tutorial might not be in the top-3. I have a lot to learn about test management, yes. I do think, however, that I can get more by starting finally to implement the stuff I learned year ago. The opportunities to do that have been scarce. I think I need more advices on how to implement the lessons to my work instead of repeating the theory myself.

What could I do to make my colleagues life better using the lessons learned from the tutorial? I have experience already from the RTI, but my situation after that session forced me to forgo the implementation of the stuff I learned. The job as a maintenance manager also did not fully support the further teaching of the methods. At the moment I am in a position where I could help my team and all Quality Engineer at F-secure to make their testing both better (using exploratory testing) and ways to manage it properly.

I am quite biased in challenging James’ tutorial because I wish I was the one with skills to pull off a tutorial like that. I have seen the traps and pitfalls at least partially already, but I think I need a different perspective to the tutorial altogether. I like to think about the scaling of the methods and also the managing of outsourced testing. How will the methods James purposes will scale across rigid and wide spread organization? How could I manage a team of tester in Kuala Lumpur according the principles? I would have to delve a bit deeper into his material. That would give me pointers on the terms and techniques he uses and possibly I could find some holes in his reasoning to sprout a fruitful conversation.

When I think about areas I’m willing to steal, the whole material could be worth stealing. The concept of managing exploratory testing using the Rapid approach gives me new tools and tricks to make our testing at F-secure more efficient and manageable.

The next step with this presentation would be almost the same as I described earlier. The approach needs to be implemented on a team to see where it might go wrong. In addition to this tutorial, one might benefit from different coaching and mentoring lessons so that the problems are found early and dealt with – almost like testing you test management.

On my Birdy scale, James’ “Rapid Test Management” would scale as follows:

Person-to-person: ***
Short time value: *
Long time value: **
Steal-ability: ***
Challenge-ability: *
Total: 10/15 stars

Paul Gerrand’s “How to Create a Test Strategy”

Paul is one of those people whose name pops up every here and there – he seems to be able to do everything. Personally I don’t know him or his work, but it seems it’s about time. The description at EuroSTAR page describes him to be attending lots of events so it’s clear why he’s a well-known person. It's hard for me to develop an understanding of Paul’s achievements on a personal level but after a few YouTube videos and some googling, I think he knows his way around testing. I may not agree with some of the stuff he speaks for, but I cannot put my finger on any specific topic. Hopefully I can get some challenging happening about hit EuroSTAR tutorial.

The first thing that comes to mind is a hint of worry – he’s using a template. I know from past experience that templates are seldom abused and used to hide incompetence and lack of interest. They look good, though. Is there something fór me in this tutorial that I could use in the near future? I wish I had taken this tutorial 5 years ago when I was struggling to tears with a testing strategy to cover a whole organization’s testing. I did do some short and efficient testing strategies on a project-by-project level, but the framing, all-encompassing strategy was a vague scribble that I loathed where other loved it – I knew I could do it better, but I didn’t have the motivation to really get into test strategies at that time (or the time to do it, I might add). As for “past” value, I would rate this really high, but now I don’t see too much value to my work. This could be one of those inspiring and challenging tutorials to attend but I don’t see short term value to me here.

How could I use test strategy workshop in my company? I’d have to say: in a punch of ways! The opportunities provided by honing the existing strategy and being able to make high and low level strategies would be helpful. The test strategy does push you towards organized testing and even give credence to ones testing if one has a strategy which to follow. On that aspect, I might even benefit from it.

I try to find something worth disagreeing or to challenge in all the tutorials, but in Paul’s case the answer is clear – templates. I loathe templates as base of documentation. They usually lose the meaning as a template and become “fill form and deliver” –documents. So I am eager to challenge template in every aspect I can. I would rather have a set of skills to enable me create my own template than a readymade one. Does Paul provide ways to create a skill set for that purpose?

I would like to be able to understand a bit more about the techniques Paul Gerrard uses to create the testing strategy. I guess that the only way is to attend the tutorial. For now I don’t see much else worth stealing than the concept of improving test strategy thinking. I’m not sure if this actually increases or decreases my willingness to join Paul’s tutorial, because I might be lacking in knowledge to actually make that decision.

Personally I would focus more on the skill set instead of the template. If he does encourage in a mindset change then that would be one of the topics I’d like to steal also. This tutorial would benefit from getting the test strategy to context and possibly the implementation to a testing project. I hope Paul has some concrete material on how the strategy implementation has worked in the past, if he has used it before.

On my Birdy scale, Paul Gerrard’s “How to Create A Test Strategy” would scale as follows:

Person-to-person: *
Short time value: **
Long time value: *
Steal-ability: **
Challenge-ability: ***
Total: 9/15 stars

Torbjörn Ryber’s “Boosting Your Test Design Powers”

I know Tobbe just a little. I have met him face-to-face, but we haven’t actually had a long conversation at that point. What lingers in my mind from our talk is a single phrase: “High-6” I hope I get a chance to talk to Tobbe at the conference at least once for he’s a great character. He has a tremendous knowledge in test design and critical thinking, besides he’s funny as hell! So I encourage all you, go and talk with him – you won’t get bored!

The tutorial seems, at a glance, to be run-of-the-mill presentation on test design. I have Tobbe’s book on test design and it is THE book for every tester! If you don’t have it, join the tutorial – you will receive a complimentary copy of the book “Essential Software Test Design”. Just like James Lyndsay’s tutorial, this one would be a fun thing to join as I know already something about the topic and to increase skills in test design cannot be harmful. Besides, ways to design testing with tools (i.e. charts, graphs, mind maps) would help me on my daily work. I do hope that we are able to get some hands-on experience on using the design techniques.

I have already promoted Tobbe’s book here at F-secure and I lend my book to one out Quality Engineers to get some advice on her work. I would like to have all our testers to join the tutorial as a wakeup call. As this is elementary for any tester out there, I encourage every pudding tester and developer to join the tutorial. For those that have been doing test planning for long time, this could act as a reminder of the good practices in test design.

Disagreeing with Tobbe’s topics can be difficult because I believe in the most parts. I do however see an opportunity to play devil’s advocate and challenge Tobbe and his claims. I do however see more beneficial to get into a debate on a separate occasion to let him bring out the most of the tutorial to people who need the knowledge. I’m not saying I don’t need more knowledge, but I will restrict myself from spoiling the fun from others.

I did a similar class few years ago where I taught test design on our testers and developers. My point of view was however a little more exploratory testing oriented and heuristic driven. I could try to steal some pointers from Tobbe to support my own material. I could then arrange a workshop here, at out office, to spread the joy.

The next step after this tutorial would be a walk to the test lab and to use these skills in practice. In that sense the schedule of this tutorial is perfect. Later in the conference people could try their newly learned or reminded skills to test stuff. I think Tobbe would appreciate the feedback that practical use of those skills could bring. For example, what areas require more attention in the future?

On my Birdy scale, Torbjörn Ryber’s “Boosting Your Test Design Powers” would scale as follows:

Person-to-person: **
Short time value: **
Long time value: **
Steal-ability: **
Challenge-ability: **
Total: 10/15 stars

Matt Barcomb and Jim Holmes’ “Becoming A Testing Craftsman”

To be honest, I don’t remember any significant details about either of these guys. I seems that matt is a busy conference speaker (according to his blog), but I did not yet find the tone in which would be in harmony with my own thoughts about testing. I do see that he’s a coach so I could try to approach him via Skype and ask for some coaching and to chat about the conference topic. Jim also seems to be quite a veteran in conferences. I scrolled through his blog and the slides that he shares are excellent! I love the way to make things simple and bite-size. If the duo is anything like what I learned from them, I would definitely want to meet with them and talk about coaching, motivation, innovation and testing topics.

On short term, this tutorial is like candy to me. Little programming excersises? Sign me in! Building your tools? I’m there! I also see that these guys focus on skills to get things done – automation is the extension of human mind, not the only solution to testing. This is by far the most fitting tutorial for the first day for me and my development, short and medium term. I am getting into trouble at my work by some tedious manual repetition that could be made easier with a shell script or a python script. I hope these guys can brrring it!

When I think about how to educate and help my fellow testers, I’m not actually sure if I could bring enough to the table. I believe, though, that the attitude towards being a craftsman instead of rank-and-file- employee could be beneficial to both them individually and to the company as a whole.

I would like to learn more programming and tool building before I could confidently teach how to build them. There’s a hell of a group here who can make tools, apps, what-do-you-need to make testing easier. I’m willing to see the applications of tool building and the test data creation/management and possibly try to teach that to my fellows.

This is an interesting topic, because I have little experience in actually building something functional for others (for myself a few scratch-built scripts, but nothing serious). If I was to choose what I would like to hear, I would like to hear more about the attitude towards craftsmanship and how we can spread the word around. I believe that craftsmen aren’t supposed to hold the secrets to themselves but to share their wisdom, like Matt and Jim.

I’d like to see these teachings to be implemented on some practical hands-on session, test-lab or something, so we can really get our craft to shine. I would also promote testing to other than testers – I think managers, documenters and all software project stakeholders could benefit from craftsmanship attitude.

On my Birdy scale, Matt Barcomb and Jim Holmes’ “Becoming A Testing Craftsman” would scale as follows:

Person-to-person: *
Short time value: ***
Long time value: **
Steal-ability: *
Challenge-ability: *
Total: 8/15 stars

Afterword

I’m still teetering on which tutorial to join, but I will try my best to decide. I know I need to make decisions fast so I can book my seat before they run out. I will let you know which one I chose after I book the tutorial. As for now, I will keep on writing about the conference. I’ll try to cover every conference day at least on some level, but I do not guarantee anything.

As you might know I am speaking at EuroSTAR on a Wednesday. I would like to hear what you might get from that session if you are to attend it. I will also hold a preliminary practice talk here in Helsinki, so if you’re interested to join, give me a tweet. ?

You gotta fight for your right to test!

2013-07-05T13:45:00.000+03:00

I am terribly sorry for the soon to be rant and biased output that is going to happen. I have did this once, but the conversation resulting from that was rather pleasant and constructive. This is a comment / response / rant about a blog page I stumbled upon today. You can find the original post here. The page may have been outdated since it was created in 2010 but it seems that it was updated half a year ago.

My first though was “not another test case” when I read the article. I’m currently trying to figure out what I will write to my next column on the “Testaus ja Laatu” –magazine, and since the theme is juxtaposing, I thought I’d try to write some blog-stuff first. One of the topics could be “test cases vs. no test cases” and I shy away from that strict way of thinking. Exploratory testing, to me, is utilizing all the available tools and gimmicks to get to the best results. Black and white –world vision narrows too much my take on testing.

Having said that, I will use my recently found taste to logic to point out what I found could be wrong in the article. I do not know the state of mind in which the article was written or the context in which it is supposed to be fitted, so I will project it to my own workplace where that is necessary.

You are warned…

The first sentence goes like this: “A significant factor in a successful testing effort is how well the tests are written.” I have no idea how much significant is this case. I would guess that it is either the largest part or the one after that. When I do testing, the significance of the test cases are miniscule, and I tend to do successful testing. Not all the time, but I know a certain cases where properly written test cases did not contribute to the successful testing effort. Also I don’t exactly know what qualifies as successful testing effort. It could mean having run all the tests within the schedule (which doesn’t quality for successful for many reasons), having written all the test cases (do I need to say more about this), the product is shipped to end user (lots of products have been shipped to customers and later fixed due to poor quality), etc. So I would say that well written test cases /may/ be a factor in the successful testing effort just as well as poorly or not-at-all-written test cases.

“They have to be effective in verifying that approved requirements have been met AND the test cases themselves are understandable so the tester can run the test as intended by the test author.”

So the test cases have to be effective in verifying requirements. Granted. Do the /have to be/ written. No. Even poorly written test cases can be effective at verifying requirements. I think the ability to verify something comes not from the writing of a test case but from the skill of a tester. If a tester is skilled there may not be need for any written test cases to get the job done. “--approved requirements have been met --” So anything that is not written to requirements doesn’t get tested? We also have expectations about the product that don’t really qualify as requirements. Testers still need be aware of anything that might threaten the quality of the product.

“The 3C’s: Clear, Concise, Complete. Test Cases are not open to multiple interpretations by qualified testers. Ambiguous or nonspecific Test Cases are difficult to manage.”

What if we do not know about the product enough at the time we write the test case? Should we wait until the product is finished and then write the cases? Isn’t that just huge waste of time and money? And when it comes to managing test cases, I think lines of text are the easiest to manage, it’s the people that might require managing. It is true that estimating coverage and depth may be difficult if the test case is ambiguous. I also think that it is difficult to estimate those with good and precise test cases. People are best to estimate the depth of their testing and the confidence in their testing. ASK IF SOMETHING IS AMBIGUOUS. -> Fight ambiguity with openness and communication

“Test Cases are easily understood. They provide just enough detail to enable testers familiar with the functional area under test to run the test case. Note: Detailed click by click steps are only useful for automated tests.”

This is something that I agree! Test case can be easily understood even if it’s like this: “Play around with the product and describe the person next to you what it does.” It is both easily to understand and you already have enough familiarity because the base requirement for that is none! This could be the baseline for any testing ever to be done at any context. FAMILIARISE YOURSELF WITH THE PRODUCT.-> Fight ignorance with eagerness.

“Test cases include setup requirements (environment & data), expected results, any dependencies on other tests and tracing to the requirements they validate. Are traced to the results of each test run, including defects (bugs) discovered, test platform run on, software build version used.”

For the data and expected results, I recommend all you read Michel Bolton’s and James Bach’s conversation and decide yourself if the test case is complete with expected results. It is necessary to document stuff that mentioned in the text so to avoid unnecessary overlapping. But traceability to test cases? Is that possible for bugs that are found during the test case execution but outside the intended observation area? BE PREPARED FOR THE UNEXPETED RESULTS WITH UNEXPETED INPUTS. -> Fight patters with chaos and vice versa.

“Measurable: For each test case, there must be a way to objectively measure that the test case has either passed or failed. All test cases must be linked to the requirements that they verify to enable impact of changes made to the requirements or solution designs to be identified (measured).”

OK. Let’s say that the test is executed perfectly and the result is exactly as expected. A minute after that the computer crashes. Does that constitute as failed? How much do we actually know about the product to say that a test has passed or finished. And if we want to find bugs, isn’t the test passed only if it finds bugs? I think test only fails if you don’t run the test, because it didn’t test anything. TEST IS ONLY FAILED IF IT IS NOT RUN. -> Fight unnecessary documentation with rightly timed planning. I.e. keep the time between planning and doing minimum. Preferably do them at the same time.

“The test case must have been approved, prior to being run, by the key stakeholders of the requirements that the test case verifies. Any changes made to test cases caused by requirements or solution designs changes must also be approved.”

There is ABSOLUTELY NO POINT IN THIS! Why the hell do we need approving for our testing? Only thing that requires approving is the results of our testing. If the stakeholders do not trust us to test the software, we could record everything we do and ask them to audit the test material. I would think they are happier to audit actual results than worthless, constantly changing trivial documentation. IF WE NEED EVERY TEST APPROVED, WE LOSE MONEY AND TEST COVERAGE. -> Fight über control with proper* documentation.

“Realistic test cases DO: Verify how the product will be used or could be misused, eg positive and negative tests. Verify functions and features that implement approved product requirements. Can be run using the platforms and software configurations available in the test environment.
Realistic test cases DO NOT: Verify out of scope functions and features. Verify unapproved product requirements.”

I agree with the first sentence – a good test could test how the product could be used/misused. Also how it should/will be used. How much does the product actually differ from what the customer actually wants? I also agree with the second sentence, but it should be broader. It should test the features, platforms, integrations, data integrity, security, performance, etc. I don’t understand the third sentence for if we don’t have the proper environment or setup, we should acquire them in time. If we do have a scope (referring to the fourth sentence) then I agree that we should not spend too much time on out of scope elements. They could be mutated or broken due to changes made somewhere else so regression/smoke testing should be implemented to out of scope areas. If the fifth sentence I don’t understand what is meant by “unapproved”. Unapproved by who? By the testers, client, developers, managers? It really depends, so making a claim like that is just nonsense. A REALISTIC TESTCASE IS REALISTIC BUT FLEXIBLE. -> Fight rigid descriptions with autonomy, critical thinking and challenging.

“Test Cases must be able to be successfully completed within the project scope and schedule.”

There is no point on writing test cases that are not run. But “must”? And why do they have to be “successfully run” and is a failed test a “successfully run” test? If a test finds three hundred bugs, is it successfully run if it doesn’t reach the expected result? WE CAN ONLY RUN AS MUCH TEST CASES. -> Fight the quantification of test cases with the amount of time spent doing testing. Count time, not test cases.

To summarize, I think the whole concept of SMART test cases is wrong excluding few things that I agreed with. I also encourage to keep the writing of test cases in minimum and the amount of testing done in maximum. Use the time wisely and appropriately! But if you do, you should consider these instead of the SMART way:

Fight ambiguity with openness and communication
Fight ignorance with eagerness.
Fight patters with chaos and vice versa.
Fight unnecessary documentation with rightly timed planning. I.e. keep the time between planning and doing minimum. Preferably do them at the same time.
Fight über control with proper documentation.
Fight rigid descriptions with autonomy, critical thinking and challenging.
Fight the quantification of test cases with the amount of time spent doing testing. Count time, not test cases.

I will leave you to this. I promise I will be back with more about test cases (if I have the time). I’m not saying “don’t write test cases”, but use your head! It is not smart (bun intended) to follow some rigid procedure for all context, but to adapt to situation and to make most of the time you have to test.

- Peksi

* Proper: Appropriate as automated as possible. Including video recording, automated logs, scans from scribbles, session sheets, statements, etc. What is required to get enough information to the decision makers without hindering the job of a tester.

Rought waters

2013-04-15T12:47:00.001+03:00

The next blog post is two-fold: the announcement for me attending the EuroSTAR Testing Conference as a speaker and the reasoning why I chose the topic.

So yes, I have been chosen as a speaker to EuroSTAR 2013 in Gothenburg. I thank everybody who has congratulated me so far and it is most likely that those people that have congratulated me have actually given me strength to keep on pushing and get my topic to be accepted. So, THANK YOU all who have supported me during these tumultuous times.

Some might be baffled why I talk about “supporting”, “strength” and “hard times”. That difficult time is the key to both my talk in EuroSTAR and to my life for the past few months. Here’s a summary about my future talk at EuroSTAR – Testing me:

During 2012 November I had a nervous breakdown: I was overwhelmed both professionally and personally. I did a job that I did not like too far from home. I wanted to be the most prominent star in the Testing scene. I wanted to be admired. But instead I burnt myself out. And I did it for the sake of my testing career. This is a story about hard decisions made to boost career over family and health.

I will tell how I felt before the melt down and what I did, the hard earned reputation and life-altering decisions about career, and how I started to buckle under the pressure. I will tell about the days I thought about quitting my job, what it took to get back to work after two months of sick leave.

This is “Testing me” - a reality check of the worst kind.

The topic is as personal a story as any. I didn’t speak much about my burnout to anyone mainly because I was afraid of their reaction. My closest family was aware of the situation to some extent but the full scale was revealed only after 3 or 4 weeks to my sick leave.

This talk is a therapeutic self-analysis on what went down during the burnout, and also a "come clean" kind of talk about why I was absent from all events and discussions lately. It is an experience sharing so that other people wouldn't have to go through what I did.

So, I encourage you to come and listen to what I have to say about my experience from stress, career and family, and the balance of those things. I don’t have the ultimate answer to all the questions about career moves, stress handling, etc. but I will share my thoughts on how I sailed through the rough waters. You might pick some pointers on what I did and how I handled different situations.

Even though the topic sounds distressing, I am now working full time and in a job that I enjoy doing. I also live closer to the office. The sky seems to clear a bit. A good sign, I think. I will also share what has happened during the time before the conference about my career, thoughts, etc. One could say I will try to make a full circle with the talk from the beginning of my career to the present day.

Anyway, hopefully I can manage a few blog posts about testing topics in near future to regain my status as a professional tester. ;)

Until next time,
Peksi

Reading Practice

2012-11-15T09:53:00.001+02:00

I’m reading currently a book called ”How to read a book?” by Mortimer J Adler and Charles van Doren. I have just started it but I talked about it in the office the other day. One of my colleagues said that one way to read a book is to first read the table of contents and the read the first page of every chapter. This post is an experience report on what can I learn by using a different reading strategy. This blog post will act also as platform for my thoughts when I read my target book. It was inspired by Erik Brickarp's blog post on taking notes.

The first pages of “How to read a book?” book states that there are two ways to learn from books: to illicit information, and to understand the book. My goal here is to run this exercise to illicit information. I choose a book called “Being logical” by D.Q. McInerny as my target book.

Preface

I decided to read the preface to be more in tune with what is going to be written about the subject. Forewords usually try to tell the reason behind why the book is written and to inspire the reader to go on. So when I got to the end of page 1, I decided to go on.

I had read the first paragraph of the book earlier (doesn’t count as cheating) and didn’t continue because of eldritch terms and words. Having read the preface, I the realized they will be explained. The book says it will concentrate to leave as little room for assumptions as possible thus trying to be explicit rather than implicit. Also it is not a text book for a class but a practical guide. This made me interested even more.

The preface addresses the structure of the book. It seems to be in five parts; each part building on the previous one. I’m interested if the parts contain what they were supposed to contain. The first part is told to be preparatory, the second one to lay the foundations, the third one to the meat and potatoes of thinking logically, fourth part discusses attitudes and fifth discusses fallacies. I know that I am fallacious, even more than regular people, so it is interesting to see what can I learn about myself while reading.

The table of contents

First thing that came to mind was that never before have I really read through the table of contents. This is the first time I really look into them. I usually skip the pages altogether to get cracking with the reading. Truth be told, I was quite excited to see how the table of contents was structured. It felt like a story was already told with the items on the list.

I pretty soon realized that every chapter had 8-30 sub chapters. Each chapter was about 1-5 pages long. I was starting to question my decision to read only first page from each chapter. For most of the sub chapters it would get the whole chapter done already. So I decided to read only the first *subchapter* of each chapter. They were, according to the table of content, almost always the introduction or foundation for the chapter.

Also I noticed that as for this book, it makes a great checklist for practicing critical thinking. By looking into the titles of each sub chapter, you would get a coherent guide to practice logical thinking. I could create a powerful mindmap out of those and print it on my cubicle wall. (And I will share it with you! Tadaa!)

Feel free to print this also!

Also this was a great stage to look for words and phrases you don’t understand that are essential to the understanding the content of the chapter. “Syllogistic”, “agnosticism”, “antecedent”, “equivocation”, “Post Hoc Ergo Propter Hoc” and “expediency” were new to me. Now that I checked them, I know better.

1st Part – Preparing the Mind for the Logic

I tackled it with my usual gusto; get cracking with it and read it again if I need to. And again I needed to read it twice for me to understand the message. I think I shouldn’t as this type of reading is just to get information. Sadly I didn’t /read/ it, I skimmed it. And after the second reading, I realized that the first sub chapter was exactly about that: Paying attention. And I had to pay, for it took my time and time is money. The book encourages you to listen instead of hearing, to see instead of looking. It gives great insight to the foundation of logical behavior.

The table of contents told that topics like “Effective Communication” and “Truth” were in latter parts of the chapter. This is the problem of this kind of quick reading, I see interesting stuff and I don’t want to stop reading. But I must refrain from reading more as I was to read this thing quickly, so on to the next chapter.

2nd Part – The Basic Principle of Logic

At this point, the technique I chose was beginning to bother me. I did read it fast, but this was only a glimpse of what it could have been. The principles could have been more thoroughly read but I chose to stick to my plan. The 1st subchapter was about the first principle of logic. Before the 1st subchapter was a brief piece of text regarding logic as three separate but linked entities; as science, as art and as skill. This did raise some questions, but I think they will be answered if I read the book with thought.

The first subchapter tries to focus on practical side of things. The theory will be discussed elsewhere, but I was intrigued by the the notion of reading even more about the theory of logic. This subchapter proved some examples which clarify the link between logic and human reasoning. Again I was tempted to read on, but managed to jump to the next chapter.

3rd part – Argument: The Language of Logic

The subchapter was about founding an argument. I did have some experience in the practical side of forming an argument, as I had been practicing that with Michael Bolton on Skype, so I knew the elements to build an argument. Those were “premise” and “conclusion”. With the help of examples the book showed some good uses of supporting and supported arguments, giving me a good ground to build upon – in fact just like the preface promised.

As this on itself might have been a good starting point to a person not knowing anything about logic and was just seeking a quick 15 minutes intense session on logic, this only made me hungrier to read through the whole chapter. I noticed that, if not the writing style or the content, my eagerness to read on was huge. I had to struggle every time to quit reading further.

4th part – The Sources of Illogical Thinking

I was a bit taken aback with the concept of writing about things that made you illogical. When writing about negative stuff some might absorb the “bad habits” instead of seeing them as negative. After reading the subchapter, I felt that it only made me stronger thinker and I was trying to spot those weaknesses – you might say - and try to find ways to mitigate them.

Skepticism was the topic of the first subchapter and it was really informative. It gave insight on selective skepticism and to behavioral skepticism – and gave some concrete examples. I began to think immediately about exercises I could to using skepticism in my coaching. I may have already done that but unintentionally. Not I could be even better at forming an argument. The book made some examples about damaging skepticism but tried to enforce the power of healthy doubt – doubt as a catalyst for learning.

5th part – The Principal Forms of Illogical Thinking

This 5th part was about fallacies. They were explained to be the typical patters people do/use to act illogically and to build illogical arguments. Usually fallacies appeal to emotions so they are more powerful than sound logic. Again by recognizing the patterns I might be better at building an argument that is based on sound logic.

The lure of using a fallacious argument is high, because it might be quicker and more effective than using sound logic. Even though you’re right and have a sound logic behind the conclusion, basing that on fallacious argument is almost never a good thing – it might bite you back when you least expect it. I had read something about the fallacies so this area in particular was really tempting.
Afterword
The afterword was a good reflection through the book. They stressed the concentration when arguing so you focus on using your logic in building an argument. I rarely read the afterword as I see no input to the meat and potatoes of the text. I did realize that the afterword did provide a fresh view to the book as a whole. It might even be effective to read the afterword /before/ starting to read the book itself as it can provide a fresh view to the book before trying to tackle the reading.

About the exercise

After having done the exercise, I feel it was a good practice. I might use it again but with a twist – I will write up questions about the first page/subchapter to a piece of paper and try to answer those questions as I read on. In that way not only will I illicit information, I will begin to understand the meaning of things.

The exercise was good fun as the text was close to my liking – it wasn’t a textbook but a guide, the topic was near to me, and it was short enough – so the exercise was a bit easy. It was good for a first experiment to this kind of reading, but I need to make this process more efficient. I might even learn more about this type of “stub skimming” (if there is no word for this type of reading, let it be that).

So right now the process goes like this:

Choose a book to your liking (any book will do)
Read the table of content
Read the preface
Read the first page of every chapter
Read the afterword

On every step, make notes and questions about the content
If there are fundamental questions about the content, read on and find the answer.

Thoughts

This is just one way to read. This is more like giving an indication of what the book is about. This is not used to understand to book but to have some knowledge of what there might be if you’d read on. This is a good way to tackle a book on before you read it thoroughly, because you already have questions about the content. On the time you re will systematically read it through (or parts of it) might be significantly faster and make it easier to understand.

Now I need to continue reading the book about reading a book. I think I will use this technique to give me a head start.

How to get anyone to do anything!

2012-11-13T08:06:00.001+02:00

This is how! Go ahead, read this post and you will find the keys to tapping into your or anyone's motivation. I will tell you how you can find motivation to do anything, or to motivate anyone to do anything! I will describe briefly the 6 steps that will make you find motivation to get things done, I will tell what is the force behind motivation and I will share some of my own experiences on success and “progress ongoing”.

Instant influence

I have written previously a post about what drives people to act. The Drive (written by Daniel Pink) has given many answers in how to motivate people in the modern society. For me, that lacked tangible examples, practical process and, odd enough, ways to motivate myself to be motivated.

I follow Daniel Pink on twitter and he posted a blogpost about something called Instant Influence. He just glanced the topic by asking two very powerful questions: “On a scale of 1 to 10, how willing are you to change?” and “Why didn’t you choose a lower number?” Immediately I started asking those questions on why I might want to do something. I began to defend the will to WANT to do something instead of finding excuses why I don’t want to do it.

The writer, Michael V. Pantalon has captured the essence of motivation in the book Instant Influence. It describes the process of asking questions from the “influencee” (he calls the participants of the motivation discussion “influencer” and “influencee”) and allowing her to find her own reasons to embark the road to change.

After I read the book I was in a motivational high and now I will share some of the secrets to you. I will urge you to grab a copy of the book and to read it yourself as this is but an excerpt from the book. The book has special ways to motivate yourself, change resistant people and coworkers, even strangers. There are ways to spot different kinds of indication of budding motivation on people that do not seem to be motivated. It’s quite quick to read and has plenty of practical examples on which to draw useful practices in real life.

The Instant Influence process is based on 3 cornerstones:

No one absolutely has to do anything; the choice is always yours
Everyone already has enough motivation
Focusing on any tiny bit of motivation works better than asking about resistance

Scare tactics don’t work! If you get bullied into doing something, you’re just as likely to choose not to do it. By saying things like “have to”, “should”, “must”, etc. just strengthen the barriers of resistance. Asking about “why might you choose to do it” is more important than telling the effects of not doing something.

6 steps to success

The book describes a process for finding the motivation. The process comprises of 6 steps. All individual steps are analyzed in the book and the power behind them is revealed for you to make the most use of the process. Every step has examples of different flavours on how to get the best out of the step with different people and situations. The process goes roughly like this:

Why might you change?
How willing are you to change?
Why aren’t you less willing to change?
Imagine you’ve changed. What positive might become of it?
Why are those reasons important to you?
What would be the next step, if any?

The first question is to allow the influencee to state the problem and to tell why she might want to commence the process of changing behavior. Asking “how might I change” may bring results but the reason behind the change could prove to be more important than thinking the actions. Trying to figure out how should one change can be overwhelming if not clear with the reasons behind the change.

When asking people “how willing they are to change” the question should be detailed to fit the situation. If I wanted to motivate myself to clean the apartment, I might ask myself: “How willing, on a scale on 1 to 10, might I be in clearing the living room table?” By breaking the task into smaller pieces and motivating oneself to do at least one of the smaller tasks, one can create a snowball effect and end up being motivated to clean the whole apartment and the garage! The number, which should be had in this question, is trivial but it creates a base for the next step.

Let’s say, I answered a “5” in the previous question. I might then ask, “Why didn’t I choose a 4 or a 3?” Then I will immediately start defending the reasons I MIGHT WANT to do the task at hand. This also gives you the opportunity to state the reasons, obvious or hidden, behind your budding motivation. Sometimes, questions 2 and 3 can give enough ground for the influencee to get motivated, but I always ask the influencee if she might be willing to answer more questions.

At the 4th step the influencee is allowed to imagine the world after the change. You can create a scenario where all the obstacles are cleared and the ultimate end result is reached, thus removing any negative influences that might arise at this stage. Focusing on the positive images might motivate the person to begin the journey to the destination, but remember to break the task into smaller goals to make the transition to being motivated easier. And I assure you, the smaller you make your goals on self motivation, the easier it is to start actually doing something.

When the influencee can identify the positive outcomes, she should be asked why those are important. Autonomy is the key here: “Why are these reasons important to *you*?” Drilling into the most deep and profound reasons might be intimidating, but after realizing that the deeper, most personal reasons are the ones that drive you to do things, you can get things done more easily and quicker.

The 6th step is important so that the influencee is clear on what she wants to do next in order to get gears turning. Again it is important to enforce the influencee’s autonomy and power to choose her actions. By asking “What might you do next?” instead of telling, can be the crucial element of finding the true motivation to do something. The action plan can be as simple as “I want to go to the living room and look at the coffee table.” or as detailed as necessary, verbal or written. But I encourage you to have an action plan. To make it even more powerful, state the reason why might you want to do it. “I want to clean the coffee table to make room for my coffee mug. I live my morning coffee when I watch the news and I don’t enjoy holding the cup on the sofa pillow.”

One thing to remember is to choose *active* actions in your action plan, that is to follow the “Dead man’s rule”: Never choose an action a dead man could do! “Don’t eat too much!” could be “Eat just enough to make you full but not too full.” “Don’t smoke!” could be “Smoke 2 cigarettes less a day for one single week.” Be active about the change, however small a change you’re aiming at.

Live exercise

This is an example of me using the instant influence on myself. I will be bith the influencee and the influencer. I will ask the questions and I will answer what is the first thing that comes to my mind – no later editing, but I will add some notes in brackets afterwards. I have a task that I want to do: I want to write a column to a testing magazine here in Finland. The due date is approaching (or went past already) and my brains are refusing to provide input to the task.

Influencee me: "I want to write a column, but it seems too hard."
Influencer me: "Why it seems too hard?" (I don’t fully understand what makes the writing so hard.)
Influencee me: "I can’t find anything meaningful to say. The ideas I have feel crappy and incoherent. I wish I could find a thread which I could then follow through the column." (I’m frustrated by the situation.)
Influencer me: "Seems like you struggle with a problem that feels too big. What is the smallest thing that you can do to get started writing the column?" (I try to scale things a bit and try to find some spark of motivation.)
Influencee me: "The smallest thing would be to… well… open Word and start typing." (I try to dodge the responsibility.)

Influencer me: "Seems reasonable enough. Why might you want to do it?" (I try to enforce autonomy. I also fell into sarcasm there, which is not good as I could have been more objective about the situation as a whole.)
Influencee me: "Like you asked, I want to get the column written."

Influencer me: "On a scale of 1 to 10, where ‘1’ meaning “not ready at all” and ‘10’ meaning “as ready as possible”, how ready would you be to open Word and start typing?" (I could have tried to push on the “why” with the reasons I want to get the column written, but I thought that I can always ask more about the deep reasons later.)
Influencee me: "To be honest, I’d say about a 7. I like seven, because it’s quite high but not nearly the highest as it could be. Ok. To be totally honest, I’d say 5." (When I really started to think about how motivated I am, I realized that my motivation is alarmingly low. The impact of really thinking about the number was quite important to me. It may not be to others, but knowing about the process, it felt really important to me. The number is arbitrary and is there just to form a base for the next question, but can create surprising effects.)

Influencer me: "Why didn’t you choose a smaller number?"
Influencee me: "Well… I do want to write the column, as I have promised to do so. I also want to share the thoughts I have on the subject as I think many other people are struggling with that kind of issues. It is also a good way to get my name out there to be seen as a writer. On a 4, I would be saying that I don’t want some of those things, but I do." (I started to defend my reasons. By this point I was ready to increase my number to 7, but didn’t. I already had some thread for the column formulating in my head.)

Influencer me: "Let’s say you have written the column. What would be the positive outcome of that?" (I created a happy, sunshine scenario where there is no evil and all columns are done within deadline.)
Influencee me: "I would get the appreciation of my peers. They have worked hard on their papers, and by completing mine I have shown the same dedication towards creating a good testing magazine." (I reflect my actions against others’ but it feels like a shallow reason.)

Influencer me: "Why is the appreciation important to you?"
Influencee me: "I feel that the status of testing professional needs constant visibility to the public and to the community. The appreciation feels like a materialization of the reputation in the community." (Here it started to get personal. I was thinking about stopping writing, because I had no idea where this talk would lead me.)
Influencer me: "Why is the reputation and more so the good reputation in the community important?" (Drilling into the most important reason.)
Influencee me: "Well… to be honest. I might feel that because I have no doctoral degree or the like to boast around, I must constantly prove myself to be worthy of the status I have achieved in the community. Or I think I have achieved it." (I’m constantly saying “to be honest”. I’m trying as hard as I can to be. As much as I want to succeed in the exercise and make it as authentic as possible, I want to get the column done in time.)
Influencer me: "Why do you feel that the status is important to you?"
Influencee me: "It makes me feel like I’m worthy."
Influencer me: "So, you might want to write the column because it might make you feel appreciated and worthy. Is that correct?" (Here I reflect what has been said and formulate them into a single sentence motivation statement. I also try to enforce the autonomy by checking that it is correct.)
Influencee me: "I guess so, yes - to feel worthy of the perceived good reputation."

Influencer me: "So what could be the next step that you’re willing to take, if any?" (I leave room for choosing not to perform any actions.)
Influencee me: "I guess I will reserve a 90 minutes brainstorming session using a mindmap to clear out my thoughts and to create a plan for the column. I will do it while in train to work as I have plenty of time then, but I will make a calendar appointment so I can remember it. That will help me to find the thread and inspiration for the column. I might even finish the text while I’m at it. If I can’t find a thread while doing so, I will write about not finding thread." (I made a plan that has a specific action, a reason to do it, and a situation to amplify the action. I also mention a next step, which I didn’t even thought I was planning. In addition to all that, I made a plan B if my initial effort fails to give results.)

Now we just have to see if I was able to finish the column in time. :)

---

PS. If you feel like trying this in real life, contact me through Skype and we can try to motivate you to do something that seems too hard for you to do.

Testgasm

2012-11-06T10:23:00.000+02:00

This is a blogpost to describe what was going on in the Rapid Software Testing class held by James Bach. This is not meant to be a comprehensive analysis on what happened or the lessons I learned but few highlights and hindsight analysis on what happened.

The dice game

...this is just a few of what we had...

Those that have been attending the dice game know that the initial exercise is hard. When one gets the idea on how the algorithm goes it’s easier to play variations on the game by group of friends or colleagues (not to say these are necessarily different). I (thanks to Michael Bolton’s course), Henri Hannuniemi and Sami Lehtonen (thanks to Antti Niittyviita) had played the game earlier and so we were grouped together and given a different algorithm than the others. I was so thrilled by the idea that I could use all the skills that I had learned to crack that nut open.

The game started and we were given a bunch of dice: a handful of regular, different colour/size dice; few D20 dice; few D10 hand drawn dice; a die that was in a transparent die; some “poker dice”, etc. We had so many variables that we became a bit confused. I started a list of different things that we could be analyzing. The size, the colour, dots or numbers, amount of dice, type of dice, arranging of dice, “zero is not zero” etc. We then arranged them so that there were different D6 coloured dice stacked together in different ways, five groups of five. James came to the table, we said “2” as a guess for every single dice pile and James replied “0”.

We had the miscellaneous dice lying in the stack nearby and I thought I ask a reply on that also. I said it “2” also and James replied “1”. A one? We had a huge number of different types of dice lying there. What could it be?

We proceeded to arrange the dice in a fashion that there were 2 or 3 special dice and regular dice bundled up so that all special dice were in use. All but one group ended up in a “0”. The one that was the “1” had the die where there was a dice within a dice. A frantic math calculation ensued. We tried to sum up the two dices together, but the result was always a “1”. So I took the die in hand and turned it so that James could see only “1” and a “2”, and we thought it was a “1”. The answer was “2”. Frustration!

Testgasm

We then analyzed the steps we took to get to that “2”. We had a couple of theories, but when the die was on the table, it was always a “1”. Heureka! We took five dice off the table and said “5”. And a five it was!

The thought process took 3 persons 20-25 minutes. The sparring between the team enabled us to try different even crazy-sounding ideas to good extent without exhausting our innovation. We simplified the data and made it more complex. We tried to look for changes in the output by varying the input. We used the different models of problem solving from our lives to figure out the pattern. We also solved a pattern composing of vocal input pattern (I save that for one of my exercise in the company) and one with a difficult mathematical pattern composing of differently grouped dice.

"Give me your hardest problem!"

Like James said, we were doing testing Kung-fu! Solving problems like matrial artists! Bonk! Blam! Thwaak! Zlott! Swoorsh! Phatam! Ka-pow! Like Batman fighting crime, we fought problems! (I’m getting a bit excited here, if you can’t read it from between the lines.) We all felt like we were invincible and we had the tools to crack every problem in the world! “Give me your hardest problem and I will solve it for you!”

The high after testgasm

After we got all the patterns solved we were all ecstatic about what we had done. We were in a problem-solving high! The word to describe the feeling would be “testgasm”. And truth be told, after a serious testing session where you find something awesome, something really important; you will get a testgasm. I’m not sure if other that testers understand the rush after a successful testing session; it is hard to explain. The joy of completing a hard task and feeling joyous about it in ways you never thought you could be. That feeling is something that testers all around are looking for when they test. Your face may light up and you yell “Yes! I got it!” and other people in the cubicle stare at you like you’re deranged.

Focus/Defocus

I had heard the concept of focusing/defocusing in Michael Bolton’s class before but I never truly understood the meaning behind it. ("If focusing is focusing, defocusing is the opposite of that") I tried to look for material online, but it was all vague and didn’t make an impact. The way that James described the method was simple: “When confused, focus; when frustrated, defocus.” Wow! When testing one sometimes loses momentum and struggles with a single piece of data for long time. Using input patterns that don’t find the problem may lead into frustration. I felt exactly that during an exercise about systematic testing.

James had us testing a piece of software that had a bug in it. We were asked to find the bug and then try to figure out why it fails. The input was a valid IP address. You know what I figured out? I have so strong built in mental models about meaningful number combinations that I was grinding my teeth and sweating to break that pattern. I had tried a pattern by testing the high and low numbers, duplicate numbers, you name it. Could I just be blind to the bug? Then James said “Look into your data. Can you see a pattern?” Yes I did. And lots of them! “Now try to find an input that is as different as possible from previous data.” And guess what IP address I used? “1.2.3.4” That’s right! I broke my pattern by trying “1.2.3.4”! What was I thinking?!?!

James was like “Dude! What the hell?” and I sat there frustrated and confused. Then I realized what he had meant. If I had drawn a line to represent my test data, it would have been like this:

I just needed to break the pattern and be more random and use data from between my clustered data pattern. And with first random IP address I put in, I found the bug. Later James explained why the program behaves like that, but I can’t remember the true root-cause of the bug, but I did learn a lot about focusing and defocusing.

Hung over (from learning)

It has now been two weeks since the course. After the class I was in a high that lasted through the weekend. I thought about giving a thorough analysis about the course but I see no need for that. I had the time to let the learning infuse to my spine and now I feel that the stuff I learned make even more difference. I did have an information hangover after the class and it was hard to get back to grips with non-testing work again. I was glad, however, that I could attend the Intensive course the next week so I wasn’t that bummed.

I recommend the class for everyone willing to improve their critical thinking, testing skills and/or argumentation skills. The exercises were good and to the point. The hot seat treatment James gave to some of us gave us experience to stand pressure and perform well when in a stressful situation. I also learned a lot about myself and the way I learn. It was also cool to hang out with great testers like Samuli Elomaa and Aleksis Tulonen.

I still have a long way to go and a lot of learning to do. (After James mentioned it) I began to think myself as a constant student, always learning. I promise James (and I will talk about this to Mr. Bolton) that I will try to compare the classes done by him and Michael. That way both of them could learn what could be done better or differently. That however will have to wait a few days (i.e. weeks) as I have a growing backlog of blog posts.

Are you part of the faceless masses?

2012-10-31T08:16:00.000+02:00

I was on my way home the other day when I happened to talk to a woman who works in HR in some consultancy company. We were talking about how to get oneself hired to a company and how to be one step ahead of the other applicants. With recent discussions with James Bach in my pocket I became challenging her claims about employing oneself and best practices thereof.

What she suggested was that by certifying one can have an advantage in the job market. If one is not certified there is no knowing what the person can or can’t do, right? Certification is the first gateway to rule out incompetent testers, right? I had some thoughts about this prior to talking to James but some of the arguments that I had been using were lacking momentum. James gave me some golden thoughts in how to be one step ahead of the cattle of unskilled certified testers (I believe that if skilled they will see that the certification will not get them employed).

Certified terminology

Certification by name certifies a certain characteristic of a person, object or organization. It is not comprehensive but directed to a specific area. It can be achieved by passing an audit, an examination, a course of some kind, to name a few. Certification is not to certify the skill of doing something but the knowledge of some fashion. It can be of terminology, syntax, operating system details, etc. None of these, however, point toward the skill of doing something.

The certification where you get certified by defining a set of terms is quite usual. You get the information from books and then you take the test, usually multiple-choice examination to ease the assessment process. You can basically get a certification by guessing the right row of answers, having a list of those answers achieved by cheating, or by memorizing a set of terms. Because the test doesn’t aim to assess the understanding of those terms the value of it is quite minimal.

As terminology changes from company to company, from context to context, we do not need to memorize a set of terms and apply them by force. We need to understand the meaning behind the terms we use and to explain them. Then, if conflicting with the other terms within that context, the use of terms must be adjusted. If you say “testing” and mean “systematic evaluation of the quality of the system using various techniques applicable to the context”, and the organization uses “uggabugga” for that same meaning and “testing” for coffee tasting, it might be good to adjust the use of terminology for that context. If you just keep using the term taught to you by some book somewhere, you will drive yourself unto a cul-de-sac of misunderstanding.

Proving skills and standing out

The testing certification provided by ISTQB is a good example on how certify a tester without any skills to actually test. It is a book examination, essentially. More so, there is a course aiming to pass the test. I’m not going to talk about the syllabus at all, but about the skills taught at the course, or the lack thereof. The certification doesn’t aim in proving skills of the tester. A tester with no experience in testing can go to the certification examination and pass before doing any testing at all.

A recruiter going through applications for a job look for something that might look for certifications as a proof of skill. When confronted by a certification that by nature does not measure skills but the knowledge of terminology (which obviously is the wrong way to go) the recruiter might confuse the person having skills. This is not to say that the applicant doesn’t have skills, they might very well have a huge set of skills, but they are not the characteristics that get you to the interview.

“If you don’t get to the interview then you cannot show your skills. That is why I use the certification to get to interviews!” I hear you. Read more.

Rising over the masses

The recruiters have a hard decision in determining who to call to interviews and who not. They look for something that stands out! You might think that a certification gets you the interview. Stop there for a moment. How many other applicants you think do the same thing? How many of the 500 applicants to a Test Engineer job have the exact thought of having a certification as a ticket to interview? 50? 100? 450? This obviously depends, but think this: The certification makes you part of a mass of people. By using a generic way to stand out, you’re “massifying” yourself – you become part of a gray mass that doesn’t stand out in any way.

Like I asked in the beginning, “Certification is the first gateway to rule out incompetent testers, right?” it actually is so. But it not a gateway only to rule out incompetent testers, it is there to rule out incompetent recruiters. A person without proper testing knowledge, skills and passion does not know how to recruit a good tester. He may know a little and thus relies on the magic of certification, at least a little. Even the most unqualified recruiter is looking for SOMETHING to make the call who to call to the interview. By having 90% of the applications look the same, they have a hard time deciding. The gateway works so that it rules out the certified testers and leaves those that have the spark, the passion and the skill. Do you want to be the one getting the interview or be ruled out because “you don’t have the spark”?

First thing recruiters see is the application. We are force-fed the template from recruitment agencies and we use that. We are afraid to be different and difference is what you should be aiming for! Instead of creating a dull list of what you can do and schools you’ve been to, do something else! Write a bug report where you describe your behavior and characteristics. Do an interview of yourself and post it like a newspaper column. Send them a video of you testing a product while explaining what you’re doing. I could go on and on! Be outrageous, but professional. The point is to make a statement. Send a filled template and you’re doomed.

Conclusions

When I had explained myself to the HR person on my way home, she said: “Well you’re obviously a guru, so you don’t need a certification.” That is not correct, although I briefly basked in admiration. I’m not a guru any more than the next guy. I have passion and I’m not afraid to show it! I have goals and I’m not afraid to tell them! I have a hard built reputation as a tester and I'm not afraid to promote it! (Maaret might say “He’s cute when he rambles.”)

Every single tester can be a professional, and they should. Every single tester can apply to a place where they want to work and get employed, and they should. Be ambitious, be excited, be passionate. And show it. Don’t fall into marketing trap and be part of the mass – be you!

And get refining that CV right now!

Flashback to Learning

2012-10-24T20:15:00.002+03:00

I rarely have the concentration span to write complex and analyzing posts. If I believe that the subject has more to it than I can scribble in 90 minutes, it will more likely become a candidate for an article and will be more fine tuned than a regular blog post. Now I thought I would write an update to my blog describing the second day at the Rapid Testing Course, but then I thought writing another a diary-like entry was not exciting enough - and I want my scribbling to be at least a bit exciting.

So why do I have to make a blog post about something that I’m not willing to investigate? I don't! That's the beauty of it! But I want to make a quick post on something interesting. In order to do a blog post from something that requires little to no research it could be about an experience that is worth sharing. This post is not from today’s class but from past but the topic was brought up today in the class.

James Bach and Michael Bolton use the Socratic Method to help learn stuff in their courses. To simplify, they ask a bunch of questions from a tester to squeeze out an answer - not possibly the right answer but one good enough. I got my share of the method in the class but I’m not going to talk about that. I’m going to talk about an event that happened 4 months ago. (Enter fairy bells tinkle and a wobbly picture to demonstrate a flashback...)

I wrote a white paper about six months ago about heuristic testing implementation that was discussed in a Peer testing session late last year. The article was about to be published in a testing magazine and it was fine tuned for couple of months by the editor and a couple of voluntary proofreaders. I still wanted to have a comment from James Bach and Michael Bolton as I have a respect for their opinion in all testing related issues. And so I sent a reviewed draft to them and waited for approval.

What then happened, I couldn't expect. I had high hopes on the content of my article as it had been reviewed multiple times by bunch of different people. I thought I was in a verge of a breakthrough and praises would that flying my way. Instead, James’ reply was simple:

“I'm completely opposed to this.”

What followed was an exchange of emails between me and James about the problems with the article. It concluded in a suggestion to remove the essential elements that I based the article on. I thought James had got it all wrong and I requested him to discuss the difference in views that we seemingly were having. Skype was the medium of choice.

We ended up talking for 90 minutes. First we were talking about the article itself and he clarified some points he had made earlier. Then James challenged some of the essential elements of the article and I tried to defend them as best I could. All the while doing so I thought better descriptions for the principles I was using. I was on hot coals during the conversation: if I had chosen a bad wording for my answer, he would grab it and ask the real meaning behind the words I was using.

The article did not survive, but I did. Later I was a happy to have endured the barrage and decided to hone the article so that I could later publish with pride and joy. I never really understood how much the discussion had given me, though. I had learned some very valuable lessons. The critique on the article was secondary compared to the practice I got performing under pressure and all the while holding to my beliefs. As James said in the course today, there is none worse than tester who is “pathetically complying”. I could have said “OK. I won’t publish! Just don’t yell at me.” and I would have lost all my credibility. I learned how to defend something even though I might be wrong. Ilari Henrik Aegerter gave me a coaching session once where we practiced exactly that: how to be able to defend your point. And so I became better at explaining myself and defending my point under pressure.

What I would have done differently is that I never really tried to sympathize to James’ point of view as I so aggressively tried to get mine across. I could have got more out of the conversation if I had listened more carefully and sought for meanings and advice that he gave between the lines.

Having shared this experience also enforced the learning that I experienced, for I was able to verbalize some of the stuff that I had thought only briefly. Next steps for me are to revisit the article bearing the real purpose of the article in mind, and try to make it better (if not perfect). The article is resting and collecting dust currently, but I will tackle the beast soon enough. I believe that the Rapid Software Testing course will give the inspiration boost that I need to get it done (although I think extrinsic motivation plays no part in this, as I already WANT to finish the article). Too bad I didn't sign in for the Let's Test! conference with the paper. ;)

One down two to go!

2012-10-23T18:59:00.003+03:00

And no, I will not link the King Diamond song here (even tho it’s cool). This blog post is about my experiences from the first (my second first day) at the Rapid Software Testing course by James Bach. I seem to be one of the lucky few who actually are able to have two goes at this amazing adventure to the deep dungeons of an exploratory testing mind.

Like I tweeted earlier, I fell into traps; the most obvious traps that can be set for a tester. I know I can do better so here’s a quick analysis on what happened and what could I have done better:

http://morningandotherstories.wordpress.com/2011/12/

Context: When I was confronted with a testing problem without a context, the first thing to do is to determine the context. Right? Here’s what I did: I thought I might sound too clever on asking and challenging, so I answered the question without determining the context. This lead into questioning my answer and making me realize that “we’re shooting live ammo here”. So I decided to sharpen up.

I could have done what I (try to) do every time I’m facing a problem: Understand the context, the people involved, the background, the current status, the mission, etc; communicate with the client, stakeholders, testers, etc. That could have brought the whole problem into a new light. I fell into a clever-trap.

Pattern and mental models: I had the advantage/disadvantage to see the formula for a pattern beforehand. The task was to determine what the pattern was. Those that have taken the RST course will remember this, right? I remember the point of this exercise being to break the assumption and to focus and defocus. Again, my previous knowledge bias struck in: I completely ignored testing the product and did some of the procedures I had seen done in previous classes. The pattern was the same, however, so basically I didn't lose anything…

…EXCEPT FOR EXPERIENCE! I could have spent the time testing in ways I had not tested before. Now I had the time to do something different. Instead I tried to look good by using Excel (like James Whitaker, I think) and I made a simple script to produce test data. I didn't even bother to check the logs, as I had checked them numerous times before. Should they have changed the behavior even a bit, I wouldn't have been able to identify the pattern. I fell into a showman-trap.

http://members.multimania.co.uk/mrmal13/saints/amardas.htm

Documenting: The task was simple: Write tests and justify all of them. James specifically asked everybody whether they had made a justification for ALL the test they were going to run. An exploratory tester documenting test cases and justifying them all with specific, detailed texts? Can you picture that? I could hear myself saying within my head “Yes, James” without even questioning my so obvious bias. I tried to be a good boy and wrote them cases and then feel pride.

The exercise was about justifying the testing but in a different way. My doing inexpensive testing and discovering something worth discovering, one can justify a more expensive testing. Like James said: “The cheap tests pave the way for the more expensive ones. They are the scouts that look for a good spot to place the artillery.” That comment alone is worth its own blog post. But instead of being inquisitive, exploratory tester, I became a test designer that is going to get fired. I fell to the guru-awe-trap.

So my first day was a success: more learning than I hoped for. I also thought that I had some form of advantage of knowing the stuff from previous, but it seems that I had misunderstood (or belittled) some basic principles of Rapid Testing. I felt some of the stuff explained more comprehensively, with sidetracks to bulk up the areas where I thought the content was thin (namely the modeling and project elements of Rapid Testing). I do wish James would have covered the modeling heuristics with more depth, but I will leave room for other areas for the next two days.

What I’m looking forward is the process of Rapid Testing itself. I somehow missed a whole lot on that subject when Michael Bolton was teaching the course. Also to hear more about the oracles would be nice. We scratched the surface today but we’re still to cover some of the mnemonics that I frequently use, like CIDTESTD, HICCUPPS, etc., but it was nice to see an update to SFDPOT with the Interface addition. I will be using that when I reinvigorate the workshop in near future.

The importance of the context

So as I’m heading home, I will share this one particularly funny event that happened in the beginning of the class. Here’s the story without context:

James Bach spit on Aleksis Tulonen.

If you add context, here’s what really happened: Some poor fellow was getting given the “Socrates treatment” by James and he had an act prepared for the response the guy was going to give. He asked a question and set a trap onto that question. He knew the answer would be something “horrifying”. So he took a sip of water after asking the question. When the poor fellow answered James theatrically spit the water from his mouth as if being so stupefied by the answer that he just couldn't bare it. Unfortunately the aim of the jet of water was a bit off. Aleksis, who happened to sit in the front row next to me, was a victim of the poor aim. Aleksis’ phone and computer got some droplets on them as collateral victim of this splendid act. Hopefully tomorrow’s newspaper doesn't have a title “A testing consultant got spit on by a guru”.