All posts by Markus Gärtner

Testing

Technical Debt applied to Testing

2 Comments

During the last two days one thing puzzled me. Yesterday I had our annual review meeting at work and during that session one topic came to speak, over which I happened to think the whole evening. Since I had read that morning on Sean Lendis’ blog about Technical Debt, the resolution I came up with, was that an occurence of something that I would like to define as Technical Test Debt Maybe someone already gave a different name to this, maybe it’s just unprofessionality, but I’ll call it Technical Test Debt for now. In order to introduce Technical Test Debt, I start by revising Technical Debt. Here is a quotation from Ward Cunningham’s site which helds the first definition:

  • Technical Debt includes those internal things that you choose not to do now, but which will impede future development if left undone. This includes deferred refactoring.
  • Technical Debt doesn’t include deferred functionality, except possibly in edge cases where delivered functionality is “good enough” for the customer, but doesn’t satisfy some standard (e.g., a UI element that isn’t fully compliant with some UI standard).

A key point I see fulfilled around Technical Debt is, that it seems to occur on Agile teams as well as on non-Agile, Waterfall, V-Modell-, whatever-teams for the development part. One thing for sure is difficult to do: Measure Technical Debt. James Shore came up with a definition in the last year, but that did not fully satisfy me so far. To quote Martin Fowler here:

The tricky thing about technical debt, of course, is that unlike money it’s impossible to measure effectively.

To give my point a little bit more context, in the past I was just involved in test automation work at my current company. We have a high attitude to automate most of the tests we do in order to run them several times before the software gets to the customer. For some hard-to-test components however we decided during the last year to not do this and just rely on manual tests. We ran into a problem when we were faced with the human factor of software development. Our Release Management group, which provide the software packages to the customer, packaged some older version of that stand-alone component we just tested manually. Since we were not expecting the software to change, we had not run those manual tests before bringing the patch to production. Due to confusion while generating the package, it contained too much, where one software component was outdated and led to a production problem – which gladly could be fixed by some high responsible developer. My resolution here yesterday was, that I had come across Technical Test Debt. Since we were not expecting the software component to change after the first approval from our customer and test automation seemed to be a high cost at the time we made the decision, we refused to do any automated test cases, that would verify the software for each delivered package. We were pretty aware of this issue, but we did not take the time and effort to pay off this Technical Test Debt and have the software component forseen with automated test cases, that would run over each of our created package, before screwing up the production system.

Another thing I would like to call Technical Test Debt concerns test automation as well. During the first days at my current company, we used shell scripts for test automation. There was a quite impressive set of shell-script functions, which in combination automated most of the work for regression tests. The debt here is similar to Technical Debt in software: Since no experienced designers were assigned to the group in order to lead future improvements into a manageable direction, the shell-function codebase grew and other the rushes of several projects noone really got the time assigned to pay off this Technical Debt in the test automation codebase. After some internal reorganisation my team took the hard line and exchanged our legacy shell-function based test automation framework through FitNesse. By doing so we managed to gain an order of a magnitude improvement by keeping Technical Debt in the automation codebase as low as possible. We used regular refactoring, unit tests to communicate intent and pair programming as key factors there, but I also see some short-cuts currently on one class or the other, where I directly know, that this Technical Debt was introduced by the first point from the list above.

While I’m pretty much convinced, that the first of my two points is clearly Technical Test Debt, the second point is discussable. I like to define test automation as a software development effort with all the underlying assupmtions on the automation code. While picking this view, I would say that the second point is just Technical Debt, that occured during a software test automation. Another thought that strikes me on the first point, is that Technical Test Debt in terms of unmade tests, might have high risks attached to it. That’s why a tester needs to know about risk management in the software under test.

Agile Testing, General, Test Driven Development

Innovations for the New Software Engineering

1 Comment

During the last weekend I went on a IT professionals seminar. On Saturday evening there was a panel discussion, on which innovations are going to be expected from the IT world during the next years. While hearing the participants and some leaders from some bigger german companies, I got struck. The question that came made me think, what the biggest thing that could happen could be. Some time during the question, for cost-center vs. profit-center thinking it came to me, that the most obvious innovation seemed to be ignored. I decided to share my insight here as well:

Involvement of the customers and stakeholders in the Software Engineering

How do I get to this obvious innovation? It is no solution to gather requirements for several weeks and months, going back into the black-box of programming to build a system after a plan, that gets anyways blown up, deliver partial tested software just to find out, that the 20 percent of value for the actual user of the product are not included. If I want to get a new suit that looks nice, then I go the dress maker and participate and contribute to his work. Of course he can measure my lengths and go into his black-box of dress making and deliver the right dress for me. Really? No, there might be some try-on iterations wortwhile in order to get what I would like to have anyways.

I’m pretty much convinced: Only if customers and stakeholders understand this lesson I learned from Agile Software Development, will this contribute to the Software Enginnering. It is not enough to realize that there is something I have to specify and get something delivered afterwards. Like I have to give a dress maker my input of what I would like to have, like the color of the cloth he should use or the material of it, the Software customer has to participate in the definition of the software system he would like to be built.

Likewise if I go into a shop and ask for a suit, a good salesman will ask me questions in order to get to know, what style I prefer. Like I participate in this gathering by giving the right answers, in the software world it is the same. Software Engineers are not staring into the crystal ball to get to know what the system shall give as advantage to its users. (Though there is a family of methodologies named after the first of the two words, but this is not the intended meaning behind it.)

Likewise it is natural that there are some iterations necessary in order to get the right system. This is true for dress making like for Software Engineering. One has to look over the built product in order to see if it fits the needs. Due to high project lengths of software projects, there be a changed business situation, so that the product does not fit anymore. Maybe I was wrong in first place, when trying to guess what I would like to have – that’s because I as a customer even cannot take a look into my own crystal ball either.

Agile goes a step further. Agile asks the customer not only for participation but for commitment to the product that is being built. This is the case of for Iteration Demonstrations of the working Software each other week. This is the case during the iterations while working about complicated business rules of it. For the dress maker comparison there are no real complicated business rules behind the product he builds. This is the part where craft comes into play. The dress maker learned how to tie together some cloth to get a suit for me. The Agile toolkit does this for Software Engineering to some degree.

Last but not least I would like to denote that heavy customer and stakeholder involvement is not all of it. But at the current time it is the biggest first step to go in order to get real innovations out of Software Engineering. Like Pair Programming and Pair Testing while having the right input at the right time more than doubles the output. This is even true for real customer involvement.

General

Craftsmanship over Execution

1 Comment

Currently there is a lot of discussion ongoing on the causes of failing agile teams. After watching these discussions for quite a while now, here is my view of the topic. The brief quint-essence is: If you’re doing crap, it doesn’t care whether you call it Agile or not – you’re just doing crap. If you’re doing a good job, it doesn’t care whether you call it Agile or not either – you’re just doing a good job. About a year ago I started to take a look on how Agile Software Development is done, especially under the circumstances of testing on Agile Teams. Since I realized that my company was struggling with delivery based on waterfall projects and non-cross-functional teams, Agile seemed to be a solution worthwhile to take a look on. Since introducing change in working habits is a large effort and I was not in a key position to introduce this, I started especially focused on the mind-set behind Agile Software Development and the sucess aspects of it. Incrementally I achieved to introduce changes based on the practices from XP – but for several reasons I was confident, that I could not introduce all aspects of it. Today I would say that I did not take the courage to just change stuff and come up with the success story afterwards.

The changes I started to introduce in my company where tiny. We were suffering from shell-scripted test automation, that was very interface-sensitive. A change in one of our software components could lead to a full regression test result disaster, our testing team being unable to give the stamp of approval on it safely. Manual testing was no practical option, since it would have lead to many weeks of efforts for that, but the bugfixes we had on our desk were critical for our customer. My team decided to reimplement test automation with a new approach and we decided to use FIT for it.

The next six weeks were spent focussing on the highest priority business use cases. We were able to build a new framework for testing on it. While I was reading The Art of Agile Development from James Shore and Shane Warden, I brought in many aspects of the practices and underlying principles and values into my team. Though we were not implementing the full set of practices, we were quite successful over the next few months and finally finished our energized efforts with a test framework, so that we were able to run our group during vacational time with just 1.5 persons, while we were unable to hold the pace one year before with 10 persons.

In the meantime one of my colleagues as well introduced a testing framework based on FIT but with a different approach. While my team used Java, his used Python. While my team focused on the readability of the tests from a business perspective reducing all visible test data to the necessary level of detail, his team put every little detail for the tests in there – whether they contributed to the expected results or not. From organizational point of view it was decided, that we needed to focus on just one programming for easier job advertisements. We came up with the solution to use Java as programming language, since most of our developers have either a Java background or are Java Developers. We started to move the previous Python classes to Java, without having the people introduced to Java beforehand. I did not that hard participate in the migration of the classes and see today that there is bunch of technical debt introduced. From my point of view there are two flaws that result from neglecting the craftsman aspect of our work: the table structure and the Java class code.

While I had read the book on FIT before starting to do anything, my colleague just started. Since he did not get the recommendations from people who have invented the framework and the problems they see on several topics, the tables are interconnected and while reading them I get a brain-twister. The second problem was, that we were forced to stick to the wrong table layout while getting the fixture code from Python to Java. As well since the people doing the work were new to Java, they did not come up with Pair Programming, Unit-Tests for the fixture code and no reusable design in the mind. Getting the toolset now ready for the next customer, will be an immense amount of work, if we agree to stick to the table layout, from my point of view.

The conclusion from that lesson for me is, that Robert C. Martin is of course right. With proper introduction to Java, JUnit and FIT the solution would be better today. We did not say, we were implementing Agile. We just focused on the parts of Agile, that helped us very much. The first approach from my side was a success, because we were simply doing a good job with future opportunities in mind and did just the necessary stuff skipping most of the YAGNI implementations. We were not doing Agile, we were not calling it Agile, we were just doing a good job. On the second step, we were not doing Agile, either. We were not calling it Agile, either. We were just doing a bad job, not paying attention to the skill-set of the people doing the implementation, not looking over the code before or even directly after submitting, no Pair Programming. We were doing a bad job, that’s it.

As stated intially, it does not matter, whether you do a good job and call it Agile or not, or whether you do crap and call it Agile or not. In either case you either succeed or fail, no matter what name you give that child.

Further reading:

General

Skillset development

9 Comments

Lately I exchanged some thought with Alistair Cockburn on his new side over e-mail. Therein I introduced him to some thoughts that raised in my mind while reading through Agile Software Development – The Cooperative Game and Extreme Programming Explained and he told me to try the terms out for a while. Therefore I decided to introduce the thinking behind it for everyone. To introduce you in the topic I will first explore some definitions from the Extreme Programming (XP) and Agile world and try to relate them to the thoughts from the Cooperative Game.

Extreme Programming

This chapter describes the initial thoughts from Kent Beck on the relationship between practices, principles and values in XP. The initial of view of Kent are complemented with the thoughts from James Shore.

Practices

The XP practices build up a key set of actions to follow in order to get into the XP way of thinking. Practices are the entry point for teams new to XP. They build the first insights on how work is being done in the XP way of thinking. Practices are clear, so that everyone knows if they are followed. Practices are situated in that they just tell you what to do in a particular circumstance. They are not applyable in the rest of your life. In the second edition of Extreme Programming Explained Kent distinguishes between two levels of practices: the Primary and the Corollary.

The Primary Practices are introduced to get started right from scratch. These build up practices everyone should be able to start with right now without any dependence – beside the will to apply them. Among these practices there are advises like Sit Together, Whole Team, Pair Programming, Slack, Ten-Minute Build and Continuous Integration – just to name a few. The Corollary ones build up practices which might be difficult to implement without following the Primary ones. Among these there are Team Continuity, Code and Tests, Single Code Base or Daily Deployment.

Principles

As Mr. Beck describes in a wonderful picture, since practices and values are an ocean apart, principles build the bridge between them. The principles make the clear practices relate to the universal values. Principles make the XP team realise, why they are doing a particular practice and lead to the higher-level, universal values behind these. Among the XP principles there are Humanity, Mutual Benefit, Reflection, Flow, Quality or Baby Steps – just to name some examples.

Values

Values form the universal underlying part of the practices. XP values Communication, Simplicity, Feedback, Courage and Respect. The underlying value of communication, courage, respect and feedback highly motivate to apply sitting the whole team together as near as possible for example. The principle of humanity demands this. Without the values behind the practices, the latter would be tedious activities fulfilled just since it is denoted somewhere. Values form the motivating factor of the XP practices, while principles give reasons to apply them.

Agile

As Robert C. Martin wrote on Object Mentor summarizes how XP relates to the four Agile values and the twelve principles mentioned in the Agile Manifesto. Alistair Cockburn writes, that the people who signed the Agile Manifesto did not dare to go deeper into the materia and try to agree on common practices. Robert C. Martin perfectly describes, why the XP practices meet the Agile values and principles, but XP is just one of several applications of the Agile values and principles turned into practices.

The Cooperative Game

Alistair Cockburn introduces in the Cooperative Game the ShuHaRi levels of skillset development. The small words Shu, Ha and Ri are taken from the Aikido domain and Alistair maps them to the skillset in software development.

Shu

Shu means to keep, protect or maintain.

In the Aikido domain the Shu level is related to a student just beginning to learn the techniques. Therefore the Shu level is the entry point for new skills to learn. The student is taught to apply the techniques by copying them and follow the teacher’s advises by his words. The protection on the Shu level is to avoid early distraction of the student by the several existing techniques around. The student shall be able to focus on practical advises – on practices.

Ha

Ha means to detach and means that the student breaks free from the traditions.

After following the practices, the student starts to question the practices rather than doing just repetetive activities. At this second level it is realised what the underlying purpose of the initial teachings is. In the human grow-up process this stage could be compared to the puberty of teenagers, who start to question the practices they initially just copied from their parents and other children in their surrounding environment.

Ri

Ri means to go beyond or transcend.

On the third and last stage the student adapts the previously learned practices to meet his own style. While applying the principles she just became aware of, the underlying values are realised and followed.

Conclusion

Basically my current picture of Agile, XP and ShuHaRi consists of practices to follow on the Shu entry level of skillset development. When trying to get an Agile mindset, you need to start with particular practices on the Shu level. Since you just start to get into it, you need to learn the practices by the word in order to not get distracted by your previous working-habits and values.

On the Ha level there are principles which give you the reasons for particular practices. When the applications of the underlying practices got firm into your mindset, you will begin to question particular activities. You will only get to realise the underlying principles, if you have followed the practices on the Shu level long and thorough enough. This is the point in time when adaptation has taken roots. You should be now in place to see the larger picture behind your working-habits and be able to begin to change some of the details and try to fit variations of the practices to your particular circumstances. You should be able to start adaptation. For this phase to start it is essential to have followed the practices by the book – as strinkingly denoted in How To Fail With Agile.

After realizing what does work and what not through adaptation, you will be able to see the universal parts of your new skills. On the Ri level you will start implementing the values naturally without even thinking about them.

To conclude my proposal, the Ha level of skillset development builds a bridge between the Shu and the Ri level. On the Shu level you follow the practices by the book, on the Ha level you start to realise the underlying principles of the particular methodology you’re following and on the Ri level you see the whole world in values and start adapting your own style. This is the quintessence.

Outlook

Since I have a strong background in software testing, personally I would like to try to define practices on the Shu level, principles on the Ha level and values on the Ri level for software testers. Elisabeth Hendrickson, Lisa Crispin and Brian Marick did very good thoughts on the theses topics, but I have not seen the ideas structured as I tried to sketch here. If my proposal turns out to be valueable, this might become future work for Agilists.

Since I asked Alistair Cockburn to do a review of the text, he already was able to add a note on his blog on it. Thanks Alistair.

General

Everyone should read The Cooperative Game

Leave a comment

After slipping through some of the blog entries from Alistair Cockburn, I found the following entry: Everyone should be a methodologist. After slipping through the errors of early methodologist in part 2 of that entry, I realised, that I personally ran into point 2. and 3. lately. Likewise I see many times points 4 and 5 forced in my company. Thanks Alistair for reminding this to me. If you got interested by the content, I recommend reading Alistair’s book Agile Software Development – The Cooperative Game, which covers many, many more aspects.

Agile Testing, FitNesse

Not every hammer fits all nails

Leave a comment

I would like to refer to gojko’s latest blog entry, which made me a bit thoughtful. Here is the actual link I’m referencing: Using FitNesse pages as templates.

At my company we started back around easter to get rid of our old tests, which were

  • build on a script generator, which generated shell-scripts
  • had a “shared fixture” strategy with high interface sensitivity to nearly all DOC of the SUT
  • suffered from test chaining and slow tests

I’m glad I now know all those fancy words after reading through xUnit Test Patterns :-)

We started using FitNesse. Actually I was the only one in our five person team, who had read the book. By coming up with mechanisms to be able to use “Shared Fixtures” and re-use an add-on component of our SUT for test account maintenance, we introduced a good framework, which is easily extensible etc. Since we did not get the support from our developers, which would have been necessary, we had to find ways to compensate for that by introducing unit tests for our generic test helpers, using refactoring and so on.

Parallel to our approach a colleague started to build a framework based on FitNesse as well. At the moment there are

  • complicated long tables
  • high level of details
  • test table chaining

built into this test suite.

Currently I’m facing the situation, that we got the assignment to unify both approaches somehow. Since I’m pretty much convinced by the context-driven school of testing, I believe that both approaches have more or less a good reason to exist. After reading through gojko’s blogentry I think, that screwing up the system by not cooperating should not be a general solution. Since FitNesse has several ways to screw things up, stay aware of the hammer argument:

If I got a new hammer, everything looks like a nail.

Try realising instead that not every hammer fits to any nail.

Agile Testing

Introduction to Agile Acceptance Testing

Leave a comment

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.

Agile Testing

Comments on “The Fifth Element of the Agile Manifesto” and Agile Mainstream

Leave a comment

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.

Agile Testing

What makes testing Agile?

1 Comment

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.

FitNesse

Fixture Gallery 2.0

Leave a comment

Gojko Adzic has released another major release of his Fixture Gallery. Personally I found this gallery valueable when making the first steps using FitNesse for our test suite rework. If you’re looking for something, take this as an additional source of information on how to create tests and the according fixtures. Gojko additional covers several programming language of Fit and the FitLibrary, which makes it additionally valueable for a large audience. Simply see for yourself.