Acceptance testing: what it is, and how to do it better

The term ‘acceptance testing’ can have various meanings. When testers utter these words, the chances are they are saying and thinking completely different things.

As with all testing activities, Acceptance Testing needs to be considered in context, as it’s value to a project is entirely dependent on the other factors in that context.

In this presentation, Michael Bolton begins by asking “What is User Acceptance Testing to you?”, and goes on to show how UAT is not necessarily alpha testing, beta testing, or the final stage of a testing project.

Download the presentation (as a PDF) over at Sticky Minds.

Why testers should dig into the technical design

As testers, it is tempting to focus on the functional design and functional requirements while testing.

However, by looking outside these confines and taking time to understand the technical architecture of a system, testers can enjoy various payoffs in their testing.

In this post for the Software Test Professionals Conference, Nancy Kelln explains how “looking under the hood” can lead to better understanding, detection of otherwise overlooked risks, and an earlier commencement to testing.

Read the article at stpcon.com.

Why regression tests are essential when verifying defect fixes

A few days ago a simple defect came back to me for retesting. On the surface, it seemed like a straightforward retest: a building society reference number was being rejected when it contained special characters such as ‘-’ or ‘/’. Here in the UK, a building society reference typically contains these characters, so the retest was a matter of confirming they were now accepted as valid.

I cross-checked the notes on the fix with the requirements document, and noticed that the maximum number of characters permitted was 20, so I thought I would do a couple of quick boundary tests to ensure this requirement was still being met.
Continue reading →

Why the decision to release should be a business decision

It is easy for technologists to forget that the business should be responsible for making the decision whether or not to release software.

Being involved in the design, development, and testing of a piece of software leads us IT folks to believe we know the product intimately, and are therefore best placed to determine its fitness for purpose; but external factors such as the cost of not implementing mean this isn’t always the case.

In this post, Michael Bolton reminds us how the decision to release is not merely a technical one, and offers some advice to product owners as to when they should ship their product. The simple answer is: when you’re no longer so nervous you don’t want to ship.

Read the post over at DevelopSense.

Effective test strategies are context-driven

The need to consider context is often overlooked when developing an effective testing strategy, particularly by larger organisations trying to shoehorn testing projects into existing methodologies that don’t quite fit.

While context-driven testing is not a new concept, it is often a forgotten one that many projects can benefit from.

This excellent article by Jimmy Bogard beautifully illustrates how one company has built a context-driven test strategy around a holistic approach that starts with system testing and drills down to unit testing for greater levels of coverage.

Read in full over at LostTechies.com.