distributedlife

The next aspect of my presentation continued what I like about the Agile philosophy. Validation.

Validation is half of testing. Did we build the correct software. Obviously this question needs to be asked in the future tense. Are we going to build the correct software or, is this the correct solution for our client. To me Agile helps out allot here:

Short development cycles or sprints at the end of which you have “releasable” code. Ideally the business owner has the ability to say, that is all I want and take the code home at that point. This has never occurred, but then again I’ve never worked on a truly Agile project. To me the shorter cycles help with regular delivery to test and promotion up the environment chain, I’ll get to deployment testing later.

In all the projects I’ve worked on the business owners are only available for one or two UAT sessions and that’s about it. Naturally you want to show them as much as possible, but not leave it so late in the development phase of the project that you can’t fix any changes they want. Bit of a problem. It’s not Agile’s fault, more the reality of software development.

There are secondary solutions. If you can’t get the business owners actively involved then you need to go to the next best thing. Business Analysts. The BA needs to understand the motivation behind a solution. When the user is not around, the responsibility of being the user is delegated to them.

A coder friend of mine makes good use of the BA. As often as he can the BA is dragged over to examine every page. This is often before the code gets to me. If you’re a tester and jealous of a BA “testing”. Don’t be. Any work I don’t have to do and results in a higher quality product by the time it gets to me can only be a good thing. Remember the focus of the software is for the end-user.

After the BA the next best person is the tester. Testers also need to understand the motivation of the user. The business reason for the application’s existence. Consider usability testing. You’re testing to ensure an application is usable by a particular demographic. When obviously you’re not. The more in your career you test and the more you test that specific application, the more you become a “power-user” and the less in touch you theoretically become. Good testers get around this catch-22 by remembering everything they can about a inexperienced user and applying what they learned.

This is also why UAT sessions are so valuable to the tester. If we don’t find anything wrong with the software, fyi this never happens, something is always wrong, we just like to watch the users. Knowing how they expect to interact with the system can help us ensure the system behaves as they expect.

Real Agile is meant to have short development cycles with continued business involvement to ensure validation. That isn’t always going to occur. When it doesn’t there is a fallback available. The further you fallback the less indicative your feedback will be. This must be factored in when wieghing up the feedback. Any feedback from someone who cares about the project, the product and especially the user experience is going to better than no feedback at all.

Note: Damn, my posts are text heavy. I’ll look into finding some hilarious imagery to make them less of an eye strain… or write more succinctly. Don’t count on it though. I have a knack for using ten words when one will do.