1.Manual Testing What is SoftwareTesting? Software testing is the process used to identify the correctness, completeness and quality of developed software.

2. Manual Testing Goals ofTesting. Determine whether the system meets the requirements. Find the bugs Ensure Quality 3. Manual Testing Advantages ofTesting Detect defects early Reduces the cost of defect fixing Prevent the detection of bugs by the customer Ensure that the product works as to the satisfaction of the customer 4. Testing Methods (or) Testing Techniques 1. Black BoxTesting: It is a Method of testing in which one will perform testing only on the functional part of an application without having knowledge of structural part. I.e: Usually the test engineers will perform 5. Testing Methods (or) Testing Techniques 2.White BoxTesting: It is a Method of testing in which one will perform testing, on the structural part of an application. I.e: Usually Development team will perform white box testing. 6. Testing Methods (or) Testing Techniques 3. Gray boxTesting: It is a Method of testing in which one will perform testing, on both the functional part as well as the structural part of an application .I.e:Testers who has structural knowledge will perform gray box testing 7. AUTOMATION TESTING Ways ofTesting: There are two ways ofTesting ManualTesting AutomationTesting(QTP, QC, Load Runner) 8. AUTOMATION TESTING: Ways ofTesting: ManualTesting: It is a way of testing in which one will perform all the phases of software testing life cycle like Test planning,Test development,Test execution, Result analysis, Bug tracking, and Reporting are accomplished manually, successfully with human efforts 9. Ways of Testing: qtp Ways ofTesting: AutomationTesting: Automation testing is a process in which all the drawbacks of manual testing are addressed properly and provides speed and accuracy to the existing testing process. 10. Roles and Responsibilities of a "Software Testing Engineer " Generally Roles and Responsibilities of aTesting Engineer may vary, depending upon the working company. But here we are going to discuss about the general and important roles and responsibilities of aTesting Engineer. 1)Analyzing the Requirements from the client 2) Participating in preparingTest Plans 3) PreparingTest Cases for module for system testing 4) PreparingTest Datas for the test cases 5) Executing theTest Cases 6) DefectTracking 7) Giving mandatory information of a defect to developers in order to fix it 8) Preparing Summary Reports 9) Communication with theTest Lead /Test Manager 10) Conducting Review Meetings within theTeam 11) Sending the daily or weekly status reports t0 Manager 12) Involve the Client calls for understand requirements 11. Levels of Testing i. Unit LevelTesting ii. Module LevelTesting iii. Integration LevelTesting iv. System LevelTesting v. User Acceptance LevelTesting 12. Levels of Testing: Unit Level Testing i). Unit LevelTesting:- Unit is defined as a smallest part of an application In this level each and every Unit developed will be tested by the developers or white box test engineer. I.e: Unit testing will test the structural part 13. Levels of Testing :Module level Testing ii) Module LevelTesting Module: A group of related features to perform a major task is known as a module EX: Medical Application In patient, Out Patient data. 14. Levels of Testing: Module Level Testing ii) Module LevelTesting In this level every module developed will be sent to the testing department and the test engineers will testing the functional part of the module 15. Integration level Testing: In this level the Developers will develop the interfaces in order to integrate the modules . While integration they will check the each and every interface is working fine or not as it is done by white box testers.This level of testing falls in white box testing. The Developers will be following any one of the following approaches in order to integrate the modules 16. Levels of Testing: Integration level Testing Top-Down Approach:- Bottom-Up Approach:- Hybrid or Stand with Mixed Approach:- Big Bang Approach:- 17. Levels of Testing: Integration level Testing Top-Down Approach:-In this approach the parent modules will be developed first and then the corresponding child module will be develop and Integrate Main Module Ex: GMail: Login page Sub Module 2 Ex: Gmail Sent Mail Sub Module 3 Ex: Gmail: Drafts Sub Module 4 Ex: Gmail: Spam Sub Module 5 Ex: Gmail Contracts Sub Module 6 Ex: GmailTasks Sub Module 1 Ex: Gmail: Compose Mail Stub 18. Levels of Testing: Integration level Testing Bottom-Up Approach:-In this approach the child modules will be developed first and then the corresponding parent module will be develop and Integrated Main Module Ex: GMail: Login page Sub Module 1 Ex: Gmail: Compose Mail Sub Module 2 Ex: Gmail Sent Mail Sub Module 3 Ex: GMail: Inbox Driver 19. Levels of Testing: Integration level Testing Hybrid Approach or Sandwich approach :-It is Mixed Approach of both theTop down& bottom up approach. Chief architect will decide which approach eitherTDA or BUA to fallow. Main Module Sub Module 4 Sub Module 5 Sub Module 6 Sub Module 2 STUB Sub Module 3 Driver 20. Levels of Testing: Integration level Testing ii) Big Bang Approach: In big bang Integration testing, individual modules of the programs are not integrated until every thing is ready. Defect multiplication is a Major disadvantage In Big Bang Approach no chance of missing Module Sub Module 4 Ex: Gmail: Compose Mail Sub Module 5 Ex: Gmail Sent Mail Sub Module 6 Ex: GMail: Inbox Sub Module 1 Ex: GMail: Login Page Sub Module 2 Ex: GMail: Drafts Sub Module 3 Ex: Spam 21. Levels of Testing: Integration level Testing Stub:While integrating the modules in top down approach if at all any mandatory module is missing then that module is replaced with a temporary program known as stub Driver:While integrating the module in bottom up approach if at all any mandatory module is missing then that module will be replaced with a temporary program known as driver 22. Levels of Testing: System Level Testing System LevelTesting:- In this level the complete application will be installed in to the environment and we will be perform so many types of testing as follows. System IntegrationTesting LoadTesting PerformanceTesting StressTesting UsabilityTesting CompatibilityTesting etc. 23. Levels of Testing: system LEVEL TESTING System IntegrationTesting: It is aType of Testing in which one will perform the action at one module & check for reflections in all related modules. Ex:WMPlayer , open a file and play it Ex: Car:- 24. Levels of Testing: User acceptance Testing This is the final level of testing conducted in the S/W company where in the user will be invited and upon his design what ever the areas he wants all those areas will be tested by our test engineers in order to make the customer to accept the application. 25. Levels of Testing: Conclusion:Testing will not be done at one stage(Level). It will done at Unit level, Module level, Integration level, System level, User Acceptance level. UnitTesting ModuleTesting IntegrationTesting SystemTesting User AcceptanceTesting 26. Environments Environment:- Environment is a combination of 3 layers o Presentation Layer o Business Layer o Database Layer Where we can install presentation logic, business logic & Database logic Application= PL+BL+DL 27. Types of environments There are 4Types of Environments Stand Alone Environment (or) One-Tier Architecture Client Server Environment(or)Two-Tier Architecture Web Environment(or)Three-Tier Architecture Distributed Environment(or)N-Tier Architecture 28. Environment: stand alone environment In this Environment the presentation layer, business layer and Database Layer will be present in a single tier Ex: Games, OS, Mobile Application, MSOffice etc If the at the application need to be used by a single(Independent users) users then we can Suggest the stand alone environment. 29. Environment: Client server environment(2-tier architecture) In this Environment 2-tiers will be the one is for clients and the other is for server.The presentation layer & the business layer will be presenting in each and every client & the database layer will be present in the server. Client=PL+BL Server=DL 30. Environment: Client server environment(2-tier architecture) If at all the application need to be used multiple users in a single organization or single building and if at all the application need to be accessed very firstly then we can use the client server environment. 31. Environment: Web environment This Environment contain 3 tier, one for Client, the middle one for application server and the other is for database server. 32. Environment: Web environment(3- tier architecture Client Server Application server Database server. Client Server: Presentation logic will be present in all the clients Application server: Business logic will be present in Application server Database server: Database logic will be present in Database server Ex:Web applications 33. Environment: Distributed environment This Environment is similar to web environment No of Application server are increased in order to distribute the load(No of Users) 34. Environment: Distributed environment If at all the application need to be use all over the world by more number of users this environment can be suggested Ex: Google, SKYPE YAHOO 35. Types of Testing: 1. Build Acceptance Testing (or) Build Verification Testing/Smoke Testing Shakeout Testing/Environment Readiness/Health Check It isType ofTesting in which one will conduct an overall testing on the released build in order to check whether it is proper for further detailed testing or not In BAT we will check whether the build can be properly installed into the Environment or not Whether one can navigate to all the pages of the application or not Whether all objects are available and properly arranged or not Whether all the required connects are properly established or not Some companies even call this type of testing as smokeTesting. 36. Types of Testing: 2. Regression Testing It is a type of testing in which one will perform Testing on the already tested functionality again and again Usually we do it into 2 scenarios 1) Whenever we indentified the defects send to the development team, once next build is released then the testers will test the defect fixed functionality as well as the related functionality once again known as regression testing 2) Whenever some new features are added to the application, build is released to Test Department.Then the testers will test all the related functionality of new features is known as regression testing. 37. Types of Testing: 3. Usability Testing It is a type of testing in which one will perform User friendliness of the screens (or)Application Ex: Error Messages, Icon messages 38. Types of Testing: 4. Port Testing It is a type of testing in which one will install the application in the client environment and check whether it is compatible with that environment or not 39. Types of Testing: 5. Installation Testing It is a type of testing in which one will install the application in the environment by following the guidelines given in the deployment document in order to check whether those guidelines or perfect for installing the application in to the environment or not 40. Types of Testing: 6. Compatibility Testing It is a type of testing in which one will install the application in to no. of environments prepared with different combinations in order to check whether the application is compatible with those environments or not Just before releasing to the customer we will perform this testing Usually this type of testing conduct on products 41. Types of Testing: 7. Exploratory Testing It is a type of testing in which the domain experts will perform testing on the application without having the knowledge of the requirements just by parallel exploring the functionality Ex: Bank Application 42. Types of Testing: 8. Monkey Testing It is a type of testing in which one will perform some abnormal actions on the application Ex: Hitting the GUI Buttons no of times, Clicking the links again and again 43. Types of Testing: 9. End to End Testing It is a type of testing in which one will perform testing on the end to end scenarios of the application Ex: When we change technology(Database) we will do this testing 44. Types of Testing: 10. Soak Testing(or)Reliability Testing Soaking:-Doing something continuously for long period of time Reliable:How long he will be continuously working? It is a Type of testing in which one will use the application continuously for long period of time in order to check the stability of the application 45. Types of Testing: 11. Mutation Testing: It is a Type of testing in which one will perform testing on the application or its related parts by doing some changes to them Ex: Regression Testing using different type of test data 46. Types of Testing: 12. Adhoc Testing: It is a Type of testing in which the testers will perform testing on the application in their own style after understanding the requirements clearly. Once the formal testing is done then we can go for Adhoc testing 47. Types of Testing: 13. Security Testing: It is a type of security testing in which one will enter different combinations of usernames and passwords in order to check whether the application is allowing only the authorized users or not. Ex: Yahoo Mail, GMAIL 48. Types of Testing: 13. Security Testing: It is a type of security testing in which one will enter direct URLs of the secured pages and check whether the application is allowing them to access or not. 49. Types of Testing: 13. Security Testing: It is a type of security testing in which one will enter into the application as one level of user and try to access the other level of user pages in order to check whether the firewalls are working properly or not Ex: Antivirus 50. Types of Testing: 14. Static Testing It is a type of testing in which one will perform testing on the application or its related parts without performing any actions Ex: GUI Testing, Document Testing, Code Reviews Etc 51. Types of Testing: 15. Dynamic Testing It is a type of testing in which one will perform testing on the application or its related parts by performing some is actions is called as dynamic testing Ex: Functionality Testing 52. Types of Testing: 16. Performance testing Performance testing is the most effective way to decide an application or an environments capacity and scalability. Performance testing is the process of determining the speed (or) effectiveness of a computer, network, software program or device. The expected performance ratio of users to response times will be identified before the tests are carried out. 53. Types of Testing: 17. Stress Testing: Testing the applications response when there is a scarcity for system resources The application is tested against heavy load such as complex numerical values, large number of inputs, large number of queries etc. which checks for the stress/load the applications can withstand. 54. Types of Testing: 18. Volume Testing: : Testing the applications with voluminous amount of data and see whether the application produces the anticipated results (Boundary value analysis) 55. Types of Testing: 19. Load Testing: It verifies the performance of the server under stress of many clients requesting data at the same time 56. Types of Testing: 20. Functional Testing / Functionality Testing: Functional testing is the process of confirming the functionality of the application. Generally this form of testing can be scripted directly from the menu options of the application. 57. Types of Testing: 20. Database Testing: Database testing done manually in real time, it check the data flow between front end back ends Observing that operations, which are operated on front-end is effected on back-end or not. The approach is as follows: While adding a record there front-end check back-end that addition of record is effected or not. So same for delete, update, Some other database testing checking for mandatory fields, checking for constraints and rules applied on the table , some time check the procedure using SQL Query analyzer 58. Types of Testing: 20. Alpha Testing(UAT): Testing of an application when development is nearing completion, Minor design changes may still be made as a result of such testing. Alpha Testing is typically performed by end-users or others, not by programmers or testers 59. Types of Testing: 21. Beta Testing(UAT): Testing when development and testing are essentially completed and final bugs, problems need to be found before the final release. Beta Testing is typically done by end-users or others, not by programmers or testers 60. Types of Testing: 22. Sanity Testing If we are moving a build from staging / testing server to production server, sanity testing of the software application can be done to check that whether the build is sane enough to move to further at production server or not. 61. Types of Testing: 23. Recovery Testing Recovery testing is basically done in order to check how fast and better the application can recover against any type of crash or hardware failure etc(abnormal state to normal state). Type or extent of recovery is specified in the requirement specifications. 62. Types of Testing: 23. User Interface Testing (or) structural testing It verifies whether all the objects of user interface design specifications are met. It examines the spelling of button test, window title test and label test. Checks for the consistency or duplication of accelerator key letters and examines the positions and alignments of window objects 63. Testing Term Definitions Defect: It A deviation from specification or Any thing that caused customer dissatisfaction Test Bed: A group of test scripts which, when taken together, test all functions of an entire system Audit: An inspection/assessment activity that verifies compliance with plans, policies and procedures Baseline: A quantitative measure of the current level of performance Bug: A catch all term for all software defects or errors Productivity: production costs, this involves prevention, appraisal, internal & external failure costs Cyclamate Complexity:The number of decision statements plus one 64. Testing Term Definitions Life CycleTesting:The process of verifying the consistency, completeness and correctness of software at each phases of the development life cycle 65. Testing Term Definitions Quality: Quality is the customers perception of how a good or service is fit for their purpose and how it satisfies stated and implicit specifications. QualityAssurance:The set of activities(including facilitation, training, measurement, and analysis Needed to provide adequate confidence that process are established continuously improved to produce products that meet specifications and are fit for use Quality Control:The process by which product quality is compared and detected w.r.t requirements and other relevant specifications, focus is in detection and removal Test item: A software item that is an object of testing User:The customer that actually uses the product received 66. Testing Term Definitions Desk Check:Verification technique conducted by the Author of the artifact to verify the completeness Dynamic Assertion: Inspection: A formal assessment of a work product conducted by one or more qualified independent reviewers to detect defects, violation of development standards, Etc. Inspection identifies defects but does not attempt to correct them 67. Testing Term Definitions Project: Project is Something i.e developed based on particular customers Requirement for his usage Product: Product is something i.e developed based on the companies specification & used by multiple customers UnconventionalTesting: Unconventional testing is a sort of testing in which the Quality Assurance(QA) People will check each and every out come document. ExInitial phase of the SDLC ConventionalTesting: It is a sort of testing in which theTest Engineer will Check the application or its related parts in the testing phase of SDLC. Ex ModuleTesting 68. Testing Term Definitions Verification:-Verification is a process of checkingWhether each and every role in the organization are performing their tasks according to the companies process guidelines or not "Are you building it right?" It is Quality Control Process Ex: software development cycle meets the customer requirement or not 69. Testing Term Definitions Validation:-Validation is a process of checking Whether they developed application or its related parts are working according to the requirements or not "Are you building the right thing?" It is Quality Assurance Process Ex: SystemTesting, FunctionalTesting ,Etc 70. SoftwareTesting Life Cycle 1.Test Planning 2.Test Development 3.Test Execution 4. Result Analysis 5. BugTracking/DefectTracking 6. Reporting 71. SoftwareTesting Life Cycle: 1.Test Planning 1. Test Plan:Test plan is a strategic document which describes how to perform testing an application in an effective, efficient and optimized way. Test plan will be prepared by theTest Lead (or) Test Manager 72. SoftwareTesting Life Cycle: 1.Test Planning Index of theTest Plan(or)Contents of theTest plan 1.0 Introduction. 1.1 Objective 1.2 Reference Documents 2.0 Coverage ofTesting 2.1 Features to beTested 2.2 Features not beTested 3.0Test Strategy 3.1 Levels of testing 3.2Types ofTesting 3.3Test designTechniques 3.4 Configuration Management 3.5Test Metrics 3.6Terminology 3.7 Automation Plan 3.8 List of AutomatedTools 73. SoftwareTesting Life Cycle: 1.Test Planning Index of theTest Plan(or)Contents of theTest plan 4.0 Base Criteria 4.1 Acceptance Criteria 4.2 SuspensionCriteria 5.0Test Deliverables 6.0Test Environment 7.0 Resource planning 8.0 Scheduling 9.0 Staffing andTraining 10.0 Risk and Contingencies 11.0Assumptions 12.0Approval Information 74. TEST PLAN TEST PLAN REF NO: DATE: TYPE OF TESTING: PROJECT/MODULE: REFERENCE DOCUMENTS: TEST ITEMS: (GIVE A LIST OF ITEMS, ie. MODULES, FORMS, REPORTS, PROGRAMS THAT GET TESTED) FEATURES TO BE TESTED: FEATURES NOT TO BE TESTED: TEST ENVIRONMENT: TEST TOOLS: SUSPENSION CRITERIA: (GIVE THE CRITERIA WHEN A TEST WOULD BE SUSPENDED) RESUMPTION REQUIREMENT: (IF A TEST IS SUSPENDED, GIVE THE CRITERIA WHEN THE TEST WOULD AGAIN BE RESUMED) COMPLETION CRITERIA: REFER CURRENT PROJECT PLAN FOR SCHEDULE, TASK AND RESPONSIBILITIES NAME SIGNATURE PREPARED BY REVIEWED BY APPROVED BY 75. SoftwareTesting Life Cycle: 1.Test Planning Index of theTest Plan(or)Contents of theTest plan 1.0 Introduction:-The purpose of the document will be clearly describe here in this section, 1.2 Reference Document:- The list of all the documents that are refer by the author, to prepare this document will be listed out in this section Ex: SRS & Project Plan 2.0Coverage ofTesting: - 2.1 Features to beTested The list of all the features that we within the Scope and need to be tested will be listed out in this section 2.2 Features not beTested:-The list of all the features based on the following criteria that are not to be tested will be listed out here in this section 1). Out of Scope features 2). Low risk Features 3).Features that are planned to be incorporated in future 4). Features that are Skipped based on the time constraints 76. SoftwareTesting Life Cycle: 1.Test Planning Index of theTest Plan(or)Contents of theTest plan 3.0Test Strategy:- What is deference between test plan andTest Strategy? Test Strategy: Test Strategy is a organization level term which is used for testing all the projects in the organization Test Plan:-Test Plan is a project level term which is used for testing a particular project in the Organization 3.1 Levels ofTesting:- The list of all the levels of testing that we followed by the company will be specified here in this section Ex: System LevelTesting 3.2Types ofTesting:- The List of all the types of testing that are conducted in that company will be specified here in this section Ex: FunctionalTesting, CompatibilityTesting, Data baseTesting 3.3Test DesignTechniques:- Techniques:-Technique is some thing that is used for accomplishing a complex task in a easy manner.The lest of all the techniques that are used in that company while designing the test cases will be listed out here in this section 77. SoftwareTesting Life Cycle: 1.Test Planning Index of theTest Plan(or)Contents of theTest plan 3.5Test Metrics(Measurements):- The list of all the metrics maintained by that company will be listed out here in this section 3.6Terminology: The list of all the terms used in that company along with their meanings will be listed out here in this section 3.7 Automation plan:The list of all the areas that are planning for automation will be listed out here in this section Ext: QTP 10.0 3.8 List of AutomationTools:The list of all the automated tools that are used in that company will be listed out here in this section QTP 10.0,QC10.0 78. SoftwareTesting Life Cycle: 1.Test Planning Index of theTest Plan(or)Contents of theTest plan 4.0 Base Criteria:- 4.1: Acceptance Criteria:- Q:When to stopTesting? Feeling that enough the testing has been done on the application will be clearly described in this section Ex:Testing should be stopped at deadlines only Ex:-When ever the user acceptance testing is pass then testing can be stopped 4.2:SuspentionCriteria:- When to suspend the testing will be described here in this section Eg:-Whenever one can not navigate to most of the parts of the application Ex:Without UAT we cant continue testing will suspend 3.7Test Deliverables:The list of all the documents that are to be prepared and delivered during the testing process will be listed out here in this section. Ex:Test case documents, Defect profile documents, Summery Report 79. SoftwareTesting Life Cycle: 1.Test Planning Index of theTest Plan(or)Contents of theTest plan 6. Test Environment:- The details of the environment that is about to be used for testing will be clearly describe here in this section 7. Resource Planning:- Who has to do what?Will be clearly describe here in this section 8. Scheduling: The starting dates and ending dates of each and every task will be specified here in this section 9. Staffing (Hiring)&Training:-how much staff is to be recruited and what kind of training is to be provided will be clearly mentioned here in this section. 10. Risk & Contingencies:- Risk:- Ex:- Employees may be leave in the middle from organization Unable to meet dead lines or Customer imposed dead lines Unable to test all the features within the available time 80. SoftwareTesting Life Cycle: 1.Test Planning Index of theTest Plan(or)Contents of theTest plan Mitigation (or)Contingencies:- Ex:- Employees need to be maintained on the bench What not to be tested need to be plan in case of customer imposed dead lines Priority based execution/Testing 81. SoftwareTesting Life Cycle: 1.Test Planning Index of theTest Plan(or)Contents of theTest plan 11. Assumptions:- The list of all the assumptions that are to be assumed by a test engineer will be listed out here in this section Ex:-Assuming, Imaging, 12.Approval Information:-Who has approved and when it is approved Will be clearly mentioned here in this section Test Plan:-Test Manager approval Test case doc:- BA Approval 82. SoftwareTesting Life Cycle: 2.Test Development I) Use CaseTemplate Use Case Template Use Case Name Brief Description of Use case Actors Involved Special Requirements Explicit Requirements Implicit Requirement Pre- Conditions Post- Conditions Flow of Events Main Flow(or)Basic Flow Actor Action Response Alternative Flow Actor Action Response 83. UseCase:- Use case is a description of actors, actions and response Input information required to prepare the use cases Ex: Screen shot for Login screen Use CaseTemplate:- Use Case Name:- Login ScreenUse Case Brief Description ofUse case:-Describes the functionality of the feature present in the login screen. Actors Involved:- Normal User and Administrator Special Requirements:There are 2Types Explicit Requirements:- Explicitly specified by the customer as known as Explicit requirements Ex: User Name, Password Implicit Requirement:-Analyzed by the business analyst which adds some values to the application without effecting any of the customer requirement are know as implicit requirements Ex:ToolTip, Messages, help SoftwareTesting Life Cycle 2.Test Development I) Use CaseTemplate 84. SoftwareTesting Life Cycle: 2.Test Development I) Use CaseTemplate Use CaseTemplate:- Pre-Conditions :-The conditions that are to be satisfied before starting a task are known as pre condition Ex: User Name and Password should be create initially Post-Conditions:The conditions that are to be satisfied at the end of the task (or) after finishing the task are known as post-conditions Ex:The Error messages should display for invalid users Flow of Events: 85. SoftwareTesting Life Cycle : 2. Test Development I) Use CaseTemplate Use CaseTemplate:- Flow of Events Flow of Events Main Flow(Basic Flow) Actions Response Alternate Flow Actions Response 86. Action Response I. Actor invokes the application II. Actor enters valid Username andValid password and clicks login button I. Application displays the log screen with the following field II. Authenticates, either home page (or) admin page is displayed depending upon the actor entered SoftwareTesting Life Cycle : 2.Test Development: 1. Use CaseTemplate I. Main Flow 87. Action Response I. Actor enters Invalid username, Valid Password and click on Login button I. Authenticates, Application displays the following error message Invalid User Name Please try again SoftwareTesting Life Cycle : 2.Test Development: 1. Use CaseTemplate II)Alternative Flow 88. SoftwareTesting Life Cycle: 2.Test Development 2.Types ofTest Cases: Types of Test Cases: Test cases are broadly divided into 3 types GUI Test Cases Look and feel testing Functional Test cases Related to functionality Non functional Test Cases Non-functionality testing Performance Testing 89. SoftwareTesting Life Cycle : 2.Test Development 2.Types ofTest Cases: 1. GUITest Cases:- The Idea is related to look and feel testing are known as GUITest Cases 2. FunctionalTest Cases:-The Idea is related to functionality testing are known as functional test cases Functional test cases are further divided into 2 types Positive test Cases NegativeTest Cases 3. Non-FunctionalTest Cases:-The idea related to non-functionality testing like performance testing, CompatibilityTesting, InstallationTesting Etc 90. SoftwareTesting Life Cycle : 2.Test Development 2.Types ofTest Cases: Guidelines forWriting GUITest cases: Check for the availability of all the object Check for the consistency of all the objects(size, font, color) Ex:Whether objects are neatly arranged or not) Check for the alignments of all the objects in case of customer requirement (Whether objects are arranged in a perfect place or not) Check for the spelling & grammar Apart from the above guidelines any thing else can be checked just by looking & feeling will fall under GUI test cases 91. SoftwareTesting Life Cycle : 2.Test Development 2.Types ofTest Cases: FunctionalTest Cases:- FunctionalTest Cases:- Guidelines forWriting the positive test cases: Test engineer should consider the positive flow of the application Test engineer should have positive mind set Ex:Valid U.N and P.W for Login Screen One should use only the valid test data from the point of the functionality 92. SoftwareTesting Life Cycle : 2.Test Development 2.Types ofTest Cases: Guidelines forWriting the Negative test cases: Test engineer should consider the negative flow of the application Test engineer should have negative mind set Ex:Valid U.N and invalid P.W for Login Screen One should use only the invalid test data from the point of the functionality 93. SoftwareTesting Life Cycle :2.Test Development Test Case Design: Test Case Design: Characteristics of a GoodTest:- Test are likely to catch bugs No redundancy Not too simple or too complex(Medium complexity) Always list expected results Before testing, the tester should plan what kind of data he is giving for test Tip:Test case is going to be complex if you have more than one expected Result 94. SoftwareTesting Life Cycle :2.Test Development Test Case Design: Test CaseTemplate: Test Cases:-Test Case is an idea of a test engineer based on the requirement to test the application or its related parts (Or)An input operation and the corresponding expected output in order to test a small unit of work Test Scenarios:-Test scenario is defined as situation that is to be tested Note:-To test each test scenario we will be having no. of test cases Test Script :- A logical group of test cases which, when taken together, test a particular function or unit of a system 95. SoftwareTesting Life Cycle : 2.Test Development Test Case Design methods: Test Case Design methods: 1. Equivalence Partitioning 2. BoundaryValueAnalysis 3. Error Guessing 4. StateTransition 5. Decision tables 96. SoftwareTesting Life Cycle : 2.Test Development Test Case Design methods: 1. Equivalence Partitioning Equivalence class is a subset of data that is representative of a larger class. Divide input domain into equivalence classes Attempt to cover classes of error One test case per equivalence class, to reduce total number of test cases needed 97. SoftwareTesting Life Cycle :2.Test Development Test Case Design methods: 1. Equivalence Partitioning Ex:A program which accepts credit limits with a given range say Rs:10,000 to 15,000 This would have three equivalence class Less than Rs.10,000(Invalid) Between Rs.10,000 and Rs.15,000(Valid) Greater than Rs:15,000(Invalid) Ex: Please view below test data for Equivalence Partitioning Less than Rs:10,000 Rs:9800 Between Rs:10,000 to Rs:15000 Rs:12500 More than Rs:15000 Rs:18000 98. SoftwareTesting Life Cycle :2.Test Development Test Case Design methods: 2. BoundaryValue Analysis A technique that consists of developing test cases and data that focus on the input and out put boundaries of a given function In practice, more errors found at boundaries of equivalence classes than within the classes In the same credit limit Ex the boundary analysis would test Low boundary plus or minus one like 9,999 (Invalid)and 10,001(valid) On the boundary like 10,000 and Rs.15,000 (Any value)(Valid) Upper boundary plus or minus one like Rs:14,999 (Valid)and 15,001(Invalid) Ex: Please view below test data for BoundaryValue Analysis Low boundary plus or minus one Rs:9,999(10,000-1) Rs,10,001(10,000+1) On the boundary Rs:10,000 to Rs:15000 Upper boundary plus or minus one Rs:14,999(15000-1) Rs:15,001(15000+1) 99. SoftwareTesting Life Cycle : 2.Test Development Test Case Design methods: 3. Error Guessing Based on the theory that test cases can be developed based upon the experience of the test engineer. In an Example where one of the inputs is the date and the test engineer may try Feb 29,2013 100. SoftwareTesting Life Cycle : 2.Test Development Test Case Design methods: 4. StateTransition When changes occurring in the state based behavior or attributes of an object or the various links that the object has with other objects can be represented by this technique. State models are ideal for describing the behavior of a single object . State transition is State-based behavior of the instances of a class. Ex..Operation of an Elevator 101. SoftwareTesting Life Cycle :2.Test Development Test Case Design methods: 4. Decision tables Decision tables, like flowcharts and if-then-else and switch- case statements, associate conditions with actions to perform, but in many cases do so in a more elegant way. Ex: Printer troubleshooter 102. SoftwareTesting Life Cycle : 2.Test Development Test Case Design methods: The limited-entry decision table is the simplest to describe.The condition alternatives are simple Boolean values, and the action entries are check-marks, representing which of the actions in a given column are to be performed. A technical support company writes a decision table to diagnose printer problems based upon symptoms described to them over the phone from their clients. The following is a balanced decision table. 103. SoftwareTesting Life Cycle :2.Test Development Test Case Design: Test CaseTemplate: Project Name: Module Name: Prepared By: Reviewed By: Test Objective: Test Scenarios: Test Data: 104. Project Name RMC Module Name: Validate Prepared By: Kumar Reviewed By: MVK Test Objective Functionality Test Test Scenarios Roles Test Data xxxxxx S.NO Test Case ID Req Id Test Case Type Test Data Prerequisite Description Expected Result Actual Result Result Pass/Fail 1 TC001 RQ001 Functional xxxxx 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 105. SoftwareTesting Life Cycle : 3.Test Execution: 3. Test Execution In this phase the test engineer will be doing the following. He will perform the action that is described in the Description column from theTest Cases He will observe the actual behavior of the application(test) He will write the observed behavior under the Actual Result column 106. SoftwareTesting Life Cycle : 4.Result Analysis: 4. Result Analysis: In this phase the test engineer will compare the Expected Result with the Actual Result If both are matching then the result will be Pass other wise the result will be Fail If at all the test case cannot be executed then the result will be Blocked 107. SoftwareTesting Life Cycle : 5. BugTracking/Defect Tracking 5. BugTracking: Bug tracking is a process in which the defects are Identified, Isolated, and managed 108. Defect profile template:- Project Name Project Name ModuleName: PreparedBy: ReviewedBy: S.NO Defect ID Test Case ID Defect Description Steps for Reproduce Submitted by Defect 1 23 TC001 RQ001 Kumar 2 TC002 3 4 5 6 7 8 9 10 11 12 Defect Pro 109. SoftwareTesting Life Cycle : 5. BugTracking/Defect Tracking Defect ProfileTemplate: Bug tracking is a process in which the defects are Identified, Isolated, and managed Defect Id:-The sequence of defect numbers will be specialized here In this section Defect Description:-What exactly the defect will be clearly described here in this section Steps for Reproducibility:-The steps that are followed byTest engineer to identify the defect will be specified here in this section. So that whenever the developer wants to reproduce the defect he will follow the same steps 110. SoftwareTesting Life Cycle : 5. BugTracking/Defect Tracking Defect ProfileTemplate: Submitted by:-The Name of the test engineer who has submitted the defect will be mentioned here in this section Date of Submission:-The date on which the defect is submitted will be mentioned here in this section Build No:-The corresponding build number will be mentioned here in this section Version No:-The Corresponding version number will be motioned here in this section Assigned to:-The Name of the developer to whom the defect is assigned will be specified here in this section by the development lead 111. SoftwareTesting Life Cycle : 5.BugTracking: Defect ProfileTemplate: Severity:- Severity describes the seriousness of the defect. Severity is classified into 4 types Critical-Severity 1 Major-Severity 2 Minor-Severity 3 Cosmetic- Severity 4 Suggestions -Severity 5 112. SoftwareTesting Life Cycle : 5.BugTracking: Defect ProfileTemplate: Critical-Severity 1:If at all the problem are related to navigational blocks unavailability of functionality then such type of problem can be treated as Critical defects Ex:- Not able to work with the application Major-Severity 2:-If at all the problem are related to the working of functionality then such type of problem can be treated as Major defects Ex: One particular functionality Minor-Severity 3:-If at all the problems are related to minimum functionality of the application then such type of problem can be treated as Minor 113. SoftwareTesting Life Cycle : 5.BugTracking: 4. Defect ProfileTemplate: Cosmetic- Severity 4:- If at all the problem are related to look and feel of the application then such type of problems can be treated as Cosmetic defects Suggestions -Severity 5:If at all the problems are related to the value of the application then such type of problems can be treated as suggestions. Ex: Use friendly messages 114. SoftwareTesting Life Cycle : 5.BugTracking: 4. Defect ProfileTemplate: Priority:- Priority describes the sequence in which the defect has to be rectified(fixed) . Priority is classified into 4 types Critical Priority 1 High Priority 2 Medium Priority 3 Low Priority 4 115. SoftwareTesting Life Cycle : 5.BugTracking: Usually in Normal situation we can Define as below Critical (Fatal)defect are given critical priority Major defects are given High priority Minor defects are given Medium priority Cosmetic defects are given Low priority Suggestions defects are given lesser priority 116. SoftwareTesting Life Cycle : 5. BugTracking/Defect Tracking Ex:- Least Severity Highest Priority:- Whenever there is a Customer visit all the look & Feel defects which are usually less Severity will be given highest priority Ex:- Highest severity Least priority:- Whenever some part of the application is not released to the testing department as it is under development the test engineer will consider then as Critical Defects but the Development lead will be giving the less priority for them 117. SoftwareTesting Life Cycle : 5. BugTracking/DefectTracking New Open Fixed Re-open (or) Closed 6.Bug life Cycle/Defect life cycle 118. SoftwareTesting Life Cycle : 5. BugTracking/DefectTracking New:- If at all the defect is found for the first time the test engineer will set the status as New Open:-If at all the defect is accepted by developer then he will set the status as open Fixed:- After rectifying the defect the developer will set the status as Fixed Re-Open and Closed:-Whenever the next build is released the testers will check whether the defects are really rectified or not. If they feel they are really rectified then they will set the status as CLOSED HOLD:-Whenever the developer is confused to accept or reject the defect he will set the status as HOLD Rejected:- If at all the developer conforms it is not a Defect he will set the status as Rejected 6.Bug life Cycle/Defect life cycle 119. SoftwareTesting Life Cycle : 6. Reporting Finally the test lead will be preparing the Test summary Report with the information like number of test cases written, number of test cases executed, no.of cycles of execution duration of execution, total no.of defects and etc With this the testing process will come to a end 6.Bug life Cycle/Defect life cycle 120. SoftwareTesting Life Cycle : 6. Reporting 1. Classical Bug Reporting Process:- In this processTester usually send mails to Dev team Reg Defects details Drawbacks:- Time Consuming Redundancy NoTransparency No Security 121. SoftwareTesting Life Cycle : 6. Reporting 2. Common repository oriented Bug Reporting Process:- In this processTesters and Developers use common shared location for reporting bugs etc .. Ex: Sharing the files from the server Drawbacks:- 1. Time Consuming 2. Redundancy 3. NoTransparency 122. SoftwareTesting Life Cycle : 6. Reporting 3. BugTrackingTool Oriented Bug Reporting process:- It is a software application which can be accessed only by the authorized people and provides all the facility for the bug tracing purpose Ex: Bugzilla, problem Reporter tracker, issue tracker FreeTools site names:http://www.software-pointers.com/en-defecttracking- tools.html 6.Test Closer Activity 123. SoftwareTesting Life Cycle : 3.Traceability Matrix (or) Cross Reference Matrix:- It is a document which contains a table of linking information and used for tracking back for the reference in any kind of confusion (or) questionable situation