Archive for the ‘Software Development’ Category
Create Quality
June 7, 2007, No Comments
Recently I was at an event from the company I worked for. The topic of the event was: “Creat Qualityâ€
Creating quality is something that is very much at the core of agile development processes and as a programmer is very important to me. My expectations were very high.
After the event I was disappointed. The talks were filled with waterfall-centered thoughts and how a testmanager can help create quality in that environment.
But as long as you think in waterfall, testing will always come after implementation and way after design. And I mean that in every possible way:
Testers opinion count less
Testers (often) get paid less
Generally, testers are less important because they “only use the software and report bugsâ€
No amount of reviews, checklists, metrics will change that. What you have to change is the way software is created. Where the tester, the programmer, the project manager and the customer representativ/analyst/product manager are all equals.
You can’t reach this in a waterfall, because by definition these roles don’t work together - they work after each other. You can try to circumvent waterfall by including the testmanager early - but he’ll always be “out of his phaseâ€. This means, he’ll be tolerated and if he steps too far, the “phase owner†(*) won’t be happy.
I was very surprised that agile methods didn’t find more friends among Testers (at least the ones I know). But I think I understand now:
If your company really wants to create quality software, it doesn’t need more testers.
What agile methods promise seems to somehow make the testers job disappear. There is no testing phase, so where are the testers? How should it be possible to develop software with few defects without a test phase?
Yes. Agile Methods kill the test phase. But it needs testers and it requires them from day 1. Automated tests are important in XP and in many other agile methods. Customers and programmers mostly think about the “happy pathâ€. Somebody has to help them think of missing tests. Somebody has to help them think of ways to test complicated things automatically. Somebody has to let them know that the software created in the last iteration wasn’t up to the quality standards the team wants to deliver. Act on that information and help fix the problem.
(*) I use “phase owner†as the person who has to say how one phase is run. This may be the Senior Designer for the Design Phase or a Chief Programmer for implementation. Whoever, don’t go to their office and try to tell them how to run the show.
OutputStream already obtained
September 8, 2005, 1 Comments
We stumbled over the following exception today:
java.lang.IllegalStateException: OutputStream already obtained
at com.ibm.ws.webcontainer.srt.SRTServletResponse.getWriter(SRTServletResponse.java:516)
at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:202)
which was caused by a Java Server Page that looked like this:
< %@ page contentType="text/html; charset=ISO-8859-1" % >
< %
response.getOutputStream().write("This is a test".getBytes());
response.getOutputStream().flush();
response.getOutputStream().close();
% >
This produces the following error:
This is a testError 500: OutputStream already obtained
The application server was IBM WebSphere 5.1.0. What made this error so strange is the fact that the JSP was already running successfully in production. The only change we made was cosmetical. It used to be:
< %@ page contentType="text/html; charset=ISO-8859-1" % >< %
response.getOutputStream().write("This is a test".getBytes());
response.getOutputStream().flush();
response.getOutputStream().close();
% >
(Please notice that there is no CR/LF in this code)
Which produces the expected:
This is a test
And yes, this JSP runs exception free. Why should the CR/LF make such a difference? In HTML and Server Pages you are usually allowed to make as many CR/LF as you want – it makes no difference.
Well, this one makes all the difference. Some googling told me that getOutputStream throws this Exception if getWriter() was called before. While we don’t call getWriter(), the CR/LF probably generates a line in the servlet that reads something like this:
response.getWriter().println("\r\n");
Even worse: The following doesn’t work properly, either:
< %@ page contentType="text/html; charset=ISO-8859-1" % >< %
response.getOutputStream().write("This is a test".getBytes());
response.getOutputStream().flush();
response.getOutputStream().close();
% >
(There are additional CR/LF at the end of the file)
Which produces:
This is a testError 500: OutputStream already obtained
There is no possibility to see this problem in the JSP. And that is highly annoying.
Of course Jakartas Tomcat runs both Server Pages without problem and that’s the way it should be. In Tomcat the writer is ignored and the OutputStream wins. This may produce wrong output, but at least you have the chance to find the bug…
Requirements document vs. Story Cards
June 5, 2005, No Comments
This article was heavily inspired by Lukas Kraus talk about: “Requirements: Clear and testableâ€. He pointed out that it is very important to have a test-manager on the requirements gathering team. His job should be to make sure that requirements are detailed enough that they can be tested later.
I agree that being able to test requirements is important. I don’t agree that the way to achieve this is by writing more details into the requirements document.
Having everything written down in great detail is one extreme. Let’s have a look at the other extreme.
Some might have heard that extreme programming doesn’t use a requirements document. That’s true. Partially.
In extreme programming requirements aren’t written down in details. They are vague. Written on a card, that might even be thrown away later.
That has its reasons of course. One is that if the feature turns out not to be important, you didn’t waste time on defining it. Another one is to delay fixing the details until the last possible minute - increasing flexibility and helping to make good decisions with regard to the things that were already built. These two ideas were adopted from lean manufacturing.
The nature of the story card becomes clear once it is time to write the code for it. Before any code is written, a conversation takes place. The customer explains exactly what he wants (face to face).
Now you might wonder how the tester (or anybody) is supposed to know what was discussed and what the software is supposed to do. That is after all, the big advantage of a requirements document. The answer has two parts. First, the tester is part of the discussion. Second - and let me emphasize this - no user story is complete without automated test cases. The test cases if properly defined become the requirements document. Not just any kind of requirements document. It is an executable requirements document.
Yes, I mean that. You click a button and your requirements document tells you exactly which features are currently correctly implemented.
Can your requirements document do that for you?
see also: Testing unclear requirements for an example
Thoughts about code readability
May 15, 2005, No Comments
There is one thought that crossed my mind: Since braces do nothing, they are basically a waste. Python recognized this and uses indentation to create blocks.
The following is a very common method in Java programs:
public void setName(String name)
{
this.name = name;
}
This method isn’t very significant for the program and it’s very unlikely to contain a defect. My editor window shows about 40 lines - after that I have to scroll down. Now a method that is insignificant and is unlikely to have a defect takes up about 10 % of the available space. Even worse I might have 9 other instance variables that need encapsulation desperatly, so I end up having a page of setter methods. If I want to see what the class really does, I have to scroll.
From that point of view, the following is better, but not much.
public void setName(String name) {
this.name = name;
}
One line saved per setter or getter. But it really doesn’t solve the problem. Why waste even three lines of code for doing almost nothing?
There is another problem with those getters and setters: clutter. If one of the setter methods does something more than just setting the instance variable it might be lost on first sight in the noise the others provide. Here is a class with a few attributes that are encapsulated by getter and setter methods. Answer as fast as possible: Which attribute(s) can’t be set and which method isn’t your normal “getter” method?
public class Test
{
private String firstname;
private String lastname;
private String address;
private String city;
private String country;
private String title;
private String size;
private String haircolor;
public String getAddress()
{
return address;
}
public String getCity()
{
return city;
}
public String getCountry()
{
return country;
}
public String getFirstname()
{
return firstname;
}
public String getHaircolor()
{
return haircolor;
}
public String getLastname()
{
return lastname;
}
public String getName()
{
return getFirstname() + getLastname();
}
public String getSize()
{
return size;
}
public String getTitle()
{
return title;
}
public void setAddress(String string)
{
address = string;
}
public void setCity(String string)
{
city = string;
}
public void setFirstname(String string)
{
firstname = string;
}
public void setHaircolor(String string)
{
haircolor = string;
}
public void setLastname(String string)
{
lastname = string;
}
public void setSize(String string)
{
size = string;
}
public void setTitle(String string)
{
title = string;
}
}
OK. Most getters and all setters were generated by Eclipse - you might be able to do better manually. The class already contains 100 lines of code that do pretty much nothing. Things get even worse when you write a documentation comment for each method (especially if it says something meaningless like “sets the size”)!
Same class, same questions, different style:
public class Test
{
private String firstname;
private String lastname;
private String address;
private String city;
private String country;
private String title;
private String size;
private String haircolor;
public String getAddress() { return address; }
public void setAddress(String string) { address = string; }
public String getCity() { return city; }
public void setCity(String string) { city = string; }
public String getFirstname() { return firstname; }
public void setFirstname(String string) { firstname = string; }
public String getHaircolor() { return haircolor; }
public void setHaircolor(String string) { haircolor = string; }
public String getLastname() { return lastname; }
public void setLastname(String string) { lastname = string; }
public String getTitle() { return title; }
public void setTitle(String string) { title = string; }
public String getSize() { return size; }
public void setSize(String string) { size = string; }
public String getCountry() { return country; }
public String getName()
{
return getFirstname() + getLastname();
}
}
The class shrinks to about 50 lines of code, does the same thing and above all, points out the important parts of this class. It almost fits on one screen, too. A bit unfamiliar maybe - but nothing you wouldn’t be able to get used to.
Of course, if you dare to ignore general wisdom of encapsulation you can make it even clearer:
public class Test
{
public String firstname;
public String lastname;
public String address;
public String city;
public String title;
public String size;
public String haircolor;
private String country;
public String getName()
{
return firstname + lastname;
}
public String getCountry()
{
return country;
}
}
I know this is considered absolutly evil and has some drawbacks. But if you look at it in isolation, you can clearly see the beauty of it. You have the same information on 20 lines (= half a screen).
If you just considered ease of reading, which version would you choose?
War of the braces
March 2, 2005, No Comments
Programmers care about where the braces are put. Deeply. The main reason for that is familiarity - the code looks weird if you do it in a different style
I’m not here to argue for one way or the other. I’ve done it both ways and you know what? It doesn’t matter. After a few weeks your eye has grown accustomed to the new style. The braces are not important - the importance lies in the indentation. Here is an example:
class Test
{
public int zahl = 0;
public String s = 1;public void do()
{
for(int i=0; i < 10; i++)
{
for (int x=0; x < 10; x++)
{
if (zahl < 20)
{
zahl += x;
}
else
{
zahl += i;
}
}
}
}
}
This is just as hard to read as:
class Test
{
public int zahl = 0;
public String s = 1;public void do()
{
for(int i=0; i < 10; i++) {
for (int x=0; x < 10; x++) {
if (zahl < 20) {
zahl += x;
}
else {
zahl += i;
}
}
}
}
}
On the other hand, if you cut all the braces and put in indentation the code is a lot clearer:
class Test public int zahl = 0;
public String s = 1;
public void do()
for(int i=0; i < 10; i++)
for (int x=0; x < 10; x++)
if (zahl < 20)
zahl += x;
else
zahl += i;
So what I’m saying is: Don’t worry about where to put the braces. Just do whatever the rest of the team does - it’ll work out fine. If your team can’t find a concensus, play poker or something - the winner gets to decide.