Practical Exposure to Testing

UNIT-1

QUALITY

Definition- “It is defined as the conformance to the specifications of the customer”.

“It is also defined as justification of requirements of the customer that produces satisfaction to the customer”.

Note - Quality is psychological rather then physical.

DEFECT

Definition:- “It is defined as the deviation from requirements”.

ERROR

Definition- “It is defined as the mistake associated with the program”.

Hence Error is the root cause for the defect to be appeared in the product.

BUG

Conceptually Bug is same as defect.

But from the point of usage, defect is used by professional and as well as the customers.

Where as Bug is used by professionals only.

Latest  Definition of Quality:-

Quality can also be defined as the presence of requirements or the absence of the defects but also presence of 'VALUE' in the product.

The Value mentioned in the above passage indicates the user friendliness of that application. The true value comes from the product if it has functionality as well the usability (user-friendliness).

How to Produce Quality to Customer?/ How to show this product is quality?

1)      Identification of the Bugs/Defects.

2)      Isolation of the Defects.

3)      Subjecting these defects for Rectification.

4)      Ensuring that the product is defect free.

Just Before the product is delivered to the customer, the organization wants to do the following steps of procedure to ensure the quality.

1.Identification of the Defects:

One has to carefully look for the areas where the requirements are not justified, in-terms of defects.

2.Isolation of the defects:

Once the defects are identified, they have to be listed out in a separate document known as Defect Profile Document(DPD).

3.Subjecting the defects for the verification:

Once the DPD is prepared, it will be sent to the development team for the process of Fixation/Rectification.

Note-Defect Rectification can also be referred as Bug Fixation.

4.Ensure that the product is defect free:

Once you send the defects to the development team, these defects are rectified and the same is informed that there are no more defects. It is the Tester's responsibility to ensure that the product has no defects at all.

Hence the Test Engineer has to ensure the following

---->To ensure the raised defects are rectified.

---->To ensure that there are no new defects as a result of rectification of the old defect.

TESTING

Definition- “It is the process in which defects are identified, isolated, subjected for rectification and ensure that the product is defect free so as to produce quality to the product and hence to the customer satisfaction”.

How the s/w projects are oriented?

Deal: signing the project

SIGN-IN

Its the process in which both the developing company and the client will get into an agreement, the specific project is to be developed within specific budget which is to be delivered by specific tentative dead-lines.

KOM (Kick off Meeting):-

It is a first meeting conducted with in the development company soon after the project is signed in.

What is the agenda of KOM or what is the order of KOM to be taken?

1)      They will have meeting for management Here all the

       Managers+ Technical Managers+ Quality team manager

i)                    First they will discuss the over view of the project.

ii)                  About customer.(good/Bad)

iii)                To select the project team

2 teams will be selected for project

Developer team                                        

1)      Project manager is selected in Dev team

2)      Project is going to be selected.

Quality Team

1)      Quality leaders are selected in Quality Team

2)      Quality is going to be selected.

What is the Role of PM?

He is always realized as PIN

After the Kick of the meeting, the project manager sends an e-mail to the CEO asking for formal permission to initiate the project development process. This process is know on as Project Initiation Note(PIN).

Once the PIN gets acceptance from the CEO, Project Manager initiates the project development activities in a systematic, scientific manner in-terms of Software Development Life Cycle(SDLC).

SOFTWARE DEVELOPMENT LIFE CYCLE(SDLC)

The Software Development Life Cycle includes the following steps-

i) Initial ii)Analysis iii)Design iv)Coding v)Testing vi)Delivery and Maintenance

i)INITIAL:-

This phase has the important task known as Requirement Gathering done by the role Business Analyst.

Apart from this with respect to required, gathered, the monitory work can be done by the other role known as Engagement Manager.

Business Analyst takes following guide lines defined by Quality Standards for that organization, he accomplishes the following responsibilities

------>Customer/User Interaction

------>Highlighting new requirements that fetch profits for the business

------>Collect the requirement and prepare the document

The Business Analyst uses the template(like a proforma in which the required fields are predefined for which the information can be given to prepare any special document) to prepare the Business document by listing out all the functional requirement in it.

This document is also known as Business Design Document(BDD).

BDD is also known as: a) Function Design Document(FDS)

b)Business Document(BD)

c) Business Requirement Document(BRD).

ii)ANALYSIS:-

This phase focuses upon the following responsibilities

--- Analyzing the requirements

--- Feasibility Study

--- Tentative Project Plan

--- System Requirement Analysis

--- Evaluation of Technology and Selection

The above responsibilities are successfully analyzed by System Analysist (SA) following the Quality Standards and ultimately preparing a document known as System Requirement Specification(SRS).

iii)DESIGN:-

This phase, designing of the project is done in following types of design practices,

a)High Level Design(HLD)

It is the design in which how many modules a single project can be divided into, can be determined.

It is done by the Chief Architect (CA).

Module- It is a collection of 'like' requirements known as Functionality, on a whole works together and enables the product quality.

b)Low Level Design(LLD)

It is a design practice in which how many sub-modules/units a single module can be determined.

The outcome of the Design phase is Technical Design Document( TDD) in which the entire design information is Documented.

Chief Architect (CA) is responsible for High Level Design and Team Leader (TL) is responsible for Low Level Design.

The Technical Design Document consists of i) Description of the Design

ii) Pictorial Representation (Depiction)

iii) Flow Chart of the Design

iv) Data Flow Diagram (DFD)

v) Functional Specification

iv)CODING:-

This phase is meant for implementation of design in-terms of development of several programs. The programmers take the responsibility of Coding (writing the programs).

In order to develop Team Lead optimized coding patterns, they follow specific set of guide lines known as Coding Standards. Ultimately, the program files/documents are known as Source Code Documents(SCD).

v)TESTING:-

The process of Testing involves the following steps:

a)Business Design Document(BDD) Review:

The Test Engineer has to review/study the BDD in order to know and understand the functionality of the product so as to attain pre-requisite for Testing the product.

b)Preparation of the Review Report(RR):

As the Test Engineer goes through the Business Design Document, he will get lots of doubts and queries in the process of understanding the functionality. Hence, he will list out all the queries for which the clarifications are required in a specific document known as Review Report (RR).

c)Sending Review Report to the Author:

Soon after the Review Report is prepared, it will be sent to the author of the document (i.e., Business Analyst) and obtain the clarifications. The obtained clarifications are used to ensure complete functional understanding of the product.

d)Preparation of the Test Case Document(TCD):

Soon after functional understanding is obtained, in order to make sure that the testing task is effective, Test Case Document is prepared.

Test Case-It is defined as the case/perception/angle with which testing can be carried on in-order to make sure the specific functionality is proper or not.

In other words, Test Case can also be defined as the possibility of finding thee defect is more.

Advantages of Test Case Document is to provide,

i)                    Planning to the Testing

Ii)  Estimation to the Testing

iii)  Organization to the Testing activity.

e)Execution Of Test Case Document:

Once the TCD is prepared, the TEST ENGINEER has to wait until specific functionality is developed and released for testing. Once the functionality is released in terms of executable file, the testing can be carried out by executing the TCD on the specific functionality.

f)Bug Tracking or Defect Tracking:

Soon after testing is completed, the Test Engineer will be able to identify functional areas in which defects are present and list all the defects in a separate document known as DEFECT PROFILE DOCUMENT(DPD) under the process known as BUG TRACKING.

g)Reporting (Bug Reporting):

Once the DEFECT PROFILE DOCUMENT is prepared, it will be sent to developing team for process of rectification.

vi)DELIVERY AND MAINTAINANCE:

Once the total application is thoroughly tested and certified, it will be delivered to the customer in the following ways. Also to make sure that the product works fine for longer time, the DEVELOPMENT TEAM will offer the Technical Support under the process of maintenance as per the deal between Development Company and Customer.

In this phase, during the process of delivery, the Development Manager, Project Manager and Software Quality Manager play a vital role. Similarly the Development Team play an important role during the process of maintenance.

Usually the following documents are delivered to the customer at the time of delivering the product:

a) Certificate Document

b) User's Guide / Manual Guide

c) Deployment Document (Installation Guide)

d) Software Delivery Note (SWDN)

What Testing Engineer Will Do While Development?

During testing phase, Test Engineer carries by executing the Test Case Document and will prepare DEFECT PROFILE DOCUMENT. When development is going on, Test Engineer will be involved parallely to carry on Business Design Document review, Review Report preparation, clarifications from the Business Analyst and preparation of Test Case Document.

TYPES OF TESTING

Based upon how testing is carried on, where testing is carried and by whom testing is carried on, there are two types of testing-

i) Conventional Testing ii)Un-Conventional Testing

i)Conventional Testing:

It is the kind in which once the product is developed the Test Engineer performs testing / checking on it to see if the requirements are justified. This process is also known as 'Validation'.

The conventional process is performed by the Test Engineer.

ii)Un-Conventional Testing:

It is the kind of testing in which testing is performed on the input of the tasks i.e., documents as well as the process to make sure that output of the task is to be qualitative. This process is also is known as 'Verification'.

The un-conventional process is performed by Quality Assurance Engineer (QAE), which includes Initial, Analysis, Design, Coding and Testing.

HOW TO PERFORM TESTING ON THE APPLICATION?

TEST METHODOLOGY:

Depending upon the perception, what part of the application to be tested and by whom the testing is carried-on, the Test Methodology defines the following methods of testing.

i)Black Box Testing ii)White Box Testing (Glass Box Testing)

i) Black Box Testing:

Definition: “It is defined as the method of testing in which one can perform testing on application without having the internal Structural Knowledge (Program Knowledge) of it”.

Usually, the Test Engineers are involved in Black Box Testing.

ii)White Box Testing / Glass Box Testing:

Definition- “It is defined as the method of testing in which one can perform testing on the application having internal structural knowledge of it”. Usually, the Program Developers are involved in White Box Testing.

*Black Box Testing focuses on the functional part of an application and hence the Test Engineer must be functional expert, whereas White Box Testing focuses upon program part of an application and program expert*

Grey Box Testing:

Definition- “It is defined as another derived method of testing in which both Black Box Testing and White Box Testing practices are combined and applied on the application”

In the Grey Box Testing, basically the test Engineer, who performs Black Box Testing application, has the Internal Structure Knowledge (Programming knowledge/Design knowledge/Environmental knowledge). With this profile, the Test Engineer can give sufficient information with which developer can easily locate defect and rectify it quickly in-turn saving the time of defect rectification.

LEVELS OF TESTING

In order to make sure that the testing (validation) is effectively, efficiently done on the product to ultimately produce quality to the product, the solution is adopted in terms of Levels Of Testing by the industry that takes care of the product at each and every level while it is being developed.

The levels of testing have the following phases:

i)Unit Testing:

Definition: “It is defined as the level of testing in which one can perform testing on unit to check if it is working as per the requirements (structural)”

It belongs to White Box Testing as most of the times at this level programs are made available for testing and usually the Graphic User Interface(GUI) is not aware. Hence the unit testing is done by the developers.

ii)Module Testing:

Definition: “It is defined as the level of testing in which soon after the units are created to form a module that can be tested for its correctness to ensure its functionality as per requirements. Since Module is being tested at this level it is known as Module Testing”.

Module Testing belongs to Black Box Testing, as the GUI is made available at this stage for performing functional testing on it. Hence Module Testing is done by the Test Engineers.

iii)Integration Testing:

Definition: “It is another level of testing in which once the modules are created, they need to be integrated to form an application and if one perform testing on these integrated modules, this testing is known as Integration Testing”.

Purpose of Integration Testing:

i) To check if the individual right functionalities of the modules are not effected.

ii) To check the desired integrated functionality.

iii) To check the data flowing among the modules as per the data flow diagrams.

iv) To check whether the user is able to navigate among various modules.(High Level Integration Testing)

APPROACHES OF THE INTEGRATION

Depending upon how the modules are to be integrated as and when they are developed, there are basically three types of approaches as described below,

i)Top-to-Bottom Approach ii)Bottom-Up Approach iii)Sandwich Approach

i)Top-to-Bottom Approach:

This approach is proposed when ever there is no interference of the customer in the sequence of the development of the modules.

As and when 'child' modules are developed, they are to be integrated with the 'parent' ones and so the direction of integration from top to bottom, hence known as Top-to-Bottom Approach.

When 'child' modules are integrated with 'parents', there is possibility that some 'children' are missing (not yet developed).It effects the integration between rest of the modules. In order to get along with this situation, a small temporary program is employed in place of missing 'child' module, known as ''STUB''.

ii)Bottom-Up Approach:

This approach is usually proposed when ever customers interfere in the beginning and try to alter the sequence of development.

As and when 'child' modules are developed they need to be integrated with the 'parents' which are usually developed after 'children' in this approach. Hence direction of integration is from bottom to upward and is known as Bottom-Up Approach.

As and when the 'children' are getting integrating with 'parents' there may be a possibility, the 'parents' may be missing which are usually compensated with a temporary solution in-terms of a small program, known as ''DRIVER''.

iii)Sandwich Approach:

This approach is proposed when ever the customer tries to interfere and change the sequence of development in between. This approach is a combination of Top-to-Bottom and Bottom-Up approaches. Hence both ''STUBS'' as well as ''DRIVERS'' are possible in this approach.

Integration testing basically belongs to White Box Testing, always done by both the developers at the programming level. Specifically can be termed as Low Level Testing.

Note- In case the Test Engineer is involved in the integration testing that is nothing but High Level Testing in which he checks whether he is able to navigate various application windows/screens.

iv)System Testing:

Definition: “It is defined as another level of testing in which once the total application is developed, it is deployed (installed) into the customer's specified environment and the whole system is formed. If one perform testing on this entire system to check the operational and performance abilities of it, it is known as System Testing”.

Usually System Testing is siad to be a full pledged testing as it covers Graphic User Interface(GUI) testing, functional testing, load, performance, stress testing, security testing, etc.,

System Testing belongs to Black Box Testing and it is obviously done by Test Engineers.

v)User-Acceptance Testing:

Definition: “It is defined as the final level of testing in which the total application is tested in the customer's simulated environment in the presence of the customer in order to ensure the acceptance criteria is justified in the application”.

The User Acceptance Testing belongs to Black Box Testing and is either done by Test Engineer or the Customer.

ENVIRONMENTS

Depending upon how the application is basically developed into the environment, the environment is classified as the below mentioned categories-

i) Stand Alone Environment ii) Client-Server Environment iii) Web Application Environment iv)  Distribution Application Environmental

i)Stand-Alone Environment:

Definition: “It is also known as 'One-Tier Architecture' where there is only one computer in which all three components of application-Program Logic(PL), Business Logic(BL) and Data Base(DB) are placed”.

Since the drawbacks like duplication of information, single user system and non-transparency factors, the solution was requires in-terms of Client Server Environment.

ii)Client Server Environment:

Definition: “This Environment is also called as 'Two-Tier Architecture' in which there are two computers connected with the network. If the Program Client is deployed into the client while Business Logic and Data Base on server machine, it is known as 'THIN CLIENT''. On the other side, if Client Machine has both Program Logic and Business Logic, it is known as 'THICK CLIENT'”.

-However, the Data Base is kept in the server usually referred to as “Data Base Server'.

-As the Business Logic is to be kept on modified, it becomes devious job with this set-up. Hence the solution was proposed in-terms of Web Environment.

iii)Web Environment:

It is also known as Three-Tier Architecture where in three computers, Client, Application Server, Data Base Server are connected to each other. The Program Logic resides the Client, Business Logic resides the Application Server and the Data Base resides in Data Base Server.

When Client sends the request to Application Server, it processes the request with help of Business Logic and if required will access the Data Base Server to get the required data for processing and ultimately reply back to Client in-terms of response. Web Server is another internal component of Application Server which is usually used for serving the web pages to the Client

--Some of clients are Internet Explorer, Netscape Navigator, AOL, Mozilla etc.,

--Some of Application servers are Web Logic, Web Sphere, Com-Cad Apache etc.,

--Some Data Base servers are Oracle, SQL server, DB2 server etc.,

iv)Distributed Environment:

It is also known as 'n-Tier Architecture' where 'n' number of machines (computers) are connected basically to distribute Business Logic and to distribute various services that can process request of the client to send proper reply in-terms of response to the client.

Mathematically,

Application = Progarm Logic + Business Logic + Data Base

Accountability

Every employ of an organization has the responsibilities to be accomplished as per the planning. Once the employ/role accomplishes the task, it is his responsibility to inform the same to the superior. Usually the superior is known as Point of Contact among the 'PEERS' (colleagues) as well as the Team members and point of contact (Team Lead) there will be always co-operation and co-ordination that is expected by the organization for the effective accomplishment of task as well as the smooth running of the organization.

Escalation:

Definition: “It is defined as the process in which either 'ISSUES' or 'SLIPPAGEES' are intimated to the high level management to let them know the situation so as to make them interfere to resolve the issue as soon as possible for the smooth running of the organization.

Note - Escallation process must be accomplished in a systematic gradual manner which is usually referred to as levels of Escallation.

TYPES OF TESTING

Testing is carried out in the following ways,

1.SMOKE TESTING:

Definition: “It is defined as the type of testing in which one can perform initial and overall testing on an application to make sure that all features/objects/windows of an application are available to carry on detailed testing on them”.

“In other words it is the test for availability that is conducted in the initial stage in short span of time”.

Note – Smoke testing is also referred to Cursory Testing as the Test Engineer play with the Cursor to check each object is focused usable.

2.SANITY TESTING:

Definition: “It is defined as the type of initial, overall and non-detailed testing conducted on an application in an short span of time just to make sure that the application is proper(checks if every feature is available for the detailed testing)”.

Note – Sanity Testing is same as Smoke Testing conceptionally, whereas they differ from each other perceptionally.

3.REGRESSION TESTING:

Definition: “It is defined as the type of testing in which one can perform testing on the already tested functionality just to make sure that it is refined to the perfection(Bug Regression Testing) and also to make sure that the existing functionality is un-effected due to the new functionality added to it(Functional Regression Testing).

-Hence Regression Testing can be classified into two categories.

i)Bug Regression Testing:

Definition: “It is the type of testing in which the Test Engineer performs testing on already tested functionality in order to make sure that previously raised defects are rectified and also to make sure that there are no new defects araised”.

ii)Functional Regression Testing:

Definition: “It is the type of Regression Testing in which one can test already tested functionality when ever new changes/functionality is added to it just to make sure that the existing right functionality is not affected due to the new change”.

4.RE-TESTING:

Definition: “It is the type of testing in which one can perform testing on already tested functionality in order to male sure that defects are reproducible if at all any, to rule out the Environmental issues and to ensure the robusness of the application”.

5.ALPHA TESTING:

Definition: “It is the type of User Acceptance Testing that is done on the product as a final testing within the Development company  just before it is delivered to the customer”.

-The advantage of Alpha Testing is that if at all any defects in the environment they can be rectified immediately before the delivery itself.

-Alpha Testing is done by Test Engineer or Customer.

6.BETA TESTING:

Definition: “It is defined as User Acceptance Testing in which one can perform testing on an application when it is delivered to the customer, deployed into the Real-Time Environment and is being used by Real-Time Users”.

-The disadvantage is that if the defects are encountered they cannot be rectified immedeatly and must be following the formalities for the rectification which is usually time consuming.

-The Beta Testing is always usually done by Third party Test Engineer known as Beata Testers.

7.STATIC TESTING:

Definition: “It is the type of testing in which one can perform testing on the application when it is not being executed”.

Example:- GUI Testing, Document Testing.

8.DYNAMIC TESTING:

Definition: “It is the type of testing in which one can perform testing on an application when it is being executed”.

Example:- Functional Testing

9.INSTALLATION TESTING:

Definition: “It is the type of testing in which one can deploy the last module as per the guide lines provided in the Deployment Document and checks whether the module is successfully deployed into the environment”.

Deployment Document

Definition: “It is the document prepared by Project Manager that is sent along with module for testing and contains the guidelines for deployer for the successful deployment”.

Note - Irrespective whether the deployer knows how to deploy the module into the environment, the Deployment Document has to be followed as it goes to the customer while delivery.

10. COMPATIBILITY TESTING:

The difference between Product and Project is that, if the requirements are from within the development company and the out come is development based on testing, such out come is known as Product.

On the other hand if the requirements are coming from outside customer and if the out come is developed based on testing, it is known as Project.

Note - Projects must be delivered only to the specific customers, whereas products are open for all.

Definition: “It is the type of testing in which usually the products are tested on several environments that are tested with various combinations of the environmental components like Browsers, Operating Systems, Application Servers, Data Base Servers etc just to make sure that the products are compatible to these environments”.

11.MONKEY TESTING:

Definition: “It is the type of testing in which one can perform abnormal, beyond capacity and more volumes of data related operations intentionally on an application to check the  stability in spite of the User's abnormal behavior”.

12.EXPLORATORY TESTING:

Definition: “It is the type of testing in which initially the Test Engineer will not be knowing the functionality and explore the application to know it while testing is carried on simultaneously”.

It is a type of testing in which the T.E encounters the application with out having pre-requisite functional knowledge. Inevitably they explore the functionality to know what exactly it is and then start performing testing on the functionality. In other words knowing the functionality and testing the functionality happens simultaneously. Since

The TE explore the application for functional knowledge while they performing Testing on it this type of testing is know as exploratory testing.

13.USABILITY TESTING:

Definition: “It is the type of testing in which one can perform testing on an application to check whether it is User-friendly, apart from it has functional perfection”.

Note – It is to be noted that for every product apart from functionality, it must have usability so as to be absolute qualitative product.

14.FORCED ERROR TESTING:

Definition: “It is the type of negative testing in which the Test Engineer may give invalid input to the application and checks if the application validates it properly and also to check if the error message displayed is appropriate”.

15.END-TO-END TESTING:

Definition: “It is type of testing in which the Test Engineer usually performs full pledged transaction and checks if all the environmental components present in the system are active and operationally available to accomplish the transaction successfully”.

In other words, it is an Environmental Testing.

EG: Client Server, Application Server, Database Server

16.ACCESSABILITY TESTING:

Accessability is defined as the extension of usability to the disabled/handicapped, apart from normal use.

The US government has defined the check list under US Regulation Act, #508, to provide the accessibility factor to the software products to the disabled/handicapped.

Definition: “It is the type of testing in which one can perform testing on the application to check if the accessibility factor is incorporated in the application apart from the functionality and usability”.

17.MUTATION TESTING:

Definition: “It is the type of White box Testing in which original, initial version of a program will undergo several changes and when the changes are incorporated in it generating several versions of it. Each such changed version of a program, the program is known as Mutant. Since Mutants are involved in testing it is known as Mutation Testing”.

Apart from this as and when the new Mutant is generated it will produce new set of sample data with which the program can be tested.

18.RELIABILITY TESTING:

Definition: “It is the type of testing in which products are tested on the specified environments with normal as well as abnormal operations usually for longer durations(say 48-72hrs) just to ensure if the products are their operational perfection with stability”.

It is a type of testing in which one can perform testing on an application with normal as well as abnormal conditions for longer durations in order to ensure operational availability with out any performance degradation.

Reliability testing is also know as soak Testing.

19.SCALABILITY TESTING:

Definition: “It is the type of testing in which the application is tested with future scenarios (increasing the functionlity, number of users etc.,) just to check whether the application is scalable without performance degradation and without redesigning of the architecture and modification of the environment as far”.

20.SECURITYTESTING:

Security is defined as a mechanism that is employed against the application to protect the vital information from unauthorized access and treating agents like virus.

Definition: “It is the type of testing in which the Test Engineer perform various activities of the application and checks if the vital information is secure”.

Some of the Security Testing types are

i)LOG-IN SCREEN TESTING:

The Test Engineer with the Log-in screen checks if the valid user is able to access the vital information whereas the invalid user should not be able to do that.

ii)ILLEAGAL ACCESS WITH URL:

The Test Engineer tries to chexk if the web page can be accessed straight away with the URL without Log-In and ensures the security.

iii)FIRE WALL TESTING:

Firewall is the means of security mechanism which is usually employed against servers, the Test Engineer checks the firewall functionality and ensures it is working as per the protocol as defined for it, ultimately ensures security for the system.

Heuristic Testing:-

This is a type of testing in which one can perform testing on an application with specially prepared check list based on the past experience to make sure that the application Is working fine in all those areas also.

21.ADHOC TESTING:

Definition: “It is the type of testing in which random/free style testing is performed on an application without using the Test Case Document unlike formal testing, in order to cover the uncovered testable functional areas in the Test Case Document and to provide absolute coverage for the testing”.

Adhoc Testing in a way refines the Test Case Document by adding new Test Cases for the corresponding functionalities that are encountered as uncovered.

Note – It is always advisable for an organization to follow and implement both the practices of Normal Testing and Informal Testing i.e. Adhoc Testing.

WHEN DO YOU STOP TESTING?

Testing can be stopped in the following two types,

i)Successful Stopping ii)Unsuccessful Stopping

i)SUCCESSFUL STOPPING:

Usually the Test Engineer once they satisfy with their testing they can stop testing successfully. The Test Engineer once they complete formal testing as well as Adhoc Testing to provide 100% of coverage for testing and also once the quality policy is justified(apart from the justification of requirements, the addition of value), the Test Engineer can successfully stop testing.

80%+20%=100%

ii)UNSUCCSSFUL TESTING:

Once the module is developed it will be sent to the Test Engineer for the sake of testing. If much of the functionality is not available, it is not usable and hence it cannot be testable.

Note – However the testing is a never ending process as the ideal perfection cannot be attained.

HOW TO CARRY ON TESTING PROCESS WITH A STRATEGY?

In order to make sure that the product is associated with absolute quality, testing Department employed a systematic, scientific accomplishment of the testing task in terms of Software Testing Life Cycle (STLC).

-Test Planning -Test Designing / Development -Test Execution -Result Analysis -Bug Tracking -Reporting

1)TEST PLANNING:

a.Why Test Planning?

As the testing process is a costly practice it needs to be planned to provide effectivness, efficiency and optimization.

b.What Is Test Plan?

It is defined as the strategic document that describes how to carry on testing on an application affectively, efficiently with an utmost optimization to ensure qualitative outcome of testing and to make sure that the product is qualitative.

c.By Whom Testing Is Looked After?

The Test Plan Document is prepared either by Quality Lead or Quality Manager.

Project Plan which is prepared by Project Manager will be the Input Document / Base Document for the Test Plan Document.

Note – Test Case Document is a Project Level Document whereas the documents like Quality Policy Document, Test Process Document etc., are Organized Level Document.

d.Contents Of Test Plan?

The Test Plan Template contains the following fields so as that the specific information can be given to them depending upon the project,

-Objective / Scope of the Test Plan

-Areas of functionalities to be tested

-Areas of functionalities not to be tested

-Resource Planning

-Scheduling

-Test Strategy

-Test Deliverables

-Testing Terminology and Defect Metrics definition

-Areas of testing to be automated and are not to be automated

-Entry Criteria and Exit Criteria

-Evaluation of Automated Tools and the list of tools used for automation

-Risks and Contingency Plan

-Details of Approval Authority Information

2)TEST DESIGNING/TEST DEVELOPMENT :

This phase is meant for preparation of Test Case Document (TCD). The importance of Test Case Document is that it provides the following for the testing effort

i)                    Planning the Testing Activity ii)Organizing the Testing Activity iii)Estimating the Testing Activity

Either the Senior Test Engineer or the Test Engineer has to prepare the Test Case Document.

Template for Test Case Document:

-Test Objective / Scope:

This field contains the areas of the functionalities that are tested with the help of the Test Case Document. Also the limitation of the Test Case Document is mentioned here in terms of the Test Scope.

-Test Scenario:

This field contains the information of the situation in which the testing can be done. In other words, it describes the situation in which the Test Case Document can be executed to test the specific functionality.

-Test Procedure: The testing can be done on any specific functionality in three ways. As every functionality is associated with look and feel, positive behavior and negative behavior. It has to be tested with GUI testing, Positive testing and Negative testing with the help of GUI test cases, positive test cases and negative test cases respectively. Hence this strategy is adopted as a Test Procedure in almost all the organizations to test any functionality.

-Test Cases:

The Test Engineer can derive the number of GUI Test Cases, Positive Test Cases and number of Negative Test Cases with the help of functional knowledge of an application, guidelines for writing test cases, techniques that are used for creating the test cases etc., and format the entire test cases in a tabular format under the classification of GUI, Positive Negative respectively.

-Test Data:

It is defined as a set of sample data which is used where ever specific test cases are exucted to test specific functionality of an application.

Usually this test data will be made available in the Test Case Document interms of the Data Tables.

Note – The Test Data Tables are made available in the Test Case Document through the Hyperlinks provided in the Test Case itself for easy reference and access.

3)TEST EXECUTION:

This phase is meant for executing / implementing the test design. In other words the Test Case Document prepared in the previous phase is executed in this phase. While Test Execution the Test Engineer does the following activities

-Implementation / Execution of the Test Cases on the application window

-Observation of the responses of the application

-Not just observation, but recording/documenting the observations.

4)RESULT ANALYSIS:

Soon after test execution and the observation of the responses of the application, the Test Engineer will conclude the test results under the process known as Result Analysis. In this process the expected value matched, the test result is concluded as ''PASS'' and if they are mismatched the result is ''FAIL''. Hence the test result is always in terms of either pass or fail.

Expected Value: “It is defined as the expected behavior of an application. In other words it is the behavior that an application is supposed to have as per the requirements”.

Actual Value:

“It is defined as actual behavior of an application, in other words it is the behaviour actually executed by the application”.

5)BUG TRACKING:

Soon after the result analysis, all the field cases are considered to be the ''BUGS''. These Bugs are to be tracked in a separate document known as Defect Profile Document(DPD). Hence DPD is outcome of the Bug Tracking phase.

6)REPORTING:

In this phase, the DPD prepared in the previous phase will be sent/reported to the development team by the Test Engineer for the purpose of Defect Rectification. Also the Test Engineer prepares high level document known as Test Report Document(TRD) that can be sent to the High Level Management (HLL) / customer (if and only if required), inorder to let them know the status of testing and stability of functionality.

Test Case Design Document Model:

TestCase#	TestCase Description	Expected Value	Actual Value	Result	Severity	Priority	Reference

Test Case Number:

It is an unique Id for the test case in order to refer/access it easily, whenever the situation denies.

Test Case Description:

This field describes the activities that are to be carried on while testing is done. Usually the test cases must be drafted in terms of instructions rather than statements.

Expected Value: It is an expected behavior that should be detailed in this section , which is usually extracted from requirements.

Note – Usually be adopted before testing.

Actual Value: It is the actual behavior of an application that can be observed and recorded in this field while testing.

Result:

Depending upon matching or mismatching between the Expected Value and Actual Value the result is recorded in terms of 'PASS' or 'FAIL'.

Severity:

This field explains how important test case is.

Priority:

Depending on Severity it defines the sequence of execution of the test cases when there is a tight schedule.

Reference:

This field contains the information of usually Business Design Documents for each and every test case indicating when the test case is genuine/legal.

Result Analysis:

Pass or Fail depending upon the Expected Value and Actual Value.

Bug Tracking:

The defects in the program are identified.

Reporting:

The failed test cases are considered to be 'BUGS' and these Bugs must be tracked into the Defect Profile Document with the help of template which has the following fields in it

-Defect Number -Severity

-Defect Description -Priority

-Defect Submitter -Steps to be reproduced

-Data Submission -Assigned-to

-Module Name -Status

-Version Number

-Build Number

The defect information can be entered in terms of a record while giving the information for all the respective fields. Similarly the entire Defect Profile Document is prepared with multiple records of defect information.

Defect:

Every defect is maintained with unique Id for the sake of unique reference and easy access. This unique Id is known as Defect Number.

Defect Description:

With respect to log-in screen discussed above with the combination of valid User Name and a blank Password, the system allowed the user to the home page which is not supposed to.

Defect Submitter:

It is nothing but the Test Engineer's name who is involved in testing and who raised the defect.

Defect Submission:

Date on which defect is raised is noted here. Based on this date, a report can be generated in which one can view the number of defects date wise.

Module Name:

Name of the module on which testing is performed and defect is raised.

Steps To Be Reproduced:

These are nothing but guidelines prepared by Test Engineer for each and every defect that can be helpful for developer or anyone to locate , in other words reproduce the same defect.

Assigned-to: This field is filled with the respective developers name against each and every defect, usually by Project Manager under the process known as Defect Assignment.

ProjectName_ModuleName_DocumentName_VersionNo

Gmail_Members_TCD_1.0

Gmail_Members_TCD_1.0

Version Number:      10—10 crore, 20 --- 20 crore

Version is defined as an instance for creation.

If it is a first instance of creation it will be always acknowledged as Version # 1.0 and if it is modified / added with something new, it will be further recognized as Version # 2.0. Hence various versions are formed whenever something new is added to the previous version.

Version numbers can be associated with the products as well as the documents. While products can have decimal version numbering system depending upon the volume of the new functionality added, whereas documents are maintained with integer numbering system.

Build Number:

In the process of testing and defect rectification done by the testing team and development team many a times, a developed software is released for the sake of testing. The software in each such release is known as 'BUILD' and each release is identified with a unique number known as Build Number.

NOTE – It is always a best practice to continue build numbers irrespective of the new versions for the proper test metrics.

Severity:

Severity is basically defined as the expression which indicates the degree of seriousness of the defect.

In order to express the degree of seriousness, the severity has been classified into the following categories,

i)Fatal ii)Major iii)Minor iv)Suggestion

i) Fatal Defects : If at all the defects are associated with navigational blockages and non-availability of important features/objects/application windows are known as Fatal Defects.

Example:- 404 Page not Found Error, 500 Internal Server Error etc.,

Fatal Defect is being termed as Blocker, Show Stopper by various companies based upon their standards.

ii) Major Defects : If the defects are associated with wrong functionalities(wrong functionalies) such defects are known as Major Defects.

Example:- Wrong Calculations, Wrong Business Rule Implementation etc.,

iii)Minor Defects : In case the defects are associated with inconsistency, alignments, spelling issues and look & feel issues, such defects are known as Minor Defects.

These defects are also known as Cosmetic Defects.

Spelling mistakes, improper alignment of the objects, inconsistency among the objects(sizes/shapes) and also of the font type/size/style.

Look and feel issues(Microsoft Standards are not followed and Universal Standards are not followed).

iv)Suggestion : Strictly speaking, suggestion is not a defect. Infact it is a note given by testers to the developers in order to add value for the application.

Example:- Suggestion for the modification of Error Messages, Suggestion for the implementation of Microsoft GUI standards/Universal Standards.

* * ** * * * *

TRIAGE MEETING:

Whenever an ambitious /controversial situation arises between testers or developers, the Triage Team will be interacting with them conducting a special meeting to resolve the issue, this meeting is known as TRIAGE MEETING.

* * * * * * * *

Priority:

It is defined as an expression that defines the sequence for the defects to be rectified. In other words it is defined as a message or note by Test Engineer to indicate what are the defects to be considered first, next, last for the process of rectification.

In order to define the sequence for various severities, priority has been classified into the following categories,

i)Critical ii)High iii)Medium iv)Low which are by default will be always associated with Fatal, Major, Minor and Suggestion respectively. At some times depending upon situation, the priorities are customized as,

Case i) : High Severity and Low Priority

In case defects are associated with out of scope situation though they are fatal, they will be given least priority as they do not come under immediate delivery with respect to deadlines.

Case ii) : Low Severity and High Priority

Sometimes though the issues are of minor/suggestions, they are considered to be high prioritized defects as they are associated with implicit requirements of the customer which matters a lot from the point of customer satisfaction.

STATUS OF DEFECT

As the defect moves from testing team to development team and vice versa in the process of testing and defect rectification, as it is crossing several milestones, each time it attains specific state which can be expressed with specific expression known as 'STATUS'.

Precisely defect will have multiple stages known as 'BUG LIFE-CYCLE', which has the following statuses of defect,

a)NEW/OPEN:

When ever a defect is raised by the Test Engineer for the first time, he will always give the status as 'New/Open' indicating is raised afresh, is not yet dealt with developer.

b)FIXED FOR RECTIFICATION:

Once the developer accepts the defect, he will rectify it and once the defect is rectified, he will give the status to the defect as 'Fixed For Verification', indicating the defect is rectified and ready for verification.

c)CLOSED:

Once the Fixed for Verification is sent to Test Engineer, on verification, if the Test Engineer realised that the defect is really rectified by the developer, he will assign the status as 'Closed', indicating that this defect is not at all present in the product.

d)RE-OPEN: On verification the Test Engineer realizes that the defect is not really rectified properly, he will always assign the status as 'Re-Open', indicating that the defect is still there in the product inspite of developers effort for rectifying it.

e)HOLD:

When ever the defect is raised, that is associated with lack of information, usually such defects are not accepted by the developers. It is because with existing information, one can neither call it as defect nor not a defect. In this situation the developer assigns the status known as 'Hold'.

f)AS PER DESIGN:

In case the hasty implementation of the requirements without the intimation of Test Engineer there is always a possibility that the Expected Value will not match the Actual Value. Obviously, Test Engineer raises a defect which is not at all accepted by developer as the implementation is done as per the requirements of the customer. Hence he will assign the status known as 'As Per Design', indicating the functionality is as per the requirements.

g)TESTER'S ERROR:

In case the Test Engineer does not understand the requirement properly, hter is a possibility of creating wrong test case to perform wrong testing and there by result is wrong defect. These wrong defects are not accepted by the developer and he will assign a status known as 'Tester's Error', indicating testing is not done properly.

BUG REPORTING:

a)Build Release Process:

Soon after the developers develop the Source Code(SC) it will be checked into the Common Repository(it is the common storage place which can be shared by Project Team members) so that the Test Engineer can download the same in-terms of a 'BUILD' for the process of testing. This downloading process is called 'Check-Out'. Usually, when the Build is checked-in it will always be associated with a tag (name of the build is to identify the build uniquely, given as per the conventions of the company). This is how the Build in other words, Code Base is released to the Testing Team along with all required necessary documents such as Deployment Document etc.,

If it is a Client Server application, 'EXE' form is released and if it is a Web Server application, 'URL' will be supplied to the Test Engineer for testing.

b)BUG BASED REPORTING PROCESS:

Depending upon the way the Bugs are reported in an organization, it has been classified into three following three categories which are evolved pronologically, over a period of time.

i)Classic bug reporting Process:

In this process the Test Engineers create individual Defect Profile Document that are sent to the Quality Lead for the process of consolidation. The Quality consolidates (sump/combine all defects, elimination of duplication, assurance of information, evaluation of information etc,) into a single document which is sent to the Project Manager through an E-mail as an attachment.

The Project Manager receives the Defect Profile Document and accomplishes the defect assignment and sends the same to individual developers for them to carry on the defect rectification process.

Disadvantages/Drawbacks:

-No security for defect information

-Consolidation process, is a tedious process for the Quality Lead

-No provision for development team to look onto the status of the testing and defect information, while the testing is carried on

ii)Repository Based Bug Reporting Process:

In order to provide security for the defect information, Common Repository is introduced in an organization which plays important role in the Bug Reporting Process. As usual, the individual DPDs are collected by Quality Lead, consolidated into a single document and will not be sent as an attachment with an E-mail but is kept in the Common Repository. The same is intimated to Project Manager through an E-mail, eventually Project Manager logs into it, access it and performs defect assignment and the document is distributed among developers for rectification.

With this the security is maintained leaving rest of the drawbacks un-addressed.

c)Tool Based Bug Reporting Process:

In order to make the bug reporting process more effective and nullify all the above mentioned drawbacks, this process has been introduced in which bug tracking tool plays a vital role. As the Test Engineers raise the defects they will not prepare individual DPDs but they enter all the defects into the Common DPD (template provided by bug tracker which is made available in the Common Repository). Hence consolidation is done automatically and also the Project Manager can accomplish defect assignment process simultaneously. Not only that, the developers will be able to look into defect information while testing is carried on simultaneously. Hence this process is considered effective and optimized since all the drawbacks are nullified.

UNIT II – QUALITY STANDARDS

Quality Standards:

Quality Standards are defined as the guide lines for an organization in order to guide each and every task that is accomplished in an organization to ensure that the task is completed effectively, efficiently with an utmost optimization to produce qualitative outcome, ultimately to ensure quality product in the end.

Adhoc Process:

In case any organization is said to be following its own guidelines, these guidelines are known as Adhoc Process.

Usually the quality standards are prepared by the team of experts after careful evaluation and customization to the present trends of the industry. Hence it is not prepared by individuals, but by the group of experts. Every Quality Standard will have its own respective place of origin.

Assessment Process of an Organization:

The organization usually gets the certification provided it followed the respective guidelines and must be in the profile of matching with the criteria that is considered for certification. Once the organization attains this profile, they invite Assessment Team Member (ATM) for the sake of assessment and evaluation. Assessment Team provides a set of questions for which the answers must be provided by the organization. Based on the responses, the assessment reports are generated that will be sent to Assessment Authority Body via Assessment Team Leader(ATL). Once the green signal comes, the organization will be issued certificate which in turn provides recognition in the market which can be treated as a vital factor for the survival.

Quality Assuarance(QA) Implementation:

Quality implementation means, implementation of the system in such a way the respective roles involved in respective tasks must accomplish then by following the guidelines defined by the Quality Standards. In case Quality Assurance implementation is biased(partial implementation) there is every possibility for re-engineering that eventually affects the cost. Hence it is always a better practice for an organization to follow Quality Standards and to implement monitor and evaluation system for each and every phase of SDLC for qualitative project development.

TYPES OF QUALITY STANDARDS There are various types of Quality Standards available in the market to guide the organization so as to produce quality products, out of which the following are considered to be most wanted and widely used quality standards.

i)ISO Standards (9001:2000)

ISO = International Organization for Standardization

9001 = Quality number or Serial Number indicating the type of organization with specific objectives and responsibilities

2000 = Year in which the standards has been introduced

History of ISO Standards:

During British regime, they started encouraging the industries to produce quality products. In order to make them quality product they started giving a set of guidelines. With these guidelines the quality production was possible and the British Government started importing the quality products. Eventually the guidelines used by the industries has become ISO Standards that are followed by the organizations today in the market. Hence ISO Standards are considered to be European Standards as they are originated from Europe.

TYPES OF QUALITY STANDARDS

There are various types of quality standards in the market to guide the organization so as to produce quality products, out of which the following are considered to be most wanted and widely used quality standards.

i)ISO Standards ii)CMM Levels iii)Six Sigma Standards

1. ISO Standards:(9001:2000)

ISO = International Organization for Standardization

9001 – Quality number ot Serial number indicating the type of the organization with specific objectives and responsibilities

2000 – Year in which the standards has been introduced

History of ISO Standards

During British regime, they started encouraging the industries to produce quality products. In order to make them quality products, they started giving a set of guidelines. With these guidelines the quality production was possible and the British Government started importing the quality products. Eventually, the guidelines used by the industries has become ISO Standards that are followed by the organizations today in the market. Hence ISO Standards are considered to be European Standards as they are originated from Europe.

Types of ISO Standards:

Depending upon the objectives, responsibilities and the activities that are happened in an organization, the following types of ISO Standards zre classified. They are

        i.            ISO : 9000 ii) ISO : 9001 iii)ISO : 9002 iv) ISO : 9003 v) ISO : 9004

i)ISO:9000

In case a set of new 'MENU' like, non- detailed guidelines are followed by usually start-up companies or immetured companies in order to regularize their activities, such guidelines are said to be falling under ISO:9000 standards and the organizations if at all they are to be certified, they will be as certified as ISO:9000 Companies.

ii)ISO:9001

This type of standards has been defined with a set of guidelines that are capable of guiding the activities like planning/designing, production/development, testing, marketing , service and maintenance to ensure productivity in the work to assure quality product in the end. These guidelines are usually detailed once for guiding the the organization in an affective way. In case such full pledged organizations are to be certified, they are certified with ISO:9001.

iii)ISO:9002

This standard is defined with a set of guidelines that are capable of guiding almost all activities that of ISO:9001 except “planning'. For planning these organizations seek the help of ISO:9001 companies. Such companies fall under the category ISO:9002 and be certified accordingly.

iv)ISO:9003

It is defined with a set of guidelines that are capable of guiding the organizations where in there are only Testing and Quality Assurance activities, exclusively. Usually these companies are referred to as testing companies, they come under category ISO:9003 and can eb certified with accordingly.

v)ISO:9004

This standard is defined with guidelines that are used for guiding the organizations with exclusive responsibilities like Research & Development and continual improvements/refinements. Such Research oriented organisations are certified as ISO:9004 companies.

ISO standards in in a nutshell (precisely),

-ISO standards are defined in terms of different types whereas each type is unique and isolated from each other( that is the reason why a single organization can have multiple ISO certifications ).

-These standards are applicable for both IT and Non-IT industries

-On evaluation of the organizations, the conformation of the company profiles is done with the process known as 'Certification'.

2. CMM Levels:

Maturity of CMM

CMM standard is highly matured in guiding the organizations in such a way that it guides the smallest tasks with the appropriate process to ensure proper accomplishment of the task and consequently to assure quality production.

'Process' is defined as the frame work that can guide smallest task to be accomplished effectively, efficiently with an utmost optimization to produce qualitative outcome.

History of CMM

A group of University students in United States formed an organization SEI (Software Engineering Institute) and did research on maturity of the organizations, ultimately developed a five level model known as CMM (Capability Maturity Model). Hence this model sometimes referred to as SEI-CMM..

Levels of CMM:

i)Initial Level:

This level of CMM is defined with the following guidelines in order to guide initial, tart-up and immetured organizations in order to refine and regularize their activities

-Companies can follow their own guidelines

-These companies must have a strong team

Though they are allowed to follow their own guidelines if the team is strong, it ensures proper accomplishment of the task. Such organizations fall under Initial Level and are assessed as CMM-1 companies.

ii)Repeatable Level:

This level of CMM defines the following guidelines to ensure every task that is accomplished is proper and also the important tasks are done productively and profitably without re-investment of resources like time, money and effort.

-Every task must be guided properly with appropriate set of instructions

-The key processes must be repeatable

Such organizations fall under Repetitive Level and are assessed as CMM-2 companies.

iii)Defined Level:

This level is defined with the following guidelines,

a) Objective Evidence(Every task must have a goal or purpose and the evidence is always associated with result of the task).

b) All the guidelines must be followed without any bias(When ever a role performs a specific task, it must be always accomplished with a specific guidelines without any reservation).

c) All the tasks must be documented (This guidelines help the organization to get into practice of recording of the activities that are happening in terms of documentation. Documentation has the advantage that one can assess the past or present from it and be productive and optimized for the future).

The organizations which follow the above guidelines fall under the category defined and be assessed as CMM-3 level companies.

iv)Managed Level:

This level defines the guidelines for 'Metrics' apart from guidelines for all the optimized procedures that happen in the previous levels.

METRICS – is considered to be the science of measurement and is defined as quantification of the objective criteria. It basically measures/quantifies a specific task to have clarity over it to evaluate if the task os profitable and productive so as to ensure quality production in the end.

In case any organization follows Metrics that will come under Managed Level and be assessed with CMM-4.

v)Optimized Level:

This level is defined with the guidelines for Research and Development, and continual improvement activities apart from all the rest of the activities that are happening in an organization. Such companies fall under Optimized level and are assessed as CMM-5 companies.

CMMi – Level companies not only focus on qualitative Software production but also they ensure qualitative Hardware for doing it.

Where 'i' stands for Integration.

CMMP or PCMM – This level companies focus upon the factor PEOPLE. They think that if the people are happy, they do productive work which in turn provides quality to the product. Hence, usually lots of benefits are provided for people in such organizations.

About CMM in a Nut-shell,

-CMM standards are defined in terms of various levels ( a single organization cannot have multiple assessments of CMM)

-As of now, CMM is only applicable for IT industries

-After evaluation, the organizations are assessed but not certified.

3.SIX SIGMA STANDARDS:

Precisely, nature of Six Sigma can be understood interms of the following factors,

i)Multiple Cycles of Production:

Six Sigma implementation is associated with repetitive multiple cycles of production. This repetitive production though its costly affair, is performed for sake of refinement of the process so as to produce the absolute qualitative product in the end.

ii)Graph Paged Implementation:

As the multiple cycles of production go soon for each production there will be statistical information about the product with which Average and Standard Deviation are calculated. With the help of these values a point can be plotted on the graph. Hence, with the multiple cycles of production, multiple points are generated which eventually develops the graph. So this process deals with the plotting of the graph simultaneously as the implementation goes on. Hence, this process is also known to be as Graph Paged/Graph Orientation Implementation.

From the Graph, the following points are observed,

a) One can understand the level of quality maintained at a specific level of production.

b)One can understand when to stop production with respect to Threshold value.

Six-Sigma Life Cycle:

In order to implement Six Sigma process affectively in an organization, usually it adopts a scientific procedure known as Six Sigma Life Cycle which has the following phases in it.

i)Define ii)Measure iii)Analyze iv)Improve v)Verify

i)Define:

Initially before production, in this phase one will define the targets for production. In other words, the bench marks and expected results are defined in this phase. Once the targets are defined, the initial production cycle begins.

ii)Measure:

This phase is meant for measuring the products. In other words, the production that is happened in the Define phase must be carefully checked for the defined requirements if they are really justified in the product.

Once measurement is done, one can realize that the product is deviated with respect to some requirements.

iii)Analyse:

This phase is meant for analyzing the deviation occurred. In other words, one can find out root causes for deviation to happen in the production.

iv)Improve:

After the careful analysis, the production process has to be modified in such a way that mistakes done in the previous process are eliminated in the previous refined process with which the next production is supposed to be relatively refined and qualitative.

v)Verify:

Once the production is done with refined process, one has to verify the latest production for the following aspects.

        i.            To check if the refined process has to got any effect in terms of refinement of the production

      ii.            To check of the product justifies the basic requirements

As the Six Sigma implementation goes on with the Six Sigma Life Cycle and multiple cycles of production goes on, simultaneously the graph is plotted with Average and Standard Deviation calculated in each and every production. As the production continues, refinement is increased simultaneously, the graph is modified in such a way that the two legs of graph travel towards each other. When graph is spanned over six units on X-axis, one can stop the production without any hesitation as the equivalent quality is 99.73%, which is almost 100%.

Since graph stands over six units for 100%, known as Six Sigma Graph and the standards are referred to as Six Sigma Standards.

Six Sigma equivalent in Software production is 3.4 DPMO (Defects Per Million Opportunities). In other words, only 3.4 defects must be present with one million opportunities/possibilities of testing the product. Hence practically this is equal to 0% defect free, in other words, 100% quality.

Advantages of Quality Standards:

a)Transparency:-

As the companies follow quality standards, the quality standards proposed in Common Repository for the industry so that the information can be transparent between Roles as well as Departments causing the tasks accomplished with much productivity which inturn leads to quality production.

b)Discipline:

The quality standards followed in the industry will insist the specific roles to do the specific assigned tasks only as per the schedule without any slippages. Hence, discipline can be understood in terms of specific tasks accomplished by specific roles within the specific deadlines. Hence quality standards in a way establish discipline in the organization.

c)Customer Satisfaction and Customer Complaints:

With the transparency and discipline increase in the organization, the end result will be always qualitative which neediness to say gives satisfaction to the customer.

With increased customer satisfaction the tendency of complaints from customer is drastically reduced.

d)Every Stage gets Optimized:

The quality standards makes each and every stage / milestone optimized. In other words they always try to reduce the input for the task in terms of effort, money and time. And at the same time maximized the output for each and every task in each and every task. Hence, optimization is achieved to the best with quality standards implementation.

e)Re-Engineering:

Because of quality standards right from the beginning, all the phases are guided properly there is a less possibility for re-doing the work. Hence the re-engineering is drastically reduced as a result of quality standards.

Test Engineer's Characteristics:

1. Quality oriented mind setup

2. Test-to-Break attitude

3. Tactful and diplomatic nature

4. Must have good Communication skills and Drafting skills

5. Must be creative and must have the ability to ensure the application intruture

6. If having programming knowledge, it is a plus, but not a mandatory. However must have Internal Structural Knowledge (ISK) i.e., Design and Environmental

7. Must have good judgement skills i) Severity and Priority Judgement ii)Judgement call

Judgement Call – It is defined as an attitude of being initiative to start the work without anybody telling for the good of the organization especially to say the resources like time, money and effort. Such nature of the role is appreciated and encouraged by the industry and ultimately it will be acknowledged that in turn helps the role to grow in the organization on all aspects.

Ways of Testing:

Testing can be carried out in the following two ways depending upon how it is carried over,

i)Manual Testing:

It is defined as the way of testing in which one can carry on the tasks of SDLC like Test Planning, Test Design, Test Execution, Result Analysis, Bug Tracking and Reporting manually with the investment of manual effort.

Drawbacks:

1. More man power is required.

2. More time consuming

3. More tedious process

4. Actions cannot be done simultaneously done

5. Human Errors

6.Testing effort cannot be repeated easily

ii)Automated Testing:

It is another way of testing in which the drawbacks of Manual Testing are addressed and nullified effectively, speed and accuracy are provided for the existing testing system.

Usually Automated testing is done bt an agent known as the Automated Tool.

Advantages:

1. V-Users

2. Tool is a software component and reduces time

3. Not a tedious process

4. Rendezvous (ren-de-vu=meeting point) actions are done simultaneously

5. Tool has recording mechanism and by which testing can be repeated easily any number of times

6. No chance of human errors, as it is done by the system (software + hardware)

Note – Automation Testing is not replacement for Manual Testing. In fact manual testing is mandatory and done first on application, then only Automation testing can follow.

Areas where Automation testing can be Applied ?

a. The areas where in tedious and complex tasks are present and wherever there is scope of time consumption for such activities Automated Testing can be applied.

b.Wherever there is a need for repetitive testing for several times, that is where Automation Testing is used(Regression Testing)

c.Whenever Load testing, Performance testing and Stress testing is to be conducted, the Automated Tools can be used

d. As for as test management is concerned, the activities like documentation can be automated by providing the corresponding readymade template

Disadvantages:

a. The automated tools are quite expensive that only few companies can afford to buy it.

b. In order to operate tools successively and proper implementation of the tool, perfect expertization is required (professionals are required)

c. If automation is not done properly there is every risk that it consumes multiple time zones of manual testing time

d. It has a limitation that it cannot cover all the aspects of an application from the point of testing(several tools are to be purchased for several features to be tested which is a costly affair)

************

UNIT III - TERMINOLOGY

1. Defect Product:

Definition: “In case in any product there is a non-conformancy(one or more requirements are not defined) and if they are functionally OK(though some requirements are not justified, functionality is not affected) these products are referred to as Defect Products”.

Defect Products are used by customers as the functionality is available though they are non-conformanced to the requirements.

2. Defective Products:

Definition: “The products in which non-conformancy is present and the presence of defect is so severe that the functionality is affected, such products are known as Defective Products.

Customers will never use the Defective Products.

3. Quality Assurance(QA):

Definition: “It is the process in which Roles and their responsibilities are guided as well as monitored in order to make sure that the responsibilities/tasks are accomplished as per the guidelines provided by Quality Standards, to ensure proper accomplishment and to assure quality in the end”.

4. Quality Control:

Definition: “It is defined as the process in which audits and inspections are performed on the Roles, Departments and their responsibilities to segregate bad process from the good one, ultimately to control quality of the product”.

Note - Testing is a validation process that checks the product. Quality Control is also the process of checking that is connected with product as well as process. Hence Testing belongs to Quality Control rather than Quality Assurance.

5. Inspection:

Definition: “It is the process of checking conducted on the Roles, departments and responsibilities without any prior intimation”.

Inspection process may question the Roles for which the Roles must submit the answers in terms of several details. Inspection process ultimately prepares an Inspection Report that can be submitted to the high level management to let them know the status.

6.Audits:

Definition: “It is also a process of checking conducted on Roles and Departments with prior intimation well in advance so that the respective Roles are ready with the required information”.

Usually Audits are done in the following two ways,

6.1. Internal Audits:

Definition: “It is the type of Audit done by internal Quality Control professionals and the Audit Report prepared by them us sent to the high level management”.

6.2. External Audits:

Definition: “It is the type of Audit done by Quality Control professionals to evaluate the status of the company and the Audit Reports usually used for external purposes like certification etc.,”.

7. Process Violation:

Definition: “It is defined as an act of violation/dis-obeying the process guidelines defined by the Quality Standards for the organization”.

8. Non-Conformancy Raised(NCR):

Definition: “It is defined as a penalty for the Roles who are found violating the process”.

It is not advisable for any Role to get NCRs in his 'tenure'.

9. Corrective Action:

Definition: “It is the process in which mistakes that are associated with the process are repaired /corrected”.

10. Preventive Action:

Definition: “It is the process in which due to irreparable mistakes, the Roles who are involved in respective responsibilities are considered for quality process oriented training sessions to give them awareness and the education not to repeat such mistakes in future”.

11. Slippage:

Definition: “It is defined as the extra time that is consumed by a specific task when compared to the plan time”. Mathematically,

Slippage = Actual Time - Plan Time (provided AT > PT)

Slippage has a Positive value.

12. Software Confirmation Management(SCM):

Definition: “It is basically a mechanism or a process that can manage the requirement changes that keep coming from the customer for the implementation”.

Software Configuration Management is effectively administered with the help of the following factors,

12.1 Change Control:

Definition: “It is the process in which the change requirements that are implemented in the product will also be updated and documented in the respective documents”.

In other words, when ever a product is modified, the modified information has to be reflected in the respective documents.

The purpose of Change Control is to ensure that the documents are in sync with the product at any point of time.

12.2 Version Control:

Definition: “It is the process in which naming convention and version numbers are defined for the change documents”.

The purpose of Version Control is to maintain the changed information chronologically and systematically so that any version document can be identified and access them easily and quickly.

13. Management Representative Management(MRM):

Definition: “It is basically a meeting in which usually Head Of Operations (HOO) will address the employees to discuss the status of the company”.

The following things are discussed in the Management Representative Meeting,

a) Growth rate of the company both in strength and technology.

b) Financial status of the company

c) Projects that are in 'pipeline'

d) Internal Audit reports

e) Customers appreciations and complaints

f) HR and technical issues

g) Individual achievements recognition

14. Periodic Project Meeting(PPM):

Definition: “This is basically a meeting conducted with Head Of Operations(HOO) and Project team with an intension to discuss the status of the project and is conducted periodically and hence known as Periodic Project Meeting”.

The following things are discussed in the Periodic Project Meeting (PPM),

a) The percentage completion and percentage incompletion of the project

b) The details of the responsibilities accomplished, Roles involved and the scheduling

c) The Slippages if at all any and the causes for it

d) The total number of defects raised in the case of testing and defect metrics

e) HR and technical issues

f) Individual achievements acknowledgement

15. Periodic Project Management(PPM):

Definition: “It is defined as a document basically prepared by Quality Lead (on behalf of Testing team) or by Project Manager (on behalf of Development team) with all the project status information like responsibilities, roles involved, task schedule details, slippage/variants information and the productivity details, and is sent to 'HOO' well in advance to let him know the status of the project”.

16. Matrix:

Definition: “It is basically defined as the process in which if at all any ambiguity/controversy comes with respect to any point of information, the Role must be able to trace back to all the relevant base documents to show the proof with them since it is traced back to the 'parent documents'”.

Matrix is also referred to as 'Cross Reference Matrix'

In other words, the main purpose of the matrix is to ensure sync with respect to the information and is made available in the same way in several documents.

17. Bench Mark:

Definition: “It is defined as the standards against which things are compared in the process of determination of the quality”.

18. Proto Type:

Definition: “It is defined as the rapidly developed model of the project that is prepared in the initial stages itself to demonstrate to the customer”, for the following purposes,

a) To finalize/freeze the requirements

b) To show that this is how it will look like in the future (preview)

c) To win confidence and credibility of the customer

19. Release:

Definition: “It is the process in which the development module is sent to the testing department for the sake of testing and this process is known as Release”.

20. Delivery:

Definition: “Once the product is tested, it will be certified and is sent to the customer for the sake of testing. This sending process is known as Delivery”.

21. Software Release Note(SRN):

Definition: “It is basically a document prepared by Project Manager and is sent to the testing department along with the module release”.

The Software Release Note contains known issues, useful information for testing and test data.

Note – Test Data basically has to be prepared by the Test Engineer and sometimes it may be provided by Software Quality Manager / Project Manager or even by the Customer.

22. Software Delivery Note(SDN):

Definition: “It is basically a document prepared by Quality Lead and is sent from testing department to customer along with the product delivered”.

The Software Delivery Note contains known issues and some useful information for the usage of the product.

23. Review:

Definition: “It is defined as the process in which depending upon the Role involved and the objective with which it is carried on, either 'study' or 'checking' usually happens on the documents”.

24. Review Report:

Definition: “It is basically a document prepared by the reviewer (Test Engineer) as an outcome of the Review process”.

The Review Report document contains either the set of questions for which clarifications are required or the review comments and suggestions like dos and nos depending upon the role involved and the objective with which the review is done.

25. Peer Review:

Definition: “It is defined as the process in which the authors exchange their documents for the sake of review in order to refine the documents ultimately”.

26. Walk Through:

Definition: “It is the process in which documents or the accomplished work will undergo a brief study”.

In other words, one can walk through the documents in order to have a overall idea about the information present in the documents.

27. Code Walk Through:

Definition: “It is defined as the process in which Source Code Document is checked for coding standards if they are really justified in the document”.

28. Code Review:

Definition: “It is the process in which a logic of the Source Code Document, program parameters like conditions, branching and preparative parameters are checked”.

29. Code Optimization:

Definition: “It is the process in which the number of lines of code and the complexity of code are decreased in order to increase the performance tremendously”.

This process is referred to as 'Fine Tuning'.

30. Change Request:

Definition: “It is an official / formal procedure in which the proposed changes with respect to requirements are sent by the customers to the development team”.

31. Impact Analysis:

Definition: “It is the process of analysis done by the Project Manager to determine the impact on the already developed project in case the proposed Change Request is accepted and implemented at the point of time”.

If the impact is more over the threshold value, the Change Request is mostly not accepted at the point of time and if the impact is lesser than the threshold value, the Change Request can be accepted.

32. Work Around:

Definition: “It is defined as an alternative solution for any role whose work flow is obstructed due to some reason  in order to keep going further and complete the work some how”.

33. Hard Coding:

Definition: “It is defined as the presence of constant values in the program that takes away the dynamic nature of it and allows the program to exhibit always a constant nature inspite of the dynamic inputs”.

The Test Engineer must be sensitive towards Hard Coding issues and make sure that these defects are rectified as soon as possible as they are usually considered as Fatal Defects.

34. Share Point / Visual Source Space(VSS) / Control Version System(CVS):

These are the tools which are frequently used by the organizations for the following two purposes,

-As a Common Repository

These tools are capable of creating the storage place for the project information that can be commonly shared among the project team members. These tools will provide a systematic software structure that allows the user to create several folders in order to keep the respective information.

-As Software Configuration Management Tools(SCM): These tools are used for implementing SCM tool automatically in such a way that when ever modification happens, unique version numbers are created for the documents for easy and quick reference.

35. Check-In:

Definition: “It is the process in which the authors soon after creation of documents, they are uploaded to the Common Repository so as to make them available for the relevant project team members”.

36. Check-Out:

Definition: “It is the process in which the author downloads the documents (removes from Common Repository and moves the same to the local machine) for the sake of modification”.

37. Baseline:

Definition: “It is defined as the process in which the author explicitly intimate all other relevant users through some notation indicating the preparation of the documentation is completed and the information in the document is finalized”.

38. Published:

Definition: “It is the process in which the base lined documents are officially made available for the relevant users so that they can make use of the information for their further use”.

39. Demo(Demonstration):

Definition: “It is a short form of Demonstration, in which some information or the developed functionalities are exhibited for the sake of understanding as well as acceptance”.

These Demos are basically conducted in two ways. They are,

39.1 Internal Demo:

In this process, the information will be displayed to project team members as a knowledge sharing process in order to be productive for the upcoming project activities.

39.2 External Demo:

These are usually conducted in order to display to customer's representative/customer for the sake of the acceptance and conformation.

40.Patch:

When ever the relevant build is observed as untestable due to the non-availability of most functionality, it will be rejected back to the development team. The developers fix the build in such a way that the untestable build is made testable. Hence the process in which the untestable build is made testable in a short span of time is known as a 'Patch'.

Build with a Patch is usually released to the testing department with the same build number.

*****