Archive for the ‘tool belt’ Category

In 2013, I was just beginning to assimilate the lessons – the failures and the successes – from the challenges of my 1st four years building a test team from 1 (me) to 5 and being in a manager role while providing testing services across multiple projects. A friend who’d just returned from a developer conference in San Francisco said, “You should speak at a conference.” The end result of his encouragement was my 1st professional conference presentation in 2014 in New York City at CAST.

I already had the benefit of practice in speaking to small groups for 5 minutes via Toastmasters (highly recommended to reduce jitters), but a pitch and preparation for a conference talk was new to me. Here is a recap of how I prepared for my 30-minute track session.

I chose to start with CAST because it felt safe and I considered myself a context-driven tester indebted to give back to that community. I was thrilled and also terrified when I received notification of acceptance a little over a month after I submitted my application.

Hurdle 2: Follow the Boy Scout motto; Be Prepared.

4 months out – Drafted outline and main points, started practicing.

SpeakEasydid not exist at that time, but you DO have this option to pair with a volunteer mentor to get coaching for help with a proposal and presentation. I hired a trusted coach who had already helped me find my voice. We met initially over Skype to nail down my main points and several times later for me to practice and get feedback to refine my presentation as the big day got closer.

He made elegant slides to fit the tone of the few selected words I had on each slide. This allowed me to focus on honing delivery, being able to speak comfortably within the time constraints.

2 weeks out: Videoed at home rehearsal. Practice run for family.

1 week out: Presented to about 15 friends at work at lunchtime over pizza.

Day before: Prepare the introduction

Met for 10 minutes with my track session facilitator, Pari. She asked me some questions to get to know me a little better so that her introduction was warm and personal and not simply a recitation of my presenter bio and talk summary, which most attendees had likely already read.

Night before: Made an unsuccessful attempt to go to bed early, but managed to get a few hours of half-decent rest.

Moments before: Breathed deeply to keep cool.

Played music for myself (to relax) and to spark casual conversation with attendees. [Listen to this one-woman orchestra. Enjoy Zoe Keating’s, The Optimist.]

Result Set

I finished within suggested time limit and based on the 15 minutes of engaging voluntary group discussion at the end of my talk, I think I did alright. I knew I had achieved my goal of reaching at least one person when a participant shyly slid me a sweet handwritten note – 2 sentences – and thanked me afterwards. Wow! How’s that for confirmation?

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:

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.

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.

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.

Learn more about system internals and the software environment.

Gain insight into error frequency and severity.

Identify internal bugs, such as logging issues or security-related problems like un-obfuscated passwords.

Investigate failures for which there is no visible error in the user interface.

Proactively monitor system health. i.e., Investigate errors before they get escalated to you via Support.

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:

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.)

System logging bugs – inaccurate log levels, missing logs!

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].