Proof Techniques in Testing and Stimulation

There are two approaches to proof of correctness: formal proof and informal proof. A formal proof consists of developing a mathematical logic consisting of axioms and inference rules and defining a proof either to be a proof tree in the natural deduction style or to be a finite sequence of axioms and inference rules.

Informal proof techniques follow the logical reasoning behind the formal proof techniques but without the formal logical system.

Simulation is used in real-time systems development where the "real-world" interface is critical and integration with the system hardware is central to the total design. In many nonreal- time applications, simulation is a cost effective verification and test-data generation technique.

To use simulation as a verification tool several models must be developed. Verification is performed by determining if the model of the software behaves as expected on models of the computational and external environments using simulation. This technique also is a powerful way of deriving test data. Inputs are applied to the simulated model and the results recorded for later application to the actual code.

The data sets derived cause errors to be isolated and located as well as detected during the testing phase of the construction and integration stages.

To develop a model of the software for a particular stage in the development life cycle a formal representation compatible with the simulation system is developed. This consists of the formal requirement specification, the design specification, or separate model of the program behavior. If a different model is used, then the developer will need to demonstrate and verify that the model is a complete, consistent, and accurate representation of the software at the stage of development being verified.

The next steps are to develop a model of the computational environment in which the system will operate, a model of the hardware on which the system will be implemented, and a model of the external demands on the total system.

These models can be largely derived from the requirements, with statistical representations developed for the external demand and the environmental interactions. The software behavior is then simulated with these models to determine if it is satisfactory.

Simulating the system at the early development stages is the only means of determining the system behavior in response to the eventual implementation environment. At the construction stage, since the code is sometimes developed on a host machine quite different from the target machine, the code may be run on a simulation of the target machine under interpretive control.

Simulation also plays a useful role in determining the performance of algorithms.

Related Posts

Walk throgh's and inspections in software testing
TESTING CONSTRAINTS PART TWO

LIFE CYCLE TESTING

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique

Operation testing technique

Compliance software testing technique

Security testing technique

Walk throughs,Inspections of software testing part two

This post is continuation with previous post Walk tyhroughs,Inspections of software testing part one.

1.System Requirements Review

This review is an examination of the initial progress during the problem definition stage and of the convergence on a complete system configuration. Test planning and test documentation are begun at this review.

2 • System Design Review

This review occurs when the system definition has reached a point where major system modules can be identified and completely specified along with the corresponding test requirements. The requirements for each major subsystem are examined along with the preliminary test plans. Tools required for verification support are identified at this stage.

3• Preliminary Design Review

This review is a formal technical review of the basic design approach for each major subsystem or module. The revised requirements and preliminary design specifications for each major subsystem and all test plans, procedures and documentation are reviewed at this stage. Development and verification tools are further identified at this stage. Changes in requirements will lead to an examination of the test requirements to maintain consistency.

4• Final Design Review

This review occurs just prior to the beginning of the construction stage. The complete and detailed design specifications for each module and all draft test plans and documentation are examined. Again, consistency with previous stages is reviewed, with particular attention given to determining if test plans and documentation reflect changes in the design specifications at all levels.

5• Final Review

This review determines through testing that the final coded subsystem conforms to the final system specifications and requirements. It is essentially the subsystem acceptance test.

Rules should be followed for all reviews:

1. The product is reviewed, not the producer.
2. Defects and issues are identified, not corrected.
3. All members of the reviewing team are responsible for the results of the review.

Reviews are conducted to utilize the variety of perspectives and talents brought together in a team. The main goal is to identify defects within the stage or phase of the project where they originate, rather than in later test stages; this is referred to as “stage containment.”

As reviews are generally greater than 65 percent efficient in finding defects, and testing is often less than 30 percent efficient, the advantage is obvious. In addition, since defects identified in the
review process are found earlier in the life cycle, they are less expensive to correct.

Another advantage of holding reviews is not readily measurable. That is, reviews are an efficient method of educating a large number of people on a specific product/project in a relatively short period of time. Semiformal reviews are especially good for this, and indeed, are often held for just that purpose.

In addition to learning about a specific product/project, team members are exposed to a variety of approaches to technical issues, a cross-pollination effect. Finally, reviews provide training in and enforce the use of standards, as non conformance to standards is considered a defect and reported as such.

Related Posts

Parallel testing technique
TESTING CONSTRAINTS PART TWO

LIFE CYCLE TESTING

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique

Operation testing technique

Compliance software testing technique

Security testing technique

Walkthroughs,Inspections of software testing

Walkthroughs and inspections are formal manual techniques that are a natural evolution of desk checking. Both procedures require a team, usually directed by a moderator. The team includes the developer, but the remaining members and the moderator should not be directly involved in the development effort.

Both techniques are based on a reading of the product (e.g., requirements, specifications, or code) in a formal meeting environment with specific rules for evaluation. The difference between inspection and walkthrough lies in the conduct of the meeting. Both methods require preparation and study by the team members, and scheduling and coordination by the team moderator.

Inspection involves a step-by-step reading of the product, with each step checked against a predetermined list of criteria. These criteria include checks for historically common errors. Guidance for developing the test criteria can be found elsewhere. The developer is usually required to narrate the reading product. The developer finds many errors just by the simple act of reading aloud.

Walkthroughs differ from inspections in that the programmer does not narrate a reading of the product by the team, but provides test data and leads the team through a manual simulation of the system. The test data is walked through the system, with intermediate results kept on a blackboard or paper.

The test data should be kept simple given the constraints of human simulation. The purpose of the walkthrough is to encourage discussion, not just to complete the system simulation on the test data. Most errors are discovered through questioning the developer's decisions at various stages, rather than through the application of the test data.

At the problem definition stage, walkthrough and inspection can be used to determine if the requirements satisfy the testability and adequacy measures as applicable to this stage in the development. If formal requirements are developed, formal methods, such as correctness techniques, may be applied to ensure adherence with the quality factors.

Walkthroughs and inspections should again be performed at the preliminary and detailed design stages. Design walkthroughs and inspection will be performed for each module and module interface. Adequacy and testability of the module interfaces are very important. Any changes that result from these analysis will cause at least a partial repetition of the verification at both stages and between the stages. A reexamination of the problem definition and requirements may also be required.

Finally, the walkthrough and inspection procedures should be performed on the code produced during the construction stage. Each module should be analyzed separately and as integrated parts of the finished software.

Related Posts

White and black box testing
TESTING CONSTRAINTS PART TWO

LIFE CYCLE TESTING

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique

Operation testing technique

Compliance software testing technique

Security testing technique

Parallel Testing Techniques

Parallel testing is used to determine that the results of the new application are consistent with the processing of the previous application or version of the application.

What are the objectives of parallel testing ?

1. Conduct redundant processing to ensure that the new version or application performs correctly.
2. Demonstrate consistency and inconsistency between two versions of the same application system.

How to Use Parallel Testing ?

Parallel testing requires that the same input data be run through two versions of the same application. Parallel testing can be done with the entire application or with a segment of the application.

Sometimes a particular segment, such as the day-to-day interest calculation on a savings account, is so complex and important that an effective method of testing is to run the new logic in parallel with the old logic.

If the new application changes data formats, then the input data will have to be modified before it can be run through the new application. This also makes it difficult to automatically check the results of processing through a tape or disk file compare.

The more difficulty encountered in verifying results or preparing common input, the less attractive the parallel testing technique becomes.

What are the Parallel Test Examples ?

1. • Operate a new and old version of a payroll system to determine that the paychecks from both systems are reconcilable.
2. • Run the old version of the application system to ensure that the operational status of the old system has been maintained in the event that problems are encountered in the new application.

When to Use Parallel Testing ?

Parallel testing should be used when there is uncertainty regarding the correctness of processing of the new application, and the old and new versions of the application are similar.

In applications like payroll, banking, and other heavily financial applications where the results of processing are similar, even though the methods may change significantly – for example, going from batch to online banking – parallel testing is one of the more effective methods of ensuring the integrity of the new application.

Related Posts

Control software testing technique
TESTING CONSTRAINTS PART TWO

LIFE CYCLE TESTING

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique

Operation testing technique

Compliance software testing technique

Security testing technique

Control Software Testing Technique

Controls include data validation, file integrity, audit trail, backup and recovery, documentation, and the other aspects of systems related to integrity. Control testing techniques are designed to ensure that the mechanisms that oversee the proper functioning of an application system work.

What are the objectives of control testing technique ?

Control is a management tool to ensure that processing is performed in accordance with the intents of management. The objectives are

1. Data is accurate and complete
2. Transactions are authorized
3. An adequate audit trail of information is maintained.
4. The process is efficient, effective, and economical
5. The process meets the needs of the user

How to Use Control Testing?

Control can be considered a system within a system. The term “system of internal controls” is frequently used in accounting literature to describe the totality of the mechanisms that ensure the integrity of processing.

Controls are designed to reduce risks; therefore, in order to test controls the risks must be identified. The individual designing the test then creates the risk situations in order to determine whether the controls are effective in reducing them to a predetermined acceptable level of risk.

What are the control testing examples ?

Control-oriented people frequently do control testing. Like error-handling, it requires a negative look at the application system to ensure that those “what-can-go-wrong” conditions are adequately protected. Error-handling is a subset of controls oriented toward the detection and correction of erroneous information. Control in the broader sense looks at the totality of the system.

Examples of testing that might be performed to verify controls include:

1. Determine that there is adequate assurance that the detailed records in a file equal the control total. This is normally done by running a special program that accumulates the detail and reconciles it to the total.
2. Determine that the manual controls used to ensure that computer processing is correct are in place and working.

When to use control testing ?

Control testing should be an integral part of system testing. Controls must be viewed as a system within a system, and tested in parallel with other system tests. Knowing that approximately 50 percent of the total development effort goes into controls, a proportionate part of testing should be allocated to evaluating the adequacy of controls.

Related Posts

Manual support testing
TESTING CONSTRAINTS PART TWO

LIFE CYCLE TESTING

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique

Operation testing technique

Compliance software testing technique

Security testing technique

Manual Support Testing

What are the objectives of manual support testing ?
Manual support involves all the functions performed by people in preparing data for, and using data from, automated applications. The objectives of testing the manual support systems are:

1. • Verify that the manual support procedures are documented and complete
2. • Determine that manual support responsibility has been assigned.
3. • Determine that the manual support people are adequately trained
4. • Determine that the manual support and the automated segment are properly interfaced

How to Use Manual Support Testing ?

Manual testing involves the evaluation of the adequacy of the process and the execution of the process. The process itself can be evaluated in all segments of the systems development life cycle.

To test people processing requires testing the interface between people and the application system. That is entering the transactions, and then getting the results back from that processing, making additional actions based on the information received, until all aspects of the manual computer interface have been adequately tested.

The manual support testing should occur without the assistance of the systems personnel. The manual support group should operate using the training and procedures provided them by the systems personnel. But the systems personnel should evaluate the results to determine if the tests have been adequately performed.

What are the manual support test examples ?

The process of conducting manual support testing can include the following types of tests:

1. Providing input personnel with the type of information they would normally receive from their customers and then have them transcribe that information and enter it into the computer.
2. Output reports are prepared from the computer based on typical conditions, and the users are then asked to take the necessary action based on the information contained in computer reports.
3. Users can be provided a series of test conditions and then asked to respond to those conditions. Conducted in this manner, manual support testing is like an examination in which the users are asked to obtain the answer from the procedures and manuals available to them.

When to use manual support testing ?

Extensive manual support testing is best done during the installation phase so that the clerical people do not become involved with the new system until immediately prior to its entry into operation. This avoids the confusion of knowing two systems and not being certain which rules to follow.

During the maintenance and operation phases, manual support testing may only involve providing people with instructions on the changes and then verifying with them through questioning that they properly understand the new procedures.(137.6)

Related Posts

Intersystem software testing technique
TESTING CONSTRAINTS PART TWO

LIFE CYCLE TESTING

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique

Operation testing technique

Compliance software testing technique

Security testing technique

Intersystem Sopftware Testing Technique

Application systems are frequently interconnected to other application systems. The interconnection may be data coming into the system from another application, leaving for another application, or both. Frequently multiple applications, sometimes called cycles or functions are involved.

What are the objectives of inter system testing technique ?

Many problems exist in inter system testing. One is that it is difficult to find a single individual having jurisdiction over all of the systems below the level of senior management. In addition, the process is time-consuming and costly. The objectives of intersystem testing include:

1. • Determine that proper parameters and data are correctly passed between applications
2. • Ensure that proper coordination and timing of functions exists between the application systems
3. • Determine that documentation for the involved systems is accurate and complete

How to Use Intersystem Testing ?

Intersystem testing involves the operation of multiple systems in the test. Thus, the cost may be expensive, especially if the systems have to be run through several iterations. The process is not difficult; in that files or data used by multiple systems are passed from one another to verify that they are acceptable and can be processed properly. However, the problem can be magnified during maintenance when two or more of the systems are undergoing internal changes concurrently.

One of the best testing tools for inter system testing is the integrated test facility. This permits testing to occur during a production environment and thus the coupling of systems can be tested at minimal cost.

What are the inter system test examples ?

1. Developing a representative set of test transactions in one application for passage to another application for processing verification.
2. Entering test transactions in a live production environment using the integrated test facility so that the test conditions can be passed from application to application to application, to verify that the processing is correct.
3. Manually verifying that the documentation in the affected systems is updated based upon the new or changed parameters in the system being tested.

When to Use Intersystem Testing ?

Inter system testing should be conducted whenever there is a change in parameters between application systems. The extent and type of testing will depend on the risk associated with those parameters being erroneous. If the integrated test facility concept is used, the inter system parameters can be verified after the changed or new application is placed into production.(138)

Related Posts

Error handling testing
TESTING CONSTRAINTS PART TWO

LIFE CYCLE TESTING

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique

Operation testing technique

Compliance software testing technique

Security testing technique

What is Error Handling Testing ?

Manual systems can deal with problems as they occur, but automated systems must pre program error-handling. In many instances the completeness of error handling affects the usability of the application. Error-handling testing determines the ability of the application system to properly process incorrect transactions.

What are its Objectives ?

Errors encompass all unexpected conditions. In some systems, approximately 50 percent of the programming effort will be devoted to handling error conditions. Specific objectives of error-handling testing include:

1. Determine that all reasonably expected error conditions are recognizable by the application system.
2. Determine that the accountability for processing errors has been assigned and that the procedures provide a high probability that the error will be properly corrected.
3. Determine that reasonable control is maintained over errors during the correction process.

How to Use Error Handling Testing ?

It requires a group of knowledgeable people to anticipate what can go wrong with the application system. The other forms of testing involve verifying that the application system conforms to requirements. Error-handling testing uses exactly the opposite concept.

A successful method for developing test error conditions is to assemble, for a half-day or a day, people knowledgeable in information technology, the user area, and auditing or error tracking.These individuals are asked to brainstorm what might go wrong with the application.

The totality of their thinking must then be organized by application function so that a logical set of test transactions can be created. Without this type of synergistic interaction on errors, it is difficult to develop a realistic body of problems prior to production.

Error-handling testing should test the introduction of the error, the processing of the error, the control condition, and the reentry of the condition properly corrected. This requires error handling testing to be an iterative process in which errors are first introduced into the system,then corrected, then reentered into another iteration of the system to satisfy the complete error-handling cycle.

What are Error-Handling Test Examples ?

1. Produce a representative set of transactions containing errors and enter them into the system to determine whether the application can identify the problems.
2. Through iterative testing, enter errors that will result in corrections, and then reenter those transactions with errors that were not included in the original set of test transactions.
3. Enter improper master data, such as prices or employee pay rates, to determine if errors that will occur repetitively are subjected to greater scrutiny than those causing single error results.

When to Use Error-Handling Testing ?

Error testing should occur throughout the system development life cycle. At all points in the developmental process the impact from errors should be identified and appropriate action taken to reduce those errors to an acceptable level. Error-handling testing assists in the error management process of systems development and maintenance. Some organizations use auditors, quality assurance, or professional testing personnel to evaluate error processing.

Related Posts

TESTING CONSTRAINTS PART TWO

LIFE CYCLE TESTING

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique

Operation testing technique

Compliance software testing technique

Security testing technique

What is Manual Support Testing ?

Systems commence when transactions originate and conclude with the use of the results of processing. The manual part of the system requires the same attention to testing, as does the automated segment. Although the timing and testing methods may be different, the objectives of manual testing remain the same as testing the automated segment of the application system.

What are the objectives of manual support testing ?

Manual support involves all the functions performed by people in preparing data for, and using data from, automated applications. The objectives of testing the manual support systems are:

1. • Verify that the manual support procedures are documented and complete
2. • Determine that manual support responsibility has been assigned.
3. • Determine that the manual support people are adequately trained
4. • Determine that the manual support and the automated segment are properly interfaced

How to Use Manual Support Testing ?

Manual testing involves the evaluation of the adequacy of the process first, and then, second, the execution of the process. The process itself can be evaluated in all segments of the systems development life cycle. The execution of the process can be done in conjunction with normal systems testing. Rather than prepare and enter test transactions, the system can be tested having the actual clerical and supervisory people prepare, enter, and use the results of processing from the application system.

Manual testing normally involves several iterations of the process. To test people processing requires testing the interface between people and the application system. This means entering transactions, and then getting the results back from that processing, making additional actions based on the information received, until all aspects of the manual computer interface have been adequately tested.

The manual support testing should occur without the assistance of the systems personnel. The manual support group should operate using the training and procedures provided them by the systems personnel. The systems personnel should evaluate the results to determine if the tests have been adequately performed.

What are the Manual Support Test Examples ?

The process of conducting manual support testing can include the following types of tests:

1. • Provide input personnel with the type of information they would normally receive from their customers and then have them transcribe that information and enter it into the computer.
2. • Output reports are prepared from the computer based on typical conditions, and the users are then asked to take the necessary action based on the information contained in computer reports.
3. • Users can be provided a series of test conditions and then asked to respond to those conditions. Conducted in this manner, manual support testing is like an examination in which the users are asked to obtain the answer from the procedures and manuals available to them.

When to Use Manual Support Testing ?

Verification that the manual systems function properly should be conducted throughout the systems development life cycle. This aspect of system testing should not be left to the latter stages of the life cycle to test.

Extensive manual support testing is best done during the installation phase so that the clerical people do not become involved with the new system until immediately prior to its entry into operation. This avoids the confusion of knowing two systems and not being certain which rules to follow. During the maintenance and operation phases, manual support testing may only involve providing people with instructions on the changes and then verifying with them through questioning that they properly understand the new procedures.

Related Posts

Regression testing
UNIT TESTING

UNIT TESTING PART ONE

UNIT TESTING PART TWO

UNIT TESTING PART THREE

GUI TESTING

WINDOWS COMPLIANCE GUI TESTING PART ONE

WINDOWS COMPLIANCE GUI TESTING PART TWO

WINDOWS COMPLIANCE GUI TESTING PART THREE

WINDOWS COMPLIANCE GUI TESTING PART FOUR VALIDATION TESTING

WINDOWS COMPLIANCE GUI TESTING PART FIVE CONDITION TESTING

WINDOWS COMPLIANCE GUI TESTING PART SIX GENERAL CONDITION TESTING

What is Regression Testing ?

Regression testing retests previously tested segments to ensure that they still function properly after a change has been made to another part of the application.

What are the objectives of regression testing ?

Regression testing involves assurance that all aspects of an application system remain functional after testing. The introduction of change is the cause of problems in previously tested segments. The objectives of regression testing include:

1. Determine whether systems documentation remains current
2. Determine that system test data and test conditions remain current
3. Determine that previously tested system functions perform properly after changes are introduced into the application system.

How to Use Regression Testing ?

Regression testing is retesting unchanged segments of the application system. It normally involves rerunning tests that have been previously executed to ensure that the same results can be achieved currently as were achieved when the segment was last tested. While the process is simple in that the test transactions have been prepared and the results known, unless the process is automated it can be a very time-consuming and tedious operation. It is also one in which the cost/benefit needs to be carefully evaluated or large amounts of effort can be expended with minimal payback.

What are Regression Test Examples ?

1. Rerunning of previously conducted tests to ensure that the unchanged system segments function properly.
2. Reviewing previously prepared manual procedures to ensure that they remain correct after changes have been made to the application system.
3. Obtaining a printout from the data dictionary to ensure that the documentation for data elements that have been changed is correct.

When to Use Regression Testing ?

Regression testing should be used when there is a high risk that new changes may affect unchanged areas of the application system. In the developmental process, regression testing should occur after a predetermined number of changes are incorporated into the application system.
In maintenance, regression testing should be conducted if the potential loss that could occur due to affecting an unchanged portion is very high. The determination as to whether to conduct regression testing should be based upon the significance of the loss that could occur due to improperly tested applications.

Related Posts

Testing metrics and Life cycle testing

UNIT TESTING

UNIT TESTING PART ONE

UNIT TESTING PART TWO

UNIT TESTING PART THREE

GUI TESTING

WINDOWS COMPLIANCE GUI TESTING PART ONE

WINDOWS COMPLIANCE GUI TESTING PART TWO

WINDOWS COMPLIANCE GUI TESTING PART THREE

WINDOWS COMPLIANCE GUI TESTING PART FOUR VALIDATION TESTING

WINDOWS COMPLIANCE GUI TESTING PART FIVE CONDITION TESTING

WINDOWS COMPLIANCE GUI TESTING PART SIX GENERAL CONDITION TESTING

What is Requirements Testing Technique

Functional system testing ensures that the system requirements and specifications are achieved. The process normally involves creating test conditions for use in evaluating the correctness of the application.

Requirements testing must verify that the system can perform its function correctly and that the correctness can be sustained over a continuous period of time. Unless the system can function correctly over an extended period of time, management will not be able to rely upon the system. The system can be tested for correctness throughout the life cycle, but it is difficult to test the reliability until the program becomes operational.

What are the objectives of Requirements Testing Technique ?

Successfully implementing user requirements is only one aspect of requirements testing. The responsible user is normally only one of many groups having an interest in the application system. The objectives that need to be addressed in requirements testing are:

1. Implement user requirements
2. Maintain correctness over extended processing periods
3. Ensure that application processing complies with the organization’s policies and procedures

Secondary user needs have been included, such as:

1. Security officer
2. Database administrator
3. Internal auditors
4. Records retention
5. Comptroller
6. System processes accounting information in accordance with generally accepted accounting procedures.
7. Application systems process information in accordance with governmental regulations.

How to Use Requirements Testing ?

Requirements’ testing is primarily performed through the creation of test conditions and functional checklists. Test conditions are generalized during requirements, and become more specific as the SDLC progresses, leading to the creation of test data for use in evaluating the implemented application system.

Functional testing is more effective when the test conditions are created directly from user requirements. When test conditions are created from the system documentation, defects in that documentation will not be detected through testing. When the test conditions are created from other than the system documentation, defects introduced into the documentation will be detected.

Where to use Requirements Testing Technique ?

1. Creating a test matrix to prove that the systems requirements as documented are the requirements desired by the user.
2. Using a checklist prepared specifically for the application to verify the application’s compliance to organizational policies and governmental regulations.
3. Determining that the system meets the requirements established by the organization’s department of internal auditors.

When to Use Requirements Testing ?

Every application should be requirements tested. The process should begin in the requirements phase, and continue through every phase of the life cycle into operations and maintenance. It is not a question as to whether requirements must be tested but, rather, the extent and methods used in requirements testing.(134.1)

Related Posts

UNIT TESTING

UNIT TESTING PART ONE

UNIT TESTING PART TWO

UNIT TESTING PART THREE

GUI TESTING

WINDOWS COMPLIANCE GUI TESTING PART ONE

WINDOWS COMPLIANCE GUI TESTING PART TWO

WINDOWS COMPLIANCE GUI TESTING PART THREE

WINDOWS COMPLIANCE GUI TESTING PART FOUR VALIDATION TESTING

WINDOWS COMPLIANCE GUI TESTING PART FIVE CONDITION TESTING

WINDOWS COMPLIANCE GUI TESTING PART SIX GENERAL CONDITION TESTING

Security Testing Technique

Security is a protection system that is needed for both secure confidential information and for competitive purposes to assure third parties their data will be protected. The amount of security provided will be dependent upon the risks associated with compromise or loss of information.

Protecting the confidentiality of the information is designed to protect the resources of the organization.However, information such as customer lists or improper disclosure of customer information may result in a loss of customer business to competitors. Security testing is designed to evaluate the adequacy of the protective procedures and countermeasures.

What are the Objectives of Security Testing ?

Security defects do not become as obvious as other types of defects. Therefore, the objectives of security testing are to identify defects that are very difficult to identify. Even failures in the security system operation may not be detected, resulting in a loss or compromise of information without the knowledge of that loss. The security testing objectives include:

1. Determine that adequate attention is devoted to identifying security risks
2. Determine that a realistic definition and enforcement of access to the system is implemented
3. Determine that sufficient expertise exists to perform adequate security testing
4. Conduct reasonable tests to ensure that the implemented security measures function properly

How to Use Security Testing Techniques ?

Security testing is a highly specialized part of the test process. Most organizations can evaluate the reasonableness of security procedures to prevent the average perpetrator from penetrating the application. However, the highly skilled perpetrator using sophisticated techniques may use methods undetectable by novices designing security measures and/or testing those measures.

The first step in testing is the identification of the security risks and the potential loss associated with those risks. If either the loss is low or the penetration method mere routine, the information technology personnel can conduct the necessary tests. On the other hand, if either the risks are very high or the technology that might be used is sophisticated, specialized help should be acquired in conducting the security tests.

Where do we use security testing ?

Security testing involves a wide spectrum of conditions. Testing can first be divided into physical and logical security. Physical deals with the penetration by people in order to physically gather information, while logical security deals with the use of computer processing and/or communication capabilities to improperly access information. Second, access control can be divided by type of perpetrator, such as employee, consultant, cleaning or service personnel, as well as categories of employees. The type of test conducted will vary upon the condition being tested and can include:

1. Determination that the resources being protected are identified, and access is defined for each resource. Program or individual can define access.
2. Evaluation as to whether the designed security procedures have been properly implemented and function in accordance with the specifications.
3. Unauthorized access can be attempted in online systems to ensure that the system can identify and prevent access by unauthorized sources.

When to Use Security Testing ?

Security testing should be used when the information and/or assets protected by the application system are of significant value to the organization. The testing should be performed both prior to the system going into an operational status and after the system is placed into an operational status. The extent of testing should depend on the security risks, and the individual assigned to conduct the test should be selected based on the estimated sophistication that might be used to penetrate security.

(132.2)

Related Posts

Compliance Testing technique Recovery testing technique Execution testing Structural software testing Static and dynamic testing Functional and structural testing Testing verification and validation Test Process Independent Software Testing and part two Testing metrics and Life cycle testing c programming break statement V model Software Testing

Other Programming Courses :

ASP.NET part one and two
Programming with C and C Sharp
Dot Net Complete Course Part one and two
Interview Questions in dot net and asp.net part one part two
Software Testing Complete course part one and two
Interview Questions in software Testing


Learn complete software testing course here as basic and advanced parts .

Thank you for visiting PROGRAMMING BLOG. If you liked the post, please subscribe to my blog via email or RSS FEED.You can contact me here for any specific feed back .

COMMENT HERE and thank you for sparing your valuable time.

I will be very glad if you share this page on your social book marking site with the below link.

Compliance Software Testing Technique

Compliance testing verifies that the application was developed in accordance with information technology standards, procedures, and guidelines. The methodologies are used to increase the probability of success, to enable the transfer of people in and out of the project with minimal cost, and to increase the maintainability of the application system.

The type of testing conducted varies on the phase of the systems development life cycle. However, it may be more important to compliance test adherence to the process during requirements than at
later stages in the life cycle because it is difficult to correct applications when requirements are not adequately documented.

What is the objective of Compliance testing ?

Compliance testing is performed to both ensure compliance to the methodology and to encourage and help the information technology professional comply with the methodology.

Specific compliance objectives include:

1. Determine that systems development and maintenance methodologies are followed.
2. Ensure compliance to departmental standards, procedures, and guidelines.
3. Evaluate the completeness and reasonableness of application system documentation.

How to Use Compliance Testing ?

Compliance testing requires that the prepared document or program is compared to the standards for that particular program or document. A colleague would be the most appropriate person to do this comparison. The most effective method of compliance testing is the inspection process.

Examples

A peer group of programmers would be assembled to test line-by-line that a computer program is compliant with programming standards. At the end of the peer review, the programmer would be given a list of non compliant information that would need to be corrected.

When to Use Compliance Testing ?

Compliance to information technology application system development standards and procedures is dependent upon management’s desire to have the procedures followed and the standards enforced. Therefore, if management really wants compliance they should perform sufficient tests to determine both the degree of compliance with the methodology and to identify violators for management action.

However, lack of compliance should also be used from the perspective that the standards may be misunderstood, not adequately instructed or publicized, or may, in fact, be poor standards inhibiting the development of application systems. In these instances, it may be desirable to change the methodology.

Related Posts

(132.2)

CONDITION TESTING

TESTING CONDITIONS PART ONE

TESTING CONDITIONS PART TWO

TESTING CONDITIONS PART THREE

TESTING CONDITIONS PART FOUR

SPECIFIC FIELD TESTING

USABILITY TESTING

INTEGRATION TESTING

INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO

Software Testing Operations Technique

Operations’ testing is designed to verify prior to production that the operating procedures and staff can properly execute the application.

Objectives of operations testing technique :

Operations’ testing is primarily designed to determine whether the system is executable during normal systems operations. The specific objectives include:

1. Determine the completeness of computer operator documentation
2. Ensure that the necessary support mechanisms, such as job control language, are prepared and function properly
3. Evaluate the completeness of operator training
4. Test to ensure that operators using prepared documentation can, in fact, operate the system.

The way of using operations testing :

Operations’ testing evaluates both the process and the execution of the process. During the requirements phase, operational requirements can be evaluated to determine the reasonableness and completeness of those requirements. During the design phase, the operating procedures should be designed and thus can be evaluated. This continual definition of the operating procedures should be subjected to continual testing.

The execution of operations testing can normally be performed in conjunction with other tests. However, if operations’ testing is included, the operators should not be prompted or helped by outside parties during the test process. The test needs to be executed as if it was part of normal computer operations in order to adequately evaluate the effectiveness of computer operators in running the application in a true-to-life operations environment.

Example :

1. Determining that the operator instructions have been prepared and documented in accordance with other operations instructions, and that computer operators have been trained in any unusual procedures.
2. Testing that the job control language statements and other operating systems support features perform the predetermined tasks.
3. Verifying that the file labeling and protection procedures function properly.

When operations testing shall be used ?

Operations’ testing should occur prior to placing any application into a production status. If the application is to be tested in a production-type setting, operations testing can piggyback that process at a very minimal cost. It is as important to identify an operations flaw as it is an application flaw prior to placing the application into production.

Related Posts

CONDITION TESTING

TESTING CONDITIONS PART ONE

TESTING CONDITIONS PART TWO

TESTING CONDITIONS PART THREE

TESTING CONDITIONS PART FOUR

SPECIFIC FIELD TESTING

USABILITY TESTING

INTEGRATION TESTING

INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO

Software Testing Execution Testing Technique

Execution testing determines whether the system achieves the desired level of proficiency in a production status. Execution testing can verify response times, turnaround times, as well as design performance. The execution of a system can be tested in whole or in part, using the actual system or a simulated model of a system.

Objectives

Execution testing is used to determine whether the system can meet the specific performance criteria. The objectives of execution testing include:

1. Determine the performance of the system structure.
2. Verify the optimum use of hardware and software.
3. Determine the response time to online user requests.
4. Determine transaction processing turnaround time.

How to Use ?

Execution testing can be conducted in any phase of the system development life cycle. The testing can evaluate a single aspect of the system, for example, a critical routine in the system, or the ability of the proposed structure to satisfy performance criteria. Execution testing can be performed in any of the following manners:

1. Using hardware and software monitors
2. Simulating the functioning of all or part of the system using a simulation model
3. Creating a quick and dirty program(s) to evaluate the approximate performance of a completed system

Execution testing may be executed on-site or off-site for the performance of the test. For example, execution testing can be performed on hardware and software before being acquired, or may be done after the application system has been completed. The earlier the technique is used, the higher the assurance that the completed application will meet the performance criteria.

Examples of the use of execution testing :

1. Calculating turnaround time on transactions processed through the application.
2. Determining that the hardware and software selected provide the optimum processing capability.
3. Using software monitors to determine that the program code is effectively used.

When to Use Execution Testing ?

Execution testing should be used early in the developmental process. While there is value in knowing that the completed application does not meet performance criteria, if that assessment is not known until the system is operational, it may be too late or too costly to make the necessary modifications. Therefore, execution testing should be used at that point in time when the results can be used to affect or change the system structure.(127.1)

Related Posts
CONDITION TESTING

TESTING CONDITIONS PART ONE

TESTING CONDITIONS PART TWO

TESTING CONDITIONS PART THREE

TESTING CONDITIONS PART FOUR

SPECIFIC FIELD TESTING

USABILITY TESTING

INTEGRATION TESTING

INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO

Software Testing Effecting factors

People Relationships:

The word “testing” conjures up a variety of meanings depending upon an individual’s frame of reference. Some people view testing as a method or process by which they add value to the development cycle; they can even enjoy the challenges and creativity of testing.

Other people feel that testing tries a person’s patience, fairness, ambition, credibility, and capability. Testing can actually affect a person’s mental and emotional health if you consider the office politics and interpersonal conflicts that are often times present.

Some attitudes that have shaped a negative view of testing and testers are:

1 • Testers hold up implementation.

2 • Giving testers less time to test will reduce the chance that they will find defects.

3 • Letting the testers find problems is an appropriate way to debug.

4 • Defects found in production are the fault of the testers.

5 • Testers do not need training; only programmers need training.


Although testing is a process, it is very much a dynamic one in that the process will change somewhat with each application under test. There are several variables that affect the testing process including :

the development process itself, software risk, customer/user participation, the testing process, a tester’s skill set, use of tools, testing budget and resource constraints, management support, and morale and motivation of the testers. It is obvious that the people side of software testing has long been ignored for the more process-related issues of test planning, test tools, defect tracking, and so on.

Surviving the Top Ten Challenges of Software Testing, the challenges have been identified as:

1 • Training in testing

2 • Relationship building with developers

3 • Using tools

4 • Getting managers to understand testing

5 • Communicating with users about testing

6 • Making the necessary time for testing

7 • Testing “over the wall” software

8 • Trying to hit a moving target

9 • Fighting a lose-lose situation

10 • Having to say “no”

Testers should perform a self-assessment to identify their own strengths and weaknesses as they relate to people-oriented skills. They should also learn how to improve the identified weaknesses, and build a master plan of action for future improvement.

Essential testing skills include test planning, using test tools (automated and manual), executing tests, managing defects, risk analysis, test measurement, designing a test environment, and designing effective test cases. Additionally, a solid vocabulary of testing is essential. A tester needs to understand what to test, who performs what type of test, when testing should be performed, how to actually perform the test, and when to stop testing.

91.8

RELATED POST

DEFECT REDUCTION IN SOFTWARE TESTING

Modes-Conditions in software testing part three

38	All fonts to be the same
39	Alt+F4 will close the tabbed window and return you to main screen or previous screen (as appropriate), generating "changes will be lost" message if necessary
40	Microhelp text for every enabled field & button
41	Ensure all fields are disabled in read-only mode
42	Progress messages on load of tabbed screens
43	Return operates continue
44	If retrieve on load of tabbed window fails window should not open	WHITE BOX TESTING WHITE BOX TESTING PART TWO WHITE BOX TESTING PART THREE WHITE BOX BASIC PATH TESTING BLACK BOX TESTING PART ONE BLACK BOX TESTING PART TWO AUTOMATION IN TESTING AUTOMATED TESTING TOOLS AUTOMATED TESTING ANALYSIS AUTOMATION BEST PRACTICES AUTOMATED TESTING PROCESS CHECK POINTS IN AUTOMATED TESTING SILK TEST SILK TEST INTRODUCTION FEATURES OF SILK TEST FEATURES OF SILK TEST PART TWO LIMITATIONS TEST PLAN FOR SILK TEST INSTALLATION TIPS FOR SILK TEST TEST CASES IN SILK TEST