This action might not be possible to undo. Are you sure you want to continue?
that is developed by the manufacturer’s specifications and used by multiple customers and customized according to the specifications What is Quality? Justification of requirements either in a product or in a project; Quality: Classical definition Quality is not defined in the product or in the project but defined in the customer’s mind. Latest definition of Quality: Not only justification of requirements but presence of value (user friendliness) Defect: Deviating from the requirement Testing: It is process of identifying the defects, isolating the defects, subjecting the defects for rectification and ensures that the product is defect free in order to produce a
quality product at the end; And hence customer satisfaction. Bidding of the Project: It is defined as request for proposal, estimation and signing off. Kick off meeting: It is the initial meeting conducted in the SW company soon after the project is signed off in order to discuss the overview of the project, and to select a project manager. PIN: Project Initiation Note It is mail prepared by the project manager and sent to the CEO of the SW company in order to get the permission to start the project development. SDLC Phases: Phase 1: Initial or requirements phase Roles: Business Analyst and Engagement Manager Task of the Business Analyst: Takes an appointment from the customer, collects the template from the SW company, meets the customer on the appointment
date and time, interacts with the customer using the template and converts the template as document and submits the same to the SW company to make sure that they both are on the same page. Task of the Engagement Manager: Responsible for following: 1) Deals with the excess cost of the project 2) Responsible for the prototype demonstration: Prototype is a roughly and rapidly developed model. Output document or proof document from Initial Phase is called FRS or “functional Requirement Specification.” It is also called as BRS or Business Requirement Specification or URS user requirement specification or CRS client requirement specification or BDD Business Design Document or BD business document. Phase 2: Analysis phase: Input document for this phase is FRS Roles: 1) System Analyst, 2) Project Manager and 3) Team Manager Tasks: 1) Feasibility study:
Low Level Designing (LLD): . 2) Tentative planning: The resource as well as the time is temporarily planned here.A detailed study of the requirements in order to check if they are feasible or not. 3) Technology selection: What are all the technologies that are required for accomplishing this project successfully are analyzed and listed off. 4) Requirement Analysis: What are all the requirements that are required to accomplish the project successfully are analyzed and listed out. Roles: Chief Architect and Technical Lead Tasks: High Level Designing (HLD): The process of dividing the project into modules is known as HLD usually performed by Chief Architect. Proof document or Output document from Analysis phase is SRS (Software requirement specification or System requirement specification) Phase 3: Designing phase Input document for this phase is SRS.
The process of dividing the modules into sub modules is known as LLD usually performed by the Technical Lead. proper commenting and colour coding etc. develops the actual source code of the project. It contains of some diagrams and pseudo code Phase 4 Coding phase: Input document for this phase is TDD. Output document or proof document from the coding Phase is SCD source code document. Phase 5: testing phase Input document is FRS functional Requirement specification . Output document or Proof document from designing phase is TDD technical Design document. Roles: Programmers or developers Tasks: Programming or Development Process: Developers using the pseudo code and following the coding standards like proper indentation.
takes the test case template and develop the test cases. after understanding all the requirements clearly.Roles: Test Engineers Task: Testing Process: FRS review. Ensures that the product is defect free If any defects are identified. Subject the defects to the developers for rectification. After the execution: Identifies the defects and isolate the defects. in doubt sends to the author of the document for clarification. Prepares the review report. the same process continue till the product is defect free Output or proof of testing phase is Quality Product or the Product which is working as per the customer’s expectation. . Once the build or module is released then executes the test cases.
Phase 6: Release and maintenance Release: Roles: Deployment engineer or Senior Test Engineer Tasks: Deploying or installation Process: The deployment engineer will deploy the application into the client environment following the guidelines given in the Deployment document by the development team.Test CASE definition: This is a check list of all the deferent perceptions of a test Engineer in order to test a specific functionality. Maintenance: After release if at all any problem is there with the SW then that problem will become a task depending upon that problem the corresponding role will be .
appointed and he defines the process based of the issue and resolves the issue. Unconventional It is a sort of testing which is conducted on each and every out come document right from the initial stage onwards by the Quality Assurance people 2. Usually the test engineers with structural knowledge perform GBT. Black Box Testing: If one performs testing on the functional part of the application with out having structural knowledge then that method of testing is known as BBT. Usually test engineers perform it. 1. . There are 2 sorts of testing. Conventional It is also known as formal testing performed by the test engineers. Gray Box Testing: If one performs testing on both functional as well as structural part of an application then that method of testing is known as GBT. Testing Methodology or Testing Techniques: White box Testing: If one performs testing on the structural part of the application then it is known as WBT usually developers perform it.
if any mandatory module is missing that module is replaced with a temporary program know as STUB. Module level: Collection of units is module. Integration of modules can be done 4 approaches. Bottom Up Approach (BUA) . STUB: While integrating the modules in TDA.Levels of Testing: Unit level: Smallest part of an application. This is a WBT. 1. It is performed by the developers as this is structural and called WBT. then the developers will try to integrate the modules and perform testing to make sure that the modules are integrated properly or not. 2. Integration Level: Once the modules are all ready. One performs testing of a unit is called Unit level testing. Top Down Approach (TDA) In this approach the parent modules are integrated with the sub modules. So a module will have some functionality and BBT is the method used due to it functionality feature.
Environment: An environment is a combination of 3 layers 1) 2) Presentation Layer Business or application layer . Big Bang Approach (BBA) Once all the modules are ready integrating them at a time is known as BBA.In this approach the sub modules are integrated with the parent modules. It is also BBT. then it is known as user acceptance testing. it is deployed into an environment and is prepared as a system. if at all any mandatory module is missing that module is replaced with a temporary program known as Driver. High breed or Sandwich approach This approach is the mixer of TDA and BUA. 3. 4. If one performs testing on the system then it is known as system level testing and it is a BBT User acceptance Testing: If one performs same system testing in the presence of the user. System Level Testing: Once the application is ready. Driver: While integrating the modules in BUA.
2) Client server or 2 tier Architecture: If at all the presentation and business layers reside in the client system and database layer resides in the server system then it is known as 2 tier architecture or client server environment 3) Web Environment or 3 tier Architecture: It contains 3 tiers where in the first tier contains Presentation or clients.ppt 1) stand alone environment or 1 tier architecture: If the 3 layers i. then it is known as stand alone environment. presentation.3) Database layer Types of environments: There are 4 types of environments JayaQA\SDLC methods.e. 4) ‘N’ tier architecture or distributed environment or multi tier architecture: Which is similar to the web environment but the business logic is distributed among a . the second or the middle contains the application server and the third tier contains the database server. business or application and database layer resides in a single system.
B) When ever the new changes are incorporated by the developer and released . A) When ever the defects are rectified by the developer and the next build is released to the testing department then the test Engineer will perform testing not only on the defects part but also on the related functionality once again. Types of Testing: 1) sanity testing or smoke testing or Build verification testing or initial testing (look and feel) 2) regression testing: In which already tested functionality is tested again mainly in 2 scenarios.number of application servers in order to distribute the load. Software Development Life cycles Models: SW development Life cycle Models 1) Water fall or sequential model or Linear model 2) Prototyping model 3) Evolutionary model or the fickle minded 4) Spiral model 5) Fish model 6) V model Software efficiency formula: DRE = A/ A+B DRE = Defect Removal Efficiency A = Defects found by the Test engineer B= defects found by the end user or the client.
tested once again with multiple sets of data in order to ensure whether the functionality is working fine or not. 3) Retesting In which already tested functionalities. The disadvantage here is.to the testing department then the Test Engineer will perform testing on the old tested part once again in order to ensure that its old functionality is not affected due to the new changes. Beta Testing: It is a type of UAT conducted in the client’s place either by the 3rd party testing units or by the end users. Static Testing: . Usability Testing: It is a type of testing in which a test engineer will only focus on the user friendliness of the application. If any defect. if any defects are found then there is no chance for rectifying immediately. The advantage is if any defects are found then there is a chance for rectifying immediately. whether it is reproducible or not? Alpha testing: It is a type of user Acceptance Testing UAT. A test engineer performs testing on an application in the presence of the user within the company.
web servers. If the installation is successful then he will come to a conclusion that the guidelines are correct. Operating systems and databases and check whether the application is compatible with those environments.One performs testing on the application or application related factors whenever it is not being executed. Ex: document testing and GUI testing. application servers. Compatibility Testing: A test Engineer may have to deploy the application into the environments prepared with different environmental components like browsers. . Port Testing: One will deploy the application into the client environment and check whether it is compatible with that environment or not. Dynamic Testing: If at all one performs testing on an application when ever it is being executed then that type of testing is known as Dynamic testing. Ex: functionality testing Installation Testing: A test engineer will deploy or installs the application into the environment following the guidelines given by the development team in the form of deployment document.
Security Testing: Authentication Testing: In this type of testing. Test Engineer will perform testing on the application for longer period of times and checks weather the application is stable or not. the test engineer will check if the application is accessed by the authorized person or not Direct URL Testing: Test Engineer will enter direct URL into the address bar of the browser and try to access those pages to make sure that they are not accessible with out proper authentication. . Soak Testing: It is also a type of stress testing. Exploratory Testing: Usually one will be exploring the functionality and simultaneously testing the functionality. Usually domain experts will perform it. Firewall leakage Testing: A test engineer will check weather the implemented firewalls are working properly or having any leakage.Monkey Testing: It is type of stress testing in which one will perform abnormal actions on the application intentionally in order to check its stability.
0 Introduction 1. End to End Testing: In which performs testing on one complete transaction from one end to the other end of the application. Since it is associated with different mutants (Logic) it is known as mutation testing. Quality lead or test lead will prepare the test plan. efficient and in an optimized way. Test planning: This describes how to perform testing on an application in an effective.2 Objective reference documents . INDEX or Contents of the TEST PLAN: 1.1 1.Mutation Testing: WBT It is a WBT performed by the developers where in he will do some complex changes and checks the performance of it. SOFTWARE TESTING LIFE CYCLE: STLC 1. ADHOC Testing: A test engineer will understand the requirements and performs testing on the application in his own style with out following any formal procedure or norms.
8 List of automated tools 4.4 Configuration management 3.0 2.0 Resources planning .2 Types of testing 3.1 acceptance criteria 4.2 Coverage of testing features to be tested Features not to be tested 3.2.5 Test metrics 3.1 Levels of testing 3.0 Test Deliverables 6.6 Terminologies 3.3 Test designed techniques (BVA) boundary Value partition (ECP) Equal class partition 3.7 Automation plan 3.0 Test strategies 3.1 2.0 Base criteria 4.2 suspension criteria 5.0 Test environment 7.
Risks and contingency plan Assumptions Approval information TEST DEVELOPMENT: Use case: It describes the functionality of certain features of an application in terms of ‘actor’. Explicit (FRS) and implicit requirements (business people) e) Precondition f)Post condition and .0 12. ‘action’ and ‘response’.0 Scheduling 9. Input information required to prepare the ‘USE CASE’ document a) Screen shot or snap shot b) FRS or functional requirements specification c) BRS or Business requirement specification or Special requirement specification d) Use case template a) Name b) Brief description of the ‘Use Case’ c) Actors involved d) Special requirement.8.0 2.0 11.0 Staffing and training 10.
4) Actor enters invalid Go to Alternative flow Table username. (Main flow) (Alternative flow) MAIN FLOW: RESPONSE Log in screen is displayed with the following fields: User Name/password/connected to/Login/clear/cancel 2) Actor enters valid User Authenticates either home name. Valid PW and 1 clicks on login button 5) Actor enters valid Go to Alternative flow Table username.g) Flow of events. valid pw and click page or Admin page is on Login button displayed depending the Actor entered 3) Actor enters valid user Authenticates either home name and valid pw and page or Admin page is selects a database options displayed with the and clicks on login button mentioned database connection. in Valid PW 2 and clicks on login button 6) Actor enters some Go to Alternative flow Table information into any of 3 the fields and clicks on clear button 7) Actor clicks on cancel Go to Alternative flow Table button 4 ALTERNATIVE FLOW: ACTION 1) Actor invokes the application .
Valid Username and clicks on login button Table 3 (Clear Click) ACTION Actor enters some information into any of the fields and clicks on clear button Table 4 (Cancel click) ACTION Actor clicks on cancel button RESPONSE An error message should be displayed “invalid PW. Please try again” Table 2 (Invalid PW) ACTION Actor enters invalid PW. . GUIDELINES TO PREPARE TEST CASES FROM A GIVEN ‘USE CASE’: Security: Identify the module to which the ‘USECASE’ belongs to (Security module) Authentication: Identify the functionality of the UC with respect to the total functionality of the application. Please try again” RESPONSE All the fields should be cleared and the cursor should be placed in”User name” field.Table 1 (invalid Username): ACTION RESPONSE Actor enters invalid An error message should username. Valid PW and be displayed “invalid user clicks on login button name. Identify the functional points and prepare the functional point documents. RESPONSE Login screen should be closed.
Ex: Admin user and normal user Identify if the use case is linked with any other use case EX: home page or Admin page Identify the precondition: Ex: login screen or the initial screen should be available Identify the post condition: EX: for valid user’s valid page and error message for invalid users.Functional Point examples: 1) user name 2) passwords 3) connect to 4) login 5) clear 6) cancel Identify the inputs that are required to perform the UC (use case) EX: Valid and invalid inputs Identify the actors involved in the use case. Document the Test Cases for the Main Flow Document the Test Cases for the Alternative Flow . Understand the ‘Main Flow’ of the use case The ‘Main Flow’ indicates the main purpose of the application and the remaining all comes under ‘Alternative Flow’.
DPD Defect Profile Document 1 Classification of the TEST CASES: Types of Test Cases: Test cases are broadly divided into 2 types User Interface Test Case: Guidelines: .Prepare the Cross reference matrix or traceability matrix This table is useful for tracing the exact location of the defect. CROSS REFERENCE MATRIX OR TRACEABILITY MATRIX TABLE USD (user FPD MTCD DTCD specification Functional Master Test Detailed Document) Point Case Test Case Document Document Document 3. And it also useful for to check for all the requirements of the customer are covered by the developers.5 13 12 8 This document explains the number of test cases that can be developed on a particular functionality.
Check for the Check for the Check for the availability of all the objects in the alignment font.Check for the application. color and consistency spelling and grammar Functional Test Case: Divided in to 2 types a) Positive: Test Engineer should have positive perception Considers only the positive flow of the application by using the valid inputs b) Negative: Test Engineer should have negative perception to consider only the negative flow of the application by using invalid inputs TEST CASE TEMPLATE: 1) Test case Objective 2) Test scenario 3) Test procedure 4) Test Data 5) Test Case Test Case ID Test Case Type LOG_001 User Description Expected Actual Value (expression Value must be (must use the commanding) word ‘should’) Check for the All the objects All the objects Result Remarks Pass None .
All the objects should be spelled as per the Object’s Table All the objects should be consistent ‘LOG IN and CLEAR’ buttons should be disabled and ‘CANCEL’ button must be always enabled. Refer to Invalid Pass Failed Negative Enter ‘USER NAME’ and Pass word as per the invalid input’s table and click on ‘LOG IN’ . Correspondin g pages should be displayed as per the ‘valid input’s table’ All the fields should be cleared and cursor should be placed in the user name field Login screen should be closed Correspondin g Error messages should be displayed as per the invalid inputs table. cancel buttons are enabled Pass None Pass None LOG_004 UI Failed Log in and clear buttons are enabled LOG_005 Positive Test Case Correspondin g pages are displayed as per the Valid input’s table All the fields are clear but the cursor is not default into User name field Pass LOG_06 Positive Failed Tab action is not defaulting to the User Name field after clear. LOG_07 LOG_08 Positive Click ‘Cancel’ Button Log in screen is closed Correspondin g error messages are not displayed as per the invalid input’s table. clear. are available as per the object’s table All the objects are spelled as per the object’s table All the objects are consistent Log in.Inter Face UI LOG_002 UI availability of all the objects Check Spellings of all the objects Check consistency of all the Objects Check ‘enabled property of LOG IN and CLEAE. CANCEL’ buttons Enter the User Name and PW as per the Valid Inputs Table and click on Login button Enter some information into any of the fields and click on ‘Clear button’ LOG_003 UI should be available as per the object’s table.
button Input’s table for details Objects Table: Serial Number 1 2 3 4 5 6 Valid Input’s Table: S. Please try again” Actual Value Home page is displayed Result Fail Error message is displayed ‘invalid password please try again’ Pass 3. Please try again” 2 Sai Nidfje Error message should be displayed. Test Execution Phase: . ”Invalid user name. “Invalid PW.NO User Password Expected Value Name 1 Kjkdjkj Prema Error message should be displayed.NO 1 2 3 User Name Sai Ram Alla Password Prema Love Akbar Expected Value Admin page should be displayed Home page displayed Sales Page Actual Value Admin Page is displayed Home page is displayed Sales page is displayed Result Pass Pass Pass Object Type Text Box Text Box Combo/drop down box Button Button Button Object Name User Name Pass Word Connect to Log in Clear Cancel Invalid Inputs Table: S.
2) Observes the actual behavior of the application 3) Documents the observed value under actual value column of the Test Case Document 4) Result Analysis Phase: In this Phase the test engineer will compare the actual values with the expected values. 5) Bug tracking Phase: In bug tracking phase. Defect Profile Document: . If both are matched then it is decided that the result is pass other wise the result is Fail.In this phase. isolated and documented and the documents must be maintained for next testing. test engineer has to do the following things: 1) Perform the action that is described in the description column of the Test Case document. the defects are identified.
It is classified in to 4 types. Usually it is given by the senior Test Engineer or Test Lead and can be changed by the . 1) Major: If the defects are related with the major functionalities working then such types or defects are treated to be MAJOR. 2) Minor: If the defects are related to the look and feel of the application then such types of defects are treated to be MINOR. or unavailability of functionality then such types of defects are treated to be FATAL. 3) Suggestion: This is not considered as defect. Priority: This describes the sequence in which the defects have to be rectified. 1) Fatal: If the defects are related to navigational blocks.Defe ct ID Inde x num ber like a prim ary Key Defect Steps Descrip for tion reprod ucibilit y Defect Instru scenari ctions o to reprod uce the defect Sub mitt er Date of Sub miss ion Build Versi Assig num on ned ber num to ber Seve rity Prior Stat ity us Severity: This describes how sever the defect is. But if the test engineer wants to give a suggestion to a developer in order to increase the value of the application then such types are called SUGGESTIONS.
then he will set the status as NEW or OPEN 2) RE OPEN: If the Test Engineer feels that the raised defect is not rectified properly by the developer then he will set the status as RE OPEN. STATUS: There are 7 Status steps for a DEFECT 1) New or OPEN Initially when ever the defect is identified by the Test Engineer newly. 5) HOLD: When ever the Developer is in a dilemma to accept or reject the defect then he will status to HOLD. Note: a triage meeting is conducted to resolve these HOLD status defects. Team lead.project lead according to his convenience depending on the situation. Priorities are classified in to 4 types: 1) Critical: Usually critical is given to FATAL. 3) CLOSED: When the Test Engineer feels that the raised defect is rectified properly then the Test Engineer will set the Status as CLOSED. . corresponding developer and Test Engineer are involved in the Triage meeting. 4) FIXED FOR VERIFICATION: When ever the raised defect is accepted and rectified by the developer. then he will set the STATUS as ‘FIXED FOR VERIFICATION’. 2) High: This is given to MAJOR 3) Medium: This is given to MINOR 4) Low: This is given to SUGGESTION But depending upon the situation the priority may be changed.
and the test engineer is not aware of the updates. then he will raise them as defects. 7) TESTER’S ERROR: If the Developer feels that it is not at all a defect then he will set the status of the defect as ‘TESTER’S ERROR’. But the developer will set the status AS PER DESIGNE. 6) REPORTING PHASE: CHECK THE DIAGRAM WAYS OF TESTING: .6) AS PER DESIGNE: When the new changes are incorporated by the developer into the build. Note: Tester’s errors are kind of warnings for the testers.
Tediousness. test development. Time. Draw backs of Manual Testing: More number of people are required (Man power) Time consuming Human Errors Tediousness Repetitiveness Simultaneous actions not possible 2) Automation Testing: This is a process in which all the drawbacks of manual testing are addressed properly and provide speed and accuracy to the existing testing process. accuracy are overcome Record and Playback facility addresses the repetitiveness Rendezvous point feature over comes the simultaneous action problem Drawbacks of Automation: Cost efficiency . Result Analysis. Advantages of Automation: Virtual users over come the man power issues As it is a SW component.There are 2 ways of testing: 1) Manual Testing: It is a process in which all the phases of the testing life Cycle (STLC) Like test planning. bug tracking and Reporting are accomplished manually with human efforts. test execution.
Expertise person not available to use the application Can not automate all the areas in a project EX: GUI ---The End------- .
This action might not be possible to undo. Are you sure you want to continue?