Learn software testing
•Download as PPT, PDF•
0 likes•92 views
Help beginners who want to learn software testing to know the major topics and there are an explanation for each one
Report
Share
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
Recommended for you
More Related Content
What's hot
What's hot (20)
Similar to Learn software testing
Similar to Learn software testing (20)
Recently uploaded
Recently uploaded (20)
Learn software testing
- 2. Contents • Part - 1: Quality • Part - 2: Software Testing & Development Models • Part - 3: Different Stages of SDLC with STLC • Part - 4: Testing Techniques • Part - 5: Types of Testing • Part - 6: Test Automation
- 3. Quality has two elements • QA - Quality Assurance • QC - Quality Control Part 1: Quality
- 4. • Quality from the • Customer’s Viewpoint Fitness for use, or other customer needs • Producer’s Viewpoint Meeting requirements What is Quality ?
- 5. • Software quality includes activities related to both • Process, and the • Product • Quality Assurance is about the work process • Quality Control is about the product Quality Function
- 6. • Quality assurance activities are work process oriented. • They measure the process, identify deficiencies, and suggest improvements. • The direct results of these activities are changes to the process. • These changes can range from better compliance with the process to entirely new processes. • The output of quality control activities is often the input to quality assurance activities. • Audits are an example of a QA activity which looks at whether and how the process is being followed. The end result may be suggested improvements or better compliance with the process. What is Quality Assurance?
- 7. • Quality control activities are work product oriented. • They measure the product, identify deficiencies, and suggest improvements. • The direct results of these activities are changes to the product. • These can range from single-line code changes to completely reworking a product from design. • They evaluate the product, identify weaknesses and suggest improvements. • Testing and reviews are examples of QC activities since they usually result in changes to the product, not the process. • QC activities are often the starting point for quality assurance (QA) activities. What is Quality Control?
- 8. Prevention is better than cure . . . . . . but not everything can be prevented! Cure Detection Prevention Prevention and Detection
- 9. Testing What is testing Objectives of Testing Part 2: Testing
- 10. Definition: • Testing is process of trying to discover every conceivable fault or weakness in a work product. • Testing is a process of executing a program with the intent of finding an error. • A good test is one that has a high probability of finding an as yet undiscovered error. • A successful test is one that uncovers an as yet undiscovered error What is Testing?
- 11. • Objective of testing is to find all possible bugs (defects) in a work product • Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn't or things don't happen when they should. What is objective of Testing?
- 12. Setting up criteria for testing Criteria can be at phase level Entry Criteria • Parallelism Vs Ready for use Exit Criteria • Completeness Vs Risk of release Suspension Criteria • Show stopper bugs • Crossing a threshold number of bugs • Developers producing a new version making the old one redundant Resumption Criteria • Above hurdles being cleared
- 13. • The Goal of a software tester is to find defects • And find them as early as possible. What exactly Does a Software Tester Do?
- 14. Testers hunt errors • Detected errors are celebrated - for the good of the work product Testers are destructive - but creatively so • Testing is a positive and creative effort of destruction Testers pursue errors, not people • Errors are in the work product, not in the person who made the mistake Testers add value • by discovering errors as early as possible What does testing mean to testers?
- 15. Waterfall Model for Testing
- 16. Simple and easy to use. Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process. Phases are processed and completed one at a time. Works well for smaller projects where requirements are very well understood. Advantages of Waterfall Model
- 17. Adjusting scope during the life cycle can kill a project No working software is produced until late during the life cycle. High amounts of risk and uncertainty. Poor model for complex and object-oriented projects. Poor model where requirements are at a moderate to high risk of changing. Disadvantages of Waterfall Model
- 18. It is a process of establishing requirements, designing, building and testing a system, done as a series of smaller development Increment produced by Iteration is tested at several levels as part of its development Regression testing is important after all iterations Verification and verification can be carried outs on each iteration Disadvantages of Waterfall Model
- 20. Simple and easy to use. Each phase has specific deliverables. Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle. Works well for small projects where requirements are easily understood. Advantages of W - Model
- 21. Very rigid, like the waterfall model. Little flexibility and adjusting scope is difficult and expensive. Software is developed during the implementation phase, so no early prototypes of the software are produced. Model doesn’t provide a clear path for problems found during testing phases. Disadvantages of W - Model
- 22. Stages of SDLC with STLC Part 3: Different stages of SDLC with STLC
- 23. Different stages of SDLC with STLC Stage-1 Requirement Gathering • DA: Defining requirements to establish specifications is the first step in the development of software. • TA: Reviewing the requirements e.g the requirements should not have ambiguous words like (may or may not). It should be clear and concise.
- 24. Different stages of SDLC with STLC Stage-2 Functional Specification • DA: It describes the product’s behaviors as seen by an external observer, and contains the technical information and data needed for the design. The functional specification defines what the functionality will be • TA: In order to make the functional specifications accurate we have review our functional specifications.
- 25. Different stages of SDLC with STLC Stage-3 Design • DA: The software specifications are transformed in to design models that describe the details of the data structures, system architecture, interface and the components. • TA: Each design product is reviewed for quality before moving the next phase of the software development.
- 26. Different stages of SDLC with STLC Stage-4 Code • DA: In this phase the designs are translated into code. • TA: Code review is a process of verifying the source code. Code review is done the find and fix the defects that are overlooked in the initial development phase, to improve overall quality of code.
- 27. Different stages of SDLC with STLC Stage-5 Building Software • DA: In this phase we build different software units and integrate them one by one to build single software. • TA: Unit testing & Integration testing
- 28. Different stages of SDLC with STLC Stage-6 Building system • DA: After the software has been build we have the whole system considering all the non-functional requirements like installation procedure, configuration etc. • TA: System testing & Acceptance testing
- 29. Different stages of SDLC with STLC Stage-7 Release for use • After the whole product has been developed and the required level of quality has been achieved and the software is release for the actual use of the customers.
- 30. Testing Techniques • Verification and Validation Part 4: Testing Techniques
- 31. • Reviews • Walkthrough • Inspection Verification
- 32. There are two main strategies for validating software • White Box testing • Black Box testing Validation Strategies
- 33. White Box Testing • Deals with the internal logic and structure of the code • The tests are written based on the white box testing strategy incorporate coverage of the code written, branches, paths, statements and internal logic of the code etc. • Normally done the developers Validation Strategies
- 34. White Box Testing can be done by: • Data Coverage • Code Coverage White Box testing Methods
- 35. Date Coverage • Data flow is monitored or examined through out the program. E.g. watch window we use to monitor the values of the variables and expressions. White Box testing Methods
- 36. Code Coverage • It’s a process of finding areas of a program not exercised by a set of test cases, • Creating additional test cases to increase coverage • Code coverage can be implemented using basic measure like, statement coverage, decision coverage, condition coverage and path coverage White Box testing Methods
- 37. Black Box Testing • Does not need any knowledge of internal design or code • Its totally based on the testing for the requirements and functionality of the work product/software application. • Tester is needed to be thorough with the requirement specifications of the system and as a user, should know how the system should behave in response to the particular action. Validation Strategies
- 38. The following are commonly used Black Box methods : • Equivalence partitioning • Boundary-value analysis • Error guessing Black Box testing Methods
- 39. Part 5: Various Types of Testing Validation is done at two levels • Low Level • Unit testing • Integration Testing • High Level • Function Testing • System Testing • Acceptance Testing Validation Activities
- 40. • Searches for defect and verifies the functionality of software, depending upon the context of the development • It includes testing of functional and non-functional characteristics • It occurs with access to code being tested and with the support of development environment • Defects are fixed as soon as they are found with out formally recording incident • If test cases are prepared and automated before coding, it is termed as test-first approach or test-driven development. Unit Testing
- 41. Integration Testing Integration testing tests interface between components, interaction to different parts of system. Greater the scope of Integration, more it becomes to isolate failures to specific component or system, which may leads to increased risk. Integration testing should normally be integral rather than big bang, in order to reduce the risk of late defect discovery Non functional characteristics (e.g. performance) may be included in Integration Testing
- 42. Function Testing It is used to detect discrepancies between a program’s functional specification and the actual behavior of an application. The goal of function testing is to verify whether your product meets the intended functional specifications laid out the development documentation. When a discrepancy is detected, either the program or the specification is incorrect. All the black box methods are applicable to function based testing
- 43. It is concerned with the behavior of whole system as defined by the scope of development project It includes both functional and non-functional requirement of system System testing falls within the scope of black box testing. On building the entire system, it needs to be tested against the system specification. An Independent testing team may carry out System Testing System Testing
- 44. Usability testing Performance Testing Load Testing Stress Testing Security Testing Configuration Testing Compatibility Testing Installability Testing Recovery Testing Availability Testing Volume Testing System Testing Types
- 45. Usability Testing • The typical aim of usability testing is to cause the application to fail to meet its usability requirements so that the underlying defects can be identified, analyzed, fixed, and prevented in the future. Performance testing is testing to ensure that the application response in the limit set by the user. Performance Testing Subject the system to extreme pressure in a short span. E.g Simultaneous log-on of 500 users Saturation load of transactions Stress Testing
- 46. Configuration Testing • Configuration testing is the process of checking the operation of the software you are testing with all these various types of hardware. Compatibility Testing The purpose of compatibility testing is to evaluate how well software performs in a particular hardware, software, operating system, browser or network environment.
- 47. Acceptance Testing Acceptance testing may assess the system readiness for deployment and use The goal is to establish confidence in the system, parts of system or non- functional characteristics of the system Following are types of Acceptance Testing: • User Acceptance Testing • Operational Testing • Contract and Regulation Acceptance Testing • Alpha and Beta Testing
- 48. Testing software that has been tested before. • Why? • Peripheral testing for bug fixes • Retesting the old version functionality with the new version Regression Test Why retest? Because any software product that is actively used and supported must be changed from time to time, and every new version of a product should be retested Retesting
- 49. Principles of Test Automation # 1: Choose carefully what to automate • Automate tests for highly visible areas • Minimize automating change-prone areas • Between GUI and non-GUI portion automation, go for automating non-GUI portions first • Automate tests for dependencies to catch ripple effects early • Automate areas where multiple combos are possible (pros and cons) • Automate areas that are re-usable • Automate “easy areas” to show low hanging fruits Part 6: Test Automation
- 50. Principles of Test Automation # 2: Ensure Automation Covers Full Circle Plan Do Check Act • Automatic Analysis • Fish Bone Diagrams • Problem Identification • Test Capture • Test Execution • Results Comparison • Test Planning • Automation Planning • Corrective Action Implementation • Automatic Rollover to next runs • Incorporation into Regression
- 51. • Compatibility to Platform • Portability across platforms • Integration with TCDB, DR and SCM • 2-way mapping to source code (may not be possible in services) • Scripting Language • Compatible to Multiple Programming Environments • Configurability • Test Case Reusability • Selective Execution • Smart Comparison • Reliable Support • Current documentation Principles of Test Automation # 3: Choose Proper Automation Tool
- 52. • Resources for Installation • Resources for ongoing execution • People Resources Principles of Test Automation # 4: Plan for Infrastructure
- 53. • Training • Development • Testing the Tests • Sync-ing with product version changes Principles of Test Automation # 5: Account for Gestation Period
- 54. • Start small • Don’t try to automate everything at the same time • Allow time for evolving standards Principles of Test Automation # 6: Run a Trial & Calibrate the Tool
- 55. Config File Scenarios Tools Results Reports/ Metrics Test Framework Test cases Report Generator Execute Read Read Execute Modify Write Read Write Test Automation Components
- 56. • The work on automation should go in parallel with product development • The requirements for automation spans over to multiple phases for multiple releases like the product requirements • The automation can be carried out in parallel with test design • Sometimes the test cases need to be modified to suit the automation requirements; where automation exist the test cases need not be elaborate • Where a dedicated team exist for automation, the schedule for automation can be independent of product releases, with some (tested) deliverables marked for each product release Process of Test Automation
Editor's Notes
- The following are lesser used methods Cause effect graphing Syntax testing State transition testing Graph matrix
- The following are lesser used methods Cause effect graphing Syntax testing State transition testing Graph matrix
- The following are lesser used methods Cause effect graphing Syntax testing State transition testing Graph matrix
- The following are lesser used methods Cause effect graphing Syntax testing State transition testing Graph matrix
- The following are lesser used methods Cause effect graphing Syntax testing State transition testing Graph matrix
- The following are lesser used methods Cause effect graphing Syntax testing State transition testing Graph matrix
- The following are lesser used methods Cause effect graphing Syntax testing State transition testing Graph matrix