In the past week I started a new blog – this time in German. I will keep both my English and my German one, but might write less here in the near future. If you’re interested why I started a German blog, I left some reasons on first post. In case you’re unfamiliar with German, you might want to read on.
I dropped out of English classes in the 11th grade. Yeah, I did that. Skip forward 15 years, and I find myself having written several articles in English, contributed a chapter to a book, and eventually wrote one in English on my own. How did I do that? I think that an English blog made a contribution to that.
Now, as I want to know whether I am capable of publishing even more in German. I see some demand for that, and I see a difference between my English-speaking audience and the problems in Germany I face. The second and third entry on my German blog for example describe the issue of congruent communication as well as how to define a problem, and that not the problem is the problem, but our inability to cope with the problem.
That said, I will keep both blogs, and will deal with different topics on the different blogs. I won’t translate between the two most of the time – but leave myself the option open. So, if I raised your attention, you wouldn’t be the first to use an online translation on my blog, I think. :)
The other day on twitter I asked
What questions do you ask during an Exploratory Testing session debriefing?
Since I didn’t any replies on this at all, I figured it’s time for me to come with some ideas on my own. Let others work doesn’t work on this one.
Continue reading Questions to ask during Debriefs
Chris McMahon is organizing currently a peer conference on Writing about Testing. Please spread the word, since I believe it to be a good way to hone our craft and spread the word to future generations of great testers. The intended speakers are writers in the testing fields. Blog writers, article publishers, etc., etc. Overall Chris seems to be well prepared for such a conference and I hope I can either make it to his one or get to organize one myself.
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.
Since I swtiched to WordPress a few weeks ago, I observed comments to my entries. I realized that there are none. James Bach pointed out a misconfiguration to the comments requiring everyone to login before being to comment on entries. Unaware oft his issue I changed the settings this morning, hoping for more comments to come. Thank you, James.
Today I switched to WordPress and happily migrated all entries from the previous blog to this one. Please mind to update your rss-feed in case you subscribed to my old feed.
Lisa Crispin motivated this morning an entry on What I’d go back and tell myself. Compared to Lisa I would like to get back a few years more towards my time in university that started in 1999 (yes, I’m not that old zealot). At the time around 2001 I took a course called Software practical that was divided in a theoretical leacture and a practical group work to build a system. During the lecture there was eXtreme Programming mentioned as a new technique with a delightning practice called Test-driven development. By that time I did not get the point and it took until 2008 to realize the benefits of test-driven development. Going back to 2001 or even 1999 I would tell myself that I really should read about test-driven development, refactoring, design patterns and unit tests and dive into more topics. Nearly two years from now I started to read on these things and get the ideas from the great books out there. Currently I feel the need to get even with the books, but am really overwhelmed so far from the pile of books that lies in front of me.
Another thing I would like to tell myself going back into the past, is that I will truly make a good start in software testing and development and see the opportunities to improve my work. Going back to 2005 I would tell myself, that I should not waste the time to investigate on PhD positions at the universities, but rather get some real hands-on in the business. Most of practices and techniques I use today I learned when I was out from university and I’m glad to have learned all this stuff.
While reading the excellent xUnit Test Patterns book I was introduced to the idea that making something less private on a class in order to get a test for it in place may break encapsulation for good. While this pattern ensures that you just have a single instance of a configuration or memory consuming object in your production system, you will have a problem with unit testing it. The xUnit book provides a pattern to make this easy. However, the Substituted Singleton pattern relies on the fact that you don’t define the singleton instance on your original class as private, but rather as protected, so you can override the instance by a subclass where you have influencing methods so you can influence your test behaviour directly. This breaks the encapsulation of the class you wrote for production use, but for good, since you can now test all your users of that singleton class rather than needing to do some special treatments of your environment in order to achieve the same. A similar reasoning can be applied for not using the final modifier on classes. These ones you will not be able to test by then, too. When deciding to do just this, you’re trading off the ability to unit test your code and show that you produced a good quality while doing so and communicating your intents for the next programmer having to deal with your class by breaking encapsulation in your class hierarchy. The first overweighs the second here.
Currently I am faced with a similar situation at work in a different context. We use Perforce for version control at work. This tool is able to indirectly track renamed files not directly – you have to do an integrate to produce a copy with a new name and delete the old file afterwards for that. The current eclipse plugin for Perforce does not cope with this. It just deletes the old file after having created the new file and opened that one for add. By submitting this change you loose the version history and cannot see anymore that the previous name of a class was Foo and is now Bar or that initially you had put up the class in the package foo.bar and now is placed in foo.baz. One of my colleagues realized this and now mandates that we should do a semi-manual refactoring for these kind of operations (rename class, move class). Personally for me the same trade-off as for encapsulation of fields in singletons exists here. Having tool support for doing these refactorings completely automatically is a big win and I can live with the fact that I will not obviously see where the file was coming from in the version history. The class was renamed to hopefully some good reason – i.e. to communicate intent in a better way or to have it placed under a package, where it is reasonable. On a side note all the history I would need should be placed in the unit tests for the classes. This trade-off is fine for me and I don’t see good reasons to get into the semi-automated process of manually integrating a file in the version control system, just to see the complete history of the file. It’s fine if I just see, “Oh I added that file and deleted that one in the first change to that file, seems like a renaming operation.” and follow-up on that file if needed (I don’t read the revision history often – most of the time I don’t have to.)
While the values might just seem to be a list of higher level goals with no direct outcome on the particular project, there is a lower level of definition in Agile methodologies: Principles. From Elisabeth Hendrickson and Lisa Crispin & Janet Gregory I was able to construct a list of useful principles. Here is the first half of this list of testing principles.
- Provide Continuous Feedback
Feedback is one of the higher values for sucessful projects. As Poppendieck & Poppendieck pointed out in Lean Software Development – An Agile Toolkit feedback is vital to software development. They compare software development and manufacturing with cooking: While development or engineering means to come up with a recipe, manufacturing is just applying over and over the recipe that is already there. Since software development is a recipe building action, it needs iterations and feedback to be successful.
From this perspective testers provide feedback from the customer point-of-view into the programming activities. Likewise they provide feedback as a substitute for the end-consumer by adding exercising tests – may these be manual or automated. Like the memory structure in the current computer systems, testers can be thought of as the cache towards production for each program increment. This does not mean, that testers are the gatekeepers for any software deliveral. This rather means, that they can provide timely feedback to the programmers, rather than opening or closing the gate towards production. By addressing issues before the software gets into production, the feedback for the programming team is achieved in an efficient manner for them to learn.
- Deliver Value to the Customer
Testers are the bridge between the programming team with its technical terms and the customers with their business language. By incorporating a solid ubiquitous language into the test cases, these two worlds can get closed and guarantee transparency for the customer. This higher level goal can be achieved by working directly with the customer on test cases and likewise giving feedback to the team members who are developing the software the customer ordered. A test which is twisted up with complex logic is no value for the customer. A test case turning business terms green when it’s passing on the other hand is. Testers provide the service of filling the communication gap between technical software development and the business of the end user.
- Enable Face-to-Face Communication
Alistair Cockburn points out the principle, that two people at a whiteboard are communicating more efficient than two people over email or videotape. He visualizes this principle in a well understandable manner. When considering software testing, a tester should therefore motivate and enable direct communication forms wherever possible. When two people are talking face-to-face on a difficult requirement, they efficiently get a common understand of it. Therefore tester should enable direct communication to customers, to developers, to department heads, to project management, …
Lisa Crispin and Janet Gregory introduce the Law Of Three in their book on Agile Testing. The Law Of Three states, that any design decision or requirement discussion need to involve one person from all of the three groups: customers, developers and testers. Whenever a discussion is started, a decision need to involve all affected groups. Direct face-to-face communication supports this law by building up efficient communication channels between the three.
- Keep it Simple
Simplicity is a key in Agile Software Development. Without the waste of usual software processes teams maintain their ability for agility. This directly means to keep your test cases as clear as possible. Additionally through simplicity you enable your team to understand your tests and be able to adapt it if the business demand this. Just like the Collective Code-Ownership practice in eXtreme Programming, testing teams have the demand for collective test case ownership. Just through simplicity you not only enable your co-testers, but also the business analysts, developers and customers to adapt test cases when the situation asks for this.
- Practice Continuous Improvement
This principle is simply demanded by the craft aspect behind Software Development. Just like any new cool programming language or technique, testers should keep their improvement potential up-to-date. By visiting conferences on test techniques or latest test automation tools, a tester can improve her skills in these areas. This also means, that learning a new programming language or test technique such as performance- or load-testing is a way to improve one’s own abilities. Learning a common language to express testing patterns is another example of it. By providing this pattern language to your teammates, you enable them to learn from you and additionally you improve your speaking skills. These are just some parts of your daily work where you can practice improvement on yourself and your team. Look out for additional possibilities.
- Reduce test documentation overhead
As Mary and Tom Poppendieck pointed out in Lean Software Development – An Agile Toolkit wasteful tasks should be avoided in order to have the highest possible return on investment. This means reducing test plans, test design documents and test protocols using tool support and ubiquitous language to a minimum. This does not mean to drop any test documentation. Rather your team and your customer should be brought in to the discussion of the level of necessary documentation. In case you’re working in safety critical software or your organisation demands it due to CMMI or ISO9000 compliance, you will be forced to use more extensive test documentation. Look out for ways to reduce these to a minimum and avoid wasteful documentation, which needs adaptation to the current situation every week or even on a daily basis.