If you don't have patience to test the system the system will surely test your patience
Testing Without Requirements—Impossible?  <ul><li>QA Team perform their job without the slightest clue of what the applica...
QA job depends on the accuracy of available documents <ul><li>Asking a tester to test with no documentation is the same as...
Paths to Do…… <ul><li>UI team prepares screenshots of the expected user interface screens. At the same time, the developme...
Better Approach: Coordination in team(Daily Meetings)  <ul><li>In the daily meetings, each team member explains what's bee...
  Develop test ideas and tactics by asking questions <ul><li>Product </li></ul><ul><li>What is this product? </li></ul><ul...
Exploratory Testing : <ul><li>Exploratory Testing is not a way of testing; It's a way of thinking about testing. </li></ul...
Many factors contribute to a tester’s choice of exploration style
<ul><li>“ Hunches” (past bug experiences, recent changes) </li></ul><ul><li>invariance (tests that change things that shou...
Exploratory Testing:  <ul><li>Simultaneously: </li></ul><ul><li>Learn about the product </li></ul><ul><li>Learn about the ...
Exploratory Testing:
Challenges: <ul><li>Learning (How do we get to know the program?) </li></ul><ul><li>Visibility (How to see below the surfa...
How to Proceed??? <ul><li>Find out what to test </li></ul><ul><li>Figure Out How Much to Test </li></ul><ul><li>Know Whom ...
Myth1: Testing starts at the end ( requirements come first) <ul><li>Testing can start right at the start </li></ul><ul><li...
What We (SAM) Do..
Myth 2 : Can’t test till it’s there ( testing the system needs to have the system ) <ul><li>Testing is more than testing, ...
What We (SAM) Do..
Myth 3: Requirements to test is a one-way street(testing uses requirements, not vice versa ) <ul><li>Thinking about testin...
What We (SAM) Do..
Myth 4: Tests are for testers only ( writing good tests is purely a testing concern) <ul><li>Ambiguous specifications – no...
What We (SAM) Do..
Myth 5: Minor changes are minor ( minor requirements changes don’t matter ) <ul><li>Impact on implementation (e.g. databas...
What We (SAM) Do..
Myth 6: Can’t test without requirements  testers MUST HAVE requirements  <ul><li>Not an excuse to avoid testing </li></ul>...
What We (SAM) Do..
Myth 8: Follow the elephant ( mainstream is more important ) <ul><li>Yes, normal use is important </li></ul><ul><li>But ex...
What We (SAM) Do..
Heuristics <ul><li>The strategy for causing the best change in a poorly understood or uncertain situation within the avail...
Suggestion and Feedback
Upcoming SlideShare
Loading in …5
×

SAM

765 views

Published on

Published in: Travel, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
765
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
69
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

SAM

  1. 1. If you don't have patience to test the system the system will surely test your patience
  2. 2. Testing Without Requirements—Impossible? <ul><li>QA Team perform their job without the slightest clue of what the application under test is supposed to do. </li></ul><ul><li>Less than ample documentation also can be blamed on changing user requirements, on-the-fly development, legacy systems for which documentation is lost or destroyed, and extremely large or expansive systems. &quot;A large system may not be documented well enough for the tester to form complete test scenarios.&quot; </li></ul>
  3. 3. QA job depends on the accuracy of available documents <ul><li>Asking a tester to test with no documentation is the same as asking them to guess.&quot; </li></ul><ul><li>Even with the lack of documents, there are certain things that can help us to do efficient testing. It doesn't substitute for having documents available, but at least helps in shipping a product with a reasonable level of confidence.&quot; </li></ul>
  4. 4. Paths to Do…… <ul><li>UI team prepares screenshots of the expected user interface screens. At the same time, the development team prepares technical design documents based on the requirements documents. The test and QA teams are given the requirements documents and screenshots and asked to develop test artifacts, a test plan, test cases and other documents. A detailed report is prepared at project completion. </li></ul>
  5. 5. Better Approach: Coordination in team(Daily Meetings) <ul><li>In the daily meetings, each team member explains what's been done since the last meeting, what (if anything) has impeded their progress, and what they plan to do until the next meeting. The daily meetings are used in place of documentation. </li></ul><ul><li>In the meetings, you will be getting feature names and maybe a short description. Find out what you are supposed to test, figure out the exact requirements and prioritize them. To do thorough testing, you will need more information than initially supplied to you </li></ul>
  6. 6. Develop test ideas and tactics by asking questions <ul><li>Product </li></ul><ul><li>What is this product? </li></ul><ul><li>What can I control and observe? </li></ul><ul><li>What should I test? </li></ul><ul><li>Tests </li></ul><ul><li>What would constitute a diversified and practical test strategy? </li></ul><ul><li>How can I improve my understanding of how well or poorly this product works? </li></ul><ul><li>If there were an important problem here, how would I uncover it? </li></ul><ul><li>What document to load? Which button to push? What number to enter? </li></ul><ul><li>How powerful is this test? </li></ul><ul><li>What have I learned from this test that helps me perform powerful new tests? </li></ul><ul><li>What just happened? How do I examine that more closely? </li></ul><ul><li>Problems </li></ul><ul><li>What quality criteria matter? </li></ul><ul><li>What kinds of problems might I find in this product? </li></ul><ul><li>Is what I see, here, a problem? If so, why? </li></ul><ul><li>How important is this problem? Why should it be fixed? </li></ul>
  7. 7. Exploratory Testing : <ul><li>Exploratory Testing is not a way of testing; It's a way of thinking about testing. </li></ul><ul><li>Any testing technique can be used in an exploratory way. </li></ul><ul><li>The Exploratory Approach is Heuristic </li></ul>
  8. 8. Many factors contribute to a tester’s choice of exploration style
  9. 9. <ul><li>“ Hunches” (past bug experiences, recent changes) </li></ul><ul><li>invariance (tests that change things that should have no impact on the application) </li></ul><ul><li>interference (finding ways to interrupt or divert the program’s path) </li></ul><ul><li>error handling (checking that errors are handled correctly) </li></ul><ul><li>troubleshooting (bug analysis (such as simplifying, clarifying, or strengthening a bug report), test variance when checking that a bug was fixed) </li></ul><ul><li>group insights (brainstorming, group discussions of related components, paired testing) </li></ul>Different styles of exploration
  10. 10. Exploratory Testing: <ul><li>Simultaneously: </li></ul><ul><li>Learn about the product </li></ul><ul><li>Learn about the market </li></ul><ul><li>Learn about the ways the product could fail </li></ul><ul><li>Learn about the weaknesses of the product </li></ul><ul><li>Learn about how to test the product </li></ul><ul><li>Test the product </li></ul><ul><li>Report the problems </li></ul><ul><li>Advocate for repairs </li></ul><ul><li>Develop new tests based on what you have learned so far </li></ul>
  11. 11. Exploratory Testing:
  12. 12. Challenges: <ul><li>Learning (How do we get to know the program?) </li></ul><ul><li>Visibility (How to see below the surface?) </li></ul><ul><li>Control (How to set internal data values?) </li></ul><ul><li>Risk / selection (Which are the best tests to run?) </li></ul><ul><li>Execution (What’s the most efficient way to run the tests?) </li></ul><ul><li>Logistics (What environment is needed to support test execution?) </li></ul><ul><li>The oracle problem (How do we tell if a test result is correct?) </li></ul><ul><li>Reporting (How can we replicate a failure and report it effectively?) </li></ul><ul><li>Documentation (What test documentation do we need?) </li></ul><ul><li>Measurement (What metrics are appropriate?) </li></ul><ul><li>Stopping (How to decide when to stop testing?) </li></ul><ul><li>Training and Supervision (How to help testers become effective, </li></ul><ul><li>and how to tell whether they are?) </li></ul>
  13. 13. How to Proceed??? <ul><li>Find out what to test </li></ul><ul><li>Figure Out How Much to Test </li></ul><ul><li>Know Whom to Ask </li></ul>
  14. 14. Myth1: Testing starts at the end ( requirements come first) <ul><li>Testing can start right at the start </li></ul><ul><li>Thinking about testing early improves requirement specifications early </li></ul><ul><li>Don’t have to wait to get benefits of a tester view </li></ul>
  15. 15. What We (SAM) Do..
  16. 16. Myth 2 : Can’t test till it’s there ( testing the system needs to have the system ) <ul><li>Testing is more than testing, and starts before testing </li></ul><ul><li>Misconception: testing = test execution </li></ul>
  17. 17. What We (SAM) Do..
  18. 18. Myth 3: Requirements to test is a one-way street(testing uses requirements, not vice versa ) <ul><li>Thinking about testing raises questions on the requirements. </li></ul><ul><li>Test design can lead to improved requirements </li></ul><ul><li>Boundary value analysis </li></ul>
  19. 19. What We (SAM) Do..
  20. 20. Myth 4: Tests are for testers only ( writing good tests is purely a testing concern) <ul><li>Ambiguous specifications – not testable </li></ul><ul><li>Non-functional quality attributes e.g. “user friendly”, “very reliable” </li></ul><ul><li>If you don’t know how to test it, how can you know how to build it? </li></ul>
  21. 21. What We (SAM) Do..
  22. 22. Myth 5: Minor changes are minor ( minor requirements changes don’t matter ) <ul><li>Impact on implementation (e.g. database, checking) </li></ul><ul><li>Impact on testing </li></ul><ul><li>What unexpected side-effects? </li></ul><ul><li>Size of change NOT = size of testing </li></ul>
  23. 23. What We (SAM) Do..
  24. 24. Myth 6: Can’t test without requirements testers MUST HAVE requirements <ul><li>Not an excuse to avoid testing </li></ul><ul><li>More responsibility on the tester </li></ul><ul><li>Exploratory testing is designed for severe time pressure and poor or non-existent requirements </li></ul>
  25. 25. What We (SAM) Do..
  26. 26. Myth 8: Follow the elephant ( mainstream is more important ) <ul><li>Yes, normal use is important </li></ul><ul><li>But exceptions must also work correctly </li></ul>
  27. 27. What We (SAM) Do..
  28. 28. Heuristics <ul><li>The strategy for causing the best change in a poorly understood or uncertain situation within the available resources. </li></ul><ul><li>Although difficult to define, a heuristic has four signatures that make </li></ul><ul><li>Its easy to recognize: </li></ul><ul><li>– A heuristic does not guarantee a solution; </li></ul><ul><li>– It may contradict other heuristics; </li></ul><ul><li>– It reduces the search time in solving a problem; and </li></ul><ul><li>– Its acceptance depends on the immediate context instead of on an absolute absolute standard.&quot; </li></ul>
  29. 29. Suggestion and Feedback

×