Software Testing

Software Testing
Software Testing is the process of evaluating the features of software and finding the differences between existing and expected requirements.In today’s scenario following are some of the major problems:
Some of the new development methodologies are developed through trial. Generally, these methods typically don't produce specifications for the tester to test against. So, testers have to find bugs by hit and trial.In today’s tough competition in the market, software development has been driven by entrepreneurial pressures, tight schedule, and constantly evolving product definition. For these reasons, sometimes, it is difficult to convince management that testing is necessary or worthwhile.There are only few trained testers using formal methods and metrics. Most of the software testers out there are just passing through testing on their way to some other career. So, overall the testing effort is not giving the high-quality results that may help demonstrate how the testing effort improves the quality of the product.In the past few years, the quality of standards of software development is improved drastically. It has a profound effect on the quality of the final product. It has also removed the need for extensive low-level testing in these areas, so the demand for white box tester is decreased.Also, please remember that “A test effort that just finds bugs is not enough.” As a software tester, you must be able to demonstrate that your effort is adding value to the quality of the software. Measure that value in order to demonstrate the value added.Management would also take interest in knowing that which parts of the software development life cycle is contributing in achieving the product quality. So, add the value as you can.

Software Testing Process
1. Understand of business logic and analysis of requirements: In this phase consider the following:

Are the definitions and descriptions of the required functionalities precise?Is there clear delineation between the system and its environment?Can the requirements be realized in practice?Can the requirements be tested effectively?

2. Test Planning: During this phase Test Strategy is defined and Test Bed is created. The plan should identify:-
Which aspects of the system should be tested.The methods, techniques and tools to be used.Personnel responsible for the testing.Manual and Automation TestingDefect Managment and Risk Managment etc.

3. Test Environment Setup: A different testing server is prepared where the application will be tested. It is an independent testing environment.

4. Test Design: Identify the test scenarios and prepare the test cases / scripts. Selection of test data is also done in this phase. If required, test designing is done with some automated tools like QTP or LoadRunner or with some other software testing tool. Designing framework, scripting, script integration, Review and approval will be undertaken in this phase.

5. Test Execution: Testers execute the test cases and report any errors found to the development team.

6. Defect Tracking: Raised defects are tracked using some tools like Test Director or Bug Host etc.

7. Test Reports: As soon as testing is completed, Test Lead or Manager generate metrics and make final reports for the whole testing effort.

Software Testing Principles
-A necessary part of a test case is a definition of the expected output or result.
- A programmer should avoid attempting to test his or her own program.
- A programming organization should not test its own programs.
- Thoroughly inspect the results of each test.
- Test cases must be written for input conditions that are invalid and unexpected, as well as for those that are valid and expected.
- Examining a program to see if it does not do what it is supposed to do is only half the battle; the other half is seeing whether the program does what it is not supposed to do.
- Avoid throwaway test cases unless the program is truly a throwaway program.
- Do not plan a testing effort under the tacit assumption that no errors will be found.
- The probability of the existence of more errors in a section of a program is proportional to the number of errors already found in that section.
- Software Testing is an extremely creative and intellectually challenging task.

Validation vs Verification, Reviews, Inspections

Validation: The process of evaluating software at the end of the software development process to ensure compliance with software requirements. It is actual testing of the application.
1. Am I building the right product.
2. Determining if the system complies with the requirements and performs functions for which it is intended and meets the organization’s goals and user needs. It is traditional and is performed at the end of the project.
3. Am I accessing the right data (in terms of the data required to satisfy the requirement).
4. High level activity.
5. Performed after a work product is produced against established criteria ensuring that the product integrates correctly into the environment.
6. Determination of correctness of the final software product by a development project with respect to the user needs and requirements..

Verification: The process of determining whether of not the products of a given phase of the software development cycle meet the implementation steps and can be traced to the incoming objectives established during the previous phase.
Verification process helps in detecting defects early, and preventing their leakage downstream. Thus, the higher cost of later detection and rework is eliminated. It includes:
1. Am I building the product right.
2. The review of interim work steps and interim deliverables during a project to ensure they are acceptable. To determine if the system is consistent, adheres to standards, uses reliable techniques and prudent practices, and performs the selected functions in the correct manner.
3. Am I accessing the data right (in the right place; in the right way).
4. Low level activity.
5. Performed during development on key artifacts, like walkthroughs, reviews and inspections, mentor feedback, training, checklists and standards.
6. Demonstration of consistency, completeness, and correctness of the software at each stage and between each stage of the development life cycle.
Review: A process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. The main goal of reviews is to find defects. Reviews are a good compliment to testing to help assure quality. A few purposes’ of SQA reviews can be as follows:
Assure the quality of deliverable’s before the project moves to the next stage. Once a deliverable has been reviewed, revised as required, and approved, it can be used as a basis for the next stage in the life cycle.
Various types of reviews:
Management Reviews: Management reviews are performed by those directly responsible for the system in order to monitor progress, determine status of plans and schedules, confirm requirements and their system allocation. Therefore the main objectives of Management Reviews can be categorized as follows:
- Validate from a management perspective that the project is making progress according to the project plan.
- Ensure that deliverables are ready for management approvals.
- Resolve issues that require management’s attention.
- Identify any project bottlenecks.
- Keeping project in Control.
Requirement Review: A process or meeting during which the requirements for a system, hardware item, or software item are presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include system requirements review, software requirements review. Product management leads Requirement Review. Members from every affected department participates in the review.
Input Criteria: Software requirement specification is the essential document for the review. A checklist can be used for the review.
Exit Criteria: Exit criteria include the filled & completed checklist with the reviewers’ comments & suggestions and the re-verification whether they are incorporated in the documents.
Design Review: A process or meeting during which a system, hardware, or software design is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include critical design review, preliminary design review, and system design review.
Inspection: A static analysis technique that relies on visual examination of development products to detect errors, violations of development standards, and other problems. Types include code inspection; design inspection, Architectural inspections, Test ware inspections etc. The participants in Inspections assume one or more of the following roles:
- Inspection leader- Recorder- Reader- Author- Inspector
All participants in the review are inspectors. The author shall not act as inspection leader and should not act as reader or recorder. Other roles may be shared among the team members. Individual participants may act in more than one role.
Individuals holding management positions over any member of the inspection team shall not participate in the inspection.
Input to the inspection shall include the following:
- A statement of objectives for the inspection- The software product to be inspected- Documented inspection procedure- Inspection reporting forms- Current anomalies or issues list
Input to the inspection may also include the following:
- Inspection checklists: Any regulations, standards, guidelines, plans, and procedures against which the software product is to be inspected.
- Hardware product specifications
- Hardware performance data
- Anomaly categories
The individuals may make additional reference material available responsible for the software product when requested by the inspection leader.
The purpose of the exit criteria is to bring an unambiguous closure to the inspection meeting. The exit decision shall determine if the software product meets the inspection exit criteria and shall prescribe any appropriate rework and verification. Specifically, the inspection team shall identify the software product disposition as one of the following:
Accept with no or minor rework: The software product is accepted as is or with only minor rework. (For example, that would require no further verification).
Accept with rework verification: The software product is to be accepted after the inspection leader or a designated member of the inspection team (other than the author) verifies rework.
Re-inspect: Schedule a re-inspection to verify rework. At a minimum, a re-inspection shall examine the software product areas changed to resolve anomalies identified in the last inspection, as well as side effects of those changes.