The ongoing search for simple solutions.

Monday 27 April 2009

Testers: The Hidden Resource by Lisa Crispin and Janet Gregory on Informit.com

I came across this great article by Lisa Crispin and Janet Gregory on Informit.com. I think it sums up a lot of what they wrote about in their book "Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley Signature)"

Lisa Crispin and Janet Gregory point out the hidden asset on many development teams: the testers. By learning from agile teams, software teams using any type of development methodology can improve their use of testers and testing.

What do the words tester or QA engineer bring to mind? They're those people who think of ways to break the software, right? Isn't QA the team that comes in after the coding is done, to tell the programmers what they did wrong? It doesn't take all that much skill to be a tester; anyone could pound on a keyboard and check whether the software works, right?

Wrong. Think again.

In traditional projects, requirements are defined up front, usually by business analysts or product managers. Testers have learned to analyze each requirement—looking for completeness, ambiguity, correctness, and much more—so that they can write detailed test cases. However, development teams using this type of phased and gated methodology often tie the testers' hands, giving them no way to get requirements changed if they find contradictions or unclear specifications. By contrast, testers on agile teams get the opportunity to accommodate and embrace change. By observing how testers contribute value on agile projects, we can see how agile testing principles and practices may be applied, regardless of the development methodology being used. The key is making testers full partners with developers, giving them access to business experts, and involving them from the very beginning of each project.

Read the full article on InformIT

Monday 6 April 2009

How to expect a non-matching result in FitNesse.Net

Using FitNesse.Net, it is simple to create a test which specifies what the expected result of a test should not be. For example:-

One plus One should not equal Three.

To do this, you simply put fail[{result}] in the result cell. For example:-

Other Blogs