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.

I shouldn't be a tester - I was tested

I did a course with a company this week, and as part of the course we discussed the different people there are in testing, and how different skills, interests and personalities are important. This brought back a memory I feel I should share more widely.

About 1,5 years ago I had decided I need to change jobs to a tester job for personal happiness - to see if I still can do it after years of test management, and in particular to learn more on the types of things you miss if you are not hands on in the actual testing work.  Looking for a job, there were a few opportunities available. Plenty of jobs in consulting it seemed then, and a few really interesting ones in product development - interesting for me, that is. There were two I seriously considered, the one I'm holding now being the other one. The other job was in financial sector in a bit larger company. My main concern of not wanting to join at that point was that as I was moving away from financial/insurance sector job that did not allow time for hands-on testing, the same risk would remain with a larger company, so having  the choice, I chose smaller and a product I believe in.

For the larger organization, I went to be tested as part of the recruitment process. That's something I've managed to avoid for all of my testing career since 1995, as I've slipped into jobs without needing to do that, for no particular reason. But this time I went to tests that would try to analyze my style of collaboration, my personality and my skills in mathematics, all in less than a day.

I enjoyed the experience of being tested. The group exercises in particular were a lot of fun. Towards the end of the testing day we all got a scheduled 10 minute appointment with the psychologist in charge.

As he looked at my papers, he asked some really brief confirmatory style questions about what he the tests appeared to be showing. And then he told me what we would write in the analysis that my potential employer had contracted for.

I was told that I not the right kind of personality to work as a tester. That testing is the most boring job ever, and that my focus was too short-term so that I would make a bad tester. I pointed out that regardless of my "tested personality", I had been a tester since 1995, with a history of being actually pretty good at that. With the 10 minutes, he however wrote down that I was unlikely to succeed in the job I was already doing. I should go through my papers to find the recommendation as in my eyes, it was just a piece of evidence on how little HR departments recruiting software testers know, if they think that that testing is the most boring work in the world.

The paper would not have stopped me from working at the company that had me analyzed. My choice of smaller team and hands-on work did. Having logged over 2 bugs on average every day of this year, including also the days when I was not working at all on projects where other people fail to see the problems and their locations is proof enough for me that I have what it takes for this job. And working on the same products for 1,5 years and still feeling excited about it isn't exactly a hint of wrong kind of personality either.

At an earlier day of my career, that info could have really brought me down. After 18 years in testing, I just think there's something seriously wrong in recruiting of software testers if it actually relies on these personality tests. Or on software testing certifications.

Open letter to No-Shows at a Free Conference

Dear all prospective conference participants,

In efforts to make things better for the future, I wanted to share you my perspective from something that happened last weekend at Tampere Goes Agile 2013 -conference. A lot of people, about 60 that had enrolled did not show up at the conference. In addition, there were about 20 people who cancelled in advance during the last week, when the per participant cost has been fixed to a level regardless of if you let us know or not.

Picture: these badges were left without their owner (We know who you are)

Some people feel really upset about this. The hard reality is that we payed 41 € / person who we reserved a space for, and with 80 no-shows, there is a sum of 3280 € +VAT 24% that we could have used on other things like beer at the location for those who were there. If we would buy beers that cost 8 € / unit for end users, we missed out on 508 pints of beer, that is over 2 units / person at the conference.

I feel that it is your right as a member of these free-form communities to reserve a spot for you and take that cost to be allocated for you. If you were present at the location, I could see you not just as cost factor, but a factor that brings the community value through your skills improving and you contributing to the learning of others and the overall atmosphere of the conference. The same idea of value is relevant for every participant at the conferences, the organizers build these places to meet up with others to generate value that would not happen if we did not discuss actively and build on each other. 

This year we increased the limit of participants so that everyone from the wait list could get in if they wanted. But letting people know on last week or during the conference day does not work. As agile as we are, we should also remember our responsibility to think a bit in advance on those things where that makes a difference - like reserving a place in a conference where you don't show up. 

In summary, I kindly ask all of you going to conferences, to keep in mind these:

• When you participate actively, you create value that takes our community forward
• When you enroll and don't show up, you become cost that creates no value.
• Critically think about your possibilities to be there over a week in advance, but if you end up sick, don't feel obliged to show up just because you think you promised something

There's been plenty of ideas of how we would do things differently because the badges left behind made the problem visible. We could:

1. Stop making free conferences - all conferences cost something and "only money makes people committed to their enrollments"
2. Charge money that you give back when you retrieve your badge, like a deposit - but work isn't free either
3. Put the no-shows on waitlist for next year when they enroll and confirm their spots only when those without the no-show history have acquired their spots 
4. Hand out twice the amount of places and hope that the no-show rate remains the same, or give the benefit of food & coffee only to N first people on the registration desk, N being the number we officially announced we would have. If lucky, there is no N+1...
5. Use more money on the no-shows so that they create value - give 20 € on their name for a cause that publishes a list of donators, so that they become donators for not showing up. Tell about this in advance.
6. Organize only conferences where presenters get in. They tend to be then more committed to showing up, and make good participants too.  

You could probably come up with other great ideas. Personally, I'm not open for anything that makes you feel any worse than you already should since you missed out a brilliant conference regardless of what was your reason. I believe many of you would have seriously wanted to be there and I hope to get the chance to see you there next time.