Work for free when you could get paid

As I've decided to leave the current employer that I work with to become a consultant again, there's been some talk around the office on how to find someone to replace me.

It's great to hear that the work I've done has been appreciated and that the vast numbers of fixed issues over the 2,5 years as well as the changes in how our teams work are appreciated. I've enjoyed my time here with all the puzzles and challenges, some of which I've blogged about. When I joined, I could build practices as I saw fit, and I saw things from agile development, exploratory testing and automated checking perspective. There was also the experience that all things "testing" are not the same in value: getting a developer to test (calling him tester) resulted as no improvement on product quality and throw-away test automation.

When I was recruited, I found this job by a lucky accident. My employer did not know of the right places to look for good candidates. We still haven't posted an ad for the position, but as I would like to help out, I've mentioned the job in passing at Finnish Association for Software Testing LinkedIn group and had three candidate contacts. We're requiring fluent Finnish, which already rules out two out of three.

As it seems my supervisor has not made much progress on posting the adds, I started looking into other routes to find him candidates. As the job isn't really something you need to be the best in testing in Finland for (modesty in my skills is not one of my traits...), it could also be a great opportunity for someone new with the right attitude for testing.  So I suggested to consider a recruiting program TestPro.

The idea with TestPro is that there's a 7 month period of training and practice with the recruiting companies, after which the companies decide on recruiting the candidate. There's 22 days of classroom training and full days of working at the recruiting company, and during which the candidate is unemployed and gets some social benefits, but isn't officially working as in getting paid for the work. This program is targeted for the unemployed or people under the threat of becoming unemployed, as in case you really are out of options it's a great opportunity to get into testing.

Some hours after suggesting this route to my supervisor, it hit me: I just made an awful mistake. I have two reasons to think I made a mistake:

1. There's a PAID job open right now, and I just postponed that for whoever would get recruited by seven months of slave labor. I should know how to do better.
2. The training the candidate receives is near to worthless from our perspective. It shows aptitude, interest and commitment (7 months of free work...) that you go into it, but the contents you will receive are not ones I would find valuable for the person to recruit. Unless the person is just right, the likelihood of ISTQB Foundation and ISTQB Agile Certificate courses to make them worse is high and they'd be better off in this job without them. The added focus on test automation attracts developers with no clue on how to perform testing with valuable results. 

There's still time to fix the mistake I'm making, I hope. Unless the temptation of "free labor" already turned some managers to the dark side. But I need to find the candidates that want to learn  by doing, take BBST and RST classes during the work hours and become a great tester within the context-driven ideas. I have little time to go look for candidates, but perhaps this blog post encourages the right one to get in touch. Even with the Finnish language skill required.

TestPro (http://www.testpro.fi) might be great, if you look for testers with the stuff they are training. I'm just not convinced they teach very much of the relevant stuff. Not only because I created the first TestPro contents years ago, but also because just few years back I was not welcomed when critiquing TestPro contents on agile testing that had very little resemblance to stuff that agile testing is in my experience. As I was told, I should not have had access to the course material that was shown to me because there was an NDA on not giving the material to non-participants.

If testing was taught more like a driver's licence

With the negative (and founded) feelings I have towards the ISTQB testing certifications, I've been recently trying very hard to focus on real alternatives, not just being against.

This post is again inspired by a tweet: 

@teemuvesala Certificate is like driver's license. It doesn't mean you are competent but it means you can be held accountable for your work.
— Esko Hannula (@eskohannula) August 20, 2014

Somehow, I hope certificate would be like a driver's licence. I also hope that courses leading up to certification (if such are even necessary for testing)  would be taught more like driver's courses.

When I teach exploratory testing, I often talk about experiences I had with driving school as analogy. It's been ages since I did my own and I still remember the nervousness that blocked me from focusing on all the aspects and how they were delivered, but I've had the fortune of following my younger siblings go through the process.

Not many years ago, my sister came back from her first driving lesson in driving school. She told the lesson started on an almost empty parking lot, where she was shown the basics: pedals, gears, steering wheel, mirrors and such, one at a time. She was driving around the parking lot, and all of a sudden the teacher tells to drive out, to the open road and towards the driving school just couple of blocks away. With a lot of focus into actions she is not used to putting together, the end result is her stating to our brother: "can you show me the basics again now that I'm not in panic mode, so that I can actually focus on the actions".

When I teach testing - the actual hands on testing - there's a lot of similarities. There's different actions that you - the tester - need to be able to balance in a way that fits your rhythm of learning. If you need to take a moment to actually read a log and not just rely on an automated tool to make sense of what you're experiencing, it's your right to do so. If you feel that taking notes while you test is difficult, you can structure your work so that you don't try to intertwine things quite so much, but take the time for the notes on regular intervals, focusing on just that. If coming up with test ideas while you test does not come naturally to you, nothing prevents you from taking a session just focused on brainstorming. You're in the driver's seat, in control.

When you start as a new tester and take a course, it's not the vocabulary that you need to make sense of to be useful. It's understanding what kinds of actions need to happen, and how you best fit those into your personality, skills and interests.

If testing on the courses was taught more like a driver's licence, we would be taught the basic actions we need to take from configuring the product to coming up with ideas of what to test, creating useful documentation for personal and team use and recognizing problems when they are right in front of us (and many more). We would be taught to focus on the actions first, and then allowed and encouraged to practice putting the actions together into series of actions.

Many times when I drive a car, I leave home and get where I was going, without a clue of what really happened on the route. After years of practice, the actions have morphed into something I don't pay attention to. But if anything happens on route, I'm surely reacting to it. It's hard to see the things that I had trouble with at early stages: changing gears and turning the wheel simultaneously. The act of testing is very much like that. We control the pace to make the flow perfect - for each tester.

Licence to drive allows you to practice with others. Licence to test that would be worthwhile does not yet exist. But if you look for courses that justify your usefulness as a tester, ISTQB Foundation is the idea furthest from useful. I should know, my name is on the creators of the syllabus and I'm sorry for being part of creating such a monster.

I think BBST (Black Box Software Testing) series - in particular the one Cem Kaner continues developing under Kaner Fiedler Associates Inc - is a real alternative. So is Rapid Software Testing by James Bach and Michael Bolton, and numerous independent trainer's (including myself) contents do a great job at delivering relevant contents. On trainings, more variety is usually better. Some messages sink in after repeating differently. And we just don't need to agree on a one true way to test, as there's so many different places and cases to do testing in. Context matters. Useful results matter.

Making a tester learn coding when not-coding is what I really need

Opening twitter inspired me this morning to write this blog post. Here's the specific inspirational piece:

There is no longer a question of whether testers should learn to write code. Smart, engaged testers are learning and succeeding with code.
— Marlena Compton (@marlenac) August 15, 2014

I feel very divided with this statement. I really agree with "smart, engaged testers are learning and succeeding with code", but I also disagree with it. I have evidence on smart, engaged testers who are learning and succeeding without code, and feel very strongly about not making those people feel inferior.

Here's a story I want to share on a smart, engaged tester succeeding with code. 

I work with a brilliant remote tester from Romania. She joined my projects two years ago with a junior tester title, quickly building and showing testing skills that many seniors can't match in my experience. She pays attention to details, she sees the big picture and is great at taking the product a flow at a time, motivated by the context of use. A lot of her time goes into telling about problems that everyone else (the developers) in her team misses - the information she provides surprises people, continuously. She's purpose-driven, polite and collaborative and drives improvement. And, she has the humility to see that as much as I respect her skills today, I respect her skills more tomorrow as every day is about learning more.

I did not contract her for coding skills. I contracted her for exploratory testing where developers will team up to provide code whenever useful. I soon learned she has a background in mathematics, and is smart to a level I can only admire. I'm still not sure how much of code background she has, as she does not emphasize things she cannot do, but things she can learn. And code would definitely be one of the things she can learn, no doubt about it.

About a year ago, we introduced the first selenium automation scripts into the product she is working on. Selenium stuff was set up as developers effort, and her role in the effort was more focused on helping with the ideas of what flows to automate, leaving the implementation with the developers with (more) coding experience. She introduced ToTest-tags as the team agreed for the ideas, but it turned out that the allocation of time into coding from the developers wasn't sufficient to make progress. As I encouraged her to take time away from the much needed hands-on testing work, she learned some basics of selenium and C# on project hours, she started adding automated checks.

The feedback from developers was quiet and clear. As they refactored the tests, they deleted all that she had created, silently. They did not replace them with ones that were working better, just deleted. Later, with me pushing for answers to understand what is going on, I learned that the code was ugly, it was clear that it wasn't done by a developer, and that the tests were brittle. Brittleness in execution was the main reason for deletion.

At first, I thought it was a better approach to just contribute the ToTest-tags and no code to be deleted. But as I looked at developers not making progress on selenium tests either, I realized something. I could never, as the test manager for this tester, accept the "fact" that she couldn't do the automation. It would be something in my power - our power - to change.

Just some months earlier, the tester needed to start working on a new feature area and I was told it would be a waste of her time as "the project will be over before she understands the area, the decision rules are so complex". We were talking of a person who would have no trouble hand-calculating all the decision rules with her math background, so I setting up for "let's show them how it goes" was a no-brainer. She not only understood the area faster, but also contributed to how the area was developed working well with the product manager, who was very thankful for her existence. Exercising the power of prioritizing into something that would take learning before results was successful.

So, I realized I had not thought the same way about her automation skills. I, as the manager, needed to exercise my power of prioritizing to make room for learning. I don't want her - anyone for that matter - to be the person who is referred to as "can't do it" even though she really wouldn't have time to do it. And of course she can do it, why couldn't she. Because the first minimal trial wasn't a brilliant success, should she give up? Of course not.

So as the summer approached, I suggested to take time for another round and we talked about the first round experiences. There was also an official reason, the no progress on automation work by the developers, but a big part of motivating realizations came from not accepting skills as they are - brilliant without coding. After spending some weeks on this while others were on vacation with support from her Altom colleagues, she came back telling she learned to choose "simpler flows" and focused on reliability of her scripts, comparing to previous rounds results - showing she learned.

There was again some frustration from the team developers with inexperience with version control systems (she wanted to only introduce a couple of scripts while she had added more), but this would all be better if she had more chances to practice continually. And now it seems that the scripts are included, running with the build and being a platform to continue from. The developers examples probably helped to find some aspects of acceptable style, so I would hope they don't end up deleted again. At least they seemed to survive a week of action so far.

Looking at the big picture for the team, I really would need her not doing automation. None of the others in the team see the problems she sees as she uses it. And she sees more, faster, when she isn't focused on automating. But while automating, she also sees problems. She mentioned two in two weeks, whereas her usual pace seems to be more of two in a day. Information-wise, I get a lot less from her as she automates. And the missing part just stays missing and we fix while in production, no one else contributes to that area for now, regardless of the efforts I've tried setting up for that as well.

I wholeheartedly agree with a friend stating "Test automation in general will take the tester's time right now, but will save them time in the future, when they don't have to do everything all over again and can really focus on things that others don't see". With this experience however, we have 10 people who can write the automation, and only one who knows the work the automation is supposed to help completing with results we expect. Simple flows the developers could implement - perhaps in this case again didn't. But they tell me the autumn will be different. 

With the "testers should code" trend, it would be selfish of me not to make her code. I need the other skills she has way more, but others will look down on her if I don't allow the coding time that we don't really need from her. And her being the real "full-stack developer" - the only one in the team for that matter - wouldn't be a bad goal either. For people who learn continuously, it's just about the choice of where to invest your time.

Kids Creating with Computers vs. Coding

  

My son, soon turning 7 years, started on 1st grade in school. It's been a great excuse for me to think about things I haven't thought about so much, both past and future - and my actions.

PAST

Starting from the past, I've looked into how I ended up becoming a software professional with a more specific label of identity: 'tester'. I remember a few core turning points in my childhood.

Chronologically, first one is remembering that our family had a computer (Vic20, Commodore64, Amiga ...) that I absolutely loved. However, it wasn't discussed as family computer, it belonged to my younger brother. Not necessarily because he was more interested, but because he was a boy. I remember asking permission to use it, finding slots of time when it was available, always being the second one to gain access to the computers. The chances of learning stuff on the computer were limited at an early age.

Either my parents were trying to be fair with the access on the computer or my brother was able to share, but I remember having my time on the computer. I learned English on Sierra's games at an early age - I absolutely loved comping up the right words to progress. I bought MikroBitti-magazines with printouts of programs I carefully typed into the program for the Commodore64 and I remember being extremely frustrated with a bug that prevented me from running the software I had "created" - copied really. My early experiences were successes with understanding how (and why) software doesn't work.

I have forgotten about my courses on computers in school, but I remember my first programming course. We could do whatever we wanted, and me and my friend paired up to create a Pascal program that implemented some girly magazine questionnaire "Test if you are popular". I was really proud on the splash screen silly graphics but remember how silly structures I created for the conditionals needed for counting the points in the actual questionnaire.

I was never told I couldn't do something. Then again, I wasn't pushed to do stuff with computers either. And the more I liked computers, the more weird I was. I had my friends - large group of them, I was never lonely - but I was never popular either. My reference group allowed me to like math, physics, chemistry and eventually, computers.

FUTURE

Now that I have kids, I want them to have a chance of learning to create, not just consume, on computers. They've played games at an earlier age and learned to click dialogs to progress without knowing what the text says. Quite different from me working with the English dictionary to play through King's Quest. I see that they are, at a young age, turning into more of consumers of technology than I ever was. Introducing creating is something I need to help with.

Also, my daughter makes me suspect that with the social nature she has, she will not be interested in creating alone. And what still often happens is that when we teach code and computers, we teach it as individual skill. With her friends telling soon enough that something is not cool or girly enough, she is sure to go with the crowd. Thus the future needs changing the crowd.

The future in Finland seems to have Koodi2014-project - first graders starting in two years will get taught programming. Both my kids will be out of the first grade system before that.  Reading the materials created to support the project also upset me with the code-centric attitude. While I think it's great to give kids the chances of experiencing that they can create stuff by coding, I'd also want them to get chances of creating stuff for computers by not coding. The software professionals today and in the future don't all code or don't code all the time. Reading the guidebook for teachers, I get the sense that we're starting to teach not valuing the non-coders contribution: the salespeople, the product managers, the business analysts and domain experts, the graphic designers, and my kind, the testers. I already have to listen to programmers creating unworking software (well, works on THEIR machine in THEIR use case) being better than others because they code, I would rather have the future teach kids collaboration and value of different skills in creating working software.

MY ACTIONS

I decided on my personal actions already in spring. I contacted my son's school's headmaster to suggest that instead of waiting until 5th grade for computer club to start, I volunteer to run one for 1st graders (and 2nd graders next year so that both of my kids get to be in). They welcome the idea, without knowing much of the contents.

I want to focus on creating with computers, in collaboration. I want us to do artwork together, add audio and put things together in very lightweight programming activities. Perhaps create ideas that are not given as "create this by programming" but creating something they could come up with. We'll do some code.org exercises and some testing exercises, also probably a bit of agile practice exercises. I'm sure different participants contribute different aspects with the idea that creating software is social group work where we can build on the others skills and ideas.

So, no "code school" for me. Code shouldn't be placed as the hub of it all. If we are "missing 17000 professionals by 2016" from software, not sharing the work with different people with different interests (other than code) is not going to help us.  I want software skills to be taught more inclusively. Code is included. But a lot of other interests that people may have should be included too.

Pairing to slow down a developer from starting new items

My last two posts have been about small batches and crazy reasons that make small batches take a long calendar time. As usual, I wasn't happy with just saying I don't like how things were, I needed to try something different.

First, I sent an email to the developer and our manager suggesting that I have two ideas of how to slow the developer down after done-without-testing as I felt that taking another task when this one was not yet really done was premature and source of problems. I suggested to:

1. Allow the developer to spend time studying instead of moving to another interesting feature he would not like to come back from. In general, the option of just moving to another task should be less tempting and the realization of getting quickly back to the thing that isn't yet done should remain the priority.
2. Make the developer responsible for the testing task following the development task, with the realization that he will need to invite me to pair up with him to do it well enough for now. 

The option to choose between the two wasn't real. Number 2 was the only real option. Number 1 was to emphasize that we actually were supposed to have a rule on limiting work in progress.

So today, the developer walked up to me first time asking me to test with him. So far I've been the one polling for a proper time and done that way too rarely. We sat down with two computers and two browsers, and started testing.

With all the issues fixed from last round, I asked if he was confident in the feature now. He said he wasn't - because there was always something I would see that he just didn't. We talked about the starting choices of what to do first and why, and he seemed a bit puzzled on my way of thinking - the problem area seemed more condensed to him with less links around the product.

We found problems in the changes he had just made, and we went through how it should work in different scenarios testing it through. He would take a pause from testing, fix things in code and deploy a new version that made things better.

When he seemed to think we were done, I wanted to try a few more things. Just because I just thought they could be connected and I had not tried them yet. We found problems specific to IE9 and how data (unneeded null values) got saved in editing scenarios. We learned that there was a connection to history feature that was forgotten during development and did not work. And that there's a multiple selection feature that this feature wasn't compatible with.

With a few hours of testing, we looked at the problems we now knew and agreed it would take a bit of time to come up with how to deal with them, and alone time might be useful. Before we parted, we still tested the other feature he had been working on that left me waiting on Monday and found no issues. And agreed we'd spend an hour together on each feature he completes from now on, because it's just more efficient and fun.

Need to keep reminding the developers that they can't outsource quality to me. Even if they know I will find problems they miss, that just isn't acceptable approach. Collaboration is good. 

Need for Speed, Motivation is the Key

Based on my previous post on waiting and having business value items in the inventory of unfinished work for a long time due to juggling to other work, a colleague in twitter left me thinking about batch sizes.

He pointed out that with a small batch size, the wait time would be shorter. It's a great observation, but also in my experience, one of the most misunderstood principles in practice.

What is a small batch? I would think that is the smallest possible value you can add, for now, into the software. A batch is not a task. It's not that you've done "design" for something, but you need to go through all the layers to actually have the resulting value in production. Small  batches are the heart of incremental development and delivery, and from a perspective of testing, I would claim I've been getting better to help my teams find the smallest possible things we could add.

The challenges with small batches tend to come with the tasks some people refuse to acknowledge. Like testing. If there's a really small change, adding six lines of code, it shouldn't take long to get that tested, right? Unfortunately, quite often the view into the system as delivering value connected with all kinds of things means that the very small change isn't a small one to test. And in particular, it isn't a small one to fix, as one (or more) of the connections were completely dismissed in the implementation. There's a very relevant, common use case that just wasn't in the focus of the change now.

So, small batches to some may be bigger to some others. And these surprises in how they are sized up are causing the waiting problems, as one has already "moved on", when more work on the same small thing arrives. The developer never committed to complete the value, just his idea of what tasks would be needed to deliver the value. And he is mentally engaged on the other tasks already when he is told, with examples, that it just isn't done yet. The message is not welcome, leading to a wait time.

This all is a vicious cycle. It eats away morale of us all. The tester, the developer, the manager. None of us is happy. So how we don't get it changed is a mystery to me.

There culture includes a "need for speed". Doing things continuously, incrementally fast. Just add more. Change it. And don't break it while changing. There's no test automation to support this. The building block of speed is the developer, who is pushed for finding a minimal solution that could be delivered quickly. The ideas of someone testing are new and are mostly making things worse. The time was already up by time of delivery, and now the poor developer has fixes to create, while feeling the pressure of the next quick feature is the queue. And often not just the external pressure but also internal - the next feature is more fun that fixing the old one.

Let me look at a small batch from one more angle. A really small batch without big testing implications that would look like an hour of work - it takes three days. Or in other words, a work week fits just two of those types of issues. When a developer is pressured with time, they learn to protect their other interests. The motivation is low as you're all alone with your assigned task, and you might not have the skills to come up with a solution. The first day goes into just procrastinating with the idea of having to do this. Google a little, read whatever you find, talk to your colleagues. Not directly on the matter of course, otherwise they might say that you're not good enough. The second day you try out some of the stuff and none works. On third day you ask directly someone who knows and can complete the task in an hour. And after the other developer did the actual bit, you spend time testing, checking and finalizing, as your name will still go on the fix.

I believe that while the idea of small batches is great, the relevant bit here is to do something about developer happiness, motivation and skills. There's a reason for any of us rather spending time procrastinating than working efficiently towards delivering the value. The pairing and other changes I suggest threatens the hidden self-development time. It threatens the permission to work remotely and not talk to your team mates for days. But it also holds a lot of potential to make us happier, all of us in the team.

How many "small batches" does your work week fit? Doesn't the whole concept of small batches make you feel bad about not completing so many of them in your week? I love the idea for trying to split things rationally from a value perspective, but I hate the work monitoring implications.

Not all batches and skills needed in them are equal. Not all days for a professional are equal. I'm great at procrastinating, letting my mind wander and building connections that wouldn't be immediately relevant for the task at hand. But the stuff I'm learning and realizing while at it, makes a big difference in the end result. But I also finish the work. Sometimes when I was supposed to. Sometimes early, sometimes later. Motivation and feeling the purpose make a big difference on whether a small batch is small in actual calendar time.

Experience on how to turn testing into not fun

I'm back from vacation, with new energy and the old love for my profession in testing. Testing is great, it's fun, it's challenging. Except when it isn't.

I started off with (re)testing a small feature I had noted that didn't work in so many ways just before my vacation. Instead of us getting the feature finished and a feeling of mutual success on making a delivery, I was told that it would be fixed while I was gone. Well, some of it was fixed, but in general it still doesn't work. The users could not do valuable work with it. It doesn't work in real scenarios.

I talk with the developer to hear that the stuff I had reported before are "special cases" - relevant to the user, but all requiring logic he just hasn't yet implemented as he thought it would be special. I mention the new problems and they are deemed "weird behaviors" - we do agree. I'm concerned of the severity of the issues for the end user, blocking the delivery of added value. The developer seems to be concerned with the technical challenge of it, how could the code do things like that. I just know it does, from experience.

I ask if the developer tested the feature himself, if he actually uses it and he tells me he does. The blatant difference in our experience calls out for pairing to test it, to share the experience. With the new energy, I'm about to suggest that.

But, just before I suggest pairing (which isn't a normal way for us to work, sadly) the developer points out that he has started working on another task that will take him days to weeks and that he will not look into the "weird behaviors" before he's done with the other work. I remember again what really frustrates me - unfinished features waiting in inventory. Features that don't improve while they wait, features that get more broken when they are "fixed" after weeks of wait time. And the repeated experience of testing something that doesn't work for me, but presumably always works for the developer.

Waiting sucks. Finding easy bugs sucks. Not collaborating sucks. This isn't testing, this is starting testing again and again being blocked right in the beginning. Testing would be great. I hope I get to do more of that soon.