Software testing for biginners

Download Software testing for biginners

Post on 18-Nov-2014




2 download

Embed Size (px)


A presenetation on basics of software testing, explaining the software development life cycle and steps invovled in it and detials about each step from the testing point of view.


<ul><li> 1. Software Testing What do you think software testing could be? Software testing is nothing but checking the quality of the applicationsystem manually or by automating it to check whether the actual result matches the expected result </li></ul> <p> 2. SDLC Software Development Life Cycle is a step by step procedure to develop a software and it consists of following phases, Requirements Feasibility study Designplan Coding Testing Installationdeployment Maintenance 3. SDLC Models Water fall model Spiral model Prototype model V and V model Hybrid model Agile methodology (mostly used) Each will be dealt in detail 4. Black box testing Testing the behavior of an application according to the requirement specification is black box testing. Types are, Functional testing Integration testing System testing UAT Smoke and Sanity testing Adhoc testing Compatibility Usability testing 5. Conti.. Functional testing: Testing each and every component of the application. Integration testing: Testing the data flow between 2 modules or checking if interface is happening between modules. System testing: Testing the end to end flow of an application. UAT: User acceptance testing is a type of testing done by customers before accepting the product. Smoke: Testing the basic and critical features of an application. Adhoc testing: Testing the application randomly. Compatibility: Testing the functionality of an application across different SW and HW platforms. Usability: Testing the user friendliness of an application. 6. Test Plan &amp; Test Strategy It is a dynamic document that drives the complete testing activities. It consists of following attributes, Objective: The aim of this test plan is to test functionality of the application. Scope: It describes the features in scope and out of scope. Approach: Flow of the application or process of testing the application. The way we go about testing the Application in future, By writing high level scenarios By writing flow graphs Testing methodologies: Types of testing to be performed. Assumption: Is if any TE leaves the company is between the project. 7. Conti Risk: The quality of that module or testing of that module may be delayed or affected. Contingency or mitigation plan: To avoid the above risk we can have primary &amp; contact for every module that is tested. In the absence or primary contact, secondary contact should take care of the module. Its a back up plan prepared to avoid the assured risk 8. Conti.. Estimation: How much time required to test, Effort estimation techniques, 1. Work break down approach 2. Use case based 3. Delphi technique 4. Based on functional point 5. Based on kilo lines of code Schedules :This section contains when exactly each activity should start and end? Exact date should be mentioned and for every activity, date will be specified. Roles &amp; responsibilities: Role of a team members and lead. 9. Conti.. Templates: Contains all the templates for the documents which will be used in the project. Ex: Test Case Traceability Matrix Test Execution Report Defect Report Test Case Review Template Automation: Details of automation testing to be carried out. Defect tracking tool: Details of tool used for defect tracking. Test deliverables: It is the output from the testing team. It contains what we will deliver to the customer at the end of the project. Entry and Exit criteria: Criteria for each testing level to enter next level. 10. Test Strategy It is a document which captures the approach on how we go about testing the product. We can call Test plan as the parent document and Test Strategy as the child document. It again depends on the process followed by company. 11. Test Scenarios and Test cases Test scenario is a high level document which consists of all possible ways or combinations of testing the application. Points to be remembered while writing scenario could be, Every scenario should be simple and understandable Each scenario should be written in 1 or 2 sentences Every scenario should have Dos and checks. All the scenario should be in proper order or sequence 12. Examples of test scenarios CUP Check it can properly contain liquid and not leaked. Test that its size and shape as per user requirement or not. Test its color as per user requirement or not. Test its material as per user requirement. Test it with maximum hot/cold and minimum hot/cold liquid. Check its strength that whether it can be broken easily. Check its with heat and cold environment. Put it in front of direct sun light for hours. 13. Test Case It is in detailed step by step procedure to test the application which consists of the navigation steps and all the inputs. Types of test case: High level Test cases are those which cover major functionality in the application (i.e. retrieve, update display, cancel (functionality related test cases), database test cases). Low level test cases are those related to User Interface (UI) in the application. Advantages of test cases To have Maximum test coverage.(all the test cases are covered) To have better test consistency. Testing depends on process rather than person Time saving. 14. Examples Examples of writing test cases according to the type, 1. Login functionality: write for functional, integration and system testing. 2. Gmail inbox 15. Test case design techniques(TCDT) TCDT is the way to define the test data. There are mainly 3 types, Error guessing Equivalence partitioning Boundary value analysis Error guessing: In this the TE keeps guessing the value based on his understanding. Equivalence partitioning: If the inputs are range if values then derive the test case for 1 valid and 2 invalid data. Boundary value analysis: Values are derived like this, if (a,b) then data will be a, a+1, a-1,b, b+1,b-1. 16. Defect life cycle 17. Different statuses of bug 1. Invalid rejected: the reason for getting invalid bug could be, TE has misunderstood the requirementdev misunderstood TE dev referring to the old req 2. Duplicate: name itself says duplicate bugs 3. Not reproducible: unable to reproduce the bug when dev tests it Reasons: Improper bug report Environment mismatch Data mismatch Build mismatch Inconsistent bug 4. Wont be fixedcannot be fixed: No technology support, bug is in the core of the application, fixing of bug is costlier than retaining it. 18. Conti Postponeddeferred : 5.Request for enhancementQA suggestion 19. DefectBug report Points that need to be considered while Reporting bug, Module Requirement number Test case name Status Assigned to Author Test data used Environment: Browser and OS information. Severity and priority Brief description of the defect Steps to reproduce the defect Observationactual result Expected result Attachments 20. Severity and Priority Severity: impact of bug on the application Priority: which bug to be fixed first Write examples for, High severity high priority: blocker bugs High severity low priority Low severity high priority Low severity low priority: UI issues 21. Regression Testing Re-executing the old test cases across multiple releases or builds to make sure that changes has not affected the existing functionalities is called as Regression testing. Types of Regression testing, 1. Unit regression testing 2. Regional regression testing 3. Full regression testing. 22. Conti.. Unit Regression Testing: re-testing that fixed bug or feature(no impact area) Regional Regression Testing: testing new feature and the impact area. Full Regression Testing: testing new feature and plus the complete old features. Impact area can be found based on the impact analysis which is done at the very early stage when we get the requirements. 23. Exploratory Testing When there are no proper requirements or when requirements are not clear we go for Exploratory Testing. Explore the application. Understand the application. Document the understanding in terms of TCs and Test Scenarios. Then test the application accordingly to the documents is called as Exploratory testing. 24. Build, Patch, Release Build: is a piece of software that contains set of features, bug fixes &amp; installed onto the test server which needs to be tested for stability. Each new build is a modified version of previous build. Test cycle: it is the time duration taken to test each build. Patch: is a small piece of code which acts as an immediate fix for any kind of blockers issues so that test engineer can proceed with his testing without any time delay. Release: is a software that contains complete set of features which are developed, tested &amp; once these featured are stable it is handed over to the customer. 25. Email at: </p>


View more >