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
Thursday, October 29, 2009
SpecFlow - Pragmatic BDD for .Net
Some days ago TechTalk released SpecFlow as an open source project.
The mission of SpecFlow is to provide a pragmatic and frictionless approach to Acceptance Test Driven Development (ATDD) and Behavior Driven Development (BDD) for .NET projects today.
The main website is at www.specflow.org
The source code is hosted on GitHub: SpecFlow.
The wiki and issue tracking is at code.google.com/p/specflow
We at TechTalk are successfully using SpecFlow in several projects.
SpecFlow was mainly developed on the background that using Cucumber on the .Net platform is currently painful and not frictionless at all. You can read more on Gaspars Blog.
SpecFlow was heavily inspired by Cucumber. It aims at bridging the communication gap between domain experts and developers by binding business readable behavior specifications to the underlying implementation.
To get an idea how this can be realized:
The mission of SpecFlow is to provide a pragmatic and frictionless approach to Acceptance Test Driven Development (ATDD) and Behavior Driven Development (BDD) for .NET projects today.
The main website is at www.specflow.org
The source code is hosted on GitHub: SpecFlow.
The wiki and issue tracking is at code.google.com/p/specflow
We at TechTalk are successfully using SpecFlow in several projects.
SpecFlow was mainly developed on the background that using Cucumber on the .Net platform is currently painful and not frictionless at all. You can read more on Gaspars Blog.
SpecFlow was heavily inspired by Cucumber. It aims at bridging the communication gap between domain experts and developers by binding business readable behavior specifications to the underlying implementation.
To get an idea how this can be realized:
First write your scenarios in plain-text...
... then let SpecFlow execute them!
Wednesday, October 21, 2009
Büroeröffnung TechTalk Schweiz im Technopark Zürich - Vortrag agiles Testen mit ATDD und BDD
Update 2009-11-18: Slides are published on SlideShare
My company TechTalk is officially opening its new office in Switzerland next Wednesday October 28 in Zurich's Technopark.
Christian and I will hold a technical Talk about realizing agile Testing with Acceptance Test Driven Development (ATDD) and Behavior Driven Development (BDD).
Everybody is invited, entrance is free.
The talk starts at 16:30. Here is the official announcement. I would happy to see you there.
My company TechTalk is officially opening its new office in Switzerland next Wednesday October 28 in Zurich's Technopark.
Christian and I will hold a technical Talk about realizing agile Testing with Acceptance Test Driven Development (ATDD) and Behavior Driven Development (BDD).
Everybody is invited, entrance is free.
The talk starts at 16:30. Here is the official announcement. I would happy to see you there.
Thursday, October 1, 2009
Learned today: Scrum is like a roundabout
Yesterday I was attending the scrum breakfast in Bern.
François Bachmann held an insightful presentation where he drew analogies between traffic and software projects: Projektstau auflösen - wie Sie Ihrem Manager Agilität erklären können (Breaking up traffic jam - how you can explain Agile to your manager).
The main analogy was:
And a funny example of scrumbut:
Arc de Triomphe - a roundabout, but entering vehicles have precedence.
François Bachmann held an insightful presentation where he drew analogies between traffic and software projects: Projektstau auflösen - wie Sie Ihrem Manager Agilität erklären können (Breaking up traffic jam - how you can explain Agile to your manager).
The main analogy was:
Scrum is like a roundabout
And a funny example of scrumbut:
Arc de Triomphe - a roundabout, but entering vehicles have precedence.
Labels:
agile,
javablog,
methodology
Subscribe to:
Posts (Atom)
