Confessions of a Professional Software Tester

Link: http://www.nn-y.co.uk/mclaren_2010.html

There are some npictures from our Mclaren Tech Centre visit in the gallery...

What's the point in having documentation if it's out of date or incorrect. I'm wondering - is this even worse than not having any at all?

As a tester in a Scrum team, what are the regular testing tasks we should be doing? I've come up with a list of a few things:

Reminding people that story estimates should include testing time.
Ensuring that any acceptance criteria is (are?) acceptable.
Identify features that may incur additional risks (for instance things such as code changes in existing areas where test coverage is less than sufficient, complex features etc)
Figure out test automation options for the team
Remind developers that whatever they develop must be tested, therefore "testability" is an important part of design. And if a feature is "testable" that means it is more likely to be "usable", as the developer will put more thought into making the design simple.
Produce code coverage metrics/complexity metrics etc for the team.
Remind the team that code coverage is not the holy grail - just because you've hit 99% of the code does not mean you have fully tested the feature.
Work with the team to extend the test suite without duplication.
Be adaptable. The team is responsible for producing features, therefore everyone has a responsibility for getting things done, whatever that entails - over the last year or so I've certainly done a lot of things that would be outside of the remit for a normal* tester.
Remember that someone else is (hopefully) going to use the feature that the team have created. Consider that a training script of some kind can help explain to new users how to use a feature. It then also helps with documentation and test cases, usability issues are picked up early.

I've also come up with a few things that I think we should be doing but I have to admit I currently do not always do:

Work with the team to produce use cases for new features. That way as above, training scripts and test cases become easier to create, and become more focused on how the user will use the end product.
Usability - Something that is hard to do in a dedicated dev team, and vitally important. I've seen some great software before fail because it's too complicated or fiddly to use, a complaint I would also level at some of our software.
Check for "re-write over re-factor" it's all to easy to duplicate existing code when unnecessary - I see it as the role of a tester to check for this. Maintainability is also an important part of coding and can be difficult to police.
Remember, everyone in the team is a (potential) tester - but it's up to the professionally trained tester to make everyone else interested!
Are there any other things that a tester does/should be doing in an agile development environment?

* A normal tester - is that a paradox or a misnomer?

Click Here

Earlier this week I bought and downloaded a game from Xbox live called “Geometry Wars 2”. Despite the immense graphical capabilities of the Xbox 360, this game produces enemies in simple geometric shapes, you have a space ship (also made up of simple geometric shapes) and you must shoot the pink boxes/swirling vortexes etc before they get you. It’s all very basic and also very addictive, and is tipped to become a big seller.

Lesson 1: We can build the most complex software in the world. We can build the most advanced software that requires large amounts of processing power. Do we always need to just because we can?

Another analogy to the Video gaming world. Several years ago Microsoft bought out the Xbox (big black machine) several months after the big competition (PS2). Throughout the lifespan of the Xbox Microsoft were chasing the leading pack and never caught up. Learning their lesson, for the Xbox 360 they released ahead of the competition. This enabled Microsoft to steal a march on the competition and had already sold a large number of units before their competitors had even launched, giving them a big head start in terms of sales/installed units.

Lesson 2: Getting to the market first is a big help in solidifying your position in the market place.

A final analogy to the Video gaming world then. In the latest round of games console releases Nintendo launched the Wii a year after Microsoft had already released the Xbox 360. Before the machine was released several industry analysts had already written the machine off. Unlike the Xbox 360 and Playstation 3, the Wii did not output a high definition image, and didn’t have wide support from 3rd party games publishers. However Nintendo, realising they couldn’t compete on hardware power chose to innovate, and with the Wii came the “Wiimote”. This greatly simplified the interface between the game and the users hands, to some extent taking the machine away from hardcore gamers and placing it firmly in the mass market. Their marketing showed that even your Granny could use the controller to hit a virtual baseball or play tennis on the screen. Because it was simple to operate, family friendly and had a strong focus on social gaming with the whole family it led to consoles being moved back into the living room for the whole family to use rather than being kept in children’s bedrooms. To date, Nintendo has sold more “Wii’s” than both Microsoft and Sony consoles!

Lesson 3: Knowing your target market and employing great marketing is vital for big success.
Lesson 4: The most effective interfaces are usually those that are the simplest to use.