Programming Portal: TEST PROCESS

Showing posts with label TEST PROCESS. Show all posts

Software Testing Process Overview

The testing and development processes are in a feedback loop. The testing process feeds identified failures back into the development process.

Failure reports provide a set of symptoms that a developer uses to identify the exact location of a fault or error. The development process feeds new and revised designs and implementations into the testing process.

Testing of development products will help identify defective test cases when testers determine that "failures" result from problems with test cases themselves or the drivers that execute them, and not the software under test.

The form and content of development products affect the testing process. When developers select methods and tools, they establish constraints on the testing process. The testing perspective must be considered, preferably by the presence of professional testers, when development methods and tools are selected.

The form and quality of a requirements specification also affects the process. Product requirements comprise the source of test cases in system and acceptance testing. System testers should participate in the gathering and validation of the requirements in order to have a sufficient understanding of them to assess risks and testability.

Three-step approach for each type of testing performed on a project.

Analysis:The product to be tested is examined to identify any special features that must receive particular attention and to determine the test cases that should be constructed. We will present a number of analysis techniques.
Construction: In this phase the artifacts that are needed for testing are created. The test cases identified during analysis are translated into programming languages and scripting languages, or they are entered in a tool-specific language.
Execution and Evaluation: This is the most visible and often the only recognized part of the test effort; however, it is also typically the quickest part of the test effort. The test cases that were identified during analysis and then constructed are executed. The results are examined to determine whether the software passed the test suite or failed it.

Test Cases and Test Suites

The basic component of testing is a test case. Test case is a pair (input, expected result), in which input is a description of an input to the software under test and expected result is a description of the output that the software should exhibit for the associated input.

Inputs and expected results are not necessarily simple data values, such as strings or integer values, but they can be complex.

Inputs often incorporate system state information as well as user commands and data values to be processed. Expected result includes not only perceivable things, such as printed reports, audible sounds, or changes in a display screen, but changes to the software system itself.

A test case execution is a running of the software that provides the inputs specified in the test case and observes the results and compares them to those specified by the test case. If the actual result varies from the expected result, then a failure has been detected and we say the software under test "fails the test case."

If the actual result is the expected result for a test case, then we say the software "passes the test case."

Test cases are organized into a test suite. Most test suites have some sort of organization based on the kinds of test cases. If software passes all the test cases in a test suite, then we say that the software "passes the test suite."

Software testing other interesting topics:

SOFTWARE TESTING AND EFFECTING FACTORS
SOFTWARE QUALITY ASSURANCE AND CONTROL

SOFTWARE QUALITY AND COST ASPECT

STABLE PROCESS OF SOFTWARE TESTING

STABLE PROCESS OF SOFTWARE TESTING PART TWO

DEFECTS IN SOFTWARE TESTING

REDUCTION OF DEFECTS IN SOFTWARE TESTING

SOFTWARE TESTING AND EFFECTING FACTORS

SCOPE OF SOFTWARE TESTING

TESTING LIFE CYCLE PART ONE

TESTING LIFE CYCLE PART TWO

TESTING LIFE CYCLE PART THREE

SOFTWARE TESTING AND CONSTRAINTS WITH IN IT

How do we test a software ?

The following are the different techniques of software testing on the open basis.

Functional (black-box) methods can be applied to any unit, build, or system, since they assume no knowledge of how either was constructed or what it contains. Such methods require a sufficient and unambiguous specification if they are to be effective. (Devising black-box tests for some code from its specification at the time the specification is written is a useful verification of the specification; if it can’t be done, the specification isn’t good enough.) This is what you will normally do for a system test.

Structural (white-box) methods can also be used on any unit or build, but are cheapest to devise when used on structured programs, e.g., well-written programs in a structured language. These are usually applied to unit tests.

Dynamic analysis techniques are derivative methods which assume that a particular technique such as condition tables, finite state machines, object-orientation, or functional programming, has been used to develop the software; we use knowledge of that technique to determine the test cases, so these have very special areas of application. These can be applied at both system test and unit test times. These are usually applied to unit tests.

Static analysis techniques can best be used before integration, and can also point to the need for more-rigorous unit testing. These require using tools to analyze the source code .These are usually applied to unit tests.

Symbolic evaluation carried out by an automated symbolic evaluation tool places no special requirement on the unit, except of course that it be in the language evaluated by the tool. This involves “dry-running” the code, and recording the output values of variables algebraically rather than using specific values for input variables . This is usually applied to unit tests.

Other Programming Courses :

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

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:

• Test data generators
• Test transactions created by the test group
• 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 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 - 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

Test Process

A process can be defined as a set of activities that represent the way work is performed.

The outcome from a process is usually a product or service. Both software development and software testing are processes.

............................................................

There are two ways to visually portray a process. One is the Plan Do Check Act (PDCA) cycle. The other is a workbench. The PDCA cycle is a conceptual view of a process, while the workbench is a more practical illustration of a process.

The PDCA View of a Process:

It has four components. They are :

P – Plan - Devise Your Plan

Define your objective and determine the conditions and methods required to achieve your objective. Describe clearly the goals and policies needed to achieve the objective at this stage. Express a specific objective numerically. Determine the procedures and conditions for the means and methods you will use to achieve the objective.

D – Do (or Execute) the Plan

Create the conditions and perform the necessary teaching and training to execute the plan. Make sure everyone thoroughly understands the objectives and the plan. Teach workers the procedures and skills they need to fulfill the plan and thoroughly understand the job. Then perform the work according to these procedures.
C – Check the Results

Check to determine whether work is progressing according to the plan and whether the expected results are obtained. Check for performance of the set procedures, changes in conditions, or abnormalities that may appear. As often as possible, compare the results of the work with the objectives.

A – Act - Take the Necessary Action

If your checkup reveals that the work is not being performed according to plan or that results are not as anticipated, devise measures for appropriate action. If a check detects an abnormality that is, if the actual value differs from the target value – search for the cause of the abnormality and eliminate the cause. This will prevent the recurrence of the defect. Usually you will need to retrain workers and revise procedures to eliminate the cause of a defect.

The Workbench View of a Process

A process can be viewed as one or more workbenches. Each workbench is built on the following two components:

1• Objective : States why the process exists, or its purpose.

Example: A JAD session is conducted to uncover the majority of customer requirements early and efficiently, and to ensure that all involved parties interpret these requirements consistently.

2• People Skills : The roles, responsibilities, and associated skill sets needed to execute a process. Major roles include suppliers, owners, and customers.

Each workbench has the following components:

1 • Inputs :– The entrance criteria or deliverables needed to perform testing.

2 • Procedures : Describe how work must be done; how methods, tools, techniques, and people are applied to perform a process. There are Do procedures and Check procedures. Procedures indicate the “best way” to meet standards.

Example:

1. Scribe: Use the XYZ tool to enter the requirements. Generate a list of any open issues using the XX template.

2. Leader: Walk through the requirements, paraphrasing each item. Address each open issue when its REF column contains the item being covered.

The previous post is regarding software independentdent testing.
111.2
ShareThis

To Do Next: 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 .

VALIDATION TESTING

At the culmination of integration testing, software is completely assembled as a package, interfacing errors have been uncovered and corrected, and a final series of software tests—validation testing—may begin.

Validation can be defined in many ways, but a simple (albeit harsh) definition is that validation succeeds when software functions in a manner that can be reasonably expected by the customer. At this point a battle-hardened software developer might protest: “Who or what is the arbiter of reasonable expectations?”

Reasonable expectations are defined in the Software Requirements Specification— a document that describes all user-visible attributes of the software. The specification contains a section called Validation Criteria. Information contained in that section forms the basis for a validation testing approach.

Validation Test Criteria:

Software validation is achieved through a series of black-box tests that demonstrate conformity with requirements. A test plan outlines the classes of tests to be conducted and a test procedure defines specific test cases that will be used to demonstrate conformity with requirements.

Both the plan and procedure are designed to ensure that all functional requirements are satisfied, all behavioral characteristics are achieved, all performance requirements are attained, documentation is correct, and human-engineered and other requirements are met (e.g., transportability, compatibility, error recovery, maintainability).

After each validation test case has been conducted, one of two possible conditions exist: (1) The function or performance characteristics conform to specification and are accepted or (2) a deviation from specification is uncovered and a deficiency list is created. Deviation or error discovered at this stage in a project can rarely be corrected prior to scheduled delivery. It is often necessary to negotiate with the customer to establish a method for resolving deficiencies.

Configuration Review:

An important element of the validation process is a configuration review. The intent of the review is to ensure that all elements of the software configuration have been properly developed, are cataloged, and have the necessary detail to bolster the support phase of the software life cycle. The configuration review, sometimes called an audit, has been discussed in more detail in Chapter 9.

Alpha and Beta Testing:

It is virtually impossible for a software developer to foresee how the customer will really use a program. Instructions for use may be misinterpreted; strange combinations of data may be regularly used; output that seemed clear to the tester may be unintelligible to a user in the field.

When custom software is built for one customer, a series of acceptance tests are conducted to enable the customer to validate all requirements. Conducted by the end-user rather than software engineers, an acceptance test can range from an informal “test drive” to a planned and systematically executed series of tests. In fact, acceptance testing can be conducted over a period of weeks or months, thereby uncovering cumulative errors that might degrade the system over time.

If software is developed as a product to be used by many customers, it is impractical to perform formal acceptance tests with each one. Most software product builders use a process called alpha and beta testing to uncover errors that only the end-user seems able to find.

The alpha test is conducted at the developer’s site by a customer. The software is used in a natural setting with the developer “looking over the shoulder” of the user and recording errors and usage problems. Alpha tests are conducted in a controlled environment.

The beta test is conducted at one or more customer sites by the end-user of the software. Unlike alpha testing, the developer is generally not present. Therefore, the beta test is a “live” application of the software in an environment that cannot be controlled by the developer. The customer records all problems (real or imagined) that are encountered during beta testing and reports these to the developer at regular intervals. As a result of problems reported during beta tests, software engineers make modifications and then prepare for release of the software product to the entire customer base.

RELATED POST

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

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

Traceability Matrix in software testing

Requirements tracing is the process of documenting the links between the user requirements for the system you’re building and the work products developed to implement and verify those requirements. These work products include Software requirements, design specifications, Software code, test plans and other artifacts of the systems development process. Requirements tracing helps the project team to understand which parts of the design and code implement the user’s requirements, and which tests are necessary to verify that the user’s requirements have been implemented correctly.

In the diagram, based on the requirements the design is carried out and based on the design, the codes are developed. Finally, based on these the tests are created. At any point of time , there is always the provision for checking which test case was developed for which design and for which requirement that design was carried out. Such a kind of Traceability in the form of a matrix is the Traceability Matrix.

Disadvantages of not using Traceability Matrix:

What happens if the Traceability factor is not considered while developing the software?

The system that is built may not have the necessary functionality to meet the customers and users needs and expectations
If there are modifications in the design specifications, there is no means of tracking the changes
If there is no mapping of test cases to the requirements, it may result in missing a major defect in the system
The completed system may have “Extra” functionality that may have not been specified in the design specification , resulting in wastage of manpower, time and effort.
If the code component that constitutes the customer’s high priority requirements is not known, then the areas that need to be worked first may not be known thereby decreasing the chances of shipping a useful product on schedule
A seemingly simple request might involve changes to several parts of the system and if proper Traceability process is not followed, the evaluation of the work that may be needed to satisfy the request may not be correctly evaluated

Where can a Traceability Matrix be used?:

Is the Traceability Matrix applicable only for big projects?

The Traceability Matrix is an essential part of any Software development process, and hence irrespective of the size of the project, whenever there is a requirement to build a Software this concept comes into focus.

The biggest advantage of Traceability Matrix is backward and forward traceability. (i.e) At any point of time in the development life cycle the status of the project and the modules that have been tested could be easily determined thereby reducing the possibility of speculations about the status of the project.

Test coverage:

Some of the persistent questions that get repeated often with regard to Testing are, “Did we test that the account numbers are valid?” , “ Is the pin number field accepting null values?” . These are very difficult question to answer, but with the help of Traceability Matrix, it is possible to relate all possible functional requirements to a test case. The Matrix indicates which test case does that test.

Traceability Matrix in testing:

Where exactly does the Traceability Matrix gets involved in the broader picture of Testing?

The Traceability Matrix is created even before any test cases are written, because it is a complete list indicating what has to be tested. Sometimes there is one test case for each requirement or several requirements can be validated by one test scenario. This purely depends on the kind of application that is available for testing.

Developing a Traceability Matrix:

How is the Traceability Matrix developed?In the design document, if there is a Design description A, which can be traced back to the Requirement Specification A, implying that the design A takes care of Requirement A. Similarly in the test plan, Test Case A takes care of testing the Design A, which in turn takes care of Requirement A and so on.

There has to be references from Design document back to Requirement document, from Test plan back to Design document and so on. Usually Unit test cases will have Traceability to Design Specification and System test cases /Acceptance Test cases will have Traceability to Requirement Specification. This helps to ensure that no requirement is left uncovered (either un-designed / un-tested).

Requirements Traceability enhances project control and quality. It is a process of documenting the links between user requirements for a system and the work products developed to implement and verify those requirements. It is a technique to support an objective of requirements management, to make certain that the application will meet end-users needs.

Creating a Traceability Matrix:

Traceability Matrix gives a cross-reference between a test case document and the Functional/design specification document.This document helps to identify, if the Test case document contains tests for all the identified unit functions from the design specification. At any point of time, the program corresponding to a particular requirement could be easily traced back. The test cases corresponding to the requirements are available in the Test Case column.

Code Inspections in software testing

An inspection team usually consists of four people. One of the four people plays the role of a moderator. The moderator is expected to be a competent programmer, but he/she is not the author of the program and need not be acquainted with the details of the program. The duties of the moderator include:

Distributing materials for scheduling inspections
Leading the session,
Recording all errors found, and
Ensuring that the errors are subsequently corrected

Hence the moderator may be called as quality-control engineer. The remaining members usually consist of the program’s designer and a test specialist.

The general procedure is that the moderator distributes the program’s listing and design specification to the other participants well in advance of the inspection session. The participants are expected to familiarize themselves with the material prior to the session. During inspection session, two main activities occur:

The programmer is requested to narrate, statement by statement, the logic of the program. During the discourse, questions are raised and pursued to determine if errors exist. Experience has shown that many of the errors discovered are actually found by the programmer, rather than the other team members, during the narration. In other words, the simple act of reading aloud

one’s program to an audience seems to be a remarkably effective error-detection technique.

The program is analyzed with respect to a checklist of historically common programming errors (such a checklist is discussed in the next section).

It is moderators responsibility to ensure the smooth conduction of the proceedings and that the participants focus their attention on finding errors, not correcting them.

After session, the programmer is given a list of the errors found. The list of errors is also analyzed, categorized, ad used to refine the error checklist to improve the effectiveness of future inspections.

The main benefits of this method are;

Identifying early errors,
The programmers usually receive feedback concerning his or her programming style and choice of algorithms and programming techniques.
Other participants are also gain in similar way by being exposed to another programmer’s errors and programming style.

The inspection process is a way of identifying early the most error-prone sections of the program, thus allowing one to focus more attention on these sections during the computer based testing processes.

RELATED POST

TEST CASE DESIGN

TEST CASE DESIGN TWO

DESIGN OF TEST CASES PART THREE

TEST CASE DESIGN PART THREE

TEST CASE DESIGN PART FOUR

TEST CASE DESIGN PART FIVE

TEST CASE DESIGN PART SIX

TEST CASE DESIGN PART SEVEN

TEST CASE DESIGN PART EIGHT

TEST CASE DESIGN PART NINE

REVIEWS AND APPROVAL OF TEST CASES

WRITING SOFTWARE TEST CASES PART ONE

WRITING SOFTWARE TEST CASES PART TWO

WRITING SOFTWARE TEST CASES PART THREE

WRITING SOFTWARE TEST CASES PART FOUR

Formal Technical Reviews

FTR is a SQA activity that is performed by software engineers.

Objectives of the FTR are

To uncover errors in function, logic, are implementations for any representation of the software.
To verify that software under review meets its requirements.
To ensure that software has been represented according to predefined standards
To achieve software that is developed in an uniform manner
To make projects more manageable

In addition, the FTR serves as a training ground, enabling junior engineers to observe different approaches to software analysis, design, and implementation. The FTR also serves to promote backup and continuity because numbers of people become familiar with parts of the software that they may not have other wise seen.

The FTR is actually a class of reviews that include walkthrough inspection and round robin reviews, and other small group technical assessments of software. Each FTR is conducted as meeting and will be successful only if it is properly planned, controlled and attended. In the paragraph that follows, guidelines similar to those for a walk through are presented as a representative Formal technical review.

The Review Meeting

The Focus of the FTR is on a work product - a component of the software.

At the end of review all attendees of the FTR must decide

1. Whether to accept the work product without further modification.

2. Reject the work product due to serve errors (Once corrected another review must be performed)

1. Accept the work product provisionally (minor errors have been encountered and must be corrected but no additional review will be required).

The decision made, All FTR attendees complete a sign-off indication their participation in the review and their concurrence with the review team findings.

Review reporting and record keeping

The review summary report is typically is a single page form. It becomes part of the project historical record and may be distributed to the project leader and other interested parties. The review issue lists serves two purposes.

1. To identify problem areas within the product

2. To serve as an action item. Checklist that guides the producer as corrections are made. An issues list is normally attached to the summary report.

It is important to establish a follow up procedure to ensure that item on the issues list have been properly corrected. Unless this is done, it is possible that issued raised can "fall between the cracks". One approach is to assign responsibility for follow up for the review leader. A more formal approach as signs responsibility independent to SQA group.

Review Guidelines

The following represents a minimum set of guidelines for formal technical reviews

Review the product, Not the producer
Set an agenda and maintain it
Limit debate and rebuttal
Enunciate problem areas but don't attempt to solve every problem noted
Take return notes
Limit the number of participants and insist upon the advanced preparation
Develop a check list each work product that is likely to be reviewed
Allocate resources and time schedule for FTRs.
Conducts meaningful training for all reviewers
Review your early reviews

TEST CASE DESIGN

TEST CASE DESIGN TWO

DESIGN OF TEST CASES PART THREE

TEST CASE DESIGN PART THREE

TEST CASE DESIGN PART FOUR

TEST CASE DESIGN PART FIVE

TEST CASE DESIGN PART SIX

TEST CASE DESIGN PART SEVEN

TEST CASE DESIGN PART EIGHT

TEST CASE DESIGN PART NINE

REVIEWS AND APPROVAL OF TEST CASES

WRITING SOFTWARE TEST CASES PART ONE

WRITING SOFTWARE TEST CASES PART TWO

WRITING SOFTWARE TEST CASES PART THREE

WRITING SOFTWARE TEST CASES PART FOUR

The Process of software testing part three

What's a 'test plan'?

A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product.

The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it. The following are some of the items that might be included in a test plan, depending on the particular project:

Title
Identification of software including version/release numbers
Revision history of document including authors, dates, approvals
Table of Contents
Purpose of document, intended audience
Objective of testing effort
Software product overview
Relevant related document list, such as requirements, design documents, other test plans, etc.
Relevant standards or legal requirements
Traceability requirements
Relevant naming conventions and identifier conventions
Overall software project organization and personnel/contact-info/responsibilties
Test organization and personnel/contact-info/responsibilities
Assumptions and dependencies
Project risk analysis
Testing priorities and focus
Scope and limitations of testing
Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable
Outline of data input equivalence classes, boundary value analysis, error classes
Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems

Test environment setup and configuration issues

Test data setup requirements
Database setup requirements
Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs
Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs
Test automation - justification and overview
Test tools to be used, including versions, patches, etc.

Test script/test code maintenance processes and version control

Problem tracking and resolution - tools and processes
Project test metrics to be used
Reporting requirements and testing deliverables
Software entrance and exit criteria
Initial sanity testing period and criteria
Test suspension and restart criteria
Personnel allocation
Personnel pre-training needs
Test site/location
Outside test organizations to be utilized and their purpose, responsibilties, deliverables, contact persons, and coordination issues
Relevant proprietary, classified, security, and licensing issues.
Open issues

SOFTWARE QUALITY ASSURANCE AND CONTROL

SOFTWARE QUALITY AND COST ASPECT

STABLE PROCESS OF SOFTWARE TESTING

STABLE PROCESS OF SOFTWARE TESTING PART TWO

DEFECTS IN SOFTWARE TESTING

REDUCTION OF DEFECTS IN SOFTWARE TESTING

SOFTWARE TESTING AND EFFECTING FACTORS

SCOPE OF SOFTWARE TESTING

TESTING LIFE CYCLE PART ONE

TESTING LIFE CYCLE PART TWO

TESTING LIFE CYCLE PART THREE

SOFTWARE TESTING AND CONSTRAINTS WITH IN IT

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

Top Tabs

The Review Meeting

Review reporting and record keeping

Review Guidelines

What's a 'test plan'?