Nunc venenatis aliquam odio nec condimentum. Maecenas at elit massa. Aenean quis dapibus massa. Proin rutrum urna et metus tincidunt aliquet. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Quisque est dui, rutrum nec dignissim vitae, aliquam non lorem. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Cras convallis elit ut enim euismod nec mollis mi ullamcorper. Sed auctor lorem in tellus sodales a semper erat aliquam.

Sed mollis tellus ut nulla posuere sed dignissim purus varius. Integer vitae augue sit amet ligula accumsan ornare. Duis a magna leo. Nunc interdum fermentum vestibulum. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Suspendisse non nulla eu velit porttitor suscipit. Maecenas non diam nec nisl faucibus sodales nec non tortor. Donec ut consectetur justo. Integer purus nisi, imperdiet convallis volutpat quis, porttitor eu odio.

Mauris ac euismod est. Pellentesque vehicula, lorem in cursus fermentum, dolor erat dapibus tortor, ac tincidunt est libero ac neque. Nullam aliquet tristique est, eget vulputate nisl semper vitae. Pellentesque interdum ante purus. Quisque pellentesque orci nec nibh elementum eu pulvinar tortor fermentum. In id urna lorem. Donec porta mauris bibendum risus auctor ornare. Nulla volutpat, magna in condimentum tincidunt, felis dolor egestas nisi, in commodo erat ipsum eu metus. Proin varius, libero a congue condimentum, augue erat ornare enim, vitae euismod est ligula ac leo. Fusce mi lorem, bibendum nec gravida non, vulputate ut enim. In hac habitasse platea dictumst. Phasellus erat orci, pharetra ut tristique vitae, iaculis sit amet eros. Cras sodales purus eu nisi dapibus vel condimentum augue molestie. Quisque vitae pulvinar tellus. Quisque convallis aliquam posuere. Mauris tempor elit vitae orci scelerisque venenatis.

Quisque vel libero lorem. Curabitur eget ultricies tortor. Nam orci mi, accumsan sed tincidunt a, tincidunt et orci. Vestibulum ac risus non neque molestie hendrerit in ut nibh. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Praesent scelerisque venenatis ligula, sed faucibus enim porttitor a. Donec ac dui ipsum. Donec quis sapien leo. Nullam convallis magna eget diam rhoncus in porttitor est hendrerit. Phasellus congue viverra felis, et vestibulum risus rhoncus id. Nullam magna tortor, viverra non blandit at, iaculis ac ligula. Vivamus ultrices, massa eget malesuada adipiscing, metus nisl facilisis leo, a vestibulum metus tellus a tellus. Pellentesque dignissim lorem porta metus convallis vel egestas mauris viverra. Vivamus vulputate turpis vitae ligula mattis pellentesque. Donec mi libero, fringilla at suscipit vitae, accumsan id enim.

Nam ut nisi augue, nec consectetur quam. Suspendisse at lacus lacinia nibh molestie consequat facilisis eu quam. Quisque massa mi, pellentesque at venenatis ut, fringilla non ipsum. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Vestibulum pretium, ligula vel pulvinar dapibus, augue nunc adipiscing nisi, vel iaculis leo justo et ipsum. Nullam vel eros ut purus dignissim pulvinar. Donec elit mi, aliquet cursus ullamcorper sed, fermentum vitae est. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Mauris non libero non dolor vehicula congue. Donec enim est, pretium a rhoncus id, ultricies id lacus. Morbi vitae est quis lacus aliquet tempor. Fusce vel leo quis leo sodales congue. Nam pretium vehicula malesuada. Curabitur ultrices tortor vel quam pulvinar gravida. Etiam vitae enim diam, ac rhoncus elit. Vivamus lobortis dictum ipsum, sed ornare urna facilisis sit amet.

Nunc mattis mattis massa, sed consectetur orci lacinia nec. Aliquam tempus nulla non ipsum faucibus adipiscing. Quisque convallis, ipsum sit amet lobortis tristique, tellus tellus auctor augue, imperdiet dapibus quam lorem at purus. Maecenas faucibus turpis in magna sollicitudin a tincidunt est vestibulum. Vivamus malesuada tincidunt nibh sed cursus. Nulla facilisi. Donec tincidunt sagittis rhoncus. Nam nec arcu ut velit fringilla ultricies pretium vel enim. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nam nisi nunc, interdum sit amet accumsan tempor, bibendum vel sapien. Donec elementum orci eu mauris hendrerit sed suscipit massa imperdiet. Quisque facilisis semper ipsum eget ultrices. Donec ut mi nisi, sit amet commodo quam. Vivamus sit amet fermentum tortor. Vivamus interdum quam a nisi bibendum nec iaculis augue lobortis.

This article will give you 5 specific actions you can regard as a checklist for success in acceptance testing.

1. Prepare for changing requirements

Formulate a strategy and establish a process for dealing with changing requirements. The process needs to help you capture, organize, prioritize, and manage many versions of new and changing requirements. How do you intend to handle the requirements changes that will appear during testing?
Most importantly, see the changes as lessons learned rather than failures; requirements are what the acceptance test is intended to approve.

2. Start early

Unless you’re aiming for failure, testing cannot wait until the end of the project – it needs to begin as early as the procurement process. It’s much cheaper to change things on the drawing board than trying to include requirements discovered when the system is ready for deployment. You’ll need at least one experienced person on the team whose focus is on reviewing and testing, depending on project size. You probably have system test managers and system testers. Acceptance test managers and acceptance testers are just as important.

3. Put usability into acceptance testing

Acceptance testers are helpful to have in system testing, since they’re good at spotting usability gaps and user interface improvements. However they can start usability testing much earlier, almost as soon as there is a user interface to look at. The interface can be as basic as a workflow, a single system module or a form, simple sketch or an advanced prototype. It’s nearly impossible to fix logical errors in workflow when they’ve been implemented throughout the system, so bring in your acceptance testers early to catch them before they spread.

4. Establish law and order with a shared test management tool

Testing isn’t about randomly kicking tires – it’s about working against a discrete list of identified risks and priorities, and tackling them in a logical order, one by one. Testers document identified defects and deviations and report them to the person tasked with correcting them. After these defects are corrected, the testers need to monitor and test the problem spots again, individually and in context. If the project involves several people, they need a shared data structure, and should coordinate their work with a test management tool right from the start. Ideally, the tool should be able to handle the entire chain from requirements through test cases to bug reporting, and provide summary statistics and metrics. Both client and developer should use the same tool.

5. Create new test cases

Developing test cases as soon as requirements are developed is great for emphasizing the importance of testing, but those initial cases are seldom sufficient; they need to be supplemented throughout the project. It’s tempting to reuse test cases from previous testing levels in acceptance testing, but each level of testing has a unique purpose and acceptance testing focuses on usage of the system. A testing tool makes it easier to both maintain and use test cases.

As with any requirement, implementing too late increases development costs.
To help with this, here is a list of 7 Requirements you should never overlook. Use this list as a starting point and supplement it with your own experiences. This will help you write more comprehensive and complete requirements.

1: System shut down

A system needs to be turned off for both emergency and planned downtime. Ideally, the process should provide the system administrator with a simple way to minimize errors that would arise if shutdown were a manual process. What information will the system display to users when it is going to be taken down or already is down?

2: Permissions

Who should be allowed to see or change what data? What happens when a user tries to use the features that he does not have access to? Can you see features you’re not authorised to use, or are they hidden? Who should administer permissions and how will they do it?

3: Error messages

Specify where messages are displayed. Do they use a message box or do they notify users in the program’s status bar? Error messages are very rarely specified in the requirements, but when developers inherit the task of formulating error messages, the results can be bad, since developers are often better at writing code than explaining things in plain English.

How can you counteract this? Specify a requirement that allows you to export all the messages in the system, for example to an Excel file. This will make it easier to adopt the same tone of voice in all the messaging, as well as make localization of the system easier if you ever decide to translate it into other languages.

Without this requirement in place, it’s usually very difficult to extract all the system messages into one place, let alone review and vet them.

4: Alarms when failures occur

When errors occur, the system should log the error and send an e-mail to operational staff, the system administrator or an equivalent. The great advantage of making the system send an alarm is that errors become more obvious and conspicuous, so the administrator is more likely to take action.

5: Logging errors

It’s much easier to troubleshoot the system if it records the details of each error to some type of log. This is especially true in the production environment, where it’s not possible to use development tools for troubleshooting.

You can log errors to a text file or to the Event Log in Windows. Other operating systems have different names for the Event Log, but the idea is available on all OSes.

When an error occurs, the system should log information about the program that crashed (including the line of code it was executing), the program error code (exception), and the input that led to the crash. Often it’s worthwhile to log more than just the error itself. For example, you might log all calls to all functions, since the error might have occurred because the calls were made in the wrong order.

6: Handling overloads

What happens if the system gets overloaded? Do you automatically roll back transactions in case of overloads? Does the system show an error message? Should the system shut down automatically? Think of the consequences and perceived risks of any of these choices and choose well, before overloads start happening.

7: Managing high volumes

High usage volumes is something you need to think of and plan beforehand. Ask yourself the question: “Will there be times when the system has to deal with a large number of users doing more things than usual?”

For example, the user volume of a retail sales system may be higher at certain times of the day, week, or year, while consumer banking systems are busier near payday. These types of spikes in usage can cause performance problems. Think of and plan these things beforehand.

So what exactly are we looking for here? Well, here are four examples of Non-Functional requirement groups; usability, reliability, performance, and supportability, as well as a few top tips on each one.

Usability:

Prioritize the important functions of the system based on usage patterns.
Frequently used functions should be tested for usability, as should complex and critical functions. Be sure to create a requirement for this.

Reliability:

Users have to trust the system, even after using it for a long time.
Your goal should be a long MTBF (mean time between failures).
Create a requirement that data created in the system will be retained for a number of years without the data being changed by the system.
It’s a good idea to also include requirements that make it easier to monitor system performance.

Performance:

What should system response times be, as measured from any point, under what circumstances?
Are there specific peak times when the load on the system will be unusually high?
Think of stress periods, for example, at the end of the month or in conjunction with payroll disbursement.

Supportability:

The system needs to be cost-effective to maintain.
Maintainability requirements may cover diverse levels of documentation, such as system documentation, as well as test documentation, e.g. which test cases and test plans will accompany the system.