Monday, June 30, 2014

Learning to code - just learning

I'm reading Cem Kaner's book on Domain testing. Having skimmed though a lot of it, I started again and got stuck with ideas from start of intro.

"Testing is a cognitively complex activity. Developing competence with cognitively complex skills requires mastery of routine tasks and formation of schemas (cognitive maps) that can guide you as you do tasks that require more conscious effort (van Merrienboer, 1997)"

I've dedicated much of my adult life to building these skills and building networks that help me develop these skills. Right now, on my summer vacation I'm putting 20 hours a week for four weeks to a course that teaches one out of hundreds testing techniques - thinking tools. I absolutely love the BBST Domain testing course so far.

Testing is cognitively complex activity. So is coding. But they are different cognitive activities. When I do things, I want to be good - excellent even. With all the effort that learning testing takes, where to find time that coding takes?

The question on my part is really rhetorical. I was forced to take coding classes as part of my MSc studies for computer science. I could do them, but I never felt the urge to do it again or do more of it. Looking back, I wasn't into the things we were supposed to implement and I never felt the same overwhelming feeling of success in a brain-engaged activity that I get with testing, again and again. Recently, I've been giving coding a second chance and with the control of choices learned in testing, it's definitely more fun. But I still don't get the feeling of success that would drive me to depths that testing has.

Creating an algorithm that handles things smartly is somewhat of a boost. But I do that for testing too, to build ideas of what's possible and expectable. I just skip implementing and debugging the idea if I test. I love thinking about the problem and solution, but I lose interest snd have to force myself to complete the details on different layers of logic - the routine tasks of coding. It comforts me a little that I learn while doing, that I see ugly code that just cries to be refactored. That I get reminded that coding is just as much exploration as testing. But it still doesn't give me the feeling that THIS I want, this feeling is totally worth all the effort. It does for some, and I respect their love of code highly. I just feel different.

A lot of the cognitive load on learning coding is like the stuff we now do on the domain testing course. Learning routine ways of doing things that repeat, to free our minds to the non-routine aspects of our work. I notice my routine with coding is off, I need to rely on guides (intellisense) to come up with syntax and I google like crazy to decide what library would already have something useful for my purpose. I don't remember since with choices of time, my practice of coding just isn't on the level I'd like it to be.

With all this, I find the 'testers should code' 'why would a tester not learn to code' a generally upsetting theme. Why should I want to be a mediocre coder when I can be a brilliant tester? Or why should I give up my aims of excellence in testing to learn coding to a level I consider professional?

On my team, most developers suck at testing. I know from a personal experience that the 'can't break own stuff' is mostly just an excuse to avoid work they don't love. As I ask developers to test more, I offer to implement more. Neither gets the things that would make us fully happy, for supposingly greater good.

I just keep wondering if this trend is really smart at all. Let testers learn coding but let them also be non-coders. This direction of emphasis would lead to driving away more good testers. You don't know what you're missing since those who think this is a smart move never paid attention to what the 'business people' do. It's not coding, so it's probably 'less valuable' - as one of my developers put it.

Coding is great. Testing is great. Finding idea-solution-product-market fit and buy-in is great. We need respect for diversity and collaboration more than super-individuals that have these all.

Let my colleagues in test not learn code in peace. Like James Bach said in twitter: not everyone wants kids. Choices and preferences should ne respected, not continuously feeling attacked. If coding is in demand, who should learn and change: those filling the demand (testers who code) or those (mis)identifying the demand (recruiting managers)?

Surely recruiting managers can go ahead and recruit for skills they need. But it just might be that emphasizing one they lose out on what they really need. But since they don't have it, they might not realize to miss it.


Thursday, June 26, 2014

Continuous delivery without test automation, first experiences

It's been a few months since I managed to get my favorite team at work talked away from Scrum and story points into a Kanban-like continuous delivery of an item at a time. There's a long way to go, but first two months are a good point of looking back at some of the things that happened.

Giving up on size estimates

The driver behind the change for us was the frustration with size estimates: story points and hours alike. We observed that the size did not really matter for us, and the ritual of sizing things up was draining our energy. In particular, if there were surprises, things to be learned while doing, we easily ended up with unproductive discussions of how the thing was understood when sized up and how it is understood now as 'requirements changed'. If the team understood the problem, solving it was design. If they did not, solving it was requirements. The externalizing was unhealthy and unproductive.

I kind of like the change in discussions this caused. Instead of sizes we talk of when could I help with testing it and where, and if we can split it into two (or more) deliveries that would already bring value to the end users. Not very good at that yet, but we had not done any of that before the change.

Releasing regularly

In an earlier post, I wrote about the feeling of ease with making releases as they are done continuously. It's a routine, not a hassle. While our continuous delivery does not (yet) rely on test automation, we're not as fast as we could be in making a feature release-ready, but we are capable of analyzing our changes  one by one, thinking of likely side effects and testing manually. And isolating a feature at a time makes it much simpler to understand what caused problems. I really loved last Thursday, when the build completely broke with two lines change that was the only thing in the build we were working on towards the release. We jumped right in to solve the surprises that none of us could foresee.

The two months also taught us about releasing regularly through trial and error. As Git and team talking to each other about what we do was new, we had at one point two significant changes put into our integration branch around the same time and as both had a lot to fix (and test again and again) we managed to block our feature release pipeline for a month, making one "traditional" release, very much like the ones we did before. Single piece in the pipeline bottleneck at a time is great, and it also drives us to think about ways of collaborating to make the bottleneck smaller.

Testing in this all

In testing of this style, there's been ups and downs. When we refactored a major area without automated tests and with time of a developer who had not originally created the feature, testing was somewhat painful as functionalities went missing: the code just had not given out a hint of such an intent being embedded in the old version. I relied a lot on my memory, tested areas I knew like I've never seen them before and digged through a lot of old Jira issues mentioning piece here and there. The specification existed, but was useless on the level of detail that was relevant this time. It was also painful to test the same connected features again and again and again, as a change would easily have impacts elsewhere. It was clear that the model / design of the features wasn't clear, but got clearer.

The good part with this was that some of the lessons learned ended up in automated unit tests. But still not enough. And it drove my focus again towards extending our test automation capabilities together with the team.

While you can do continuous delivery without test automation, you might not enjoy it was a lesson worth experiencing for me.

Back to usual

In the last two weeks, we've been doing releases 2-3 times a week. It's nice and routine again. The developing and testing isn't routine, but making the release is - just as it should be. Releasing more often has also revealed some issues in production that we can honestly say that we would not have thought of to test manually / automate. Fixing them has been quick and routine, and the general build quality in releases has not lead anyone to question the idea of releasing more often. I hope we stay that way.

Single-piece flow will still take us a lot of effort, but some nice agreements on how we organize towards that have already been made. I look forward to starting our pair programming trials in autumn, and working out ways to move from working solo on a task to working as team on a value item. The potential is there, while road will most likely be long and winding. 

Saturday, June 7, 2014

A story of a big small bug

This week, after a day at conference and a day home with a sick kid, I got back at the office to test. As I opened Jira and got reminded of recent fixes, I chose an area that I found relevant to start from. The changes were quite extensive as the developer had spent several days puzzled with them. 

I opened the application and clicked though the shortest possible sunny day scenario and the application froze. I could't believe it, so I restarted and it was true. I felt upset. I felt disappointed. I felt that with all the efforts to improve on team responsibility, it just gets worse. I was thinking that perhaps the best way to help my team mates feel responsible would be just to remove me as the safety net - except that did not work either. So I talked with the devs to let them know it doesn't work and blocks me, logged it on Jira and steamed out the worst of frustration in a tweet. 

Then I tested some more, to learn that the first feature I was testing was just a tip of the iceberg. Out of the features I tried, there was one that worked and many that didn't. I realized the problem wasn't with the changes to area I was testing at first, but with common dialog component. As we're a tight team, I realized the issue would belong to another developer, the one with the faulty change. So I reassigned the jira issue. 

At this point, I was even more upset. There was a problem making our application freeze on all actions but the one the change was done for. Not only had the developer making the change skipped testing any other places when changing our dialog component, but he had done the change paired up with another who did the same. And none of the six had used the app in over two days to notice. 

Soon after, there was a quick and dirty fix - by the words of the developer. The final fix would take a little longer. But I was told they're both small fixes, and wouldn't need much testing after. A little later I also learned that a developer had seen the problem, but forgot to mention it to others. At least there was hope, as the whole team wasn't completely hands off the application. Mistakes happen. 

This incident reminded me again about the difference in how I think as a tester and how developers think. When I see a problem, I look into its severity and implications to users. When developers see the  same problem, they look at how interesting or complicated it is to fix. And size of symptoms may be completely unrelated with the size of the fix. 

With the discussions on smallness of the fix, I was left feeling unappreciated. It was a small fix, small effort for the developer. But it wasted a day of my time. How about including my time in sizing up the implications in the team? It would have kept small if there was at least a bit of own testing by the developer before the feature showed up in the common build. Or after. But before it blocked all of my other testing. 

Also, the fix wasn't small to me as I was going through all features in the program for other surprising impacts. While knowing the fix it was unlikely, it was still a possibility. Again some hours of work the developers refuse to take ownership of as it shouldn't have an impact. 

So, negotiating on more test automation ahead. Even if the developers dislike maintaining it. 







Thursday, June 5, 2014

Agile Finland in a year - my individual view

Agile Finland non-profit had the annual meeting yesterday. From a personal perspective, I feel there's again an inspiring twist that could not quite be foreseen, just like last year. Last year the twist was that I showed up and volunteered at the meeting, just moments before the executive committee selection. That works great to get a lot of votes. This year I had been driving the formation of the new executive committee, people could have expected I volunteer to be the chairman and that I would at least be available as executive committee member. It turned out I was not. With the active recruiting of new executive committee members being so successful, we had more people than could fit in, and I made room by not making myself available officially. Unofficially, I'm as available as ever and believe that Agile Finland has come to a point in which I or anyone else no longer needs to be "in" to be included actively. So I will be hanging out with  the executive committee without being a member.

In Annual Fannual, Agile Finland did not show a "plan of action" for the upcoming season. Some participants made a comments on this, justifiably. Would be nice to know what will happen next year - still would be. I find personally that it's very hard to make a plan for a group of people that has not yet been selected, but we could have done a little better just making the community members individual commitments visible. Because, that's what we have, a community of volunteers that do things if they feel they want to - we cannot really drive things by deciding something will be done, unless the individuals choose to see those suggested priorities as their priorities. I find it unlikely that we would be "following a backlog", but it's more about seeing where individuals' energies lead us - together.

Now that I'm  not in the board, I'm more free than ever to tell where Agile Finland should be heading. That's what this post is about. And I suggest other individuals will create their own views, publish them and we discuss - perhaps getting a common view that we can then better communicate back to the community.

If things go as I'd like them to go, Agile Finland in a year:

1) Runs three significant conferences: Tampere Goes Agile 2014 in autumn, Scan Agile 2015 in Spring and an unconference-type of a conference with a name not yet known. Since I have a great group around Tampere Goes Agile, Vasco Duarte has his heart set on Scan Agile and Aki Salmi is already actively thinking about an unconference, this is very likely thing to happen.

2) Runs seminar/event -series in major cities: Oulu, Tampere ... perhaps Turku too?
Oulu will see a full-day agile/cloud -seminar as collaboration of Agile Finland and EIT ICT Labs, and Agile Finland is already preparing schedule for an agile sauna late in the year in the Oulu region. Testing cell is also live and kicking in Oulu, there's one session on Security Testing in June (identified as testausOSY event) and a practice oriented session siding the Oulu Agile Seminar. I will also make sure we get one more session for the springtime 2015 in Oulu.

Tampere will have Tampere Goes Agile, but it also has a very lively Coaching circle going on - ask Eveliina Vuolli more on that one. Testing cell is also active in the area, with an event in planning for 4.9 - around a meeting of Tampere Goes Agile organizers. My intention is to get TGA organizing to a level where there would be again local leadership with good support from Agile Finland so that new volunteers for making it happen would have things set up for a good start of TGA 2015.

3) Runs events that are not location-based. Yes, webinars. I want to see us experiment on these and see where the experiment takes us. What drives me to this is that I want to practice delivering webinars, and while doing what I want to do (learn), I'm very happy to help others with that as well. I would want to see a mix of English and Finnish presentations, and perhaps this could also be a way of showing the great stuff we have in Finland outside Finland - when the language is English.

4) Owns a for-profit (company). This may be surprising to some, but very much something I'm driving towards. Agile Finland would want to organize stuff that is real business, not just "non-profit". Real business in the sense that it advances the goals of the non-profit to have absolutely brilliant selection of courses available that are not available in Finland, in all major cities as of now. The for-profit part of non-profits should be set in a company that is fully owned by Agile Finland. The company would pay taxes like all good companies do - non-profits don't exist to go around taxes, but to advance things that companies don't and to create opportunities for us all - individuals and companies in the community.  If my dream world would become real, this would employ someone as a ceo and/or event organizer and pay actual salary. And enable individuals to use the organizing services paid for to make their ideas for the community a reality easier!

5) Has several well-run cells, where some are local and some are built around themes. The context driven non-profit we set up can be seen as a testing cell, since there's so much in common. And we learn better ways to work in these small units of cells, allowing autonomy and support from Agile Finland.

6) Has run a pilot with my local elementary school on a computer club for kids that emphasizes the diverse viewpoints into creating software, not just learning to program. I hope to make people see that making software is fun and really relevant, but that the core of it is in ideas and collaboration. And that there's nothing wrong with girls/boys coding, not coding, whatever but not remaining distant from such an important trend. Create, not just consume. I also hope to deliver a few evening / weekend things within Agile Finland, as I've already talked to many mom's of smart kids who would like to contribute themselves too. There's no official say that Agile Finland will support me on this or identify it as something Agile Finland does, but I will do my pilot with the local school anyway.

7) Has established first connections for professionals to volunteer as speakers on agile / craftmanship themes of various sorts for vocational schools and universities in Finland. We need to make the teachers life in finding great case presenters and inspiring speakers just a little easier. On testing and on other topics. 

8) Collaborates with major student non-profit organizations in IT-area, at least in Helsinki and Tampere. At least the one that I find my non-profit home - Tietokilta, Data Processing Guild. Students bring such energy to organizing our conferences if they are in as full members organizing, I think that is a key to why Turku Agile Day is so great. 

9) Runs a regular coding-oriented cell where we can practice our craft from that angle. Make sure agile does not turn into facilitators and customers silo, but keep the core of development included as well. A friend of mine noted, that Agile used to be the only crowd that encouraged developers to grow in their skills and see the world differently, practice coding. I would hate to see that go away, even if I'd love to see us emphasize the other existing communities in that area. I know there's great activity for security and for devops stuff, and there must be more than I'm aware of.

10) Solves the financial puzzle in such a way that there's enough money to always say yes to events that attract people and bring them together without enforcing "find sponsors" rule. I want to see that we can help with the sponsors so that people could focus on brilliant contents and sharing their lessons learned. There's ways of financing that are tied together with my point number 4. But there's also the idea of corporate membership that I would like to see prepared for action by next Annual Fannual.


11) Runs regular commercial top-notch trainers courses in Finland, on different locations with both international and local teachers. Gets known as a channel to good stuff, and in particular creates good stuff the companies don't yet create. And in particular, on locations other than Helsinki.

Note that my view of Agile Finland does not have the most common aspect of "selling agile to people who don't yet get it". I want to see us focus on being so excellent in every other way that people will get drawn in. Create pull, not push. And I think the stuff Karoliina Luoto and Marika Leeds facilitate on Agile Ownership stream is a great example of that power.

Now that I've shared my ideas, I hope it enables people to talk about where we agree and disagree. And perhaps, help me clarify and change my ideas so that we build an ecosystem of agile, that makes companies extinct that make testing awful by leaving it to the end, under impossible circumstances.  I think Agile ideas are the best thing that ever happened to testing. Agile managed to deliver messages on illusion of speed, fixing loads of bugs creating more that testers have tried to say for ages with less success. And it creates a need for smart and fun exploratory testing, where you are actually required to do more than execute checks - you explore the product in ways where "before implementation" and "after implementation" get mixed up in short cycles. So, there's always a testing idea in there for me.