Tuesday, December 31, 2013

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.







Sunday, December 22, 2013

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.


Monday, December 16, 2013

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. 


Friday, November 15, 2013

Unknown unknowns from another perspective - numbers and tacit knowledge


At EuroSTAR Alexandra Casapu talked about "Fooled by the Unknown Unknowns". Thinking through her story, I still think that her approach to turning her stumblings in a project into a success story, which it truly is,  shows the same remarkable characters she has exhibited as tester growing into excellence.

When I suggested that she would use her first "own" feature as a story, I did not have yet in mind what kind of a story that would make. Thus looking at the story from another angle seemed like a fun exercise.

The numbers

I collected some data points about the effort:

My first ideas in collecting this is that the story is not about a project. It's about a testing assignment within a project. It's about an assignment that did not, even at the most focused times get the full attention of the tester, as even January turns out to be just a third of the hours in that month.

The assignment is about coping with many things at once, and taking responsibility of how much time you need as a tester. This was the first assignment, where the priority of the task was such that more time could have been taken - and was, right after the feedback. The assignment is also about importance of not delaying feedback, as the decisions on going forward with the customer were pressing at the end of January.

The data points also remind me, that this is very typical in how things happen: from decision to start to customers actually starting may take quite a while. I would not be surprised that as the budgeting cycle is now at hand, we'd only now see the issues we've missed. And that we missed, in numbers, quite a significant amount of things the customers did pay attention to, and the bugs that were put on wishlist did not come back from the customers. We differentiate between bugs and change requests, where with change requests we may claim we could not have the info available, except that my other project keeps showing that surprisingly a tester may have info available about needs that are not specified anywhere. Thus I think some of those were also escapes from us.

I'm also reminded that the external push to start questioning what you actually know may not need to be that big of an effort. In this case, it was less than a working day of discussing documentation and playing with the software. And with that, the change in numbers by the original tester was already significant.

Looking at this and thinking about what happened, I think the time it takes for things to sink in also plays a relevant factor. The later bugs found by the tester were not about new problems introduced, but about new learning introduced to the tester to pay attention to the right kinds of aspects. Every round this testing seems to be getting better.

Tacit knowledge?

The talk also left me thinking about role of tacit knowledge. A point a lot of people picked up and commented on was the tester's remoteness, and being deprived of communications with the business & developers. An example of tacit knowledge that could have helped her would be that she would have seen me test something similar. Then again, I wasn't testing the same / similar, I was on completely different areas.

Looking at what was missed, there's clearly a piece of tacit knowledge that was not put forward in the discussions - in addition to the info that was told but that did not sink in as usually happens with information you have no context for yet. No one needed to tell me that this customer, who we talked about by name, is important. It's a customer with some reputation in Finland, so knowing the importance is knowledge of the local culture. In hindsight, I did not even think that providing more context on the customer than what the product data reveals could have been useful.

It will be interesting to look more deeply into tacit knowledge in the research we're starting at work. Or rather, the subjects of which we start to become at work. I still think that a lot of the issues we were facing are basic lessons new testers need to learn, and can't learn from books or courses. Thinking is multiple dimensions, using all sources in a proper series of actions so that they enable you to learn more and don't close out options. And getting feedback on how you do in real projects is really valuable. All a junior needs is a little push to become a lot better.

Every day we learn, every day makes us a little better. I love the playful competition in us learning side by side, that keeps challenging me after all these years.