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

Continue and do-while In C Language

When continue is encountered inside any loop, control automatically passes to the beginning of the loop. A continue is usually associated with an if.

Example :

main( )

{

int i, j ;

for ( i = 1 ; i <= 2 ; i++ ) { for ( j = 1 ; j <= 2 ; j++ ) { if ( i == j ) continue ; printf ( "\n%d %d\n", i, j ) ; } } } The output of the above program would be... 1 2 2 1 The continue statement takes the control to the for loop (inner) bypassing rest of the statements pending execution in the for loop (inner). The do-while Loop

The do-while loop looks like this:

do
{
this ;
and this ;
and this ;
and this ;
} while ( this condition is true ) ;

The difference between the working of while and do-while loops. This difference is the place where the condition is tested. The while tests the condition before executing any of the statements within the while loop. As against this, the do-while tests the condition after having executed the statements within the loop.

This means that do-while would execute its statements at least once, even if the condition fails for the first time. The while, on the other hand will not execute its statements if the condition fails for the first time.
The previous post of the blog deals with Requirements testing technique.

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

Recovery Testing Technique

Recovery is the ability to restart operations after the integrity of the application has been lost. The process normally involves reverting to a point where the integrity of the system is known, and then reprocessing transactions up until the point of failure.

The time required to recover operations is affected by the number of restart points, the volume of applications run on the computer center, the training and skill of the people conducting the recovery operation, and the tools available for recovery. The importance of recovery will vary from application to application.

Objectives :

Recovery testing is used to ensure that operations can be continued after a disaster. Recovery testing not only verifies the recovery process, but also the effectiveness of the component parts of that process. Specific objectives of recovery testing include:

1. Preserve adequate backup data
2. Store backup data in a secure location
3. Document recovery procedures
4. Assign and train recovery personnel
5. Develop recovery tools and make available

How to Use Recovery Testing ?

Recovery testing can be conducted in two modes. First, the procedures, methods, tools, and techniques can be assessed to evaluate whether they appear adequate; and second, after the system has been developed, a failure can be introduced into the system and the ability to recover tested. Both types of recovery testing are important. The implementation of the technique is different depending upon which type of recovery testing is being performed.

Evaluating the procedures and documentation is a process using primarily judgment and checklists. On the other hand, the actual recovery test may involve off-site facilities and alternate processing locations.

Testing the procedures is normally done by skilled systems analysts, professional testers, or management personnel. On the other hand, testing the actual recovery procedures should be performed by computer operators and other clerical personnel, who would be involved had there been an actual disaster instead of a test disaster.

A simulated disaster is usually performed on one aspect of the application system. For example, the test may be designed to determine whether people using the system can continue processing and recover computer operations after computer operations cease.

While several aspects of recovery need to be tested, it is better to test one segment at a time rather than induce multiple failures at a single time. When multiple failures are induced, and problems are encountered, it may be more difficult to pinpoint the cause of the problem than when only a single failure is induced.

When to Use Recovery Testing ?

Recovery testing should be performed whenever the user of the application states that the continuity of operation of the application is essential to the proper functioning of the user area. The user should estimate the potential loss associated with inability to recover operations over various time spans; for example, the inability to recover within five minutes, one hour, eight hours, and a week. The amount of the potential loss should both determine the amount of resource to be put into disaster planning as well as recovery testing.(128.4)

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 Teting Structural

Structural system testing is designed to verify that the developed system and programs work. The objective is to ensure that the product designed is structurally sound and will function correctly. It attempts to determine that the technology has been used properly and that when all the component parts are assembled they function as a cohesive unit.

The structural system testing techniques provide the facility for determining that the implemented configuration and its interrelationship of parts functions so that they can perform the intended tasks. The techniques are not designed to ensure that the application system is functionally correct, but rather, that it is structurally sound.

Click here to see different kinds of structural testing.

Stress Testing Techniques:

Stress testing is designed to determine if the system can function when subject to large volumes of work i.e., larger than would be normally expected. The areas that are stressed include input transactions, internal tables, disk space, output, communications, computer capacity, and interaction with people. If the application functions adequately under test, it can be assumed that it will function properly with normal volumes of work.

Objectives of stress testing :

The objective of stress testing is to simulate a production environment for the purpose of determining that:

1 • Normal or above-normal volumes of transactions can be processed through the transaction within the expected time frame.

2 • The application system is structurally able to process large volumes of data.

3 • System capacity, including communication lines, has sufficient resources available to meet expected turnaround times.

4 • People can perform their assigned tasks and maintain the desired turnaround time.

How to use this :

Stress testing should simulate as closely as possible the production environment. Online systems should be stress tested by having people enter transactions at a normal or above normal pace.


Batch systems can be stress tested with large input batches. Error conditions should be included in tested transactions. Transactions for use in stress testing can be obtained from one of the following three sources:

1. • Test data generators
2. • Test transactions created by the test group
3. • Transactions previously processed in the production environment

In stress testing, the system should be run as it would in the production environment. Operators should use standard documentation, and the people entering transactions or working with the system should be the clerical personnel that will work with the system after it goes into production. Online systems should be tested for an extended period of time, and batch systems tested using more than one batch of transactions.

Stress testing should be used when there is uncertainty regarding the amount of work the application system can handle without failing. Stress testing attempts to break the system by overloading it with a large volume of transactions. Stress testing is most common with online applications because it is difficult to simulate heavy volume transactions using the other testing techniques.

The disadvantage of stress testing is the amount of time it takes to prepare for the test, plus the amount of resources consumed during the actual execution of the test. These costs need to be weighed against the risk of not identifying volume-related failures until the application is placed into an operational mode.(126)

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

Softeare Testing V Model 11 steps

This post is in continuation with Software Testing V model.

Step 1: Assess Development Plan and Status

This first step is a prerequisite to building the Verification, Validation, and Testing (VV&T) Plan used to evaluate the implemented software solution. During this step, testers challenge the completeness and correctness of the development plan. Based on the extensiveness and completeness of the Project Plan the testers can estimate the amount of resources they will need to test the implemented software solution.

Step 2: Develop the Test Plan

Forming the plan for testing will follow the same pattern as any software planning process. The structure of all plans should be the same, but the content will vary based on the degree of risk the testers perceive as associated with the software being developed.

Step 3: Test Software Requirements

Incomplete, inaccurate, or inconsistent requirements lead to most software failures. The inability to get requirements right during the requirements gathering phase can also increase the cost of implementation significantly. Testers, through verification, must determine that the requirements are accurate, complete, and they do not conflict with one another.

Step 4: Test Software Design

This step tests both external and internal design primarily through verification techniques. The testers are concerned that the design will achieve the objectives of the requirements, as well as the design being effective and efficient on the designated hardware.

Step 5: Program (Build) Phase Testing

The method chosen to build the software from the internal design document will determine the type and extensiveness of tests needed. As the construction becomes more automated, less testing will be required during this phase. However, if software is constructed using the waterfall process, it is subject to error and should be verified. Experience has shown that it is significantly cheaper to identify defects during the construction phase, than through dynamic testing during the test execution step.

Step 6: Execute and Record Results

This involves the testing of code in a dynamic state. The approach, methods, and tools specified in the test plan will be used to validate that the executable code in fact meets the stated software requirements, and the structural specifications of the design.

Step 7: Acceptance Test

Acceptance testing enables users to evaluate the applicability and usability of the software in performing their day-to-day job functions. This tests what the user believes the software should perform, as opposed to what the documented requirements state the software should perform.

Step 8: Report Test Results

Test reporting is a continuous process. It may be both oral and written. It is important that defects and concerns be reported to the appropriate parties as early as possible, so that corrections can be made at the lowest possible cost.

Step 9: The Software Installation

Once the test team has confirmed that the software is ready for production use, the ability to execute that software in a production environment should be tested. This tests the interface to operating software, related software, and operating procedures.

Step 10: Test Software Changes

While this is shown as Step 10, in the context of performing maintenance after the software is implemented, the concept is also applicable to changes throughout the implementation process. Whenever requirements change, the test plan must change, and the impact of that change on software systems must be tested and evaluated.

Step 11: Evaluate Test Effectiveness

Testing improvement can best be achieved by evaluating the effectiveness of testing at the end of each software test assignment. While this assessment is primarily performed by the testers, it should involve the developers, users of the software, and quality assurance professionals if the function exists in the IT organization.

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 V Model Testing

Life cycle testing involves continuous testing of the system during the developmental process. At predetermined points, the results of the development process are inspected to determine the correctness of the implementation. These inspections identify defects at the earliest possible point.

Life cycle testing cannot occur until a formalized Systems Development Life Cycle (SDLC) has been incorporated. Life cycle testing is dependent upon the completion of predetermined deliverables at specified points in the developmental life cycle.

If information services personnel have the discretion to determine the order in which deliverables are developed, the life cycle test process becomes ineffective. This is due to variability in the process, which normally increases cost.

The life cycle testing concept can best be accomplished by the formation of a test team. The team is comprised of members of the project who may be both implementing and testing the system. When members of the team are testing the system, they must use a formal testing methodology to clearly distinguish the implementation mode from the test mode. They also must follow a structured methodology when approaching testing the same as when approaching system development.

Without a specific structured test methodology, the test team concept is ineffective because team members would follow the same methodology for testing as they used for developing the system. Experience shows people are blind to their own mistakes, so the effectiveness of the test team is dependent upon developing the system under one methodology and testing it under another.

The life cycle testing concept is illustrated in Figure below. This illustration shows that when the project starts both the system development process and system test process begins. The team that is developing the system begins the systems development process and the team that is conducting the system test begins planning the system test process. Both teams start at the same point using the same information.

The systems development team has the responsibility to define and document the requirements for developmental purposes. The test team will likewise use those same requirements, but for the purpose of testing the system. At appropriate points during the developmental process, the test team will test the developmental process in an attempt to uncover defects. The test team should use the structured testing techniques outlined in this book as a basis of evaluating the system development process deliverables.
During the system test process, an appropriate set of test transactions should be developed to be completed at the same time as the completion of the application system. When the application meets the acceptance criteria, it can be integrated into the operating environment.

During this process, the systems development team and the systems test team work closely together to ensure that the application is properly integrated into the production environment.

At that point, the teams again split to ensure the correctness of changes made during the maintenance phase. The maintenance team will make whatever changes and enhancements are necessary to the application system, and the test team will continue the test process to ensure that those enhancements are properly implemented and integrated into the production environment.

In the V-testing concept, project’s Do and Check procedures slowly converge from start to finish which indicates that as the Do team attempts to implement a solution, the Check team concurrently develops a process to minimize or eliminate the risk. If the two groups work closely together, the high level of risk at a project’s inception will decrease to an acceptable level by the project’s conclusion.(119)

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 Static and Dynamic

Static testing is performed using the software documentation. The code is not executing during static testing. Dynamic testing requires the code to be in an executable state to perform the tests.

Most verification techniques are static tests.

1 • Feasibility Reviews – Tests for this structural element would verify the logic flow of a unit of software.

2 • Requirements Reviews – These reviews verify software relationships; for example, in any particular system, the structural limits of how much load (e.g., transactions or number of concurrent users) a system can handle.

Most validation tests are dynamic tests. Examples of this are:

1 • Unit Testing : These tests verify that the system functions properly; for example, pressing a function key to complete an action.

2 • Integrated Testing : The system runs tasks that involve more than one application or database to verify that it performed the tasks accurately.

3 • System Testing : The tests simulate operation of the entire system and verify that it ran correctly.

4 • User Acceptance : This real-world test means the most to your business, and unfortunately, there’s no way to conduct it in isolation. Once your organization’s staff, customers, or vendors begin to interact with your system, they’ll verify that it functions properly for you.

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 Functional and Structural

Functional testing is sometimes called black-box testing because no knowledge of the internal logic of the system is used to develop test cases. For example, if a certain function key should produce a specific result when pressed, a functional test validates this expectation by pressing the function key and observing the result. When conducting functional tests, you’ll use validation techniques
almost exclusively.

Conversely, structural testing is sometimes called white-box testing because knowledge of the internal logic of the system is used to develop hypothetical test cases. Structural tests use verification predominantly. If a software development team creates a block of code that will allow a system to process information in a certain way, a test team would verify this structurally by reading the code, and given the system’s structure, see if the code would work reasonably. If they felt it could, they would plug the code into the system and run an application to structurally validate the code.

Each method has its pros and cons:

Functional Testing Advantages

1• Simulates actual system usage.
2• Makes no system structure assumptions

Functional Testing Disadvantages

1• Potential of missing logical errors in software
2• Possibility of redundant testing

Structural Testing Advantages

1• You can test the software’s structure logic
2• You test code that you wouldn’t use if you performed only functional testing

Structural Testing Disadvantages

1• Does not ensure that you’ve met user requirements
2• Its tests may not mimic real-world situations

A functional test case might be taken from the documentation description of how to perform a certain function, such as accepting bar code input. A structural test case might be taken from a technical documentation manual. To effectively test systems, you need to use both methods.

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 - verification and Validation of a process

Verification ensures that the system (software, hardware, documentation, and personnel) complies with an organization’s standards and processes, relying on review or non-executable methods. Validation physically ensures that the system operates according to plan by executing the system functions through a series of tests that can be observed and evaluated.

Verification requires several types of reviews, including requirements reviews, design reviews, code walk through's, code inspections, and test reviews. The system user should be involved in these reviews to find defects before they are built into the system. In the case of purchased systems, user input is needed to assure that the supplier makes the appropriate tests to eliminate defects.

Examples of system verifications :
The fallowing table illustrates the examples of verifications.

Validation is accomplished simply by executing a real-life function (if you wanted to check to see if your mechanic had fixed the starter on your car, you’d try to start the car). Examples of validation are shown in Table below.

Determining when to perform verification and validation relates to the development, acquisition, and maintenance of software. For software testing, this relationship is especially critical because:

1 • The corrections will probably be made using the same process for developing the software. If the software was developed internally using a waterfall methodology, that methodology will probably be followed in making the corrections; on the other hand, if the software was purchased or contracted, the supplier will likely make the correction. You’ll need to prepare tests for either eventuality.

2 • Testers can probably use the same test plans and test data prepared for testing the original software. If testers prepared effective test plans and created extensive test data, those plans and test data can probably be used in the testing effort, thereby reducing the time and cost of testing. (116.2)

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

Break Statement in C Programming

When break is encountered inside any loop, control automatically passes to the first statement after the loop. A break is usually associated with an if.

Example: Write a program to determine whether a number is prime or not. A prime number is one, which is divisible only by 1 or itself.

All we have to do to test whether a number is prime or not, is to divide it successively by all numbers from 2 to one less than itself. If remainder of any of these divisions is zero, the number is not a prime. If no division yields a zero then the number is a prime number.

Following program implements this logic.

main( )
{
int num, i ;
printf ( "Enter a number " ) ;
scanf ( "%d", &num ) ;
i = 2 ;
while ( i <= num - 1 ) { if ( num % i == 0 ) { printf ( "Not a prime number" ) ; break ; } i++ ; } if ( i == num ) printf ( "Prime number" ) ; } In this program the moment num % i turns out to be zero, (i.e. num is exactly divisible by i) the message “Not a prime number” is printed and the control breaks out of the while loop. There are two ways the control could have reached outside the while loop: 1 . It jumped out because the number proved to be not a prime. 2. The loop came to an end because the value of i became equal to num. When the loop terminates in the second case, it means that there was no number between 2 to num - 1 that could exactly divide num. That is, num is indeed a prime. If this is true, the program should print out the message “Prime number”. The keyword break, breaks the control only from the while in which it is placed. The following is the example to explain this point. main( ) { int i = 1 , j = 1 ; while ( i++ <= 100 ) { while ( j++ <= 200 ) { if ( j == 150 ) break ; else printf ( "%d %d\n", i, j ) ; } } } In this program when j equals 150, break takes the control outside the inner while only, since it is placed inside the inner while. The previous post of the blog deals with nested if statement of IF'S.

Learn complete course of C Programming here.

CONVERSION OF CONSTANTS IN C PROGRAM

PRIORITY OF AR THEMATIC OPERATIONS IN C

OPERATORS ASSOCIATIVITY IN C

IF STATEMENT

MULTIPLE STATEMENTS IN IF

IF AND ELSE

NESTED IF AND ELSE

BREAK

CONTINUE AND DO WHILE IN C LANGUAGE

SWITCH IN C PROGRAMMING

FUNCTIONS IN C PROGRAMMING

Functions and usage in C part two

Coding in C functions


OTHER PROGRAMMING COURSES:

Dot Net Complete Course Part one and two

ASP.NET part one and two

Programming with C and C Sharp

Interview Questions in dot net

asp.net part one part two

Software Testing Complete course part one two and Interview Questions

Nested IF ELSES in C Programming

We can use to write an entire if-else construct within either the body of the if statement or the body of an else statement. This is called ‘nesting’of ifs.

Note that the second if-else construct is nested in the first else statement. If the condition in the first if statement is false, then the condition in the second if statement is checked. If it is false as well, then the final else statement is executed.

You can see in the program how each time a if-else construct is nested within another if-else construct, it is also indented to add clarity to the program. Inculcate this habit of indentation, otherwise you would end up writing programs which nobody (you included) can understand easily at a later date.

In the sample program an if-else occurs within the else block of the first if statement. Similarly, in some other program an if-else may occur in the if block as well. There is no limit on how deeply the ifs and the elses can be nested.

Here is the sample code to execute the nested if else statements.

main( )

{

int i ;

printf ( "Enter either 1 or 2 " ) ;

scanf ( "%d", &i ) ;

if ( i == 1 )

printf ( "You would go to heaven !" ) ;

else

{

if ( i == 2 )

printf ( "Hell was created with you in mind" ) ;

else

printf ( "How about mother earth !" ) ;

}

}

Related Posts :

IF STATEMENT

MULTIPLE STATEMENTS IN IF

IF AND ELSE

NESTED IF AND ELSE

BREAK

CONTINUE AND DO WHILE IN C LANGUAGE

SWITCH IN C PROGRAMMING

FUNCTIONS IN C PROGRAMMING

Functions and usage in C part two

Coding in C functions

IF - ELSE Statements

The if statement by itself will execute a single statement, or a group of statements, when the expression following if evaluates to true. It does nothing when the expression evaluates to false.To execute one group of statements if the expression evaluates to true and another group of statements if the expression evaluates to false we use the else statement .

Example:

In a company an employee is paid as under:

salary and DA = 90% of basic salary. If his salary is either equal to or above Rs. 1500, then HRA = Rs. 500 and DA = 98% of basic salary. If the employee's salary is input through the keyboard write a program to find his gross salary.

main( )

{

float bs, gs, da, hra ;

printf ( "Enter basic salary " ) ;

scanf ( "%f", &bs ) ;

if ( bs <>

{

hra = bs * 10 / 100 ;

da = bs * 90 / 100 ;

}

else

{

hra = 500 ;

da = bs * 98 / 100 ;

}

gs = bs + hra + da ;

printf ( "gross salary = Rs. %f", gs ) ;

}

The flow of control is given as shown below.

Here are the few points to concentrate further.

1 . The group of statements after the if up to and not including the else is called an ‘if block’. Similarly, the statements after the else form the ‘else block’.

2 . Notice that the else is written exactly below the if. The statements in the if block and those in the else block have been indented to the right. This formatting convention is followed throughout the book to enable you to understand the working of the program better.

3 . Had there been only one statement to be executed in the if block and only one statement in the else block we could have dropped the pair of braces.

4 . As with the if statement, the default scope of else is also the statement immediately after the else. To override this default scope a pair of braces as shown in the above example must be used.
78.2

The previous post of the blog deals with Multiple Statements with in IF .

Related Post :

IF STATEMENT

MULTIPLE STATEMENTS IN IF

IF AND ELSE

NESTED IF AND ELSE

BREAK

CONTINUE AND DO WHILE IN C LANGUAGE

SWITCH IN C PROGRAMMING

FUNCTIONS IN C PROGRAMMING

Functions and usage in C part two

Coding in C functions