Archive for the ‘learning’ Category

Yes, You Have Something to Share

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.

Hurdle 1: Decide on what to share and make the pitch(es).

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

  • 4 months out – Drafted outline and main points, started practicing.
    • SpeakEasy did 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.
  • 1 month out – Got graphics help from my design friend, Chris.
    • 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.

Pari

 

  • 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?

Artifacts

  • CAST Live  – daily broadcast each evening following the close of the conference:

  • Coming soon – My session was not recorded, so I will make my own recording and publish on Vimeo.

Additional resources I used:

 

Personal Blindspots

Weird…when you get close to something that BIG you can’t see anything at all.

-Toad the Wet Sprocket, Butterflies (Fear, 1991)

 The subject of blind spots keeps begging for my attention lately. This is when something hits me that I did not see coming or I run into something that shocks or surprises me.  Maybe this is an interaction where I feel dangerously blindsided, caught off-guard and unprepared.  Maybe this is some counter-productive behavioral pattern I did not notice as being not-so-great for me or our team.  Maybe this is a gap in my test approach. – a gap obvious to others, but not to me.  Maybe this is a more subtle metaphorical dripping faucet in the back of my mind, something I am slow to acknowledge and investigate.  My conscious quest for personal and testing blind spots started in 2010 when I attended Michael Bolton’s On Noticing presentation at my 1st CAST.

Because we are collaborating, problem solving and building great things, I think the nature of a career in software development and testing offers great opportunities for discovering blind spots  and learning from them IF we are open to having them pointed out to us through feedback or coaching or if we make time for retrospection and have them revealed to us through self-inquiry and observation.  It is important to make time to reflect on our work daily.  To jumpstart my renewed effort to do this, today I revisited these blog posts.

I will share several blind spot examples as part of my story in my CAST 2014 track session, Beyond Bewilderment, which is about finding personal success in testing.  Once I return from NYC, my after work time no longer dedicated to track session preparation, I plan to focus my professional development in the area of learning scripting.  This will probably lead to a post of the subject of technical blind spots through katas, paired testing and development. More later.

Tenacious Testing

I admire your tenacity.

This sentence was a lifeline when it arrived in my inbox a few years ago. This was a perspective, which I had not considered at a time when I felt like I was flailing around in emotionally exhausting waves at work.  I was learning (not so gracefully) to get used to argument and criticism.  I was also testing a technically challenging product developed by multiple teams.  It was important to get to market quickly without major quality issues, however testability and supportability were not-so-great, so pinpointing bugs was tough and getting to market was taking too long.

  • Articulate and own your role.
  • Articulate and evolve your strategy.
  • Educate yourself  so that you can increase your capacity to do all of the above.

Those were the lessons from my “stick-with-it-Ness”  AHA moment.  Also, that sentence and these experiences  re-affirmed my commitment to and love for the work I was doing:

  • Remain steadfast in your commitment to all of your stakeholders.
  • Be grateful for whatever comes your way, especially if it makes you uncomfortable.  Doses of stress can be opportunities to strengthen your emotional muscles and to develop a repertoire of responses which is (at least) as nuanced as the problems you face. (Reference: Law of Requisite Variety).

Be tenacious in your testing, but also remember Rule # 6.  Don’t take yourself so dog-gone seriously. 🙂

 

 

 

 

 

May Meetup Redux, Mobile Software Development & Testing

Eight of us (including a colleague from Mobile, AL!) gathered earlier this month for the Gulf Coast Software Testing Meetup.  Thank you to Janusz Chudzynski for speaking with us about Mobile Application Software Development and Testing in iOS and Android.   Janusz is a software engineer, frequent presenter, and research associate at University of West Florida with multiple mobile applications under his belt.  He had suggestions for getting started with development, programming in Objective-C, and utilizing various frameworks for application management, debugging, and deployment. We discussed challenges of testing across platforms and devices.  We also discussed many of these topics as Janusz demonstrated them to us:

  • IDEs and unit testing with XC test framework.
  • xCode’s UI designer and storyboard components.
  • strengths of iOS simulators for forcing test conditions such as stressed resources or slow connections.
  • strengths of xml-based layouts for Android development.

In closing, Janusz passed around a few iBeacons and we brainstormed useful and fun mobile application ideas to benefit from these devices.

I appreciated Janusz’s gracious tone and confident, casual style amidst a somewhat disruptive environment with one of the restaurant patrons having a medical emergency and with dissonant attendee opinions on a few subject areas.  I thought his talk was accessible to testers who do not code and to developers and testers who do code.  I have very limited experience with mobile application testing, however as a result of Janusz’s talk, the subject seemed accessible and I felt inspired to experiment for fun and learning with mobile software application projects outside of my day job.

You can find Janusz on LinkedIn or Twitter @appzzman.

Lean Style @ Seville, April Meetup Redux

I did not publicize and promote April’s LeanCoffee Style GCST Meetup as much as February’s Lean Pie, so with leaner attendance there was no need to vote on topics.  Bullets below indicate the main cards we wrote up and discussed.  The sub-bullets are offshoots, shared anecdotes of main topics in conversations over dinner.  Thank you to Apper and UWF peers for the subject matter and food for thought.

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

 

GCST “Lean Pie” at O’Zones Pizza Pub

I want to help connect people to learn from one another to advance the craft of software testing within our area.  Getting the fledgling Gulf Coast Software Testing Meetup (GCST) group going is a fun way to explore this territory.  We had our 1st Lean Coffee style GCST meetup at O’Zones last week where I facilitated a modified version of the 1-hour Lean Coffee format, the mechanics of which roughly followed this template.  After introductions, each person wrote up to 3 cards (topics), explained our subjects, cast our votes with 3 dots, racked and stacked cards, and kicked off time-boxed conversations beginning with topics with the most votes.

Eight of us gathered to ask questions, share info, insights, and experiences.  I enjoyed seeing friendly new faces and everyone seemed to have great time.  What I like about this meeting framework is the breadth of topics, how each topic could stand alone as fodder for an evening’s knowledge share.  I also appreciate how everyone has an opportunity to speak, so you get a hint of everyone’s personality and you learn a little about their interests even if you do not elaborate on their topic during the meeting.

The topics:

6 dots:  JavaScript testing in Jasmine? Appropriate for all JS Apps?

3 dots:

  • Mobile development frameworks in use at your company
  • Levels of testing and where to concentrate effort – UI, end-to-end, data
  • UI design strategies in general

2 dots:

  • Testing Kata
  • Selenium
  • Define “Done” in the context of software development

No votes:

Our meetup went an hour and a half, which was just the right amount of time considering that we ordered and enjoyed food and drinks as soon as we had all arrived.  As we packed our to-go boxes we talked about tentative plans for upcoming meet ups.  Some of the ideas shared included a local version of our own “Test Bash” and 20 minute show-and-tells.  I think the collective will come up with a great plan, so let’s have our March meetup be a planning session for the next 6 months.  To our friends across the bay in Mobile, AL, several of us, myself included, would be up for meeting in your area.

Parting thoughts:

  • Next time, I will promote the meetup through like-minded channels, such as IT Gulf Coast and Innovation Coast.
  • Thanks Chris, for reminding me to start the timer (twice!).:)
  • Our group could use a snazzy logo, which better represents us… something other than the stock image I selected.  Although, I love bats, those swarming creatures look a bit ominous.
  • The thumbs (up, neutral, down = keep going, I don’t care, let’s leave this topic) element used at each topic time limit was interesting here in that there was some reticence about when to use up or down.  We joked aloud that maybe the thumbs-down was kind of harsh. I wondered if it was our polite Southern cultures, which lead to this sentiment, or if I did not do a good job of explaining the thumbs.   I will get more feedback from my Dev friends who attended.
  • Thanks to my social friends at the Association for Software Testing, who organized the 1st Lean Coffee I ever attended.  That early morning session at the funky cool coffee shop in Madison, Wisconsin, was energizing and showed me the possibility of trying it out on my own.

Career Composting


As kids, my brother and I loved to dig into our family’s enormous compost pile of oak and pecan tree leaves, vegetable scraps, and dried horse manure to find worms for Grandpa’s fishing trips.  Our rewards:  his ear-to-ear grin and 10 cents for every worm we found.  As an adult, I sift through a much smaller pile in my backyard and tend a tiny family garden.  Using my hands there goes a long way in clearing my head and often helps me turn over my work experiences.

I love to unearth bugs in software and appreciate help finding bugs in my thinking.  Like composting, growing into new habits take practice and patience. Here is the goodness which surfaced over time in the bins of the greatest personal challenges in my recent software testing history.

I have a voice and I trust myself to use it.

  • Test leadership – I articulate my strategy and my role as a tester.  I narrate 3 stories – status of the product/how I tested it, how good that testing was/why you should be pleased with my testing, Is there anything else you want to know? (Credits and thanks to Paul Holland’s Track Tutorial on End-to-End Agile Testing at CAST 2013 conference). I am not a gatekeeper or Product Owner, so I speak up when someone asks me to “make the call” to launch. I re-iterate my role in support of the business stakeholder team making an informed decision.  I make recommendations based on testing and quality issues.  I adjust the test strategy to explore areas of concern as project scope changes.
  • Management – I am responsible for providing direction and for communicating clearly;  I am not responsible for other people’s happiness. To be of best service, I direct my attention to the former, to the clarity and content of my message.

I will not underestimate the importance of community.

  • The above phrase resonated with me at CAST 2013 closing remarks by Scott Barber and Rob Sabourin.  I am continuously bolstered by the generosity of the software testing community through reading many blogs, my participation in a few sessions with Weekend Testing Americas, online coaching from Anne-Marie Charrett, learning from interactions and resources from online training through the Association for Software Testing, attending conferences.  I use techniques, tools and resources from the all of the aforementioned.
  • Now is the time to begin to give back.  I did a lightning talk at CAST 2013 on Leading Testing: Lessons Learned from Gumby. The positive responses and encouragement from those 4 minutes was part of the nudge I needed to draft my 1st post. I will devote energy to the fledgling meetup group I founded, Gulf Coast Software Testers, and I will eventually follow Claire Moss’s lead on co-branding this group as she has smartly done with Software Testing Club – Atlanta.

I ask for help.

  • I recognize emotional triggers as an invitation to cultivate self-awareness and an opportunity to grow my emotional intelligence (EQ). There is something (within me) that is asking for my attention.  No dillydallying!  I promptly confide in someone I trust to ask for feedback about the situation.
  • If I feel like something is technically over my head or if I get bogged down isolating failure conditions, I step away from my desk to get a 2nd opinion.  When I have been on the same test project for a long time, I reach out to my teammates to discuss testing with a developer, architect, and/or another tester to discover there are areas of the system, other scenarios, or approaches I have not considered.
  • Thank you to these great folks for their contributions, which have inspired me in this area:  Eric Jacobson – blog post, You’re a Tester, Relax;  Anne-Marie Charrett – Article [PDF], Beware the Lotus Eaters: Exploratory Testing; Paul Holland – YouTube video commentary on Skilled Testing.

Catch any worms lately?  What lessons did you learn in 2013 to apply in 2014? I wish you a hardy and prolific new year! 

– A heartfelt thank you to @aclairefication for her effervescent feedback, which helped me refine this post.