Quality Assurance Basics to Advance Points

TABLE OF CONTENTS

PHASE 1............................................................................................ 3

Software Development Life Cycle..................................................... 3

1.1 Introduction.......................................................................................................... 3

1.2 SDLC................................................................................................................... 3

1.3 SDLC Models...................................................................................................... 4

PHASE 2............................................................................................ 9

Software Testing Life Cycle.............................................................. 9

2.1 STLC.................................................................................................................... 9

2.2 Phases of STLC.................................................................................................... 9

2.3 SDLC vs. STLC................................................................................................. 10

PHASE 3.......................................................................................... 11

Bug Life Cycle................................................................................. 11

3.1 Bug..................................................................................................................... 11

3.2Bug Life Cycle.................................................................................................... 11

QA Basics......................................................................................... 13

Bug Summary................................................................................. 14

Types of Manual Testing................................................................ 15

Gap Analysis.................................................................................... 16

Test Plan.......................................................................................... 17

Test Cases......................................................................................... 19

Software Configuration Management............................................ 24

Testing Scenario.............................................................................. 24

Impact Analysis Document............................................................. 26

Integration Test cases...................................................................... 28

Functional Test cases....................................................................... 30

PHASE 1

                                                          Software Development Life Cycle

1.1 Introduction

SDLC describes all the tasks required for developing and maintaining software.

1.2 SDLC

SDLC consists of a fullproposal describing how to develop, maintain, replace and modify or improve specific software. The life cycle defines a methodology for improving the quality of software and the overall development process.

Figure 1.1 Graphical representation of the various stages of SDLC

Software Development life cycle consists of the following stages:

Stage 1: Planningand Requirement Analysis:

It is executed by the senior members of the team and taking inputs from the customer and domain experts of the industry. This information is then used to plan the basic project approach andtechnical areas.

Stage 2: Defining Requirements:

This step is used to clearly define the product requirements and get them approved from the customer or domain experts. This is done through ‘SRS’ – Software Requirement Specification document which consists of all the product requirements to be designed and developed during the project life cycle.

Stage 3: Designing the product architecture:

SRS is used for product architects and to derive the best architecture for the product to be developed. The internal design of all the modules of the proposed architecture should be clearly defined with each and every details of project.

Stage 4: Building or Developing the Product:

Developers have to follow the coding guidelines defined by their organization and programming tools like compilers, interpreters, debuggers etc. are used to generate the code. Different programming languages are used such as C, C++, Java and PHP.

Stage 5: Testing the Product:

After the Developing phase, testing phase take place to recognize the result of application. Testing is done to recognize actual result and the expected result.

Stage 6: Deployment in the Market and Maintenance:

Once the product is tested and ready to be deployed it is released officially in market.

1.3 SDLC Models

SDLC models are also referred as "Software Development Process Models. Following are the most important and popular SDLC models followed in the industry:

Ø  Prototype Model

Ø  Waterfall Model

Ø  Spiral Model

Ø  V-Model

Ø  Big Bang Model

The other related methodologies are Agile Model, RAD Model – Rapid Application Development.

Prototype model

Advantages

-          Whenever the customer are not clear with their requirements at that time this is best suitable model

Disadvantages

-          It is not complete process development model

-          Prototype need to be built on companies cost

-          Slightly Time consuming model

-          User may limit his requirements by sticking to the PROTOTYPE

Waterfall model

Advantages:

-          It is simple model

-          Project monitoring and maintenance is very easy

Disadvantages:

-          Can’t accept the new requirements in the middle of the process

Spiral model

Ex: Risk based scientific projects, Satellite projects.

Advantages:

-          Whenever the project is highly risk based at that time this is the best suitable model

Disadvantages:

-          Time consuming Model

-          Costly model

-          Risk route cause analysis is not an easy task

Cycles depend upon Risk involved in the project and size of the project, every cycle has 4 phases.

V Model

Advantages

-          As verification, validation, test management process is maintained. The outcome will be a quality product.

Disadvantages

-          Time consuming model

-          Costly model

Big Bang Model

Big Bang Integration Testing is an integration testing strategy wherein all units are linked at once, resulting in a complete system. When this type of testing strategy is adopted, it is difficult to isolate any errors found, because attention is not paid to verifying the interfaces across individual units.

Disadvantages:

-          Defect identified at the very late stage when all modules are integrated.

-          It is very difficult to isolate the defects found

-          There is high probability of missing some critical defects

-          It is very difficult to cover all cases of integration testing

Phase 2

                                                                   Software Testing Life Cycle

2.1 STLC

STLC (Software Testing Life Cycle)

Figure 2.1 Graphical representation of the various stages of a typical STLC

2.2Phases of STLC

1.Requirements stage	-          Requirement Specification documents -          Functional Specification documents -          Use case Documents -          Test Trace-ability Matrix for identifying Test Coverage
2.Test Plan	-          Test Scope, Test Environment -          Different Test phase and Test Methodologies -          Manual and Automation Testing -          Configuration Mgmt., Risk Mgmt. Etc.
3.Test Design	-          Test Case preparation. -          Test Traceability Matrix for identifying Test Cases -          Test case reviews and Approval
4.Test Execution	-          Executing Test cases -          Capture, review and analyse Test Results
5.Defect Tracking	-          Find the defect & tracking for its closure.
6.Bug Reporting	-          Report the defect on tool/Excels
7.Regression/retesting	-

2.3 SDLCvs. STLC

SDLC(Software Development Life cycle)	STLC (Software Test Life Cycle)
SDLC is Software Development LifeCycle, it is a systematic approach to develop a software.	The process of testing a software in a well-planned and systematic way is known as software testing life cycle (STLC).
Requirements gathering	Requirements Analysis is done in this phase, software requirements are reviewed by test team.
Design	Test Planning, Test analysis and Test design is done in this phase. Test team reviews design documents and prepares the test plan.
Coding or development	Test construction and verification is done in this phase, testers write test cases and confirms test plan.
Testing	Test Execution and bug reporting, manual testing, automation testing is done, defects found are reported. Re-testing and regression testing is also done in this phase.
Deployment	Final testing and implementation is done is this phase and final test report is prepared.
Maintenance	Maintenance testing is done in this phase.

Phase 3

                                                                   Bug Life Cycle

3.1 Bug

“A computer bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working correctly or produces an incorrect result. Bugs arise from mistakes and errors, made by people, in either a program’s source code or its design.”

3.2 Bug Life Cycle

Figure 3.1 Graphical representation of the various stages of a BLC

1) New: When QA finds new bug.

2)Open: A defect that has been reviewed and verified as a true defect.

3) Deferred: If the bug is not related to current build or bug is not important to fix immediately then the project manager can set the bug status as deferred and correct it in next release.

4) Assigned: ‘Assigned to’ field is set by project lead or manager and assigns bug to developer.

5) Resolved/Fixed: When developer makes necessary code changes and verifies the changes then he can make bug status as ‘Fixed’ and the bug is passed to testing team.

6) Retest: A defect that has been fixed by developers, which isstands for test.

7) Need more information: If developer is not clear about the bug reproduce steps provided by QA to reproduce the bug, then he can mark it as “Need more information’. In this case QA needs to add detailed reproducing steps and assign bug back to developer for fix.

8) Reopen: If QA is not satisfy with the fix and if bug is still reproducible then QA can mark it as ‘Reopen’ so that developer can take appropriate action.

9) Closed: If bug is verified by the QA team and if the fix is ok and problem is solved then QA can mark bug as ‘Closed’.

10) Rejected/Invalid:  bug is Rejected or Invalid if the system is working according to specifications and bug is just due to some misinterpretation.

Functional Defect:If the functionality of the application is not working as per the SRS, Example if the requirement is after successfully login Welcome page should be opened.

Usability Defect: If the Application is not easy to understand then it is called usability defect. Example if you are entered wrong details in login window then validation message should be come.

Cosmetic Defect:Cosmetic defects are the bug which does not affect further processing of the application and testing. The priority of the cosmetic defects are categorized as "low", while assigning priority.Cosmetic errors are the spelling mistakes, tab sequence etc.

                                                                   QA Basics

QA Testing

QA confirms the implementation of processes, procedures and standards for verification of developed software and proposed requirements.

It is a subset of Software Test Life Cycle (STLC).

Objectives of QA Testing

Ø  QA develops testing documentation (including test plans, test specifications, and test procedures)

Ø  Design and execute a full testing lifecycle.

Ø  Assure the quality of client deliverables.

Ø  Confirm the full functional capabilities of the final product.

Ø  Confirm stability and performance (response time, etc.) of the final product.

Ø  Confirm that product/website meet client expectations/requirements.

Ø  Report, document and verify code and design defects.     

Ø  The test cases are testing the software requirements in accordance with test plans.

Ø  The test cases are supportable.

Bug Summary

Bug ID	1
QA	Nisarg Kachhiya	Email :- nisarg.k@msp-group.co.uk
Submit Date	20/09/2014
Summary	Login panel not working
Severity	High
Product	Website
Version	1.0
OS	Windows
Browser	Firefox 21.0
URL	www.abc.com/login.php
Steps to Reproduce	1.      Open www.abc.com 2.      Click on Login button 3.      Enter Email Id and Password 4.      Error on Login button Current login button is not working hence unable to login
Screenshot	1.jpg

Types of Manual Testing

Smoke Testing

Smoke Testing is used to determine that the critical functionalities of the program is working fine.

This testing is performed by the developers or testers.

For Example a typical smoke test would be - Verify that the application launches successfully, Check that the GUI is responsive ... etc.

Sanity Testing

Sanity testing is performed to determine that the bugs have been fixed and no further issues are introduced due to these changes. The goal is to determine that the proposed functionality works roughly as expected.

Sanity testing checks only the particular component of the entire system.

Regression Testing

It is type of testing in which one will perform testing on the already tested functionality again and again. Usually we do this in 2 scenarios:

1.      When the tester identifies the defects and raise to the developers, and defect is successfully modified by developer and give it back to tester.The test engineers will check defect functionality and related functionality once again.

2.     Whenever some new features are added. Then the test engineers will check all the related features of those new features once again this is known as Regression Testing.

Functional Testing

Functional Testing is a testing technique that is used to test the features/functionality of the system or Software, which cover all the scenarios of product. 80 percent of functions and 100 percent of test cases should be performed in function testing.

Integration Testing

Integration testing in which individual software modules are combined and tested as a group. It occurs after unit testing. Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing.

Retesting

It is type of testing in which one will perform testing on the same functionality again and again with deferent sets of values, in order to confirm whether it is working fine or not.

Adhoc Testing

Adhoc Testing is carried out with the knowledge of the tester about the application and the tester tests randomly without following the specifications/requirements. The tester has to find defects without any proper planning and documentation.

Testers randomly test the application without any test cases or any business requirement document.

RandomTesting

Random testing is a black-box software testing technique where programs are tested by generating random, independent inputs. Results of the output are compared to software specifications to verify that the test output is pass or fail.

Acceptance Testing

Acceptance testing is basically done by the user or customer. The goal of acceptance testing is to establish assurance in the system.

Usability Testing

Usability testing is testing for 'user-friendly'. Clearly this is subjective and depends on the targeted end-user or customer. Programmers and developers are not suitable as usability testers.

How easy it is to use the software, how easy it is to learn the software, how useful is the software to end user.

GUI Testing

Graphical User Interface (GUI) testing is the process of testing the system's GUI of the System Under Test. GUI testing involves checking the screens with the controls like menus, buttons, icons, and all types of bars - tool bar, menu bar, dialog boxes and windows etc. GUI testing should be work according to mock up document.

Front End Testing

Front End Testing is basically Graphical User Interface (GUI) testing or GUI functional testing.

Front end testing it refers to GUI and Functionality testing. When we check the client part of the program is often called the front end testing and the front end is responsible for checking syntax and detecting error.

Back End Testing

Back End Testing involves databases or any backend storage. It’s basically testing data while travelling from front to back end or in back end to back end only. When we enter some data in front end application and it is getting stored on some database then we have to test it whether it is storing correctly. We can do it by writing relevant SQL queries.

Security Testing

Security testing is basically a type of software testing. It is used to check whether the application or the product is secured or not. It checks to see if the application is vulnerable to attacks, if anyone hack the system or login to the application without any authorization.

Example: Network security, System Software security, Client side application security, Server side application security.

Browser Compatibility Testing

It checks compatibility of your website with different browsers like Firefox, Google Chrome, Internet Explorer, Safari etc.

End to End Testing

End-to-end testing is a technique used to test whether the flow of an application right from start to finish is behaving as expected. The purpose of performing end-to-end testing is to identify system dependencies and to ensure that the data integrity is maintained between various system components and systems.

The entire application is tested for critical functionalities such as communicating with the other systems, interfaces, database, network, and other applications.

Gap Analysis

When requirements are modified during project development at that time it may be possible that some modules are added to the product or modified the existing modules.

So in that situation tester has to test that new modules and also verify the other modules would not be affected by new added modules.

  

Test Plan

Topics	Description
Summary	Write a detailed description of the test plan. The section also includes the status of the work item that tracks the progress of the test plan.
Business Objectives	Specify the business explanation for the release. Business objectives are often tied to financial goals, for example winning market share from a competitor or improving product usability and reliability.
Test Objectives	It gives the success criteria for the project. You can define the goals for the planned testing effort. For example, If we want to track an objective, to track its successes, failures, defect status, and issues in order to provide feedback to development before software is delivered to customers.
Formal Review	List the people who must review or approve your test case and define the approval process.
Requirements	In requirements, it is used for comparison of requirements and test cases. By compare between requirements and test cases, we create coverage reports to define the percentage of requirements that are covered by test cases.
Risk Assessment	List the risks that are associated with a particular test plan. Each risk includes an assessment, impact, a measurement of relative importance, and a mitigation impact. Team members can add their own risk assessment in the My Risk section.
Test Schedules	Define the schedule for the test plan. In this section, create multiple milestones.
Test Estimation	Define test execution effort for test plan. Effort can be entered in person hours, days, months, or years.
Test Environments	Set up of software and hardware on which product will going to perform.
Test Team	List the members of each test team.
Quality Objectives	Quality objectives provide various measurements of quality for the overall release, for example, the number or percentage of high severity defects.
Entry Criteria	Specify the conditions that are required to start testing, such as the minimum level of product and feature quality, test environment setup, test data.
Exit criteria	We specify the testing is complete, If 100% of the test cases are run and that all of the most severe defects have been fixed. During the course of a test cycle, we can adjust the exit criteria.
Test Cases	Lists the test cases associated with the test plan.
Attachments	Attach files and documents to the test plan, such as previous test plans, test iterations, screen captures, and other supporting material.
Test Strategy	Test strategy is an outline that describes the testing approach of the software development cycle.

  

Test Cases

Test Cases for Login Module:

Test Case:-1

Test case ID	Test Module	Test Step	Expected Value	Actual Value	Result	Priority/Severity
1	Login_positive	1)Enter the url:www.abc.com 2)Click on Sign In link 3)Enter valid userID and   valid password 4)Click on login button	1)Verify the homepage of url: www.abc.com 2)Verify the login page 3)verify user can able to click login	Working as expected	PASS	High

Test Case:-2

Test case ID	Test Module	Test Step	Expected Value	Actual Value	Result	Priority/Severity
2	Login_negative	1)Enter the url:www.abc.com 2)Click on Sign In link  3)Enter invaliduserID and   valid password 4)Click on login button	1)Verify the homepage of  url: www.abc.com 2)Verify the login page 3)verify user can able to click login	Working not properly because of Following issue: INVALID ID	FAIL	High

Test Case:-3

Test case ID	Test Module	Test Step	Expected Value	Actual Value	Result	Priority/Severity
3	Login_negative	1)Enter the url:www.abc.com 2) Click on Sign In link 3)Enter valid userID and   Invalid  password 4)Click on login button	1)Verify the homepage of  url: www.abc.com 2)Verify the login page 3)verify user can able to click login	Working not properly because of Following issue: INVALID PASSWORD	FAIL	High

                         

Test Case:-4

Test case ID	Test Module	Test Step	Expected Value	Actual Value	Result	Priority/Severity
4	Login_negative	1)Enter the url:www.abc.com 2)Click on Sign In link 3)Enter Invalid userID and   Invalid password 4)Click on login button	1)Verify the homepage of  url: www.abc.com 2)Verify the login page 3)verify user can able to click login	Working not properly because of Following issue: 1) INVALID ID 2)INVALID   PASSWORD	FAIL	High

Test Case:-5

Test case ID	Test Module	Test Step	Expected Value	Actual Value	Result	Priority/Severity
5	Login_negative	1)Enter the url:www.abc.com 2)Click on Sign In link 3)Leave blank userId and   blank password 4)Click on login button	1)Verify the homepage of  url: www.abc.com 2)Verify the login page 3)verify user can able to click login	Working not properly because of Following issue: 1) INVALID ID 2)INVALID   PASSWORD (Try again with your full Email ID and password )	FAIL	High

Test Case:-6

Test case ID	Test Module	Test Step	Expected Value	Actual Value	Result	Priority/Severity
6	Login_negative	1)Enter the url:www.abc.com 2)Click on Sign In link 3)Enter valid userId and   keep blank password 4)Click on login button	1)Verify the homepage of  url: www.abc.com 2)Verify the login page 3)verify user can able to click login	Working not properly because of Following issue: 1) INVALID ID 2)INVALID   PASSWORD (Try again with your full Email ID and password )	FAIL	High

Test Case:-7

Test case ID	Test Module	Test Step	Expected Value	Actual Value	Result	Priority/Severity
7	Login_negative	1)Enter the url:www.abc.com 2)Click on Sign In link 3)Leave blank username and  enter valid password 4)Click on login button	1)Verify the homepage of  url: www.abc.com 2)Verify the login page 3)verify user can able to click login	Working not properly because of Following issue: 1) INVALID ID 2)INVALID   PASSWORD (Try again with your full Email ID and password )	FAIL	High

Test Case:-8

Test case ID	Test Module	Test Step	Expected Value	Actual Value	Result	Priority/Severity
8	Login_negative	1)Enter the url:www.abc.com 2)Click on Sign In link 3)Enter valid userId and  Invalid password 4)Click on login button	1)Verify the homepage of  url: www.abc.com 2)Verify the login page 3)verify user can able to click login	Working not properly because of Following issue: INVALID   PASSWORD (Enter alphanumeric password )	FAIL	High

Test Case:-9

Test case ID	Test Module	Test Step	Expected Value	Actual Value	Result	Priority/Severity
9	Login_negative	1)Enter the url:www.abc.com 2)Click on Sign In link 3)Enter valid  userId and   Invalid password 4)Click on login button	1)Verify the homepage of  url: www.abc.com 2)Verify the login page 3)verify user can able to click login	Working not properly because of Following issue: INVALID   PASSWORD (Need one special character in password )	FAIL	High

Test Case:-10

Test case ID	Test Module	Test Step	Expected Value	Actual Value	Result	Priority/Severity
10	Login_negative	1)Enter the url:www.abc.com 2)Click on Sign In link 3)Enter valid userId and   Invalid password 4)Click on login button	1)Verify the homepage of  url: www.abc.com 2)Verify the login page 3)verify user can able to click login	Working not properly because of Following issue: INVALID   PASSWORD (Need one capital letter in password )	FAIL	High

Test Case:-11

Test case ID	Test Module	Test Step	Expected Value	Actual Value	Result	Priority/Severity
11	Login_negative	1)Enter the url:www.abc.com 2)Click on Sign In link 3)Enter valid  userId and   Invalid password 4)Click on login button	1)Verify the homepage of  url: www.abc.com 2)Verify the login page 3)verify user can able to click login	Working not properly because of Following issue: INVALID   PASSWORD (Need one capital letter and alphanumeric password )	FAIL	High

Test Case:-12

Test case ID	Test Module	Test Step	Expected Value	Actual Value	Result	Priority/Severity
12	Login_positive	1)Enter the url:www.abc.com 2)Click on Sign In link 3)Click the hyperlink of Forgot Password	1)Verify the homepage of url : www.abc.com 2)Verify the login page 3)verify user can able to click hyperlink of forgot Password and redirect to the webpage	Working as expected	PASS	High

Test Case:-13

Test case ID	Test Module	Test Step	Expected Value	Actual Value	Result	Priority/Severity
13	Login_positive	1)Enter the url:www.abc.com 2)Click on Sign In link 3)Click theSign Up button	1)Verify the homepage of url:www.abc.com 2)Verify the login page 3) verify user can able to click Sign Up button and redirect to the registration page.	Working as expected	PASS	High

Test Case:-14

Test case ID	Test Module	Test Step	Expected Value	Actual Value	Result	Priority/Severity
14	Login_negative	1)Enter the url:www.abc.com 2)Click on Sign In link 3)Enter valid  userId and   Invalid password 4)Click on login button	1)Verify the homepage of  url: www.abc.com 2)Verify the login page 3)verify user can able to click login	Working not properly because of Following issue: INVALID   PASSWORD (password must be between 8 to 32 character long)	FAIL	High

Test Case:-15

Test case ID	Test Module	Test Step	Expected Value	Actual Value	Result	Priority/Severity
15	Login_negative	1)Enter the url:www.abc.com 2)Click on Sign In link 3)Enter Invalid userId and valid password 4)Click on login button	1)Verify the homepage of  url: www.abc.com 2)Verify the login page 3)verify user can able to click login	Working not properly because of Following issue: INVALID ID (username must be between 8 to 32 character long)	FAIL	High

Software Configuration Management

SCM provides the services in following area:

Managing a repository of Component:

In project development there is need of storing different modules and all the versions of product safely. So this feature provides version management and complex object modelling,workspace control.

“SCM is the process of identifying and defining the items in the system, controlling the changes of these items throughout their life cycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items.”

What is Testing Scenario?

A test scenario can be an independent test case or a series of test cases that follow each other. Test scenario is just a story which explains the usage of the software by any end user.

  

Impact Analysis Document

1. Impact analysis

Impact Analysis is an estimation of the number of risks associated with the product changes, including the estimation of influence on resources, work and timetable. This definition takes into consideration changes values in terms of the whole development process.

It may be useful in such cases:

• There are changes in requirements;
• A request for product changes has been received;
• The introduction of a new module or functionality into the existing product is expected;
• Every time, when there are changes of the existing modules and product features.

2. Impact Analysis for developer

To perform successfully Impact Analysis, a programmer should have such skills:

• Very attentive and detailed research of the relationships between the program modules.
• Tracking of the shared resources.
• Keeping analysis documents up to date (adding new features, changing relationships).

§  Considers the final product and not a separate module as result of his/her work.

Features/Impact Analysis information	Affected configuration	Developer’s comments	Importance	Plans
Main Feature1
Main Feature2	x64	Bug report #1111	4
Main Feature3	all	Bug report #1112	2	Bug report #1001
…

Impact Analysis table

 3. Impact Analysis for tester

Knowledge about the correlation and mutual effect of some changes can help testers:

• Not to waste time on testing of those project parts that has not been affected.
• To focus on the functionality where changes have been introduced.
• To take into consideration other project parts possibly affected by the introduced changes.

Without Impact Analysis, testing specialist can use those test cases that in truth don’t cover last changes in the project. It turns out that Impact Analysis is a powerful tool that allows QA Team to decrease time and resources wasting and considerably increasing testing efficiency.

4. Example of Quality Level calculation

Total=	361	%
Passed=	310	85.9
Failed =	26	7.2
No Run =	25	6.9
N/A =	0	0
Quality Level =	92.3%

Quality Level = (Passed\ (Total-No Run))*100

Where:

• Total means the total amount of the performed test cases;
• Passed means the number of  test cases passed successfully;
• Failed means the number of test cases passed unsuccessfully;
• No Run means the number of not passed test cases;
• N/A means the number of test that are impossible to run at the moment.

5. Sections of Impact Analysis Document

Impact on Requirements: In this section the Analyst writes what needs to be changed in the Use Cases to support the change requested.

Impact on Design and Architecture: In this section the architect and the designer mention which parts of the model need to be modified or redone to support the change.

Impact on Test: The QC writes the test cases need to be updated.

Estimation and Impact on Schedule: The project manager estimates the effort needed and the cost of the change and the impact on project schedule.

Integration Test Cases

Integration Test Case

Integration Test case differs from other test cases.It focuses mainly on the interfaces & flow of data/information between the modules. Here priority is to be given for the integrating links rather than the unit functions which are already tested.                            

Sample Integration Test Cases for the following scenario: Application has 3 modules say 'Login Page', 'Mail box' and 'Delete mails' and each of them are integrated logically.

Concentrate only how modules linked to the Mail Box Page.

Test Case ID	Test Case objective	Test case Description	Expected Result
1	Check the interface link between the Login and Mailbox module	Enter login credentials and click on the Login button	To be directed to the Mail Box
2	Check the interface link between the Mailbox and Delete Mails Module	From Mail box select the an email and click delete button	Selected email should appear in the Deleted/Trash folder

Test Case of Delete Mail Module

Approaches/Methodologies/Strategies of Integration Testing

The Software Industry uses variety of strategies to execute Integration testing.

1) Big Bang Approach and 2) Incremental Approach

 Incremental Approach divided into 3 types:

1) Top Down Approach

2) Bottom Up Approach

 3)Sandwich Approach

Integration Testing Procedure

1. Prepare the Integration Test Plan
2. Design the Test Scenarios, Cases, and Scripts.
3. Executing the test Cases followed by reporting the defects.
4. Tracking & re-testing the defects.
5. Steps 3 and 4 are repeated until the completion of Integration is successfully.

Brief Description of Integration Test Plans:

1.      Methods/Approaches to test (as discussed above).

2.      Scopes and Out of Scopes Items of Integration Testing.

3.      Roles and Responsibilities.

4.      Pre-requisites for Integration testing.

5.      Testing environment.

6.      Risk and Mitigation Plans.

Functional Test Cases

Functional Test Cases

Functional test cases are designed to validate that the application performs a specified business function. The majority of these test cases take the form of user or business scenarios that resemble common transactions. Testers and business users should work together to compile a list of scenarios. Following the Business Process Testing practice, functional test cases should be derived directly from the business process, where each step of the business process is clearly represented in the test case.

For example, if the test plan objective is to validate support for the Manage Business Process, then there should be test cases specified based on the process definition. Typically this means that each process or sub process has one or more defined test cases and each step in the process is specified within the test case definition.