Thursday, August 28, 2014

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 ( 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.

Friday, August 22, 2014

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: 
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.

Friday, August 15, 2014

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:
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.

Wednesday, August 13, 2014

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.


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.


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.


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 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.