Gojko Adzic has published a very good introduction on fitting Agile Acceptance Testing into the Agile development iteration. The flow reminded myself about the views I got during reading through some example chapters the upcoming book Agile Testing: A Practical Guide for Testers and Agile Teams from Lisa Crispin and Janet Gregory. If you’re searching for a good introduction for agile testing make sure to read the article from Gojko while waiting for the book.

Since I’m personally not able to join the Agile 2008 conference, I was very pleased and thankful for Gojko Adzic‘s regular blog entries on discussed topics he attended to. Today he had an entry on Robert C. Martin about The Fifth Element of the Agile Manifesto, which made me think for a while.

Personally I identified some causes of the effects Robert C. Martin addresses in his talk. Since I read recently Alistair Cockburn’s book Agile Software Development – The Cooporative Game my sights are heavily influenced by it.

Failure Modes

When looking through the remaining human failure modes, I see them addressed in Robert C. Martin’s talk. The remaining three human failure modes might also apply, but I leave the application up to your own thoughts or you might be willing to address them in the comments of this article.

Inventing rather than researching

Rather than reusing the practices from a given methodology it is better to re-invent the wheel new by defining practices from yourself. The problem arises here, that you will come up with ignoring the underlying Agile principles as stated in the Agile manifesto while not understanding them. Considering the Shu-Ha-Ri principle of skill-adaption here, when skipping the Shu stage, you’re not going to reach the Ri stage.

Being inconsistent creatures of habit

First of all does Dr. Cockburn enlist humans being inconsistent creatues of habit as one of the individuals failure modes. Robert C. Martin addresses this with the question for the code coverage of the unit tests at the Agile conference. Even the lack of knowledge on the XP practices in the audience is another sign for this.

Cooperative Game

To quote Alistair Cockburn:

Software development is a (resource-limited) cooporative game of invention and communication. The primary goal of the game is to deliver useful, working software. The secondary goal, the residue of the game, is to set up for the next game. The next game may be to alter or replace the system or to create a neighboring system.

Simply put, I you do not set-up yourself for the next game, you missed the secondary goal of the cooperative game principle. This might be achieved by not coming up with unit tests in the proper depth, this might be caused by relying completely on osmotic communications, thereby ignoring the fact to extend the team – yes, this one I address to myself.

Agile mainstream

Last but not least there is an insight I came up with by myself. The more people are adapting agile processes, the more it is likely that sloppy software developers also get in touch with agile and therefore the agile methods might get bad reputations through the people trying to skip the Shu and Ri level of the agile skill-set. Interstingly I came up with the idea for this cause right before reading Gojko’s Wrap up of the conference, where exactly this is also a part of his critics.

If you still did not yet get the clue, I would propose to read an article in the Better Software Magazine on How to Fail with Agile from Clinton Keith and Mike Cohn. Personally I like the second one the most:

If agile isn’t a silver bullet, blame agile.

last week I submitted a paper proposal to StickyMinds on thoughts I came up with for Agile testers mainly influenced by the reocurring questions on how to test on Agile projects on the AgileTesting Yahoo-Group. Here is the essence of that paper. You can find the whole article here.

Agile Testers face the problem that there is few literature on how to test on Agile teams while there are a lot of recommendations for the development staff. Nevertheless Agile testers need to know the working habits of an Agile team. One thing reoccuring on the Agile-Testing group is the question how agilsm changes the way a tester works. Attracted by the principles in The Art of Agile Development from James Shore and Shane Warden here are those additions that apply for the testers on an Agile team. When appropriate I will make cross-references to chapters in their book, that also apply for testers on Agile teams.

Thinking
Beside an Energized Work and Informative Workspace, a tester should be able to apply Root-Cause Analysis when finding severe bugs so that they are unlikely to reoccur. Furthermore Retrospectives help improving the overall process. Beside these practices from The Art of Agile Development Pair Testing is useful for improving the brain power on your daily work.

Pair Testing
Pair Testing improves the work within the testing process – just like Pair Programming improves the brain power during development. Pair Testing can be applied with different expertise and techniques. Nearly all types of combinations are possible. An experienced tester can pair together with a junior tester or a customer may join a tester to help building test cases for a critical or difficult business logic. The feedback from the on-site customer can be spread to the programmer, when the tester pairs with a programmer while she is working on the story.

The first time I got to know pair testing was during a critical phase of a software replacement at a larger company. The department lead decided that I should pair together with another experienced tester with extensive on-site epxeriences from the user acceptance tests. We had a timeframe of four weeks left for the acceptance of our customer. Based on our previous working habits we would have needed three to four months of work that had to be done within one month. We were asked to exercise the user acceptance test cases documented and agreed with the customer. Our customer and user acceptance test team was located 1000 kilometers from our location and we needed more direct feedback for our development department. We both had quite impressive knowledge of the system under test, but each of us just knew one of the larger sub-systems very good. Therefore combining the knowledge of two adjacent views of the system lead to an impressive work-output. We managed to find critical bugs at a rate of ten per day. In the end we achieved to drive the development to meet the upper organisational goal within the given timeframe.

Collaborating
In the Collaborating section The Art of Agile Development lists many practices that are also worthwhile to apply to the testers in the team. When the team members Trust each other because they are Sitting Together and have an Ubiquitous Language, it is easier for the testers on the team to do the neccessary Bug Reporting.

Bug Reporting
Though No Bugs is a core practice under the Agile practices, during the development process of new functionality software defects slip in. When a tester finds a bug, it is up to his personal intentions on how to report it. Based on the particular level of Trust in the team there are several possibilities.

Write a test
This is the easiest way for the tester. He simply builds a test case that catches the bug and submits it into the revision system. When using automated build tools the next automatic build that the tests are run on will show up with the bug and the developers start fixing it.

Open a bug
The classic approach to report bugs is of course by opening an entry in the projects bug tracking tool. The advantage here is that any additional information useful for the resolution of the bug, i.e. logfiles and screenshots, can be put in, too. The programmers will start to fix the issue when working on the bug.

Report directly
For severe problems that need immediate attention during the fast paced devlopment cycle of an Agile team, a bug may be reported directly to the development lead in the team. This ensures immediate attention to the issue slipped in and makes sure that the bug can be resolved if it would lead to a critical outcome, i.e. during the iteration demo when Exploratory Testing is done in front of the stakeholders. Based on my experience this level requires the largest amount of Trust within the whole team.

Personally I prefer to do direct reports when appropriate. The flavour of throughing bugs back over the wall by opening some entry in the tracking tool or by writing a test which fails during the automatic build process which will sooner or later execute reminds too much to the days when software was thrown over the wall to the testers. Anyways it is usually better to open a bug or write a failing test for non-severe problems. Disturbing a programmer just due to some typo in the user interface does not account for the amount of thinking neccessary to get her back to work.

Developing
The Art of Agile Development mentions Customer Tests. Based on my personal impressions I would like to add a chapter named Business Facing Tests that is a combination of the original Customer Tests chapter and the Exploraty Testing chapter flavored with the personal realisations I came up with.

Business Facing Tests
Business Facing Tests are the key compound for Agile testers. By defining test cases in terms of the business language the test cases can be defined simultanously with the software development work. Therefore they provide immediate feedback for the software under test and provide valueable feedback directly after the story is developed.

After establishing the first tests in FitNesse in my company I noticed the following on the next project. My test team was able to apply the same principles that are driving the development during Test-Driven Development just on a higher level. We were able to define test cases beside the development work. After adding some smaller fixtures the test cases could be directly run and provided immediate feedback on the code under test. Additionally I noticed that our developers noticed this improvement and started to ask us about input for their bugfixes. By concentrating on the business value we achieved to build up Trust between the members of the teams beside the fact that we managed to get enough time for Exploratory Testing.

Based on my experience Business Facing Tests result in quick feedback that is needed during the fast development cycles. While being able to give this feedback nearly instantly Test-Driven Development is applied on a higher level.

After experiencing the concepts of test-driven-development during the last few weeks, I realised the essence of agile testing. After reviewing main parts of Janet Gregory’s and Lisa Crispin’s upcoming book on Agile Testing back in February I just now realised a common pattern in test-driven-development and agile testing: Tests – or like Brian Marick stated it: examples – drive the development process. You start with a first simple example. This might be a “the collection has just one element” during test-driven-development or “the account is activated afterwards” during a test scenario. From my point of view this can be thought as the essence of agile testing in either case.

Alistair Cockburn’s introductional chapter in Agile Software Development – The Cooperative Game reminded me today on something I learned before entering university. My fourth a-level during my german abitur was on education science. My teacher by that time (1996-1998) had a strong background in psychology and introduced Lawrence Kohlberg’s stages of moral development to us. Cockburn’s introductional comments on Shu-Ha-Ri reminded me on this when I came to read the chapter this morning.

Since I learned on Kohlberg’s model nearly 12 years ago without having any practical use of it, I had to look up the model. Cockburn had raised the question in me, if there were any parallels between Kohlberg’s model and the Shu-Ha-Ri educations. I started with this by searching out the notes we were given during school. Since I collected everthing that I wrote down during my abitur time, this was quite easy, though I did not remember the right semestry.

Kohlberg’s model denotes three main levels each with two sub-levels or stages. There is also a zeroth level and – as I got to know today – also an undocumented seventh stage. The three main levels with two stages each build the ground for his theory. Within the first (pre-conventional) level the student is influenced mainly by the teacher and the teacher’s opinion on right or wrong may be mapped to the student’s one. The second (conventional) level describes reasoning from the social point of view.

Persons who reason in a conventional way judge the morality of actions by comparing these actions to societal views and expectations.

Lawrence Kohlberg’s stages of moral development

The third (post-conventional) level goes beyond this. The argumentation follows princicples of ethics like Immanuel Kant’s categorical imperative.
Personally I was hoping to find parallels between these three main stages and the Shu-Ha-Ri concept.

Shu-Ha-Ri consists itself of three stages of communications and learning. The first stage describes the obeying phase.

The student should absorb all the teacher imparts, be eager to learn and willing to accept all correction and constructive criticism.

In the second stage:

The student’s individuality will begin to emerge in the way he or she performs techniques. At a deeper level, he or she will also break free of the rigid instruction of the teacher and begin to question and discover more through personal experience.

For the third stage:

Although the student is now fully independent, he treasures the wisdom and patient counsel of the teacher and there is a richness to their relationship that comes through their shared experiences. But the student is now learning and progressing more through self-discovery than by instruction and can give outlet to his or her own creative impulses.

The meaning of Shu-Ha-Ri

Though I hoped to find parallels between Kohlberg’s model and the Shu-Ha-Ri I came up disapointed that there is nothing. After reading more stuff on Kohlberg on Wikipedia it finished that Shu-Ha-Ri can be thought of as being more progressed than Kohlberg’s model. Especially the critisms on Kohlberg made me aware of this. The cases where Kohlberg did not think of are the cases where Shu-Ha-Ri steps in.

Furthermore I hope you disagree with this statement of mine and would like to share your viewpoint on this topic.

Lately there is some heavy discussion on the Agile Testing mailing list which started with the question of the developer to tester ratio. Today Ron Jeffries noted a good point on a sub-discussion on the different skill sets of developers and testers:

Suppose we have some “requirement” and some test examples. Suppose that we are worried that the “requirement” is not met. What do we do? We produce another test example. While we are unconvinced that the “requirement” is met, we keep testing and coding. When we become convinced (or sufficiently confident), we stop testing and stop coding. Therefore the tests are the requirements.

Ron Jeffries

After thinking a while over Ron’s quote, I come to the conclusion, that testing – even in the agile context – is what it is: the translation of business interest into the development process. This short conclusion was difficult for me to express, so let me refine the previous statement.

Leaving the agile context out for a second testing shall provide the necessary feedback that the software under test has met the right degree of requirement fulfillment. Analytical testers use coverage metrics for this topic and an Agile Tester concludes with the customer representatives on the team which are the points to measure for requirement fulfillment. Like a Fourier transformation in maths you have discrete points on your function (software). The topic a tester has to fulfill to deliver good tested software is to identify the supporting points of the function (software). If the tests are build on uninteresting points within the function, the testing effort should have been saved. This may sound a little tough, but if you just check the error behaviour, you may and most likely will miss the business relevant tests on the happy path and therefore deliver software at a very high risk.

Today I was pointed out to three different measurements of success, that I applied in my mind on the current status of our project to migrate legacy tests to FIT/FitNesse. My weekly plan for the last week forsaw to have some kind of “prove of concept” for a very first test. We started to work on migrating our legacy tests from some shell-script approach towards more business-facing tests using FitNesse two weeks ago. We planned for three weeks, therefore we are currently more or less half way through the iteration. With some hard work I managed to get my first “proof of concept” by yesterday and felt successful about this. Anyways today I was pointed out to three different types of success measurement while reading The Art of Agile Development from James Shore and Shane Warden. Their definition made me thoughtful on the things I was happy about yesterday.

Basically we started with five people working on this project. First of all we wanted to concentrate on two areas of our product under test. For these two areas we decided to note down particular tests in FIT-style. Beneath this test definition where most of my testers were planned for, we wanted to build up a small framework in order to integrate our application and having more simple Fixtures to be created.

Until last Friday I wanted to get a first “proof of concept” for this whole work – a single first test, which hopefully should pass. Since there was just one of our external staff members working on that framework, it was not very stable and usable. Personally I decided to work on that proof of concept which I had set as goal for the week. The remaining two available testers in my group decided to start to maintain our legacy test suite, since there was a new release of the system upcoming and the framework was not usable, so we could not really include them into our work, yet.

By Thursday evening I had included a very first draft, which had the setup mechanisms hard-coded. The code was already triggered properly. On Friday I started to do some circumvention work on the framework my external staff member was working on in order to get our first test running and doing everything as intended by the table. I managed to exchange the hard-coded setup mechanism and introduced the result checks as intended. In the end everything showed up green and I was happy.

In The Art of Agile Development I got to know, that there are three kinds of success to think on: Personal Success, Technical Success and Organizational Success. The personal success I felt by yesterday evening is obvious. I have met my weekly goal, a first “proof of concept” is working. Technically I produced some circumventing solution, which works, but will be hard to maintain. From my point of view I have not been successful in this area when looking at the Fixture code I produced during the last week. Organisational we reduced the scope of our iteration, since we could not make that good progress as it would like to have.

Therefore I have a 1:2 situation and I’m not that happy on the success I have met during the last week. I hope I can smooth out to meet at least the technical success needs, which I would like to have by the next Friday, but unfortunately I’m currently not that convinced about that. Maybe it could help to get to know, what we have been doing wrong and how to react on this in the next iteration planning.