I started enthusiastically on January 2nd by following up on a post about the “Follow the link exercise” by Jeff Lucas. In short the exercise is to choose a blog post of your liking. You start reading it critically and then follow every link mentioned in the post. You then pursue this with every post that you read in a one hour session.

In my session, that actually lasted two hours, among others I followed up on a link to Alan Page’s blog “Tooth of the Weasel”. This post contained an overview of posts Alan wrote in 2011 so there were enough links in there to follow-up:
• My job as a Tester
• What is Testing?
• Test Design for Automation
• Numberz Challenge
• Beyond Regression Tests
• R-E-S-P-E-C-T
• Judgment in Testing
• Lost in the weeds

Although I had heard about Alan Page I was not yet familiar with his work. It pleasantly surprised me with some useful ideas and even some advice for my personal goals for this year. Let me give you some quotes I found interesting:

“What you do or don’t define as testing may differ per context.”

Automated testing “starts the same as always. Design your test first then automate where eligible. Coded tests do not replace, but enhance human tests.”

“Do not only use automated testing for regression. Vary the data, the sequence, randomize, to find new information” data driven testing

“Are testers’ second class citizens? NO. Are they whiners? Yes; Figure out how to get and earn respect!”

My second (larger) series of practice session(s) started with watching the 2011 GTAC keynote by Alberto Savoia with the ominous title “Test is dead”. You can read more about this on the blog post I wrote “Is testing dead?”

My third endeavour entailed reading the hardcopy of the book “Essential Software Testdesign” by Torbjörn Ryber. The E-book is free to download, but I liked the content enough to want to own it. Some warning is in order however. Even the hardcopy has a somewhat annoying number of typos, illogical sentences and even faults. Nevertheless the concepts Ryber discusses are helpful for many a tester.

Early in January the DEWT’s met up again. This time to discuss and prepare the TestNet event about context-driven testing. On January 18, some 150 testers visited the event to watch James M. Bach and Michael Bolton do a one hour introduction on context-driven testing using Go to meet  (which btw. worked brilliantly). After the break the DEWT Zeger van Hese, Ruud Cox, Ray Oei and myself gave a number of lightning talks followed by Q&A. Themes of the talks were “On being context-driven”; “Spin-Off”; “Context-Driven expert”; “Test Plan”.

All in all these activities got me some 20 hours of practice bringing me well en route for the 250 hours of testing practice. But to be honest I am even more of a test nerd. I have spent another 10-15 hours on following Twitter feeds with a peak while participating in a #Testchat lead by Lisa Crispin asking the following questions:
Q1: Have you worked on a “test automation project” that succeeded? What helped it succeed
Q2: What do you think upper management should know about testing? (not limited to automation)
Q3: related some to Q2: How do you keep your testing transparent to others on your team and in the organization?
Q4: Are testers on your team treated with the same respect as programmers?
Q5: sometimes the tester is undone by the process. Documentation outdated leading to looking like lack of knowledge

The last practice activity however was, for me personally, the most engaging, emotional and gratifying one.

In December I contacted Markus Gärtner to ask him for a challenge to see if I was worthy enough to enter the realms of the Miago-Do software school of testing. This actually the first step of the challenge having found a member. Markus offered my “The light saber” challenge. Several times during the challenge I would sent Markus my test investigation results and as many times Markus answered. I used several heuristic approaches, tried to inform the customer based on his needs and eventually offered a solution using personas. Somewhat to my despair Markus’s answers were getting shorter and repetitive and I asked Markus to debrief me.

We organized a one hour Skype session and went on with the challenge discussing results, progress en feelings during the challenge. Eventually we came to the point where Markus would reveal if I was allowed to enter Miagi-Do. The result got me stunned, silent and humbled for a moment… Not only was I a new member I was one of the members to, fully endorsed by other instructors, become a Black-belt.

I can only say again. Thanks guys, I am honoured.

This evening, January 18, I will be on stage during the TestNet theme event about Context-Driven Testing. The evening will start with a duo presentation by James Bach and Michael Bolton followed by a series of short presentations, lightning talks and discussion. In one of those lightning talks I will share a personal experience report. It describes how I changed the way I make test plans. Since most of you will not be able to be there (or might have never heard about TestNet*) I am sharing my experience with you in this post.

Twitter

Even if a lightning talk last only for five minutes it still requires some preparation. So to extra prepare myself I placed my experience into perspective and placed the following message on Twitter:

“ @Arborosa: Question to my tweeps: What items do you put in a test plan?  I’ll put the results on my Blog. (please retweet)”

This resulted in the following responses:

Rob van Steenbergen (@rvansteenbergen)
Scope of testproject, context of product (with mindmap), product risks and qlty attributes and risk approach, planning, who tests, stakeholders, testing tools, explanations abt testing for orgs that are still learning. TP is also promotion material for testing.

Stephan Kämper (@S_2K)
Well, what to put in a plan? A (current) goal of what you’re planning. The major way you’ll follow to reach said goal. A ‘Plan B’. (Known) risks – What’s the risk of following the plan? …the risk of *not* following it? Tools & Techniques? Not sure about these.

Nitin Hatekar (@nhatekar)
Entry and exit criteria for each test phase and specific test approach for each phase. Scope of testing and the estimates for completion of in-scope test efforts. A section for assumptions, risks & blockers as well.

Rik Marselis (@rikmarselis)
For your testplans take IEEE829 (1998) as a starting point. And see tmap.net for templates (And after a reprimand by Huib Schoots to be more serious) Don’t start with making the testplan. First make the outline of the testreport. That’s your deliverable! The testreport outline must be discussed with stakeholders. Then you have startingpoint for your testplan.

Jesper L. Ottosen (@jlottoosen)
Generally answers and descriptions to “how” – to the level required of the context. ie #itdepends

I have to admit that all items in themselves are in some way relevant to testing software. But one can argue the usefulness of some of these items and more so of having these items together in one document.

The latter is best illustrated by a remark my mentor made when after three months, of being a professional tester, I was writing my first Master Test Plan. He said: ”Don’t waste time. Take one of my plans. Ctrl-H the project name, change the stakeholders and check if there is mention of specifics not relevant to your project and change them. All else you can leave the same. So, even if I resisted the idea, like my colleagues I learned to do the drill; fill the template in a copy and paste style. Only occasionally I had a stakeholder question what was in it and disturb from actual testing.

Some five years ago I changed departments and found myself in a place in which I not only was free to use only those elements that I felt were useful, but I could start changing the template and the use of it entirely. But there was resistance both from the testers and the stakeholders. The testers, I think, because some of them now had to think and communicate more and the stakeholders because this broke with the standard process and they too would have to get involved and think more. To break the deadlock I started with an experiment. I filled in the template not only complete but to the letter of the “law”. I ended up with a 36 page document which I immediately send out to all stakeholders with an invitation to meet next week, meantime thoroughly check it and be ready to sign off the document during the meeting.

At the meeting the stakeholders were sitting silently, sighing at the thought of having to go through all the 36 pages. I didn’t do that. Instead I asked how many of them had read the document. With 6 out of 8 I was actually impressed. I then asked  how many of them had reviewed it. Still 4 out of the 6. I then asked who found the document a pleasure to read, who fully understood its content and thought it was of value to the project. As I hoped for all the attendees broke out in commenting the document, its length, its irrelevance, the difficulty of the content etc….

I decided to then pull out the rabbit and said “I agree with you all. I too think it’s basically of no use. There is no point in reviewing it. But we still need to write a test plan. So why don’t you tell me what you actually do want to know about testing your product.”

We spend an hour or so discussion what they wanted to know about testing. Agreed that since we are a financial institution we still have to follow certain rules, regulations and guidelines and that I would deliver a new document the same week.

I ended up writing a document that was still 24 pages long. But now it not only adhered to the documentation standards but of those 24 pages 11 were purely related to testing as way to mitigate risks and provide information about the product for this project and another 4 on testing and test heuristics in general. The original document had no  explanation and only 8 pages related to actual testing.

Conclusion

Approach writing a test plan as you would approach any test activity. Figure out what information your stakeholders need, if there are other things to consider like rules, regulations or standards. Use your personal experience and other references you think useful and then write a plan that suits your model of the context and verify and confirm it with your stakeholders.

Last year, 2011, Alberto Savoia, presented the opening keynote at GTAC with the title “Testing is dead”. Alberto started with an all to recognizable Old Testmentality:

• Top down
  • Thou shalt follow the spec
• Rigid
  • Thou shalt not deviate from the plan
• Distinct roles and responsibilities
  • Developers shalt develop
  • Testers shalt test
  • And never the twain shalt meet
• Do not release until ready
  • Thou shalt not sell wine before it’s time

He concludes this with declaring that in essence the focus is on building it right.

Alberto’s then takes an elaborate detour to arrive at the conclusion that in the New Testmentality the focus is on building the right it. While doing this he comes to the conclusion that success, in the Post Agile era, does not depend on testing or on quality but on building the right it at the highest speed (to get the best realistic marketing edge). And so you do not actually need to test at all. Well…. at least at the start, in the right environment…. I could go on but I think Mark Tomlinson’s blog post says just the right it.

The reactions

Alberto’s keynote and later presentations like James Whittaker’s at EuroSTAR have spawned a load of critical reactions from the testing community. (At least the part that I am following.) Most of them were even downright negative and dismissive. As an example a quote of one of my fellow DEWT’s: ”Ik vind het  ‘Test is Dead’-paradigma in ieder geval tijdloze flauwekul” (in English this translates to “In my opinion the ‘Test is Dead’ paradigm is to be considered timeless nonsense”). I can understand these reactions and based on the stories and without critically thinking over what the paradigm was saying I had a similar mindset.

Requital

In short the ‘Test is dead’ paradigm argues that test will disseminate into two directions. It will either move down to the developers or it will move up to the users. The arguments for the movement down to development are that software in general has gotten better; that there are more possibilities to quickly fix in production, that software is able to self repair; that there are more standards,better software languages and that software is no longer localized but available in the, more stable, cloud. The arguments for moving testing up to the users are that the current testing slows down the development process and that it imitates user behaviour. Since speed has more value than quality and users can do a better job at being users then testers this kind of testing is no longer necessary.

I agree with the observation. It is true that software nowadays is different then the software that was produced when the first major test approaches were established. The shift to web-based software (delivery) and the growing knowledge and acceptance by the public of software updates has changed the playing field. I think a lot of what testers (still) do nowadays can be done by developers as well. Particularly the stuff I heard a fellow tester sigh about during a TestNet event “Come on do I still have to test input fields and buttons on correctness. Why don’t those lazy programmers write unit tests as they are supposed to.”. Oh and yes there are loads of testers that go and sit behind their computer and punch keys as if they were users. But are they really testers…..

I do not agree with the conclusion. When it comes to testing business logic, calculations, multi state or multi integrated programs, security, or usability more and bigger unit tests really do not cut it. Yes they take out the more or less obvious bugs, but still leave the less obvious and unimagined ones mostly untouched. If you want to catch those you need sapient testers who are able to use their investigative skills. Who are able to cooperate with and understand developers, business analysts and users. Testers who adjust their skills and the use of those skills to the context in which they work. Only these kind of tester can smoke out bugs that otherwise would have gotten away and provide information that allows others to make the right decisions. Even Alberto Savoia himself limits his arguments when he says during his keynote that eventually you have to build it right also and that security sensitive, risky or regulated software still needs a testing process.

So is testing dead?

Yes if you mean factory style mindlessly following standards and pre-scripted testing.

No if you mean sapient critical skillful and context-driven testing.

or in other words

Testing is dead, long live testing!

On January 3, 2011 Phil Kirkham posted a question on the Software testing club:

“so if you were to set a target of doing 2 hours practice a week every week this year, how would you spend your 100 hours ?”

Having missed the post initially I read the post as early as the week before Christmas. So I really had not enough time left to get to 100 hours in 2011. After reading the post and comments I felt however that Phil was making a valid point. One should spent time and effort on practicing and in my comment on his post I made the following promise:

“As 2012 is on the brink of starting I will try to put this into practice. As two hours seems a bit low I will spent 5 hours per week on practicing and some extra time on logging and writing short (monthly) posts about it.”

2012

So today is January 1st and I am starting to live up to my promise. Every week of this year, except for the summer holidays, I will try to practice for at least 5 hours and log the things I do. At the end of every month I will write a post sharing my activities, providing short reviews and formulate my insights.

I have started practicing earlier today by reading “Essential Software Test Design” by Torbjörn Ryber. A book that I had downloaded as a PDF before and of which I found after a number of pages and comments from fellow DEWT’s that I wanted to have the hard copy. Later today I will make time to listen to TWiST # 76. I am not yet sure what I will do for the rest of the month, but as said before I will keep you posted.

For now I wish all of you a wonderful, succesful and entertaining 2012 and I hope to meet lots of you in person this year!

I have a concern. We online testers have one thing in common: we care enough about our craft to take the time and read these blogs. That’s all very fine. However most testers, and this is based on my perception not research, most testers do not read blogs, or articles, or books or go to conferences, to workshops or follow a course. Well some of those testers do, but only when they think their (future) employer wants them to. And when they do they go out for a certificate that proofs they did so.

Becoming a tester

Regardless of where we start our carreer, be it in software engineering, on the business side or somewhere else, most testers start out with some kind of introductory test training. In the Netherlands, where I live, most of the time that means you’re getting a TMap, or sometimes an ISTQB training. And my presumption is that you get a similar message on what testing is everywhere:

• Establishing or updating a test plan
• Writing test cases (design; procedures; scripts; situation-action-expected result)
• Define test conditions (functions; features; quality attributes; elements)
• Define exit criteria (generic and specific conditions, agreed with stakeholders, to know when to stop testing)
• Test execution (running a test to produce actual result; test log; defect administration)

But there are likely to be exceptions. For instance at the Florida Institute of Technology where Cem Kaner teaches testing.

Granted neither TMap nor ISTQB limit testing solely to this. For instance TMap starts of by defining testing as: “Activities to determine one or more attributes of a product, process or service” and up to here all goes well, but then they add “according to a specified procedure”. And there is where things start to go wrong. In essence the TMaps of the world hold the key to start you testing software seriously.  But instead of handing you down the knowledge and guide you to gather your own experiences they supply you with fixed roadmaps, procedures, process steps and artifacts. All of which are obviously easy to use for reproduction in a certification exam. And even this still could still be, as these methods so often promote, a good starting point to move on and develop your skills. Unfortunately for most newbies all support and coaching stops once they passed the exam. Sometimes even facing discouragement to look beyond what they have learned.

Non-testers

To make matters worse the continuing stance to make testing a serious profession has brought line managers, project managers, other team roles and customers the message that these procedures, processes and artifacts not only matter, but they are what testing is about. These items (supposedly) show the progress, result and quality of testing being undertaken. Line and process managers find it easy to accept these procedures, processes and artifacts as measurement items as they are similar to what they use themselves according to their standards. So if the measurements show that progress is being made and that all artifacts have been delivered they are pleased with the knowledge that testing is completed. Customers or end users go along in this but face limits in their belief of these measurements as they actually experience the end product. Like testers they are more aware that testing is never really ended and about the actual information about the product and not about testing artifacts.

So?!

New methods and approaches such as agile testing have brought the development roles closer together and have created a better understanding for the need and content of testing to both the team and the stakeholders. Other approaches, like context driven testing, focus more on enhancing the intellectually based craftsmanship of testing, emphasizing the need for effective and efficient communication, the influence of context on all of this and that software development is aimed at solving something. And thus the aim of testing is shifting from checking and finding defects to supplying information about the product. Regardless of this however and inspite of how much I adhere to these approaches I think they have a similar flaw as the traditional approaches. Like TMap or ISTQB neither of them go outside of their testing container enough to change the management and customer perception. They still let management measure testing by the same old standards of counting artifacts and looking at the calendar.

Challenge

I think we as a profession should seek ways of changing the value of testing to our stakeholders. To make them understand that testing is not about the process or procedure by which it is executed nor about its artifacts, but about the information and value to achieve business goals it supplies.

I myself cannot give you a pret-a-porter solution so I challenge you, my peers, to discuss with me if you agree on this vision and if you do to form a new approach for this together. I will gladly facilitate such a discussion and deliver its (intermediate) results to a workshop or conference at some point.

From 14 to 17 November 2011 The Agile Testing Days took place in Potsdam (D). Here is my second impression of my visit there.

Preparation

I am an advocate of being well prepared when going to a conference. This enables me to  make informed choices of which tracks I really want to follow or not. This time I added two additional things to my preparation. First I did a poll on Twitter and LinkedIn. I wanted to know who else would be going to the conference and at what time they would arrive in Potsdam. I myself would be arriving on Sunday and wanted to meet other conference attendees. It always surprises my how well this works. On Sunday I met with Lisa Crispin and went out to have dinner with her and eight other testers, of which four were conference speakers. The second part of the preparation was more pragmatic. I wrote a number of blog posts an agile basics, gave a tutorial and a workshop at TestNet.

Surprise & Tutorial

Monday started with a quick breakfast and registration for the conference at which I got a bag with conference information, some tourist information (incl. a bottle of local beer) and also the program for Testing & Finance. A few months earlier I had entered a proposal for that conference and since I hadn’t gotten a reaction I was curious to see who, if not me, were on the program. To my surprise I found myself having a track at the end of day 1. A brief check learned that they had tried to reach me the day before at my home e-mail address that had not checked since I left home.

The rest of the Monday was filled with a one-day version of Jurgen Appelo’s Management 3.0 course. This course I can only wholeheartedly recommend to both managers and testers alike. Besides the necessary theory, the course also is punctuated with reading tips and practical exercises. My personal take-away from this tutorial is the use of complexity theory and the notion that, despite of the fact that all models are fallible, several weaker models can be as effective and as a strong model, and certainly no better model. I will dig into that at some time soon and combine that with Jerry Weinberg’s books on Systems Thinking.

Some of the highlights of the track days

Keynote by Johanna Rothman – “Agile Testers and test managers”
In the keynote, the changing roles of testers and test managers were discussed. For example, testers will need to cooperate more intensively with developers. Test managers should be leaders in the organization and pursue the following key activities: Monitoring of the project portfolio; Removing organizational obstructions, Create confidential relationships, Leading the hiring process, Increasing the capacity of the organization and finally the Start up communities of practice. I liked the keynote enough to be following her tutorial at the Belgium Testing Days in March 2012.

Track by David Evans – “What testers and developers can learn from each other”
This track showed that testers and developers, while working on the same product, see this with a different perspective. Testers often seem more capable of changing perspective. By being able to do so testers can learn developers that there are different kinds of tests. A good model for showing this is the “Agile Testing Quadrants” as defined by Crispin and Gregory from the book Agile Testing. But I a will keep further description short as you can see the whole presentation on YouTube at, http://skillsmatter.com/podcast/agile-scrum/what-testers-and-developers-can-learn-from-each-other

Track by Rob Lambert – “Do agile testers have wider awareness fields”
This track went in to the need to be aware of your context and to use this awareness to your benefit as a tester. Perhaps it is the process or maybe it is the people? Or is the awareness field of agile testers is not wider at all? Agile testers however seem to display a higher ability to feel, to perceive, to know and to be aware of themselves and the world around them. Traditional testers often seem to have a more limited consciousness in terms of testing, and development roles. Even if it is wider, it is often less versatile than in an agile environment. There is however a distinction between social (situational) awareness and personal awareness. One reason for the difference in perspective among other things, is that the focus of testing in a traditional development environment is narrower than the focus of testing in an agile environment. A greater awareness and a broader focus, often leads to an increase in choices. This allows you to choose one of the possible paths instead of chosing a prescribed path. A greater awareness is also a first step on the path of change. However you can not follow all paths. It is necessary to have sufficient self-knowledge and to know your limits. More on this in this prezo.

Track by Huib Schoots – “So you think you can test”
Huib actually wasn’t on the initial program of the Agile Testing Days. But a few of the presenters were ill and since Huib happened to have his laptop with this presentation on it at the venue he offered to pitch in. The organization graciously  accepted his offer and Huib made his first appearance at an international conference. As the title suggests his talk was on what makes a good tester and how to become one. I really enjoyed his talk but rather than to describe it here I am going to point out a series of columns on this Huib is writing.

Keynote by Liz Keogh – “Haiku, Hypnosis and Discovery: How the mind makes models”
Liz put an extraordinary exercise into her keynote. She let the audience pair up to create Haiku’s. Together with Johanna Rothman and I came up with the following sentences that we combined to the following Haiku:

Foggy breath
An agile journey
Bright blue burst over the rocks

Or a more famous one from Matsuo Basho:
Furuike ya                  Old pond
Kawazu Tobikomu     Frog jumps in
Mizu no oto                The sound of water

Liz continued with a hypnosis session to explain that concentrated and focussed attention on positive experiences can bring a state of mind that widens perception and activates the ability to see patterns and models. Huib Schoots volunteered to go on stage and be hypnotized. It was impressive to see how more than half of the audience participate and was elevated by the experience.

Keynote van Gojko Adzic – “5 key challenges for agile testers tomorrow”
Gojko concluded the track days with an inspiring keynote talk on five challenges agile testers are facing:

#1 Shorter delivery phases
#2 Agile is now main stream
#3 Faster feedback
#4 Large “enterprise” projects
#5 Validating business, not software

His final message was to adopt principles, adapt practices, teach each other how to test, help business to define and validate actionable metrics, visualize risk value areas and to draw up contexts to inform testing. This definitively struck a chord with me. As I am working at a large enterprise transitioning to agile. I can fully understand that the energetic and all present Gojko won the MIATPP Award 2011 as “The most influential Agile Testing Professional Person 2011″

Final day

The final day was a series of parallel sessions with Open Space, Coding Dojo, Testing Dojo and last but certainly not least TestLab. To be honest I was both to actively involved and tired after the previous days to take sufficient notes. But what I can share with you that these possibilities to actively use what you have learned, to spar with your peers and to be coached by the organizers and speakers that are there makes this part of the conference potentially the most valuable part.

In October I started a series of posts on agile. For me there were three reasons to start writing those posts. First, I worked in an agile environment, second, I felt there had to be more to agile than its most commonly mentioned method SCRUM and third it was a way of preparing myself to go to the Agile Testing Days. Now that I have returned from the conference I would like to share my experiences with you in several posts. I am going to use the discussion  with Huib Schoots about going to conferences as a starting point to describe the social aspect of going to a conference. Other posts will go deeper into the content when I have digested the information bombardment.

Why should testers attend conferences?
My argument at the time  was: “Conferences typically are the place where you can learn the latest developments and opinions, submerge yourself into the testing mindset, confer with your peers, refresh your ideas and expand your network”.

Well at the Agile Testing Days this was absolutely true. But, and this is something I will have to be adamant about, this does not happen automatically. There are a few conditions to consider. Preparation You need to prepare yourself; for instance by knowing who the speakers are and what their subjects are. And not only to determine to which talks you want to go but also to ask yourself if it would be interesting to talk and discuss with them about it. Being Approachable Most of the speakers and delegates, as I have experienced, are very approachable and like to talk to you about almost anything. A conference can be so much better if you are open to this yourself and are courageous enough to step up to others and start a conversation. Look beyond the program Conferences, typically those that host different nationalities of speakers and delegates, do not stop when the talks are finished. Get together with the people you meet. Go out and have dinner with them, or get a drink at the bar. Why would you lock yourself up in your hotel room. A conference is not like a class room where you enter at a scheduled time and leave once class is over. Enjoy Go and talk about what you have on your mind. It does not even have to be about anything from the conference or testing even. There is great stuff to learn, great people to meet and lots of fun to have. And even if you think you have nothing to talk about there is a lot to gain by listening and watching the interaction. But I am pretty sure once you are there conversations will happen.

So what did I do?

Having said all of the above you might question how I fared myself. Well I started with inquiring who else, other than my colleagues (Frank Pellens, Huib Schoots, George Stevens and Robert Copoolse), was going to go the Agile Testing Days by sending out a few tweets on this matter. As it turned out there was a division between either the Agile Testing Days and with EuroSTAR within my followers. After some conversation Lisa Crispin and I agreed to meet on the Sunday evening before the conference. Now having set a date others would be able to join in. We ended up having a very enjoyable and entertaining dinner at Petite Pauline with Tamara Taxis, Liz Keogh  (Picture: Liz folding origami animals from Euro bills), David Evans, Stephan Kämper, Huib Schoots, Bob and Lisa Crispin and myself. Back at the hotel we went for another drink at the bar and found that several people that we as a group knew, like Michael Bolton, were to be found there also. So even before the conference had started I was meeting new people, talking to them and started a rolling snowball that would keep on growing during the rest of the conference.

Now that I had made contact and kept an open spirit I found myself getting to know lots of new and interesting people during the conference. Additionally I reconnected with people who I had met before and all of them added to my story of these Agile Testing Days. A story that enriched me and let me have much more content, context, depth and interactivity during the conference than when I had only gone there to listen.

PaTS

One of the other highlights was something Huib Schoots and I organized. Having heard about lightning talks and rebel alliances at other conferences we kind of felt the Agile Testing Days should have something similar. And if it were to happen we wanted to be part of it. So what better way to ensure that than to organise one ourselves. We contacted the guys from Diaz-Hilterscheid and after some explanation we were allowed to rent a room at the venue. Shortly after we made an initial selection of people we would like to meet and that we knew were coming to the Agile Testing Days. In that mail we called our gathering the Potsdam agile Testers Session or PaTS. We planned to start with the people who reacted positively on our mail and would see who else would like to join us whilst in Potsdam. On the third day of the conference we (Rob Lambert; Rob van Steenbergen; Daniel Lang; Janet Gregory; Simon Morley; Brett L. Schuchert; James Lyndsay; Stevan Zivanovic; Jim Holmes; Bart Knaack; Lisa Crispin; Olaf Lewitz; Mike Scot; Jurgen Appelo; Thomas Ponnet; Cecile Davis; Michael Bolton; Huib Schoots and myself)  got together in the TestLab, ordered some beer and pizza and started talking.

We started by making up a prioritized list of subjects of which we did the following:

• What makes a good tester (Nice post on this by Olaf Lewitz); Quote by Michael Bolton: “To see complexity in apparent simple things And to see simplicity in apparent complex things.”
• Manage / lead testers to become great; Qoute by Michael Bolton: “Learning does not stick if it does not sting a little bit.”
• DEWT / Peer groups (DEWT = Dutch Exploratory Workshop on Test)
• Acceptable level of risk

My following posts will be go deeper into the content or the conference and PaTS, but for now there is the following post by Jean Claude Grosjean; “Agile Testing Days 2011: Day 1 – What a fabulous day“

While getting in the mood for the Agile Testing Days 2011 in Potsdam I remembered  seeing a XP exercise sometime before. Essence of the exercise was to use the agile manifesto, its principles and to link them to development practices. This really felt as a great practical extension to my previous two posts on agile. Only trouble was that it had forgotten who wrote it so the exact steps were unknown to me. Also I remembered that it originally targeted an XP development audience and  that I felt that it needed some adjustment to be useful for (non-coding) testers.

At the same time I was getting ready to participate in the TestNet workgroup theme night with the Agile Testing workgroup. While e-mailing with the workgroup chair, Cecile Davis, I offered to use a recreation of the exercise suitable for testers and to translate the manifesto and principles into Dutch along the way.

Sprint 1 – Proof of Concept

At the following meet the other workgroup members liked my idea and draft version of the exercise. So at the TestNet workgroup night on November 8 I have presented and executed the exercise in front of some 30 people.

All in all the execution of the exercise was a success and I received positive feedback. Several participants were interested in doing the exercise with their team. But personally to be honest I quickly saw after the introduction that in spite of the good idea the six exercise steps I had written were not going to work with such a large group. So the exercise was saved by improvising, getting some goodwill and by offering additional explanation during and after the execution. Also I discovered that trying to keep it inside the period of an hour was a real challenge.

In good agile tradition I concluded the evening with a retrospective. Combining feedback from the participants with my own feedback I put new items on the (virtual) backlog. First one was to write this post, second to do a re-write of the exercise in general and thirdly to make an adaptation of the exercise steps in order to make them suitable both for smaller and larger groups. Both the content and the ‘new’ exercise steps of the exercise will be part of the following sections. The Dutch version, containing I believe the first complete translation of both the agile manifesto and the principles, will be placed on the TestNet ‘Agile Testen’ workgroup page [TBD].

Sprint 2 – The exercise (published version)

Preparation:

• Large separately printed sheets of the agile manifesto and the twelve principles
• As many  A4 / Letter print outs with the practices on them as you have participants
• Post-its or similar
• Markers
• Introductory presentation about the agile manifesto, the principles and the practices
• Know what you’re talking about
• A room with possibility to form groups, walk around, and hang the print outs on to the wall.

Step 1:
Give a (short) presentation on the Agile Manifesto and its principles.
Depending on the agile experience of your audience this can be shorter or longer. Check my previous two posts for to get additional information or inspiration.

Step 1B (small groups):
Group members discuss what the principles mean to them and how they map to the Agile Manifesto.
Depending on the time you have and on the familiarity of your audience with the Agile Manifesto you can spent longer or shorter amounts of time on this. In larger groups this tends to take a lot of time and is probably best added into the step 1 presentation or left out all together.

Step 2:
Present the practices and handout a hardcopy version of them to all participants.
Depending on the experience of your audience (and the time you have) you can provide information about all of the practices (takes a lot of time), or let the audience indicate which ones need to be elaborated or skip explanation al together.

Step 3:
Have the group go up to all of the principles and have them discuss  and map the practices that they think fitting to the principle. Mapping should be visualised by writing the practice on to a post-it and sticking it to the top of the sheet if it is a good fit, to the bottom of the sheet if it only fits partially.
The group should form a consensus on the which practices fit and to what extend. The aim here is to learn by actively linking practices to agile principles by discussion and argumentation. When necessary the facilitator should provide additional information and elaboration about the practices. 

Step 3B (Large groups):
Divide the audience into smaller groups of no more than 6-8 people. Then execute step 3 by letting them go by all principles from a different starting point.
To aid the visual result you can hang multiple versions of each principle (as many as you create groups) next to each other and differentiate the groups choices in this way.

Step 4 (Large groups only):
Have each group pick one or two of the principles and let them explain why they chose those practices and why they placed them higher of lower on the sheet. The other groups should be able to ask questions.
This step is more about sharing information and reasoning then that it is about argumentation and justification. A single group will have done this automatically during the exercise.

Final step:
Have all members evaluate what they have learned and taken away from this exercise. One of the take aways should be to pick one or more practices that they are going to actively work on during the next period. Then execute a (quick) retrospective on the execution of the exercise.
Depending on the group size and time you have left this can be down by letting each member express this to the group or to let them do this individually later.

The agile manifesto, the principles and the practices

To conclude this is what it is all about. Starting of with the practices:

Practices

A practice is something that has proven to be valuable in a certain context and offer insight into solutions that may or may not work in your situation.

You can do this with the list below for a start. But preferably create you own shorter, longer or more suitable list. Basically you can do this with any kind of practices not just test related practices.

• Manage risk
• Execute your project in iterations
• Embrace and manage change
• Measure progress objectively and understandably
• Test your own test cases
• Leverage test automation
• Team change management
• Everyone can test (and owns quality)
• Understand the domain
• Describe test cases from the user perspective
• Manage versions
• Co-locate
• Leverage patterns
• Actively promote re-use
• Rightsize your process
• Continuously reevaluate what you do
• Test Driven Development
• Concurrent Testing
• Pair Testing
• Specification by example
• Acceptance Test Driven Development
• Plan sustainably
• Stand-up meeting
• Plan in relative units
• Configuration management
• Learn by doing
• Whole team approach
• Shared Vision
• Use Case Driven Development
• Risk Based Testing
• Evolutionary (Test) Design
• …..

The agile manifesto

We are uncovering better way of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The principles:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Simplicity–the art of maximizing the amount of work not done–is essential.
• Continuous attention to technical excellence and good design enhances agility.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Remembered who the original exercise was from: David A. Koontz

How and why they met is briefly explained at the Manifesto itself, so I will not go into that further at this point. A few of the authors have written a recap of events at the manifesto meeting and where ever I have encountered them I have added them here too.

Some of the authors I had heard about at conferences, read work written by them or have seen them mentioned by others. But for quiet a few of them it started of as a journey into the unknown. As I travelled further I found that for some of them their work obviously spoke louder to me then their name. I might not have heard of recalled their name, their products or ideas I did recognize, appreciate and use nonetheless.

My approach to the overview of authors is that I present them in alphabetical order. I tell something about what the are doing  and for what they could / should be known. If possible I will provide links to those particular items providing possibilities for you to dig in deeper yourself.

Although the trip proofed to be taking a bit longer than anticipated I really enjoyed myself and I can only encourage you to have a go at the material yourself and treat this blog as a starting point for your own journey.

The authors

Kent Beck

Kent Beck is a software engineer. He is the founder and director of Three Rivers Institute. He is the creator of Extreme Programming (XP, 1996) and has rediscovered Test Driven Development (TDD).

Kent Beck typically is not known to be a tester. Most of his work is oriented on organizing development processes and teams. His ideas on this have had a visible impact on how agile teams are seen today. He has emphasized embracing change, stressing customer satisfaction, customer participation and the use of feedback. Testing is as such is recognized but limited to what I would call development testing (or checking). In short he sees testing as:

• All code must have Unit tests
• All code must pass all Unit tests before it can be released.
• When a Bug is found tests are created before the bug is addressed (a bug is not an error in logic, it is a test you forgot to write)
• Acceptance tests are run often and the results are published

Mike Beedle

Mike Beedle is Founder and CEO at New Governance and e-Archtitect. He also is, together with Ken Schwaber, the co-author of the first Scrum book, Agile Software Development with Scrum. Scrum has probably become the most popular agile method. Over the years Scrum has gotten many supporting organizations, training facilities and lately even certification has come available.

Arie van Bennekum

Arie van Bennekum joint the conference as a member of the DSDM consortium. Arie van Bennekum started with working on RAD, followed by DSDM and is currently more involved in Atern. He provides a nice introduction to Atern on his website (in Dutch).

Alistair Cockburn

One of the authors I had not heard or read about outside of the manifesto, kind of rang a bell and turned out to be quiet interesting. Alistair Cockburn was an advocate of the use of use cases. Later on Alistair Cockburn joint an initiative similar to the manifesto: “The declaration of interdependence for modern management”. Which declares the following:

“We …

• increase return on investment by — making continuous flow of value our focus.
• deliver reliable results by — engaging customers in frequent interactions and shared ownership.
• expect uncertainty and manage for it through — iterations, anticipation and adaptation.
• unleash creativity and innovation by — recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
• boost performance through — group accountability for results and shared responsibility for team effectiveness.
• improve effectiveness and reliability through — situationally specific strategies, processes and practices.”

Finally Alistair Cockburn has described a group of lightweight methodologies in the Crystal family.

Ward Cunningham

Ward Cunningham is known for contributing to OO, Paterns and Extreme Programming (together with Kent Beck and Ron Jeffries). Ward Cunningham is however best known for his invention of WikiWikiWeb, better known and used as Wiki. Testing wise Ward Cunningham is known for his invention of the Framework for Integrated Test, a.k.a. Fit, an automated, open-source, tool for user tests. Fit is often used with a third-party front-end Fitnesse.

Martin Fowler

Martin Fowler focusses on understanding how to design software systems ( Patterns, Refactoring, Domain Specific Languages) and on promoting agile approaches. On his website he has a fairly nice recollection of the meeting in Snowbird in which the Agile Manifesto came to life.

James Grenning

James Grenning is a name I actually did not recall from before writing this post. But he was the first on which the initial (alphabetical) search results turned something about software testing: “Test is not about finding bugs“. James Grenning applies agile development to the embedded world. He is an XP coach, but his biggest contribution to agile is the invention of Planning Poker. Personally I find his blog, after reading several posts very entertaining.

Jim Highsmith

Jim Highsmith is the creator of Adaptive Software Development embodying the principle that continuous adaptation of the process to the work at hand is the normal state of affairs. On contrast to the other authors (so far) Jim Highsmith is more about project management and team work than strictly programming. Together with Martin Fowlers he works at Thoughtworks Inc. and was co-author of the earlier mentioned Declaration of Interdependence.

Andrew Hunt

Andrew Hunt co-authored the The Pragmatic Programmer and together with Dave Thomas founded the Pragmatic Bookshelf providing a series of books on software development amongst were books about the Ruby programming language. In one of his blogs I found the following rules, derived from Improv:

Rule one, agree.  Don’t reject current agile practices, but don’t accept them as written in stone either. What constitutes your current set of agile practices isn’t “done”: it’s not finished, it’s not established as canon, and it never will be. 
Rule two, add your piece.  It’s up to you and the rest of your team to evolve your agile practice, to keep it alive and keep it moving.

Ron Jeffries

Ron Jeffries is together with Kent Beck and Ward Cunningham one of the founders of Extreme Programming. His website is very informative on XP and its core practices. (Do not be fooled by the shortness of this item and visit the XP website!!)

John Kern

There is not a lot of typical information on John Kern. I suppose a good introduction is supplied by his recollection of the Snowbird meeting. In addition his blog provides a nice introduction to Ruby.

Brian Marick

Over time Brian Marick has gradually shifted from software testing to a more on general development oriented approach and is currently focussing on Ruby. He was at the time of the Agile Manifesto one of the (few) software testers present.

Brian Marick has an old and a new blog that are both worth visiting. The old blog did have slightly more focus on testing whereas the new blog is more about agile development with a focus on how testing fits in. The old blog also has a good introduction on agile testing with a series of links to interesting blog posts. Most noteworthy, to me, is the test matrix that Brian Marick developed that later on also was successfully used by Lisa Crispin and Janet Gregory in their book Agile Testing.

Robert C. Martin

Robert C. Martin also known as Uncle Bob Martin is a software consultant and author. Robert C. Martin is well-known for his books on agile software development, e.g. Clean Coder, and as a leading member of the software craftmanship approach that produced the following manifesto as an extension to the Agile Manifesto:

As aspiring Software Craftsmen we are raising the bar of professional
software development by practicing it and helping others learn the
craft.  Through this work we have come to value:

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

A nice anecdote the at a keynote for the Agile 2008 conference Robert C. Martin added a fifth value to the Agile Manifesto; “Craftsmanship over Crap” which he later changed to “Craftsmanship over Execution”.

Steve Mellor

Stephen J. Mellor is known for his books on Essential Modeling Techniques and Executable and Translatable UML that was derived from Schlaer-Mellor method.

Ken Schwaber

Together with Jeff Sutherland Ken Schwaber formulated the initial versions of the Scrum development process and are authors of the definitive Scrum Guide, of which recently an update version became available. He is a founder of the Agile Alliance, and he is responsible for founding the Scrum Alliance and creating the Certified Scrum Master programs and its derivatives. Follow Ken on his blog to see what his opinions on the development of Scrum are.

Jeff Sutherland

As mentioned previously Jeff Sutherland works closely with Ken Schwaber. Ken and Jeff formalised the Scrum development process at OOPSLA’95 in the Scrum Paper of which an updated, 224 pages, version is available. Additionally this article is available on his blog and explains where the idea came from. Jeff is very active in providing training and you have ample change to meet him in this capacity.

Dave Thomas

As mentioned before Dave Thomas co-founded the pragmatic bookshelf and wrote the “The Pragmatic Programmer” together with Andrew Hunt. They also went on to write about the Ruby programming language in the book Programming Ruby and Agile Web Development with Rails, a book on Ruby on Rails which also touches on Ajax and the Ruby programming language. Dave has also coined the phrase ‘Code Kata‘.

This concludes my visit to the authors of the Agile Manifesto. In part three of the blog I will visit some of the other authors / persons that I have found noteworthy since I have gotten interested in agile.

“We’re talking about agile sure enough, but why is it I mostly hear Scrum, Lean and Kanban content passing by. How agile is that? And if it is not how bad is that?”

This post will therefore take you along the route I took to rediscover agile. It will contain some information on agile, and is a sort of personal recap. It is not intended as a complete and detailed overview of the agile approach and all of its derived methods and practices. Where ever I mention them however I will try to add a link to guide you to more information or interesting blogs. So feel free to use it, if nothing else, as your (re) introduction to agile if you like.

My original journey to agile started in 2007 and I will start once more at what was then my starting point. One of my colleagues came back from EuroSTAR 2007 and was enthusiastically talking about this new thing: Agile! I had heard about it before but had never really dug into it before. So like then I will go to where agile had taken off: the declaration of the Agile Manifesto in 2001. Seventeen people came together in a ski lodge and drew up a manifesto with the four following lines and guideline:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

This probably still is the best known part of agile there is. No self-respecting course will bypass these lines and not show them and declare them the essence of agile. Personally I think the manifesto, once read, makes sense to almost everybody who has been in IT for more than a couple of years. Their strength lies in stating something people sense but not always come to formulate themselves.

A lot of courses on agile do not go beyond this and do not also show the additional: “Principles behind the Agile Manifesto”. They jump straight to one of the methods and often enough without mentioning the principles at all. In my opinion this does not do justice to the manifesto as a whole. Therefore let’s have a look at these twelve principles. The seventeen authors of the manifest, who are also hardly ever mentioned, are part of the second part of this small series of post on agile. The third part will be on other prominent authors, like Lisa Crispin, and popular methodologies.

The Principles

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

As many of us have probably experienced, changes in requirements during development and even late in development is not new to software development. To accept and embrace these changes is certainly less common. This is one of the items that differentiates agile from other approaches. Other (more traditional) approaches either deny the existence of such possibilities, are unable to cope with them or try their utmost to abolish them.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

All software projects aim to deliver working software. The difference here is that agile projects aim to deliver more than once and to do so within a (far) shorter time span.

• Business people and developers must work together daily throughout the project.

Two elements in this principle provide direction into how business people and developers should work together. Those are to do it daily and to do it throughout the project. This combination I believe is typical to good software development in any approach. A lot of the other approaches have formalized so much however that to do so amounts in a breach of process, plan or protocol.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

In management theories this concept has been around for decades. For some reason however the application of these theories seems not so common place in the software development world. In this respect this principle sets the right mindset in creating self steering, responsible and trusted teams.

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This is a radical break to what is, or I rather would hope, was considered standard in software development. Still a lot of developers, testers and even more so managers and stakeholders consider it impossible to do without upfront and approved documentation. “How else would you know what to do.” Reality is that documentation hardly ever completely describes what the customer wants. Let alone that it completely describes how to build it. I can personally not think of a faster way to retrieve or confirm information then by asking the informant directly. And if anything needs to be recorded you can do that while talking together, in the code or on paper later.

• Working software is the primary measure of progress.

There is beauty in this principles simplicity. As a tester however I think it’s a bit to simple. What does that mean “working software”? Does the code run, does it pass all checks or is it tested also and do the customers find the value in product that they were looking for. The intent of this principle is good, but it needs enhancement on the concept of what working means in your context and to whom.

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

I can only adhere to and promote this. I do realize however that it often is not on the mind of project managers. PM’s regularly still steer their projects on cost, time and scope using unfounded estimates that still have to be kept even when pushes personnel to their limits and over.

• Continuous attention to technical excellence and good design enhances agility.

I suppose this applies as an enhancement to all software development and therefore also to agile. If it actually enhances agility I am not so sure. The need for short sprints, iterations, cycles, or what you call them seems to work counterproductive here. (At least for the developers and architects I know.)

• Simplicity–the art of maximizing the amount of work not done–is essential.

In order to deliver the right content swiftly you should refrain from adding self thought up features or so-called enhancements. Unless the stakeholders or users are informed before and see them as adding additional value. Otherwise these items are likely to go in unnoticed, undocumented and untested. With all the risks that come with that. As to minimizing the work on agreed upon requirements I applaud the intent, but I think most developers start of to do their best and refactor when they see possibilities. In that sense it is wisely mentioned but if it really brings benefits in practice I have doubts about. (But I will get to this when I go into Lean later.)

• The best architectures, requirements, and designs emerge from self-organizing teams.

I totally agree with the idea behind this principle. Self-organizing teams are a good breeding ground for this. It should however not limit them to seek and accept expert input if this brings even better results.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The best way to handle your faults, or any experience, is to reflect and learn. This applies to teams as much as to individuals.

This concludes the first part in which I have travelled along the Manifesto and its twelve principles. I will continue (next week) with some info about the authors. Which is actually new to me as well, so that will be a journey into largely undiscovered country.

]]> http://arborosa.org/2011/10/10/agile-to-agile-1/feed/ 0 jpv66