Some weeks ago James Bach began a series on Quality is dead. Since up to now he did not yet write up more of it, I get in touch with him via instant messaging. He explained to me that quality is dead, it cannot be brought back to live. How come?
Continue reading Testing quality into the productCall for peer reviews
In October I’ll have a session at the Agile Testing Days in Berlin. So far I have prepared an article, which has gone through two iterations of review already. Today I decided to seek more review comments on it before making it final. If you think you can help me and have some time to spare for a 10 page document, please drop me a line at shino at shino.de. Thanks in advance.
Cowboy Testing vs. The Cash Cow
Over the past week I was contacted by two persons, who described to me that their current employee was not doing any software testing activities at all before they joined the company. Ok, you might say, how many years or decades have past since then? Two years in one case and the other one is from this year. What? We have 2009, over 50 years ago software testing was coined interalia by Jerry Weinberg, and there are companies out there, who do not do software testing at all? Yes, this seems to be true. In addition I have a name for this: Cowboy Testing. What? I thought they’re not testing at all? Of course, professional software programmers who built the software are going to “try out” what they built. According to the case studies, these programmers were not using test-driven development, or automated testing, or even continuous integration, but there was some kind of testing like activity included into the software before shipment, otherwise these companies will truly run out of business.
Pradeep Soundararajan just blogged today about the Software Testing cash cow. This is the opposite side of todays testing activities. Companies go out and pay other companies for the lacks of their testing process. These companies do not seem to think about the outcome of their actions, since they get scammed by billed hours for extensive documentation and promises from the testing companies.
Personally I am glad to work in the middle of these two extrema. My company feels responsible for the quality of their work and knows that quality needs to be considered from the beginning of the project. Still, there are improvements possible. Basically I am a protagonist of test-driven development and try to introduce colleagues to it using Coding Dojos and Prepared Katas – with little to no success so far. There is still some more work left to do, i.e. in understanding The Composition Fallacy or Acceptance Testing using frameworks like FitNesse. But at least my company noticed the fact that we need to test our products and that this needs to be done by employed people within the company itself. Amen.
Meeting Principles
Yesterday I ran over a list from Esther Derby on how to improve meetings when you’re not in charge. Funnily I had compiled a similar list at our company some time ago divided into participant improvement actions and moderator improvement actions for meetings. The list is thought as a motivation compiled of optional things I can do to improve the meeting. The basic principle behind this is that I am allowed to do this and that with the intention if I’m not doing these things, I should not complain about ineffective meetings. Here is the list. I appreciate any kind of feedback.
As a participant of a meeting I am allowed to
Preparation
- … ask for a meeting agenda
- … prepare contemporary for the meeting
- … decline an invitation
- … look forward to the meeting
Performance
- … ask for an introduction of unknown participants
- … reflect on the agenda and the goal of the meeting
- … visualize
- … value contributions of other participants
- … get clarification on contributions of other participants
Wrap-Up
- … offer appreciation to the moderator or facilitator
- … work through the protocol
- … reflect on the course of the meeting
- … discuss personal discomfort
As a moderator/facilitator of a meeting I am allowed to
Preparation
- … provide a meeting agenda
- … communicate intentions and goals of the meeting
- … choose participants wisely and personally get in touch with them
- … prepare myself for the meeting
Performance
- … feel responsible for the success of the meeting
- … welcome participants
- … repeat the goal and the agenda of the meeting and ask for feedback
- … help meeting participants work effectively and efficiently
- … remind participants on agreed conversation rules
Wrap-Up
- … ask for feedback on the grade of success from participants
- … thank everyone for the investment of their time and knowledge
- … take care to monitor follow-up actions
- … reflect on personal facilitation and moderation abilities
Some links from the week
Ben Simo explains his view on Best practices related to the first two principles of the Context-driven school of testing and makes a fantastic conclusion:
No process should replace human intelligence. Let process guide you when it applies. Don’t let a process make decisions for you.
Seek out continuous improvement. Don’t let process become a rut.
Process is best used as a map; not as an auto-pilot.
Matt Heusser came up with some thoughts regarding failing Agile teams. Indeed some time ago Alistair Cockburn already discussed this topic in more detail. I found both quite worth reading.
Reactions on Tom deMarcos article in IEEE
Here is a wrap-up of the blog entries and articles that were written as a reaction on Tom deMarcos article in the IEEE.
Developer-tester, Tester-developer
During this week I watched the following conversion between Robert C. Martin and Michael Bolton on Twitter:
Uncle Bob
@dwhelan: If you’ve enough testers you can afford to automate the functional tests. If you don’t have enough, you can’t afford not to.Michael Bolton
Actually, it’s “if you have enough programmers you can afford to automate functional tests.” Why should /testers/ do THAT?Uncle Bob
because testers want to be test writers, not test executers.Michael Bolton
Testers don’t mind being test executors when it’s not boring, worthless work that machines should do. BUT testers get frustrated when they’re blocked because the some of the programmer’s critical thinking work was left undone.Uncle Bob
if programmers did all the critical thinking, no testers would be required. testers should specifying at the front and exploring all through; not repeating execution at the end.Michael Bolton
I’m not suggesting that programmers do all the critical thinking, since programmers don’t all of the project work. I am suggesting, however, that programmers could do more critical thinking about their own work (same for all of us). Testers can help with specification, but I think specification needs to come from a) those who want and b) those who build.
Over the weekend I thought through the reasoning. First of all I truly believe that both are right. Elisabeth Hendrickson stated this in the following way:
In any argument between two clueful people about The Right Way, I usually find that both are right.
Truly, both Uncle Bob and Michael Bob are two clueful people. In the conversation above they seem to be discussing about The Right Way, and I believe they are both right – to some degree, in some context, depending on the context. Basically this is how I got introduced to the context-driven school of testing.
The clueful thing I realized this morning was my personal struggle. Some months ago I struggled whether I am a tester-developer or a developer-tester. Again raising this point in my head with the conversation between a respected developer and a respected tester opened my eyes. Three years ago I started as a software tester at my current company. Fresh from university I was introduced into the testing department starting with developing automated tests based on shell-scripts. Finally I mastered this piece and got appointed to a leadership position about one and a half years later. Until that point I thought testing was mostly about stressing out the product using some automated scripts. Then I crossed “Lessons Learned in Software Testing” and got taught a complete new way to view software testing.
The discussion among these two experts in their field raised the point of my personal struggle. Testing is more than just writing automated scripts. Over and over executing the same tests again is a job a student can do. It’s not very thought-provoking and it gets boring. Honestly, I haven’t received a diploma in computer science (with a major in robotics) to stop thinking at my job. Therefore I got into development topics. Since our product doesn’t include good ways for exploratory testing, I came up with better test automation. Basically the tools I invented for the automated tests also aid in my quest to be good as an exploratory tester.
So what was I struggling with? Basically I realized that on my job the programmers get all the Kudos. That’s why I started investing time in becoming a better programmer. Meanwhile I found out that it’s also a fun thing to do. You can see the results whenever you run your programs. This is why I never gave up looking at code, dealing with it. Sure, it’s not what Michael Bolton or Jerry Weinberg mean with software testing. On the other hand it’s what I would like to do.
Basically I consider myself a developer for software test autmation. I have a background in software development and I have an understanding of software testing. (I leave it up to my clients and superiors whether I’m a good one or not.) In the way I understand my profession it’s necessary for me to know about both sides. This is also why I now realized that I am a tester-developer, not a developer-tester. As I just realized my personal struggle comes from the aspect that I am not sure, whether I really ever was a software tester or not. But for sure I have started to become a developer.
In order to conclude this posting with the initial discussion from the two experts in their fields, there is one thing left to say. As a software tester you may choose to become a developer of test automation. Robert Martin refers to these kinds of testers. On the other hand as a software tester you may choose to become a tester who applies critical thining. Michael Bolton refers to these kinds of testers. Whether or not to choose one path over the other may be up to you.
Misunderstood metrics
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.
Mindful readings about Software Craftsmanship
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.
Something new
Today I decided to join it: Twitter. After spending some time playing around with some settings and searching for some interesting people to follow, I am still wondering what makes people curious about it. What made me join then? Today I got a notice on Xing about the XP Days Germany on Twitter. Curiosity killed the cat. Personally I decided to try it out for some time and see what might happen. I included my updates on the right, as you might have noticed.