testingReflections.com - extreme programming (XP)

If only software development was like listening to internet radio...

Thu, 24 Apr 2008 12:46:28 -0500

It's true - people who don't get TDD hear the word 'Test' and all but ignore the 'Driven Development' part of it... sometimes to the point that they assume "oh, that's that testers job then"... or the opposite happens when you hear "doesn't that mean developers spend time testing when they should be writing code?"... It can take long and hard to break through this initial cultural barrier... For a long time I've searched for a way other than dropping the word 'T' in 'TDD' to break through the inevitable barrier and I'd almost given up hope... to the point where I was about to resort to the BDD philosophy. The benefits of test-infection made me persist.

To try to get people to understand the 'Driven Development' aspect of writing customer tests first a.k.a. "Acceptance Test Driven Development" (ATDD) and the relevance of the test and testing and testers and let's not forget early and frequent customer feedback... I've been using a different approach. It doesn't solve all of the problems caused by the letter 'T' but it does solve one of them - the part where people ignore the fact that the tests are driving development (yes I said 'tests' not 'testers' - I emphasise this because someone recently asked me 'so, how exactly do the testers drive the developers?').

So... let's talk about something else for a second... I want you to stop thinking about testing... for one moment. I want you to forget about the word 'test' and all the connotations that go along with it... I want you to think about something else... something random... let's say... 'Internet Radio'...

How do I know when I'm done... (again)

Wed, 06 Feb 2008 11:08:47 -0600

In the context of an XP-style Story/Acceptance Test Driven Development process, that uses exploratory testing to generation intra-iteration feedback... The question “how do we know we are done” is often asked and I'm not sure I always give or get the best answer. One of the problems is that there is so much context... so, here's one way you might know (based on my better experiences)...

That sweet check-in...

Movie tickets and bugs in agile

Sat, 23 Dec 2006 21:45:05 -0600

I've been thinking about the way agilistas handle bugs recently. Several years ago, I was the editor of an internal IT newsletter for a large Australian financial organisation. Every month, I'd include a critical thinking puzzle, and I select a correct entry to win 2 movie tickets. I was able to give these out to my Australian readers, but I used to get some entries from our Indian IT shop as well. I arranged to have them win 2 movie tickets as well, if they were chosen as the winner. I thought this was a comparable prize, then I discovered that movie tickets are very cheap in India. In Australia, the prize would pay for a weeks public transport, but in India it would be only a day or two.

Transition of Bugs

Fri, 20 Jan 2006 11:38:43 -0600

I do testing in application which is developed under eXtreme Programming model. Due to the short span of the development process, we always work with bitter pressure. Whenever I encounter a bug, I immediately logged the issue in the tracking tool and if necessary I would made a face to face discussion with the developers.

I was recently testing an application which had an excellent search function. Most of the pages had a data grid with 4 to 6 columns. The point here I wish to mention is, the bugs identified is taking different weightage at different levels of development process. Within a period of week, the high priority bug becomes obsolete.

I fought XP and XP won

Fri, 14 Oct 2005 06:06:59 -0500

One day I heard about eXtreme Programming. Wow, I was a student, eager to know, and I tried to live on the edge. Extreme was just what I looked for. Soon after I got Kent Beck's - Extreme Programming Explained, the first edition. I read it very fast and that was a decisive moment in my programming life. I thought everthing in there was good but not appliable. I said , you can never have 100% unit tested code. In time I saw I was wrong. I said PP costs double. I was wrong. Every practice was for me a new impossible and as the time got by, I found it less and less imposible but as the book said very beneficial.

Video of my "Intro to Agile Development" talk at INDA is online

Sun, 21 Aug 2005 04:42:51 -0500

Paschal has posted online Part I of my Talk at the INDA group. It's roughly 3/4 of my full "Into to Agile development" talk and Parts II and III (Unit Testing Best Practices) will be posted later on, in audio format as well. A few points to note before watching the video:

The real talk starts 5 full minutes into the video.

Link: Crispin on test-first customer tests

Sun, 21 Aug 2005 04:27:30 -0500

Lisa crispin has a nice, short article on how her team uses business-facing tests to drive development. A couple of points I particularly like:

Good examples of questions someone (often the tester) should ask about even a simple story.
An emphasis on just-in-time test creation.

Using Customer Tests to Drive Development

Fri, 05 Aug 2005 13:13:51 -0500

This article reports a concrete experience of incorporating customer input in a Test-Driven Development approach.Author: Lisa Crispin Published: Methods and Tools, Spring 2005

XP Games links

Fri, 05 Aug 2005 12:53:17 -0500

Some links to various "XP Games" - small games to simulate Agile Development practices and benefits (via the XP Mailing list at Yahoo)

The XP Game
XP War
Some nice games fro developers from Bill Wake
Offing the Off-Site customer workshop materials
Extreme Hour

I'm planning to have one of these games at the upcoming Agile Israel Meetings.

Agile Performance Testing?

Wed, 25 May 2005 21:42:17 -0500

Neill,

You touched two very interesting points here. I have formulated them in a different way for myself, but probably it is the same (if I got it correctly).

The first point, as I got it, perhaps can be named “start performance testing early”. Everybody talking about it, but not much done. Mainly, the only thing that a performance tester (as it is usually defined now) can do until some functionality will work is to collect requirements/use-cases/scenarios.

Portland, OR XP Users Group Meeting - Mar 8

Thu, 03 Mar 2005 00:04:28 -0600

XPDX is having their next meeting Tuesday March 8. If you are in the Portland, OR area next week come on by. My buddy Mark Clerget is going to talk about running an agile project in a government environment. This post is a result of some of the work they did to fit into the culture of the existing PMO.

Why use eXtreme Programming? Not just another development methodology

Mon, 14 Feb 2005 00:43:39 -0600

Extreme Programming (XP) has been an accepted form of software development for about eight years now. Many of the concepts found in this lightweight method of development have been implemented into the software shops without even the awareness that they were XP techniques. XP takes many of its fundamentals from other iterative development methodologies, including RAD and JAD. Author: Troy Holmes

Portland Extreme Programming Users Group (XPDX)

Thu, 03 Feb 2005 02:07:18 -0600

XPDX is having another meeting Tuesday Feb 8, 2005. I will be running a workshop I am preparing for Agile 2005.

Pushing & Pulling Teams - An Exercise in How Things Get Done

eXtreme .NET: Introducing eXtreme Programming Techniques to .NET Developers

Sat, 18 Dec 2004 13:35:07 -0600

eXtreme .NET shows developers and team leaders how to incorporate eXtreme programming (XP) practices with .NET-connected technologies to create high quality, low-cost code that will build better software. This practical, realistic guidebook systematically covers key elements of XP methodology in the specific context of the .NET Framework, Visual Studio .NET, Microsoft Visual C#, and related Microsoft .NET-enabled applications.