Software Testing

• sure the user can see that an error has occurred. Error messages need to stand out from the rest of the layout. They should be placed at the top of the page if that is the area displayed after the form has been submitted with errors.
• An error icon if your layout makes it difficult to visually separate errors from the rest of the page
• Be consistent when you present errors (the user will expect errors to be displayed at the same location and with the same style on all pages)
• Update the page title to indicate that the user is on the same page but with errors (e.g. if the page title is “Registration” you could change it to “Registration - Error occurred”).
  

• Make sure the error message identifies the related field with the name as it is written in the label for that field
• Do not use complicated words
• Describe what the user should do to correct the error, especially if it could be difficult to understand
• Make it clear if there were more than one error so that the user can correct all errors at once
  

• Make sure all user agents can parse error details. Use a heading to identify the error area.
• Present each error as an item in a list. This makes it easy for the user to understand what has to be corrected. Also, screen reader users will find it easier to keep errors apart
• If you use software specific error id numbers do not hesitate to add them to the id-attribute of the list element. If you use automated functional tests (e.g. Rational Robot) it will be much easier for the test robot to parse and identify errors
• Provide an access key for the error message section. This is valuable if your form can generate many errors and enables the user to move back and forth between the error list and the form
• Make it possible to navigate from the error message to the related field. This makes it easier for users that navigate with the keyboard

Web system often requires both client-side and server-side installs. Testing of the installer checks that installed features function properly--including icons, support documentation, the README file, and registry keys. The test verifies that the correct directories are created and that the correct system files are copied to the appropriate directories. The test also confirms that various error conditions are detected and handled gracefully.
Testing of the uninstaller checks that the installed directories and files are appropriately removed, that configuration and system-related files are also appropriately removed or modified, and that the operating environment is recovered in its original state.

Perform to check that an application functions properly across various hardware and software environments by using Compatibility and configuration testing. Often, the strategy is to run the functional acceptance simple tests or a subset of the task-oriented functional tests on a range of software and hardware configurations. Sometimes, another strategy is to create a specific test that takes into account the error risks associated with configuration differences. For example, you might design an extensive series of tests to check for browser compatibility issues. Software compatibility configurations include variances in OS versions, input/output (I/O) devices, extension, network software, concurrent applications, online services and firewalls. Hardware configurations include variances in manufacturers, CPU types, RAM, graphic display cards, video capture cards, sound cards, monitors, network cards, and connection types(e.g. T1, DSL, modem, etc.)

Exploratory Testing do not involve a test plan, checklist, or assigned tasks. The strategy here is to use past testing experience to make educated guesses about places and functionality that may be problematic. Testing is then focused on those areas. Exploratory testing can be scheduled. It can also be reserved for unforeseen downtime that presents itself during the testing process

Missed errors by formal test cases are found by using this method of testing. These tests simulate the actions customers may take with a program

The forced-error test (FET) consists of negative test cases that are designed to force a program into error conditions. A list of all error messages that the program issues should be generated. The list is used as a baseline for developing test cases. An attempt is made to generate each error message in the list. Obviously, test to validate error-handling schemes cannot be performed until all the handling and error message have been coded. However, FETs should be thought through as early as possible. Sometimes, the error messages are not available. The error cases can still be considered by walking through the program and deciding how the program might fail in a given user interfaces such as a dialog or in the course of executing a given task or printing a given report. Test cases should be created for each condition to determine what error message is generated.

The task-oriented functional test (TOFT) consists of positive test cases that are designed to verify program features by checking the task that each feature performs against specifications, user guides, requirements, and design documents. Usually, features are organized into list or test matrix format. Each feature is tested for:

• The validity of the task it performs with supported data conditions under supported operating conditions.
• The integrity do the task's end result
• The feature's integrity when used in conjunction with related features

The configuration on which the Web system will be deployed will often be much different from develop-and-test configurations. Testing efforts must consider this in the preparation and writing of test cases for installation time acceptance tests. This type of test usually includes the full installation of the applications to the targeted environments or configurations

The functional acceptance simple test (FAST) is run on each development release to check that key features of the program are appropriately accessible and functioning properly on the at least one test configuration (preferable the minimum or common configuration).This test suite consists of simple test cases that check the lowest level of functionality for each command- to ensure that task-oriented functional tests (TOFTs) can be performed on the program. The objective is to decompose the functionality of a program down to the command level and then apply test cases to check that each command works as intended. No attention is paid to the combination of these basic commands, the context of the feature that is formed by these combined commands, or the end result of the overall feature. For example, FAST for a File/Save As menu command checks that the Save As dialog box displays. However, it does not validate that the overall file-saving feature works nor does it validate the integrity of save files.

The release acceptance test (RAT), also referred to as a build acceptance or smoke test, is run on each development release to check that each build is stable enough for further testing. Typically, this test suite consists of entrance and exit test cases plus test cases that check mainstream functions of the program with mainstream data. Copies of the RAT can be distributed to developers so that they can run the tests before submitting builds to the testing group. If a build does not pass a RAT test, it is reasonable to do the following:

• Suspend testing on the new build and resume testing on the prior build until another build is received
• Report the failing criteria to the development team
• Request a new build

1. Unit Testing

• Unit Testing is primarily carried out by the developers themselves
• Deals functional correctness and the completeness of individual program units
• White box testing methods are employed

2. Integration Testing

• Integration Testing: Deals with testing when several program units are integrated
• Regression testing: Change of behavior due to modification or addition is called ‘Regression’. Used to bring changes from worst to least
• Incremental Integration Testing: Checks out for bugs which encounter when a module has been integrated to the existing
• Smoke Testing: It is the battery of test which checks the basic functionality of program. If fails then the program is not sent for further testing

3. System Testing

• System Testing : Deals with testing the whole program system for its intended purpose
• Recovery testing: System is forced to fail and is checked out how well the system recovers the failure
• Security Testing: Checks the capability of system to defend itself from hostile attack on programs and data
• Load & Stress Testing: The system is tested for max load and extreme stress points are figured out
• Performance Testing: Used to determine the processing speed
• Installation Testing: Installation & uninstallation is checked out in the target platform

4. Acceptance Testing

• UAT: ensures that the project satisfies the customer requirements
• Alpha Testing : It is the test done by the client at the developer’s site
• Beta Testing : This is the test done by the end-users at the client’s site
• Long Term Testing : Checks out for faults occurrence in a long term usage of the product
• Compatibility Testing : Determines how well the product is substantial to product transition

Automated testing is as simple as removing the "Manual Effort" and letting the computer do the thinking. This can be done with integrated debug tests, to much more intricate processes. The idea of the tests is to find bugs that are often very challenging or time intensive for human testers to find. This sort of testing can save many man hours and can be more "efficient" in some cases. But it will cost more to ask a developer to write more lines of code into the game (or an external tool) then it does to pay a tester and there is always the chance there is a bug in the bug testing program. Re-usability is another problem; you may not be able to transfer a testing program from one title (or platform) to another. And of course, there is always the "human factor" of testing that can never truly be replaced.
Other successful alternatives or variation: Nothing is infallible. Realistically, a moderate split of human and automated testing can rule out a wider range of possible bugs, rather than relying solely on one or the other. Giving the testers limited access to any automated tools can often help speed up the test cycle.

1.White Box
White box testing is also called ‘Structural Testing / Glass Box Testing’ is used for testing the code keeping the system specs in mind. Inner working is considered and thus Developers Test.

• Mutation Testing-Number of mutants of the same program created with minor changes and none of their result should coincide with that of the result of the original program given same test case.
• Basic Path Testing-Testing is done based on Flow graph notation, uses Cyclops metric complexity & Graph matrices.
• Control Structure Testing-The Flow of control execution path is considered for testing. It does also checks :-
  
  • Conditional Testing : Branch Testing, Domain Testing
  • Data Flow Testing
  • Loop testing: Simple, Nested, Conditional, Unstructured Loops

2. Gray Box
Similar to Black box but the test cases, risk assessments, and test methods involved in gray box testing are developed based on the knowledge of the internal data and flow structures
3. Black Box
Also called ‘Functional Testing’ as it concentrates on testing of the functionality rather than the internal details of code.
Test cases are designed based on the task descriptions

• Comparison Testing-Test cases results are compared with the results of the test Oracle.
• Graph Based Testing-Cause and effect graphs are generated and cyclometric complexity considered in using the test cases.
• Boundary Value Testing-Boundary values of the Equivalence classes are considered and tested as they generally fail in Equivalence class testing.
• Equivalence class Testing-Test inputs are classified into Equivalence classes such that one input check validates all the input values in that class.

Consider the impact of project errors, not the size of the project. However, if extensive testing is still not justified, risk analysis is again needed and the considerations listed under "What if there isn't enough time for thorough testing?" do apply. The test engineer then should do "AD HOC" testing, or write up a limited test plan based on the risk analysis.

Consider the impact of project errors, not the size of the project. However, if extensive testing is still not justified, risk analysis is again needed and the considerations listed under "What if there isn't enough time for thorough testing?" do apply. The test engineer then should do "ad hoc" testing, or write up a limited test plan based on the risk analysis.

Work with management early on to understand how requirements might change, so that alternate test plans and strategies can be worked out in advance. It is helpful if the application's initial design allows for some adaptability, so that later changes do not require redoing the application from scratch. Additionally, try to-

• Ensure the code is well commented and well documented; this makes changes easier for the developers
• Use rapid prototyping whenever possible; this will help customers feel sure of their requirements and minimize changes
• In the project's initial schedule, allow for some extra time to commensurate with probable changes

When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested. Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn't create other problems elsewhere. If a problem-tracking system is in place, it should encapsulate these determinations. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it.