Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software Testing - L..


Published on

  • Be the first to comment

  • Be the first to like this

Software Testing - L..

  1. 1. SOFTWARE TESTING Przygotował: Marcin Lubawski
  2. 2. Testing Process Analyse Design Maintain Build Test Instal Software testing strategies Verification Validation System Testing / Quality Control
  3. 3. Master Test Plan 1. Test Approach Overview 2. Test Phase Definition <ul><li>Define staged testing processes to be employed to ensure full feature & function </li></ul><ul><li>compliance with documented requirements and specifications relating to the project. </li></ul><ul><li>Develop and establish structured testing environment </li></ul><ul><li>Implement structured testing processes and controls which will improve defect </li></ul><ul><li>detection, reduce iterative development </li></ul><ul><li>This section provides a high level definition of the testing processes </li></ul><ul><li>All aspects of testing should be included in this section </li></ul>
  4. 4. Master Test Plan 3. Participating Systems 4. Responsibilities 5. Resource Requirements <ul><li>Specify those systems which will incur change and those which will need to </li></ul><ul><li>participate in Integrated Systems Testin </li></ul><ul><li>Contact names and phone numbers should be indicated for each area of </li></ul><ul><li>responsibility. Include project organization chart and matrix relationships. </li></ul><ul><li>Specify individuals responsible for accepting the plan </li></ul><ul><li>Provide a matrix of the estimated manpower requirements by month </li></ul><ul><li>Specify any anticipated hardware / software costs for testing tools that have been </li></ul><ul><li>indicated in the plan. </li></ul>
  5. 5. Master Test Plan 6. Schedules 7. Glossary of Terms <ul><li>Provide a high level schedule of the major testing milestones including each test </li></ul><ul><li>phase start and end dates </li></ul><ul><li>The Master Test Plan should include a glossary of terms to assist in providing </li></ul><ul><li>clarity and understanding to the work to be performed, like: </li></ul>testing terminology acronyms application specific vocabulary
  6. 6. Testing Tactics <ul><li>White Box </li></ul><ul><li>Black Box </li></ul>
  7. 7. White Box „ White Box” Logic Work ? Meets Specs ? The System Testing based on knowledge of internal code structure and logic
  8. 8. Black Box „ Black Box” Meets Specs ? Fit for Use The System Testing based on external specifications without knowledge of how the system is constructed
  9. 9. Testing strategies 1. Unit Testing <ul><li>Functional Testing </li></ul>3. Integration Testing 2. System Testing 4. Customer Acceptance Testing <ul><li>Perforamnce Testing </li></ul><ul><li>Security Testing </li></ul><ul><li>Recovery testing </li></ul>
  10. 10. Unit Testing Unit Unit Unit Unit System
  11. 11. System Testing <ul><li>Once each of the individual modules has been tested & </li></ul><ul><li>validated to correctly perform all the instructions assigned to it, </li></ul><ul><li>the next step is to verify connectivity to related modules. </li></ul><ul><li>The system test should detect any errors promoted between </li></ul><ul><li>modules within the same system. As a result of a completed </li></ul><ul><li>system test, all internal 'hand-shaking' will have been verified. </li></ul>testing Unit Unit
  12. 12. Integration Testing Component Component Component Component System Integrated
  13. 13. Acceptance Testing If there is one customer, a series of acceptance tests are conducted (by the customer) to enable the customer to validate all requirements. If software is being developed for use by many customers, can not use acceptance testing. An alternative is to use alpha and beta testing to uncover errors.
  14. 14. Acceptance Testing <ul><li>Alpha Testing </li></ul><ul><li>Beta Testing </li></ul>Alpha testing is conducted at the developer's site by a customer. The customer uses the software with the developer 'looking over the shoulder' and recording errors and usage problems. Alpha testing conducted in a controlled environment. Beta testing is conducted at one or more customer sites by end users. It is 'live' testing in an environment not controlled by the developer. The customer records and reports difficulties and errors at regular intervals. Software Accepted
  15. 15. Performance Testing <ul><li>For real-time and embedded systems, functional requirements </li></ul><ul><li>may be satisfied but performance problems make the system </li></ul><ul><li>unacceptable. </li></ul><ul><li>Performance testing checks the run-time performance </li></ul><ul><li>May require special software instrumentation. </li></ul>
  16. 16. Security Testing <ul><li>Systems with sensitive information or which have the potential to </li></ul><ul><li>harm individuals can be a target for improper or illegal use. </li></ul><ul><li>This can include: </li></ul>1. attempted penetration of the system by 'outside' individuals for fun or personal gain. 2. disgruntled or dishonest employees
  17. 17. Security Testing <ul><li>During security testing the tester plays the role of the individual </li></ul><ul><li>trying to penetrate the system. Large range of methods: </li></ul>1. attempt to acquire passwords through external clerical means 2. use custom software to attack the system 3. overwhelm the system with requests 4. cause system errors and attempt to penetrate the system during recovery 5. browse through insecure data.
  18. 18. Recovery Testing <ul><li>Many systems need to be fault tolerant - processing faults </li></ul><ul><li>must not cause overall system failure. </li></ul><ul><li>Other systems require recovery after a failure within a </li></ul><ul><li>specified time. </li></ul><ul><li>Recovery testing is the forced failure of the software in a </li></ul><ul><li>variety of ways to verify that recovery is properly performed. </li></ul>
  19. 19. Classic Testing Mistakes <ul><li>starting testing too late </li></ul><ul><li>not testing the documentation </li></ul><ul><li>not testing installation procedures. </li></ul><ul><li>failing to correctly identify risky areas </li></ul><ul><li>recruiting testers from the ranks of failed programmers </li></ul><ul><li>physical separation between developers and testers. </li></ul><ul><li>programmers can't test their own code. </li></ul><ul><li>paying more attention to running tests than to designing them </li></ul><ul><li>poor bug reporting </li></ul>And many more ...