Testing Internet Applications

What do you mean by Internet Application??

Internet applications are essentially client-server applications in which the client is a web browser and the server is a web/application server. Conceptually it seems to be simple, but complexity of these applications varies wildly. As a result of openness and accessibility of the Internet, competition in the Business-consumer arena (e-Commerce) requires intensive testing.

The goal of testing internet-based applications is no different from traditional applications. Just need to uncover errors in the application before deploying it to the internet. Considering the common typical 3 –tier architecture of usual e-commerce sites testing should be performed.

3 –tier Architecture:
Tier1 (Web servers) - Presentation layer
Tier2 – Business logic layer
Tier3 – Data Access Layer

Challenges to face while testing Internet Applications:

1. Large and varied user base: with different skill set, variety of browsers and operating systems usage. Business environment: like dynamic calculation of taxes, shipping charges, financial transactions, and tracking customer profiles.
2. Locales: Accessing the application in other countries force to concentrate on Internationalization and Localization concepts.
3. Testing Environment: To test the application properly, dummy environment related to production should be created which is a bit complex task.
4. Security: As e-commerce applications are open to the world, high priority should be imposed on security to protect it from hackers.

Testing Strategies: Developing a testing strategy for Internet-based applications requires a solid understanding of business requirements. And it is best tackled with a divide and conquer approach. Need to focus on individual tier.

1) Presentation Layer: The layer of an internet application that provides the Graphical User Interface (GUI). The following identifies the three major areas of presentation layer testing:

• Content Testing: Overall aesthetics, fonts, color, spelling, content accuracy, default values.
• Website Architecture: Broken links or graphics.
• User Environment/ Browser-Compatibility testing: Web browser versions and operating system configuration.

2) Business Logic Layer: The layer that models your business processes such as user authentication and transactions. And the testing involves finding errors in the business logic and concentrates on the following factors.

• Performance: Test to see whether the application meets documented performance specifications. Example –Stress Testing.
• Data Validity: Test to detect errors in data collected from customers.
• Transactions: Test to uncover errors in transaction processing includes payment processing, e-mailing verifications.

3) Data Access Layer: The layer that houses data used by the application or that is collected from the end user. Credit card numbers, payment information and user profiles are examples of data in data access layer. Testing the data base primarily involves storage and retrieval of information. The areas to focus on

• Response time: The maximum time to fetch the data through DML.
• Data integrity: Verifying that the data are stored correctly and accurately.
• Fault Tolerance and Recoverability

Reference: "The art of software testing" by Glendford J. Myers

                                        Agile Methodology

Now a days every MNC in IT sector is following Agile methodology because of its advantage.
In the agile methodology, the team will design and implements the code for certain part of the Software according to client requirements and delivers the build to the testing team and client for the evaluation.

If the client and Testing team feedback is positive on the basis of requirements documents, then the development team moves to Remaining part of the software development ,

If they receives negative feedback the re-work will be done on the Developed software.

This is called one of the "test driven software development model" because the client will be closely associated with the development team and testing team. So there is a high chance to deliver the high quality product.  

The software engineers follow different approaches in development and testing. Agile methodology in testing is completely different from Other models .

In agile methodlogy the software engineers follow different frameworks to develop and to deliver the project.
The popular framework among all is "Scrum".

Tomorrow we will be discussing the complete scrum process in detail.
Source: 1) Mostly Wikipedia and other related sites,
             2) My trainer notes and
             3) Special thanks to Mr. Srikanth Girijala for the support in some Concepts

Test Plan Document:

Test Plan Document:

This document is prepared by the Test lead once they get the approved test strategy document from the test manager.

The test plan document is dependent on Build release.  

Contents of Test Plan Document:  

      Title: It describes the name of the project with type of document

Example: Banking System Test Plan v1.0 à describes the type of the document with version number where v1.0 represents initial version of first module.

·         History Of Document: It describes about the details of author of test plan document, when it was prepared, who conducted reviews, change of notifications and approval of test plan document.

·         Introduction :

Ø Project Overview: Brief description about the application under test.

Ø Objective of Test Plan: Brief description about the current test plan document.

Ø Referred Documents: About the documents referred to prepare the test plan document.

Example: BRS and FRS documents.

Ø Scope :

ü    In Scope:  It describes the possible testing activities under current test plan like functionality testing, usability testing, etc…

ü    Out of Scope: It describes the activities which are not possible under current test plan like unit testing, integration testing, performance testing, etc…

·         Features to be tested: It describes about the available modules and requirements in current build to validate

·         Features not to be tested: It describes about the modules and requirements which are not required to validate.

·         Entry & Exit Criteria:

a)      Entry criteria describe when to start testing or when to perform dynamic testing or when to perform test case’s execution.

The factors which were considered in entry criteria,

      All the test cases should be prepared and reviewed.

      Build should be deployed (installed) at test environment.

      Build should pass sanity test. i.e., build must be stable.

      Test environment setup should be completed.

b)      Exit criteria describe when to stop testing activities.

The factors which were considered in exit criteria,

      All the test cases should be executed atleast once.

      Majority of the test cases should be passed.

      Identified defects should be closed or postponed.

      Defect ratio must be less than acceptance level.

      Budget and time constraints should be keep in mind.

      When UAT is completed then test engineers can stop testing.

·         Suspension & Resumption Criteria:

a)      Suspension Criteria: It describes when the test engineer can suspend the test cases    execution.

The factors which were considered in suspension criteria,

      When build is not stable, means when it is failed in Build Verification Test.

      When there is a change request from client.

      Delay in publishing input documents.

      Whenever test engineer identifies showstopper defect.

b)                  Resumption Criteria: It describes when to continue the test execution after suspension.

The factors which were considered in resumption criteria is,

      When the patch file is released for rejected build.

      When requirements are refined based on client request acception or rejection.

      When input documents are publishes.

      When showstopper defects are resolved.

·         Testing Approach: It describes the testing approaches they will be using to validate the application functionality.

Example: Usability testing, functionality testing, compatibility testing etc…

·         Roles & Responsibilities: It describes the test engineer names and allocated tasks to perform.

·         Schedule: It describes the timelines to perform each activity during testing.

·         Test Environment: It describes the required environment setup for test cases execution like hardware and software configurations in the system to run the test cases.

Example: Browser setup, OS settings, etc…

·         Test Deliverables: The document which needs to be delivered at end of every task in testing is known as test deliverables.

Here in entire testing process after every phase the documents regarding to that phase must be delivered to the appropriate officials.

Example: Test Cases Review Report, Test Cases Execution Report, etc…

·         Risks & Mitigations: It describes the possible risks and the solutions for those risks at the test environment and work environment.

Example: Lack of domain knowledge to test engineers , here the solution is conducting KT sessions .

Note: Once the test plan document is prepared, the test leas conduct review with senior test engineers to get it approved and then the approved test plan document is delivered to the test engineers of the team.

Interview Question: What is showstopper defect???

Some Useful Templates_ Defect Report Template:

Every Organization will maintain their own templates .

Defect Report: The document which is used to report about the identified defects while testing the software application to the development  team , and the process of reporting is known as defect reporting.

Sample Defect Report Template:

Components of Defect Report Template:

Summary: Brief description about the review.

Defect_ID: The name of the defect and it should be unique.

Note: If we are using any defect reporting tool then tool will generate unique ID for a defect.

Reported By: The name of the test engineer who identified the defect.

Reported On: On which date the defect identification was done.

Note: In general, whenever the Test engineer identified defect on the same day we need to report about the defect.

Reported To: The person belongs to the development to whom the test engineer reports about the defect.

Reproducible Defect: If the defect is raised whenever the test engineer rechecks the same functionality then it is the reproducible defect.

Reproducible à Yes

Not Reproducible à No

Project Name: Name of the project.

Module Name: Name of the module in the particular project.

Build Version: Version Number of the build.

Test Set: Name of the test set in which test cases are failed.

Test Case_ID/Name: Name of the test case in which the defect is identified.

Priority: It describes the importance of the functionality in which we identified the defect.  Levels of Priority were High, Medium, Low.

Severity: It describes the impact of the defect to execute other test cases. The levels of Severity were High, Medium, Low.

Status: It describes the state of the defect.

Snapshot: The picture of the functionality in which we identified the defect.

Some Useful Templates_RTM TEMPLATE

RTM (Requirement Traceability Matrix): RTM is a dcocument consists of tabular format which is used to cross check the requirements coverage with the written test cases. It can be prepared by the test engineer or test lead. RTM can be prepared either in excel sheet or in Quality Center (Depends on the availability of the resources in the organization).

Sample Requirement Trace ability Matrix (RTM) Template:

Components of RTM Template:

Project Name: Name of the project.

Module Name: Name of the module in the particular project.

Created By:  Name of the test engineer who created the Requirement Traceability Matrix.

Created On: The date on which the RTM was prepared.

Reviewed By: Names of the persons who were responsible to conduct the reviews on RTM.

Reviewed On:  On the date review was conducted.

Referred Documents:  Inputs to derive the RTM.

Requirement_ID: The name of the specific requirement of a particular application and it should be unique:

Syntax:  001 Project Name_Module Name_Requirement

Test Scenario: The scenarios which were derived based on the requirement. One requirement may have many test scenarios.

Syntax: TS001_Requirement_Derived condition for that requirement

Test Case_ID/Name:  The name of the test case and it should be unique for the derived test scenario

Syntax:  TC001_Project Name_Module Name_Functionality

Test Case Description: It describes the purpose or objective of the written test case.

Some Useful Templates_TEST CASE TEMPLATE

Here I followed the general standards in the preparation of templates

Test Case: The step by step procedure to validate the functionality of the application, for every user and the subsequent response from the system. Every Organization will maintains their own template. 

Sample Test case Template:

Components of test case template:

Project Name: Name of the project.

Module Name: Name of the module in the particular project.

Created By:  Name of the test engineer who created the test cases.

Created On: The date on which the test cases are prepared.

Reviewed By: Names of the persons who were responsible to conduct the reviews on Test cases.

Reviewed On:  On the date review was conducted.

Referred Documents:  Inputs to derive the test cases.

Test Case_ID/Name:  The name of the test case which should be unique.
Syntax:  TC001_Project Name_Module Name_Functionality.

Test Case Description: It describes the purpose or objective of the test case.

Step Name: It describes the no. of steps in a test case.

Example: Step1. Step2, Step3…etc

Step Description: It describes the user operation to be performed on AUT (Application Under Test) during test cases execution.

Test Data: It describes the data which we give to the application during test cases execution.

Priority: It describes the importance of the test case for execution. It was derived based on the importance or usability of the functionality with respect to client business needs. Based on the importance priority status can be mentioned as High, medium, low.

Expected Result: It describes the expected behavior of the application with respect to user operations.

Actual Result: It describes the actual behavior of the application after execution of the test case.

Status: It describes the status if the test case after execution. The statuses used to mention in status column is

Passed:  When both actual result and expected result are same.

Failed: When the actual result and expected result are not same.

QC Path: It describes the name of the folder in “Test Plan” Component of Quality Center (QC) to export these written test cases. 

About Reviews

Reviews and Its Types:

Review is a type of verification technique.

Without executing the application checking to find out the defects on the work done is known as Reviews.

We have different types of Reviews.

Peer Review: Peer Reviews (One to One Reviews) are informal reviews between two employees, where one employee delivers the details regarding the documents to other employees for the identification of mistakes/defects with no cost. It is an unplanned meeting.

Example: My friend is struggling with generation of test script for particular functionality. After I finish my work, I am helping her. This is the great example of peer reviews.

Walkthroughs: Walkthroughs are the semi informal meeting with more than 2 or more employees, where the document owner (Author) explains about the document to the other employees to identify the mistakes/defects. It is a pre- planned review, so it costs more than peer reviews

Example: Presenting my ideas regarding one task in front of the 2 or more members with full preparation.

Inspections: A fully formal meeting with more than 5 employees, where all the employees participate with the intention of finding mistakes/defects.

Interview Questions_0103: What is peer review??

Interview Questions_0104: What is a walkthrough??

Interview Questions_0105: What do you mean by Inspections??

Interview Questions_0106: Have you participated in the peer reviews while doing project at your institute??