Understanding Ways Of Software Testing Information Technology Essay

The testing the software takes places in different ways: testing often performed by an autonomous group of testers after the software is developed but before it is handover to the customer. This result in the testing phase being used as project buffer to balance for project delays, thereby negotiating the time devoted to testing. Another way is to start software testing at the same time when the project starts from the requirement specifications and continuous until the project finishes. One more best way for test suites is to be developed during technical support intensification procedures. These tests are maintained in regression testing to guarantee that future updates to the software do not repeat any of the known mistakes.

A common difference can be made between dynamic and static techniques, depending on whether the software system is executed or not. Static techniques are based exclusively on the manual or automated assessment of project documentation of software system models and code, and related information about requirement specifications and design. Thus, static techniques can be engaged along with development processes, and their earlier practice is of course highly desirable. Considering a general software development process, it can be applied:

During the requirements stage for examination language syntax, consistency and completeness as well as the observance to established conventions;

During the design phase, for estimating the completion of requirements, and identifying inconsistencies;

During the implementation phase for examination the form adopted for the implemented products i.e., code and related documentation and interfaces and data types’ correctness.

Traditional static techniques include:

Software inspection: In this technique, the systematic analysis of the documents (deliverables) is formed against a compiled checklist of common and historical faults.

Software reviews: During review, the processes by which different features of the working software system are presented to project personnel (managers, users. customer etc).

Code reading: In this, the desktop analysis of the produced code is done for determining typing errors i.e. violation of style or syntax.

Algorithm analysis and tracing: This is the process in which the complexity of algorithms engaged and the worst case, average-case and probabilistic analysis estimates can be derived.

Dynamic Techniques

Dynamic techniques acquire information of interest about a program by monitoring some executions. Standard dynamic analysis includes testing and profiling. Essentially a program profile counts the number of times some entities of interest occur during a set of controlled executions. Profiling tools are gradually used today to derive measures of coverage, for example in order to dynamically identify control flow invariants, as well as measures of frequency, called spectra, which are diagrams providing the qualified execution frequencies of the monitored entities. In particular, path spectra refer to the distribution of loop-free paths traversed during program profiling.

Testing appropriately based on the execution of the code on test inputs. Of course, the set of test cases can be considered infinite. However, test cases those can be run effectively during testing are limited. It is in practice impossible to exhaustively implement every input of a specific set even when restricted. A test strategy therefore must be adopted to find a trade-off between the number of chosen test cases and overall time and effort committed to testing purposes.

Ways of software testing

There exists many approaches to software testing, but effective testing of complex products is the dynamic analysis of the product. One such analysis is reviews, walkthroughs or inspections known as static testing, whereas actually executing the program with a given set of test cases at development stage is often referred as dynamic testing, which accentuate the fact that formal review processes form a part of the overall testing scope.

There are two fundamental methods of software testing:

Manual testing

Automated testing

Manual Software Testing

As the name specified, manual software testing is the process of an individual or individuals manually testing the software. As one might believe, manual software testing required labor and is slow. The manual software testing is appropriate for:

User interface or usability testing

Exploratory/ad hoc testing

Testing area of the application that experience a lot of change

User acceptance testing

Most significant drawback with manual software testing is time. The time required to fully test the system will be weeks to months. Second draw back of the manual testing is Variability of results which depending on who is performing the tests. Due to this, many software developer companies seek for automation as a means to speed up the software testing process while reducing the inconsistency of results.

Automated Software Testing

Automated software testing is the procedure of generating test set that can then be run automatically, cyclically, and through numbers of iterations. Automated software testing can help to minimize the inconsistency of results, accelerate the testing process, increase test coverage, and finally provide greater quality of the software being tested.

However, automated software testing is not appropriate for some items. These include:

End user usability testing is not characteristically a good applicant for automated testing.

A test that fails to run more than a few times are normally not a good candidate for automated testing, as the payoff of in test automation comes after many test cases executions.

Tests in the applications, which experience many changes, are also not a good for automation because this directs to substantial maintenance of test automation scripts. Such application may be more effectively tested manually.

There are numerous common software measures, called “metrics”, which are used to determine the state of the software or the adequacy of the software testing [http://everything.explained.at/Software_testing/]:

Bugs found per Tester per unit time

Total bugs found in a release

Total bugs found in a module / feature

Bugs found / fixed per build

Number of customer reported Bug – As a measure of testing effectiveness

Bug tendency over the period in a discharge

Number of test cases executed per person per unit time

Percentage of test cases executed so far, total Pass, total fail

Test Coverage

Levels of Software Testing

Unit Testing: This tests the smallest software component, or module. Each software module is tested to verify that either detailed design for the component has been implemented correctly or not. In Object-oriented testing environment, this is done frequently at the class level, and the smallest unit tests also include the constructors and destructors.

Integration Testing: This testing technique interprets faults in the interfaces between integrated modules. Tested software components of the architectural design are integrated and tested until the software works as a complete software system.

Functional Testing: During functional testing, any level (class, module, interface, or system) are tested for proper functionality as defined in the requirement specification.

System Testing: This tests completely integrated system to confirm that it meets its requirements.

System integration Testing: This tests the system when it is integrated to any external system defined in the system requirements.

Performance Testing: This validates Non-functional requirements those are defined at the requirements stage is met by the final system.

Acceptance Testing: Accepting testing is performed by the end-user, customer, or client to confirm whether to accept the system. Acceptance testing can also be performed as part of hand-off process between any two phases of software development.

Alpha Testing: It is carried out by prospective users, customers or an autonomous test team. Alpha testing is frequently engaged for off-the-shelf software as acceptance testing, before the software send to beta testing.

Beta Testing: This testing is done after alpha testing. Beta versions of the software are released to limited viewers outside of the programming team. This testing is carried out so that further testing can ensure the software system has few new faults or bugs. Sometimes, these are also made available to the public to increase the feedback ground to a maximal number of future users.

Regression Testing: After every change in functionality or fix defects a regression test re-runs previously applied tests on the modified software to make sure that the modifications in software does not by chance caused a failure of previous functionality. Regression testing may be performed at any levels of software testing.

Testing is usually performed for the improvement quality and reliability estimation purposes. Quality means the fulfillment to the specified design requirement. The flaw of human nature makes it almost impossible to make a quite complex program correct at the first time. So finding the faults and get them fixed, is the purpose of debugging in programming phase. Software reliability has significant relations with every aspect of software, including the structure, and the amount of testing it has been subjected to.

Strategies for Test Case Selection

Effective testing requires strategies to trade-off between the two opposing needs of amplifying testing thoroughness on one side for which a high number of test cases would be desirable and reducing time and cost, on the other for which the fewer the test case the better. Given that test resources are limited, how the test cases are selected becomes of crucial importance. Indeed, the problem of test cases selection has been the largely dominating topic in software testing research to the extent that in the Literature “software testing” is often taken as a synonymous for “test case selection”. A decision procedure for selecting the test cases is provided by a test criterion. A basic criterion is random testing, according to which the test input are picked purely randomly from the completely input domain according to a specified distribution, i.e. after assigning to the inputs different “weights” more properly probabilities.

Software testing methods are traditionally divided into Functional (black box) testing and Program based (white box) testing. These approaches are used to describe the viewpoints when a test engineer designing the test cases. 

Selection Criteria Based on Code

Code-based testing, also said, “Structural testing” or “white box” testing has been the dominating trend in software testing research during the late 70’s and the 80’s. White box testing is used when the tester has right to use the internal structures and algorithms. In the Program based testing methods test case