From test of the need to building the program

Today, October 20th, is the last day we sell Super Early Bird tickets (350 euros) for the European Testing Conference. All of our tickets are cheap in relation to the conference contents we're setting up, but this is ridiculously cheap for a 2-day professional conference in a high-end location in Bucharest, with great international speakers.

Two weeks ago we set out to test the need of this conference and support in the community by setting a goal of people showing us they want us to do this by buying the tickets. On the last day, we are at 85 % of our goal, with belief you will take us above our set limit. Two weeks ago, I was feeling moments of despair fearing what the decision to test would reveal. But it is revealing that you're with us.

We've started our call for co-creation. That is to say that this event is from us the organizers as part of the community to the overall community. We think we know some great speakers as we follow our craft intensely and have been around. But we also know that our sample is the visible contributors from around the world. We need the community to help us find them so that we can reach out to them, inviting them to share with us for you.

We do not limit ourselves to call for co-creation. We seek the best speakers and contents, both with you and without you, co-creating it with the speakers. And we believe we can do this, because we have set our conference uniquely to pay the speakers for the work they do. With this, we're changing the world of testing conferences that sometimes appears to mostly enable people whose companies have something to market.

A few people have asked why buy the ticket without knowing the content. My answer is to look at the list of organizers and the sessions we do in conferences around the world, that sets a bar (which is not low) on contents we will be offering and decide on whether you would trust us with your money to be invested in the best possible testing learning experience combining testing as we know it as developers, testers and analysts.

We've intentionally revealed so far only that Linda Rising will be with us to encourage us into the days of practice. Linda is the author of a book Fearless Change, and speaks from a vast experience of being around a while to the hearts of people. When I first heard her speak at Turku Agile Days, I left the room crying and I wasn't alone. Her talks move people and change the world. And now she joins to change the world of testing with us.

I will make sure I can say as positive things about every one of our speakers, not just the keynotes. That's why we co-create. We get to know you. We want to help you shine. And through this, we all win. We're creating a balanced conference of practical testing, with an agile slant as we believe in fast feedback. You'll want to be there.

Oh, the normal ticket price is now available: it's 750 euros. The Super Early Bird price is available only today.

Writing a blog or writing a book

If you read my blog, you must have figured out by now that I like writing. Writing is my way of externalizing my thoughts, making notes of them and finding bugs in my thinking patterns. I forget my thoughts and going back to them helps me see things with fresh eyes. Now I'm moving from writing a blog to writing books, discovering LeanPub.

A theme I have been writing about a lot is pair programming (strong-style) and in particular mob programming that includes the same pairing mechanism as strong-style but extends to the whole team.

In Tampere Goes Agile 2014, I invited Woody Zuill to share my community his story on Mob Programming. Since then, I've been practicing to get towards it and learned that Mob Programming is a gateway to pair programming too for pairing reluctant developers. It feels safer as the first step, and shares the responsibilities of growing up those who are behind in their skills development on some area. In Tampere Goes Agile 2015 just this weekend, someone phrased it nicely: a year ago they heard about Mob Programming for the first time. Now it feels like it's everywhere.

There's companies like Mystes in Helsinki who have several teams mob programming full time and sharing their experiences locally, like in Scan Agile 2015 -conference. There's people like Woody Zuill and Llewellyn Falco, who have both been around since inception of the concept that keep showing up. Llewellyn now lives in Finland, and Woody has been back twice since first visit in Tampere Goes Agile 2014. I've experienced a bunch of coding sessions in mob format to learn refactoring and test-driven development. And I've started experimenting with mobbing at my work, and in particular, I've transformed all my exploratory testing training sessions into a mob format during the last year. It just works in learning so well.

From a discussion with Juho Vepsäläinen I realized that the work I do in background (writing a book) I should change into doing it in the foreground, as other people energize me. So yesterday I published with Llewellyn Falco our first version of one of our books in progress.

Mob Programming Guidebook. 

Today, we have sold for money 3 books. The support of people in writing can make a world of a difference. It makes a difference for us. Writing when you know there's someone who wants what you're writing creates a different feeling. I can only call it "driven". This book goes forward, and it will be awesome.

I feel I need to add thanks to all those people, who tell us stories of struggles on introducing mob programming. How it feels wrong and how it fails. That comparison is already helping us isolate some of the patterns that you might want to recognize that helps you in succeeding and getting well started.

It's time for me to learn how is it different to write a blog and write a book - in leanpub style. This should be fun!

Four sessions of remote pair testing

Sometimes I feel alone and isolated as the only tester amongst the developers in my team. I start to question my learning, my observational skills and my ability to work with people in general. Pairing up with other testers on an exercise helps with self-doubt. Remote pairing with volunteers has also been a relevant step in my ongoing journey to learn to be a better facilitator and participant in mob programming (testing activities in mobbing in particular).

In particular, after a weekend testing session where remote pairing was a hard experience to deliver through writing and instructions, I asked people from that group to give me an hour to experience it with me.

The setup for pairing was use of my computer, sharing control of it through join.me -application. We would have a Mindmup-document to make notes on. We would have Dark Function Editor as out system under test. And we would have a recon mission, learning what there is that should be tested as our starting task. And we would change who was driving (using keyboard) and navigating (speaking of what to do) every four minutes.

The four sessions I had were completely different in how they felt to do as a pair. The four sessions also had very different outcomes as in the learnings we had on the application within that timeframe.

From the shapes and colors in the mindmaps, you can already see some of the differences. One session was much more attention on the software, trying to understand as much there without making notes regularly. One session was very observant on bugs. Two sessions focused heavily on identifying the  features, noting only occasional bugs. It's hard to do all at once. 

Here's some notes I've written down on the session that I enjoyed the most:

• She made me work on higher level of abstraction, giving me small tasks without details on instruction with instant feedback on correcting if I misinterpreted what she wanted
• We noticed things together, and found bugs in the application I had not seen here
• She knew what she was doing, even if she usually tests backend and logs. 

To contrast to another very output-wise productive session I did not feel at ease with:

• Very focused on what is a bug and knowing the right answer on a product we don't know made me feel like my product, even me, was being criticized.
• Strong assumptions, not testing for what is plausible out of what we think we already know; overconfidence in coverage in short time
• Not staying with the pair but going alone to prepare the data - different idea of working in pair
• As a driver I keep asking "what would you like me to do", "did you notice", "should we make a note of that" - feeling left out. 
• Could not change roles while "in middle of something". 
• Pointed out a type of functionality I had not paid attention to before: tabs.
• Not "pairing" but "working individually with someone watching". 
• Needs longer timeframe to build into collaboration not a skills demo. 

The two others I had not made as specific notes on. I remember really enjoying the flow and ease of one, and enjoying in a very different way with one where we started from basic ideas on how testing works. 

My main lesson: driving and navigating are skills that take practice. I can learn from everyone, but everyone also teaches me very different things about myself. Practicing with different people is good, and a regular reflection on how the pairing makes you feel creates an environment where the experience is going forward. But there's some hard messages to deliver about how you feel sometimes. It's not about getting the most out of the two people, but the best. Both need to be contributing. This experience also gave me a glimpse into the idea why pairing can make people quit: inability to hide while requiring much out of your individual contribution creates extra stress. 

Unit testing is about Asserts

There's this weird state of mind that I'm in with Unit Testing. I read unit tests, I talk about unit tests but I rarely write any. But I've been around them enough to start to think I'm recognizing some patterns there, and know when stuff I'm being suggested is useful / good and not.

Last week, one of my teams had a Unit Testing -training. My motivations to participate were two-fold. I was really curious why they had set learning unit testing as their target (now that they no longer have a professional tester working with them, the rumor is that they might be struggling more with delivery quality). I also wanted to see how the new training company was doing on the topic.

Out of the three hours, we spent two with theory and one with hands-on work. The theory was the usual stuff: refactor to find functional bits you can test. Isolate the bits that make it hard for you and leave them out of your tests. We also looked at my team's tests, without a single good example. There was a lot of bad out there.

The hands on work focused on removing need of profiler in the tests. We had been heavy on mocking with JustMock, that made testing possible, but to an extent it made tests slow doing some things for us that weren't needed. So we were removing dependencies on Profiler.

While looking at the examples and the tests we were trying to change, my eyes kept going to the asserts in the tests. That's where the bit of testing with the tests happen. And I could not help but noticing how weak the asserts were. I had been primed for paying attention to that.

To start the same week, I had just listened to a talk by Llewellyn Falco titled "Common Path for Approval Testing - patterns for more more powerful asserts". Perhaps that is why I made the connection: all of the asserts I was seeing were the first step. We would assert numbers and boolean values for existence. Nothing more advanced. Nothing more meaningful. And asserting simple things is simple, but leaves a lot to hope for in the perspective of actually noticing that things break. And when they break, being able to analyze what is going on. The picture introducing step 6 (Diff tools), doing things on failure that can be slow but happen only on items that fail was an eye-opener to me.

With all of this, I was left to wonder. Having weak tests that run faster cannot be the goal we should be having. When there's many things to work on, how do teams really end up making their choices of what to start from? This choice, looking from a tester perspective, just makes little sense. If testing happens somewhere in the unit tests, the asserts seem like a place to pay attention to. Thus I'm very drawn to the idea of making them more powerful. 

Contributing in mob programming as a non-programmer

Mob Programming is about the whole team working on one computer, taking turns on the keyboard driving (no thinking while on keyboard), and while not on the keyboard, navigating with the rest of the group. It's single piece flow, everyone working on the same value item.

Here's a worry that re-emerged from a discussion I had, something I've needed to address for myself.

What if I'm a non-programmer, I'm learning but not contributing, I'm just slowing the others down.

Well, I'm a non-programmer and I've volunteered to sit in mobs. I continue to volunteer, to the point that I'm working on convincing my team to mob more with me around. So I've needed to address this, and here's what I learned to pay attention to.

1. Being there "holding space" for testing/quality has value too.
   There's a weird phenomenon I'm observing when I mob with my team. Quite often during our day, one of the developers glimpses at me without me saying anything saying "should we test that?" or "we'll need to fix that". It's as if they are somehow on their best behavior on testing/quality, knowing that stepping away from testing I'm there to remind us - without me even reminding. They work better when I'm around. Sometimes they even acknowledge that in the retrospectives.
2. Being there as "the only woman" or "the only non-programmer" has value too. 
   I don't really know how my team mates behave when I'm not around. But I've listened enough to others to recognize that me being different has value too. It might be again that people are on their better behavior. But it seems to be also that me being slower in getting what goes on makes them being clearer in navigating. And there's been observable instances where speaking with me in mind makes things easier for the other developers.
3. My learning has value in the long term even if not immediately
   When I'm there, I'm learning a lot. I'm learning about details of implementation, dynamics of what is easy and difficult, ways developers go at problems and the syntax of the language we're working. Seeing my developers work creates different models on how I test when I'm without them, knowing where they seem strong or weak.
   If I am just learning today, that learning is in use for me the next time we do this. And I get to live to my motto: every day at work makes me, my brain - the most important tool in testing, a little better. I'm sticking around, I matter just as much as the next guy.
4. Driving and allowing others to navigate has value too.
   Just taking the keyboard and writing what others tell you, even letter by letter has value too. It slows down thinking and makes thinking clearer. I've noticed me being slow gives my team mates room to jump in to correct the other, just because they want to avoid the mistake being made in my pace. Articulating your ideas clearer is good. I can provide that service when there's nothing else I can provide.
   With few rounds, they no longer need to tell a non-programmer introducing variables letter by letter, but they get to work with concepts. Every non-programmer can learn that, and it does not turn us into programmers immediately. Personally, I think ability to fluently read code is separate from ability to fluently write code, and I can do the first as a non-programmer. I love talking around code, but writing by myself makes me sleepy.
5. There's stuff I contribute when I speak up
   I've noticed I say particular types of things. I pick up half-sentences that are about domain knowledge to correct it, preventing mistakes from turning into code. I ask about using time on something and if we should try something else. I have answers on direct product-owner-type questions with actionable information of connecting features on detailed knowledge of using the product in all imaginable flows that come to my mind.
   Llewellyn Falco told a story about one of his mobs having a team member who contributed by asking "maybe it's called something else" without knowledge what that could even be, triggering the others to realize the place they were looking at being wrong. They could have been stuck there for quite a while, and found what they needed with that remark that mostly went unnoticed.
6. Positive feedback is valuable
   I've noticed many of the things I say are about my amazement of how nicely things flow, and how smart my team mates are. Hearing someone appreciates what you do with specific examples isn't an everyday thing. Saying "I feel I did not contribute, you are great" has value in itself. But you might notice that your team returns the favor and lets you know they appreciated you being there - even if you slowed them down. 
7. Beginner mind
   Adding one more thing on my list. There's a bunch of questions only a true beginner can ask. They are typically "why" -questions. When answering why you do things the way you do, the more experienced one tends to sometimes find out that thing they take for granted aren't. 

Give yourself a chance and try mob programming. If you are worried, don't stay away but express your concern and invite the people you mob with to bear with you. In a mob, you're valuable when you're learning or contributing. Learning is a perfect reason to be there. 

From Co-Creation to Collaboration

Agile. We all have our ideas what it might mean. When listening about Agile Testing explanations, it's evident that testing is still testing but Agile is a context that changes many of the factors on how the testing ends up being done.

With Agile, the testers have learned to work together with developers. I guess it works both ways. We hang out in the same meetings. We share work on the same value items to deliver. We pitch in from a bit different perspectives, with a common goal of getting it done, learning to find problems before implementing still leaving the question to be answered on how well this works when it has been implemented. And "this" is something small, with a continuous flow.

In this setting, when a tester finds a problem, she tells about it to a close colleague. Having worked together for years on consistent pace, there's no drama to this. It's information exchange. I know something you didn't, now you know it. And knowing it means more work for both of us. It's only natural to ask if we could learn something from the information and avoid late discoveries next time. Optimistically we agree to try to work on it, yet always failing with some details. It's a "I wish I knew when I made that decision" -case.

Now that I've seen a bit of Mob Programming (whole team, one computer), I'm suspecting that the best of our current tester-developer collaboration is just co-creation, not true collaboration.

In Co-Creation, work well together but not really together. You know something, I know something, and we take turns to contribute our things into the end result. Some of this we pair up on, but mostly when we pair, we pair with the likes of us, with similar type of information at hand. We're not witholding any information, we're actively sharing, making anything available. We sit together in the same space, asking is easy - if only we know to ask.

In Collaboration, we don't need to ask as we build on top of each other. Like when we mobbed in my team, someone mentioned in passing looking at the code we were changing the words "one or many", with an instant conclusion that the answer was known: "one". I immediately jumped in correcting it's "many", adding a bit of history of why's to the shared knowledge. And a third person cracks a joke: "That would have been an expensive one to find later". Mostly me in the room makes others say things like "ooh, we need to test that", with a glimpse to my direction looking for acceptance, acknowledgement and approval on the developers being on their perfect behavior of discipline. But there's also these moments when I suggest variation to explore the limits of the box we've set ourselves into: change of browser, different data, different order of doing things, new viewpoints to see the same differently. And I do my share typing for my team, on my turn. 

How could we move from sharing, helping and co-creating in our projects and professional communities into true collaboration, where we remove more of the time and task separation, without removing the specializing that enables each of us to contribute things the others could not by themselves? That's something for me to think about.

Test Early, to not Fail often

It was one of those usual yet unusual meetings. The product ownership team had summoned together a team of versatile experts. There was deep representation of the user base. There was sales and marketing. There was half of the development team, all "disciplines" represented with the project manager, the coding architect, the user interface specialist and the testing specialist. It was labeled "Concept" and little did we know what was coming.

It was a meeting to start something new, perhaps only a year later. It was an early chance of testing. And it taught me how important it is, yet again, to be testing early on.

As the meeting unfolded, I learned that the product we've been creating isn't optimal (easy to sell, hard to find market for) based on a marketing research done on one target market. And that something else would be more optimal. Something we did not have. At all. Something that would land in the same rough business neighborhood but that was not what we had been creating for the past three years.

It wasn't that we were told we had spent three years with features they did not want. There was a strong internal customer too, and they had significant competitive advantage with what we had created. It was great. But the other customers we would dream of did not see it as something they need. And we wanted to learn to create things others wanted too.

Clearly, something failed with how we had been testing our assumptions about the business opportunity. These kinds of failures of testing are in scales more expensive than any other mistakes we could do. The result of late testing can be that we will recreate everything, if we even get a second chance.

These kinds of experiences have made me a big fan of lean startup. The idea that you should test your business model's built in assumptions with smart approaches, going to the real customers and not taking their word for it when their money speaks volumes more to the truth. You can politely say something is interesting, but when you're asked to buy it, your actions will say if you were serious or not. In software, we should sell earlier - a major lesson I've learned over the years.

The same idea that I keep failing with at work in scale and practicing to handle better with suggestions of how we could test our business assumptions applies to my side projects. I'm pretty proud of myself for the agreed action items yesterday, that will dispel some of our illusions. I'm extremely happy to be testing early in great collaboration with people who never tell me that I'm "Just a Tester" because they've seen that testers like me are helpful finding good ideas of how we could know more of what's real and what's illusion

With my side project, the European Testing Conference, I don't want to fail in the same way I do with my work. I want to do what I do for my work: early testing. What we need to test is something others too consider valuable. We believe it is, in the organizer group. We are passionate in our belief that extending the learning we've already had between testers by profession and developers by profession within the organizer group, that will create a great conference. That there should be a space, a conference, in which we bring together the different worlds of developer testing and tester testing, build bridges and co-create cross-functionally.

We're inviting you to test with us. A Super Early Bird ticket I like to call "validate-the-need" ticket is now available for ridiculously low price until Oct 20th. We're creating a great conference that will teach you practical stuff. Will you trust us on that and be there with us?