Aedificamus: The Value of the Self "Check-In"

We all go through them in certain ways. That one-on-one meeting with your supervisor, the daily stand-up, the family meeting, the heart to heart talks, they all have a purpose. The goal is to make sure that we are "on track", whatever on track might mean at that given moment. On track often means different things to different people. I'm having a bit of that now with my son. He's 19, going to college, working a job, and developing a sense of who he is and what he chooses to do. For me, the check-in's are important. For him, they may be less thrilling, because his idea of "on track", at the moment, differs a little from mine. I need to remind myself of this from time to time; I remember having the same conversations with my dad when I was 19. If I'm not mistaken, many of the topics were very familiar ;).

Checking in with others is fairly easy. With another person, I have accountability. The more difficult process is the personal check-in, the act of interviewing myself and regularly asking the following questions:

• How are you doing? 
• Is everything OK?
• How's everything at home?
• Are you working on what you need to? 
• Do you need help with anything? 
• Are there things you probably should stop doing? 
• Are the things you are thinking about stopping doing actually the things you should stop doing, or are they the things you need to double down on?

I could greatly expand this list to talk about my family, friends, initiatives I'm involved with, etc., but for today, it's the Self Check-In I want to focus on.

I've been experiencing a rediscovery in regards to fitness and health. Today's technologies give us the ability to have these conversations. As I've said many times, RescueTime helps me know what I actually spend my time online doing. It's great when the feedback is positive. It's frustrating when I realize things I'm doing are, at best, a mild amusement or diversion. At worst, they are a total waste of time. Still, those insights are made with regular check-ins and asking myself "what could I be doing with this time?".

Sixteen days ago, I downloaded the "Pacer" app because I wanted to do something about my exercise (specifically, the lack thereof). Pacer gave me a very simple goal; "can I get 10,000 steps in every day?". At first, I started thinking about it spread out through the day. I determined the easiest way to do it was to park my car at home and walk to the train station (which is one and a half miles from my house). When I reach Palo Alto, I get off the train and walk to the office (another half mile), and then repeat the process backwards. This makes it part of my daily routine. If I were to just do that, I would be 80% of the way to my goal (and cover four miles each day). Just milling about at the office would takes care of the rest.

As I started making that 10,000 step goal each day, I shifting my thinking to "What about doing it at one shot?" Yeah, that is doable. I need to cover five miles, and take me about an hour and forty minutes (that's just walking at a regular pace, no jogging or running, or deliberately lengthening my stride artificially). Soon, I started considering the goal met when I could do it at one shot, or as early as possible. As I was doing this, I started noticing that there was a daily estimation to the calories I was burning (I don't consider this to be scientifically precise, but as a general rule of thumb, sure, I'll take it). As I was looking at the calories, I started asking myself "Hmmm, what if I were to limit my food intake to what I'd burned?" In other words, if I did a walk and I burned 700 calories (which for sake of reference takes me about two hours of walking or about 7 miles), then I am allowed to eat that amount of food. In other words, can I match the calories I eat to the calories I burn?

This approach works for immediate meals. I would not recommend doing this too aggressively, because it does not take into account my basal metabolic rate (which is imprecisely about 2,200 calories for my height and weight at zero activity level. If I were really to just eat what I had "burned", I'd have a daily deficit of 2,200 calories, which comes out to 15,400 calories a week. I'd lose 4.4 pounds each week at that rate, and at least half of that would be lean muscle mass, which would ultimately make my MBR lower. This is why I do not let myself go that low. Generally speaking, I become so irritable at that level of deficit that I have to eat, so at this point, it's not been something I can maintain in any meaningful way. Still, by doing this process, just by tracking the calories I "burn" with keeping track of the calories I consume, and being aware of how much of each I am doing, the net results after 15 full days is that I have dropped 12.5 pounds! Some of that is water weight, some of it is redistribution, some of it is lean muscle addition (and perhaps a little bit of muscle subtraction), but a fair chunk of it is also body fat, and that is something I'm happy to see go "bye bye").

My point with a lot of this is not to say that pacer is cool, or that calorie counting helps, or that evaluating my BMR on a regular basis is helpful (though all of those are). The act of a self check-in, to see what exactly I am doing, and being mindful of that check-in, helps me keep my motivation. It helps me to recognize if I am on track, or if I need to modify my plan. Additionally, it lets me consider if the time I am spending is the best use of my time, or if I can somehow modify what I am doing. Ultimately, what I choose to do with that time, (especially with walking) is important, because it is now literally time I cannot do something else. Actually, that's not entirely true, I'm using that time to listen to CodeNewbie podcasts (currently up to Episode #33), so there is a very limited level of multi-tasking I can do ;).

How about you? Are you giving yourself a regular check in?

How Many Words Do You Have Left In You?

This may seem like a borderline macabre post, but it was prompted by my recent deep dive into the CodeNewbie podcast. Episode #17 featured Scott Hanselman (a great episode about engaging with new programmers or anyone in tech) and one of the comments that he made was the idea that we all have a limited amount of keystrokes left in each of us.

Scott breaks it down like this. Think of how old you are now. Now consider a conservative life span. For me, to date, the direct line of males in my family have lived to 82 at the latest, though my Dad is looking great at 75 and shows no signs of slowing down yet, so that's a plus :). I'll take a mid figure and say 78. that means I have about thirty years of words left in me. Divide that by the number of hours I work in a given day, and then divide that by the minutes in those hours, and then divide that by the number of words I type, and there you have it.

The point to this is that we have a lot of things we can do, but often we end up doing things that are repetitive and can possibly be of benefit to others if we do them the right way. In other words, instead of answering emails with the same questions, writing blog posts and pointing people to them might prove to be of more benefit.

I was reminded of this a week or so ago as I realized that on any given week, a big portion of my traffic comes from the series of posts I wrote four years ago when I embarked on "Learn Ruby the Hard Way". My rationale was that I was already looking at this stuff, and experimenting with it. I wanted to take notes and see if I could explain what worked and what didn't. If it didn't, was it a problem with the material, or was it a problem with me? More times than not, I'd discover it was a problem with me, or my understanding of the material. By talking out the ideas in the blog posts, and rereading them back to myself, often I was able to uncover problems just by talking out the problem, as though someone else was there to listen. Four years later, those experiments, frustrations and discoveries are still bearing fruit.

To me this highlights the importance of us documenting our journeys. It's tempting to say that a blog post is just a blog post, and that in the grand scheme of things, doesn't amount to very much. I think the opposite. To borrow again from Scott, by putting a URL to our words, we have the potential of seeing our words outlive us. Granted, the specifics of our posts may ultimately prove to be outdated, but the general process of learning, discovery, and our individual journeys along the way have timeless truths that may well prove to be valuable to other travelers. In the ideals of Will Allen Dromgoole, "I'm building a bridge for them" or at least I hope to.

The tl;dr version of this is "find ways of sharing your discoveries, and do what you can to limit the repetition of what you say". If you truly say it once, say it in a chat or an email. If you find yourself referencing it more that that, blog it. You never know what piece of advice you may have hidden in a chat transcript or an email thread that may help hundreds or thousands of others.

Aedificamus: Product Review: #FluidStance #Level

As a blogger, one of the nice perks that happens from time to time is that people send you items to review. Most of the time, my reviews have centered around books in PDF form or software as downloads. In other words, the item I'm reviewing is not a tangible "thing" but an electronic file(s). Today, I received my first "real thing" to review, and intriguing doesn't even begin to describe this.

I have a setup that I use that converts a regular table into a standing desk, using two Ikea Lack end tables. When I want to sit down, I just take the tables and set them to the side, but when the standing desk configuration is in place, well, I typically stand up and do my thing. Often that also involves shifting around, putting my foot up on an upturned wastebasket, and changing positions. With my desk in the seated setup, I sometimes break out a yoga ball to use as a chair, the consistent shifting back and forth giving my core some movement and some variation. I've often lamented that I didn't have something similar for a standing desk configuration.

Enter the FluidStance Level.

"What, dare say, is the FluidStance Level?" you might ask. To put it simply, it's a balance board that you stand on while you are at your standing desk.

This is the top sheet, made of bamboo. It's sturdy and smooth, plus it looks like a nice piece of furniture. 

The underside of the board looks like this. The base is made from aluminum with a powder coat finish. It's very smooth and the curve of the base creates a moderate imbalance while you stand, but doesn't feel dangerously so. 

First impressions while standing on it is that the balance point feels natural. At shoulder width stance, it feels a little like standing on a small boat out on the water. With a narrower stance, you work a bit harder to keep the balance, but it doesn't feel at all clumsy or unpredictable. Instead, it gives a gentle swaying motion with consistent feedback to help you right your stance and keep balanced.

All well and good, I hear you saying, but what is the point to this thing? Put simply, while you are at your standing desk, you stand on the board. The consistent shifting of balance and readjusting gives your body something to do while you are working. I decided to see what thirty minutes of working would be like with The Level, and I found it to be surprisingly fluid and, dare I say it, natural. 

As you stand on the Level, you are definitely "active", which means that you are going to probably need to step away from the desk a little more often, but what I did not feel was fatigued or sore. In fact, it felt the opposite. I found myself feeling very relaxed, even with the shifting weight. Of course, the standing desk to balance myself against also helps.

So what's my verdict on the FluidStance Level? I personally enjoy the sense of shifting movement. I liken it very much to sitting on yoga ball if you have a sitting arrangement set up. It's surprisingly comfortable, and it's easy to get the hang of the sweet spot to balance with little effort. There's something nice about having a product that you did not even know existed come into your reality and have you say "wow, I've waited years for this!" but of course you didn't because you had no idea such a device even existed. I'm looking forward to using this balance board in the years to come.

Call For Interest: BASTUC

Today's post has a local flavor, and it's something I've been mulling over since I got back from the CAST conference in Grand Rapids. Conferences are often expensive, they require travel, time commitment off work and away from family, and a need to negotiate flights, hotels, transportation, etc. These are indeed headaches, but the return on that hassle is often great interactions, learning new things and getting answers to questions I have from sources I might not have initially considered. Plus, I managed to make a new set of great friends each time I go.

For the past few years, we have also had a Saturday event happen before CAST, which has gone by a couple of different names (Test Retreat, Test Coach Camp, etc.) and this has been a much smaller affair. The costs are nominal, usually just enough to cover rental of a space and some snack foods during the day (attendees are encouraged to get breakfast before arriving and go as small groups for lunch). What I find great about the process is the model used for facilitation. Test Retreat/Test Coach Camp is run as an "un-conference"or an Open Space Conference. The topics are voted for democratically, and those people who want to be part of a particular topic participate, and those who don't, don't. Some sessions may have nearly all of the attendees, and some sessions may have two or three people. In both cases that is perfect, because the person speaking is sharing their experience and the people in need of hearing that message get to do so.

One of the challenges I have faced with being one of the leaders of the Bay Area Software Testers meetup is that we want to encourage more people to speak, but there are often limits to opportunities for those potential speakers to get in that space. We have done lightning talks and we are embarking on quarterly Lean Coffee events, but my personal goal is to do something that will help encourage more software testers, and in particular those in the Bay Area to come together, develop talks, practice speaking, conduct workshops, and engage with the broader testing community that's right here.

This is why I'm proposing that we do our own Open Space Conference, the Bay Area Software Testers Un-Conference (BASTUC) . One day, one place, and as many software testers as want to participate. Agenda? You set it! Topics? You decide! Speakers? In this case, I encourage everyone who would attend to come with at least one topic they would like to talk about, even if it's formative or just to say "I have so many thoughts going on in my head about THIS THING, and if I don't get together with some other people and discuss it, my head's going to explode!" Well, OK, we hope not literally, but we want to encourage testers to feel comfortable coming out and discussing the things that matter to them. Chances are, they matter to other people too.

For the record, I have not told Josh and Curtis about this. This is a blind side, and frankly, it's just an idea. I want to see if there would be support for it, and who would participate. If you want to play along, please leave a reply, and we'll take the next steps if this is something that appeals to enough people (and seriously, in my mind, if we get ten people interested, that's enough to move forward on this).

Also, the name is open to discussion, but I had to call it something ;).

Podcast Review: CodeNewbie

Yes, I am late to the game on this, but this really deserves to be a destination for people learning to code, who want to learn how to code, or may even just have an itch in their brain that they might want to code in the future. On any given day, I match all three of those ;). That's why my discovery of CodeNewbie has been fun and informative.

First, some background. CodeNewbie describes themselves as "the most supportive community of programmers and people learning to code". There is a lot of great content on their site, such as Ruby Monday where each week they get together to work on a project, and yes, all are welcome to participate if they want to. Each Wednesday at 9 p.m. EST they host a Twitter chat, using the #CodeNewbie hash tag. I've followed along with a few of these, and they are quite informative and, while primarily focused on the new programmer, don't be surprised if you don't learn a thing or two even if you are experienced in programming.

All this is great, but it's the podcast that I want to focus on. The CodeNewbie Podcast has been around since September of 2014, and it is hosted by Saron Yitbarek. I first heard Saron on the Ruby Rogues podcast, and some time back I made a note to check out the CodeNewbies project she had announced at the time. Like many things, it fell to the back of my list, but as I kept seeing CodeNewbies pop up in my listings, I decided I had to give it another look, and specifically, yes, the podcast. Since they now have 49 episodes, I'm approaching them in alternating order, meaning I am listening to the earliest episodes, followed by the latest episodes, and simultaneously working my way forwards and backwards. What that has done is let me see just how dramatically the show has improved in delivery (this is to be expected with any regular podcast) but also how consistent it has been in staying on message and in a format that is both accessible and readily relatable. Saron gets a lot of credit for that, in that each show is structured in a similar manner (yes, comparisons to Ruby Rogues abound, but since that is one of my all time favorite technical podcasts, that's meant to serve as praise). Saron also has a voice designed for radio, and considering she spent some time at NPR interviewing people, that should surprise no one. It adds a polish and an ease to the episodes that makes each interview feel smooth and well presented. That's not a requirement for podcasts, since I generally prefer practitioners over over-coached pros, but when you can get both, hey, run with it!

If you were to listen to any one episode, I would encourage starting at the beginning, with Saron's interview with Carlos Lazo titled "Bootcamps, Water Coolers, and Hiring Devs". Carlos talks about his time in the "Flatiron School", which is a programming bootcamp. The interview covers a lot of ground, such as the difference between studying computer science and actually being an engineer, why he chose to attend a three-month bootcamp to become a web developer, and several interview related questions and strategies for would be developers to consider. One piece of advice I really liked was to "own your ignorance". Don't be intimidated by the fact that you don't know something. In fact, embrace the idea that, if you are asked about something you don't know, you will not fake your way through an answer. Instead, reply with "I'm not familiar with that particular area. Could you tell me a bit more about it? How do you use it?" Seriously, this interaction alone is worth the time to listen to this episode, but there is so much more to glean from it, so I encourage you to do so.

If you are new to code, have dabbled in code, or have made a decision to get more involved with code, then CodeNewbies is a great destination site. Saron's podcast is a great way to plug in, get inspired, and learn about many aspects of the world of coding you might not think relate to it, but are as essential as the syntax you learn.

TESTHEAD gives the CodeNewbie podcast two thumbs way up :).

Aedificamus: The Hidden Side to 10,000 Steps

This is an odd post, but then again, if you've been around my blog long enough, odd posts are probably more normal than not. In any event, this is a personal examination of motivation, behavior and the hidden side of metrics.

Like many people, I have become a touch enamored with my iPhone. For years, I had mobile devices to test with, and to that level, I typically had wifi access to do most of the functional testing, plus borrowing a friends device if needed to actually test on a carrier. Still, at the end of the day, I was content to put down the mobile device and get on with my life. That dynamic changed when I got my first Android phone a few years ago, and the change really accelerated when I bought an iPhone. I made the shift away from the idea of a mobile phone that can do a few things to a pocket computer that "has plenty to keep me interested, engaged and thoroughly distracted if I choose to be".

The apps that I have been interested of late have been "personal motivators", or those things that track goals in the way of using time, getting exercise and health in general. A neat little discovery on my part was the fact that even before I had installed a fitness app to track walking, running and bicycling, I had data for an entire week ready to display. How? The motion tracking feature is already on the iPhone and it's active, so all this data was ready to be picked up once I installed the app. Cool... and a little creepy at the same time.

One of the things that I notice about myself is that I personally love messing with gameification systems in devices or apps. I like trying to figure out ways I can leverage the apps to generate numbers and see how I can tweak them or apply them, and once I get my teeth sunk into a number, I tend to obsess over it. The number I'm currently obsessing over at the moment is "10,000", which is to say, the goal of getting in 10,000 steps a day. This is the number that is currently touted as being part of an Active Lifestyle. The app I use, Pacer, considers 10,000 steps and more as being "Highly Active". At this point, it's easy to conclude that getting in 10,000 steps will be the ticket to getting me in shape, getting that weight off, and putting me on a path to health and wellness... or is it?

Taken by itself, 10,000 steps has lots of supporting variables to consider. I'm 6'2" tall. My 10,000 steps will cover more ground that someone who is 5'2". Additionally, how are these 10,000 steps performed? In the area where I work, were I to get those 10,000 steps in at one time, it would be on flat ground. Were I to do it where I live, I'd have the option of choosing paths that are relatively flat or with some steep hills thrown in. I live at the top of a hill in my town. The street leading from the main cross road up to my house is steep enough for half a mile that I'm definitely huffing and puffing by the time it flattens out. The calorie counter reads the same amount regardless of which path I take. There are also paths I can take that will have me under tree cover and in the shade, and others will have me exposed to the sun and heat with little to no cover. The point to all this is, by throwing a bit of variety in, those 10,000 steps will vary in the level of effort, the level of sunlight and heat (which affects the amount of sweating I do), and the speed in which I can complete those steps.

For a few days, I experimented to see what it would take to get those 10,000 steps in all at once. The answer is, for me, that it requires five miles of walking, and usually is accomplished in an hour and forty minutes. By comparison, just walking around my neighborhood, walking from my car to the train, pacing on the platform, walking from the train station to work, wandering around the office, and reversing the trek gets me pretty close to 10,000 steps without even realizing it. The difference in effort and how I feel on days where I front load those 10,000 steps, versus days where I reach them literally at the end of the day, is phenomenal.

I've gotten interested in tracking weight loss with this app, and I've set up a few goals. I'll say that at the start of this experiment, I weighed 260 lbs. For the record, that's my all time heaviest. When I was more athletically involved (at my peak in around 1995 when I was training to become a competitive snowboarder), my leanest was about 190 lbs. and my bulkiest was around 225 lbs., both with aggressive training, eating like a horse, and being super active. When I broke my leg back in 2011, I chose to slow down some of the aggressive sports stuff to let the bones heal and get back to their former density. After four years, it's safe to say that my bones are as dense as they will get at this stage of my life, but my habits went significantly downhill, resulting in the weight gain I'm trying to reverse now. Over the days I've been doing this (i.e. less than ten) I've managed to pull five pounds from my frame. I'm currently at 255 lbs. I hope to lose more going forward. Did 10,000 steps have something to do with it? Yes, but perhaps not in the way you might think.

As I embarked on this approach, I wanted to see how I dealt with other things I did. Would getting in 10,000 steps make me more lazy? In truth, I'm finding it makes me motivated to move even more, and on certain days, I get well over the 10,000 steps threshold. Another thing I've noticed is how I eat and what I eat. Prior to doing this, I'd typically just eat whatever was available. Now, I find that I am being much more deliberate in the choice of food I eat, and when I eat it. Part of me thinks this might hearken back to what I've called "The Craddick Effect". When you are scared to do something, force yourself to walk back and attempt it again. Repeat this until you tire yourself out to get your mind and body ready to conquer that fear (and yes, it works :) ). I think my slightly fatigued body starts to shout down my lizard brain trying to find comfort in junk food. It's yelling "hey, I just walked five miles to burn off 600 calories, do NOT sabotage my efforts!" I'd figured it would be the other way around, where I'd say "hey, I've worked hard, I deserve this" but the opposite is proving to be true.

A TED Radio Hour Talk that I enjoyed greatly, titled "Amateur Hour" (of which I expect to talk about in later posts more in depth) had an interview with A.J Jacobs, the editor at large at Esquire who takes on some pretty extreme challenges and writes about them. In the process of talking about his "Year of Living Biblically", he took on the idea that "if we change our mind, we will change our behavior" but in reality, it's the other way around, i.e. "by changing our behavior, we change our minds". We can understand something, we can believe it, we can internalize it intellectually, but if we don't DO anything with that knowledge, we won't actually cause any change. Though early in the process, I can say, at least for now, that putting in 10,000 steps each day, especially if I aim to front load those steps, that my subsequent behaviors around food, activity, and rest change. When I hear of people saying they drop anywhere from twenty to fifty pounds in a year following this approach, the 10,000 steps is merely a catalyst. Sure it's a measurable number, but it's the underlying "infrastructure and behavioral changes" that go on, many of which are imperceptible, that really do the hard work of transformation. I'm looking forward to seeing if this holds three weeks from now, when I next report in on this (and yes, I give you permission to call me on it if you don't hear back from me :) ).

Our Python "Esperanto Project"

Much of the time, my work environment is not pretty. It's not the elegant situations that are spelled out in books or in "best practices" guides. Often, there are things that would look convoluted to outsiders, that seem like strange and quirky paths to get to places and to accomplish tasks that seem, well, not at all ideal. Why do we use them? Because it works. More to the point it has worked for years, and the thought of ripping out everything and starting anew would be a tremendous loss.

I have been discussing with my daughter ways that we could get more involved in and create an environment that we can both use, both agree on, and both work in and understand what each other is doing. In other words, we both decided we would put together our own "Esperanto Project" to help each other learn interesting tools, try out various frameworks and have an excuse to apply the ideas we are soaking up here and there and put them into an environment we can both work with.

Currently, our project resides on a Trusty Tahr build of Ubuntu Linux. The agreed to language for what we are going to do is Python, mainly because my daughter and I are both roughly skilled at an equal level (somewhere between novices and advanced beginners). As a web framework, we are using Django, because, well, Python. Selenium WebDriver is installed, with the idea that test scripts will be written in, you guessed it, Python. For my own fun, I am adding JMeter, Kali Linux and a few other tools to practice testing scenarios and particularly to exercise APIs, utilizing Python as the scripting engine. Finally, we are using PyDev as a plug-in to the Eclipse IDE because, hey, why not ;)?

One of the reasons I want to do this is that I want to be able to not just play with tools, but also have a way to keep the things I learn and find in an environment that can follow me from place to place. Each company uses their own set of tools and languages, and it's likely that I will not be using Python at different jobs. That's OK, since the goal is to not necessarily do a direct port of what I do from one company to the next, but instead, get to a point where I am able to develop and test an environment with a broad range of tools and become more familiar with all the possibilities, while also teaching my daughter how these tools are used. In turn, I'm hoping she will be able to teach me a thing or two later on down the road.

I joked with Kristoffer Nord yesterday via Twitter that his "Python for Testers" course would perhaps be an ideal jump start to this goal of ours. I'm looking at how I can make this into something interesting going forward, and I'd like to make regular updates to it and say where we are in the process. More to the point, I'd like to use it as a chance to ask for help here and there from the broader community, specifically the Pythonistas out there, because our goal is to use Python as the unifier of all the tools we pick, wherever we can.

It may work well, it may work terribly, but we won't know until we try :).

Local Stuff in Testheadland (for SF Bay Area Software Testers)

As I have come back from CAST, and I have taken some time to settle back into daily life and breathe a little easier, it strikes me that there's some stuff happening in my local reality that I'd like to encourage others to get involved with.

If you are outside of the San Francisco Bay Area, this may not be all that interesting to you. If you call the Bay Area home, and specifically, if the cities of Palo Alto or San Francisco are easy for you to get to, then these two items may be of interest to you :).

Socialtext is looking for a Senior Quality Engineer

Socialtext was acquired a few years ago and folded into another company called PeopleFluent. While we do have a site and a brand that is advertised as Socialtext, all of our hiring is being done through PeopleFluent. After being alerted to the fact that that was causing some confusion, I figured a quick explanation would help matters.

If you go to the Socialtext web site and look at the Senior Quality Engineer position, and then click on "Apply Now", you will be directed to a job listing with PeopleClick. That is by design and exactly what you should see. Also, while I cannot guarantee it will fast track you in the system, you have the option of including a note that says you are an employee referral. If you'd like to contact me directly and have any questions, I'll be happy to answer them as best I can. After that, if you add that you are an employee referral, and say that Michael Larsen referred you, we'll both be telling the truth ;).


BAST is going to be holding a Quarterly Lean Beer

I'm taking this from the BAST Meetup page, but since I feel it gets the point across, I'm going to add it mostly verbatim:

Bay Area Software Testers was originally created with 1 rule: it won't always be Curtis, Michael, or Josh speaking. Unfortunately, for the most part we've violated that rule. It's time for that to change.

Join us for the first of our quarterly "Lean Beer" BAST events. What is Lean Beer you ask? Well, it's identical to Lean Coffee, but we used beer (or water) and it happens in the evening instead of the mornings! 

Okay, smart ass answer aside, here is an excerpt from the leancoffee.org website:

"Lean Coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated."

The basic idea is we talk about what the majority of the people present want to talk about. There is no central speaker and no central topic. Come prepared to talk about what matters to you!

We are also planning on using these events to help get an idea of what people are interested in, and trying to find experts to come and speak on those topics. So come, discuss, and have fun.

My goal coming back from CAST was to get more involved in the things happening locally, and emphasizing my commitment to software testing in the Bay Area. Consider this a first step towards that :).

On Letting Go and Embracing Change

During the week that I was at CAST in Grand Rapids, there were many changes in my personal life that occurred, and that I am having to process and work through now. this is not going to be about testing per se, but if I don't find a place to get this out, it's going to eat away at me, so I'm going to do it here. I'm also likely to get emotional here. I've commented that sometimes, we need to have navel gazing posts on our blogs from time to time, and this is one of those days.

Nine years ago, shortly after my son's tenth birthday, we decided it was time to have a pet join our family. My wife and I had kept animals like fish and birds for our entire marriage, but we hadn't had a dog or a cat, partly because we wanted our children to be old enough to appreciate them and interact properly with them. Our neighbors across the street had several Welsh Pembroke corgis, and of course my kids adored them. When it came time to have a dog, we knew they'd want a corgi, so we asked our neighbor who we might talk to. She told us of a corgi faire that was happening down in Los Gatos, CA, and that several breeders would be there showing their dogs. As we went and talked with people, we met a lady that had brought several dogs to show, including one that she felt wasn't really into the whole "dog show" thing. She believed this particular dog would benefit from being part of a family. Our kids met the dog in question, a sweet fawn colored girl that was a little over a year old, and they fell in love with her. We decided to take her home. My son at the time was playing Final Fantasy X and thought her coloring and her antics reminded him of one of the characters from that game, so he named her "Rikku".

About two months ago, we noticed that Rikku was moving more slowly, seemed to be breathing heavier, and was generally listless and not her usual self. as we were petting and scratching her, we noticed that around her neck and her hip joints, she had swelling and big bumps. We had the vet take a look at her, and our worst fears were realized. She had stage four lymphoma, i.e. cancer of the lymph nodes. we enquired about treatment options, but soon realized that her condition was terminal. It could be a year at the furthest, several weeks at the shortest. They gave us some medicine that they said could help her feel better in the short term, i.e. a cortico-steroid, but that it wasn't a cure. It would just be a matter of time before the cancer progressed further.

For several weeks, we gave her the steroid drug, and for a time she rallied. Her lymph nodes shrank considerably, and she was, in many ways, her old self. She was playful, happy, went with us to her favorite places, and interacted with us as she always had. Unfortunately, last week, the slow movements and heavy breathing came back again, and when we checked, her lymph nodes were even more swollen than before. I had to leave for Grand Rapids, but I asked the family to keep me informed as to her condition. By Monday, August 3, her mouth was gaping open at the sides. She couldn't close her mouth, her breathing had become ragged and harsh, and she wasn't walking well. She didn't look like herself, she didn't act like herself, and I was told that they felt that the time had come, and that we needed to have her put to sleep. They felt horrible that I wasn't there, but they felt waiting until I came back was going to prolong the inevitable and force her to deal with several more days of pain. I told them that they did not need to wait for me, that I understood what needed to be done, and that at this time, Rikku needed us to say goodbye and let her suffering end. My wife and elder daughter brought her into our veterinarians office on Tuesday, August 4, and they said their last goodbyes to our little girl.

"Today has been a very tough one..At around 11:30 this morning, we put our little angel Rikku to rest. Her body was deteriorating and we couldn't continue to watch her beautiful, yet delicate soul suffer any longer. Rikku was everything we could've ever wanted in a pet. She had been nothing but a blessing to our family; a comforter and loving friend. Thank you for all the many memories you have given me, I'll never forget them. R.I.P. Rikku…my adorable loaf of bread🐶🍞❤️ March 30, 2005 – August 4, 2015✨" --Karina

Since I was dealing with the conference and all the activities that went along with that, I was kept busy and had limited time to think or process what had happened. In some ways, I felt bad that I wasn't able to be there with my family in this moment of grief and sadness, but I encouraged from afar and did my best to let them know I loved them and felt every bit the same way they did.

On Thursday, after wrapping up the last conference details, settling up with the hotel for any additional charges needed, and doing a last little bit of tourism around town, I got to the airport and flew from Grand Rapids to Dallas to catch the connecting flight to bring me home. Turns out while I was in the air, my wife and daughters went to the Peninsula Humane Society to see the animals there and to help process what had happened on Tuesday. While doing so, the girls found a rescued kitten, a domestic shorthaired calico girl. By the time I landed and was able to look at my messages, Christina told me that we had a kitten. She apologized and said that we should have waited until I came home to ask. I told her it was OK, and under the circumstances, totally understandable. When I asked if she had a picture, she sent me this:

It would be another few hours until I got home, but once I arrived, I went into our little hallway bathroom (the place we have for the time being set up for the kitten's home) and got to know her. As I held her and listened to her purr like a small motorcycle, I cried a little for the loss of a longtime member of our family, but smiled a little in that this little patchy furball was already helping my girls come to grips with the loss of Rikku. This morning, as we were talking about the new member of our family, I made it clear that that is exactly what she was. She was not a "replacement" for Rikku, she was an animal with feelings and the ability to love and be loved in return, and that she required the same level of love and commitment that had been given to Rikku all these years. While I was waiting to get on the plane, I participated via chat in the "naming game" for this little kitty, and by the time I had gotten home, no suitable name  had yet been agreed to. This morning, though, that was resolved. We all agreed that her name would be "Éclair", because she looks like one with her chocolate and golden and white patches.

As I sit here today, walking around my home, listening for the barks and tell-tale scrabbling along the wooden floor that I would normally hear, it is clear that my little girl is gone. Rikku brought so much joy to my family, and I am missing her greatly. At the same time, Éclair is purring and meowing and nestling into my arms when I pick her up, and that brings a smile to my face. When I asked Christina what made her decide to get the kitten, she said it had been the eerie silence of the past two nights, the absence of the familiar noises and interactions with Rikku. She said the thought of dealing with that going forward was just too painful, and while part of her feels that having Éclair helps to act as a distraction to that empty silence, she is also warming up to her as well.

If you have read this far, I thank you. There really isn't a point to this other than I feel the need to talk about it and share this part of my reality at this time. As I was away for an entire week, I'm just now processing my emotions surrounding all of this. The one thing for sure is that time marches on, and changes will occur, whether we want them to or not. Life happens when you are busy making other plans, and sometimes, it has no regard for the things you had planned originally. Still, we have a chance to make new choices every day, and some of those choices can be profound. All we can do is live them and deal with the changes that come our way.

Concentration on Information Radiation

Ever have an experience at a conference that just sticks with you, that one thing that seems like such a little thing and then, as you consider it more and more, you just slap your forehead and say to yourself "for cryin' out loud, why didn't I think of that?!"

On Monday while I was at CAST, I was the room helper for Dhanasekar Subramaniam's tutorial about "Using Mind Maps for Mobile Testing". Much of the session was around heuristics for mobile testing and the ability to capture heuristics elegantly inside of mind maps. as part of the process, we spent a bit of time creating mind maps in XMind to use later with our chartered test sessions. I've done this before. I've even created a full mind map of the entire James Bach Heuristic Test Strategy Model (yes, one mind map and yes, when fully expended it is massive. Probably too massive). As we were working to create nodes and sub-nodes, Sekar pointed out that there were many labels that could be applied to the nodes, and that the labels were additive. In other words, each node could have several labels applied to them. 

As I was looking at this, and seeing labels such as pie chart fill, green check boxes, people silhouettes of several different colors, red x's, green yellow and red explanation points, and many others, I started thinking about how, by color and proximity, we could gauge how much coverage we have given a particular mindmap (or in this case, how completely we have applied a heuristic to testing) and what the results were for that. Instead of stopping to write down lots of notes, each node we were testing would get a label placed, and each label would have a semantic meaning. Green check box meant good, red X would mean failed or something wrong, a quarter pie chart would mean a quarter done, a yellow square would mean something that was a warning, but maybe not an error. Different color people icons would mean the person who performed that set of steps, and so on.

As I was looking at this, I joked with Sekar that we could tell the entire testing story for a feature or the way we applied a heuristic to a story in one place with one relatively small map. We both chuckled at that, and went on to do other things.

The more I thought about this, though, the more I liked the idea. In a previous company, we set up a machine and had a couple of flat screen monitors attached. These flat screens were placed in the main area and left on, cycling the images that were shown, only in this case, they were graphs and pages of results that were relevant to us. In short, they were acting as information radiators for our team. At a glance, we could know if the build had failed, if deployment was successful or not, and where the issue would be if there was one. We could also use this technique for information radiation. Imagine a charter or set of charters. Each one had their own mind map. Each mind map could be cycled through presentation on the monitor(s). the benefit would be that, at a glance, the team would know how testing was going fort that area, and we could update it all very quickly. I kept experimenting with it, and the more I did, the more I became convinced this just might work.

To that end, I am holding a Weekend Testing session this coming Saturday, August 8, 2015 at 10:00 a.m. PDT. We will look at mind mapping in general and XMind in particular, and we will develop a small heuristic for a feature (within XMind itself) to test and to update. I really like this idea, but I want to see if it can be tinkered with, and if it might be a useful approach to others.

If you think this might be a fun way to spend a couple of hours, come join us on Skype. Contact "weekendtestersamericas" and add us as a contact. On Saturday, get on Skype about 20 minutes before the session and say you want to be added to the session. Prerequisite, if you want to follow along and actually do the exercise, would be to download the XMind app for your platform.

 Again, I apologize for the short notice, but I hope to see you Saturday.

Do You Have To Be...

I'm sure you all thought you were through with hearing me post comments and thoughts from CAST, seeing as the conference finished last night, and all that's left today is to clean up the last bits and go home. while the conference is over, the reverberations from sessions should continue for some time to come. I woke up this morning and checked my Twitter and saw that I appeared in an interesting side discussion, and it's that side discussion, from a session I was not actually in, that prompted this particular post.

I've had the pleasure of getting together with and talking over dinner and at several other events with Jeff Morgan (@chzy) and Henrik Andersson (@henkeandersson) over the past few years. I have worked through Jeff's book "Cucumber and Cheese" and found it to be both great fun, and a great way to construct an automation framework. I have used Henrik's "Context-Driven Robots" module as a core component in teaching about context to new testers in the SummerQAmp curriculum. Both of these gentlemen took part in a spirited debate about whether or not software testers should code. Again, I could not attend this session because I was facilitating and co-presenting a session with Albert Gareev (@agareev) about how to design and how to test for Accessibility. Still, much was said and many tweets resulted from this discussion. I replied to some, retweeted others, and it was in this process and in light of one exchange that things got interesting :):

There's more to this conversation, and if you would like to see the rest,  I encourage looking at the other tweets, but the last message is what prompted this post today. I look forward to others who will post on the topic, too.

There are three aspects that I think are coming into play with this discussion:

1. Do we want to have a separate role and focus of energy within organizations for programmers and testers?

2. Do we want to see more testers become programmers in their own right?

3. Do we want to see programmers develop the skills to become better software testers?

Note: this may not be where the original conversation meant to go, and that's totally OK. This is my thoughts on this, and based on talks we had at CAST (I'm specifically thinking of Jessie Alford's talk about Pivotal and Cloud Foundry and how they code and test).

Let's start with the first. Several organizations are either considering, or have already decided, that there will not be a separate role for software testing that is distinct from programming (role as in dedicated teams or members of staff that do that particular job). Jessie Alford presented a model that Cloud Foundry uses where programmers rotate into a role for a time as explorers, and then they go back to programming. The focus and activities are the same. There is definitely software testing happening, and software testing as those of us who consider ourselves being testers would recognize as what we want to see testing be represented as. It is not, however, being performed by strictly manual testers. It is being performed by the programmers on the team. It's an interesting model, and from Jessie's talk, it's working quite well for them. Can a programmer be an excellent tester? If Jessie's experience is to be believed, the answer is "yes". This certainly indicates that the third point I mentioned above is not only possible, it is happening. 

There are arguments for and against a dedicated test team within an organization. My company has both roles and dedicated staff for them. We have dedicated programmers and dedicated explorers. We report to the same person, the VP of Engineering. At this time, the test team is integrated into the programming team, but we have a clear distinction between programmer and tester. That doesn't mean we don't program, especially in the area of automation. Each of us on the team has the skills and the experience to create and edit the automated tests that we use. I have the experience to be the release manager for the company, in addition to being a software tester. Thus, I certainly do feel that having programming skills can be a solid benefit to a tester. At the same time, I will not pretend that I have the same level of programming skill or experience as our production programmers do. I'm also not being asked to provide that. We have a dedicated person whose sole responsibility is to create automated tests. My teammates and I supplement their efforts, but generally, it's our efforts as explorers (to borrow from Jessie once again) that is desired most by our engineering team, at least at this time.

Michael Bolton makes a clear point in the exchange above and in other tweets that were part of the conversation. Do I have to be an expert photographer to edit National Geographic? Do I have to be an expert healer to be a pathologist? Do I have to be an expert mechanic to be a race car driver? Note, Michael didn't actually say that last one, I added it for the fun of it. The point is, we do not have to be any of those things to do the things that we excel at... but having a good knowledge of each area will certainly be helpful, as it will help us to understand better the domains we work in, and will help inform what we do. 

As testers, being able to understand code and what makes it work can give us a tremendous boost into ways we can test and ideas we can develop. At the same time, I've had experiences where the code I have written, and tested, has been enhanced by an external tester who can think of things I did not consider. I value that software tester's help and insights. I also realize that that software tester can be a programmer on my team. Exploration skills and mastery of testing approaches and ideas are important. If a team can do that with having programmers take on the role of explorers for a time, or reciprocate for one another in that capacity, it may prove to be a very workable solution. In other teams, it may make sense to have a dedicated testing group do that. 

As was made clear in the debate, the process of programming and testing are both vital. Both need to be done. There are many ways to accomplish those goals, and varying approaches will be used. Personally, I know enough programming to be dangerous, and enough testing to help mitigate danger. I'm not personally good enough at both to mitigate my own danger, but I'm working on it. My personal opinion as relates to the debate is that no, software testers do not have to be production level programmers in addition to being excellent software testers, but if you would like to get to know more about how systems work and what influences those systems to work, and if you have that base level curiosity that all good testers have (in my opinion), adding some programming to your personal portfolio would certainly not be a detriment. It's possible that you might learn something and decide that it's not for you. Again, that is OK, but don't be surprised if the effort to learn starts to give you new ways to think about the testing you are already doing, and presumably quite good at performing. In my opinion, that seems to be a good trade :).

Crossing the Finish Line - Reflections from #CAST2015

It's a little after midnight right now, on Thursday, August 6, 2015. The last talk was given six hours ago. Pizza, soft drinks and candy were brought in to complement the tester games and lightning talks. All during the evening, I shook hands with and got to meet many first timer attendees and thank them for putting their trust in us to put on a memorable conference for them. We look to have succeeded on that front.

I made it a point this time, as President, to sit a different tables and talk with people who were first timers at the conference. I wanted to understand what brought them here. Some came because of the reputation of CAST. Some came because co-workers recommended it. Some came because it was local to Western Michigan. Some came because at the last minute, the person who was supposed to come had to cancel and they were asked to go in their place. It was the last one I had a chance to hear about in the elevator as I headed upstairs after we finished everything. I asked her if she felt it was worth going in blind to an event she knew nothing about. She said "Yes, very much!"

This conference has been in the planning stages since this time last year. The board as a whole came out to Grand Rapids to check out the Amway Grand Plaza and scout out the surrounding neighborhood, and we felt we had a great venue to work with. The responses from the participants seems to confirm that fact. the conference committee handled logistics and contracts in as focused and timely a manner as could be hoped for. The Program committee did a wonderful job delivering a balanced program of excellent speakers, including a whole bunch of brand new speakers. We have been proud to sponsor new voices at CAST over the years, and especially this year, with the help of Speak Easy. Several speakers submitted papers to go with their talks and workshops, and those should be available soon.

I spent much of this conference in the role of a facilitator or facilitator's helper, and it helped keep me focused and alert to the questions and answers. Open Season means something quite different when you are the one managing the crowd and their expectations. Put simply, I would definitely do it again.

Each year the webCAST grows bigger and more people participate. I don't have hard numbers, but if Twitter is anything to go by, a lot of remote people liked what they saw and took to the Twitterverse to confirm it. Ben and Paul Yaroch, an excellent job once again. I can't wait to see the videos uploaded to YouTube.

We elected a new board for 2015-2016, and we released those who have chosen not to continue with the board going forward. as I said in an earlier post, I have bittersweet feelings about resuming my life as a civilian. On one hand, I feel four years is ample time. I think it's important that, for new ideas to take hold, those of us on the board don't run continually. We need to encourage other new voices to get involved and roll up their sleeves.  I may be back again to try to run in the future, but I feel it's time to step back and let others have a chance.

Overall, I want to say thank you to each and every one of the participants that carved out time during their week to come spend time with us. The conference is now finished, we have indeed crossed the finish line, and now it's on to the next adventure. That next adventure still has a few things that need to be ironed out before we can say anything, but I have a feeling that the audience and participants will love it ;).

That's it for me, I need sleep. Goodnight, everyone!!!

Exploring at Cloud Foundry - Live at #CAST2015

Jessie Alford told me something that astounded me... he's at Pivotal, working on Cloud Foundry... hey wait a minute, that means he's in my neck of the woods now! Mind you, that has nothing whatsoever to do with his talk which is "Driving Adoption of Chartered Exploratory Testing In An Agile Organization", but it made me smile because I  have talked with a n umber of people over the last couple of years about what Cloud Foundry does and how they approach testing... and now I can see it for real :).

Pivotal believes in exploratory testing, even if they don't have a dedicated test team. They have dedicated explorers that work in shifts along with their other development responsibilities. they create a variety of charters to help describe areas that might be risky.

I am impressed that a programming team would spent the time to develop charters for exploratory testing, but Pivotal has surprised me many times over the years (at my previous job I was a daily user of Pivotal Tracker). Jessie shared his backlog with listed charters, and it's cool to see how targeted they are.

Also what's cool is that everyone is encouraged to write charters, and each team develops their own norms as to how they are written. Each of the questions they ask are able to point back to the charters for targeted testing. As Jessie explained, charters are a general purpose scaffold. When Dev teams started looking at charters, they used them for testing, but they also started using them for lots of other things, like how to interact with other components, and use it to make sure that they are working effectively.

Another key aspect they learned was that pairing is not enough to communicate skills across an organization, but charters can allow teams to codify those abilities. Additionally, it's not enough to just teach exploratory skills, but to be able to confirm that those skills are transferred. In Pivotal, the term "test" doesn't get used very often in Pivotal, but "Explore" is an every day word. When you say test in a TDD, CI, CD environment, test has become so diffuse that it's lost its meaning, but exploring is easy to communicate, so it gets used. Automated checks are of course used and are important, but the ability to look at exploring makes clear the ways it is used in Pivotal, which is pretty cool.

Quick message to Natalie Bennett, Elisabeth Hendrickson and Dave Liebreich... Jessie done good, y'all should be proud of him. Jessie, if you find yourself down in the  Pivotal Palo Alto office, let me know so we can get together for lunch or something :).

Fomenting Change... In Space - Live at #CAST2015

We hear about organizations dealing with change for applications and hardware that are in data centers or in server farms in remote locations, but how about making changes to equipment that resides outside of Earth orbit... or on another planet entirely! Barbara Streiffert gets to deal with that reality as part of the Jet Propulsion Laboratory. She deals with testing of the Mars Rover, among other initiatives. Talk about a risk averse environment!

So much of this talk was specific to information shown on video. She showed us details about the Dawn Spacecraft and Ion Propulsion... wow, talk about a unique test experience! How cool would it be to work on systems that control Ion Engines! For those not familiar with what an Ion Thruster is, instead of heating the gas up, xenon is introduced into the gas chamber, and the ionization that results causes thrust (that's what I heard, I will not vouch that I got that right ;) ). Fortunately, this talk was part of webCAST, so everyone can see the videos and details.

The Dawn spacecraft flyover of Ceres is being shown, and my inner third grader is totally spazzing out right now :).

The Art and Science of Questioning - Live at #$CAST2015

It's fun being a facilitator, in that you get to actively participate in the discussion, and it also gets you up and moving. today I'll be spending most of my time facilitating the webCAST room, so if you see a bald guy in a white AST polo running around, yep, that is me :).

Jess Ingrasselino (@jess_ingrass) works with Bit.ly and worked as a music teacher prior to her tech career. I think that having that background is probably awesome for her being involved in programming and testing. She explained how she went from being a music teacher to quality assurance engineer, and that the processes are actually very similar. When a violinist or violist wants to start playing the Brandenburg Concerto, they don't start with the full piece. They start with the first note, or the first theme, and then they grow from there. There is a focus on building the knowledge and experience with performance and practice. Software testing does much the same thing; we start small with basic concepts, and we practice and apply them.

Testers ask questions, but not just any questions. They need to be targeted and specific, such that they may better understand and learn the product, and focus on other aspects of the product. I'm fond of the definition of testing that I use, which is "Ask the product a question, and based on the answer you receive, ask additional and more interesting questions."


Jess makes a case that borrowing from social science, and understanding the methods used in "qualitative research" makes it possible for us to ask compelling questions The methods Jess will use for this come from Robert Stakes. One of the areas to focus on is "multiple interpretation". What happens when different people with different permissions logged into the system? What is shared? What is unique to certain permissions?

One of the things that is vexing about asking questions is that we can fall into the trap of asking questions that are self-serving. We can easily craft questions that will provide answers that support our own beliefs or biases. We need to be aware of the unintentional ways that we word things or couch questions. Instead of asking "what issues are you having with development?", ask "can you describe for me your interactions with the functional teams in the organization?". Yeah, that seems like a squishy way of asking questions, but it allows the person being questioned to provide an answer free of initial or expected negativity. Instead of asking them to tell us what is wrong, we ask them what they do. In the process, they may more freely describe what is going wrong.

Another compelling answer to questions is silence. Yep. I've seen this many times, and silence means many things. It can mean "I'm thinking" or it can mean "I'm waiting to see if you will walk back that answer before I open my mouth." gauge the silence and don't be afraid to meet the silence with silence. It can often be used as a negotiating tactics. The marks are usually people who cannot get through the quiet and will start saying something, anything, to break the silence. Often, people who negotiate find that they settle for far less than they would if they were more focused on maintaining the silence.

Testers are, or should be, fundamentally curious. Even with that, asking questions is a skill, and it's one that can be developed. I see that studying up on qualitative research is in my future :).

The Future Is Here - Live at #CAST2015

It's Wednesday, and to be honest, the events of the past several days have become a blur. I've been in Grand Rapids since Friday, and I've been moving non-stop since I've been here. Test Retreat, conference setup, facilitator meetings, elections, logistics, rooms, venue preparations... it's easy to lose track of where we are and why we are here. I joked a few days back that I and the rest of the board and conference committee were busy doing all we could "to make all your wildest conference dreams come true". I'm not sure how we've delivered on that, but from the tweets I have seen, and the comments directed to me thus far, I think we're doing pretty good on that front :).

I was excited to see that Ajay Balamurugadas was chosen to be Wednesday's Keynote speaker. Ajay was one of the first software testers I had the pleasure to interact with when I chose to plug into the broader software testing community. Many testers were saying things and spouting ideas, but Ajay was rolling up his sleeves, doing stuff in real time, and sharing his results, both good and bad. Ajay introduced me to Weekend Testing, and then encouraged me to bring it to the USA. He stayed up late for his time to shadow me and offer suggestions for the first few sessions we did, and then he let me fly on my own. He has participated with many of our Weekend Testing sessions, including a session with flawk, which is a company my friend Matt Coalson has been building the past few years. Matt's literal words to me about the session was "Dude, that guy, Ajay? Wow, he's the real deal!" Ajay has put the time and the energy in to prove, time and again, that yes, he is indeed the real deal!

Ajay did something pretty bold for a keynote speaker. he put up a mind map of his talk and the details titled "Should I listen to Ajay?" In a nutshell, he says that he will be covering Learning opportunities, a trend in who tests, testing education, testing & other fields, Standards and schools, and his own thoughts. He then said he invited those with more important things to do to leave, and he would be totally OK with that. Notice I'm still typing ;). Right now, this is the most important thing I can be doing :).

Ajay starts with a quote from Aldous Huxley... "try to learn something about everything, and everything about something". In a nutshell, to borrow from Alan Page (and yes, others say it too, but Alan is famous for talking about this on the AB Testing Podcast) "be a generalizing specialist as well as a specializing generalist". Be T-Shaped, a jack of al trades who makes a priority of getting genuinely geeky with a few areas that you enjoy and feel are valuable. Don't just be a software tester, actually learn about software testing. Some ideas are going to be better than others, but dig in and try ideas out. Learn as much as you can, even if it's to decide what you will discard and what you will keep. Why do we so often welcome new testers with test cases? Do we not trust them to be able to test, or do we just insist on them doing what we tell them of front, with hopes that their creativity will appear later? If they are given prescriptive test cases, and told to execute them, don't be surprisedif that hoped for creativity does not appear.

there are several organizations taht exist to help teach software testers, some obvious and some less so. Ministry of testing, Weekend Testing, BBST Testing Courses, Udemy, Coursera, Test Insane's Mind Map collection, the Software Testing World Cup... there's *lots* of places we can learn and try out new ideas.

Ajay said something pretty cool (attribution missed, will fill in later).. "If you would like to double your income, triple your learning!" we each need to take the opportunities we have, and we need to apply them. I personally believe that my blog exists for this purpose. Sometimes I have let several days go fallow without writing because I feel I don't have anything unique to share. However, I have had such a rush these past few days writing summaries and interpretations of each of the sessions I've been involved in since Saturday. Before August, my largest number of blog posts for any given month was nine, and sometimes I felt like I struggled to get those out. Right now, I'm writing the eighteenth blog post for August, all of which inspired by my being here in Grand Rapids, with the activities I've been participating in. If all goes well, I may have four more to offer by the end of today. Seriously, that's twenty-two blog posts in five days! What's interesting is that, as I've written so many, I'm feeling energized, and I want to keep that energy going. That's the power of diving into your learning, and creating in the process. I want to see what it takes to keep it going.

Ajay has asked why you need a title to be a leader? The truth is, you don't. You can lead right now, and you can be an example and a guide to others. You do not need to ask permission, you just need to act with conviction and determination. Figure out the things you can do without having to ask permission, and dig in. If a process is slow, try another one. In parallel, if you must, or totally replace the old efforts with a new approach if you can do so. People may feel frustrated if you go and do something without asking, but they will likely keep what you are doing if you deliver a better result than what they were getting before.

What do you say when someone says "I'd like to become a software tester, what do I need to know?". Do we tell them the truth, that it can be exceptionally hard, and that there is so much to learn? Do we tell them that there's a lot of things they can get involved with? Do we encourage their curiosity, and get them engaged where they are? Personally, I think we can do a lot of good by starting with where people are and showing them the fun and experience software testing can be. Granted, it's not always fun, but there's plenty of opportunities to explore and be curious. De-emphasize the mechanics of testing, encourage the curiosity. Software testing classes are developing. I'm biased, but I'm pretty fond of the BBST courses and what they offer. Still, there's a need for more, and we have an opportunity to help make that happen. It will take time, of course, but there is a need for excellent software testing training. Let's do what we can to foster and develop it.

My thanks to Ajay and his devotion to our craft. He's a role model that I believe any software tester would do well to emulate, myself included. At this point I need to get ready for Open Season and help facilitate questions and answers. Thanks for playing along with me today, I'll be back in a bit :).

Early Morning Musings - Live from #CAST2015

For those not familiar with the concept of Lean Coffee, a group gathers together (coffee optional), proposes a set of topics, organizes the topics to see if there are synergies, votes on the topics to set the order of discussion, and then goes into discussion of each item for an initial five minutes. If there is still energy for the topic after the first five minutes, we can vote to continue the discussion or stop it and move on to another topic.

Today's attendees are/were:

Perze Ababa, Carol Brands, James Fogarty, Albert Gareev, Dwayne Green, Matt Heusser, Allen, Johnson, Michael Larsen, Jeff MacBane, Justin Rohrman, Carl Shaulis

Topics that made the stack:

Testing Eduction, What's Missing?

Thoughts thrown out by the group: Accessibility, Test Tooling, Mobile and Embedded, Emerging Technologies, Social, Local, Geographically Tied Applications, Testing Sttrategy

Of all of these ideas, the testing strategy seemed to get the most traction. Everyone seems to think they know what it is, but it's a struggle to articulate it. Regulatory compliance could be a relevant area. What about shadowing a company(s) and see what they are doing with their new testers, especially those who are just starting out? What are their needs? What do they want to learn? What do those companies want to have them learn? Consider it an anthropology experiment. Action was to encourage the attendees to see which companies would be game to be part of the study (anonymized).

How Can We Grow Software Testers Through our Local Meetup Groups?

Getting topics of interest is always a challenge. How do we focus on areas that are interesting and relevant without being too much the same as what they deal with a work. Albert has been hosting a Resume Club at his Toronto Testers Meetup, and that's been a successful focus. Gaps in experience can help drive those discussions. Lean Coffee format itself can be used in meetups, and the topics discussed can help develop new topics that appear to be of interest to the community. Encourage games and social interaction, we don't necessarily have to focus on talks and discussion. ST Grant program can also be used for this. We offer grant funds for meetup support, but we also have the option of flying in people to meetups to help facilitate events as well (Michael did this in Calgary back in 2012 for the POST peer conference).  If monthly meetup is too difficult, commit to quarterly and work to recruit speakers in the in between time. If the critical mass gets large enough, schedule more meetings. Have a round robin discussion from a talk that's already been presented and recorded. Make workshops based on topics of interest.

Writing Code For Testers Via Web Based Apps

Matt discussed this around a web app that aims to help teach people to program (as part of a Book to Teach People How to Code in Java). In a way, this is a two part problem. On one hand, there's the interface to engage and inform the user to get involved and learn how to code. The second is the meta-elements that can determine if the suer has completed the objective and can suggest what to do.  Both require testing, but both have different emphases (the ability for an application to determine if "code is correct" can be challenging, and there is always TiM TOWTDI to consider (There Is More Than One Way To Do It).

Good discussions, good ideas to work with, and so many more possible things we didn't even get to consider.  Lock and learn for me is that it might be cool to run an anthropology experiment with other companies to see what they want to have their testers learn.

Time for breakfast, see you all in a bit :).

Leaping into Context - Live from #CAST2015

Erik Brickarp gets the nod for my last session today. After facilitating three talks, it feels nice to just sit and listen :).

Erik's talk focuses on "A leap towards Context-Driven Testing". When chaos and discord start raining down on our efforts, sometimes the best break through comes with a break with.  In 2012, he joined a new team at a big multinational telecom company. That team had a big, clunky, old school system for both documentation and loads of test cases (probably based on ISO-9001, and oh do I remember those days :p ). What's worse, the teeam was expected to keep using these approaches. To Erik's credit, he decided to see if he could find a way out of that agreement.

The team decided they needed to look at the product differently. Rather than just focus on features  and functions, he also decided to look at ways that the project could be tested. In the process of trying to consider what the test approach had to be, they moved from multiple spreadsheets to web pages that could allow collaboration. By using colors in tables (as they used previously in cells) they were able to quickly communicate information by color and by comment (reminds me of Dhanesekhar's tutorial yesterday ;)).

By stepping away from iron-clad rules and instead focusing on guidelines, they were able to make their testing process work more efficiently. Of course, with changes and modifications, this welcomes criticism. The criticism was not based on the actual work, but they were upset that the junior team member went behind the back of the organization to "change the rules". Fortunately, due to the fact that the work was solid and the information being provided was effective, informative and actionable, they let them continue. In the following weeks, they managed to make the test teams deliverables slimmer and more meaningful, faster to create and easier to maintain. By using a wiki, they were able to make the information searchable, reports listable, and easy to find.

Erik admits that the approach he used was unprofessional, but he was fortunate in the fact that the effort was effective. As a lesson learned, he said that he could have approached this with better communication and could have made these changes without going behind their backs. Nevertheless, they did, and so they have a much more fun story to tell. The takeaway here is that there is a lot of things we can do to improve our test process that don't specifically require corporate sanction. It also shows that we can indeed make changes that could be dramatic and not introduce a ton of risk. Support is important, and making sure the team supports your efforts can help testers (or any team) make transitions, whether they be dramatic or somewhat less so.

Additionally, if you have a hope to change from one paradigm to another, it helps a great deal to understand what you are changing to and how you communicate those changes. Additionally, make sure you keep track of what you are doing. Keeping track doesn't mean having to adopt a heavy system, but you do have to keep track. Exploratory testing doesn't mean "random and do anything". It means finding new things, purposefully looking for new areas, and making a map of what you find. When in doubt, take notes. After all that, make sure to take some time to reflect. Think about what is most important, what is less important, and what I should be doing next. Changing the world is important, and if you feel the need to do so, you might want to take a page from Erik's book. I'll leave it to you to decide if it makes sense to do it in full stealth mode or with your company's approval. the latter is more professional, but the former might be a lot more fun ;).

Get Your Gandalf On For #a11y Testing - Live at #CAST2015

We spent the first part of the session framing the problem and encouraging the attendees to discuss the issues, now we are unleashing the hounds and letting them hear what a site sounds like as seen by a screen reader. To be brave, we submitted the AST web site to the #a11y treatment. Needless to say, we have some work to do to behave better with screen readers, but it made for a great way to discuss the challenges.

We have two angles we use to approach the acccessibility question. The first is to frame questions we can ask and principles we can discuss at the initial design phase. The ten principles I like to use come from Jeremy Sydik's book “Design Accessible Web Sites: Thirty-six Keys to Creating Content for All Audiences and Platforms (Pragmatic Publishing, 2007)":

1. Avoid making assumptions about the the physical, mental, and sensory abilities of your users whenever possible.
2. Your users’ technologies are capable of sending and receiving text. That’s about all you’ll ever be able to assume.
3. Users’ time and technology belong to them, not to us. You should never take control of either without a really good reason.
4. Provide good text alternatives for any non-text content.
5. Use widely available technologies to reach your audience.
6. Use clear language to communicate your message.
7. Make your sites usable, searchable, and navigable.
8. Design your content for semantic meaning and maintain separation between content and presentation.
9. Progressively enhance your basic content by adding extra features. Allow it to degrade gracefully for users who can’t or don’t wish to use them.
10. As you encounter new web technologies, apply these same principles when making them accessible.

From there, when we consider the design issues we want to discuss, if we want to be ready to discuss the requirements and do early testing on initial designs, we can use a heuristic called HUMBLE:

Humanize: be empathetic, understand the emotional components.  

Unlearn: step away from your default [device-specific] habits. Be able to switch into different habit modes.

Model: use personas that help you see, hear and feel the issues. Consider behaviors, pace, mental state and system state.

Build: knowledge, testing heuristics, core testing skills, testing infrastructure, credibility.

Learn: what are the barriers? How do users Perceive, Understand and Operate?

Experiment: put yourself into literal situations. Collaborate with designers and programmers, provide feedback

Both the design principles and the HUMBLE heuristic are useful early in the process of discussing Inclusive Design and overall Accessibility coding. What can we do when we are testing an existing feature, and we are evaluating it for Accessibility? We are working on a feature that is Dev Complete and has been delivered for testing. Do we have some suggestions for that situation? As a matter of fact, yes :).

Albert encourages testers to embrace "PaSaRaN". the word "pasaran" in Spanish means "They Shall Pass". If you say "no pasaran" you are effectively saying "you shall not pass"... and now my cheesy title should make a little sense ;).

PaSaRaN is a method of testing if a Page allows for Accessible Scanning, Accessible Reading
and Accessible Navigation.

It's entirely possible that you can go through your testing career and never get involved in an Accessibility project, but it's a very good bet that issues surrounding Accessibility will affect you at some point in your life, whether it be in a secondary or primary aspect. If you would like to evaluate products for Accessibility, PaSaRaN is a clever short-hand. If you find yourself getting into site design or web development, I'd like to encourage you to consider the ten principles and be HUMBLE in your designing and coding. Also, if you would like to talk about any of the stuff that we covered directly in the workshop, please feel free to contact either Albert or me and we'll be happy to answer any questions.

Finding Your #a11y in Accessibility - Live from #CAST2015

Albert Gareev and I have been working on the material for this presentation for a long time, so I am excited to be facilitating this workshop session. Albert is making his debut as a speaker at CAST, and more important, this conference has been the first time we have met each other in person. We've collaborated online for five years, so to finally get to work together on this material as relates to accessibility means a lot to both of us. The fact that we have a group of people interested in participating with us is icing on the cake :).

Accessibility is not just for people with "special needs". Accessibility comes into play for everyone at some point. In the presentation, we presented an example of a person with several "physical impairments" and asked the group to tell us what this person looked like. We had some interesting discussions, and then we revealed the trap, a picture of a young lady looking at her cell phone while walking across the street. After a few chuckles and an explanation, we introduced the idea of "secondary disability" or the fact that there are certain environments where a person has a special need, where in their regular environments they might not. Over time, if we are lucky to live long enough every one of us will deal with a special need that falls into the Accessibility realm. If we have impressed on the group that Accessibility is more than just for people with specific disabilities, I will consider that a huge success.

Albert and I both agree that putting a heuristic out there for people to use, while helpful, is much more potent when it is seen in action. A few months ago, I had the chance to give an accessibility talk at STP-CON in San Diego, and as part of my presentation, I asked the participants to fire up a screen reader on their systems and navigate to one of their favorite pages. As the screen reader started to do its job, the reactions were both amusing, and very telling. They "saw" how difficult it was for non-sighted users to "listen" to the information on the screen. They were drowned by the rapid fire speech that was trying to articulate what was on the page. this was one example and one condition. There are many other areas that accessibility covers as well (non-sighted, limited-sight, no-hearing, limited-hearing, limited movement, limited cognitive ability, etc.).

Accessibility is a difficult requirement to test for, in the sense that context has to be taken into consideration. Most of the time, we have to pick and choose which Accessible features we will use and who we will address. Is it enough to make a screen reader work with the product? Do we need to also had closed captioning for hearing-impaired? Do we have a way to make shortcuts for limited movement? Are we looking to address all of them at once, or are we willing to take them on one at a time.

We're taking a break now, so this seems like a good time to push this out. I'l come back with part two of our workshop in a bit.

Can I Lean on My Context at My Startup? - Live at #CAST2015

Eric Reis wrote an interesting book called "The Lean Startup" back in 2011, and it's become quite the buzzword du jour. Thomas Vaniotis has decided that he wants to get beyond the buzzwords and actually discuss Lean Startup and make the case that Lean Startup is all about testing.

Thomas recently made the shift from Technical Tester to Product Manager, working with a "Lean Startup" and he states categorically that he is doing as much testing as ever, if not more so. Thomas uses Eric Reis' definition of a startup, which is "a human institution designed to create a product or service within an environment with extreme uncertainty". "Lean" is the idea that we want to focus on the essential value, and remove the waste from the system wherever possible. Put the two concepts together, and you get "Lean Startup". This means that organizations that embrace this are going to look rather different from one another. It also means that what is considered value and what is considered waste will be different in each organization. Testers, this means that context matters a LOT!

Waste can vary. Overproduction is a real issue in a literal product factory, but it's also visible in software for features that are not used or have no value. Code needs to be maintained, tests need to be run, refactoring needs to take these empty features into account, and other features that may be more important are not made because the time is being spent working on stuff that is not relevant. Idle machines are a reality in factories, and backlogs in moving features forward is every bit as bad. I see this when we have a number of stories in DevComplete but with no testers with open cycles to work on them. What happens? They sit there until they can be picked up and addressed. Over time, this lag can be significant; getting a feature from PM proposal to shipped can take days, but some times it can take months or even years. In all, identifying waste takes some time and talent to recognize, and it can be a real struggle to eradicate it once it builds up.

There's waste in programming, there's waste in design, there's waste in testing,and there's waste in release. It just happens. the goal is not to eliminate it, but it is important to look to see where waste occurs and see what can be minimized. Testing is part of of the waste production and waste prevention culture. It's a solid part of what we do as testers, not just to find problems but to also find inefficiencies that we can work on. How do we do that? We can do that with Validated Learning, which means we subject failure to scrutiny, which in turn opens us up to failure. It's possible our investigation may disprove our hypothesis. Our experiment may show that we are wrong in our assumptions, but learning that also helps us expose and remove waste, even if the waste we remove is faulty assumptions of our own.

One of the ways we can help drive the learning is with a "Minimum Viable Product". This is an ideal method for applying what is called the "Build-Measure-Learn" loop. By building the smallest possible product, we can learn if our ideas our sound, if our product meets the need and if the data we receive supports the notion that we are on the right track. testers do this all the time, even with something that's not a MVP. New ideas are spun out from each cycle of this process. If this looks a lot like exploratory testing, indeed, it is :).

Thomas used a number of interesting examples (Zappos, Dropbox, etc.) and how they made their minimum viral product. For Dropbox, it was a video explaining why they had a solution for something most people hadn't figured out was even a problem. Additionally, Dropbox did it in a way that everyone could understand... it's a folder. That's it! For most people, that's all they need to know or deal with, and it's proven to be wildly successful. Food on the Table designed their system around initially a single customer. By working specifically with that one customer, they discovered what they needed to do to refine and create the system that would ultimately develop, and with each new family they added, they refined it even more, including automating a lot of the processes.

When we make MVP's, we need to measure the effectiveness of our efforts. In short, we need actionable metrics. What is the data telling us about our product, and are we accurately measuring something that is relevant? Does our vanity influence this choice of metrics? It certainly can. Case in point, I love seeing the hits on my blog each day. Yes, I pay attention. The problem is, hits alone tells me very little. It may mean people come to see my page, through some means, but does it mean they read the whole post? Does it mean they liked what they read? Does it mean they shared the link with someone else? Hit count won't tell me any of that, but it sure sounds good to say "hey, I received thousands of hits when I posted this". that's a vanity metric. It feels good, but it doesn't really tell me much, and it certainly doesn't guide me to action.

Once you have data that tells you that something isn't working, you need to change. The term for this is "pivot", and pivoting is much harder with large and bulky products. MVP's are easier to pivot with. Additionally, pivoting isn't just doing something different, but it's helping people see a pain point that they don't know about and you are ready to address. In this case, testing can help the organization not just confirm quality, but also see avenues to pivot into as well.

Lean Startups are often associated with Continuous Delivery. The reasoning is that, if we can deploy more frequently, releases themselves become much smaller and more manageable. When an organization gets to pushing multiple times in a day, releases can literally be a single story or a single bug fix. The turnaround time, instead of being counted in days or weeks, could be counted in hours, or even minutes. This approach doesn't minimize testing, it exposes it as even more relevant and necessary.

While MVP's are a starting point, the fact is, the product needs to mature and quality needs to continually improve. By using the Lean approach, that process becomes easier to manage, because the experiments are smaller and the turnaround time to getting a broken build fixed becomes easier with smaller incremental changes. Regardless, some experiments fail, and the line needs to be stopped at times. Be ready for that.

Time to put on my facilitator hat. Thanks, Thomas for a great talk, and now let's see what the audience has to say :).