User acceptance testing is different from System Testing. System testing is invariably performed by the development team which includes developer and tester. User acceptance testing on the other hand should be carried out by the end user. This could be in the form of

• Alpha Testing - In Alpha Testing, the users are invited at the development center where they use the application and the developers note every particular input or action carried out by the user. Any type of abnormal behavior of the system is noted and rectified by the developers
• Beta Testing - In Beta Testing, the software is distributed as a beta version to the users and users test the application at their sites. As the users explore the software, in case if any exception/defect occurs that is reported to the developers. Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the company. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users

In both the cases, these testing might be assisted by software testers.

It is very important to define acceptance criteria with the buyer during the various phases of SDLC. A well defined acceptance plan will help development/QE teams by identifying user’s need during software development. Acceptance Test plan must be created or reviewed by customer. Development team and customer should work together and make sure that they have

• Identify interim and final products for acceptance, acceptance criteria and schedule.
• Plan how and by whom each acceptance activities will be performed.
• Schedule adequate time for buyer’s staff to examine and review the product
• Prepare the acceptance plan.
• Perform formal acceptance testing at delivery
• Make a decision based on the results of acceptance testing.

Entry Criteria

• System Testing is completed and defects identified are either fixed or documented.
• Acceptance plan is prepared and resources have been identified.
• Test environment for the acceptance testing is available

Exit Criteria

• Acceptance decision is made for the software
• In case of any caveats, development team is notified

A race condition is a conflict between at least two tests. Each test works correctly when done in isolation. When the two tests are run in parallel, one or both of the tests fail. This is usually due to an incorrectly managed lock. A memory leak happens when a test leaves allocated memory behind and does not correctly return the memory to the memory allocation scheme. The test seems to run correctly, but after being exercised several times, available memory is reduced until the system fails

Note that load testing does not aim to break the system by overwhelming it, but instead tries to keep the system constantly humming like a well-oiled machine. In the context of load testing, extreme importance should be given of having large datasets available for testing. Bugs simply do not surface unless you deal with very large entities such thousands of users in repositories such as LDAP/ NIS/ Active Directory; thousands of mail server mailboxes, multi-gigabyte tables in databases, deep file/ directory hierarchies on file systems, etc. Testers obviously need automated tools to generate these large data sets, but fortunately any good scripting language worth its salt will do the job

Volume Testing is done against the efficiency of the application. Large data/database is processed through the application under testing in order to check the extreme limitations of the system

Volume Testing, as its name implies, is testing that purposely subjects a system (both hardware and software) to a series of tests where the volume of data being processed is the subject of the test. Such systems can be transactions processing systems capturing real time sales or could be database updates and or data retrieval

Volume testing will seek to verify the physical and logical limits to a system’s capacity and ascertain whether such limits are acceptable to meet the projected capacity of the organization’s business processing

Regression testing attempts to mitigate two risks:

o A change that was intended to fix a bug failed.

o Some change had a side effect, unfixing an old bug or introducing a new bug

Regression testing approaches differ in their focus, Common examples include:

Bug regression: We retest a specific bug that has been allegedly fixed.

Old fix regression Testing: We retest several old bugs that were fixed, to see if they are back. (This is the classical notion of regression: the program has regressed to a bad state.)

General functional regression: We retest the product broadly, including areas that worked before, to see whether more recent changes have destabilized working code. (This is the typical scope of automated regression testing.)

Conversion or port Testing: The program is ported to a new platform and a subset of the regression test suite is run to determine whether the port was successful. (Here, the main changes of interest might be in the new platform, rather than the modified old code.)

Configuration Testing: The program is run with a new device or on a new version of the operating system or in conjunction with a new application. This is like port testing except that the underlying code hasn’t been changed–only the external components that the software under test must interact with.

Localization Testing: The program is modified to present its user interface in a different language and/or following a different set of cultural rules. Localization testing may involve several old tests (some of which have been modified to take into account the new language) along with several new (non-regression) tests.

Smoke or Build Verification Testing: A relatively small suite of tests is used to qualify a new build. Normally, the tester is asking whether any components are so obviously or badly broken that the build is not worth testing or some components are broken in obvious ways that suggest a corrupt build or some critical fixes that are the primary intent of the new build didn’t work. The typical result of a failed smoke test is rejection of the build (testing of the build stops) not just a new set of bug reports.

A test of new or repaired equipment by turning it on, if it smokes… guess what… it doesn’t work! The term also refers to testing the basic functions of software. The term was originally coined in the manufacture of containers and pipes, where smoke was introduced to determine if there were any leaks. A common practice at Microsoft and some other shrink-wrap software companies is the ‘daily build and smoke test’ process. Every file is compiled, linked, and combined into an executable program every day, and the program is then put through a “smoke test,” a relatively simple check to see whether the product ‘smokes’ when it runs.

One of the best uses of ad hoc testing is for discovery. Reading the requirements or specifications (if they exist) rarely gives you a good sense of how a program actually behaves. Even the user documentation may not capture the “look and feel” of a program.

Ad hoc testing can find holes in your test strategy and can expose relationships between subsystems that would otherwise not be apparent. In this way, it serves as a tool for checking the completeness of your testing. Missing cases can be found and added to your testing arsenal. Finding new tests in this way can also be a sign that you should perform root cause analysis. Ask yourself or your test team, “What other tests of this class should we be running?” Defects found while doing ad hoc testing are often examples of entire classes of forgotten test cases.

Probably developers will write the unit test cases but your understanding of the framework and unit testing can certainly help him/her in designing the flow for unit test cases, generating test data and making good reports. All these activities will ultimately help you in the long run as product quality will increase significantly because of the efforts you put in on the unit testing

So if you think as a test engineer, you should also learn/know about unit testing

Unit testing is the method of making sure that smallest unit of your software is working properly in isolation. You can define this smallest unit in your own term; it could be a java class or library. A more formal definition and Kent Beck wrote JUnit framework along with Erich Gamma and it became extremely useful for the Java community. JUnit made it very easy for the developers to write, organize and execute unit test cases for there java code. Success of JUnit was enough to inspire people working on other languages to come up with unit testing framework for the language of their choice. Now we probably have more than 25 Unit testing frameworks based on the XUnit architecture covering all the major languages