Category Archives: Methodologies

Methodologies

Agile Testing, Software Craft, Test Driven Development, Testing

My Definition of Done

2 Comments

Over the course of the Agile Testing Days I noticed that the definition of “Done” is troubling for Agile teams. It was not only raised in the Tutorial I took, but also on several key note speeches and there were several presentations that also dealt with it. Personally I was wondering why. During the last three days I thought “Done” simply means that you can make money with it. Sounds like an easy definition, isn’t it? If your customer or product owner is not willing to pay money for the user story implemented, it’s not “Done”. Period.

But today I came up with another, easier definition of “Done”, which was strikingly easy to realize in the end. For the definition let me put together several influences from Elisabeth Hendrickson, Adam Goucher, Kent Beck, and many more to a remarkably easy combination.

Elisabeth Hendrickson told me that “Done” simply means implemented, tested (or checked as Michael Bolton defined it) and explored. Very easy, isn’t it? But there’s more to it. Implemented means it is designed, and written in probably some programming language, right? Does this make sense? Considering my visit at the Software Craftsmanship Conference in February I noticed that it seems to be accepted – at least for the crafts people I met there – that implementation means to do it using Test-Driven Development. There was no discussion and arguing about this, it was simply taken as a fact and it was done in a TDD-style. But, remembering back Kent Beck TDD means Red – Green – Refactor, right? A three part meme, oh another one. Great.

The next term in Elisabeth Hendricksons definition of “Done” is tested (or checked). Considering current approaches to get the customer’s requirements using an Acceptance Test-Driven Development style, I would like to coin tested to mean, that we agreed on examples to implement and these examples serve as acceptance criteria in an executable manner. So, actually tested here means, that the code was able to pass the acceptance tests which were agreed upfront onto and were elaborated maybe by the testers on the project to also contain corner cases, which were missed. On Monday Elisabeth Hendrickson taught me, that ATDD can be thought of as Discuss – Develop – Deliver. Gojko Adzic corrected this over twitter to Describe – Demonstrate – Develop. But what do we have here? I claim that tested (or checked) here refers to ATDD style of development, which is itself again defineable as a tricolon itself. So, wrapping up, we have

  • Done is Implemented using TDD, Tested via ATDD and Explored
  • Implemented using TDD is Red – Green – Refactor
  • Tested via ATDD is Discuss – Develop – Deliver

(Forgive me Gojko, but I find Elisabeth’s definition more intuitive to remember.)

Oh, I got one more. Explored clearly refers to Exploratory Testing. It actually might be a coincidence, but Adam Goucher came up with a definition of Exploratory Testing today in a tricolon manner, too: Discover, Decision, Action. Sounds reasonable to me. During Exploratory Testing we discover information about the product which we previously did not know. Based on the information we decide what to do about this. Michael Bolton uses to ask me here: “Problem or not a problem?” so that I can decide, what to do next. Inform the next test executed about what to do. After that we take the next reasonable action based on the information we just recently found out about our product. To make the terminology more cohesive here, I propose to coin explored to mean Discovery – Decide – Act.

So, to wrap it up, just like we have Practices, Principles and Values in Agile, we learn using a Shu – Ha – Ri fashion (thank you Declan Whelan for saving the Agile Testing Days for me by mentioning it), we can define “Done” in this same manner:

  • Done is Implemented using TDD, Tested via ATDD and Explored using Exploratory Testing
  • Implemented using TDD is Red – Green – Refactor
  • Tested via ATDD is Discuss – Develop – Deliver
  • Explored using Exploratory Testing is Discover – Decide – Act
Leadership, Software Craft, Testing

Responding to Change

2 Comments

During my stay in the US during our vacations this year I was able to collect some notes and reflect on some stuff in the real world and compare it with software development occassionally. Today I decided to do a write up on the “Responding to Change” value of the Agile Manifesto.

While finishing the book The Pragmatic Programmer I got confronted with some concepts that I also noticed in the real world. Early on in the Design Patterns movement I learned to decouple my code as far as possible to allow change to happen. Craig Larman and Robert Martin early on got me into this thought process.

Being a European there were quite a bunch of things different in the US as here at home. Here is a list of things I noticed and I was wondering how hard it would be to change them in our software system. Luckily most of the things I wasn’t able to find at all, whereas most major variation points like currencies or tax systems were also thought on. How does your software respond to change it to the US system? What about selling your software to a European customer? For the testers and checkers among you, would you test that your software supports these? Do you test your software supports these? Does your software support them? Here’s the list, make the test, build up your mind and maybe let me participate in your findings.

Currencies There are a bunch of currencies I was confronted with. Euros of course, Deutsche Mark in the past (does anyone know what a “Groschen” is?), US Dollar, Pennies, Dimes, Quarters, Cents (does your software support the ¢ sign?), Disney Dollars (you can actually pay with it in Walt Disney World ressorts or take them as a gift for your mates at home), …

Tax Maps In the US every single state has a different tax model, even every county can have it’s own. In Germany there are different taxes applied usually, the lower one for food, the higher one for the rest. In Brasil there are 27 states each with their own tax model. Tax laws seem to be the most complex stuff.

Distances Meters, millimeters, centimeters, feet, inches, miles, kilometers, bavarian ells, english ells.

Area sizes Square feet vs. square meters.

Volume Litre, cubicmeters, Gallons to name just some.

Temperatur How many degress Celsius is one degree Fahrenheit? Is 90 degrees Fahrenheit hotter than 30 degree Celsius? What about Kelvin?

Fuel prices How much is 2.59 USD per Gallon in Euros per litre?

Consumption Is a fuel consumption of 28 Miles per gallon the same as 5 litres per 100 kilometers?

Voltages 110V vs. 220V vs. 400V, AC vc. DC.

What did I forget? What hard to change facts do you have to deal with?

Software Craft

People who influenced me

2 Comments

Over the course of creating the Ethics of Software Craftsmanship there was a statement included which tempted me to this blog entry for quite a while now. Here it is:

We can point to the people who influenced us and who we influenced.

At moment there are quite a bunch of craftspersons which influenced me. At the time I’m writing this I am working for three and a half years now in the Software business. Having finished university four years ago, I have gained a lot of experience from some great colleagues, which I never personally met, but which influenced me quite a lot. Today I decided to give you a list of these persons who might not know about their influence on me. I will divide the people into categories: Testing, Developing and Project Management. Personally I might also add Leadership in general, but due to my little experience in this field, I will leave this category out.

Continue reading People who influenced me →
Software Craft, Testing

Succeeding with project methodologies

Leave a comment

For my blog post Craftsmanship over Execution I had read about teams that were doing Agile, – i.e. Scrum – had practices – i.e. test-driven development. The point by that time concerned that another development team would hear “Oh, they succeeded with Scrum, let’s take Scrum and be successful, too!” There are several reasons why this is a bad idea and I decided to write about some of them.

Continue reading Succeeding with project methodologies →
Software Craft, Test Driven Development, Testing

XML Unit: assertEquals and fail

4 Comments

Some weeks ago I was challenged at work that led me to invent a unit test framework for xml files. After some basic first steps I decided to introduce the approach on my blog as well.

Motivation

Why did I need a unit test framework for xml files? Easy enough. Our product has an intense configuration consisting of several xml files for the customization part. On the current project I’m working on there is a configuration file which consists of about 18 Megabytes of customization in one xml file. Most of our other tests use to start up a full system (taking a bit more than 60 Megs of main-memory database in combination with oracle database persistence) and exercise the whole chain all through the system. Initially I tried to write a unit test using JUnit and JDom, but failed to have it executed in my IDE while the 18 Megs were trying to be loaded with an OutOfHeapSpace exception. Brian Marick had pointed out Assert { xpath } from Ruby some weeks ago and I started to consider this as an alternative. After realizing that nearly no one knows Ruby at my company and there would be drawbacks considering the way our company uses the Revision Control system, I forgot about these alternative.

Then I reminded myself on an approach using xsltproc and some stylesheets. Usability for our Continuous Integration framework was an issue, therefore I decided to produce an output similar to the JUnit XML reports, so these can be directly hard-wired. This blog entry will describe the first few functions that I built: assertEquals and fail. If there is a demand for follow-ups, I will try to come up with an approach similar to the Test and the Suite classes of JUnit. In the end a test runner will also be needed, which is currently handled by Makefile dependencies.

Continue reading XML Unit: assertEquals and fail →
Leadership, Software Craft

Misunderstood metrics

Leave a comment

My Miagi-Do school mentor Matt Heusser placed a blog entry on metrics today. Since I haven’t got the clear problem with metrics, I needed to contact him to fulfill The Rule of Three Interpretations. In our conversation I realized that he was referring to a concept, which I haven’t been experiencing in my three years of working as a software tester.

Generally spoken I was referring to metrics as using FindBugs, PMD or cover coverage tools on your software. For some time we have been using these for the framework that we grew on top of FIT for testing our software product. In combination with Continuous Integration you can see improvements and you can see where your project currently is. Is it in a good shape? Where might be holes? Which codepaths are not tested well enough? This feedback is essential for management to make the right decisions about the risks when delivering the product against your test results.

On the other side Matt refers to metrics on a different level. If your annual reviews and your salary gets decided upon management metrics, these are evil. The struggle I have is, that I am in the situation that I never worked in such a system where my personal performance and salary was based on some metric. Basically I can think of situations where this is evil. Here are a few:

  • A software architect getting paid by the number of architectural pages written.
  • A software developer getting paid by the number of lines of code.
  • A software developer getting paid by the number of software products finished.
  • A software tester getting paid by the number of tests executed/automated.
  • A software tester getting paid by the number of bugs found.

Speaking as a software tester, I would use a tool for generating the easy test cases that are easy to automated (I have been down this rabbit hole, I just realize, but wasn’t getting paid based on that) or use a spell-checker on our logfiles (I always wanted to do this, but didn’t because there are more severe problems than the correct spelling of some debug log messages). As a colleague uses to put it: When you measure something, you change the thing you’re measuring. Be careful what you measure, because it just might improve. When I understood these different meanings of metrics, I also got the problem.

Some time later I found the origin for the discussion. It is a recent statement from Tom DeMarco reflecting over 40 years of software engineering and measurements. Take the time to read. Here is the portion which I found most interestingly:

So, how do you manage a project without controlling it? Well, you manage the people and control the time and money. You say to your team leads, for example, “I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product. Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value, and doing integration and documentation and acceptance testing incrementally as you go.”

I believe that this will work. At least it will keep the team from being micro-managed and over-measured.

Software Craft

Mindful readings about Software Craftsmanship

Leave a comment

While looking through my personal backlog of blog entries, I found this one today. It cites a quotation from Uncle Bob Martin in one of his blog posts in April. Here is the quote:

I see software developers working together to create a discipline of craftsmanship, professionalism, and quality similar to the way that doctors, lawyers, architects, and many other professionals and artisans have done. I see a future where team velocities increase while development costs decrease because of the steadily increasing skill of the teams. I see a future where large software systems are engineered by relatively small teams of craftsmen, and are configured and customized by business people using DSLs tuned to their needs.

I see a future of Clean Code, Craftsmanship, Professionalism, and an overriding imperative for Code Quality.

The related article was named Crap Code Inevitable? Rumblings from ACCU. Today I remember, that I wanted to quote that article by that time to be a mindful reading. After having read over it again, this point is still pending.

First, the mentioning of doctors reminds myself of a visit at my doctor in May. I had a problem raising my arm after having exercised too much. After initially stating the problem, my doctor told me to stand up, raise my arm this way, rais my arm that way, raise my arm in another way, and then he had identified the problem. This was amazing when I realized that this way of analyzing a problem in the software is not as efficient. On the one hand it took him no more than 5 minutes to find the cause. On the other hand I realized his level of expertise at this. Clearly I doubt that there was a course back in university held, where my doctor learned this. Basically I consider that he knew how the muscles and fibers are connected with each other. But I clearly doubt that back in his university times there were practial courses where an injured patient with a problem in his arm like myself was asked and evaluated in front of the students. Likewise, even though I did not have a course on test-driven development, but I can take the conscious decision to apply it and communicate my intentions to my colleagues. For this to work I take my personal experiences with TDD and simply do it. Similarly this applies for Acceptance test-driven development. Every day anew I can take the decision to give the best I can in order to delight my colleagues and my customers. Personally I consider this to be an act of professionalism.

On the other hand the quote from above reminds me also about a problem I have just lately read about on Twitter from Brian Marick:

I detect a certain tendency for craftsmanship to become narcissistic, about the individual’s heroic journey toward mastery. People who think they’re on a hero’s journey tend to disregard the ordinary schmucks around them.

Heoric journeys are a problem. Mostly I refer here to an insight from Elisabeth Hendrickson and a work which I think was from Alistair Cockburn, but don’t know for sure anymore. The problem with our education system is that during school you’re the one that fights on your own during the exam courses. In the university it’s your work that gets graded. For PhDs this is even more dramatical (as I have been told, no personal experience with this, though). Then when you get into your first job, you are asked to do team work. But where should you have learned this? The whole value system that worked all of your life gets collapsed. So, what do you do about this? People being “inconsistent creatures of habit” create their walls around them making their work safe against the rants of others. But – and now comes my reply to Brian’s statement above – the Software Craftsmanship Manifesto states differently. Software Craftsmanship is about taking apprentices, teaching what you have learned, what has worked for you, build a community of professionals for valueable exchanges just like the teams from Obtiva and 8thLight has proven to us. This is our responsibility to do. This is professionalism in the sense of Software Craftsmanship and it’s among the things we value.

Software Craft, Testing

Testability vs. Wtf’s per minute

Leave a comment

Lately two postings on my feed reader popped up regarding testability. While reading through Michael Boltons Testability entry, I noticed that his list is a very good one regarding testability. The problem with testability from my perspective is the little attendance it seems to get. Over the last week I was inspecting some legacy code. Legacy is meant here in the sense that Michael Feather’s pointed it out in his book “Working effectively with Legacy Code”: Code without tests. Today I did a code review and was upset about the classes I had to inspect. After even five classes I was completely upset and gave up. In the design of the classes I saw large to huge methods, dealing with each other, moving around instances of classes, where no clear repsonsibility was assigned to, variables in places, where one wouldn’t look for them, etc. While I am currently reading through Clean Code from the ObjectMentors, this makes me really upset. Not only after even ten years of test-driven development there is a lack of understanding about this practice, also there is a lack of understanding about testability. What worth is a class, that talks to three hard-coded classes during construction time? How can one get this beast under test? Dependency Injection techniques, Design Principles and all the like were completely absent on these classes. Clearly, this code is not testable – at least to 80% regarding the code coverage analysis I ran after I was able to add some basic unittests, where I could. Code lacking testability often also lacks some other problems. This is where Michael Bolton, James Bach and Bret Pettichord will turn in heuristics and checklists, the refactoring world named these as Smells.

On the Google Testing blog was an entry regarding a common problem, I also ran into several times: Why are we embarrassed to admit that we don’t know how to write tests? Based on my experience project managers and developers think that testers know the answers for all the problems hiding in the software. We get asked, “Can you test this?”, “Until when are you going to be finished?” without a clear understanding of what “tested” means or any insight what we do most of the time. “Perfect Software – and other illusions about testing” is a book from Jerry Weinberg from last year, which I still need to read through in order to know if it’s the right book to spread at my company – but I think so. If a develoepr doesn’t know about the latest or oldest or most spread technology, it’s not a problem at all. If a tester does not know how to “test” this piece of code, it is. He’s blocking the project, making it impossible to deliver on schedule – escalation! What Misko points out in his blog entry is, that the real problem behind this is also testability:

Everyone is in search of some magic test framework, technology, the know-how, which will solve the testing woes. Well I have news for you: there is no such thing. The secret in tests is in writing testable code, not in knowing some magic on testing side. And it certainly is not in some company which will sell you some test automation framework. Let me make this super clear: The secret in testing is in writing testable-code! You need to go after your developers not your test-organization.

I’d like to print this out and hang it all over the place at work.