How to Insult a Tester

This post is about things that happened recently, flavored with a bit of attitude of both not believing what people say to others and laughing at how common these issues are. Put your dry humor glasses on as you read on...

There was a meeting to discuss testing with the tester, tester's personnel manager and tester's project manager. The meeting all in all was productive and took place in good spirit. Yet, it was an exemplary case of How to Insult a Tester.

Idea 1: Blame the tester for missing bugs that caused trouble in production regardless of knowing 1/3 of recommended testing was done

The meeting started off with a discussion about production problems a week before that were humiliating and should have been found. We all agree that they should have been found. But we don't agree on why they were not. As the tester, I think they were not found because they were not tested as there was not time to test those things. They were on the list of things to test, the list that none in the team can help with because they need to do other work.

Idea 2: Explain that you want Monkey testing

The project manager suggests that he would like to get more of "shallow testing" all around the product to find all the problems and that the problem is that what happens is "too in-depth". He would like tester to find all the problems in shorter time. What would be the style of testing needed is some hours on every area of the product, in a case where every area is so big to test that it would need a lot of time. Project manager continues by explaining that he wants more of monkey testing, just clicking around AND that would bring out all the bugs in a shorter time frame.

Idea 3: Explain testing belongs with the tester but developers can't help because other stuff is "more important"

The discussion continues with the 10:1 ratio of developers and tester, non-existing test automation and huge amount of features that could break with system level changes, like ones seen as problems last week. As a particular example, raising the point that testing efforts planned in the common planning have been 3 times the effort of skilled testers available, and that as a team we don't react to testing not getting done due to lack of resources. End of this: developers have so important features that just must be developed, that there is really no other choice but to get all the testing done by the tester. To soften this a little, suggestion is to try and get permission to hire/contract a second tester, but with reservation that most likely that will not be possible because "product management promised they can do monkey testing themselves". End this with "you can't work on the more important stuff coders work on, because you need to test". That end bit was from a previous discussion though, not this one.

SUM THIS UP
Dear project manager, please: 

Stop blaming the tester for the bugs in production, if you refuse to invest in the testing needed to find the bugs - in particular, since the bugs would not be there if we did not create changes so hastily under stress.  I did not put the bugs in. I did not help removing them either, this time. But I did help remove quite a bunch of other bugs with the choice of how to use time you did not question beforehand, even though you were asked to.

Stop calling the work with complex results of all the relevant bugs Monkey testing. That is insulting and does not make anyone more interested in delivering the results you actually look for.

Learn to think about delivery as a whole team effort instead of working to isolate really collaborative developers and testers into separate silos with the idea of efficiency that just does not work. Let us share the work and let us take in less so that we can actually run the task through. 
 

Follow through - it just might pay off

I was reminded on a lesson I've learned earlier in my testing by something that happened today.

Towards the end of the working day, I noticed a bug report being just now marked resolved. With my new found powers (I control the builds for myself, finally!) I was keen to test the fix right away. I checked the comments to find out that no fix had been made. Instead, there was a comment telling that this is related to a behavior in the program we plan on fixing later, and actually is exactly the same problem.

I talked briefly with the project manager, who knows the product in nice detail, and he almost convinced me that the symptoms I had reported could be related to that. I asked quite many question to clarify how the feature should work if this was indeed the explanation to what I was experiencing. Joking over the low wall of my cubicle, I told him that he must know I will not take his word for it, but I will need to see it by testing it. I felt that was probably a thing for me to experience. And perhaps I could notice something else while checking that - it has been a while since I've looked at that particular scenario.

I decided on the minimum test that I would need to do to find out if it works as specified for now even if it doesn't work as we'd like it to work in the long run. And, also a little to my surprise, I learned that while they had been looking at component A, the problems causing the symptoms were likely to be in component B and the problem was real. I was able to add better isolated steps and explanation to the issue.

What this little piece reminded me is:

Follow through the stuff, even in cases where the explanation sounds plausible, theory is just not the same as trying things first hand.

The style of discussion with the project manager was also very positive. He never suggested I might be wasting my time. We both smiled and joked about it, both before and after. And we felt a common sense of accomplishment now that we understand that just a little better and know where to dig in to find the thing we need to fix. 

Do you really think finding YOUR bugs is fun?!?

As a tester, I provide a service. As a person, I provide this service because I enjoy it - often very much. There's a but - it seems some developers have the ability to take all joy out of testing work. I had an experience like that today.

I reported an issue on a feature we had just been working on, that had a similar consistency within product issue fixed since last week. The fix moved the problem elsewhere, and I thought to be helpful, and let the developer know of the problem.

The first issue had been raised by the team's architect and the developer gave up under pressure on his idea that while for the rest of the product we aim for polished and finished experience, on his first feature on this product / technology we would not.

The reaction to the issue I raised probably got all the steam that had been building under the hood, and the response was much stronger: fixing this would be a waste of his time. I explained, that if we, as the team, indeed think that this type of an issue is waste of time, I'm happy to not report issues like that. But as far as my experience with the product, we have had the habit of fixing these issues and I'm happy to change that practice, but the rules should be for the product - at least similar features within the product. He agreed on a compromise from his point of view: if our GUI designer thought it should be fixed, he'd fix it. He would prefer waiting to see if real users see that as a problem, implying that what ever I did was something a user he can think of and cares of would not do.

An hour later, the GUI designer had taken a look at the problem, and said it should be fixed. So I suppose it will.

There's testing that is fun - creative, intellectually challenging and that makes me feel useful. Fighting about information that isn't wanted isn't exactly fun. Finding same problem step after step in the effort of fixing a problem instead of the mentioned symptom isn't exactly fun. One skill that I feel I've built over the years is to try to find the fun way of doing the things where developers see no fun - much of the absolutely necessary testing falls into that category.

I remember many testing courses and conferences, where I've been educated (and educating) on how to be considerate towards the developers. How to report bugs in a non-judgemental way, how to discuss things face to face rather than resorting to passing messages through the bug tracking system. Today I'm wondering about the extent that kind of skills are taught to developers. I'm trying to provide a service, but my service usually does not include accepting insults, belittling or swearing. I find it amazing that there still are people who might think that this would be acceptable behavior. Luckily, my two examples are both older. I can put my faith into the future generations of developers, who treat colleagues in teams with respect, right?

Another lesson I'd love to see more of my developer team mates catching is that while comparing an hour of end user time and team time, we may actually see more value for the end user time if it is not used on serving our needs. The end user might actually be able to do his job - like selling our product - if he wasn't always busy letting us know that he could not really do what he was trying to do. And seriously, users are not necessary happy even if they don't complain. Workarounds allow them to do what they tried, but is that really what we wanted to offer, a workaround to get the thing done that we were trying to implement for real?  Who wants to drive their software development with the idea of "let's just react to problems when users see them"? I hope that too is a thing of the past.

Make presentation selection difficult for EuroSTAR 2014

I had the pleasure of joining Michael Bolton, Bart Broekman, Alan Richardson and Rikard Edgren in EuroSTAR program committee last year. I did not realize I was the only woman in that group - as gender has never been an issue to me - before we discussed gender as part of the criteria to fill in the keynote slots. That discussion was quite painful for me, as it left me in months of questioning (I never asked!) whether I was chosen to program committee on merit (which I know I have and shouldn't question) or by gender. I made a commitment to myself never want to experience that again, but with help of three amazing women I managed to put that idea past me: Ru Cindrea helped me focus my energy on the positive, Fiona Charles helped me see that outspoken criteria might not be the most relevant in changing state of affairs and Alexandra Casapu put the whole thing past me sharing that while I needed to suspect my gender as selection criteria, she had been told so on occasions.

I strongly believe people should be speaking conferences because of their merits, not because they are the appropriate gender. If you have a good story and you can deliver it well, if it teaches the listeners something that they need and want to hear, it should be on the slots. To create a conference with great presentations, you need a variety to choose from. You need a bit of healthy competition, striving to make your story relevant in contents and wrapping, and that's what the call for presentations tends to be about.

We made a commitment in EuroSTAR 2013 with Rikard Edgen, that both of us would strive to make the selection of the best paper award challenging for program committee of 2014. Nothing to spice things up like a positive sense of competition - where we can help each other to make the selection hard as both would be polished and relevant. So I better get on with my work on the talk and then the paper to be on the competition.

So, please take this as an invitation to join me in making the work of the program committee 2014 hard. When there's too many great talks suggested, it takes more to build the program. But it also creates a conference that takes us forward. I would hope to see a mix of consultants and non-consultants. But in particular, I'd like to see that gender is not raised as a criteria with the abundance of both genders in the proposals. For that, I'd hope there will be many and again many women submitting - just as there should be many and again many men submitting. There's equality in testing, let that be visible in the submissions.

If I can help you with your proposal, let me know. I'd be happy to. The testing field needs its newcomers and its seasoned speakers alike to bring in new and relevant contents. I've had the privilege of introducing dozens of new speakers in Finland, stemming from private discussions with just a little of encouragement to share the great stories. We all have what it takes. Let's just share, in call of presentations, what we're into sharing right now. The good stuff needs to be out in the open. 

When bugs feel too simple

I've spent today testing a feature reading its specification. I let the specification reading bring ideas into my head, and follow them - with the result of logging quite many bugs.

One bug in particular was a tipping point today on how I feel about my usefulness.

I was reading the specification mentioning copy feature, to realize that I've tried the feature but I have not really owned the data I'm copying, that is, intentionally creating it to be something that I would find relevant for this copy action. So I created the maximum data (filling in all the fields) with data that I could recognize (naming everything so that they tell about their location) and hit the copy button.

With some more tests, I could pinpoint the piece of data that was causing the problem, and the problem is not about the contents of the data I entered, just about me filling anything in to a particular field.

With  this bug, I could not help but to feel frustrated. A very simple way to see if a feature works is to use it. And if you will use it, why not use it with full data?

This example is from a team with me and six developers. I'm a part timer on the product, developers are full timers. And yet we, continuously, over and over again, regardless of all the discussions about developer testing end up with this: evidence of not having used the feature.

I went digging into the bugs I've logged in the last few weeks, and came to a very depressing conclusion. None of the bugs I've found required any more sophistication than this one. All it takes is a little time with the product.

Need to start doing something about this. Again and more. This is not a skills issue. This is an attitude issue. Developers can test this. For a reason I don't really get out of my team in discussions, their testing for these issues just does not happen often enough.

Where did 2013 go?

Reading other people's reflections of the year 2013, I came to realize I've had an amazing year.  There's two things that characterize the year in particular: learning as a tester and active organizing of events. If there's a downside, it must be that I've had a lot less chances of preparing presentations to share my own stuff but that's an easy fix for next year.

A Full Year at the Office

I changed jobs in April 2012, so this was my first year at this job that I could spend the full year on. I've loved the challenges that hands-on testing work presents me, enjoyed the freedom of learning bits of Selenium to get my teams started on that path and the varied work that I can choose from from helping business model development, defining our products to making sure they are actually what we thought they should be through testing them.

There's one feature area in particular that I absolutely loved testing this year. Learning that a migration feature works as specified and then finding out why specified is by no means good enough and driving the feature to actually useful piece of software was enjoyable and a great collaboration.

It's also been a full year with the amazing Alexandra Casapu (@coveredincloth) and guiding her on her tour to learn more of testing. Stopping to think about our different approaches teaches me a lot about how to use my strength, and encourages me to develop some of the weaknesses I had almost accepted - the automation avoidance in particular. Our collaboration has also given me plenty of things to write and talk about.

I'm more convinced than ever that I love long-term assignments for the depth of applying and developing skills. And I'm pretty sure I will not, no matter what I said when joining, be changing jobs after two years.  But I will continue on the path to enable Alexandra to work as full team member, regardless of her remote status and our insistence on not being comfortable with English in general.  

I also love the fact that in this work, I'm judged and thanked for the effort with the same criteria as the rest of us. No more "are you THAT Maaret Pyhäjärvi..." but actually being allowed to be just one of the team members. There's a downside to ten years of presentations, teaching and sharing what ever I can on testing with the local testing community.

Laying the Groundwork for the Year

For this year, I decided to focus my volunteering effort into whole-team view for software, as a tester still. The motivation that I hold for this is that there seems to still be the idea around that Agile teams don't often know what to do with good testers like myself, and testers developing their craft in isolation isn't really helping this. And, the fact that I've been helping the Finnish testing community for over ten years also begged to try out what happens when I leave for other volunteer work. I learned it means that discussions survive, but most of the other action completely vanished. 

Not Only Finland

I wanted to work on stuff that is not only in Finland and for Finland. The relatively regular tweeting makes me feel more connected, and I've managed to write to my blog in English mostly this year - even though Finnish is still my daily working language. I also had the privilege to be invited to EuroSTAR program committee and enjoyed the process of selecting the best possible content in Europe for the biggest and greatest testing conference. The only thing I was disappointed in that it wasn't more work so I took upon myself the work of getting to know many first timers at the conference site. Testing has so many amazing people and brilliant minds. 

I was also invited to speak at a conference organized by Agile Latvia -colleagues.  My presentation was titled "Serendipity and Perseverance - Injecting Testing in a Test Resistant Team". Wildcard conference was a lot of fun and my first of three chances this year to have long face to face discussions with Laurent Bossavit. I loved his book on Leprechauns of Software Engineering which made me more aware of what I want to quote in my presentations and let loose as things people refer to.

Organizing here and there

I run through  the organizing of Helsinki Testing Days that happened in June. With a few tracks and a massive test lab, the free event with about 400 people was a great experience. I did not speak there, as I felt that I should give room to others, and we had some really exciting new speakers for this audience. And my friend Ru Cindrea, Romania's gift to Finnish Testing community, did a great job with the test lab with a bunch of volunteers. 

I set out to organize a series of webinars. I run a couple of them, presenting one myself with title "Experiences with Remote Testing", trying out the GoToWebinar -platform. I also participated quite a bunch of webinars with nice contents, and realized that there's enough of that sort to my taste, and that a webinar is never even remotely the same as a live session. 

Then I joined the board of Agile Finland and took some things to organize from there. I organized a monthly breakfast series for various topics in Agile (no testing yet!) and Tampere Goes Agile -conference. With TGA, I learned that running a free 400 person testing conference is easier than running one for Agile at Tampere, from financing perspective. A non-profit without any money (FAST) has many benefits over a non-profit with some money (Agile Finland). And my connections to Tampere and Agile are not quite in the shape my connections in Helsinki and Testing.

I also made a commitment to developers to get something started with coding dojos and retreats. I did, bringing Adi Bolboaca to discuss this with us and build some energy, to work with my team at Granlund (to be "the one positive thing that happened this year" according to a team mate of mine) and convinced my brother to run a code retreat at Tampere Goes Agile. Happy developers result in better quality and more fun for testing, so that was a good choice. 

Since I had times of not enough things to do for my taste, I also did some work on agile.fi wordpress setup for Agile Finland. 

Absolutely best part in organizing was again doing something I had avoided for no particular reason. I learned to love Github and did my share of bugs for the web page I had to maintain for TGA.

Testing Stuff Re-emerges

While I thought I wouldn't do much for the testing community, seems there were a few things after all:

• Helsinki Testing Days main organizer
• Helsinki Agile Testing meetup group sessions: evening with James Bach and evening with Alexandra Casapu, as I can't let the great visitors pass by without contributing 
• Presentations for Jyväskylä on Testing themes, with "Five things of (agile) testing for all of us" and "Does testing give us quality?" while I was visiting anyway  
• Couple of testing dojos to practice together and see how other testers work with their test targets

Training too

I did a lot less training and presentations than on a usual year. Still my year fit a couple of 2 day trainings on Test Automation in Jyväskylä. And a couple of tailored for customer courses, a one-day session on "Acceptance Testing" and a two-day session on "Testing and Test Cases". Talentum gave me two changes to speak in their conferences, first a talk "Testing in a team that isn't colocated" and then "Buying testing services as a customer". I was also invited to an organization to share my experiences on with title "Specification by Example: Experiences on Getting Started".  Compared to previous years, I took it easy on this side and will definitely do more of this next year, with BBST around the corner as co-instructor with Cem Kaner.

Family and personal goals

With all of this, I spent weekends with my two kids, not doing much expect hanging out and playing. And I found time to start exercising (dance!), collect my willpower and lose 28 kilos on the side.

My family, in particular my mom is just amazing. And I have a great group of people around me that help make things real. I've been lucky. Here's hoping the good stuff continues for 2014 and allows me to try more things I love doing.

Happy new year all!

End of Year at Work

I spend the last working day at the office analyzing what we have accomplished in a year. I'm a tester, not never just a tester. I like to know what happens around me.

For one team, I learned that we delivered 11 versions, 30 features worth mentioning over those versions. Some of the 30 features were delivered incrementally, but looking at them now, mentioning them many times for the year just isn't the thing to do. The 30 features included about 200 Jira issues related to business value to deliver in increments. I also was reminded, that out of these features there is one that has not been tested by the professional testers, but by the developer with help of some users - not "system tested" would be the term we use. I could not help but feeling satisfied, especially after looking at all the changes we've done on how we work together as a team.

As usual, there's a but... I spend my time with two teams, and the other one isn't quite where I would hope us to be. I actually cannot count how many features worth mentioning there are since the bookkeeping isn't quite up to par - that would be a significant work effort to analyze. But I can count bugs, although I shouldn't.

I'm sharing a management summary of some percentages here.



The first team isn't perfect, but at least its fun to work with. The second team depresses me, as I seem to continuously fail at helping people see that testing by the customers can be a risk they don't intend to take and that there are problems to find that are not found if testing does not happen.

I don't care who tests, but it should be someone who sees a problem when it waves at you. Seems my developers, in both teams,  are still on the way to learn how to surface and recognize problems. Well, something to do in the 2014 still as I don't give up.