Responding to Change

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?

Lesson 12: Never be the gatekeeper!

Adam Goucher wrote today a blog entry on being the gatekeeper as a software tester. Adam writes that it is a bad idea to be the gatekeeper, but there are of course situations where you can’t refuse to play the game of being the gatekeeper in software testing.

The topic line is taken from Lessons Learned in Software Testing. James Bach, Cem Kaner and Bret Pettichord reason pretty well about this. In a private conversation with Michael Bolton we indentified that “ship it” or “don’t ship it” is a business decision and thus far I wasn’t able to make these sort of business decsisions due to lack of particular knowledge and influence about the project, the development methodology, etc. Maybe there is something more to come for me, but in my roughly three years of experience as a software tester, I never was in the position to make these decisions.

Particularly why Adam’s blog entry raised my attention is that I was faced a gatekeeping situation lately at work, and I refused to be the gatekeeper there – for good. Over the past few months we had a big deal to work with in order to get the project off the shelf which we worked on over the complete year. Of course, there is a customer, which has stated intentions to give some of his money to us, if we finish this off properly. We are delivering our software to another company which is then installing it for the customer. None of the three companies – the customer, the company we’re delivering to and ourself – seems to have a proper picture of the business logic of the customer. All we get is data dumps from the legacy system which we then convert and adapt for our product.

Over the project course I was faced with the situation that the data dumps we got were incomplete. We were realizing a change request and needed that data dump, the changes should be delivered by the next business day. The software was going to get shipped and right after sending it to our colleagues we realized there were severe gaps in the data we got. So, what to do about it?

  • Be the gatekeeper, disapprove the delivery and wait one week for the next data dump.
  • Raise the point to the project manager and let him make the decision about this business issue.

Clearly the first option was never considered by myself, so I stuck to the second option for good. This case should make the point clear why gatekeeping as a testing is no good option to give in. If I had made the decision to not install the change request which was pending for over one or two months, the business would have been blocked, we would have gotten the full blame. On the other I would have gotten the blame when we delivered the software and I let it go through in the gatekeeper role and it did not work properly. On a side note, the project is spread between Germany and Brazil with a pretty five hour timezone delay between the two locations, which makes communication hard.

How would you have reacted? Maybe there is an option I oversaw here or did not consider since it seemed too stupid in first place.

People who influenced me

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

Succeeding with project methodologies

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

The tested checker

Michael Bolton brought up a series of blog entries on Testing vs. Checking recently with follow-ups here and here. He perfectly explains the differences between the mindful job of testing and the checking attitude. While both have a reason to be done, checking is too often confused with testing. From my experience this has a negative impact on how testing and testers are perceived by the organization around them. If people in the organization get told about testing and indeed have checking in mind, the lowered expectations about testing gives a negative impact on respect towards this mindful and thought-provoking activity.

Michael defines testing as a sapience based activity. You need the human to perform it. On the other hand checking is a pure act that anyone can do – even the computer. Based on my work experience, usually we think up new test cases, which we then start to automate and put into our revision control system and have them run on a regular basis. The former, the invention of the test case, is a testing activity. You need a human for this, since we are not capable of automating this step in our software development cycle. The latter, the mere execution of the automated test is a checking activity. Any computer can do this, and mostly we have this even done in our continuous integration server without required attendance of a human. If something goes wrong, well then we could have a problem and need a human to investigate in the test result and whether or not we have a problem with this outcome. This again is a testing activity.

This is not everything we do as testing activities, of course. There are documentation reviews, bug reporting, etc. that also needs to be done on our course. These also require a sapient to conclude. (I thought about automating that bug reporting in the past directly when an automated test case fails, but didn’t do it – so far.)

Matt Heusser noticed recently that there are few blog entries on testing recently. Personally I have cut my blog posts in the last two weeks down since I had to work on my submission for the Agile Testing Days conference in Berlin in October. There is bunch of blog entries I would like to point my readers to that I have piled up since then. In case you’re seeking for new testing blogs to read, Matt has compiled a list of worthy blogs in his entry on best new software test writing.

Finally I would like to point out to Joe Harters blog. Yesterday he made a great first post. Worthwhile to read and a great story on how to teach testing to your colleagues.