Quality Assurance - deep dive

QA definition is prevent mistakes and defects in manufactured products and avoiding problems when delivering products or services to the customers. It is an activity to ensure that an organization is providing the best possible product or service to the customers.

Quality means meeting the needs and expectations of customers with respect to functionality, design, stability, and the price of the product.

Assurance means a declaration on a product or service, that it will work well. It provides a guarantee that the product will work without any problems as per the expectations or requirements.

Quality Assurance Certifications - ISO 9000: was established in 1987. It helps the organization to ensure the quality to their customers and other stakeholders. An organization who wishes to be certified as ISO 9000 is audited based on their functions, products, services and their processes. The main objective is to review and verify whether the organization is following the process as expected and check whether existing processes need improvement.

ISO 9000 defines as "providing confidence that quality requirements will be fulfilled". This defect prevention in quality assurance, focuses on quality earlier in the process, differs from defect detection and rejection in quality control . This certification helps to: Increase the profit of the organization (Customers make this as qualifying criteria while selecting a software vendor), Improves Domestic and International trade, Reduces waste and increase the productivity of the employees, Provide Excellent customer satisfaction.

"Quality assurance" and "Quality control" The terms are used to refer to ways of ensuring the quality of a service or product. The term "control", is used to describe the fifth phase of the Define, Measure, Analyze, Improve, Control (DMAIC) model. DMAIC is a data-driven quality strategy used to improve processes.

Quality assurance comprises administrative and procedural activities implemented in a quality system so that requirements and goals for a product, service or activity will be fulfilled. It is the systematic measurement, comparison with a standard, monitoring of processes and an associated feedback loop that confers error prevention. This can be contrasted with quality control, which is focused on process output.

A Test Plan is a document describing software testing scope and activities. It is the basis for formally testing any software/product in a project. The document describes the scope, approach, resources and schedule of intended test activities. It identifies, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process.

Test Plan Types

• Master Test Plan: A high-level test plan for a project/product that unifies all other test plans.
• Testing Level Specific Test Plans: Plans for each level of testing.
• Unit Test Plan: Describes the test strategy, objectives, schedule, estimation.
• Integration Test Plan - focus on functionality.
• System Test Plan - Details the complete approach to the validation of the system under test. It generally contains glossary terms, the objectives of the System Test, the testing approach, risks, deliverables, defect management, and much more.
• Acceptance Test Plan - (ATP) describes the acceptance testing process, such as the features to be tested, pass/fail criteria, approach to testing, checklists, roles and responsibilities, resource requirements and schedules.
• Testing Type Specific Test Plans - Plans for major types of testing like Performance Test Plan and Security Test Plan.

Test Plan Template

The format and content of a software test plan vary depending on the processes, standards, and test management tools being implemented. Nevertheless, the following format, which is based on IEEE standard for software test documentation, provides a summary of what a test plan can/should contain.

Test Plan Identifier: Provide a unique identifier for the document. (Adhere to the Configuration Management System if you have one.)

Introduction: Provide an overview of the test plan, Specify the goals/objectives, Specify any constraints.

References: List the related documents, with links to them if available, including the following: Project Plan, Configuration Management Plan

Test Items: List the test items (software/products) and their versions.

Features to be Tested: List the features of the software/product to be tested, Provide references to the Requirements and/or Design specifications of the features to be tested

Features Not to Be Tested: List the features of the software/product which will not be tested, Specify the reasons these features won’t be tested.

Approach: Mention the overall approach to testing, Specify the testing levels [if it’s a Master Test Plan], the testing types, and the testing methods [Manual/Automated; White Box/Black Box/Gray Box]

Item Pass/Fail Criteria: Specify the criteria that will be used to determine whether each test item (software/product) has passed or failed testing.

Suspension Criteria and Resumption Requirements: Specify criteria to be used to suspend the testing activity, Specify testing activities which must be redone when testing is resumed.

Test Deliverables:

• List test deliverables, and links to them if available, including the following:
• Test Plan (this document itself)
• Test Cases - In software engineering, a test case is a specification of the inputs, execution conditions, testing procedure, and expected results that define a single test to be executed to achieve a particular software testing objective, such as to exercise a particular program path or to verify compliance with a specific requirement. A test case can be built to produce the desired coverage of the software being tested.
• Test Scripts - a set of instructions that will be performed on the system under test to test that the system functions as expected. 
• Defect Reports - also known as Bug Report, is a document that identifies and describes a defect detected by a tester. The purpose of a defect report is to state the problem as clearly as possible so that developers can replicate the defect easily and fix it.
• Test Reports -  an organized summary of testing objectives, activities, and results. It is created and used to help stakeholders (product manager, analysts, testing team, and developers) understand product quality and decide whether a product, feature, or a defect resolution is on track for release.

Test Environment: Specify the properties of test environment: hardware, software, network etc, List any testing or related tools.

Estimate: Provide a summary of test estimates (cost or effort) and/or provide a link to the detailed estimation.

Schedule: Provide a summary of the schedule, specifying key test milestones, and/or provide a link to the detailed schedule.

Staffing and Training Needs: Specify staffing needs by role and required skills, Identify training that is necessary to provide those skills, if not already acquired.

Responsibilities: List the responsibilities of each team/role/individual.

Risks: List the risks that have been identified, Specify the mitigation plan and the contingency plan for each risk.

Assumptions and Dependencies: List the assumptions that have been made during the preparation of this plan, List the dependencies.

Approvals: Specify the names and roles of all persons who must approve the plan, Provide space for signatures and dates. (If the document is to be printed.)

Test Cases Guidance

• Writing Good Test Cases
• As far as possible, write test cases in such a way that you test only one thing at a time. Do not overlap or complicate test cases. Attempt to make your test cases ‘atomic’.
• Ensure that all positive scenarios AND negative scenarios are covered.
• Write in simple and easy-to-understand language.
• Use active voice instead of passive voice: Do this, do that.
• Use exact and consistent names (of forms, fields, etc).

Characteristics of a good test case:

• Accurate: Exacts the purpose.
• Economical: No unnecessary steps or words.
• Traceable: Capable of being traced to requirements.
• Repeatable: Can be used to perform the test over and over.
• Reusable: Can be reused if necessary.

Test Plan Guidelines

• Make the plan concise. If you think you do not need a section that has been mentioned in the template above, go ahead and delete that section in your test plan.
• Be specific. For example, when you specify an operating system as a property of a test environment, mention the OS Edition/Version as well, not just the OS Name.
• Make use of lists and tables wherever possible. Avoid lengthy paragraphs.
• Have the test plan reviewed a number of times prior to baselining it or sending it for approval. The quality of your test plan speaks volumes about the quality of the testing you or your team is going to perform.
• Update the plan.