Archive for the ‘skills’ Category

Mitch’s Testing Kata

Thanks to Mitch Ferrer, Application Architect with AppRiver, LLC, for hosting the Gulf Coast Software Testing June Meetup and to our friends at the Gulf Coast Center for Innovation and Entrepreneurship for providing meeting space for 10 Test Enthusiasts.

Why kata?  -for the sake of practice and growth.  Test drive a language, test drive a solution, test different approaches, practice patterns and techniques, change habits, and accelerate learning by pairing, develop skills and mastery.  Mitch opened with a brief slide deck that gave us a background on katas as applied to software.  He reviewed their benefits and lead us through the kata posted in this discussion thread as a demonstration of how arbitrary, seemingly obtuse, requirements are often driven by real world needs.  We then launched into brainstorming user stories and user-acceptance criteria on a whiteboard.

After we were satisfied that we had a good start exploring user stories and acceptance criteria,  Mitch walked us through two solutions, a math solution and pure string manipulation solution.  This dichotomy showed the math solution to be ultra efficient but not easy to understand vs. a pure string manipulation solution (Typescript with Jasmine) which was more lines of code but readable and easy to follow.  The key to this kata were tests designed based on desired behaviors using triangulation – sample inputs and outputs – to allow for vetting business rules and to allow for adding new use cases, which surfaced as we discussed a variety of acceptance criteria.

With Mitch putting each solution through the tests (swapping out implementations) and modifying some bits of code, we saw firsthand how test first development (consuming tests first) ensures ease of use and awareness of how changes will affect customers.  We saw how test first development makes requirements provable and implementations easy to re-factor, and ultimately, how tests facilitate teams tackling business problems.

This kata was a fine example to illustrate the beauty of test first development.  Thank you, Mitch, for sharing your time, expertise and love for the craft of software development and testing!

 

All Kids Love Logs!

We learn from logs – application logs, system event logs, API logs, network trace logs.  These are invaluable tools for testers.  To not consult logs or not have access to logs is to miss out on these benefits:

  1. Save time on bug investigation.e.g., Logs can show failure conditions related to data problems or issues with error handling, thereby saving you time trying to figure out what just happened.  Logs can point you to an environmental/operational health condition such as network or server related problems.
  2. Report the bug even when you cannot recreate the issue yourself. You have proof and details, which you can build upon if the bug shows up later.
  3. Strengthen your street cred with Programmers and other Testers.
    • Build bug reports which include exception stack traces, timestamps, request & response object details, which can help with the next bullet point.
    • Reduce the time Programmers spend pinpointing and fixing the bugs you reported.
    • Become a more technical tester.
    • Demonstrate that you have done your homework on the bug.
  4. Learn more about system internals and the software environment.
  5. Gain insight into error frequency and severity.
  6. Identify internal bugs, such as logging issues or security-related problems like un-obfuscated passwords.
  7. Investigate failures for which there is no visible error in the user interface.
  8. Proactively monitor system health. i.e., Investigate errors before they get escalated to you via Support.
  9. Identify on what day a particular error appears to have started, i.e., bugs introduced in a particular build, problems introduced as a result of an environmental change such as a change to server configuration .

Gotchas:

  1. What you zoom in on within logs may seem more significant than it is so remember to adjust your focus and stay neutral in your bug reporting.
    • What you notice is important, but what you are focused on might not be what you need to see. (Jesse Alford’s reference to AutoFocus in his Lightning Talk, Focusing the Mind’s Eye.  An Optics Analogy at CAST 2013. See Jesse’s talk here.)
  2. System logging bugs – inaccurate log levels, missing logs!
  3. Make sure your software architecture or operational configurations prevent DEBUG logs from getting into your production environment and creating a mess.

*Credits:  For fun – I borrowed ‘All Kids love logs!’  title from Ren and Stimpy.  Here is a tidbit from their quirky show [1 minute: 6 seconds via YouTube].