Tuesday, July 26, 2016

A Tester Invades Philmont: Lessons from the Trail

Well, I made it. An event that I had trained for this past year, lost a lot of weight for, and did a lot of practice runs with a scout troop to help make us eligible to participate in has come to an end. I've been home for a week now, and I've been able to think a bit on the various events, activities and opportunities to learn that I and my Troop were subjected to. Six youth and two adult advisors took to the backcountry of the Sangre de Cristo mountains in New Mexico, and we al lived to tell the tale. It's a safe bet to say that everyone who participated in this trek came back changed people. For the next few posts, I'd like to talk about some of those changes, and what I learned while I was unplugged from civilization for two and a half weeks.




First, a little background. a part of my scout troop participated in a trek at Philmont Scout Ranch. Philmont is the oldest and largest of the USA High Adventure bases used by the Boy Scouts of America. Other properties used for High Adventure bases are Northern Tier (located in the Boundary Waters region of Minnesota), Florida Sea Base (located in the Florida Keys) and Summit Bechtel Reserve (located in the mountains of West Virginia), but Philmont is the one that most Scouts have heard of, and for many, it's the ultimate destination for a troop to have an event there at least once in their scouting life times. Crews are limited in size from a minimum of seven and a maximum of twelve. All participant need to be at least fourteen years old, and there are weight requirements and fitness requirements for both youth and adults to attend. We quickly learned that these were not suggestions, but that they were genuinely necessary for successful completion of treks. Philmont offers more than thirty possible treks for crews to take part in, and encourage early selection of a variety of options. Once you get assigned an Itinerary, that's the one you do, and everything is built around your itinerary. Ours was #10, which focused on going into the Nothern part of the Phimont Property and taking part of our trek outside of Philmont property, hiking into regions of Carson National Forest, as well as going into places where trails and trail markers didn't exist, or at least would make the journeys longer if we were to follow them.

A crew is led by a crew leader, which is a youth member of the expedition. There is also a Chaplain's Aide and a Wilderness Gia (Guide). Al of these jobs are held by youth members of the expedition. In an ideal expedition, adults advise, but call not shots and get no votes on what the expedition does. Needless to say, what is ideal and what actually happens often doesn't line up, but more on that in a bit ;). We determined that we advisors would do little in the way of active management of the trek. We would offer suggestions, we would model behavior, we would give examples of things to do for the boys to learn from, but as much as was in our power, we would not interfere with their decisions or operations. This gave us ample opportunity to teach, but it also gave us ample opportunities to learn about group dynamics and leadership in general. At the outset, I want to say that I am immensely proud of this expedition and what it accomplished while it was out in the field. I'll dare say I learned as much from them, if not more so, than they did from me. Still, there were some interesting observations I'd like to share over the next few posts. I hope you will indulge me :).

Leadership is a Walk

If there was any one thing I wish I could go back and help train this expedition better to accomplish, it would be to see how they could execute on the plans they made. Leadership is more than making a plan and telling people the plan. That part was easy. What was difficult was actually getting the group to execute on what they agreed to do, and seeing the consequences of not executing. The two adult leaders (myself and another adult) shared a tent and also shared some common equipment. We both knew what we had, how much space it took, and hat it would mean for us to carry it on our backs for ten days. Because of this, we split up our obligations, we split up the gear, including the tent, and we knew what we needed to do. Each morning, as the designated time that was announced the night before as wake up was determined, we'd set our alarms for 15 minutes prior (because that's just what a leader does, we know we have to take care of our own business before we can be of any help to anyone else). We'd wake, stow our personal gear, break down our tent, and then we'd go and sit in the central area and wait for the boys to do their thing. Often, we'd be waiting for quite a while. Some mornings, we'd be waiting an hour or more for the leaders to wake up and get the rest of the group moving. Sure, it would be easy for us to walk over and tap on the tents and remind the leaders what time they said they wanted to wake up, but often, it was more effective to let them get up and discuss their execution after the fact. At times, we would quite loudly talk among ourselves to give the hint that they should be awake and active. Simple things that we took for granted seemed to be a challenge for some of these participants, such as setting an alarm to wake up, or to do something as simple as to ask one of the adults to use their alarm and follow up with them to get them up on time.

Another big stumbling block to execution happened on several mornings, and that was the stowing and transporting of shared expedition gear. Things like bear bags, ropes, carabiners, pots and camp stoves were the property of the entire group, so provision had to be made for each item to be carried by someone. Invariably, on several of the early days of the trek, the delay in getting everything packed was "who is going to carry (fill in the blank item)". Personal gear was no problem, everyone knew what they needed to cary that belonged to them, but allocating the items that were expedition equipment seemed to be a recurring problem. Each day, someone waited to see who would make the first move to carry whichever item needed to be carried. Few were the ones willing to just divvy up the items and say "I'll carry this" and be done with it. This often meant that it might take an extra hour or two to sort who would take what. Sure, I and the other adult leader could have just said "you take this" and "you carry that", but that went against the whole ethos of the trip. We were there as suggesters, not as tyrants or dictators. We were hands that could be used to help, but that was it. Needless to say, we often struggled with this. It's easy to say that you will step back and let the leaders lead, no matter how painful that process might be. at times, it truly was panful, because the solutions, at least to me, were so obvious. I realized, though, that that was not entirely fair, because I had had years of experience, both on the trail and in everyday life, where developing ways of being efficient and effective had come from lots of experiences where I was anything but. These boys were in a new world, one where they came to realize that saying they were leaders wasn't enough, they had to actually be leaders. At times, they would succeed, and at times they would fail. Most often, they would fail because they couldn't see a larger picture.

One of the ways that they learned the value of getting things taken care of early was when they were faced with leaving camp to get to the next destination, and that next destination was ten miles away. May not seem like much when walking city streets, but it takes on a whole different meaning when you are doing it with fifty pounds on your back, no set trails, and at altitudes over 9,000 feet. Also, a term that I helped ingrain in them, perhaps with a little bit of respect after a few days, was "hiking in the heat of the day". It was a very different experience hiking at six or seven in the morning than it was hiking at ten or eleven. The temperature difference could be as much as forty degrees higher (that's Fahrenheit because we're American's and we just use that system, I know in the rest of the world a foty degree difference means something significantly more ;) ). Still, that difference had a big impact on the progress of the rest of the day, and what energy reserves were left at the end of the hike to do things in the new base camp area. An early start meant a relatively quick hike, with plenty of energy and time to do program activities and relax a little bit. A late start often meant arriving at our cam late in the day, no time to do fun activities, and a scramble to get done what we needed to to get camp set up, dinner cooked, and to get some sleep before the next day. It tok a few times, but my comment of "hiking in the heat of the day" slowly started to sink in, and the group figured out what it needed to do to get a move on so it wouldn't have to bak under the hot sun for too long each day.

I see many parallels in the work I do every day and in the way that I often lead testers and other engineers on my teams. It's so efficient to just tell people what to do, but real learning and expertise is rarely developed that way. Often, advising as to a course of action, and then stepping back and letting people do what they need to do is a much better option, but it i also filled with frustrations. It will rarely be done the way we want it to be done, or in the timely manner e would hope it would be done... at least, not at first. However, when people are held accountable for the execution of their plans, especially if thy say they will do something a certain way, they will often meet up with those expectations over time. It requires a willingness to walk a learner's walk, and at times, that willingness means being able to model correct principles, yet let people govern their own ways of actually accomplishing the goals they set. Yes, that includes dealing with the consequences of their actions (or inactions) at times. I frequently told the participants of our expeditions that the adults were ready an hour or two before they were, and as such, we just sat and waited, and of curse we suffered through their delays and "hiking in the heat of the day", too. Over time, though, they came to internalize what they needed to do, and they also figured out how to cut their time from waking to walking down considerably. It's a shame we didn't have another ten days, as I think they would have been fantastic on a second leg. As it was, they were getting the hang of it by the time we ended the trek. Maybe they can carry it into the future and other activities they do. Time will tell :).

Tuesday, June 28, 2016

And Then it's "Go Time"

Two years ago, my Scout Troop put in a submission to trek at Philmont Scout Ranch in Cimarron, New Mexico. We'd submitted before, and due to the lottery system, we'd been unsuccessful in years past. However, in 2014, we got the message we'd been waiting to see for some time.

"Congratulations, your Crew has been selected to trek at Philmont Scout Ranch during Week 7 of the 2016 program year." With that, we all breathed a collective sigh of relief, cheered at our good fortune... and then came face to face with the enormity of what we'd just agreed to do.

For some, backpacking, cooking and camping in the backcountry for twelve days may be a regular occurrence. For many of our scouts, this was absolutely not the truth. We realized we would all have to up our games. We'd need to get new gear. We'd need to consider how much what we would bring would weigh. We'd need to get in shape... oh man, *I'd* need to get in shape!

For the better part of two years, we made sure we had the right group of people to attend. We had fits and starts. We had firm commitments from lots of scouts, only to have several of them fall by the wayside when the enormity of the trip (both in the effort and the cost) became apparent. At points, we feared we might have to cancel the whole thing, but somehow, at the moments of truth along the way (and there were several), we were able to pull it out of the fire and make the trek viable. We raised money by whatever means we could. We advertised a willingness to do jobs no one else would want to do (having to clear out a garage for an estate sale and clean up rodent damage to a large part of the storage will certainly live as one of the more memorable ones). We planned itineraries and booked flights, hired charter buses, made travel plans both before and after the on the mountain trek. We reviewed medical forms over and over. We went to get certified for Wilderness First Aid and CPR. Most of all, though, we strapped on back packs with all of our gear and we hiked. We hiked on flat paved trails. We climbed and descended mountains. We hiked on grass, in dirt, on forest floors littered with pine needles. We practiced cooking as a group. We dealt with the realities of one of our campers being genuinely gluten and dairy intolerant (as in full scale Celiac disease level, and realizing that nothing on the Philmont meal plan was edible for him). We pitched in and bought him a full compliment of gluten and dairy free trail foods so that he could participate with the rest of us.

Shortly, all of the planning, training, dieting, working out, learning, certifying, proofing, and other stuff that has consumed our lives for what feels like forever and no time at all will be set in motion. We will board a plane. We will fly to Albuquerque. We will be met by a shuttle service. We will travel around the small towns in and around the New Mexico Rocky Mountains until our check in time. We will then hit the trail, scale summits, evade bears, explore mines, climb to the top of Mt. Baldy, cover close to seventy miles, perform service and area improvements, and overall see how well we actually prepared for this adventure of ours.

In my day to day life as a tester, this all reminds me of the countless stories, iterations, releases, and other milestones we have met over the years. At some point, you no longer have time to practice, to learn, or to model what you will do. The time comes that you just "must do". In short, it's "Go Time". You are either ready, or you are not. Your solutions work, or they do not. Your learning is sufficient, or it is not. The one difference is that, when I test, there's always another day, another chance to get it right. Out in the wild, if we do something bone-headed or we take on something ill-prepared, the consequences may not be as mild. Though I am not anticipating it, I have to realize that, during these trips, though the numbers are small, people get hurt or die out here. We can do a lot to mitigate those risks, but we can eliminate them entirely. Now we just have to go out and do our best, and know that we have trained for this. I'm humbled, but I'm also excited.

For the next two and a half weeks, I will effectively be unplugged and off the grid. I'm looking forward to the opportunity to help provide a trek that I hope will be life changing for the participants, and yes, I'm hoping one of the life's changed, in a positive way, will be mine :). Happy trails to you, until we meet again!
 

Monday, June 13, 2016

The Testing Show Is YOUR Show

Edited: Date changed, see below.

TL;DNR: We have a new podcast at The Testing Show. We need show ideas, questions, your involvement! We are having a Tweetup using hashtag #TestingShowChat on Wednesday, June 22, 2016 from 11:00 a.m. - noon Eastern USA timezone. Join us!!!

And now on to more of the show... so to speak.

For the past several months, a fairly large percentage of my time has been spent on an endeavor that I enjoy. That endeavor has been producing and editing "The Testing Show". Put simply, the Testing Show is a podcast hosted and paid for by Qualitest Group. A few years ago, Matt Heusser and I partnered on a podcast hosted by Software Test Professionals called "This Week in Software Testing" (TWiST). It ran for two and a half years, we produced over 130 episodes, and at the time, we felt like we had said all we really wanted to say, or could say. We took a hiatus from podcast production that lasted longer than either of us thought it would.

Towards the end of 2015, Matt and I, along with Justin Rohrman and Perze Ababa, discussed the idea of creating another software testing podcast, reminiscent of the old TWiST, but updated and focusing on newer topics and changes that have happened in the testing word since we stopped producing TWiST. The net result of those efforts is The Testing Show.

Twice a month, we bring you news on an issue happening in the world of testing, or something we think is interesting going on in the broader world and how software testing effects the stories we talk about. In previous episodes, we've covered software systems that erroneously released felons, automated trucking, the challenges of accurate Super Bowl predictions, and software updates causing a satellite to fall out of orbit and burn up in earth's atmosphere... hey, who said testing wasn't fun :)?

We've had a great group of guests come and join us on the show to talk about topics related to their areas of expertise, ranging from Test Management (both process and people), being a Trusted Resource, Testing in Scrum, visits to QA or the Highway and the Reinventing Testers workshop, Automation & Tooling, and Measurement & Metrics.

At the end of each episode, I ask listeners to send us their feedback about the shows they have heard, what they would like to hear, and topics we could cover. It's in this aspect that I want to reach out to our listeners, both current and potential, and see if we can do more.

In our minds, we discuss topics that we think would be interesting to our listeners. Comments on Twitter and other social media sites have been positive, and we thank you all for that. We'd like to see if we can do better, both in the way of helping make a show that you would love to listen to, and also make a show that you would love to share.

As producer of the show, I do my best to make each fortnightly episode the best quality it can be. We often talk for an hour plus, but we edit the show to be roughly thirty minutes, give or take a few. We create show notes with complete transcripts of all the conversation presented, as well as references to what we cover and jumping off points where our listeners can learn more. As we do this, we realize that, amongst ourselves and each other, that we have a limited view as to what's most important to you, our listeners. We can make guesses, but we don't know everything you know, we haven't walked everywhere you have walked, and you have ideas and questions we may never think to ask. We'd like to engage with you directly, and get some opportunities to know what you would like to hear on the show, who you would like to hear from... and if one of the people you would like to hear from happens to be "you", hey, we can talk :).

On Wednesday, June 22, 2016 from 11:00 a.m. - noon Eastern, the cast of The Testing Show will be hosting a live event on Twitter. We will answer questions about the show, discuss things we've talked about in previous shows, but more to the point, we want to know things that you would like to hear us discuss in future podcasts. If that interests you, and you'd like to give us some feedback on what we are talking about, or what we could be talking about, we hope you'll join us. Use the hashtag #TestingShowChat to play along with us. If you can't participate at that time, you can always send email to us at thetestingshow@qualitestgroup.com, and we will do follow up in future shows.

Another way that you can help us get the word out is to leave reviews of The Testing Show on iTunes. If you like what you hear, leave us a review. More reviews means better placement in search engines, and more chances of people discovering the show. Share the show with your friends and encourage them to listen as well. We aim to make The Testing Show the best podcast we possibly can, but ultimately, the show belongs to you, our listeners, and our success resides with you. We'd love if you would join us, and help us make your show the best we can make it.

Thursday, May 19, 2016

Aedificamus: Everything Works, Until it Doesn't

I started this little all consuming project on August 14, 2015. At the time, I weighed 263 pounds (yes, posts earlier stated I weighed 260, but the scale I was using at first and the one I use now have a three pound discrepancy. To be consistent, since I'm using the Health-O-Meter LoseIt Scale, I adjusted to keep the numbers consistent). I embarked on an approach that I tinkered with over several months, and for quite some time, felt I had come up with a winning formula. My results certainly seemed to confirm that line of thinking. I did offer a caveat that, what works at one point may stop working or be less effective later on.

That's the reality I'm dealing with today.

First, let's look at the numbers:

My LoseIt graph of bodyweight, current as of May 19, 2016.


Yep, things have been interesting the past few months. In some ways, I feel like I am more active than ever. I'm focused on the food I prepare. I'm getting ready for what will likely be a challenging but fun two week long backpacking trip. I should have had this in the bag a long time ago, and yet...

Not only has progress slowed, at certain points it has stopped completely and reversed. Ups and downs and fluctuations day to day are to be expected, but this is different. Using a moving average, when all is said and done, I have been virtually parked at around 193 for three months. I got down to 190 for a day, and then later I reached 188 for a few days, but then rocketed back to around 194. I blamed it on a weekend at a scouting activity where my prime responsibility was cooking (and yes, cooking the fun stuff :) ). I also bring my culinary skills to a variety of pirate festivals (in addition to being a living history docent, I also act with the Quartermaster crew as galley cook, which, let's face it, is fun). Still, I've been keeping track of my calories, I've been diligent about syncing my Fitbit with my apps, and sure, there are some days I don't make target, but the high majority of the time, I do. 

So what gives?

Data is interesting. If you focus on just one thing, it can tell you something specific, but it may not tell you the whole story. The image above deals with weight by itself. The following image, which is a graph of my Body Mass Index (BMI) adds another dimension:

My LoseIt graph of BMI, current as of May 19, 2016


I'll be the first to tell you that BMI is a flawed measure. No two people are exactly alike, and I have some unique morphology that messes with the very premise of BMI. I have a classic Viking build. I often joke that my scant Danish heritage is really only represented in my name, as I am basically 1/8 Danish, with a full half of my heritage Italian and Spanish/Mexican, and the rest a mixture in various parts of English, Irish and Welsh. For those who are fans of history, you probably already jumped to the point where you would say "yeah, but there's lots of Danish/Scandinavian in that mix of English, Irish and Welsh... that's who the Saxon's were", and you'd be right. Long story short, classic Viking morphology defines my body. I have broad shoulders. I have a long torso. I have a long neck. Most important, I have stubby legs. I'm 6 feet, 2 inches, but I have a 31" inseam. A typical height for that inseam length is about 5 feet 10 inches, so four inches of my cross section are coming out of my torso. There' a lot more mass in the torso than in the legs, all things considered. My point being, just getting to a green zone BMI may or may not be a proper target, but since hospitals and the insurance industry use it, and pretty heavily, for making health related decisions (and assigning risk factors), I abide by it. I hit 24.9 BMI (the highest I can be and still be in the green zone) on February 27, 2016. The green line in the graph represents that 24.9 goal. 

Do you notice anything interesting? Yes, there are dips, even some significant ones, and there are setbacks (yep, a significant pair of them as you can see), but overall, when averaged out, I'm holding altitude at that 24.9 spot. This is, I assure you, not intentional. I really want to hit that 185 target I made for myself, but my body has been fighting me tooth and nail... or has it?

What's different between now and what I was doing in the Autumn of 2015 and the Winter of 2016? 

One interesting variable change is the addition of the FitBit into the equation. It's a really neat tool in that it tells me my caloric burn for each day, and it tracks steps for me. However, I have noticed something interesting. Back when I was using my phone as my pedometer, it seemed to take me an hour and forty minutes of cumulative walking to get to 10,000 steps. I stopped keeping track time wise or distance wise, but I've had the nagging suspicion that my FitBit may be a little too generous with my step count. It certainly seems I hit that value much sooner. It's also possible that my phone registers the distance differently, and since I started wearing the FitBit, I don't carry my phone with me everywhere all the time, so I can't compare the two values in a meaningful way. 

Additionally, I've been training for a two week backpacking trek, with conditioning hikes covering five to seven miles, with elevation climbs of about 1,000 feet up and down, with a 45 pound backpack. Seems I should be losing weight left and right with that kind of regimen, except... now that I'm doing these long hikes, I have had mornings where my typical physical training sessions, be they yoga or strength training stuff, have diminished. Also, I've been producing a podcast that takes up a fair amount of editing time, so a lot of my previous exercise focus has been shifted. In short, while I want to say I'm doing the same thing I was doing before, the truth is, I'm not. I've changed the load, both physically and cognitively. I may not be getting all of the exercise and calorie burn I think I am getting.

Yeah, but my food regimen has been rock solid, right? 

Well... I can go back and see a whole bunch of things that, if I were to be 100% objective, I thumb ruled and used experience to provide numbers. Did I include the pat of butter that went in to lubricate the pan? How about the salt used in the blanching process? Did I really know the make-up of that rice noodle I used? When I eat out at a Mexican place and get ceviche, do I really know the caloric breakdown of what I have eaten? Have I truly been making my own meals, or have I slowly worked in social lunches at the office to help balance things? Sure, I hit my fruits and vegetable quota religiously, and have for months, but there's a lot in the mix I am probably not accounting for, or I am willfully ignoring. In short, I may be eating more than I am giving myself credit for. Mix that with a changed workout regimen, a possibly overgenerous accounting of my thermal output, and a very real underreporting of my caloric intake, and I think it's very possible that my lack of progress is my own darn fault. 

Additionally, it's also entirely possible that I've biased myself by having hit the BMI target. It's not the weight goal, but it's put me in the green zone for healthy weight, and perhaps my sub-conscious is saying "OK, body, that's enough, we need to overrule this darn fool, by whatever means necessary."

There's one final detail I think may be important, and that's time. Time using a caloric budget. Time planning workouts. Time going out of my way to train. Time avoiding certain foods or food combinations. Time researching alternatives to help me lower sodium or excess sugar. All of this adds up, and results in "Weight Loss Fatigue". Yep, I'll admit it, some days, I just want to say "the hell with all of this!" It manifests itself some times in my going days without weighing myself. I'd been an advocate of daily weighing and found the daily fluctuations to be a wonderful source of daily angst, so I cut them back to once a week. Problem is with once a week, I'm not getting that daily feedback or getting the motivation to course correct. Holding ground isn't so bad, but it also makes me a little complacent. Having a spike in weight makes me less want to weigh daily. Therefore, even though the daily weigh-in irritates me, it really does give me daily input that I can act on, so I'm going back to it, or as daily as I can realistically do.

It's easy to lament a lack of progress and think "oh, things have just gotten so much harder, I'm doing the same thing and not getting results any longer". It's possible that could be the case; the body is highly adaptable, and I could be developing muscle from all my exertions, but with a reduced calorie load, I'm highly dubious. No, I think the real facts are that I'm not doing the same thing. I've drifted off my course and routine. I'm not as diligent as I was. I'm using the tools to provide a false sense of accomplishment. I'm getting a dose of dopamine each time I meet a goal and see the bar and icons turn green. That in and of itself is its own reward, and it distracts from my ultimate goal. To that effect, it's back to some of my tried and true methods. An hour and forty minutes daily walking time, measured some other way than just letting my FitBit tell me. It's time to get back into those FitStar workouts that I've let become less frequent. It's time to say "no, thank you" to team lunches, or at least go less frequently, and take my cooking and food preparation back. Mostly, I need to really take the time to think about what I ingest (and more importantly, digest), and realize that there may be lots of hidden stuff I'm not accounting for, but I better figure out how.

So there it is, nine months in, almost seventy pounds down, but those last eight pounds are proving to be frustratingly difficult to say goodbye to. Whatever the reason, what I relied on before isn't working the same way, so it's time to pivot. Check back in a couple of months and we'll see how well I do with that ;).



Friday, April 8, 2016

Webinar: Test Estimation Hacks with Matt Heusser

As many of you know I don't do direct advertising on TESTHEAD. At times, though, I do give plugs for things my friends are doing or things I think would be noteworthy and interesting. This would be one of those plugs :).


The folks at QASymphony are having Matt Heusser present a webinar on Test Estimation Hacks, April 21, 2016 from 2:00 p.m. - 3:00 p.m. Eastern time.

First off, this is not a sales presentation. Matt is doing this based on concepts and practical approaches that are tool agnostic. You’ll leave with a half-dozen ways to think about estimating, from “can you finish it by lunch?” to full blown new product development and planning. The techniques themselves can be applied by anyone, and Matt will explore why coming up with time estimates in testing can be so counter intuitive — and what to do about it. It's not an endorsement of QASymphony or a plug for them, either. They are hosting the webinar.

Matt is a thorough presenter, he's engaging, and he does his homework. Anyone who has listened to the "TWiST" podcast or "The Testing Show" knows what I'm talking about.

In short, if you can attend, do so. If you can tell others about it, do that, too :).

Thursday, April 7, 2016

Automation Challenges: Live from #STPCON

One of the things Paul Grizzaffi said as a lead in to his Automation Challenges Roundtable was "this will *NOT* be covering how to use Selenium!" With that, I was sold for where to spend my last session.

What's nice about this session is that it's not a presentation per se, it's a group hug, in the best and nicest way I can say that. Since this is a open mic flow, we'll take it as a question at a time approach:

How Do I Communicate the Value of Our Automation?

I'm fortunate in that I work for a company that has a robust and long serving automation platform. IT's not very modern, and its not always pretty, but it works well and has for a long time. Most of the tests pass most of the time, and truth be told, there have been a few times where I wondered if our tests were really valuable... until we actually caught regressions that saved our butts. To that end, having the automation in place was tremendously valuable, so I'm not sure what I would suggest beyond making sure that you report your results regularly, highlight where the tests helped with finding issues, and encouraging continued work on automating new features as they come.

Different Personalities in the Automation Pipeline

It helps to have people with different experiences and viewpoints, but that opens up some additional challenges. People develop in unique ways, and different people work in ways that may or may not be optimal for others. Short of isolating everyone and having them work alone (i.e. what's the point?), encourage each member to communicate how they like to work. We may not be able to resolve everything, but helping each other understand our best approaches will certainly make it smoother.

Requirements, BDD and Code in One

The desire to have business requirements, BDD language and code in one place is doable, but it's tricky. Test Rail is an approach that can front end the business language, yet still minimize the duplication. Bigger question is "how can we get the group to work together with a minimum of duplication?" The unfortunate truth is that the more specific we make something, the less flexible it becomes. Seems a good potential product :).

Helping Teams Not Go Rogue

Everyone has their favorite framework or methodology. What happens when there are several tools in use and different technological requirements? One suggestion was that everyone knew how to run the tests, regardless of the tools required. Spreading the knowledge helps encourage looking for synergies. We may not always be able to pick a unifier, but over time, learning from each group can help either draw projects together or at least determine which areas must be separate for technical reasons.

---

...and with that, we bid adieu to STP-CON. Thank you all for a terrific week, and thanks for bringing the conference to me this time :).



Become an Influential Tester: Live from #STPCON

When we get right down to it, we are all leaders at some point. It's situational, and sometimes we don't have any choice in the matter. Leadership may be thrust upon us, but influence is entirely earned. I would argue that being influential is more important than being a leader. Jane Fraser, I think, feels the same way :).

Influence is not force, it's not manipulation, and it's not gamesmanship. Sadly, many people feel that that is what influence is. Certainly we can use those attributes to gain influence, especially if we hold power over others (titles are somewhat irrelevant in real influence. People who respect you will walk though fire for you regardless of your title. People who don't respect you may put forward a brave face and pay lip service, but behind your back, they will undermine you (or at the most benign level just ignore you).

So how can we get beyond the counterfeit influence? I'm going to borrow a Coveyism (meaning I'm stealing from Steven Covey, he of the "7 Habits of Highly Effective People" fame). To have genuine influence, we need to build "emotional capital" with our associates and peers. That emotional capital needs to be developed at all levels, not just with upper management. One sure way to develop emotional capital is exchange information and experiences. In my world view, that means being willing to not be the sole proprietor of my job. IF I know how to do something, I try to make HOWTO docs that spell out how I do it. Some might think that would be a detriment, i.e. where's the job security? Fact is, my job is not secure without emotional capital, and sharing my knowledge develops that capital. It also frees me up to explore other areas, safe in the knowledge that I am not the silo, you do not need me to do that thing, because i've shown many others how to do it.

Persuasion is a fine art, and it's one that is often honed with many experiences of not being persuasive. Persuasion is, in my opinion, much easier when you are dispassionate an objective, rather than passionate and enraged. Making a clear case as to why you should be listened to takes practice and experience, and developing a track record of knowing what you need to do. Over time, another aspect of persuasion gets developed, and that is respect. Respect is earned, often over long periods of time, and unfortunately, it's one of those resources that can be wiped out in a second.

Influence often comes down to timing. Unless the building is on fire, in most cases, timing and understanding when people are able to deal with what you need to present and persuade about helps considerably.

Over time, you are able to develop trust, and that trust is the true measure of your emotional capital. If your team trusts you, if you have made the investments in that emotional capital, they will go to bat for you, because you have proven to be worth that trust. Like respect, it's a hard earned resource, but it can be erased quickly if you fall short or prove to not be trustworthy.

Being able to work with the team and help the team as a whole move forward shows to the other members of the team that you are worthy of respect, trust and that you deserve the influence you hope to achieve. Note: leadership is not required here. You do not need to be a leader to have influence. in fact, as was shown in an earlier talk today, the leader or first adopter has less influence than the first follower does. That first follower is showing that they have faith in the first person's objective, and by putting themselves in the position of first follower, they are the ones that influence more people to sign on or get behind an initiative.

A key component to all of this is integrity. It may not be easy, you may not always be popular, you may wish to do anything else, but if you keep true to your word, your principles and you own up to shortcomings or mistakes without shifting blame, you demonstrate integrity, and that integrity, if not always outwardly praised, is internally valued.

Active listening is a huge piece of this. To borrow from Covey again, "seek first to understand, before you try to be understood". It's often hard to do this. We want to be right, and often, we put our emphasis on being right rather than being informed. We all do this at some point. Ask yourself "are you listening to what the speaker says, or are you too busy rehearsing the next thing you want to say?" If it's the former, good job. If it's the latter... might want to work on that ;).

Ultimately, influence comes down to reliability and dependability. People's perception of both of those is entirely dependent on your emotional capital reserves. You are not reliable and dependable, you demonstrate reliability and dependability. Over time, people perceive you as being reliable and dependable, and the relationships you foster help determine how deep that perception is.


Party Down with MS DevOps: Live from #STPCON

Anarka Fairchild is an engineer with Microsoft, and she's our lunch time keynote. Her talk is squarely focused on the emergence of DevOps, and how that term is both abused and misused, yet still a goal that many want to achieve.

From the Microsoft perspective (did I mention Anarka is with Microsoft? OK, now I have ;) ), DevOps starts with a solid Application Lifecycle Management Plan. It's not just technology and toolsets, but a mindset and cooperative approach to everything in the delivery pipeline for the business. Their approach starts with planning, and that planning should include development and test from the get go (yes, I can get behind this!).

Next, development and test link up and work to develop and proof the code in concert, with an emphasis on unit tests. Cross platform build agents are more important than ever, so Microsoft is leveraging the ability to build on many environments (Windows, Linux, iPhone, Android, etc.). Next up is release and deployment and Anarka walked us through the approach Microsoft uses to manage the release and deployment process. Finally, the end step (not really the end, but the start of the loop back) is Monitor and Learn. By evaluating usage stats, analytics, and taking advantage of reporting tools, we can look at all of these details and bring us back to "Do".

So what should we consider when we are building modern apps? Three areas that Anarka identified were Quality Enablement, Agile Planning and Developer Operations. Typically, QA has historically been left to the end of the development life cycle. I don't need to repeat that this is inefficient (not to mention kinda' dangerous) in that we find bugs too late. Microsoft looks to be aiming to make quality enablement a central tenant of their development process.

Conceptually, this all sounds pretty interesting, but for me personally, due to the fact that I live in a Linux development world, much of the presentation is too product specific. If it seems like I'm being slim on details, it's because there's a lot of Microsoft specific componentry being discussed. Having said that, I do like the fact that there is an emphasis on making tools and capabilities better for us plebes :). For those who work in Microsoft shops, it sounds like there a lot to play with for y'all :).


Visual Testing: Live from #STPCON

Mike Lyles is covering something I like to talk and present on, so I felt it would be good to get another perspective. Visual Testing is important because, in many ways, we need to use our eyes to validate something an automated test cannot, and yet, our own eyes are untrustworthy. We fill in a lot of the details that we expect to see. We are remarkably good at inferring what we think we should be seeing, so much so that we can miss what would be obvious (or at least, what we think should be obvious on closer inspection).

Assumptions come from one place; the brain will sacrifice facts for efficiency. This is why we can be tricked into thinking we are seeing one thing when the full image shows we are looking at something else. On the bright side, the brain is constantly evolving (thank goodness the "your brain is locked at 25" idea has been debunked). More relevant is that the brain does not want to pay attention to boring things. We get conned into attempting to multi-task because we crave novelty, yet the brain can't really multi-task, so we make shortcuts to help us deal with what's in front of us. In short, we become more fallible the more novelty we crave. Additionally, the more stress we deal with, the more pronounced this cycle becomes.

One of the things I often suggest, and I learned this from James Lyndsay a few years back, is the need to repeatedly focus and defocus. We need to focus to see patterns, but we can often become so fixated that we miss other patterns that are clearly in front of us. Fans of the game SET are probably familiar with this, especially when the pattern is picked by someone else. With stress, the ability to focus on what's in front of you diminishes, but if you practice working with the stress, you can overcome your diminishing faculties.

Other senses can help us remember things, but what we see is usually more memorable than anything we experience in any other way. Mike gave two pieces of paper to two participants, telling the same story, but one was just words, and another had pictures. The person with the annotated pictures remembered a lot more of the details of the story.

People are naturally curious, and little children especially so. Over time, we tend to tamp down on that natural curiosity in favor of efficiency and performance. Good testers will work to try to awaken that natural curiosity, and they will try to open themselves up to approaching problems from a variety of angles.

We often approach systems with a pre-conceived notion of what they should do and where they should be placed. There's a comfort in standardization, but that can also led us astray when an item is designed intentionally to thwart that expectation. In many cases, we interact with the device the way we expect to, not how it is actually configured. While I may say it is overkill to look at every device with fresh eyes, it does make for an interesting experiment to try to put aside the expectations we have and try to look at it as a brand new object.

One interesting example Mike used was to pull out a jar of gum balls and ask us how many there were. Some people set low numbers (I guessed three hundred), some guessed high (close to 1000) but as we recorded more guesses and then took the average, the average was within ten of the actual count. In short. a collection of observations and comments gets us pretty close to the reality, whereas one of us might be wildly off, based on our limited visibility and understanding. In some cases, the crowd sees better than the individual.

Good thing to remember is that what we think we are looking at may not be at all what we are looking at. Plan accordingly ;).

Leading Change from the Test Team: Live at #STPCON

http://bit.ly/JRChange

Think of a village next to a river. Early in the morning, someone is hear drowning in the river. A person runs in to save that drowning person. Later, another two people are coming down the river, drowning, and two people run in to save the drowning people. A little leter, five people come down the river, drowning. This time, our hero gets dressed and starts running upstream. As the village elders yell and ask what he is doing, he responds "I'm going upstream to see who or what is throwing people into the river".

This is a cute and yet good reminder that, at times, we need to stop dealing with the immediate crisis to see where the root problems lie. Another common joke is "when you are up to you rear in alligators, we often forget the job is to drain the swamp."

John Ruberto points out that, sadly, most change efforts fail. The primary reasons are that we often fail to build a good case as to why the change is needed. There's a model called "the change curve" where we start with denial, put up resistance, then embark on exploration, and finally we commit to the change.

Making change needs two important things. First, it needs to have an initial leader, but just as important is a first follower. When a first follower steps in and participates, and most important, the leader embraces and accepts them, that encourages others to do so as well. Over time, those not participating will start to because their non-participation will be very visible, and now not following is the strange course. In other words, the most important leadership role is not the actual leader, but being the first follower.

First and foremost, we need to build the case for change. What's the need? Where can we get supporting data for the need for change? What would happen if we didn't implement it? What is the urgency? Pro tip: the higher the urgency, the more notice and attention it will get. However, often the most important changes needed don't rise to the level of most urgent. However, if left untreated, something important can certainly rise to most urgent (especially if the time left untreated results in a catastrophic bug getting out in the wild).

Next, we need to communicate in the language of our intended audience (as well as those who might not be in our immediate audience, since they may have influence on direction). Ideas need to map to a vision. Features need to communicate benefits. We do pretty well on the former, but we could use some help with the latter. In short, don't communicate the what and not communicate the WHY!

We can communicate the needs, we can speak to the value, but we need to validate the hypothesis as well. That means "Scientific Method" and experiments to confirm or dispute our hypothesis. It's important to remember that the Scientific Method is not a one and done, it's a continuous cycle, especially when we hope to make changes that will work and, more important, stick. Don't give up just because your first hypothesis doesn't hold up. Does it mean your whole premise is wrong, or does it mean you may need to refine your hypothesis? We won't know until we try, and we won't know for sure if we don't genuinely experiment, perhaps multiple times.

Next, we have to rollout our change, and observe. And be ready to adapt and adjust. John used a cool image from Sweden in 1967 when the switch from driving on the left side of the road to the right went into law. Even with all the testing and experimentation, there was still some chaos in the initial implementation, and it took some time to adjust and resolve the issues that resulted. For us, we need to be open to feedback and ask, consistently "how can we improve this?"

We of course need to show progress. If everything has gone according to plan thus far has worked, but we are not showing progress, we may need to be patient to ensure we have adopted the change, but at some point, we need to objectively evaluate if our efforts and changes are really valid. it's of course possible that we could hit all cylinders and adopt a change that doesn't really achieve what we hoped. Does that mean the change was irrelevant? Possibly, but it may also mean that, again, we need to adjust our hypothesis. Typically though, sticky changes have to show progress worthy of the change.

In short, remember to be in love with the problem, and try to address the problem. Don't be too married to any solution that doesn't really accomplish the goal of solving the problem. Good goal to shoot for :).