STLC (Software Testing Life Cycle):

STLC (Software Testing Life Cycle):

It contains 6 phases.

1)     TEST PLANNING

   Plan: Plan is a strategic document, which describes how to perform a task in an effective, efficient and optimized way.

  Optimization: Optimization is a process of reducing or utilizing the input resources to their maximum and getting the maximum possible output.

Test Plan: It is a strategic document, which describe how to perform testing on an application in an effective, efficient and optimized way. The Test Lead prepares test                                                                                                                    plan.

Inter system testing:

Inter:

During this testing process tester can verify co existence of a new application with other application which is already used. 

used. 

Recovery testing:

R

 During this testing process tester can verify how well our application changes its state from abnormal state to normal state. Usually applications are run in normal state. When the application changes its state from normal to abnormal state due to power failure, system failure, Mishandling etc…

ov

Security Testing

             Its is a type of testing in which one will concentrate on the following areas of the application

             a. Authentication Testing

             b. Direct URL Testing (Uniform Resource Location)

             c. Fire Wall Leakage Testing.

(a) Authentication Testing: -

             It is a type of testing in which one will enter different combinations of usernames and passwords and try to access the home page in order to check whether only the authorized persons are accessing the application or not.

(b) Direct URL Testing: -

             It is a type of testing in which one will enter the URL of an unauthorized page directly in the browser and try to access that page in order to check whether it is been accessed or not.

(c) Firewall Leakage Testing: -

             It is a type of testing in which one will enter as one level of user and try to access the other level of unauthorized pages in order to check whether the firewalls are working properly or not.

Installation Testing: -

             It is a type of testing in which one will install the application in to the environment by following the guide lines provided in the installation document and if the installation is successful then he will come a conclusion that the given guide lines are correct otherwise he will come to a conclusion that the given guidelines are not correct.

Compatibility Testing

It is a type of testing in which one may have to install the application into multiple number of environments prepared with different combinations of environmental components in order to check whether the application is suitable with these environments or not. This is use usually done to the products.

Load testing:

 During this testing process tester can verify the performance of the server  when many clients requesting the same data at a time.

Performance Testing:

 Tester verifies speed of processing. During this testing tester will verify how fast applications respond with a user request

Soak Testing:

 During this testing process, tester can run application continuously or long period of time to verify whether the application performance is stable or not.

Localization Testing

•         Checks the quality of a product's localization for a particular target culture/locale.

•         This test is based on the results of globalization testing, which verifies the functional support for that particular culture/locale.

•         Can be executed only on the localized version of a product

Stress Testing: During this process tester can run application with extra loads to find out break point of application or max capacity of application

Volume Testing: During this process tester can run application with huge amount of resource (data /device resource) to measure the performance of application.

Globalization testing:

•         The objective of globalization testing is to detect potential problems in application design that could inhibit globalization.

•         It makes sure that the code can handle all international support without breaking functionality that would cause either data loss or display problems.

•         Globalization testing checks proper functionality of the product with any of the culture/locale settings using every type of international input possible.

Parallel testing

During this testing process tester can verify the features of new application with the features of a similar application with is already used to know the strengths & weaknesses  of the new application. 

Ad-hoc Testing:

It is a type of testing in which one will perform testing on the application in his own style after understanding the requirements clearly.

Regression testing:

It is a type of testing in which one will perform testing on the already tested functionality again and again this is usually done in scenarios (Situations).

Scenario 1:

Whenever the defects are raised by the Test Engineer rectified by the developer and the next build is released to the testing department then the Test Engineer will test the defect functionality and its related functionalities once again.

Scenario 2:

Whenever some new changes are requested by the customer, those new features are incorporated by the developers, next built is released to the testing department then the test engineers will test the related functionalities of the new features once again which are already tested. That is also known as regression testing.

Retesting:

It is a type of testing in which one will perform testing on the same function again and again is called retesting.

It is performed for 2 reasons

-         Reproducibility

-         To rule out environment issues

Usability testing

It is a type of testing in which one will concentrate on the user friendliness of an application.

Smoke Testing

Smoke testing is the initial test performed on the application to check  whether  the total functionality exits or not.

It is also called as build verification testing (BVA).

Sanity Testing:

Testing the application with positive approach is called sanity testing. In this we verify the application with valid inputs.

Functional Testing

Functional Testing:

This testing is performed to check how the application is responding by giving proper

inputs.

E.g. Navigation, Data entry, processing and retrieval, based on desired or expected behavior and requirements.

TESTING TECHNIQUES

1 Black Box Testing

It is a method of testing in which one will perform testing only on the functional part of an application with out having any structural knowledge. Usually test engineers perform it.

2 White box Testing (Or) Glass box Testing (Or) Clear box Testing

It is a method of testing in which one will perform testing on the structural part of an application. Usually developers are white box testers perform it.

3 Gray box Testing

It is a method of testing in which one will perform testing on both the functional part as well as the structural part of an application.

Note: The Test engineer with structural Knowledge will perform gray box testing.

Types of Testing-

System testing contains

           a) GUI testing

           b) Functional Testing

                1)  Sanity testing

                2) Smoke testing

                3) Usability testing

                4) Retesting

                5) Regression testing

                6) Ad-hoc Testing

                7) Accessibility testing

                8) Parallel testing

                9) Globalization testing

                10) Localization testing

        c) Non-Functional Testing

               1) Compatibility testing

               2) Configuration testing

               3) Intersystem Testing

               4) Installation testing

               5) Performance testing

                        i) Load testing

                        ii) Stress testing

                        iii) Volume testing

                        iv) Soak testing

                        v) Ramp testing

                        vi) Recovery testing

              6) Security testing

         5) User acceptance testing:

          Acceptance testing contains

            1) Alpha Testing (α)

            2) Beta Testing (β)

V-Model:

 

Requirements begin the life cycle, before development is started a system test plan is created .The test plan focuses on meeting the functionality specified in the requirements.

The high level design phase focuses on system architecture and design. An integration test plan is created in this phase in order to test the pieces of the software systems ability to work together.

The low level design phase is where the actual software components are designed and unit test plans are created.

The coding phase is where all the coding takes place ,once coding is complete the path of execution continues up the right side of ‘v’ where the test plans developed earlier are now put to use.

Advantages:

Simple and easy to use .

Each phase has specific deliverables.

Higher chance of success over the water fall model due to the development of test plans early during lifecycle.

Disadvantages:

Little flexibility and adjusting scope is difficult and expensive .

Software is developed during the implementation phase so, no early prototypes of the software are produced.

Spiral Model:

Advantages:

High amount of Risk Analysis.

Good for large and critical (complex) projects.

Software is produced early in the life cycle.

Disadvantages:

Can be costly model to use.

Risk analysis requires highly specific expertise .

Projects success is highly dependent on the risk analysis phase.

Water Fall Model (or) Linear Sequential Model

 

  

Advantages:

       It is a simple model and easy to maintain project implementation is very easy.

Drawbacks:

       Adjusting the scope during the lifecycle can kill the project.

         No working software is produced until late during the lifecycle.

         Poor model for complex and object oriented applications.

Software Development Models

         Prototyping Model

         Waterfall Model

         Spiral Model

         V-Model

1. Prototyping Model of Software Development:

A prototype is a toy implementation of a system; usually exhibiting limited functional

capabilities, low reliability, and inefficient performance.  There are several reasons for

developing a prototype.  An important purpose is to illustrate the input data formats,

messages, reports and the interactive dialogues to the customer. This a valuable mechanism for gaining better understanding of the customer’s needs. Another important

use of the prototyping model is that it helps critically examine the technical issues associated with the product development.

Types of Environment: - There are four types of environments

1. Stand alone environment or One-tier environment
2. Client –server environment or Two-tier Architecture
3. Web environment or Three-tier Architecture
4. Distributed environment or N-tier Architecture

a.    Stand Alone environment: -

In this type of environment all the three layers that is presentation layer, Business layer& Database layer will be present in al single tier. This type of environment is suitable for single user application.

One-Tier Architecture

                                   PL

                                   BL               ÞOne tier Architecture
                                   DBL

 

b.    Client –server environment:

In this type of environments there will be two tiers, one tier is for clients and other tier is for database servers. The presentation layer and the business layer will be present in each and every client . The database layer will be present in the database server. This type of environment is suitable for multi user application in a single or a limited area.

Two tier Architecture

c.     Web environment:  In his type of environment three tiers will be there. One is for client’s the middle one is for application server and the other one is for database servers. Presentation layer will be present at clients, Business layer will be present in the application server, and database layer will be present at the database servers. This type of environment is suitable for the applications that are used all over the world by limited number users

Three-tier Architecture:

Web server: -

                        It is software, which provides web services to the clients.

E.g.: - Internet Information service (IIS).

Example for Application servers: Tom pact, Web logic, web sphere etc..,

d.    Distributed environment: -

It is similar to the web environment but the number of application servers are increased and represented in individual tiers in order to distribute the business logic so that the logic will be distributed.

N-tier Architecture:

Levels of Testing

There are 5 levels of testing.

1) Unit level testing:

If one performs testing on a unit then that level of testing is known as unit level testing. It is white box testing usually developers perform it.

Unit: -It is defined as a smallest part of an application.

2) Module level testing:

If one perform testing on a module that is known as module level testing. It is black box testing usually test engineers perform it.

3) Integration level testing:

Once the modules are developing the developers will develop some interfaces and integrate the module with the help of those interfaces while integration they will check whether the interfaces are working fine or not. It is a white box testing and usually developers or white box testers perform it.

The developers will be integrating the modules in any one of the following approaches.

i) Top Down Approach (TDA)

            In This approach the parent modules are developed first and then integrated with child modules.

ii) Bottom up Approach (BUA)

             In this approach the child modules are developed first and the integrated that to the corresponding parent modules.

iii) Hybrid Approach

               This approach is a mixed approach of both Top down and Bottom up approaches.

iv) Bigbang Approach

              Once all the modules are ready at a time integrating them finally is known as big bang approach.

STUB:

While integrating the modules in top down approach if at all any mandatory module is missing then that module is replaced with a temporary program known as STUB.

DRIVER:

While integrating the modules in bottom up approach if at all any mandatory module is missing then that module is replaced with a temporary program known as DRIVER.

4) System level testing:

Once the application is deployed into the environment then if one performs testing on the system it is known as system level testing it is a black box testing and usually done by the test engineers.

At this level of testing so many types of testing are done.

5) User- Acceptance Testing:

          It is the level of testing in which one will perform the same system testing in the presence of the user in order to make him accept the application. It is a black box testing and usually Test engineer performs it.

Environment: - Environment is a combination of three layers    (e.g.: Yahoo)

a.      Presentation layer

b.      Business layer

c.       Data base Layer

System: The application installed in to an environment combinable called as system.

1. Presentation Logic: The logic that is used for viewing application is known as presentation logic
2. Business Logic:  The logic that is used for performing the operations on the application is known as business logic.
3. Data Base Logic:  The logic that is used for sharing and retrieving the data is known as database logic.

How many sorts of testing are there?

There are two sorts of testing.

Unconventional Testing

It is a sort of testing in which quality assurance people will check each and every out come document right from the initial phase of the SDLC.

Conventional Testing

It is a sort of testing in which the test engineer will test the application in the testing phase of SDLC.

SDLC (Software development lifecycle):

It has 6 phases:

                           1. Initial phase

                           2. Analysis phase

                           3. Design phase

                           4. Coding phase

                           5. Testing phase

                           6. Delivery and Maintenance

1. Initial phase:

                 Task:        Interacting with the customer and gathering the requirements.

 Roles:        BA (Business Annalist)

EM (Engagement Manager)

Process:

Business Annalist

Gathering the requirements is the main task. First of all, the business analyst will take an appointment from the customer, collect the templates from the company meets the customer on the appointed date gathers the requirements with the support of the templates and comeback to the company with a requirements documents

Engagement Manager

Then the engagement manager will check for the extra requirements if at all he fined any extra requirements he is responsible for the excess cast of the project. The engagement manager is also responsible for prototype demonstration in case of confused requirements.

Template:

It is defined as a pre-defined format with pre-defined fields used for preparing a document perfectly.

                 Prototype:

                 It is a rough and rapidly developed model used for demonstrating to the client

                 in order to gather clear requirements and to win the confidence of a customer.

Documents Prepared in this phase:

BRS  -   (Business Requirement Specification)

constitute a specification of simply what the business wants. This is usually expressed in terms of broad outcomes the business requires, rather than specific functions the system may perform. Specific design elements are usually outside the scope of this document, although design standards may be referenced.

FRS  -   (Functional Requirement Specification)

CRS  -   (Client/Customer Requirement Specification)

URS -   (User Requirement Specification)

BDD -   (Business Design Document)

2. Analysis phase:

Task:   Feasibility study

          Tentative planning

            Technology selection

            Requirement analysis

               Roles:   System Annalist (SA)

             Project Manager (PM)

             Team Manager   (TM)

Process:

Feasibility study: It is detailed study of the requirements in order to check whether all the requirements are possible are not.

Tentative planning: The resource planning and time planning is temporary done in this section.

Technology selection: The lists of all the technologies that are to be used to accomplish the project successfully will be   analyzed listed out hear in this section.

                    Requirement analysis :

  The list of all the requirements like human resources, hardware, software required

  to accomplish this project successfully will be clearly analyzed and listed  

  out hear in this section.

Document prepared in this phase:

                                      SRS: (Software requirement specifications)

3. Design phase:

Tasks:   HLD (High Level Designing) , LLD (Low Level Designing)

Roles:   HLD is done by the CA (Chief Architect).

                              LLD is done by the TL (Technical Lead).

Process:

The chief architect will divided the whole project into modules by drawing some diagrams and technical lead will divided each module into sub modules by drawing some diagrams using UML (Unified Modeling Language).

                The technical lead will also prepare the PSEUDO Code.

Documents prepared in this phase:

                   TDD: (Technical design document)

Pseudo Code: It is a set of English instructions used for guiding the developer to develop the actual code easily.

Module:

Module is defined as a group of related functionalities to perform a major task.

4. Coding phase:

Task            :   Programming / Coding.

Roles:  Developers / Programmers.

Process:

Developers will develop the actual source code by using the PSUEDO Code and following the coding standards like proper indentation, color-coding, proper commenting and etc…

Documents prepared in this phase:

                             SCD (Source Code Document)

5. Testing phase:

Task          : Testing.

Roles:  Test Engineer.

Process:    

    First of all the Test Engineer will receive the requirement documents and review it

    for under studying the requirements.

    If at all they get any doubts while understanding the requirements they will

    prepare the Review Report (RR) with all the list of doubts.

    Once the clarifications are given and after understanding the requirements clearly

    they will take the test case template and write the test cases.

    Once the build is released they will execute the test cases.

                 After executions if at all find any defects then they will list out them in a

                 defect profile document.

    Then they will send defect profile to the developers and wait for the next build.

    Once the next build is released they will once again execute the test cases

             If they find any defects they will follow the above procedure again and

             again till the product is defect free.

             Once they feel product is defect free they will stop the process.

Proof: The proof of this phase is Quality Product.

Test case: Test case is an idea of a Test Engineer based on the requirement to test a particular feature.

6. Delivery and Maintenance:

Delivery:

Task :        Installing application in the client environment.

Roles:        Senior Test Engineers / Deployment Engineer.

Process:      The senior test engineers are deployment engineer will go to the client   place and install the application into the client environment with the help of guidelines provided in the deployment document.

 

Maintenance:    

After the delivery if at all any problem occur then that will become a task based on the problem the corresponding roll will be appointed. Based on the problem role will define the process and solve the problem.

When can Testing be stopped?

It’s difficult to determine exactly when to stop Testing.

The following are some of the cases which can help to decide when to reduce/stop Testing:

Ø      Deadlines (Release/Test Deadlines etc)

Ø      Test cases completed with certain percentage passed.

Ø      Test budget depleted.

Ø      Coverage of code/functionality requirements reaches a specified point.

Ø      Bug rate falls below a certain level.

Ø      Beta or Alpha testing period ends.

What is the goal of Software Testing

Ultimate goal is Quality in software product in terms of functionality and user friendly.

Why the above things are done

To find, if it happens in real time, then how the software reacts, how the end-user feels working with our software.

How The Testing Is Performed?

Intentionally breaking the software to find errors, Check whether software is user friendly or not , check as per the client requirements whether this software is created or not, check whether this software work for long hours or not(heavy load).

Testing can be done in the following ways:

• Manually
• Automation (By using tools like Win Runner, Load Runner, Test Director …)
• Combination of Manual and Automation.

Why Testing?

There are many reasons behind the need to test a software. Listed below are some of them:

1. To reduce the number of bugs in the code
2. To provide the quality product
3. To see all the requirements are met
4. To satisfy the customer need
5. To provide bug free software

VALIDATION:

It is a process of checking conducted on the developed product in order to check whether it is working according to the requirements or not.

Every Test Consists Of 3 Steps:

Planning: Inputs to be given, results to be obtained and the process to proceed are to be planned.

Execution: Preparing Test Environment, Completing the test and determining the test results.

Evaluation: Compare the actual test outcome with what the correct outcome should have been.

Buddy Checks:

This is the simplest type of review activity used to find out bugs in a work product during the verification. In buddy check, one person goes through the documents prepared by another person in order to find out if that person has made mistake(s) i.e. to find out bugs which the author couldn’t find previously..

Walkthroughs:

Walk through can be considered same as inspection without formal preparation (of any presentation or documentations). During the walkthrough meeting, the presenter/author introduces the material to all the participants in order to make them familiar with it. Even when the walkthroughs can help in finding potential bugs, they are used for knowledge sharing or communication purpose

Inspection:

Inspection involves a team of about 3-6 people, led by a leader, which formally reviews the documents and work product during various phases of the product development life cycle. The work product and related documents are presented in front of the inspection team, the member of which carry different interpretations of the presentation. The bugs that are detected during the inspection are communicated to the next level in order to take care of them.

VERIFICATION

Verification is a human examination or review of the work product. There are many forms of verification which ranges from informal verification to formal verification ,verification is used for various phases in SDLC and can be in the form of formal inspections ,walkthrough or buddy checking

                                                          (OR)

It is a process of checking conducted on each and every role of the organization in order to check whether they are working according to the guidelines or not right from the starting of the process till the ending of the process

BUG:

When the defect is accepted by the developer then the defect is called as bug.

DEFECT:

 Defect is defined as deviation from the requirements. (OR)

 Mismatch between the expected values and actual values (For Automation).

ERROR:

Mistakes in the syntax and semantics of a program are called errors.

QUALITY:

Quality is defined as not only the justification of the requirement but also the present of value (user friendly).

PRODUCT:

Product is a software application that is developed based on the company’s specifications and used by multiple customers

PROJECT:

It is a software application developed based on a particular customer requirement and used by that particular customer only.

TESTING:

Intentionally finding errors from the software is called testing. Errors may be functional errors or usability errors.

                                                                     (OR)

Testing is the process of executing a program with the intent of finding errors.

                                                                      (OR)

Verifying and validating the application with respect to customer requirements.