Inevitably interviewers ask me, How and why did that happen? – career track shift from environmental science to software development. This question and related blog post by Eric Jacobsen, You’re a Tester. How’d that Happen? are fodder for this introspection and retrospection. The Why: I wanted to be in perpetual state of intellectual challenges, where interpersonal interaction was essential to making tangible positive results happen, and where I could make a better salary.
I chalk the ease and naturalness of this shift up to these things: aptitude, educational foundation in science and engineering, my varied and solid work experience since the age of 14. The How is below. Disclaimer: It is entirely possible and likely I would have eventually found what I wanted in the environmental science and civil engineering field as my perspective broadened over time with experience and exposure.
I began to recognize what I wanted a few months out of college and into my role as an environmental microbiologist in a full-service laboratory. I found lab work dull, repetitive and isolating. My 1st clue that I would eventually love looking for potential problems was when an angry project manager visited me with a complaint; a client was unhappy about their lab results for coliform, biological dissolved oxygen, or cyanide. The test details escape me, but I keenly remember I felt excited that there was a problem, something to investigate – my lab records. This intrigue was greater than the anxiety which accompanied being yelled at. I wanted to get answers and help her make the client happy. My boss, the lab owner, was not excited. He saw me as unorganized. There was a bug with the test results on their bugs in a surface water sample.
A college study buddy with the same GPA and degree had gone to work for the technology branch of what was then Anderson Consulting in “Knowledge Management”. When I described what I wanted she said I should look into the company. I decided that if they hired her, then they would hire me. The corporate office responded to my resume and application with “Thanks, don’t call us. We will call you.” I was undeterred.
As an Auburn Alumni, within 2 years post-graduation, I still had access to campus recruitment events, so I made the drive from Orlando and from Atlanta to Auburn, Alabama, campus for several career events to shake hands with recruiters to make sure they knew my name. I landed a screening interview followed by 3 more intense behavioral interviews. Over a year after I had initially submitted my application, I was hired as a “Business Analyst” and spent 1 month in training on C++. My only prior experience with programming: 1 college Fortran class. It was no fun. I felt lost the entire time. Programming became more enjoyable for me in Anderson’s collaborative learning environment and now that I had built a GUI, something with which I could interact!
Sink or Swim
Project 1: I worked night shift, monitored batched script results of database conversion test cycles, followed runbook procedures, and hoped I would not have to call someone if something terrible happened. Project 2: I used VI in UNIX to write and test conversion scripts for the next phase of the database conversion project. I had a great team lead and detailed specifications to help me with this. Project 3: I moved on to a web-based application effort. I was with a much larger team, and had detailed specifications and guidelines for all phases of testing (V- Model) and also began to test other people’s code. Magical Project 4: J2EE pilot project at the client site with an architect, a manager and me, the junior developer! Relationships formed, job well done and longer term multiple application contract won. I was always responsible for testing my own code. For the 1st time, I got to work directly with the customer for requirements gathering and elaboration over various UML documents, wireframes, test coverage, and user acceptance testing. Over those 4 years I learned I loved the nature of testing and exploring value with customers and teammates more than I enjoyed coding. I am grateful for the deliciously diverse approaches, models, and operational processes I continue to learn.
This was and still is wonderful.
Have you ever made a delightful or tough yet satisfying career transition which elicited doubtful questions and puzzled looks from others? I would like to hear about it!
I am frequently asked, So how do you like working from home (WFH)? My response is, Even more than I anticipated. I have been reflecting on this quite a bit lately.
JIGSAW FALLING INTO PLACE
How this started. Last August I left an amazing company and a role in which I was generally content, where I happily contributed for a personal record tenure of 6 years. A former colleague presented me with an opportunity to amp up my face-time and engagement with customers, to leverage my experience with a relatively young team with an exciting mission and big vision, and to learn the ropes of a new role, Product Owner. I would have to use ALL of my standout strengths: stimulator, connecter, teacher, pioneer. My excitement meter jumped from 20 to 100 and remained pegged there after the interviews. WFH was a bonus in this unexpected opportunity. This meant early realization of a long-term goal of being able to work from anywhere. You see, my husband and I aspire to eventually live a migratory snowbird lifestyle and live up north during the summers.
EVERYTHING IN ITS RIGHT PLACE
1. Connections with Colleagues. The team has been “remote” since its 2014 inception. On this powerful little distributed agile team of 17, we all WFH unless we are near a corporate office and choose to go on-site. 1 does this daily, 2 folks occasionally. Here is where we live.
Frequent, clear interpersonal communication feels now even more important than when I was working in a co-located space. There is still the benefit of body language with Hangouts. And being head-phoned makes me especially attuned to voice, the most emotionally expressive and telling organ we have. I know when I have over-worked myself, because I can hear it in my own voice when my game or self-confidence has taken a little dive.
2. Growth. Everyone is accountable to each other. Hangouts and Slack keep us highly communicative, visible, & transparent. I have been extremely impressed with this team’s ability to deliver, to pivot, and to swarm and expeditiously triage from multiple angles. We have a culture that says, It’s okay to fail. Let’s do it fast & learn from it. I have also been extremely grateful for receiving rapid, candid, practical feedback and learning to practice radical candor. In my new role, I quickly recognize the impact (helping\hurting) of my actions or inactions on the team and I can course correct rapidly.
3. Same same. Asking open ended questions is not enough. This yields crickets if working with a quiet set of folks and makes it so that the team might not benefit from an introvert’s expert perspective. Instead of asking, What do you guys think about XYZ? I engage directly, D, what do you think about XYZ?
4. Toolbelt. We primarily use these collaborative tools: Slack, GoogleHangouts, Pivotal Tracker, Mural.ly, and also Trello (for team retrospectives). I use a Verizon JetPack MiFi for backup internet service for those times when my ISP for home internet connection is flaky or in case of temporary power outages in my neighborhood. I also use the JetPack when I choose to work physically elsewhere.
1. I wanna see your face! I am a pretty social person, so I would probably feel depressed and isolated if I never actually saw my co-workers. Just hearing their voices would not be enough for me. Thank goodness for GoogleHangouts which lets me have early a.m. coffee time, one-on-ones, daily stand-ups, retrospectives twice a month, impromptu face-to-face chats and screenshares with teammates as needed throughout the day. Daily Hallway conversations happen in Hangouts, too. I enjoy getting to know some of my teammates cats or if it is late in the day, their kids. Facetime is important in our team culture. It’s essential for me to being all the more attuned with folks.
2. Easy now. Stick to a schedule & regular breaks. Though flexible across the overall team, most of our squads (squad = smaller teams within the overall team) hours are generally 9 – 5 EST. I am not as productive or at my best when I over work; extra hours are not encouraged. I had this challenge before WFH. My dedication to work and propensity to arrive early and stay late is exacerbated by the convenience and proximity of a home office. Couple that with an initial sense of needing to work extra hard because I was WFH and you have… hogwash. Friends outside of my team who also WFH express this as a common side effect: You get even more out of me because I work from home. I am forming healthier habits by sticking to office hours and literally wiping my hands when I am done for the day, closing my laptop along with my home office door.This little end-of-day ritual helps me to get into I am off work now mode. I still think about work after hours. Always have, always will. I love what I do and I enjoy thinking about it.
3. Cabin fever. Going to the grocery store is now something I look forward to! I also take daily walks, go out for lunch, sometimes with a friend every couple of weeks to mitigate cabin fever. Yoga and swimming are not highly social activities, but I still need and enjoy the community vibe in those spaces outside my home.
4. Nope. I do not have these distractions during my workday: laundry, cleaning, cooking, constantly walking into the kitchen and raiding the fridge. Sure I might toss in an early morning load, timing this so it can be hung up to dry – that’s right I am old-school and eco here – just before I checkin to work. I do not work in pajamas. What I wear promotes a sense of I am shifting into work mode now. Although I started out dressing like I was going to an office on casual Friday – nice shirt with nice jeans – I quit that after a couple of months.
1. Quality of life. While this transition was not a calculated decision based solely on $$, after a month, I recognized quantifiable benefits that increase my already high happiness quotient. No purchases to refresh my work wardrobe this year. Putting even fewer miles on my car. I enjoy more time in the morning for a relaxed breakfast with my husband sans pre-office work prep and commute. I estimate I recover an extra 1.5 hours\day of no-fuss time by not having to pack lunch, get fancied up in office clothes and drive to\from work. I had it good even before this came along. I live where people vacation. I enjoyed amazing views (the bay, sailboats, dolphins) during my 15 minute one-way commute. Way better than my Atlanta days where the commute was 2+ hours roundtrip. Although I don’t have any little ones, I think WFH is especially cool with shuttling kids to\from school & activities and with the fact that the kids get some exposure to their parents in action (work mode) at the end of the day. I like being able to look out a bit for my neighbors & to be available for them by being around.
2. Less is more. This became my motto with this career transition. I realized that WFH simplified my focus and energy in every slice of the pie of my life: Volunteering, Finances, Friendships, Family, Fun, Fitness. Maybe this just happens to coincide with or be in part due to where I am in my life\my age, but the move to WFH seemed to initiate more care, attention, and introspection and adjustments to those slices.
3. Resources. Listen to HanselMinutes Podcast with Karolina Szczur on Building Remote Teams First. Read 37 Signals Founder’s book, Remote, for employers and employees on how they can work together remotely.
Gratitude. Thank you to my fellow Honeybadgers, Squids, and ATeam teammates, Diego, Nate, David, Rob, Wen, Mitch, Behrooz, Darren, Michal, Tej, Kavinfranco, Nick D., Joel, Brad, Nick V, and Yin for being awesome and for making me feel welcome since Day 1.
How does this compare with your experience? What were\are your greatest challenges? What do you appreciate the most? I’d like to hear from you!
Credit Note: the ALL CAPS subheadings of this post are Radiohead song titles.
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).
- Followed the advice in Eric Jacobsen’s Failure Story #3 – Failed Conference Proposal, especially Bolton’s tips on writing an awesome conference proposal.
- 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.
- 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.
- 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.]
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?
- 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:
- Scott Hanselman’s Art of Speaking
- Fix your boring slides
- Get the most from your experience, How to Enjoy a Testing Conference
Attribution Note: This post’s title belongs to the Counting Crows album released in 1993. *Please see below.
One of my software testing community colleagues emailed me this week, “You’ve been quiet. How are things?”
I went into something akin to recluse mode after an amazing week in New York City in August 2014 where I participated in my first un-conference, TestRetreat2014 NYC with other passionate skilled quality-minded folks, and then participated in three days at CAST2014 NYC where I attended an awesome workshop lead by Noah Sussman, lead a track session (my 1st conference talk, yeah!), and served as LAWST-style facilitator [Ref.] for multiple speakers. I am an extrovert who thrives on stimulating thoughts and connections in and with others. I love people, but I also need space and quiet, focus time to recharge my batteries. My personal goals derived from those energizing days were as follows:
- TestRetreat – cross-pollinate by talking about software quality to non-testers and kids and engage with local agile or lean software groups.
- CAST NYC – share my conference experiences (including details on that week) and insights through blog posts.
In keeping with my decompression needs, I had a delayed start plan; I intended to reflect and publish my mix of handwritten and typed notes by pumpkin time, Halloween. That did not happen. Lesson learned: Do not wait! Share your thoughts and reflections while they are super fresh. Yes, I still intend to post insights from over a year ago. Life happened.
In early October, I took a week long adventure trekking trip with 2 dear girlfriends, and when I returned home I learned that a loved one’s health had taken an alarming nose dive. Outside of work responsibilities, family, and a 2-room home remodel project prompted by water, shade, and 65 year old plaster, I did not muster any energy to connect with my software testing community or make a move on my good intentions until awhile after that loved one’s passing in May.
I have slowly been inching out of the woodwork since. This summer I teamed up with someone locally to transfer leadership of the meetup group I founded, GCST, and to transition it to an agile meetup group. I started a fresh effort to envision long-term goals and am now preparing and reviewing course materials to assist as an instructor for BBST Foundations. I am also brushing up on Gojko Adzic’s Specification by Example and Impact Mapping. I drafted this post as I flew home to Florida from new job orientation in California. That is big news. I wear a product owner hat now. I will remained focused on quality in software delivery in an agile environment for a different organization. I get to apply the testing mindset upfront in processes in direct collaboration with customers and as part of the development team!
Although, I have been a wallflower in the software testing community since last August – not actively participating in professional online groups – in the last year I did manage to contribute 3 company DevBlog entries and to do a few talks, which I now have listed in a Speaking page on this site. Thanks for reaching out to me Matt Heusser and thank you for creating interactive spaces like TestRetreat and Software Delivery 24/7 for quality-minded folks to support each other and to learn from one another.
Thank you to CTS Mobile sponsoring and hosting this month’s Lean Coffee Style Meetup in their Wall Street office. It was great to have both testers and developers at the table forming our own agenda, sharing insights, experiences, laughs, and food.
Everyone took 2 index cards and wrote down a topic of interest. Next we laid out the cards for all to review so that each person could take 3 sticker dots ( and place all or some of them on the card(s) of greatest interest to them. Then we reordered the cards based on number of votes and consolidated duplicate topics (next time, we will remove dups prior to voting). We place these cards in the ‘To Discuss’ column and pulled the 1st one into ‘In Progress’ column. The original submitter of the topic gave us a little more context on the card. We dedicated at least 6 minutes to each topic. You can learn more about the LeanCoffee meeting style here.
- Dev/QA communication and relationships
- how not to play the “blame game”, communication throughout the build cycles
- talking vs. only communicating via bug tools.
- importance of neutral tone, clarity in bug documentation, including steps/tests
- How best to limit depth & number of test cases – research and scope
- consider risk area, quality factors that matter most, breadth of coverage
- apply multiple test techniques
- Manual test case structure (test case naming conventions and step details)
- naming conventions and standards vary between clients
- should capture the essence of test intent
- Importance of performance testing
- clients often think performance testing is included.
- client education, advocacy, and awareness
- examples of performance issues
- How do you manage requirementstraceability in an Agile environment?
- changing tools, planning, documentation, and approaches in this context
- Effective Exploratory Testing
- you CAN have traceability and accountability with exploratory testing
- take tours, tailor your approach, endless possibilities
Thank you to to Matt Seese for reaching across the bay to host, to Kaeisha Ford for notes, to Justin for the photos and to everyone who participated.
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!
I closed my CAST track session with this puzzle: Connect all 9 dots with four straight lines without taking the pen from paper.
The frames our minds create, define – and confine – what we perceive to be possible…Everybody hears: ‘Connect all 9 dots with four straight lines without taking the pen from paper, within the square formed by the outer dots. And within that framework there is no solution. If, however we amend the original set of instructions by adding phrase, ‘Feel free to use the whole sheet of paper,’ it is likely that a new possibility would suddenly appear to you. I might see the space outside the dots was crying out, ‘Hey bring some lines out here!’ – from Art Of Possibility: Transforming Professional and Personal Life.
My CAST session was inspired by various forms of bewilderment I met in testing, akin to experiences I worked through during 3 days in silence with paints, paintbrushes, and paper through a Process Arts workshop. The painting weekend was an incredible experience for me. Art, after all, is about rearranging us, creating surprising juxtapositions, emotional openings, startling presences, flight paths to the eternal.
Now 15 years into my testing career, I see inter-disciplinary studies across all fields. In my mind, testing is not far from what I loved about studying and working in environmental science, which was whole-systems thinking and the growth of ideas like those in Natural Capitalism. Testing insights are everywhere waiting to be discovered…through studies and applications of sciences, personal study, play, and the practice of art.
P.S. We can still go beyond the above illustrated solution. Check out how on Seth Godin’s post on Appropriate Cheating in the nine-dot problem.
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.
- Karen Johnson’s Debriefing Alone. Question 1 is my “dripping faucet”.
- Julie Zhou’s Manager’s Manifesto
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.
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. 🙂
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.