Manual Testing for Developers

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

Transcript

1. BUGS. Gotta catch ‘em all. Mai Nguyen
2. 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
3. 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.
4. 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?
5. 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!
6. 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
7. 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?
8. 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
9. 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
10. 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
11. 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?
12. What happens when you go too slow? Do sessions expire gracefully? What happens when the state of objects changes before an action is completed?
13. 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
14. 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
15. 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.
16. 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
17. 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.
18. 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!
19. Questions?