Monday, November 17, 2014

Agile Testing Days 2014: There are no Agile Testers

Fortunately I had the opportunity to attend the Agile Testing Days 2014 in Potsdam, Germany. It has been a great conference. I got so many new ideas out of it. It was very well organized and there were passionate and well chosen speakers around. I regret to only have booked the first and third day, especially for they built a car in the hotel lobby on day two. And I missed that one.

To give you a little background on myself. I'm not a tester. Never have been. Agile or not. Most of my career I've been a developer working on a wide range of topics in very small and very big teams. I have done my fair share of UI development both web and RCP. I have done server development and even system development. So I've seen many things between a slick UI and moving around single bits. What I haven't seen all the time was an agile tester. I barely ran into a tester, old school that is. Nowadays I'm involved with shipping a product of round about 2 million lines of code and coaching agile teams. So, maybe I'm a little bit biased here. But now you know. Just in case.

The whole conference has been arranged around the topic agile testers between past and future. Already the opening keynote of Lisa Crispin and Janet Gregory set the tone to what then was yet to come. To me it seems agile testers experiencing a phase of self-discovery these days. On talks gave insight to the live of a tester in a development team who out of a sudden got supported by a developer to get his testing done (Kristoffer Nordström). Another workshop tried to introduce tools that could help a tester to develop a proper testing strategy and to cover the cube of testing opportunities by identifying what he has to actually test. A major part of this workshop put emphasis on the means to obtain information about the application (Huib Schoots). The talk by Alan Parkinson explained how pull request could be used to communicate with developers and how to make sure only tested code gets into the trunk. These talks very much based in the notion that testers and developers are not really working together, that developers throw their stuff over the wall and testers have to cope with what they have implemented. At least that is how I understood what has been told.

And then there has been the third day opening keynote by Anthony Marcano with the title "Don't put me in the box". He was ventilating the idea that agile tester would be no title or job description but an activity one would do for some time. To me this would be the key idea for the future for testers, agile or not.

I've been around in this industry for over 25 years now. The longer I'm into it the more I lack the understanding what a tester would be good for. Or to put it another way around. I lack the understanding why there should be people called testers that would have the obligation to check the work others (developers) have done a little while ago. I'm very well aware of the fact that testing as an activity probably would be the most important task in software development. As an activity.

In my opinion there is no such thing like an Agile Tester when we assume this to be a person. To me agile means fast feedback and early as well as frequent adaptation to what ever needs to be adapted to. The instance of a tester that would consume whatever a developer has programmed only manifests the old fashioned way of waterfall like setups with late feedback and little adaptation. And it doesn't really matter whether the tester would be part of an agile team or not. As long as he is supposed to test after the implementation work has been done he could as well be half a world away. Well communication would be a little easier when he sits right next to the coders.

The major shift the agile tester has to go through would be the change from being a job title to becoming a role one could take on for some time up to its extreme in TDD where it would become a hat which has to switched often with other hats. In times of XP and TDD and all that stuff we would talk about agile testing instead. Agile testing would be any activity from TDD to ATDD or whatever testing happens while implementing.

And what happens to the people? The real existing agile testers? I understand that this change brings about uncertainty and there are a lot of people who ask themselves how to deal with this situation, how to move on. I've seen operations guys turning into devops applying TDD to writing chef recipes. I've seen operation guys moving from writing scripts into developing a build and test infrastructure in an agile team applying XP methodologies. They brought there special knowledge and they moved on. I'm sure same would be possible for agile testers. They do have valuable skills, unique skills that any team of developers would highly appreciate to have around. Agile testers could bring their knowledge to the developers while they bring their unique knowledge to the former testers. Anyone could draw something out of it. Testers would start to take part in the implementation and developers learn how to test early, frequently and automated. Finished user stories would be delivered in high quality in the first place. No need for subsequent QA anymore.

Okay. This might be to bold to claim. To be honest, there are testing activities that would require special knowledge not available for everyone. Think of usability testing or user acceptance testing where there is much more need to be able to deal with people to guide them through the process. These (and some others) are high value manual tests. These tests are not stupid repetition work like scripted manual testing would be. They are interesting an challenging. A work for specialists. Any other testing especially any testing that could be automated or which would be supported by a tool should, or shall I say: must, be done close to the implementation work to make sure to get early feedback. Only in such setups it would be possible to fix bugs as early and cheap as possible, to change architecture as long as one still has the knowledge about it.

To wrap it up. Although there are some testing tasks that would require specialists to get completed most of the testing would be work a developer could learn and has to learn when he is a member of an agile team with the assumption that agile teams incorporate some or many techniques of XP. Agile testing would be the testing work that would be done while implementing a user story. Agile testers would merge into these agile teams. Their job title would become a role or even better an activity. They themselves would move on to become one more guy to get user stories done. They would bring their unique strengths and capabilities to the teams. They would teach former developers how to test efficiently and they would learn how to code.

Once I've been a member of a real agile team. Anyone in this team would code and do TDD as well as any other testing that was required. Anyone would touch the build scripts or would build stuff to get automation done. Anyone was sharing the same idea: We as a team make something happen. We take on any activity needed to get our work done. That has been a great time. Probably the best, the most inspiring I've ever had. If I would imagine the future of our industry this would it be.




Read also:

On Sporadics - How to deal with intermittent tests in continuous delivery
Part 1 Part 2 Part 3 Part 4 Part 5 Part 6 Part 7

The opinions expressed in this blog are my own views and not those of SAP

Friday, November 14, 2014

On Coaching Agile: Techniques - Make a Bold Statement

In coaching agile methodology or coaching in general making people to leave their comfort zone or pushing them out of it would be key to get your message across, to bring about a change. You want to make them think, open up their minds to the new concepts and ideas. There are several techniques to achieve this. Last time I was talking about the power of a simple question: What do you want to test?

This time I want to focus on another technique I use a lot: Make a bold and simplified statement.

What do I have in mind by that? Well a bold statement would be something that stands middle of the road, massive, hard to get around, a bit provocative too. You have to deal with it when it happens on your way. There is no way of slipping through unnoticed.

When coaching you want to make the people that attend the training or that you coach on the job understand what you have to say. I guess it is a common observation that people that attend a training at some point or the other tend to drop out of it for different reasons. So every now and then it is required to retain their attention, distracting them from whatever they would do at this very point in time. Making a bold statement or repeating it could do the job very well. Here are some examples of what I have in mind: J.B. Rainsberger claims Integration Tests are Scam and David Heinemeier Hansson declared TDD is dead. Long live testing.

One I would use very often would be: "There have to be unit tests". Well, sure it is not as bold as the two prominent examples above. It was meant for a different audience. But what they share, all of them are catchy and promise a message that would make people listen. Either for they think they would agree or not. But whether or not a statement will be received as bold or even disruptive or not very much depends on the context. In a context where there are only a small number of unit tests around but a huge number of long running UI click tests a simple statement like "There have to be unit tests" could be a really bold statement that would get a lot of attention, positive and negative of course. Tell you what, it really did.

If the bold statement you are about to use works or not depends on how well it fits the context you would like to use it in. It is supposed to put emphasis on a hot topic or a pain point the trainees experience in their daily work so they are able to relate themselves to it. It should be simple and rather short to be remembered. It should wrap up a message you want the trainees to understand. And of course there has to be a message in the first place and you should be able to explain it at every length at every time. As coaches we are not supposed to resemble the yellow press - just punchlines and nothing else. A good punchline helps but there has to be more to it.

The statement "There has to be unit tests" clearly is short and one could remember it quite well. But it clearly has an offensive touch to it when presented to a team that works on a code base that is so highly interwoven that it is not at all unit testable just like that. In order to bring in unit tests there have to be major refactorings prior to it. It simplifies the message, which would be to incorporate a test portfolio that resembles the testing pyramid we all know. So, what it definitely does not say and not even mention is that integration tests would be forbidden for all times. But it has been received like that and there were huge discussions following along. To be honest that has been the best that could possibly happen. Out of a sudden I've got all peoples attention. Most of them were disagreeing. But finally I was able to make my point.

Suppose you do have a message, sure you have. You wouldn't be coaching if you wouldn't have any, would you? So, you've got your message. And now? When coming up with your punchline be cautious to make it bold enough otherwise it would go unnoticed. You would not get the attention you want to get. You would not get people out of their comfort zone at all. If it is too bold, on the other hand, it either will be noticed but it does not grab hold in peoples minds for they do not relate to it. Or they will feel really offended which would spoil you as a coach.

There is one side effect I should mention here. A bold statement tends to become a synonym for you. It is like there is a sticky note on your forehead with this statement written to it. You will be cited and you will be misunderstood. People take the statement and try to turn it against you. You have to stand it. You have to preach over and over again. Repeating the message all over again.


A checklist to summarize:

Pro:
  • distracts people
  • makes you get peoples attention
  • wraps up your message in a memorable little piece
  • annoys and breaks indifference
Con:
  • needs the right tuning for the audience you would like to address
  • easy to be misunderstood
  • could be offensive and repulsive

Read also:
On Sporadics - How to deal with intermittent tests in continuous delivery


The opinions expressed in this blog are my own views and not those of SAP