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 .


  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.