Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Manual Testing for Developers

Manual Testing for Developers

A basic primer on how to become a better tester and deliver code with fewer bugs using Manual testing.

Mai Nguyen

May 25, 2016
Tweet

More Decks by Mai Nguyen

Other Decks in Programming

Transcript

  1. Why Test? Quality applications for customers No such thing as

    bug free code! Known bugs are better than unknown bugs With more testing, the more certain we can be our code will perform as expected
  2. What is a bug? According to Wikipedia: A software bug

    is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. Most bugs arise from mistakes and errors made by people in either a program's source code or its design, or in frameworks and operating systems used by such programs, and a few are caused by compilers producing incorrect code.
  3. Bugs are in the eye of the beholder Customer Any

    annoyance or problem they encounter trying to use the application Tester Any deviation from expected results Management Any problem that has impact over revenue or customer satisfaction Developer Is it a bug, feature or enhancement?
  4. Key Factors to Consider When Testing Know your audience Who

    are they? What are they trying to do? Know your environments Browsers and Add-ons, OS, hardware, etc The less control you have over these, the less certainty you have your code will perform as expected!
  5. Manual Testing vs Automated Testing Automated Testing Manual Testing Pros

    • Great for regression testing, load testing, and other repetitive testing • Vital for Continuous Integration • Consistency between test runs. • Good for projects with complex business cases • Good for UI and usability testing Cons • Not really great at UI testing • Tests are only as good as how thoroughly they are written. • Costs time to maintain tests as code changes • Cannot creatively find new bugs. • Not great at simulating real users. • Costs time and money • Testing is only as good as the tester • Can only test on one platform at a time • Testing is never 100% consistent • Can be tedious
  6. Manual Testing Can complement automated testing and is most effective

    when testers have: Creativity Intuition A questioning mind Attention to detail … Wait, but aren’t developers supposed to have all of those too?
  7. The Developer Mindset vs Tester Mindset A Developer’s Mindset A

    Tester’s Mindset Assumes the code works perfectly Assumes there is always something wrong How do I build this feature? How do I break this feature? Cares about how it works Cares about how it should work Has a personal stake in what they build No personal stake Wants to create and protect what they build Evaluates and reports the good and bad Thinks users are intelligent, rational, and have assumed knowledge Thinks like a real user, assuming no knowledge
  8. Benefits of thinking like a tester In addition to fewer

    bugs: • Better product = happier customers • Fighting fewer fires • Less work to fix bugs found sooner while code is still fresh in your mind • Can uncover the need for clarification earlier in SDLC • Can help you identify use cases that clients may not be aware of earlier • Will help you ask better questions in your feature planning
  9. Manually Testing Your Own Code Separate your ego from your

    work Doesn’t necessarily take more time If you are going to click around, do it efficiently: • Look for edge cases • Do things that you normally wouldn’t • Mis-use your application • Test code, not validations
  10. Form Inputs Special & unicode characters - are they properly

    escaped where needed? Length of strings -- too short or too long -- can affect display/design Numbers -- negative, zero and very large numbers -- can affect display too Files - different sizes and types for uploads, corrupt files, badly named files Different types of images, resolutions, ratios and colour intensities How do different form inputs interact with each other?
  11. What happens when you go too slow? Do sessions expire

    gracefully? What happens when the state of objects changes before an action is completed?
  12. What happens when you go too fast? Double clicking on

    form submits Clicking on things before the page finishes loading Clicking ‘cancel’ button mid-action
  13. Other situations How does the application handle multiple instances/tabs/windows from

    the same user? Responsiveness, resizing screens Data errors - non-unique uniqueness, database inconsistencies Interact with the application using the keyboard as much as possible Interact with the application using the mouse as much as possible Back button use and consequences
  14. A second set of eyes really benefits Only way to

    catch bugs if the Developer has misinterpreted the requirements A developer likely will not test for cases they never thought to coded for If you have difficulty switching into Tester mindset Another person will have a different perspective and different testing biases and strengths.
  15. Testing Tours for Integrative Testing “Tours” give strategy to exploratory

    testing (unscripted testing). • “Money Tour” Visit the main attractions in succession, in different orders. • “Garbage Collector Tour” - Choose goal like “all menu items” and visit each one • “Back Alley Tour” - Visit all of the least used features • “Fedex Tour” - Follow the data and track it as it goes through all stages in the application Exploratory Software Testing by James Whitaker
  16. Any strange behaviour can be a bug Even if you

    expect the behaviour, it does not mean someone else will not think it is a bug. Better to report these issues than they be a surprise. New use cases should be documented and Product Owner notified.
  17. Conclusion Known bugs are better than unknown bugs Manual testing

    can improve quality and does not need to take more time Thinking like a tester will make you a better developer Be creative with your testing!