How You Measure Success In Testing?

Very early in my testing career I understood that this will be tricky: it is hard to say when you are successful as a tester. Even worse,  it is hard to be proud of anything in testing.

There was time that it was cool to write many as possible test cases or to find many as possible bugs. That was success. But now those times are gone. Now testers question stuff and support teams.

I raised 10 questions yesterday, today I asked 12 – yeay, I am pretty good at this!

OK. Let’s assume for the moment this is how you measure quality of a tester. If asking more questions shows success, then we will want to ask more questions to be more successful. 15. 20! 35? And suddenly questions becomes a noise and distraction for a development team.

My current answer how to measure quality of a tester is following:

Testing is a service. If tester brings value to the development team with what s/he does than s/he is a good tester.

Food for thought – what kind of testing team would you call successful?

 

My personal success

I wanted to answer the question for myself – am I successful?

For a long time I thought I wasn’t. I am an autodidact in testing. I even cannot say that I learned on the job, all learning happened in my free time. There was no manager or senior colleague at any point of my testing career who would guide me through the subject. Google was my friend. Developers around me did not like testing, managers around me always wanted me to do manual checking. It took time and mental strength to understand that there is more. From that moment on I started to practice selling and explaining testing. I had very different results. I started to doubt myself. I looked up to big names in testing, compared myself to them and though I paled in comparison. I was sure that on my self-education way I missed the turn and miss some existential  information. I felt like a fraud…

But then something happened. I attended an open space, run a session and apparently my statements annoyed one of the biggest names in testing. He got angry, we started to argue and then he asked me whether I knew what a state chart was. I said no, causing him to raise his voice and to ask me in front of the group how I dare to call myself a tester. That was it! Somebody was calling me a fraud, but instead of being ashamed, running away and hiding, I answered him with confidence: Yes, I am a tester!

Suddenly I understood that I am very special kind of tester. There is only one of me. My experienced shapes how I test software and how I communicate with people. It will not work for every team or every manager and that is OK. There is no one universal answer to a question. BTW, I looked up immediately after our dialog what “state chart” is. I realised that I knew it, but only in Latvian.

If I do consulting and my client wants me to automate UI tests in two weeks and then leave, I could do a few things:

  1. I could start to explain what testing is, how it works and what you can do with testing. And I will crash and burn, because the client will be frustrated and overwhelmed with this information, which will turn around everything they know and how they work. How do I know it? I experienced it.
  2. Or I could “shut up and simply do the job” (greetings to Mark ;) ) that I was contracted to do.
  3. Lately I choose to combine both. I do the job, but I involve other people to whom I explain what I am doing and why, so that after I am gone they could carry it out by themselves.

Is this the only possible solution? No. It is my current one. Next year it will probably look completely different, because I am continuously learning and improving my methods.

Now, when I look back to when I thought I was a fraud, I can not understand why I felt that way. I always had a job offers and I got mostly good feedback from the teams I worked with. Why I did not recognise this as success? I have a page on this site for speaking engagements.  Average only two appointments per year. To some it could look very empty. But for me it is OK. I have a day job, I have a family, I have hobbies and I am member of several local groups. Two to three talks a year is what I am comfortable with.

As I get older, I find the strength not to compare myself to others. I compare me with me. If I read one of my old blog posts and feel ashamed – this is good thing, because it means I learned something in-between.  

 

 

Attracting Girls To Engineering

Statement “girls are not interested into engineering” is wrong.

Take me as an example. I had loving parents, but they had strong opinion what kind of toys are meant for girls. I beg them, but still never got a car or train to play with. Never understood why I cannot wear pretty dresses AND play with the trains?

Later at school we had craftsmanship lessons. Girls did cooking, knitting, crochet, weaving, boys could build something from wood and they took plumbing lessons. One thing I was interested in, but never were allowed to try. Because I was a girl.

At university one of my professors once told me: no way you wrote this code yourself!

It was so frustrating… I did not get chances to show what I am capable of OR every time I delivered something, my work got questioned just because I have no penis!

Based on my experience here are seven simple suggestions how you can attract girls to engineering:

  1. give chances to girls to try
  2. do not question results what they deliver. no comments that they could do better. they will do better after some time of practice
  3. invite not just one girl, but all her girlfriends. it is safer to fail, if your friends are around you
  4. find a role model. tell stories about women, who was the very first programmer, did very first debugging, wrote code to fly to the moon etc.
  5. listen when a girl talks
  6. make no suggestions if she does not ask for those. let her figure it out for herself
  7. if you see somebody doing opposite what I wrote in 1-6, call him/her out, tell that it is wrong. tell to the girl, that it is wrong

Today I Learned

Last September I joined trending and became one of the ISTQB trainers. I have a whole story “why?” and I plan to share it one day, but today I want to talk a bit about learning.

How I see learning from the trainer side is pretty ugly – mostly students do not want to learn. It is trendy to talk about learning and training should be safe place where to learn, but in many cases ISTQB is something where they have been sent by a boss or something, what they think they have to do, to get a next shiny job title. I try hard to make trainings entertaining (I carry different testing games with me) and informative (learning materials, stories from the past), but sometimes it is simply not working. Sometimes I am happy that at the end of the day everyone simply memorised what negative test is and why we should do it. Most challenging are the ones who refuse to understand some definitions or concepts, for example, difference between validation and verification. Most frustrating if this is a person who has 20 years of experience in IT. In those moments I ask myself, is this really for me? But then I remember my “why?” and everything is OK again. Part of that “why?” are students, who are engaged and eager to learn everything I can share with them. They did some research upfront and have clear vision what they need. It is highly rewarding to work with that kind of students. Discendo discimus – while teaching we learn.

In trainings I invite people to embrace failures, to share experiences, to learn from each other, to use synergy. To help them to do that, I point to my own mistakes. Something like the picture on the top of this post. Few month ago I put whiteboard into our home kitchen. We use it as drawing board, as shopping list, as design board for next game we will program and sometimes I write citations. I guess, now till end of my days, I will spell “intelligence” correctly. Not always I was so cool about my mistakes. Few years ago I would feel ashamed and embarrassed, would try to hide it, put a lot of energy to deny it. Today I share it with the world. I know who I am and spelling mistake will not make me less me. I better put my energy to think why did I spell it wrong? Am I writing too less on an analog information carriers? Do I assume that software will catch all my spelling mistakes?

Since this month we have new colleague Dani. One thing what he did, he created channel in our company slack #todayilearned to share our learnings. It has became simple but effective training for me to identify what did I learn new today. Sometimes it is simple stuff, like, how to spell “intelligence” or that I am afraid to sit in the car which moves faster than 210kmh on busy autobahn, or that people who smell lavender fragrance make less typos and are more productive (I sent this fact immediately to my colleague with whom I used to share an office and passion to lavender). Or sometimes it is realisation that not everyone reads and spends on learning about a software as much as I do. I moved away from digital transition because I was sick of explaining software development basics again and again. Now I explain them on weekly bases :D . I like to think that I can assume correctly about previous software development experiences of my respondent and explain missing parts accordingly his/her level of understanding. And almost every second time I fail, because of aiming too high. People try to write an essay without knowing the alphabet! Yes, even in 2018 you have to explain, with patience and empathy, what is a smoke test, what is a negative test and regression test to a developer with 10 years of experience in software development. And this is OK. We all make mistakes, take wrong decisions and can use it as learning possibilities.

 

 

State Of Testing 2018

This is a time of year when “PractiTest” and “TeaTime with Testers” invites all the testers to fill a survey to find out who we are, where we come from and on what kind of subjects we are working on. This is 5th year in a row and I am already looking forward to the picture we will get this time.

Big thank goes to contributors in the review team: Jerry Weinberg, Derk-Jan de Grood, Maria Kedemo, Helena Jeret, Alan Page, Brent Jensen, Eran Kinsbruner, Bas Dijkstra, Erik Proegler, Kristel Krustuuk, Gerie Owen, and Nermin Caluk. If you have any suggestions how to improve it, you are invited to join the review team.

The organisers estimate that the survey will take only 10minutes of your time. For me, it took more time. Why? In this year’s survey, there are few questions where you have to think and/or recall what did you learn last year. Hier are few questions for you to get a feeling:

Have you attended any conferences or training sessions in the past 3 years?
Have you started using any new tools to support your testing (Exploratory testing or in general) in the last year?
Have you made any important changes in the way you are testing during the last year?  

 

Those are few good questions, right? Be part of it! You can find the survey here.

Dictum – Factum

I am the doer. I see a problem/aim/thing I want and I go for it. If I have obstacles, I will put my mind around it, I will make compromise, but I will get a results.

I have put my finger on several key processes along my employee career and for a looong time I thought that I do not need to label my ideas and/or results as mine. Mainly because I believe in following two things:

  • an idea is more important as human who brought it to the life. If my idea/work lives and developes without me, than that was really necessary for the world and not just for my ego.
  • everyone who works together with me, knows what I am capable of and which parts of work was delivered by me.

Mostly it worked well. Everyone in the company knew QA=Kristine, even if I was not part of the project. If people needed help with testing or quality related issue, they were looking for me and I helpe as best as I could. I am also very good in puzzles – from small information bits I like to create big picture – that comes handy if you work on big projects or big companies where people do not know each other. Than one day I organised feedback workshop with my old team. We had small, but cool team and I thought it could be perfect to exercise on self-introduction and feedback giving the same time.

Nice and easy, right? To my surprise I got one negative (and 4 positive) feedback about my introduction! I was so surprised. I shaped my introduction to people with whom I work together, I was assuming that they all know who I am, what are my topics and how I am working. In this case I could excuse myself with the fact that the person, who gave that negative feedback, was working remotely. But frankly it shocked me that even people on my team can misunderstand me so greatly.

I started to rethink it all and to pay attention what is my message, what do I say. Besides other things, I noticed that in most of the cases I use “we”. One example – since almost two years I organise TestParadies – a meet-up for testers and QAs. Alone. I have no team, no sponsors, all the fees I am paying from my own pocket. Year ago I was lucky to get Petra on team to write retrospective blog posts about the meet-ups, but generally I do the whole thing alone – looking for speakers, looking for locations, maintaining platforms, writing emails, moderate discussions, deciding on topics. And still when I talk about TestParadies I say “we did…”, ” we plan…” no matter that there is no “we”. An outsider could think that I am ashamed of running a meet-up! Why I do not take the credit for my work?

Why and How Testers Should Act Like Marketeers” was talk by Rosie Sherry on European Testing Conference 2017. I was not lucky to attend it, but found her slides on slideshare. Many good ideas there! Marketing and selling testing seems not to be those things testers are familiar with. Currently I am trying to shape my blog as my portfolio and I struggle on first page – how to design it that the message is clear? I decided to visit blogs/websites of test people who do consulting to collect some of ideas. Almost everyone I checked had a personal bio, but I was very surprised to found just a few business oriented introductions. 

Some time ago I was working together with a developer on contract. He was working 3 days/week on the project and 2 days/week managing his company. At the beginning I thought that it is only an excuse, he is working on some other project and does not want to admit it. Now I see it from different angle and believe that being great developer or tester is not enough. I expand that old Latin saying to:

Dictum – Factum – Signum – Explicatum

Find Courage – A #TestBash Story

tb_utrecht

On January I was on a trip to the Netherlands. I had an honour to support Rosie and Huib – people, who made another incredible Test Bash event.

I had much, much fun to run registration both days. I love to see new faces, to see the expectations in their eyes, I love to be the first one who meets, greets and guides them into TestBash world. I am kind of staying in the gates to the new knowledge and encouraging people to come forward. I met a lot of new people, had very interesting discussions and good laugh. But let’s start from the beginning.

Meet-Ups

In good old TestBash tradition there were a pre-TB event and pre-pre-TB event, a game night!

If you do not know what is TestBash meetup, then imagine crazy loud tester gatherings in some local bar, where over a drink you have a chance to have a word with a speaker or another cool testing personality. Sooner or later you will realise that all TestBash talks are keynotes and all testers who attend TestBashes are really cool testing personalities. Even yourself! Another very cool thing about TestBash meet-up is, that if you are in the area and can not make to attend the conference, you still have a chance to meet the test people.

Workshop day

Huib picked some very good workshops for the first TestBash Utrecht conference. I heard only good or excellent references.

After registration was done (and it took some time…) I participate in the afternoon workshop about exploratory testing by Jean-Paul. As a person, I am quite impulsive, but since I live in Germany and work as a tester, I work really hard to make me more organised to not to fall out too much. That is why I was expecting to get some practical tools how to do my exploratory testing. And I got them. Thank you, Jean-Paul!

Besides that, Jean-Paul gave me permission to think. This was so unusual, I am too much used to deliver, that I forget how it is to take a time and think. Explore slowly, for example, the room where you are sitting. In fact, everything in the workshop was a little bit like Zen. We tested applications, wrote test cases, documented our findings and let them go. No one wanted to know what exactly we found, what we thought. Very confusing and in the same time healing, because the process was the thing, not the result. Inspired by all that, in February I run my very first exploratory testing mini workshop.

img_20170126_180336

The day ended up with setting registration area and desks with swag. We learned from mistakes and rearranged place that people move faster to the rooms and do not stay in cold. It worked out good and in the next day there was no jam.

The conference day

My day started after 5 am. Very first thing was to move the car. Then I headed to the old church – TestBash Utrecht location. Punctuality is not my thing, that is why for important stuff I work hard to break my habits. As the result I was the very first one, the church was locked, no lights to see, freezing cold. Ha ha, next time I will take it easier on myself.

The conference started with Alans talk about misuse and fun, which unfortunately I did not hear it in Utrecht because people were coming in late for registration. Luckily my boss got for us Dojo access, talks are now uploaded and available for watching. Jipī!

The second highlight of the conference for me was Gitte talk about courage to be yourself. I met Gitte shortly during ATD and she heard pieces of my trust talk, we share similar values and some of experiences as well. I was thrilled to hear her talk. I can imagine that some felt uncomfortable and some could think that it is not a proper talk in tech conference. But it is proper and it is important! It is the blessing that we have people among us, who dare to remind us – we are humans, we are different and it is OK.

All other speakers were amazing too, but I will highlight only one more – Mary. Her talk about “Just enough security” had huge amount of information and I will rewatch it on Dojo to make some notes. Mary, you gave me the push to participate in #30daysofsecuritytesting. Thank you!

I like to talk to speakers after their presentations and take photos of them. The atmosphere of sharing is amazing!

I also like to take group photo of all lady speakers to show role models and inspire more women submit their stories, but in Utrecht they were too many to organise in one photo. Good job, Huib!

99 sec talks

Another tradition of TestBash is 99sec talks. Never participate? You should! That was first stage experience for several presenters, me including. The idea is to give a 99 seconds long (short) talk about testing related subject. As I first stand on the TestBash Brighton stage, I was surprised that the lights are not so bright as they seem to be and I could see all attendees. Before that, in my imagination, I thought it will be like a crowd of wolfs starring on me from the darkness. But instead of that I saw bunch of friendly faces, some carefully listening, other checking or typing something in their digital devices.

Utrecht

Usually, I do not have a lot of time to see a place where a conference is happening. This time I came by car and had no time pressure for leaving.

At the end…

In few days TestBash Brighton will start. If you are going – I wish you joyful learning journey! If you just got to know about TestBashes – I guess there are still some tickets left – invest in your future, you can afford it yourself, if your boss does not see value in sending you to the conference. I fund most of my activities myself and look where it brought me!

Becoming Mentally Strong

Last week was emotionally hard for me. I had a strong disagreement with a person, who’s opinion means a lot to me. It seemed that there is no way out and it made me ill. I hade a feeling I am losing a very dear friend over stupidity. Except that it was not stupidity, but very important part of my believe.

What to do?

As always I asked the question: why? Why it is so important to me and why am I feeling sick? And as always those questions lead to the past. I remembered my personal struggle many years ago, several very unpleasant situations and my actions, who lead me to be a person, who I am today. I had very emotional moments and decided to open up to my friend – introduce the elephant in the room, explain myself and ask for work around.

It looks like that it worked.

When relief and joy came down, I realised what happened. Some kind of summary line between then and now, things I have learned and the self-building journey I have made. I learned a lesson, paid the price and moved on. OK, it was a little bit different: stopped to blame circumstances (because it did not help), understood which exactly lesson I had to learn to be able to move on, learned it, stopped paying the price, which I paid during avoiding to understand the lesson and moved on.

It is good, time to time open up, show the scars and person behind them.

 

My First Exploratory Testing Workshop

screen-shot-2017-02-07-at-22-59-08

Today I did something fun!

Already some time my colleagues &co were asking about an exploratory testing workshop. I did not say yes or no. I wanted to do it, but did not have clear idea how?

Then I went to TestBash Utrecht and had a chance to take a part in Jean-Paul‘s exploratory workshop. That was mind blowing!!! There is generally this thing about TestBash workshops – they accelerate my skills and boom my motivation. In this one Jean-Paul literally several times said that I have no idea how to explore. Important was that when he said it, it was not like shaming but like exposing one of my unknown unknowns and that’s up to me what I will do with it. Plus, in case I wanted to do something about it, he gave practical tools for it. LOVE IT!

So today, thanks to Jean-Paul, I gave my very first mini exploratory testing workshop. My task was easier, because I work together with my workshop team, and harder, because I realised, it is part of the workshop to expose unknown unknowns.

It turned out to work out very well. We had AHA moments, fun and bonding.

Outline for our 45m workshop:

  • exploring surrounding
  • exploring software with 7 Questions by Jean-Paul at EuroSTAR Conference. Those slides were not a part of workshop in TB NL, but because of limited time and to support the idea I wanted to transfer in my workshop, found them very fitting.
  • re-exploring software with SFDPO

And we ended with de-briefing strategy: PROOF (stands for Past, Results, Obstacles, Outlook, Feelings)

P.S. if you can, go and take a workshop by Jean-Paul. I recommend it. And do not forget to tell me afterwards how did you liked it.

#30DaysOfSecurityTesting – Task X

screen-shot-2017-02-04-at-11-14-00

All previous posts in this series: I, II, XXX

The task for today: Read and Learn about Ethical hacking

My way to learn about the topic was to read the story how Troy Hunt started his career in web security and how he became a content creator for ethical hacking certifications. After reading the story you may want to browse other articles written by him.

Another great thing (even I do not agree to everything, it is still very good) created by Troy: Internet Security Basics for those, not so much into security.

Testing Guidelines For Junior Tester

This is a very short visual guide for a junior tester.

screen-shot-2017-01-21-at-09-54-08

Do exploratory testing. That means: be curious, attentive and organized.

come1   come2

Try mindmaps to get the testing ideas and cheatsheets to try different inputs and watch carefully for side effects.

screen-shot-2017-01-21-at-09-44-25

Trust your intuition, see what others do not see and make it visible. How? Use different personas, ask strange questions, like: “can this application kill a person”, and read stories how others test.

screen-shot-2017-01-21-at-09-53-16

Report findings properly, describe the beauty harm in simple reproducible steps and do not forget to mention, why it is important to fix the bug in next iteration. I think it is bad style to write in bug report something like this: “unless you remove the “border=0” attribute“. Show respect = get respect.

 

Enjoy the video, which inspired me to write the guidelines: