Jay Fields has a poignant but concise style to express his opinion.
Currently my two favorite quotes are:
We're still figuring this stuff out. All of us.and
When no one knows what's "correct", people with confidence generally win the discussion.
Monday, November 16, 2009
Poignant statements about our profession
Jay Fields has a poignant but concise style to express his opinion.
Currently my two favorite quotes are:
follow me on twitter, I need some friends :-)
Labels:
programming,
quote,
work
Wednesday, November 11, 2009
A note to all software project stakeholders: Remember it is not christmas!
Peter Stevens hit the nail on the head at the SAQ Software Tester Forum 2009 last week:
That's a fact. Accept it.
Actually you can get everything you want if you have unlimited time and money. But since that is not the case in todays software projects (maybe there are exceptions?), we have to make tradeoffs.
And that is where the strength of Agile Software Development comes into play.
Agile advocates constant feedback and prioritization. Together with the 'good enough' and YAGNI principles this helps to create better usable systems within budget and time constraints (eliminate waste in the lingo of the lean).
Peter Stevens then talked about how goals can still be achieved, even without getting everything we want. His presentation can be downloaded here.
Later on, in an interesting conversation Andy Palmer pointed out that even when a MoSCoW (Must, Should, Could and Won’t) analysis is done, still a lot of projects finally only deliver a fraction of the actual 'Musts' ... and are still considered as a success. What does this tell about our prioritization?
You won't get everything you want!
That's a fact. Accept it.
Actually you can get everything you want if you have unlimited time and money. But since that is not the case in todays software projects (maybe there are exceptions?), we have to make tradeoffs.
And that is where the strength of Agile Software Development comes into play.
Agile advocates constant feedback and prioritization. Together with the 'good enough' and YAGNI principles this helps to create better usable systems within budget and time constraints (eliminate waste in the lingo of the lean).
Peter Stevens then talked about how goals can still be achieved, even without getting everything we want. His presentation can be downloaded here.
Later on, in an interesting conversation Andy Palmer pointed out that even when a MoSCoW (Must, Should, Could and Won’t) analysis is done, still a lot of projects finally only deliver a fraction of the actual 'Musts' ... and are still considered as a success. What does this tell about our prioritization?
Labels:
agile,
javablog,
methodology,
programming
Monday, November 9, 2009
Testing: Chances and Challenges in an Agile World
Last week I gave a presentation on the SAQ Software Tester Forum 2009:
The stage for my presentation was very well set by Andy Palmer and Peter Stevens who talked both about Acceptance Test Driven Development and about Agile Development in general.
In the afternoon there were several discussion sessions. Generally people wanted to know what the major changes there are in agile projects concernig testing.
A lot or the participants were very eager to affirm that Agile does not change anything concerning testing. Somehow I got the feeling that there was a fear that Agile is claiming that traditional testing is somehow outdated or superfluous...
In my opinion this is definitely not the case. Solid testing practices and processes are even more important in Agile projects. What changes is the timeline! This however has implications on the amount of work (a lot more test effort aggregated over the whole project) and it is a challenge for tester how to deal with this. But it does definitely not change that testing in all flavors (automated, manual, guerillia ...) is still a must.
If I look at requirements engineering, development and testing as three separate disciplines in software projects, then I would argue, that Testing is actually the discipline that is the least affected by Agile.
Most of the participants however were very focused on their current situation and activities and not seeing the big picture. Tests to assert quality is and will always be important. But testing can be more than quality assurance! Tests can be leveraged to prevent defects. Of course this is not necessarily bound to Agile, but Agile explicitly supports those notions.
One consequence of these ideas however is that developers and testers have to interact intensely and there is no place any more for traditional boundaries between testers and developers! Agile promotes multifunctional teams. This however does not mean that there are no specialized testers any more, but they are part of the same team as the developers and all have the common goal of producing useful software. Games of queen of spades between developers and testers definitely have no place in an Agile project!
In the final panel discussion Peter Stevens pointed out another perspective, that shows that testers can greatly profit from Agile:
In traditional enterprisey environments the salary curve is usually inverse proportional to the distance to the customer. Testers sit at the end of the chain, with the greatest distance to the customer. This setup can change drastically with Agile ideas like formulating Acceptance Tests with the customer, moving Acceptance Tests to the beginning of development and driving development with Acceptance Tests. Open minded testers can seize this chance and redefine their role in the organization hierarchy!
Testing: Chances and Challenges in an Agile World (most slides in english...)
Update 2009-11-11: Here are some pictures of the event.
The stage for my presentation was very well set by Andy Palmer and Peter Stevens who talked both about Acceptance Test Driven Development and about Agile Development in general.
In the afternoon there were several discussion sessions. Generally people wanted to know what the major changes there are in agile projects concernig testing.
A lot or the participants were very eager to affirm that Agile does not change anything concerning testing. Somehow I got the feeling that there was a fear that Agile is claiming that traditional testing is somehow outdated or superfluous...
In my opinion this is definitely not the case. Solid testing practices and processes are even more important in Agile projects. What changes is the timeline! This however has implications on the amount of work (a lot more test effort aggregated over the whole project) and it is a challenge for tester how to deal with this. But it does definitely not change that testing in all flavors (automated, manual, guerillia ...) is still a must.
If I look at requirements engineering, development and testing as three separate disciplines in software projects, then I would argue, that Testing is actually the discipline that is the least affected by Agile.
Most of the participants however were very focused on their current situation and activities and not seeing the big picture. Tests to assert quality is and will always be important. But testing can be more than quality assurance! Tests can be leveraged to prevent defects. Of course this is not necessarily bound to Agile, but Agile explicitly supports those notions.
One consequence of these ideas however is that developers and testers have to interact intensely and there is no place any more for traditional boundaries between testers and developers! Agile promotes multifunctional teams. This however does not mean that there are no specialized testers any more, but they are part of the same team as the developers and all have the common goal of producing useful software. Games of queen of spades between developers and testers definitely have no place in an Agile project!
In the final panel discussion Peter Stevens pointed out another perspective, that shows that testers can greatly profit from Agile:
In traditional enterprisey environments the salary curve is usually inverse proportional to the distance to the customer. Testers sit at the end of the chain, with the greatest distance to the customer. This setup can change drastically with Agile ideas like formulating Acceptance Tests with the customer, moving Acceptance Tests to the beginning of development and driving development with Acceptance Tests. Open minded testers can seize this chance and redefine their role in the organization hierarchy!
Labels:
agile,
BDD,
javablog,
programming,
testing
Monday, November 2, 2009
Quick Tip: Running Selenium on OS X Snow Leopard
Probably it is not only a Snow Leopard thing. But I stumbled over the following problems when running Selenium on OS X:
With Safari 4.0.3: Pop-up blocking is default on, switch it off:
With Firefox 3.5.3:
I got the following error from the selenium server:
This problem was fixed with copying a newer version of the library into the firefox installation:
(First command is just for backup. Tip found here)
Update: 2010-11-14: For Firefox 3.6 make sure that you are upgrade to the latest version of selenium-server. I just wasted some hours trying to get firefox running with selenium-serve 1.0.1. The problem disappeared with selenium-server 1.0.3.
With Safari 4.0.3: Pop-up blocking is default on, switch it off:
With Firefox 3.5.3:
I got the following error from the selenium server:
dyld: Library not loaded: /usr/lib/libsqlite3.dylib
Referenced from: /System/Library/Frameworks/Security.framework/Versions/A/Security
Reason: Incompatible library version: Security requires version 9.0.0 or later, but libsqlite3.dylib provides version 1.0.0
This problem was fixed with copying a newer version of the library into the firefox installation:
mv /Applications/Firefox.app/Contents/MacOS/libsqlite3.dylib /Applications/Firefox.app/Contents/MacOS/libsqlite3.dylib.orig
cp /usr/lib/libsqlite3.dylib /Applications/Firefox.app/Contents/MacOS/libsqlite3.dylib
Update: 2010-11-14: For Firefox 3.6 make sure that you are upgrade to the latest version of selenium-server. I just wasted some hours trying to get firefox running with selenium-serve 1.0.1. The problem disappeared with selenium-server 1.0.3.
Labels:
javablog,
programming,
testing
Subscribe to:
Posts (Atom)
