|
• What is Functional Testing?
• What is Error-Oriented Testing? • What is Hybrid Approaches Testing? • What is Integration Strategies Testing? • What is Transaction Flow Testing? |
Functional Testing generates test data based on the requirement document specifying the behavior of the software. The major objective of the functional testing technique is to verify the behavior of the software over some subset of its input and measure the quality of the function (business) component of the system. Functional testing is the beginning phase for any software test team during any given release. Functional testing is a powerful testing technique which reduces significant number of defects in the application. Functional test cases are derived from functional requirements of the software that are the basis for system testing
Functional testing is sometime also refers to as GUI Testing or Black Box testing which require no knowledge of code or inner design. It is a concrete box or functional testing that checks the output of a program, given certain inputs, conforms to the functional specification of the software programs.
Functional Test can be designed as follows:
- Specify Functional Test Cases:
Based on the requirement document, functional test cases are designed in a systematic and organized ways. Most of the companies adapt tools to manage their documents. There are vendor's management tools as well as open sources. Test Director/Quality Center from Mercury HP is one of the very popular tools. A group or test suite is necessary to organize test cases/scripts. A main folder is designed and named after usually a release month i.e. JanM09.
A sub folder is designed to reflect whole project under the main folder and initiated its name after the project name i.e. '1000.ABC Online Transaction'. Any new or existing tests can be stored and retrieved easily in a manageable way. - Creating Functional Test Cases:
As mentioned above, we need to select the suite to generate new test cases. Two major aspects of generating test cases are a. Details of the test case and b. Design Steps of the test case.- Details
- Design Steps
- Test Name
- Test Status
- Test Plan Priority:
- Project:
- Program:
- Release:
- Test Designer:
- Application:
- Test Creation Date:
Design Steps include the following fields:
- Steps Name:
- Steps Description:
- Expected Result:
- Program:
- Executing Functional Test Cases:
Upon completion of the test case design or planning, next phase of the testing is the execution of the test cases or scripts against AUT. Execution module needs to be selected to execute test cases. Test case can be run manually as well as by using automation. When we begin running manual test case, we need to concentrate mainly on the following modules :- Select first Steps Name
- Read the description
- Read the Expected Results
- Invoke AUT and start executing test case
- When execution is finished, change the status to passed/Failed
- Insert the result of execution into Actual Result box
- End the Test Run
- Verify Functional Test Results:
After test case Execution, we can view/verify execution results to track the test run. We can check details of the execution results such as the execution date, attachments, Configuration, Status, History of execution etc. This will help manage projects, and all the documentation in an efficient way. - Reporting & Tracking Defect:
When we come across any issue or defect during the execution of the test, another de facto technique is to record, report, and track the issue. Here is how we can track defects by using tools. Report module needs to be selected to report issue. Following fields need to be filled with the adequate informations:
- Summary: (a brief one liner explaining about a defect)
- Application Name:
- Defect Priority:
- Detected By:
- Detected Date:
- Bug Status:
- Release:
- Assigned To:
- Cause of Defect:
- Reproducible:
- Description:
Functional Testing includes the following testing types
- Positive Testing
- Negative Testing
- Validation Testing
- Back-End Testing
- Security Testing
Functional Testing Tools include:
- Win Runner
- Quick Test Pro
- Test Director/Quality Center
Structural Testing is conducted at source code level where test data is developed based on the implementation of the product. Structural Testing technique includes 'data flow anomaly detection', 'data flow coverage assessment', and 'various level of path'. Structural Testing is applicable to Unit Testing, Integration Testing and Regression Testing. At the System Testing level, Structural Testing is not applicable due to the large size of the system to be tested. But at the module testing and integration testing, all of the structural Testing techniques are possible. So in another word, Structure Testing is also referred to as White Box testing or Clear Box testing as inner code knowledge is required to conduct this kind of testing.
Unit Test includes smallest code possible such as procedures, subroutine, class, method, database etc. Structural Testing technique ensures that software's statements, decisions and logics are entirely exercised by executing codes. Loop constructs are behaving as expected as per the data boundaries. 'Dead Code' is also checked at unit test level as dead code refer to as code that can not be reached for execution by any means of code paths.
Error-Oriented Testing Technique:
Error-Oriented Testing emphasizes on presence or absence of the error in the software programming process. Error-Oriented Testing Technique is applicable to all level of testing such as module, unit, regression, functional testing etc. Error-Oriented Testing Technique uses error-tolerance
Error-based testing:
Error-based testing is done to ensure that certain errors have not been committed in the software process. This test begins with programming process, identifies potential errors in that process and asks how those errors are reflected as faults. It then tries to show the absence of that error.
Fault-based testing:
Fault-based Testing emphasizes that certain prescribed faults are not included in the code. It has two terms local extent and global extent. Local extent describes that the fault has local effect on computation. Global extent tells that a fault will cause software program failure.
Probable Correctness:
Probable Correctness is a probability that no fault exists in a tested program (By Hamlet). Each successful execution ensures that implemented function is correct.
No single testing technique is enough. Hence the idea of having Hybrid Approaches have been developed combining several techniques together. Combination of functional, structural, and error-oriented techniques has been used for Hybrid Approaches incorporating best features of different methods into one new technique. Test data are selected to ensure simultaneous coverage of specification and code. An operational specification language has been designed that enables a structural measure of coverage of the specification
All the individual components or modules are developed and tested and they are put together to build an application or portion of an application. We conduct testing on these components to check the functionalities of the application are working and no issues are encountered due to the integration of the modules. Test cases are design to meet this purpose that interfaces between modules are working. Usually there are three basic types of integration testing:
Top to Bottom Testing
Bottom Up Testing
Sandwich Testing.
Following errors are targeted by Integration approaches:
- Range Errors: When the source of input falls out of range of their destination import/export range error is found. Careful boundary value testing will resolve this error.
- Type Compatibility Errors: User defined mismatches type will create this kind of errors. And error are detected while compiling the source code.
- Representation Error: When the parameters are the same type and meaning is different, we encounter this kind of error. For example, comp. A passes a Time Elapse of type real to comp. B. Comp A is assuming it is passing time in seconds, and Comp. B is assuming time has been passed in milliseconds. Hence, it creates Representation Errors.
- Parameter utilization errors: Some times parameters used can be corrupted due to alteration of information while the module is called. Careful testing can prevent this while compiling source code.
- Domain/computation error: Domain/computation errors are encountered during module testing when specific input values follows the wrong path because of the control flow faults.
Sequence of tasks is executed in the Transaction flow techniques. Such as, let us take an example of a printing task. Here, first sequence would be checking if a file exists and second would be to check if file permission is readable and so on. It is more like sequence of steps of interaction between users and systems. Very nasty bugs can be detected early at this Transition flow testing.
The following steps are taken to conduct Transaction Flow Test Technique:
- Indentifying the transactions points, such as drawing data flow diagram
- Test link/decision in the transaction flow
- Test all the single, double loop in the transaction
- Test all the paths within the transaction flow
- Test that system behavior is normal
Transaction Flow Technique is very effective methods identifying defects at the early stage of software development.
All of the works and hours spent on building software can go waste if the product is not tested properly. Stress testing technique is one of the significant methods to crack down the remaining bottleneck of the software product. The purpose of stress testing is to find potential errors that might harm the software program. Based on the requirement, system is put under pressure beyond its limit and resources and verifies if system can handle the extreme pressure. An example would be logging 100 simultaneously users and monitoring if system can handle it without crashing. It simply attempts to break the software.
Stress testing technique emphasizes on the following errors type :
Potential race condition, Faults processing sequences, Errors in thresh hold and control statement, and Resource contention. Tester will identify those resources first that can be stress tested. Then, test cases are designed and executed. Usually Stress Test is done at the end of the software development. But it is good idea if it can be performed during system testing to identify bottlenecks that might prevent the application to satisfy its specification.
Failure analysis/root cause analysis is one of the significant techniques that attempts to collect and analyze data to indentify the cause of the failures and prevent it from happening in future. Failure Analysis is conducted during validation and verification of the development process. This is required during requirement verification as well. It is also essential to identify product recovery errors which can lead to lost data or files.
Concurrency Analysis technique is often used to examine the interaction of simultaneously executed tasks to make sure that requirement is met. It is often conducted in parallel with the other testing such as system testing. Test is designed and executed and analyzed to exploit the parallelism in the programs and ensure that requirements are met.
The goal of Performance Analysis technique is to ensure that software product meets its specified requirement objectives. This technique is applied during requirement validation to ensure the completeness and feasibility of the product. All the informations are gathered once program is executed, analyzed, and outlined what section of the program needs to be optimize to speed up the program's behavior. Modeling approaches such as Prototyping, simulation are used to ensure performance analysis
| <<Previous | Page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Next>> |
No comments:
Post a Comment