A tester view into mob programming

I remember when I heard the term 'Mob programming' for the first time. As with new concepts, I was eager to know what the new fad was about, and if someone had again just come up with a fancy word for something we were already doing on another name.

With a little research, I learned that it was whole team working on one computer. Everyone taking turns. It mentioned testers in the team also taking their turn on the keyboard, round robin style, regardless of the activity. I can't say I was convinced it would be a good idea, or that it would be fun. And in particular, I wasn't convinced that including all the testing work into the same style of work would be a good idea. Or that I would in any way be fit for that style of work.

However, I invited Woody Zuill to Finland for Tampere goes Agile to talk about Mob programming. It seemed interesting enough, different enough, revolutionary enough to be thought provoking. I listened in particular to the parts where he was discussing wait times building up and how that could be avoided, and could see a connection to things I perceive as relevant: feedback and reaction to it. And I started thinking it would be fun to try it out, even if it meant me taking a turn on writing code  every 15 minutes or looking at code most of my days. I also liked the ideas about team decision-making enabling change of mind, as learning would happen.

I suggested mob programming at work with my team to get a primitive reaction from one of the developers, who was clearly offended with the idea that introverts are forced out of their corners with all these crazy agile ideas. And when Llewellyn Falco was in Helsinki and suggested he could spend a few hours with my team on refactoring (as a mob), I did not even tell the team that we would be trying out mob programming.

So there I sat, as the tester who prefers not to work on code, working on code. We took turns on being on the computer as driver, and the rule of others navigating made it quite easy. I thoroughly enjoyed seeing how simple things were difficult for my team's developers, and how things I thought might be difficult were made simple. I feel we learned a lot about shared naming styles, about keyboard shortcuts and about regular check-ins of code (or fear related to those).  But a few hours is different from the idea of actually moving to do all work like that, and we did not do any testing yet.

Another chance to think about my feeling toward mob programming came as I was in San Diego, and got a chance to spend a day with Woody Zuill's team. It was a day in early January, and the team was not in its full manpower, just three people. I somehow assumed I'd just watch, so you can imagine the shock when Woody took it as a natural thing that he would add his visitors on the team to work with the team. Apparently that is what they are used to doing. A new company, new product, no clue on what is going on whatsoever, and joining a team - sounds like a reason to panic or complete waste of everyone's time.

The timer was set on 4 minutes - allowing faster rotation with newcomers - and everyone would take turns. I can't say I particularly enjoyed the driver seat, I was always so relieved when I could get off. We were sorting out a web service call not going through and while I was totally uncomfortable, I also started noticing that I could actually follow on what we were doing. The others were super helpful, building things up from telling a beginner line by line, tool by tool, window by window, and quickly adapting to telling a little less as the simpler ideas sunk in. They were navigating on the level the person driving can understand, building up the level as we went.

I can't imagine better introduction into a new team, a more efficient way of making sure new people start learning. With half-a-day, I have an idea about one part of the product. From my interests as tester into the system, I could get a lot of information that was relevant, quickly. And some things I might not be so interested in might also rub on. Seeing the team work this way made me think of empathy and understanding - to all directions. Woody talks often about "kindness, consideration, and respect" and he seems to live to those with him team even with visitors.

With half-a-day with Woody's team, I changed my mind on wanting to work that way. In addition to experiencing my discomfort and learning, I got a tour around discussions of what needs to be done and could imagine testing done in the very same style. I saw they were organising specialised times for product level exploration, again for the whole team. Planning and learning were nicely tied to the overall package. And one being away (or half of team being away) did not stop them from making progress.

I'm still not convinced if all work in a mob is a good idea. But a lot of work in a mob would be a great idea. And I still would love to experience a "all hands testing day" with Woody's team. I have a theory from my experiences in the past that testing might be different than programming for a mob.

I've really liked coding dojos in the round robin style. It works great, having a pair at a time working on things. But with testing dojos, I always felt very disconnected while I was not in the pair. While coding, we were creating a common understanding, but while testing, we were missing out on ideas because software speaks when you use it, we were getting easily disengaged.

With testing, I like mixing different dynamics: solo work in isolation; solo work in pairs where some stuff is shared right away and most stuff is shared at end of session allowing focus for the session; paired testing on one computer in driver-navigator -settings; group testing in round robin style; group testing where some stuff is shared as it is learned, but most things are discussed after session.  Pairing tester-minded people and pairing tester-developer.

My team has promised to spend half a day every two weeks like this - refactoring, programming together, hopefully testing together too. All I need to do now is follow up on the promise and schedule it. Knowing them, they would slip away if someone wasn't organising it. Any other testers out there trying this out? 

I failed - or did I, and how?

I'm feeling something every tester probably recognizes: guilt about problems in production. No one is saying that I should have found that problem. Everyone, including me, knows I did not put the problem there in the first place. Out of the choices we made on using our time as a team, we failed to understand where the impact could be, and none of the tests we did hit that spot.

It was not just one spot though. It was three.

The reason I feel particularly guilty today, is that I failed to do something I almost always do: ask the developer for clarification on what exactly did he change on a task of "last refactoring from LINQ to EF" - which parts did he refactor this time. Or to be more precise, I asked and I opted to be happy with a shallow understanding, not getting a more precise list of functionality he could see impacted. And his precise list would have included functionality that did not work. But I chose to use my time differently this time. After all, we have a working agreement in the team that a developer (who knew exactly what pieces he changed even if I did not this time) does own testing, to see if things work. With a ratio of 9:1 of developers and testers, testing is everyone's job. So if we failed, we all failed.

While my lips voice out the "we missed that" and "if we knew where it was broken, wouldn't we have fixed it" and "I focused here to find these other problems by choice, none of us came up with that spot to check", my head still says I'm better than that. And often I am, just by staying with the software longer, with more variations, pushing my luck in systematically going through things from different perspectives.

The feeling of unjustified guilt drives me to look at the symptom of "own testing" a little wider in my team. Not only did we see problems in production, but I've had one of the most unproductive days in a long time. I tested one feature (fifth cycle) to only find out it doesn't work. I tested another feature, to find out that the styles have completely been broken rendering the area unusable. And I asked for a demo (and then tested) a third new feature that did not work at all.

From three in production to three in test environment is evidence that the infamous "own testing" isn't happening, even if we just had yet another chat about it on Monday with the team. All these were problems you could not miss if you just opened the software for the feature that was being changed - there's much more intelligent problems around than just that.

I'm trying to change the dynamics, and here's my list of things I do on that:

• Move first experience of bad quality from me (externalizing the experience) to the developer by asking for a demo and showing it fails when they touch it
• Introduce simple variation in the demo, by asking to show specific things outside the usual demo flow, again with the intention of moving the experience of bad quality to the developer
• Add Selenium checks on features, in hopes of feedback that does not require the developer to go to the integration test environment personally
• Testing shallowly quickly after introducing a change. 

Removing the tester (me) seems like an option, to remove the feeling of someone to watch over you. But we've tried that before I joined, with the end result that our end users become the testers. 

I would love if we could learn that the most important work for us as a team is to make the product work. Developers are not too valuable to spend time on actual flow of value over insignificant half-done tasks and features, hitting an arbitrary (and self-created!) deadline. Need to find ways of building more of a culture of working software. That culture not sticking may be the failure I can feel guilty about later on. Accepting status quo and just compensating by testing brilliantly seems like an awful choice. Better than not testing, but there must be more I can do.

Submitting to conferences, take two

I have a confession to make: since I posted that I don't submit talks to conferences last autumn, I've submitted more talks than ever before. I've also been invited to do talks more, without submitting.

Not only have I submitted talks, I also volunteered with Speak Easy (http://speaking-easy.com/) to mentor other people submitting to conferences.

I still feel very much divided on this. If I am hesitant in submitting, how can I advice others to do so?

Why I'm hesitant to submit to conferences?  

Reason 1: Speaking gets expensive. Really expensive. Find someone who pays for it.

Many conferences don't pay for travel expenses. Some employers don't find it in their interest to pay for conference travel when conferences don't pay for it. Some employers don't pay for the time at conference either. As self-employed, the time away at the conference is also time away from paid work. This all totals to the fact sometimes speaking gets to be expensive.

I personally work for a product company that has no interest in promoting anything to the testing (or software) community. They don't have extensive needs of recruiting within the software professionals. The work we do, the testing we so is interesting and we have a lot to share - I have a lot to share. But my employer does not pay my travel. They don't pay for my time at the conference. If (when) I want to do it, I just take time of - unpaid vacation. Personally, I compensate by doing training/consulting on the side. But everyone does not have that option.

I'm a big believer in getting paid to speak or at least not paying to speak. I dislike the current culture of conference organizing (I'm a conference organizer with the bad habit myself!) where you, as speaker, pay for your travel and hotel to speak, and work hard to conferences close to me to paying expenses and later paying honorarium to all speakers. I believe that would significantly improve content, and that not paying is one of the main reasons we sometimes have hard time finding speakers - diverse as in people who have so much other work that they don't do the talks for promotion purposes only.

The reason why I started submitting again after promising not to, is that I want to find work in US, California to be exact - for personal reasons. And it seems that I will be doing that in a role of a consultant. This changes my stance on submitting. I need to pay to be visible. Speaking in conferences has direct value to me: promotion. I still believe great contents without promoting is the best promotion, so it does not change what I deliver. But it changes the fact that I need to submit even if it gets expensive.

I feel this financial divide already shows in quality of current conferences. Many of those consultants who have a lot of gigs coming in steadily without promotion won't take unpaid time away from their gigs. And those who have no promotional needs don't share their best stories because they would have to pay for telling the stuff everyone would love to hear.

When choosing a conference to submit to, submit to one that pays for travel. 

Usually that lowers the bar for your employer to let you be at conference as working hours. First time speakers are not always the highest promotional value for the consultancies and thus the finances will be an issue.  Luckily, there's exceptions to that rule around.
 
Reason 2: They say they want women to speak and I'm already out there as a speaker. How about doing some homework? 

Call for submission is a great way to find out what people would suggest to talk about. It is also a great way to make people put in a lot of effort in preparing a talk without their personal payback on getting to deliver that talk.

I've delivered talks in conferences, user groups and the like since 2001, tens of them every year. In Finland, I get invited - a lot. Mostly I don't need to submit. Some conferences make it their principle of not inviting, and sometimes I leave it equally to be a principle of letting them be without me. Sometimes I submit, like I did for Scan Agile, because there just is a message that the conference needs to hear from me. They should know to ask for one. But they don't. Sometimes they know to ask, like BTD Conference and I go without submitting.

I prefer to work on tailoring my talk with the conference organizers, knowing I can deliver great contents, over sending proposals where the feedback is Selected / Not selected. I prefer to be invited. It makes me feel like someone did their homework. Someone recognized where to find good people. Best conferences I've been to I have ended up this way, instead of responding to a call for submissions.

I can easily list a hundred women who could deliver great talks on testing. I regularly do that - not only for women  but great people in general - for Finnish conferences. We get great talks because we invite people. People feel appreciated when invited. And many people I have invited ask me to coach them on their message and delivery, a service I'm happy to provide to build even better contents.

If diversity (as in women) is something you look for, how about making sure you can name enough people to choose from instead of asking for the effort of submitting passively? You could specifically invite people to submit. That already might be something that would lead me to submit when I wasn't planning to. It's nice if people realize you exist instead of just waiting for you to push yourself to their view.

(Sure, I can always deliver the prepared talk elsewhere. I actually do, for rehearsal purposes. And it it would not make sense to send 50+ people from Finland to UK / Belgium / USA just to hear the latest and greatest I can also deliver to my local community. When Finns travel, I love the idea that they get to hear from those they can't hear from locally.)

Speak Easy, why did I join?

With the two points above, I'm still cautionary on submitting to conferences. Speak Easy promotes talking at CAST2015 as of now, and is particularly seeking for women, and I would not submit myself, so I feel a bit odd promoting the idea that you should. However, I think you should.

1. CAST is an experience worth experiencing

I've spoken at CAST once, and participated it once before I delivered a talk there. CAST is fun. The open-season style of discussions makes the sessions special, in-depth and high energy. It has been a great place to meet people. 

2. Great conferences deserve great contents

Everyone of us has great contents, practical and relevant experiences to share, things that help others forward. Great conferences are a good place to bring out the best of contents there is. There's messages we repeat, with different ways of telling the story bound to one's practical experiences. There's new messages we should hear, based on the different experiences we have.

Context-driven leaves open an endless selection of contexts. We should share how we do things in different contexts, to learn how what our options are, to become better at what we do.

I believe the world is full of great stories waiting to be heard. I know from experience working with great people delivering wonderful content in Finland, that many people don't recognize that their personal, hands-on experiences are just the kind of content that we'd like to see. Many people dismiss their experiences as nothing special.

Conferences like CAST cannot go around the world personally inviting people to submit. But with programs like Speak Easy, there's people like me who can go and ask some people personally to submit.

3. There is work to do in changing the dynamics, meanwhile we need to meet and mingle to talk about this.

I volunteered for Speak Easy because people will need support finding the thing they should talk about, and can use support in preparing their presentations. I've received help, still continuously receive help and would be happy to give back in return.

But the main dynamic that I would like to see changed is financial. I'd like to see work on raising funds on supporting travel costs for diverse speakers - not women, but people from companies that cannot afford to pay for the travel even if people would be willing to share their great contents. This is something particularly dear to me in Finland, something I already had written as one form of action for a testing non-profit we started in 2014 (Software Testing Finland, specializing in context-driven / skilled testing). I see Speak Easy as an opportunity to collaborate in long run in changing this too.

While I'd love to be already able to offer a "scholarship" for people who travel to CAST from Finland, I will need more work on the financing before that is possible. But I will get there. Finland first.

We need to meet and talk about changes we like to see. We need to talk about what is actually stopping us from submitting to conferences, and how we can help in the community. Being in a conference is a great chance for these talks.

Get ready to submit and take mentoring from Speak Easy?

There's plenty of organizations that have reasons to promote their existence by paying their employees to speak at conferences, yet those organizations have same people submitting. I'd like to encourage new voices where the financial framework already would support it.

There's people who are willing to invest financially into their career and visibility, but feel they could use help in getting their message out. I really like the concept of finding your voice with Speak Easy - helping you discover what you could share that is extraordinary. And then following through preparations to practice of delivery.

Speak Easy can help when you're interested in talking. And talking in conferences opens discussions that lead to professional growth I believe would otherwise would not be possible. If you won't go to CAST 2015, use Speak Easy to do a talk in your local user group. Use Speak Easy to do a talk in a conference that pays for travel. Use it for the conference you have always wanted to attend, to lower the bar of your company sending you there or paying for the time you are there. Get out there and share. Everyone of us has great experiences that will benefit the others when well delivered.

A personal note to end this with

Before I started public speaking, I was horrified of public speaking. I believe that the decision I made to actively work on my fears on public speaking have been the best investment I have made on my career. The transformation from someone who would faint at introducing herself to an audience to someone who gets energy from addressing a crowd of 500 people is almost unbelievable. But, it is what I've been through. I got help. I practiced a lot. I still practice a lot. But most importantly, I decided that was a change I wanted to see happen. I wanted to face my fears - and I did.

Speak Easy is a great idea for making finding the help you need easier, all you need to do is say that you want help. How about asking for help today?

Driving a mindset change: why it is good to sell non-existing features?

As a tester, I've spent most of my professional career in a split role talking actively to business and talking actively to developers. These two groups sometimes seem to speak a completely different language, to an extent where it is hard to get the communication to work. Agile and developers caring more for value and business has been a great help, but still there's time when translation is clearly needed.

One of those moments of need of translation repeated again in my project just a short while ago. My team's developers were full of anger and frustration while the business people were absent, on the fact that business people had again sold a feature that does not exist in the product and after selling it, came back to ask development if it would be available in March as they had already promised. The developers were raging on changes of priorities as whatever we thought would need to be done until now would have to wait, as this important already-sold feature allows us in development to drop all other work if need be.

In midst of negative emotions, I offered another viewpoint. We are looking at it wrong, this is a great, positive news.

1. A feature sold is a positive thing for us and schedules are not absolutes
   
   Our team - business and development together - is like a startup. Lean startup ideas - finding the business model that moves us as quickly as possible to sustainable product - are very relevant for us. We need to test our assumptions by going out of the building, validating with real customers and the news we just got is a positive result of one of those tests. Someone wants to pay for our product.
   
   The feature business sold was not something completely off the product vision, but it was clear feedback on the vision of what types of things would make it worthy to pay for. Clear as in signed contract, not just kind words promising possibilities that might not realise.
   
   The revenues pay the costs. We should, as a development group, care for the overall sustainability of our product, since we do want to keep delivering great features into it. And that is only possible if the things we develop are things someone will want to pay for.
   
   More than once we have complained on an opposite problem. Business asks for a feature that no one uses over 6 months after it has been available in production. We had implemented something that wasn't providing value, not because we did not implement, but because we had chosen to implement something where the need of the feature was theory that wasn't tested in advance.
   
   When the business sells a feature to be delivered in three months, we should learn to trust them on the fact that they did not just do an estimate for us. They did an estimate of what their customer find acceptable for now. We should look at history and remember that this schedule too is flexible. If we deliver half of the promised feature in a way that delivers half of the value it is easy to get more time negotiated without losing the sale.
   
2. Our team is perfectly equipped to changes in business needs with continuous delivery
   
   We already work in a way that supports this and we have no need to resort into the old school development thinking, where we're opposing sides with the business. We use Kanban with Work in Progress limits, and we can always move away something else to focus on the new thing. We are good, even great at that, and should take pride in the fact that we are responsive to business without giving up on our idea of technical excellence in particular in maintainability. We always find the good ways to do things, in collaboration.
   
   Sure, the roadmap that gave us an idea of what would happen this year will change. But the roadmap was a theory of what we'd work on, not a commitment into us delivering this. Our team sets the goal we're rewarded on for the year when most of the goal has already been delivered - we're already tweaking the rewarding process to support the real way we should be rewarded on, our excellence in delivering value and flexibility of what the value actually is. 

I know remembering this is hard, and I'm here to remind us on this. I'm here to suggest we celebrate how great we are in being able to do this. And I'm absolutely delighted to realise that looking at this as testing of customer needs is a helpful way for me to communicate it further, for both sides. 

Being in a position to know a little of both worlds can have a significant impact in how we understand each other. And what I love most about being in this position is that is has a visible impact on how much and with what quality we deliver. I know something about our business and it shows in how I test, not only in how I talk about what we're developing.

Great manager does not keep bullshit away from me

Ilari-Henrik Aegerter made a good point yesterday in evening discussions on the fact that there are very few line / business managers in the ranks of context-driven testing. It's great that while he is nowadays a manager set to be just that in the future, he still chooses to hang out in testing crowds.

Listening to him, I realise I have the habit of moving between a manager role and a tester role, and that from a personal preference point of view, I'd like to see test managers being very hands-on to be respectable while line/business managers I consider a different trade.

When talking about his work as line manager responsible for 20 subordinate managers, Ilari talks about shielding / protecting as his responsibility.

And another nice one by @ilarihenrik: "One of my roles is to keep BS out of my team." #DEWT5
— Jacqueline Frank (@jackiejackjack) January 18, 2015

Hearing this, I realised that I don't want my manager to shield / protect me, I want my manager to support me. I consider this a relevant difference. I don't want my manager to "remove impediments" for me, I want my manager to support me in removing impediments. A significant part of my happiness at work is the versatility of tasks I work on, and I would find the idea of boxing the work into "tester work" and "manager work" uncomfortable.

Let's look at a tangible example. To get our testing done, we will need hardware and organisation tends to make hardware acquisitions difficult. If I would work on hardware acquisition, it would be time away from my focus on testing. It could be a welcome change that increases my motivation. Or it could be needed at a time, when I could really appreciate someone else helping out with that particular thing. Instead of seeing that as manager responsibility, I like the idea that managers responsibility would be to help and support when I need it - like when I want to and need to focus.

When I remember back on things I'm particularly proud of in my career, many of the things that come to mind are things that could have been "manager work" that I did as a tester. Seniors can do things, and make things happen. Hardware example is good in the sense that I remember getting two of my organisations to invest significantly into test environments in cases where others would tell me it is not possible - and yet it only took making the business case visible.

There has been examples where I really appreciated my manager doing things for me, often bureaucracy. I remember fondly a manager who created a flexible job description for me in an organisation where that was "impossible". I love my current manager (eh, last year's manager) for letting me run my own collaboration reviews and just supporting my ambitions and goal setting instead of trying to set my goals for me. And I remember with warm thoughts a manager who refused to be an escalation channel for the discomfort my existence created in the organisation, but would always sit me in the table with the relevant parties to resolve what ever issues were at hand.

I don't like the tester / manager role and responsibilities split as I want to deal with versatile challenges. Then again, I realise other testers might want stuff to be done for them. I want the control to myself on when I focus just on testing and have asking for help as my responsibility.

When I work as manager, I tend to consider my role to be helping. If it means collecting the empty soda bottles away from the test lab, so be it. It can mean doing the work that no one else volunteers for, or pairing up to do that work. It can mean running some nasty bureaucracy with creative interpretations of the external requirements (my specialty). And as line manager, there are specific responsibilities on hiring and compensation that might be hard to delegate on the decision level. But as a tester, I would like to see my manager actively delegating wide responsibilities to me.

Sense of being given versatile multi-role responsibilities is essential for my happiness. I appreciate my current managers for understanding that and never telling me that "this is not a tester responsibility".  I love dealing with bullshit and I excel at that. And it does not mean that I have to become a manager (for a change). Testers can do that too.

A learning journey with unit tests just starting

I know I'm privileged. I have work that allows me to craft my work into whatever I personally want it to be. I can share details of my work other people could not share. I have friends and colleagues that are willing to help me with whatever I'm ready to accept help on. The privileges with a new year brings me to a new thing I'm just starting to work on: unit tests.

My team does some unit tests but the scale is small and all of it is test-after. The tools and approaches we've chosen come from books and articles, and the level of fluency we have on the whole idea of unit tests is low. I've kept my distance to unit tests, occasionally looking through what there is, but I never took the time to get my environment to a point where I could even run them. Looking through them happens mostly in secret, all by myself, but occasionally I might also ask a developer to show me around, just to make them talk of what they've been up to.

I have had a feeling that due to lack of fluency in the practice, we're really not getting the hang of it.  The lack of fluency is also driving us heavily towards Selenium tests, where the feedback cycle is long as we run those tests only with nightly builds. And even there now that we've added more tests, we're seeing symptoms of brittleness that lowers the information value our Selenium tests provide.

I feel I'd like to help. I can help by bringing in coaches and consultants, and that is how we ever even got started. But someone visiting with examples that are not your code tends to be quite different from the actual work. A day tends to be different than longer term. And my company tends to not be ready to pay for longer term help. So I asked help as in a personal favor for me to learn unit testing from a friend with much better knowledge on the topic than anyone in my team. This starts my journey into total discomfort, as he volunteers to personally coach me and pair with me to help me learn things I know I could and should, but not always want to. The step from theory of code and reading of code into writing it, even with a great developer to pair up with, is going to be causing me some growing pains.

With our first session, I came in with the idea that we could look at some tests the team's architect - the best unit tester as far as my perceptions would be right - had just added. I wanted to see what is there, and if that would help me make some sense into the whole thing in my head. We randomly sampled one.


Just looking at it left me confused.

• I had no idea what the "comparator" the test is testing is
• Naming into "method_scenario_result" is probably consistent with a good practice from a book, but it doesn't exactly help reading the test
• I could just not make sense of what the test was and was already ready to give up

All by myself, I would probably have given up. But with a friend with me, I was asked to give him seven minutes of a time box to work on the test with me, and we'd see then if it starts making more sense.

He said there would be some work we could do on readability of the test, and we started from creating the same test idea in a bit different format, where everything we worked on focused on readability. The tests would be named more simply to read as English, the concepts would be pulled out and grouped both on level of tests and variables within the tests, and the test data we would use would try to emphasize the fact that we're testing case sensitivity. With test data he was advising me to create, I found connections to stuff I do when I test - being able to follow the data, like entering text into a text field that tells me where that particular piece of data had been entered.

Seven minutes passed, and I had started to feel there was hope after all. With another seven minutes with him explaining changes step by step with me on the keyboard asking whenever I needed to clarify things, we ended up with the new, extended version of the same test and found inconsistencies in null/empty value handling that could be a bug. We also changed the code the test was testing to handle nulls.

With the short time of changing the code with readability in mind, I feel a lot happened. Some of the information in the original tests was not relevant to what the test was about (the content of the URLs did not matter), and as it got removed, it made understanding what was there simpler. Instead of every test being an individual check, we'd group checks so that each test checks things that belong together. It would end up as something I can read.

It would be foolish of me to claim I now could do all of this by myself. I feel the main outcome of the first test was a positive feeling that this could eventually make sense, and that I would not need to run away and hide even though I was feeling way out of my comfort zone. 

Why I think we should pay for online courses?

In my review of year 2014, I mention teaching commercial version of BBST Foundations. I was asked for more information or backstory to why I think online courses should have fees and though that would be a good thing to share. It was definitely a perspective I had not considered myself.


If you're into testing, you probably know what AST (Association for Software Testing) BBST (Black-Box Software Testing) course series is. It's a brilliant online course on testing and it is ridiculously cheap. Some of the courses in the series AST offers for free. The most expensive in the series is $200. That is basically nothing.

BBST Series of online courses are different. They are not just a talking head of video and exercises you do on your own, but they are fun, engaging, challenging and include relevant amount of group work. They teach different things to newcomers and more seasoned professionals, and are worth the time investment in what you can learn on the courses. But they are also different in the sense that the time investment a student needs to put is not light hanging around in the classroom for two days, but half-days here and there in cycles of half-a-week for four weeks. And time is money for your organization, you in training is probably time away for invoicable work - a term I keep hearing from management quite often.

I'm suggesting that what AST does with making the courses free to participate is a bad idea in long term, and that it is an idea I cannot support. I don't really actively talk against it, it's really none of my business. But I want to actively talk towards making it possible to create course contents like this. It should be financially sustainable for the creators.

You probably know if you stop to think about it how the classroom teaching works. You hire a teacher who will facilitate the learning experience with you, come in with material that makes it effective, but essentially, you will feel like you are paying for their time. Online training in general has changes our ideas of what we are willing to pay for, so that reusing a video is not considered time we would want to pay for, and if we are able to create exercises that can be done individually, scaling that makes it significantly cheaper. But most online trainings are not anywhere near the experience you can get with a good classroom training. 

The BBST series has been created with significant funding from research institutes over a period of a decade or more. The main creators are Cem Kaner and Rebecca Fieldler, and creating the course contents has not only seemed to be their full time job, but also a hobby. The course experience shows the dedication that has been put on the contents. Research financing works so that it stops at some point. It does not go on indefinitely. At some point, even research funding expects that the research starts to pay back and either become financially sustainable or wither away. AST using the open source version of the BBST materials is one approach to making the research results financially sustainable: running low cost organization based on international volunteers.

As with all things in software, change and improvement is inevitable. So it is with the BBST series. So someone should spend significant time still looking at the effectiveness of the teaching material, develop it further. And that someone should get paid for their time.

This is why I'm in support for the Kaner Fieldler Associates version of BBST series. First of all, it has the up-to-date materials that fix some of the problems the AST version has as some of the lessons are missing from the research results, and were only done after the research time was over. Second, there's full courses in the series like the absolutely wonderful domain testing course, fourth part in the BBST series.

I hope to see many commercial courses - public and company specific - emerge for KFA (Kaner Fieldler Associates) BBST to support the future development of great teaching materials for testing. I was happy to participate in delivering with this ideal with Altom Consulting. And while my efforts are now elsewhere, I would like to see people support the future of the BBST materials by choosing courses that they will pay for.

There was just today a nice post on getting paid for speaking that hits the same chord. Traveling around the world on someone else's expense is fun, but speaking from a personal experience: it is taking unpaid days off client work. We should be ready to pay for value, or we get talks and trainings by marketers that are shallow and sometimes infested with marketing interests over actual learning outcome.

Taking stock of 2014

A friend of mine tweeted today that 2 % of year 2015 is already behind us. It woke me up to realize that I'm very much out of my usual practices related to change of year, as I have not yet tried looking back to what the year was and what should this year be. I'm not big on new years resolutions, but with all this agile and continuous change, I find the regular rhythm of stopping and seeing bigger things extremely relevant.

My big thing for new years seems to be to learn more, within the context of understanding more about contexts and how to do great software (testing) with different kinds of organizations and people. And I find sharing what I learn amplifies my learning and makes me more driven - challenges me. 

Becoming International

Being more connected with the international testing community was something I wanted for 2014. I took the easy route to be more connected, being active on twitter (now with 920 followers and a great number of people I follow) and blogging actively. I have published 62 blog posts in English in this blog, with 27239 clicks in 2014. I've been delighted to see that Software Testing Club has noted several of my posts, and that Joris Meerts, tweeting as @testingref regularly tweets links to my posts to the testing audience. Comments / discussions -wise it has been quiet, more quiet than I would hope for.

I managed to publish an article in Testing Circus on using Rapid Reporter. There's a few articles I'm working on, that I hope to finish in 2015, and will publish more to contribute for Women Testers, Testing Circus and Software Testing Club. 

I was helping out Mieke Gevers with Belgium Testing Days, organizing Test Lab for the conference with my close friend Ru Cindrea, and on that conference met several people. I found respect for Lisa Crispin, as I watched her work remotely in the hotel lobby to help her team make a release at Belgium Testing Days - her contribution in the team, something that I find very hard to grasp from the Agile Testing book. I got a chance to meet Richard Bradshaw and really look forward to bringing him to network with the Finnish Testing Community. And I met Huib Schoots and Joris Meerts in person.

Twitter-wise, I feel I have found some great ladies to network with: Ann-Marie Charrett, Katrina Clokie, Amy Phillips,  Jyothi Rangaiah, Ulrika Malmgren, Teri Charles, Helena Jeret-Mäe. I follow them all closely, in addition to ones I already had on my list before this year. Ladies seemed to be a theme of the year in general, as Jyothi kicked off women tester magazine that I have yet to contribute to.

We also had international guests in Finnish Testing Conferences, and I got a chance to talk more with Iain McCowatt, Shmuel Gershon, Alan Richardson and Ilari-Henrik Aegerter. I noticed I have a pretty good track record on getting my suggestions of who to invite through with the Finnish conference organizers.

I also co-taught BBST Foundations with Cem Kaner with Altom with an audience of Romanian and Finnish testers. BBST is a great online course that has even greater version by Kaner Fieldler Associates than the AST's free one. And I became a supporter of the idea that we should pay for online courses to support sustaining the contents and developing them further.

Becoming international is really the theme, as I also ended up submitting talks to international conferences and thus will be speaking in 2015 at TestBash in UK, STPConference in US. I was also invited to hang out with DEWT on Strategy in the Netherlands - peer conferences where everyone comes with an experience, will see if I deliver mine or not.

I also decided to start chasing a dream of relocating outside Finland, which must have something to do with the fact that I just turned 40 years of age. At least that is what my team's developers say. The dream chasing became more pressing, as I fell completely in love with a man from US and really would want to spend time with him. Thus the end of the year has been colored by efforts in starting to look for a job in San Diego.

Being Local

As always, I'm a networker and learn from people. Whenever I had an idea of something I wanted to discuss, I would organize a meetup. And I organized many, locally in Finland. I started a new non-profit on Context-Driven Testing with Soile Sainio and Sami Söderblom called Software Testing Finland (Ohjelmistotestaus ry). For the non-profit, I blogged semi-regularly in Finnish for the autumn. And I still continued to volunteer actively with Agile Finland, which included also organizing Tampere Goes Agile -conference for the second time.

In addition to organizing a lot more, I did a few talks and trainings myself: 13 was the total for 2014. I would actually like to get back to doing more of contents and less of organizing, and that's something I'm working towards with Agile Finland deciding to hire it's first "make-it-happenizer".

Changes of Focus at Work with a Personal Crisis

Weird enough, my work at Granlund became work in 2014. It was no longer the center of my universe, but it is still very much something I enjoy. With an effort on in-team communications and pairing to fix bugs without reporting them, I ended up logging 535 bugs. My focus moved from finding as many relevant bugs as possible with two products into being a full-time team member with just one product.

Our team took huge improvement steps. We moved from TFS to Git in Visual Studio, and learned to do continuous deployment. We stopped estimating effort, and take baby steps towards focusing on flow. Communication and collaboration improved a lot. And there's all the time in the world for testing a change before putting it in production, as it is no longer the last check but a relevant part of how we do things together. We also learned to talk about requirements and what we're implementing so that we managed to turn around the trend of rewriting features when I joined in later to test them. No Specification by Examples (yet), but just talking about what we'd expect with the whole team and the business representatives.

I also turned the managers around in their "no international conferences" policy, getting two of our developers to fly over to an unconference in Romania. This was something everyone in the team swore that would never happen. And I got the biggest compliment ever, being named the team's "catalyst" - just being there makes things happen better.

On a personal level for work, I started the long and hard route towards being more of a developer to get rid of excuses my team's developers have on skipping their shares of testing. And the one developer who told me that women can't code was probably just presenting a challenge I need to accept. And I had that challenge written in my personal goals in collaboration review.

Coding with Kids

My son started the first grade, which lead me to the natural idea of volunteering to do stuff on computers with him and his school mates. With trying out different things at home, we finally started doing things at his school with #HourOfCode -week, as I got to teach Angry Birds and Frozen Programming Basics to three different groups.

Before that, I volunteered to join on teaching a TKP class (Teaching Kids Programming, Java) with 8-9th graders. I consider the idea that the local teacher now wants to continue teaching this class for spring term a great accomplishment.

We also started some discussion on teaching kids programming in general. With that theme, I got to meet Linda Liukas and people from Finnish Ministry of Education, and look forward to turning that into actions in 2015.

More Focus on Personal

Even if I did more than ever on the professional side, I still feel 2014 was a year of personal achievement.

A year ago, I told I had lost 28 kilos and I continued the project until my birthday, becoming in total 46 kilos lighter than I had been. I became addicted on dancing (zumba & sh'bam) to the extent that I would leave work early to go work out and not promise to do volunteer work if that would mean skipping my favorite dance class. Pictures perhaps speak louder than words on this. The square picture is very recent. The two others are before and after.

As I mentioned earlier, I also fell in love, so much that it makes me fly across the ocean to spend time working remotely in San Diego right now - and actually for 8 weeks in first two months of 2015.  And I actively look for ways to relocate to San Diego, so in case you have hints on how to do that, I would very much appreciate you letting me know.

Who is stopping developers from doing unit testing?

Last night I participated at .NET user group meeting in San Diego. I should not feel that out of place, after all, I work with .NET development even if I choose to focus on testing, and I love talking to my developers about all the cool stuff they get excited about. And that tends to be about some very neat way of implementing something. I thoroughly enjoy the excitement they have for their craft even if I occasionally wonder how something like that could be so interesting, but I know they feel the same about me ranting about something really cool on the testing scene or what I learned about our product or people or whatever makes me tick this time.

The speaker of the evening was David McCarter, speaking with a title Rock your apps: 10 things you probably aren't doing. I enjoyed the talk, in particular I found it funny that we share so many things to rant about in for example realizing how the world around the implementation details work. But something he said, not the main message of his talk, left me really puzzled.

Most places don't let you do unit testing.

I felt like I had entered a time warp and jumped 15 years back in time, it has really been so long for me to have heard things like that. I feel that nowadays you are required to do unit testing. They actually teach it in universities - at least where I come from. And test-driven development is pretty popular too in my agile-like circles. 

With the shock of that statement, I had a discussion on the topic on the way home to learn to my shock that there were recent experiences close to me (that's what happens when you change your circles, new shocking information - be careful who you date...)  that somewhere managers had actually asked to remove already created unit tests as good developers are not supposed to need tests. The mere idea is awful.

My experience is that a lot of times we in the teams hide behind "estimates" and "not being given enough time" to not create unit tests. The reality is that we need much time, as we don't have the skills to do the unit tests. We add them after creating the software, when adding them is harder, and we tend to be very careful refactoring in fear of breaking things. I can't expect my managers to give me a blank check on time to not provide end-user visible value, but I've experienced my managers being very helpful in finding timeboxes in which to drive things forward.

This took me back to situation in my current place of work two years ago. Actually, the developers were telling me when I joined the company that they are not allowed to do unit testing, just feature after another. I soon learned it was not true - or it was true as their perception. I helped the team negotiate a week of each month on learning the basic skills on this. They could have started any time  before me. It was just about asking, suggesting, finding a balance.

For any of my testing colleagues out there: ask your developers if they feel they are not allowed to do unit testing, and when you can help them. There's so many things on how you can help. Support their message. Talk on their behalf. Reframe unit tests as "executable documentation" like Liz Keogh suggests if it helps. Ask for effort for developers to participate in testing, and organize that as their refactoring time to allow for adding the tests they'd want to add. Acknowledge the work someone does on adding tests. Be interested in their experiences, and help share those in the team, just by voicing out a question that others are not asking. Create an atmosphere where the managers see that this practice creates a lot of positive around it, pinpoint the good and help improve the bad.

And if it happens that your developers really don't yet want to do unit tests, send them somewhere to meet their happy colleagues who are already doing that. What you say will have less impact that their peers saying and showing things.

Unit testing, as agile emphasizes it, is the best thing that has happened to quality. Even though it is a type of testing I tend to not deliver.

Who really stops developers from doing unit tests? Their own perceptions. Help them change that. Developers might say managers, but have the developers then really done all there is in advocating for their perspective? Investing into unit tests is a valuable practice in the bigger scheme of things.