ETL Real time testing

Source table :
Empno, Ename,sal ,hiredate comm. deptno
101 sarath 1000 12-jun-2011 100 10
102 sarath 3000 12-jun-2011 100 40
103 sarath 2000 12-jun-2011 100 30
104 sarath 5000 12-jun-2011 100 20
105 sarath 5000 12-jun-2011 100 30
106 sarath 7000 12-jun-2011 100 20

Source table2:
Empno, Ename, sal ,hiredate comm. Deptno state
101 sarath 1000 12-jun-2011 100 10 ap
102 sarath 3000 12-jun-2011 100 40 ap
103 sarath 1000 12-jun-2011 100 40 Tn
104 sarath 3000 12-jun-2011 100 50 kan
105 sarath 5000 12-jun-2011 100 30 ap
106 sarath 6000 12-jun-2011 100 10 kan

Logic
1)Both table Common data
2)state equal to AP
Dev team data loading from source to target they are using etl tool

Target table output:
Empno, Ename, sal ,hiredate comm. Deptno state
101 sarath 1000 12-jun-2011 100 10 ap
102 sarath 3000 12-jun-2011 100 40 ap
105 sarath 5000 12-jun-2011 100 30 ap
testing team validate the data.
data is properly loading into source to target

In real time we prepare test case first of all.small exmaple i will say how we will test .

source
empno,ename
100,satish
101,ravi
102,keerthi
103,laxmi,
104, jsuri
105,nikith
target
empno,ename
100,satish
101,ravi
102,keerthi
103,laxmi,
104, jsuri
105,nikith
we will write maximum sql queries whether data populated correctly or not.
first we will check all records are load or not(we will use count(*) for both table
2.select * from source minus select * from target.
in this query it will display any missed records from source
3. select * from target minus select * from source
in this query it will display any missed records from target.

4. select * from source where empno is null;
4.select * from source where ename is null;

5.select * from target where empno is null;
5. select * from target where ename is null;


6.if they are using any joins then we will join those tables and we will check..

7.if we want to find any duplicate records are correctly getting then we have to write a query and check the data. in this way we have to prepare sql queris for each and everything.

we don’t use any tools for this. we will write sql queries.we will upload all test cases
in qc.

what we have executed by sql we will prepare in excel sheet.

1.prepare the test plan (team lead or teat analyst)
2 based on test plan .we are prepare the test cases(excel sheet or Qc depends on the client) our test case should be cover the business requirements.
3.once test case are completed we are validated the business logic(business logic should be covered our testcases)

4. we are validate the data here we are using(TOAD) OR direct databases(oracle, teradata)

validate data means: our sql queries executions in database or TOAD 

Software Testing:

 Technical Factors:

1.       Meet the customer requirements.

2.       Meet the customer Expectations.

Non-Technical Factors:

1.       Time to Release.

2.       Cost of Purchase.

SDLC[Software Development Life Cycle]:

BA { Information Gathering} BRs & Urs & CRs

                           |

SA { Analysis } SRs

                  |

Architcture{ Designing } Prototype [HLD, LLD]

                |

Developer{ Coding} Build

              |

     Testing

             |

Releasing& Maintanance

BRS(Business Requirement Specification):--

Business Requiremnt Specification defines the requirement of the customer to be developed on a new Software.

       In the face of “ BRS” Business Analyst(BA) can Involved.[What to Develop]

Functional:- Requirement to Be Developed.

System :- Software to be used.

It is a non technical document is known as BRS & CRS & URS.

SRS[Software Requirement Specification]:--

          It Defines Functional Requirements to be Developed and Software requirements to be used.[How to Develop]

Review:- Correctness and Completeness:

It is a static testing technic to follow the responsibility document and responsbility technics.

BRD[Business Requirement Document]

DFD&UM:-[Data Flow Diagrams]

Prototype:-A Sample Model and Application without functionality is called Prototype.

    Ex:- Power point, Slide Show

Snap Shots:-

DDT/FRS: Data Design Table, Functional Requirement Specification.

Designing :

HLD means High Level Designing: It Defines Architectural Designing of a functionality. It is a front End Designing & Back End Designing

LLD(Low Level Designing): It defines every part of the module such as sub modules and Sub-Sub Modules or Link Pages.

It is a module designing & Program Designing.

High Level Designing is Known as External Designing

Low Level Designig is Known as Internal Designing.

Coding: It is a Programming Level Process Developer can Involve.

White Box Testing:It is a coding Level testing technic which Person developed build that person can test the build it known as White Box Testing.It known as Glass Box Testing,Clear Box Testing,Structural Testing.[It is also Known as Unit Testing[UT]]

Build:Finally Integrate all the modules that set of modules known as Build.

White Box Testing is a Logic Oriented.

Black Box Testing: It is a build Level testing.In this Testing Software testing People can Involved.

Releasing & Maintanance: After Completion of all the testing technics project Manager conducting the releasing team.In the Face of releasing team they are using some observation technics and release the build.

[Those  Peoples observe the Softwares it is working correct or not. It is working Properly it is released]

Software Development Models:

Types of Models:

1.       Water Falls Model

2.       Incriments Model

3.       Proto Type Model

4.       Rapid Model

5.       Spiral Model

6.       V Model Development.

1.Water Falls Model:

 Classification of Water Fall:--

              Requiremnets

                      |

            Analysis

                  |

            Design

                  |

           Coding

               |

        Testing

             |

Maintenance

It is a common Popular model and most of the projects can be do by using this model.This Model give importance for repairing the documents.

Advantages:    

1.       Simple Model

2.       Transparency

This System is very open.If there are many mistakes or bugs in the above steps it will be comes below.

DisAdvantages:New Changes or extra requirements cannot be accept in the middle.

This model can use small and medium Scale organisations.

V Model Development:

“V” stands for Verification & Validation.This model Defines mapping between the development process and testing process.

UAT-User Acceptance Testing.

“V Model”:-  It is Expensive for small and middle scale organisations.Due to this reason small and middle scale organisations are not maintain the “V” Model.In the face of “ V” model development team and testing team requires more man Power.Large Scale industries anly can maintain the “V” Model.

Advantages:-1. It is Better Quality[As a verification valid or ensure and test management Process are take care, the output of the V Model is a Quality Product.

Dis advantages:

1. Time Consuming

2.Expensive

Test Management Documentation:

            Test Policy

                     |

            Test Strategy

            |

Test Methodology

          |

   Test Plan

          |

Test Case

        |

Test Procedure

       |

Test Script

        |

Test Log

       |

Defect Report

Document:- In every company Management will prepare the work process this is called a document. In the core companies they prepare the Production document.[Core Companies means Steel, Textile, Chemical etc non-technical companies.]

The Software companies also developed the document Such as Service Level document or Project level document.This document follows the “IEEE”[Institute of Electrical and Electronics Engineers]. Norms.In the document the main object is “what to Test”, “How to Test”,” Who to Test”, “When to Test”.

Test Policy: Every Organisation will have their Own policies.Just like that for Every organisation the testing team or the development team will follows some rules and regulations related with the testing process.

Testing Policy Format:

Address  of the Organisation:----

Testing Definition:--- Verification and Validation----

Testing Procedure:---- Prepare Planning Before Starting

Testing

Testing Standards:- One Defect Per 250 Lines of Code or Ten Functional Points.

Testing Maintanance:- QAM,TMM,PCM

[QAM: Quality Assurance Measurement.]

[TMM: Test Management Measurement]

[PCM: Process Capability Management]

Loc: Lines of Code

FP: Functional Point[ No. of Screens or Pages or Forms]

                               TEST STRATEGY

Test Strategy is developed by Quality manager or Quality Analyst or Project Manager.This Documentation Approach is two follow the components.It is a Company Level Document.

1.       Scope & Object: Need of Testing in Organisation.

2.       Business Issues: Business Issues declare the Project cost or Budget control.[65% development team 35% testing team]

3.       Testing Approaches: Test Responsibility matrix[TRM] defines mapping between Development stages and Testing Stages.

4.       Test Environment:Specified Requirement document to be prepared during the testing by testing team.[Methodologies test scripts, test case,test log,procedures and defect report]

5.       Roles& Responsibilities: The name of the job in Testing team and their responsibilities.

6.       Communication and Status Reporting: Communication  between testing team and development team during execution should be good.

7.       TEST AUTO MACHINE AND TESTING TOOL: Purpose of Auto machine during test execution Availability of Testing Tools in our Organisations.

8.       Testing Measurements: QAM, TMM, PCM

9.       Defect Reporting And Tracking: Understanding of the navigation between testing team and Development team at the time of bug fixing.

10.   Risk and Mitigations:In the face of Testing Problems risk during and solving to Overcome.[Mitigation Means all Health Problems]

11.   Change and Configuration Management: In the Testing Face the sudden changes of the Customer Requirements during Testing and Maintenance.

12.   Training and Planning: Whenever you start the testing process require persons training should be given.

                                     TEST METHODOLOGY

In this refinement form of the Strategy and it was developed by Quality Analyst.For on Going Project Testing to Developed.A Testing Methodology for current Project QA is Follows below Process.It is a project level Document.

1.       Accurance Testing Strategy Document: Need of Correct Persons to be Maintain.

2.       Determine the Project Type: Depends on Project Type P.M can Discuss and Delete Unwanted Matters from TRM.

3.       Determine the Project Requirement: Deleting the Unwanted rows.

4.       Identify the Scope of the Project: Adding the expected features.

5.       Identify technical Risks: Depending on Analysing risks PM and QA delete Some of the Selected factors in TRM.

EX: Testing Factor = 30(Total factors) -10 20 +2

Finalising TRM of Current Project.

Preparing the Module test Plan.

                                       TEST PLAN

Test Plan is a Organisation level Document.It Describe the Old details about theProjects.

Test Plan Prepared By the test lead.Test Plan Document Prepared in “IEEE”Format.

There are two types of Test Plans one is the:1.Master Test Plan (or) System Test Plan

                                                                       2.Module Test Plan.

1.Master Test Plan: It defines the overview of complete Software System from Testing Point of View .

The Master test Plan helps to Understand the architecture of Projects with High level design documents.

2Module Test Plan: It defines the individual components of the complete Software System.

Test Case are for individual components from Functional requirement Specification that is called “FRS”.

How to Prepare the Test Plan:-

Input                                             Process                                    Output

SRS ------------>       Team Information---------------------> Master Test Plan

Project Modules---------> Time Availability----------à  ModuleTest Plan

1.Introduction:- Object of the Project.

2. BackGround: Explain the technology

                        Ex: Front End And Back end involved within the Project.

3Test Items: Names of Modules, Functions,Services etc

4Features To Be Tested: What type of features to be tested.

5. Features not to be Tested :--

6. Approaches:- Selected technic testings to be Application Modules[TRM].

7. Testing Levels :-Sanity Testing ,Boundary Level Testing, Functional Testing, Regration Testing, Performing Testing, Security Testing.

8.Features Pass or Fail Criteria: When Modules are pass, when modules are Fail

9. Suspensive Criteria: Company will Follow some Standards.

            Ex: More than three bugs in a build test can Suspension Build.

10. Test Environment: Require Software and Hardware include Testing Tool also.

11. Test Delevariables: Require Testing Document to be Prepared.

                  Ex: Test Case, Test Procedure, Auto machine test Log etc

12.Schedule Tasks: It is a well Planned time table for all achives with in Testing Team.

13. Staff Training: Identify the training need for the team members.Prepare all resources for technology updations.

14. Risks and Mitications: Possible general problems raise during at the time of testing and solving overcome than [sick and general holiday]

15.Approvals: Sign all team managers[Higher officials] & Test Plan Authors.

Master Test Plan it Describes entire Build

Modular Test Plan it Describes Entire Module.

                                                TEST CASE or TEST DESIGN

After completion of tests plan test Engineers are Prepared the test cases.The MainIntension of the test case test Engineers are follow the three functional Methods.

1.       Business Logic Based Test Case Design.

2.       Input Domain Based Test Case Design

3.       User Interface Based Test Case Design.[GUI]

Note: All test cases are to be prepared from usecase and test scenarios[page by page or Documentation]

Test Case Format: In the face of test case format to be prepared by test Engineers.It is in “IEEE” Format.

Format:

Test Case ID: It is in Unique number or Unique Name.

2.Test Name: The name of the test condition.

3. Features suit ID:Name of the Module.

4. Test Suit ID: Name of the Batch(group of number)

5.Priority: The importance of the test case with respectable functionality(low,medium,high)

6. High Priority:(P) “P0” basic functionality Problems.

        Ex: “Page Cannot Open”

7 . General or Medium Functionality “P1”:Ex: Only UpperCase willaccept that is only accept but lower case also accept.This Type of problems medium priority “P1”

8 . Low Functionality (P2):Graphical Points are user InterfacePoints.

Ex: Font size, Colour,Alignment etc-

9.Test Environment:- Required Hardware and Software at the time of execution is suitable or not.

10.Test Effort: No.Of Persons or Hours to be worked on the Project (or) test case.

Ex: 20 mins average time to be execute for one test case.It is” ISO Standards”

[ISO-International Standard Organisation]

11.Test Duration: Date and Time[When you will execute test case after receiving build]

12. Test Setup: Necessary task to do before starting Test case Execution.

13.Test Procedure: Step By Step Procedure test execute the Test Case.

14. Test Case Pass(or) Fail: When this case is Pass, when this case is fail.

A login Process allows user Id and Password and OK Button.

User Id: Allows all Alphabetical in lower case from”4 to 16” characters length.It is Passed.

Login Password: It is allowed numeric values,”0 to 9 “ from 4 to 8  characters length.

Test Case 1:-

Boundary Values                                     Boundary Value of “User ID”

BVA(Size)                                                      ECP(TYPE)

Min------4------Pass                                   Valid                  Invalid

Max---16-----Pass                                     “a-z”                   A-Z

Min-1----3---Fail                                                             0-9 Any Other

Min+1---5—Pass                                                            Characters or Blanks

Max-1---15---Pass

Max+1---17—Fail

Boundary value of” Password”

BVA(Size)                                                      ECP(Type)

Min----4---Pass                                               Valid                  Invalid

Max----8----Pass                                               0—9                A-Z,a-z any other special characters

Min-1—3—Fail

Min+1—5—Pass

Max-1 – 7 ---Pass

Max+1 –9—Fail

[ECP---Equalent Class Partician]

Boundary Value of Login Operation:

User-ID                                   Password                          Status

Valid                                           Valid                              Pass

Valid                                            Invalid                          Fail

Invalid                                          Valid                           Fail

Valid                                            Blank                           Fail

What is a use case?

Ans:It is a document expecting all the functionalities and Applications from end user Print of view.

1.       Review During Information Gathering: In the face of information gathering Company higher authority can involved in this face.It is generally non-technical documentation.

2.       Review of Analysis: It is Software Development Process starts in Analysis Process. In this face Software technical People are Involve and develop “SRS” documentation.

3.       Review Designing: After Completion of Analysis face Company Architecture and Software Peoplea are Develop the External design and Internal Design that is called “HLD” and “LLD”. After Developed the design document company higher authorities conduct the reviews.

4.       Review of Unit Testing: After Completion of above three section reviews Programmers are conduct coding.In this face programmers are do the Unit Testing (or) White Box Testing.

While Unit Testing there are three types of testings are use.

1. Programming Testing

2. Platform Testing

3. Change Testing

Unit Testing Means “Verify the Internal logic of the Code”

5.Programming Testing[Executing Testing]:

A. Basic Path Coverage[All statements in Programming Correctly]

B.Loops Coverage: Every loop is correct or not

C. Programming Techniques Coverage:[Taking less time during Execution]

6. Platform Techniques or Operation Testing: Whether a Program is running to the customer Expectation flatform or not (flatform means operating System Browser] etc—

7.Change Testing or Mutuation Testing: As per Customer requirement customer can ask the Sudden changes on that time Programmer can use the technics.

1.Integration Testing: After Completion of Programming process Integration tester can Integrate the Modules.There are Three types of technics:

1. Top-Down-Approach:- In this top-down-Approach Modules are Integrated from main Module to Sub-Module.

         In this Scenario Programmers are use  temporary Programmers. It’s Known as “Stubs” or called “Programs”.

2Bottom-Up-Approach: The coverage of sub-module to sub-module with out coming from main module is called “Bottom-Up-Approach”

In this System Programmers are use temporary Programs .It’s Known as drivers or calling Programs.

3.Hybrid Approach: It is a combination of Topup and Bottom. It is called as “Sandwich”

Review During System Testing: It is nothing but functional testing. After Completion of Integration All the modules test Engineers are Performing the function and System testing.In this face testing team will follow the “Black Box Testing”. In this four types of techniques.

1.       Usability Testing

2.       Functionality Testing

3.       Performing Testing

4.       Security Testing

1.Usability Testing: In the face of usability testing tester will Observe the user friendly application or bulid. In usability testing easy to user understandable of screens look and feel speed in Interface(Short Navigation)

2 a. Functional Testing: It is a main testing division in Black Box Testing. During this testing, testing Team will reach the customer requirements they are classified several sub technics and functional coverage.

Behavioural Coverage[Changing Properties of Objects]

Error Handling Coverage[Preventing Wrong Navigation]

Ex: with out enter correct Password immediately appears wrong Password.

Calculation Coverage:Correctness of Output

Ex: Mathematical Notations

Back End Coverage:Front End Operations and Back end Tables Conducting.

Input Domain Coverage: Correct type and Size Input Values.

Service Level Coverage: Order of Functionality.

Input Domain Coverage: It is part of Black Box Testing.The test Engineers are cover two Mathematical notations such as Boundary value Analysis(BVA),Equalence class Particians [ECP].

BVA(range/Size)                                                        ECP[Type]

Min-----Pass                                                            Valid             Invalid

Min-1---Fail                                                               pass             fail

Min+1---Pass

Max-----Pass

Max-1----Pass

Max+1-----Fail

Example:

A login operation Username, Password are available click on OK button. Username allows only Alphaticals.It is lower case only from 4 to 16 characters length Password allows Alphabaticals in Upper case.It allows 4 to 10 Characters length other any Special characters and numerical characters are not allowed.

BVA(Size/Range)                                            ECA(TYPE)

Min---Pass                                                      Valid                    Invalid

Max---Pass                                                    a---z                      A—Z,0---9 any other        

Min+1----Pass                                                                                      special characters

Max+1—fail

Min-1--- Fail

Max-1 ---Pass

Password:

BVA(Size)                                                             ECA(TYPE)

Min-----Ok                                                      Valid                       Invalid

Max---OK                                                        A---Z                    a—z,0—9 any

Min-1---Not Ok                                                                              other characters

Max-1---Ok

Min+1----Ok

Max+1---Not Ok

Compatability Testing:Compatablity testing is a flat form testing or Product testing this is suitable for customer Expectation flatform also and other than flatforms also.

[Flatform means that Operating System compiling browsing and other than Softwares]

It is Known as Fortablity Testing.

Configuration Testing:It is Known as Hardware Testing. It Supports the different hardware technologies or not.

Ex: SAP----350 GB Hard Disk

1GB RAM, Dual Core

C, C++ -- 10 GB Hard Disk

           30 GB RAM, Celtron Processor

End to End Testing: In this System Test Engineers are Performed testing a Complete transaction or “ end to end scenario”

Ex: Login

          |

Balance Enquiry

          |

Withdrawl Money

         |

Mini Statements

        |

Log Out      

Sanity Testing: During Sanity testing the Testing team is Verify the basic functionality.Before going to Start actual testing and Functional Testing.

Sanity Testing Check up will be placed at below levels.1.Build Verification 2.Access Functionality Application with Browser 3.Application Connect with Tool(Addings).5.Verify the Script.

Performance Testing: It is Speed of Processing testing.This is also one type

Of “Black Box Testing”.

Ex: Request : Response time---Transaction per Second

Page Download time

There are several types of Performance testing.

System Testing: After all the modules combined together test carried out on total System (or) software is Called System Testing.

         System Testing completion after integration testing and before accepting testing.

Note: System testing is one of the Part of Functional Testing.

Review During Performing Testing:While during Performing testing the test Engineers are involve for check the Performance of Build or Software. It is also one level of Black Box Testing.

         To Test the server response with different user loads the Purpose of Performing testing is to be findout the “Bottle Necks” in add application.

What is Bottle Neck: “Bottle Neck” is a break Point where the server will be in Peak users.The Bottle neck is a Pin Point or Break Point.

Where the Server respond where the Server will be beganining with user request.

Types of Performing Testing:

Load Testing: In the face of load testing our Application build under customer Expectating

Configuration and Customer expectating load[“No-of User”] to estimate the performing testing is called Load Testing or Scalability Testing.

Stress Testing: To Test an Application Performs on Same functionality by the number of users at a time.

Storage Testing: It is technology support testing.

Ex: MS Access Technology Supports 2GB Data Base  Maximum.

JAVA Technology Supports upto 3GB Maximum.

Security Testing: In this testing the Test Engineer’s Prepared Some “Privacy Pages”.During this Testing, Testing Team Follows below sub-testings.

Authentication Testing: In this testing valid users are permitted and Invalid Users not Permitted in the Application.

Ex: 1. Login with Password

     2Credit card Validation

   3Digital Signatures

 4Finger Prints

5Cye Visual

6Blood Indication

7Body Scanner

Access Control Testing: In this testing some valid users only Permitted for use Specified user.

Encryption/Description Testing:

Review During User Accepting Testing: It is a final stage of testing.Completion of all functional and System testing Project Manager conducting the user accepting testing.To Take the Feedback from the customer side they conduct the two types of testings one is “Alpha” and “Beta” Testings.

Review During Maintenance Testing: In the face of Maintenance testing project manager will conduct the Releasing team with all developers and all developers and all test Engineers and Hardware engineers all are form as releasing Team.

             In the releasing team conducting the “Port Testing” in customer side to Completeness and Correctness of Software Installation. It is not Testing just observe only that build is Ok or Not.

         After Completion of Observation releasing team will give training for customer side People[End Users]

Monkey Testing or Chimpanji Testing:  The Test Engineers are cover main functionalities only.”Lack of Time” test Engineers are follow this “Monkey” Testing.

Exploratory: It is level by level Testing. The Test Engineers are test the Application with out using any test case and with out knowledge of Functionality.

Ad-Hoc Testing: Testing Team Conduct the testing Depending on Pre-defined ideas are using in this testing.

Test Harness(Ready to Start Testing): It  indicates readiness of start execution.

Test Harness= Test Environment + Test BED

Test Execution: After Completion of Test case Design Test Engineers are receive build from development Team and start the test Execution, whether the functionality right or wrong.

Verification: Checking the Process of Developing Applications Correct or Not.

Validation: Checking the developed Application is meet the Customer requirement or not.

Reviews: The Process of Checking a document for Completeness correctness, and clarity is called “Review”. These Reviews are help to us for Identify the defect at early stage.

Walk Throughs: It is a one of the quality improvement Process.It is Process of Inspection.The Software code Check line by line before Execution the code.The Main Intension of code “ Walk- Through” is to ensure that the code fit or not.

SRS: Whenever Administration window alignment to good login form “min” “max” “close” buttons has to available. Username is in Text Box.Valid Data is Upper Case of alphabates. It length is 4 to 16 characters.Other than any Characters not accept.Password has to in text Box.It is in encrypted form.This Valid data is “0---9” number value only other than any Characters are not accept.

Click on OK Button will be enable (or) [Blinking].

Click on Cancel username, Password both has to clear.

Module Name: Administration Module

Form Name: Login Form

Pre-Request: login window should be Available.

Created By: Creator Name.

Retesting: Re-Execution  test on our Application Build with Multiple input Values is called

“Retesting”

Level Testing or Somok Testing: In the face of Level0 Testing receive “initial Build” from developer the tester can start the sanity testing from this face.The Tester follows some below factors.

1.       Understandability

2.       Operatable

3.       Observable

4.       Controlability

5.       Consistancy

6.       Simplicity

7.       Maintanable

8.       Automatadable.

In the Sanity testing Level 0 testing also known as “Build Verification Testing”. Tester Accepting Testing “ and Oct angle testing, Testability Testing.

Level1 Testing: After Completion of Initial build work the test Engineers are Conform the “Stable Build” then the Engineers are starts the testing Process after this. It is Functional or Black Box Testing will starts from here.” We can do this testing By Using of Automachine testing also.

Level 2 Testing:(Regression Testing):- During Level1 Testing test engineers are execute the test case at that time any mismatches are face the test engineers are Report to the development team. The Developer resolved that mistakes. After that the test case is modified build.After receive this modified build the test Engineer will follow the regression testing on the Modified build.

What is Regression Testing:--

The Test engineers are Identify any mistakes in Application build after the developer will rectify mistakes. After modify the mistake tester will start their Application on that “Modified build”

Which testing we are Doing again on Modified build that is called “Regression Testing”

Test Reporting or Defect Reporting[Tracking]:- During Level1 and Level2 testing at the time of execution test Engineers are find defect or mismatches or Issues After they send back to developer team By Using the “IEEE” Format.

Defect Report Format:

1.Defect Id: Unique Number

2. Description: Summary of the defect.

3. Build Version Id: Build Version Number or Module Number.

4. Features: Name of the Module name & Number

5.Test Case Name: What Type of functionality or Test Case ID

6. Reproduce Defect: Yes or No

7. Severity: The seveourness of  defect.

A. High B.Medium C.Low. It is Functionality Point of View.

8.Priority: The Importance of Defect and terms of customer Point of view.

9.Status: New or Reopen, Position of the defect detected by name of test Engineers assigned to the resposable Person Id at Development Team Side.

10. Fixed By :- The Name of Project manager or Test Lead.

11. Resolved By: The name of the developer.

12. Resolved On: Date of Solving

13. Approved By: The Signature Project Manager.

Defect Age: The time gap between reporting date and resolved date of a defect.

Error, Defect ,Bug:  A mistake in Coding is called ”Error” this error find by test engineer during testing It is called “ Defect” or Issue. This defect accepted by developer to resolve is called BUG.

Defect SubMission Process: Diagram

Bug or Defect Life Cycle:

             Detect Defect

                    |

  Reproduced Defect

                  |

      Report Defect

                 |

      Bug Fixing

                |

   Bug Resolving

             |

   Bug Closing

Types Of Bugs:

1.User Interface Bugs or Cosmetic Bugs: Bugs related to GUI of Application or Navigation or Spelling mistakes, font style, font size, colors, right alignment.

2. BVA Related Bug: Minimum and Maximum values.

3.ECP Related Bugs: Valid and Invalid Type.

4. Input/Output Bugs:

            a. Valid Values not Accepted.

           b. Invalid values accepted.

5. Calculation Bugs:

          a. Mathematical Errors

          b. Final Output is Wrong.

6. Load Condition Bugs:

          a. Does not allows multiple users

         b. Does not allows customer Expected Load.

7. Race Condition Bugs:

        a. System crash and Hang

        b. System cannot run client Platforms.

8. Version Control Bugs:

        a. No version Information Available.

        b. This occurs usually in regression Testing.

9. H/W Bugs:

      a. Device is not responding to the Application

10. Source Bugs:

     a. Mistakes in help documents.

Test Closing: After completion of Test execution levels and Corresponding bugs resolving test lead is conducting a review meating to estimate completeness and correctness of test Process. When you stop testing the test Engineers goto test stop before they are follow below coverages.

1.Business required based coverage(Module Level).

2. Use Case based Coverage (Functionality in Every Module Level)

3. Data Input Based Coverage(Input object in Every Functionality)

4. UI Coverage [Screens in Every Functionality ]

5. TRM Based coverage [Text Factors level]

[TRM- Test Responsibility Matrix]

[RTM- Requirement Traccability Matrix]

BUG Density: Average number of Bugs Testing team found in module.

                   Ex: Module1            10%
                         Module2           40%

                        Module3           20%

                       Module4            30%

                       Total                   100%

Note: Need for regression (module 2)

Level 3: Analysis of Deferred Bugs: Whether the deffered bugs are postpone are not after completion test close review the testing team is conduct “Level 3” Testing. It is known as “Final regression” or Pre acceptable testing” or “Relieving Testing”.

User Accepting Testing: After completion of final regression testing Project Manager will conduct UAT or CAT. To Collect feedback  from real or model customer.There are two types of UATs those are “Alpha” and “Beta”.

Sign Off: Complete after UAT and Any modification test lead will prepare the “Final Test Summary” [STSR].This document is a part of Software releasing notes.This is Final Summary of report or document.They follow below technics:

1.       Test Methodology/ Test Strategy.[TRM]

2.       Test Plan

3.       Requirement tracability Matrix.

4.       Auto Machine Test Script.

5.       Final Bug Summary Report.

Kich of Meetings: It is first meeting conducting with in development camp or Place.

[With in the Company][High level management like Board of directions, CEO, And all project managers]

1         They discuss overview of Project.

2         Customer nature also discuss.

3         Project team development & Testing Team.

Peer Review: Reviews carried out by Peer or Persons at the same level in the Hierarchy.

Peer Review were done on designing stage, coding stage, testing Stage. This review helps to improve the product quality.

Change Request: Change request is a process of process to requesting the development team for adding some new changes to the existing module. Usually the Customer ask new change request(Change testing or Mutuation Testing).

QA Manager Manage all the projects in the company.

Project Manager: Projects Manager works in specified Project only.

Difference between QA & QC:

          QA                                                                     QC

1.Quality Analyst                                                 1.Test Engineer

2. Responsible for Prevention of defect.             2. Resposible for detection of defects.

3.Qa defines process                                                           3.Qc follows the process

4. They improves Process                                   4. They improves Product

5. QA Prepares all templates                             5.They use all templates 

Like: Test Plan, Test Case defect report

6 QA is for entire Organisation                         6.QC is for across the organization.

7 Verification                                                     7.Validation

Client Server Application:

1.Two Type Architecture (Backend ,Front End)

2. Limited Users

3. Flat Form Independent.

Web Server Application:  

1.       Three tire Architecture.

2.       On Users flat form depended

Ex: Browser, Backend and Server.

PETT Process:  This Process model developed by “HCL”. It isalso a refinement form of “V Model” and Mapping between development and testing Process from this Process organization are maintain by separate testing Team for functional and System testing.

Diagrams:

TEST HARNESS:[ Harness means Ready to Testing]

Case Study:

Developers                                   Responsibilities                            Time Duration

1.Test Case Selection                  Test Engineer                                 10-15 Days

2. Test Case Review                    Test Lead                                       5 to 6Days

3. Requirement trasablity Matrix TestLead                                       1 to 2 Days

4.Sanity Testing                           Test Lead/Engineers                      5 to 10Days

5. Automahine Testing                 Test Engineer                               7 to 14 Days

6. Level 1 Testing                         Test Engineer                              25 to 30 Days

7. Level 2 Testing                          Test Engineer                              30 to 40 Days

8. Test Reporting                          Test Engineer/Test Lead              On Going

9.Status Report                             Test Lead                                     Weekly Once or twice

10.Final Regression                     Test Lead/Engineer                        1 to 2 days

11. Test Closure                            Test Engineer                               1 to 2 days

12.User Accepting                       Customer,Test Engineers other heads  5 to 10 Days

13. Sign Off                                 Test lead or Other Heads                      2 to 3 days

KT: K: Knowledge   T= Transfer

To sharing the Knowledge with colleagues.

To retrieve Knowledge from Others.

                  Library Project                          

 Modules:- 3 Modules: Masters

                                           Transactions

                                          Administration

Grey Box Testing: A Tester having Knowledge of Black Box and White Box testing both is Known as “Grey Box Testing” .

Tables:

Use Case: Preparation of Test Case of “ATM” With drawl form.

TC01: Card Insert Successfully

TC 02:  Wrong Side

TC 03: Unsuccess Insert other cards (Time Expired)(Office ID Cards)

TC 04: Success Enter Pin Number

TC 05: Unsuccess Enter Wrong Pin number [RBI declair u number Pin Only. Enter more times Pin number]

TC 06: Successful of selecting Operations [Select navigation or particular tag or Option] Ex:Account type.

TC 07:Success of Selecting account type.

TC 08: Unsucess operation due to wrong account type selection.

TC 09:Successful of Operation with drawl.

TC 10: Successful Entry of maximum amount.

TC 11:  Unsucessfull Entry of Invalid amount.

Ex: 99,999,228,101 etc…

TC 12: Successful with drawl Operation.

Output: money with right receipt possible of card come back.

TC 13: Unsuccess withdrawl Operation due to amount greater than possible balance.

TC 14: UnSuccessfull Withdrawl Operation due to Lack of amount in “ATM”

TC 15: Unsucessfull Operation due to Server down.

TC 16: Unsucessfull operation due to amount greater than day limit.

TC 17: Unsucessfull withdrawl due to click or cancel after Insert card and Pin Number or language selection.

TC 18: After inserting card Pin number, language type, select the with drawl Operations and enter the amount.

Use Case: Prepare the test case of automatic door open with the help of sensor system follow the below scenarios.

The door Open when a Person comes infront of the door and after door close.

TC 01: Successfully door has to Open if a Person infront of the door.

TC 02: Unsuccessfull door Open due to absent of Person.

TC 03: Successfully door close when person came Inside.

TC 04: Unsuccessfully door close due to Person stands at the door middle.

Test Case: Preparation the Operations of washing machine.

TC 01: Successful of Power Supply.

TC 02: Successful of door Open

TC 03: Successfully drop the Clothes.

TC 04: Successfully Water filling.

TC 05: Successful at drop detergent.

Use Case: In Banking Application customers are connecting Bank Server using Internet Connection. In this Login Process Customer will follow in below stages.

Password   6 Digit Number

Area Code 3 Digit Number

Prefix 3 Digit Number but doesnot start.

Affix 6 digit with 0,1 Alphabetical numeric.

Commands:- Cheque deposit, with drawl mini statement.

TC 01:  Successful Enter Password

BVA                                                              ECP

Min= 6 digits pass                                    Valid                    Invalid

       = 5 digits fail                                     0-9,numerical           Alphabets and Any other

      = 7 Digits  fail                                      numbers                    characeters.

TC 02: Successful entry of Area Code.

BVA                                                                     Equalent Class Particians[ECP]

Min=Max=3---Pass                                               Valid                    Invalid

                  =2---fail                                            0-9,numerical         Alphabets & Other special

                =4----fail                                            numbers                        characters

TC 03: Successful Entry Prefix.

                     Development Of Test

Use Case: Use case is a description of functionality of a certain feature of an application and actions of response.

Functional Requirements: 1.Login screenshots contents username, password connect to fields are available.

2.Connect to is not a mandatory field but it should allow the user to select a database Option.

3. Upon Enter the valid user name, Password and click on the login button the corresponding page must be display.

4. Upon enter some Information into any of the fields or click on Clear Button all the fields must be cleared and the customer Placed in username field upon click on Cancel Button login screen should be closed.

Special Requirements or Validation or Business Rules:

1.Initially whenever the login screen will open the login and clear button must be disable.

2.Cancel button must be always enabled.

3.Upon entering the username and Password the login button must be enabled.

4. Upon enter information into any fields clear button should be enable.

Types of Test Cases: Two Types of Test Cases.

1.GUI Functionalities

2.Functional Test Case: a. Positive

                                        b. Negative

Check the Points of Preparing GUI Test Case:

1.Check the availability of all Objects.

2.Check the alignment of Object.

3 .Check the consistency of Object [Style, colors].

4.Check the Spelling of grammar.

Check the Points of Preparing Positive Test Case:

1.The Test Engineer Should have Positive ideas.

2. Test Engineer should consider the Positive flow of Application.

3. The Test Engineer should always use only the valid inputs.

Check the Points of Preparing Negative Test Case:

1.Test Engineer should have the Negative Ideas.

2. Test Engineer Should consider the Negative flow of Application.

3. Should have always use Invalid inputs.

What is the Test Object: The Purpose of the document is described here in the section.

What is the Test Scenario: The Situation that are to be tested described(flow of an application)

What is the Test Procedure: It is a functional level term which describes how to perform on a functionality.

What is the Test Data: The data that is required for testing is described here in this scenario.

Build mail from Development to Lead to Test Lead

All,

New build is ready for QA.

Build is available in VSS.

File location: \\VSS\WBMS\Testing\Builds\WBMS2.0

Please continue testing and update the status by tomorrow EOD.

Thanks,

RK

􀂾 Same mail will be Forwarded to Team via Test Manager/Test Lead

Team,

FYI.

Start testing.

􀂾 Test Lead will prepare Task List and Fixed issues and communicated to Team

Team,

Attached please find a list of Fixed Issues - To be verified in WBMS 3.0 and Build 01.

Same sheet is updated in our shared server

Location: \\sharedserver\WBMS\ReTesting

Please retest the all fixed issues and let me know the status by Tomorrow EOD.

Let me know, if required further.

Thanks,

Prasanna

􀂾 Test Lead will collect status reports from Test Engineers daily basis and he will

prepare Build Summary report. Same he will forward to Test Manager

Hi Rahul,

Attached is the WBMS Build summary report of 3.0v Build 01.

Thanks,

Rajesh

ALA Testing Workflow

Mr. Venkat

􀂾 Test Manager Will forward Build Summary Report to Development Lead and

Client Call

Hi All,

Agenda for WBMS 3.0 Build 01 testing review meeting

1. Bugs summary and Test execution status

2. Next build plan and Q&A if any

We will call: 1 7878678

Time: 9.30 am PST Wednesday (10.00 pm IST Wednesday)

􀂵Weekly Build Summary Report􀂶 is attached to this email for reference.

Thanks,

Pratap

􀂾 Next Day Team with Test manager and Test Lead will prepare MOM and

circulate to Test Engineers

Team,

Minutes of today meeting are as follows:

Date: 10-13-2009

Time: 9:30 AM 􀂱 9:40 AM PST

Participants: Team

Highlights:

􀀀 Discussed about WBMS 3.0 build 01

􀀀 One more new build will be released tomorrow

􀀀 WBMS 3.0v is scheduled for one month

Action Items:

􀀀 Testing team concentrates WBMS 3.0 testing

Thanks,

Sagar