Wednesday, November 11, 2015

Agile Testing Days 2015: There Are No Agile Testers - There Are Testing Facilitators

I had the opportunity to attend Agile Testing Days 2015 in Potsdam. It's been the second time. And again, there haven been great sessions, inspiring talks, eye-opening chats. But still there is something that bothers me. If you following my blog post you might have noticed the "There Are no Agile Testers" blog posts:


To say the least they have been received a bit controversially. Many testers felt personally offended. I could understand this to some extend. A year has passed since then and the idea circulated in my thoughts. I was trying to understand what really bothers me about the agile tester thing. I'm not sure I'm done with it yet. But new aspects revealed themselves. 

The thing that bothers me the most is the fact that by just bringing testers to agile teams does not solve the issues we've had with the development and QA departments. Testing still comes last in the development cycles and tends to be skipped or blamed for being a bottleneck. This is nothing I made up, but something that has been said by testers at the conference. In a way the testers in agile teams establish a silo just as the developers do. Developers rely on testers to get quality into the product and complain if testers do not manage to handle the amount of user stories done for coding stories tends to be faster then thoroughly testing them.

Over the years I became more and more opposed to silo thinking in teams. This discomfort still grows. I try to find ways that could help to overcome this dangerous tendency. My experience from many years shows that whenever a teams starts to separate into silos team performance, quality, and outcome drop dramatically. The teams start to dissolve and I've even seen teams to dissect.

A second aspect that I grow ever more uncomfortable with is the fact how developers are pictured as guys not willing to test, not willing to care for customer needs, not willing to care for quality. A great many developers may fit this description. But another great many developers care for concepts like Continuous Delivery, Lean Startup and DevOps. Both of them are heavily relying on being responsible and accountable for ones quality. Developers show that they are willing to produce stable, high quality code that covers actual customer needs. That they are willing to measure customer acceptance and to act accordingly. That they are willing to ship to production as often as possible. I reckon (a new generation of) developers understand(s) pretty well that they are no longer sitting in the basement coding all day long without ever bothering themselves with any consequences their work might have for the world around them.

For quite some time now developers proved to be no good at testing. Whether they are just testing agnostics, arrogant my-code-will-not-break guys or anything you might think they are doesn't count. Testing did not take place in a way and amount that would have been desirable. Because of that QA people had to be hired to clean up the mess they left behind. But no one bothered to tackle the root cause: Improving quality of the code from line one. This would have meant one has to deal wit these strange guys in the basement. So, an opportunity has been missed. The mere existence of a QA department that made up for the mistakes developers made encouraged them to code even more carelessly. There simply has been no need to do otherwise.

It is time to reverse this development. Now, as developers develop a sense of responsibility testers are urgently needed to share their knowledge and experience gained over so many years of testing. This knowledge has to be shared with developers. Testers are urgently needed to challenge developers to take testing beyond unit testing seriously. There is far more to testing than that as one could learn form "Agile Testing" by Janet Gregory and Lisa Crispin. 

Me, being a developer for most of my professional life, I would wish if not expect from testers that they make testing an integral part of a developers daily business. Testers in agile teams have to become test facilitators. There is no way around that. If an agile team would be staffed with as many testers as you would need to make sure all user stories are covered with acceptance tests, all new code is covered by unit and component tests, all security, usability, performance and you name it what test are required up to thorough exploratory testing one could easily end up with maybe 3 (or more?) testers per developer. Would this be the way you would like to go?

In my humble and honest opinion we would need to tackle the problem from two sides.

1. Testers Coach Developers


Testers gained insights on lots of different aspects of testing including experience of typical hot spots especially when it comes to integration testing. Testers would need to pair with developers to support them when writing these kinds of tests figuring out what test cases are needed and how to best test them. It may be that while doing so testers become familiar with development itself and eventually cease calling themselves a tester. I would consider this a great achievement for our industry when testers did their coaching job that well that developers are able to do the necessary testing and former testers turn to writing code themselves. In a way we would have to call them all Agile Engineers. Then Continuous Delivery and DevOps would fully unfold their potential.

2. Testers Provide Automation Frameworks


Not all testers would like to turn to bare development. I would propose another direction for them. Many developers do not care for security or performance testing because there are no frameworks and no infrastructure available that would perform these tests reliably and easy to write and evaluate. Any of these frameworks needs to be made available in build and test pipelines. If they are not available that way they will hardly be done. Developers need to be urged into writing  these kinds of tests by making this unavoidably easy. Whether or not these frameworks have to implemented from scratch or could be bought. Someone has to set them up for use in pipelines. Someone has to educate developers of how to utilize them.

3. Testers as Integrators


Developers tend to be off by one, so am I. There is a third category of testers. The ones that never ever wrote a line of code and are not fond of doing so at all. There are businesses that have to fulfill legal requirements with respect to quality assurance. There businesses that built huge products with millions lines of code contributed by teams not at all co-located to each other and often enough not well connected. Products like that tend to have integration issues and no one feeling responsible for them. These are areas testers in a more classical sense still would be needed without the urge to turn into developers.

Conclusion


Testers in agile teams should try to see themselves as coaches and facilitators to spread the art of testing. Developers need to be educated and enabled to do lots of testing on their own while and before writing any code. Developers need to learn to look at what they do from a users side in order to enable them to decide in favor of a users needs.

Testers could provide frameworks for automated security, performance, product life-cycle testing and alike. These frameworks have to be made available to developers in their daily work to make these kinds of testing an integral part of coding well before a user story is labeled DONE.


The tasks testers will face in the future might change. For some this change may even be dramatic. But I think we could not afford moving on as we did before. It is time for Developers 2.0






Read also:
On Coaching Agile - What I've learned from being an agile coach
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

Thursday, September 24, 2015

On Coaching Agile: A Matter of Gray - Don't let prejudice guide you

Just recently I was receiving a mail containing a quote which went like this:

"I get paid for features not for tests"

It has been put in a context where we were discussing something like code coverage or test coverage issues. That's the setting. What happened next?

To me this quote in this very moment and this very context has been proof that there something was totally wrong. Based on this quote we would not need to talk about application of agile methodologies with these guys any longer for they are not prepared for it. And I went off into my standard narrative about ignorant developers and ignorant management, that most of the time were complaining about what went wrong and that everything would have to change but no one would ever start doing anything least did they question themselves. And on and on it went.

"I told them many times and they just don't understand. They just ignore the evidence", is what I could tell myself over and over again.

That very same day while taking a shower in the evening it struck me: What did I know about the quote?

Well basically nothing! Who did say this? I don't know. What has been the context it has been said in? I don't know. Was there anything else that has been said to put this into relation? I don't know. How was it said? Angry? Regretfully? Complainingly? Resignedly? Ironically? I don't know! Anything? I JUST DON'T KNOW!

What I did know, it felt perfect to me. I could be the good guy knowing about all the "right" stuff, doing all the "right" stuff - well most of the time. And they (as anonymous as could be), they are the guys doing it wrong. Again. And over and over again. With that two things are for sure:
1. My work as an agile coach would never ever come to an end, and
2. I would always be the good guy. I could always feel superior to "them"

A question arises here: Could I really be a coach to "them" when I consider myself superior? Would I ever be able to bring my message across? Would I really like to bring my message across to help "them" get better?

To be honest the answers would be something like: I don't think so. No. To some extend, yes.

At least in retrospective I would need to admit that "being better than them" gave me a feeling of comfort, a feeling of importance, somehow even a feeling of doing the right thing which supports me in trying to move on despite the little impact one achieves from time to time. So, in a way this attitude supported my will to strive for a change.

Thinking about this I figured that I would have to deal differently with the quote. First of all. Listen. In this case I wasn't able to listen for I've got this second hand. So it would have been asking. Asking all that questions to fill in the obvious gaps, to understand what the speaker really wanted to say. Only then I would have been able to build an opinion about that. Only then I would be able to decide on which steps to go the mitigate a possible issue that could have been meant by saying what has been said. - You see, all purely conjunctive.

What did I learn from this?

Instead of speculating about the manifold of possible reasons one should try to get a hold on the real reason. If you can't just let it go.
Do not exploit a quote to make a point. You could try to do this with the very person the quote came from. You would be spoiled right away. Nothing could reestablish the lost trust.
Do not preach your solutions. Try to understand the issues your coachees have and help them solving them no matter whether your prepared solutions or methodologies could be applied or not.
Don't exaggerate your position. You are not the guy anyone is supposed to follow, the guy that knows. You are the servant. You should do what many blogs, articles and books tell about coaches:

You are a facilitator, enabler, mentor, partner whatever the coachee needs at this very point.

After all the most important thing you have to be is being

humble.



Read also:

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

Tuesday, August 11, 2015

Agile Methodology Breast Feeding

How come that many of us developers are struggling with agile methodologies like test-driven development or componentization/modularization of a software?

I was asking myself this for a long time now. Being an agile coach I frequently see developers fail applying these techniques in their daily work. Intelligent people that are able to write code to take care of the most complex problems around. And yet an apparently simple technique like write-your-test-first doesn't get a grip with them. Why? 

In the past I tended to blame the workload and pressure of management and the urgent need to put out the next feature and QA it afterwards that somehow caves in the people into this treadmill of assembly-line work like feature production. In this treadmill they are not able to get the time or freedom or even will to learn something new, to question what they are doing, or how they could do better.

It's easier to just do what one has always been doing for this they would know, this would require less efforts and less energy. Change on the other hand comes with inconvenience, with insecurity, with the need to work more consciously which slows down compared to working with a routine.

So, changing the approach developers use to get their things done becomes a long hard process. Sometimes it feels like a behavior therapy with me being the therapist. 

But I get carried away - a bit.

Just recently I came up with another source of evil, though: Textbooks!

I was curious about JavaScript and node.js recently. What would you do to get a concise guidance on any new language? Well, me I would buy a good book and work through it - or google a good tutorial on the web or something.

This time though I wanted something else. For me being an agile coach I wanted to do what I am preaching. Do TDD right from the start. So I skimmed through the pages and in the index I found "Testing" at page 10-something. Wow! I thought. There is something about testing and it's quite early in the book.Promising! 

Well. what a disappointment. It simply suggested to create an index.html file where the JavaScript would be written to or linked and to open this in a browser to witness the effects of my changes.

That's all to it.

After this the whole thing was like every time: Gradually introduce the language and write some code to learn it.

That way I learned some other languages as well. It never ever crossed my mind that I should write some tests first. Instead I wrote a few tests afterwards. Just like the others did. Fine!

No!

Thousands of young people learned their first programming language that way. They did not learn about testing. They got the notion that programming meant just writing code that accomplished the task at hand. Then they would discover that there are bugs in what they wrote and they learned how to debug even nasty code. Some of them are rather skillful debuggers and learn about seldom used features of their tools. They feel like the best programmers around for they would nail down even the strangest bugs. Bug fixed. Fine. No test needed. The bug has gone, hasn't it?

I've seen many of these guys entering corporate software development where they would move along their way and would just hack on a bigger scale. 

Try to tell these people that there are other ways of doing it. They imbibed programming with no testing from their infancy. It's hard to change something about it. They would lack the awareness of potential problems with that approach.

I'd plead for a new style of textbooks. 

It came to my mind that the textbook I would like to read (or even write for that matter) would be different. I would like to introduce a language TDD style. Explaining testing first. Why not writing a HelloWorldTest first? It's a program as well, isn't it? It's a minor change of perspective but a huge change in mind. 

Tell you what, while thinking about this idea I stumbled across this book on node.js:
http://leanpub.com/nodecraftsman by Manuel Kiessling.

To my big surprise it did exactly what I would like to do: it started introducing node.js with TDD. Thanks for providing this enlightened little book!



Read also:

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