Ah yes, the after lunch stretch. I will confess I'm a tad bit drowsy but what better way to cure that than to have a rapid-fire set of five-minute test talks.
We've had several speakers play along with a variety of topics:
Brian Kitchener getting hired into a QTP shop with a background in Selenium. His idea was talking about how to make organizational changes when they are a big ship and you are just one person. The answer is lots of little changes to help prove that making small scale changes and proving their benefits can be scaled to make larger changes.
Brian Saylor talked about the idea that "CAN'T" is a four letter word. To Brian, can't is the most offensive word.
"I can't do that" really means "I don't want to do that".
"It can't be done" often means "I'm too lazy to do this"
"You can't do that" often means "I can't do that, so therefore you shouldn't be able to"
Thus Brian asks us to be sensitive and to strike the word "can't" from our vocabulary and see what it is we are really saying.
Tricia Swift talked about changes she has seen over the last twenty years. The major changes she noticed was that there was about ten percent of her MIS class who were women. Compared to her CS friends, she was a lot more represented. She is happy to see that that has changed. ISO compliance and Waterfall was everything twenty years ago (and oh do I remember *that*). Thankfully, much of that has changed, or at least the approach has changed. Most important, she is seeing women in development where twenty years ago there were very few.
Raj Subramanian wants to make it clear that "It Is OK If You Mess Up". The issue with a culture where messing up is punished means that nothing creative or innovative will be tried. Cultures that penalize people for making mistal=kes ensure that they will remain stagnant. Raj basically shared an example where a test had an effect on production (an airline app) and the learning experience was that his rogue test exposed a series of policy problems with their production server. Raj still has that job and the product was improved, all because a mistake was acknowledged and accepted.
Anan Parakasan shared his experiences with the conference and the development and focus on "trust". It's a word that has a lot of different meanings and isn't exactly easy to nail down. Anan shared ways that he felt that trust could be better fostered and developed for our teams. Additionally, developing Emotional Intelligence will help considerably by making a team more effective. Think less adversarial and more collaboratively.
Final talk is Heath (?) and he talked about "feature flag insanity" and the fact that his organization has gone a bit trigger happy with their feature flags. Having them means running with them on, of and not there. However, his point was that the flag had contexts that were understood by some people but not others. Needless to say, the feature flag had an option to fail every credit card transaction. Not being able to find it and have it rolled out to production meant that every credit card transaction in production was failed and that cost a whole lot of money. In short, know your system, document it and make sure everyone knows what the feature flags do.
Came down to Raj and Brian Kitchener and they both have $50 Amazon gift cards. And with that, I'm much more awake ;).
Using Agile to Adapt to Changing Goals There's an old joke that goes around that says, basically, "If you don't like the way things are today, come back tomorrow". Meaning the only true constant is change and change happens a lot. We all have choices to be a driver of change or to have change be driven onto us. To this idea, any goals that your team has made are just as likely to change.
Sue Jagodzinski described her own situation of change within her company and the chaos that resulted from it. Part of her story described the challenges of managing two teams that were focused on different things. Both teams needed to use and support the adoption of a test automation tool and to be able to enhance and support that tool. One team focused on build, test, and automation. The other team focused on training, support, and documentation. While the tool they were working on was the same, they had very different missions and purposes and that would show up in the backlogs they built up and the priorities they placed on their respective backlogs.
Here's a bit of nerdy for you. The training and support team decided to call themselves Team1. In retaliation, the other team called themselves Team0 because they understood how arrays were indexed (and yes, this was a real dynamic between these teams. I thought she was kidding, she assured me she was not.
To this end, Sue determined that there were some key danger signs happening here. By segregating responsibility between two teams, there was an unhealthy competition that developed. trust issues developed along the way. when there issues there was plenty of finger pointing to go along with it. Most visibly was the fact that there were conflicts where teams would determine what to work on was guided by whatever the other team was not working on.
By moving to a shared backlog, the teams came into immediate conflict and had to negotiate how to change that dynamic. Some of the areas that Sue addressed was:
- how can we determine the skills that were needed on each team, and institute necessary moves if needed?
- determine the soft skill levels of the team members, who were the leaders? Who could become a new leader if needed?
- who would be best served to go elsewhere?
- how could we restructure the teams to be less contentious?
The last one was easy-ish to solve by changing names. the two teams for purposes of this presentation were "Awesomation" and "Thorium". Both teams agreed to go to a single backlog. Teams were set up so that both teams had technical expertise in the test framework. More to the point, an emphasis was made to reward and encourage those that would share their knowledge and skill sets. By doing this Sue was able to get close to equalizing the team. By sharing a backlog, the grooming sessions were done together, with their expected challenges. Sue took over as the product owner and she had to learn what that entailed. She described the process as being "harder than many people might realize" in addition to getting a better knowledge of the product.
The net results of this process, though not easy, were that they had the ability to learn how to do any task on either of the teams. In other words, two teams with Generalizing Specialists (service mark Alan Page ;) ). In the process, each of the team members engagement increased, different perspectives were heard, learning and reflection were done in the retrospectives, and the teams learned to progress together. Perhaps the most valuable skill they both discovered they could do was to adapt to priorities and be able to pivot and change if/when necessary.
OK, this gets me to a third of the way through the challenge. Fortunately, this is a relatively easy entry as I get to talk about other people doing great stuff and I'm glad to oblige. With that, let's keep this 30 Days of Testability Party going, shall we?
Follow and share three people on LinkedIn/ Twitter who regularly talk about testability.
If you read my previous entry about sharing a video, this name should be familiar. He also has a pretty extensive blog and a lot of learning resources via his own books and via YouTube.
Maria covers a lot of ground and has excellent content that she frequently shares. As to the topic at hand, check out her "Testability Awakens" article she wrote for Testing Trapeze.
I have been terrible with my shameless self-promotion as of late, but I think it's time I switch that up a bit. Remember my comment about that "grind" earlier in the week? Here's the end result and yes, I always feel better about it after it's all said and done because I enjoy seeing the end product and most importantly sharing it with everyone out there.
I have a little favor to ask as well if you are so inclined. Do you enjoy listening to The Testing Show? If you do, could I ask you to go to Apple Podcasts and write us a review? Reviews help people find the podcast and make it more likely to appear in the feed listings. Seriously, we all would really appreciate it. We work hard to bring these out and I'd love nothing better than to have more people be able to find it.
In any event, we hope you enjoy this month's episode. To set things up, here's the lead in for the show:
August is a busy time of year for software testing conferences (not to mention conferences in other industries). This month, we decided that, with everyone heading off to conferences hither and yon that we would dedicate a show to the topic, and we have done exactly that. Anna Royzman (Test Masters Academy), Claire Moss (DevOpsDays) and Mike Lyles (Software Test Professionals) join us as guests in their capacity as conference organizers, speakers and attendees (not necessarily in that order) to riff on Conferences and Conferring with Matthew Heusser, Michael Larsen, and Perez Ababa. Want to know where to go, what format to take part in or if you want to try your hand at speaking/presenting? We’ve got something for all those bases!
Any time I attend a conference, I tend to go with 70% new content and about 30% familiar speakers. Over time, I've found it harder to look for new people because many of the people I get to know get asked to repeat present at conferences. With that out of the way, I consider Damian Synadinos a friend, but I picked his discussion for a specific reason. While I think he is intending for this to be about public speaking, I'm looking to see how I can leverage public speaking focus on my own active company interactions.
Why do I speak at conferences, at meetups, or at events? There are a variety of reasons but if I have to be 100% honest, there are two reasons. The first is wholly professional. I want to develop credibility. I want to show that I walk the talk as well as that I know at least an aspect of something. The second is personal and depending on how well you know me, this is either a revelation or so obvious it's ridiculous. I'm an ex-"RockStar". I used to spend a lot of time entertaining people as a singer and I loved doing it. I get a similar rush from public speaking, especially when people say they actually enjoy what I'm talking about and how I deliver the messages I prepare.
Part of talking in public is the fact that you are putting your ideas out there for others to consider. That can be scary. We own our ideas and our insecurities. as long as we keep them to ourselves, we can't be ridiculed for them. In short, people can't laugh at us for the things we don't put out there. Personally, I think this is a false premise. I have had people laugh at what I presented, but not because what I was saying was foolish or made me look dumb. Instead, it was because what I was talking about was in and of itself funny (actually, more absurd) but people laughed because they could relate. To date, I have not been laughed at. Laughed with, lots of times. If you are afraid people will laugh *at you*, let me reassure you, it's hugely unlikely that will happen.
The biggest reason why I encourage getting out there and speaking is that our ideas deserve to be challenged and we should want to challenge our ideas. Also, we may never aspire to get on a stage and speak, but all of us participate in meetings or presentations at work, in some form or another. By getting out there and speaking, we can improve our ability to function in these meetings.
Something else to consider for a reason to give a talk or speak in public is what I call the "ignorance cure" for a topic. It's wise to talk about stuff we know about, but once a year or so, I will deliberately pick something I don't know much about or that I could definitely know more about. When I do this, I try to pick a timeline that gives me several months so that I can learn about it in a deeper way. People's mileage may vary with this, but I see a definite benefit from doing this.
Not every talk idea is going to be amazing. Not every talk idea is going to be some revolutionary idea. Truth be told, I'm lousy at revolutionary things. I'm highly unlikely to be creating the next big anything. However, I am really good at being a second banana to take an idea someone else has and running with it. Don't be afraid that something you want to talk about isn't new. We aren't born with ideas, and most of the time, we stand on the shoulders of giants.
My recommendation to anyone who has any interest in public speaking, no matter how small, is to borrow from Morrisey... "Sing Your Life". Talk about your experiences, as they will always be true and real. You may not be an expert on a topic, but you are absolutely an expert on *your experiences* with that topic. Also, if anyone wants to get up and talk, let me know. I'd be happy to help :).
One of the fun part of being a "recidivist conferencist" is that we get to develop friendships and familiarity with speakers we get to see over several years. Mark Tomlinson and I share a ridiculous amount of history both in the testing world and personal endeavors, ao I always enjoy seeing what he is up to and what he will talk about at any given event. This go-around, it's "Testing Teams and Strategies" so here we go...
Does it seem common that the people who decide what you do and how you do it have NO IDEA what it is you actively do? I'm fortunate that that is not so much the issue today but I have definitely lived that reality in the past. It's annoying, to be sure, but often it comes down to the fact that we allow ourselves to be pigeonholed. The rate of change is insane and too often we think that we are being thrown into the deep end without a say if what happens to us. If we don't take some initiative, that will continue to happen to us.
I've had the opportunity over the past (almost) three decades to work in small teams, big teams, distributed teams, solo, and freelance. Still, in most of my experiences, I've been in what I call part of "the other" organization. That's because I've worked almost exclusively as a tester in those three decades (my combined time as a cable monkey, administrator and support engineer equals up to less than four total years and even in those capacities I did a lot of testing). Point being, I've spent more time as part of another organization that has been siloed. It's a relatively new development that I'm working on a team that's both small enough and focused enough where I'm actually embedded in the development team now. As a point of comparison, my entire development team is seven people; three programmers, three testers, and one manager. Really, that's our entire engineering team. That means that there is too much work and not enough people for anyone to be siloed. We all have to work together and in reality, we do. My role as a Tester has dramatically modified and the things I do that fall outside of the traditional testing role is growing every day.
if I had to put a name on our type of team, I'd probably have to describe us as a blended group of "Ronin", meaning we are a relatively fluid lot with a host of experiences and we are ultimately "masterless". If something needs a champion, it's not uncommon for any of us to just step up and do what's needed. The funny part is Mark just put up the "non-team testing team" and basically just defined what I just wrote. Ha!!!
OK, so teams can be fluid, that's cool. So how do we execute? Meaning, what is the strategy? To be clear, a strategy means we deliver a long-term return on investment, align resources to deliver, arrange type and timing of tactics and make sure that we can be consistent with our efforts. Ultimately, we need a clear objective as well as a strategy to accomplish the objective. Sounds simple but actually being concrete with objectives and developing a clear method of accomplishing them is often anything but. In my opinion, to be able to execute to a strategy, we have to know what we can accomplish and what we need to improve on or develop a skill for. Therefore a skills analysis is critical as a first step. From there, we need to see how those skills come into play with our everyday activities and apply them to make sure that we can execute our strategy with what we have and develop what we need to so that we can execute in the future.
I had to step out and take a meeting so I missed probably half of Damian Synadinos' talk. Therefore, if this feels incomplete and rambling, well, that's because it literally is ;).
I am intimately familiar with being asked "what I do" as well as "who I am". The fact is, I am a lot of people. No, I don't mean in a schizophrenic sense (though that's debatable at times). I mean it in the Walt Whitman sense:
"Do I contradict myself? Very well, then I contradict myself, I am large, I contain multitudes."
The point is that we are never just one thing. All of our quirks, imperfections, and contradictions come from our many experiences, histories and active pursuits.
Depending on who you talk to about me, you might get a wildly interesting view of exactly who I am. It might get really interesting depending on what period of my life you ask about, but if I had to guess, these identities might show up:
actor
bass player
bodybuilder
boy scout leader
carpenter
cosplayer
dancer
drummer
father
fish geek
gardener
guitar player
husband
mandolinist
mormon
obsessive music fan
otaku
photographer
pirate
podcast producer
poet
programmer
prose writer
singer
snowboarder
tester
video gamer
yogi
If I had to choose a specific attribute, I'm going to lay claim to "eclectic".
Each of these has informed my life in a variety of ways, and each of them has given me skills, interests and a number of very interesting people to do this variety of things with. In many ways, it's the people that I interacted with that informed how long or how little time any of these endeavors/attributes have been a part of my life, but all of them are and all of them have provided me skills to do the things I do.
Also, if any of the items on that list have you wondering what they are or how I'm either actively involved in or why I chose to mention them, please be my guest :).
One of the most difficult to pin down topics and titles of the last couple of decades is to define oneself as a web developer. What exactly does that mean, and what skills does one need to know to become one in this day and age?
Starting with the Prologue, Julie describes the specific circumstances that started her on this journey. With a softening job market during what we now refer to as “The Great Recession,” Julie describes how she moved from being a bank teller to become a junior developer. Her point in sharing this story is to make clear that you don’t need an advanced degree in computer science or have lots of history as a programmer to make the shift into doing web development. This book pledges to help you make that transition. Does Julie deliver on that promise?
Chapter Zero: Prepare for the Journey
Julie sets out some basic markers to help you make the most of this journey including the idea of starting your job hunt while you start your web development journey. Counterintuitive, but makes good sense. Looking at what is out there, what is required and what skills are consistently being asked for is a great way to tailor your learning path. Utilizing Meetup groups and other resources will also help. Determine how to measure your progress, whether that be a way to check in with an online community or work with a specific mentor or group of people. In this day and age, showing goes a long way and having resources you can demonstrate to show your skill can be a big boost in this process. Code repositories and websites in the cloud to show your work can help tremendously. Don’t be concerned with whether or not you “measure up” to others out there. At the start, you won’t but your journey is yours and that’s what matters.
Chapter One: First, Choose Your Goal
Front End, Back End, Full Stack, Mobile, and a reference to QA by way of automation. This particular part touches me because I am primarily a tester in my work role, but many web development skills are still part of my daily repertoire. I’m glad Julie include testing on the list because many developers do actually make a decision to look at testing as a primary responsibility. The point is, deciding where you want to place your efforts will make a big difference in what you study and in what order. Likewise, there’s no rule that says you have to be permanently committed to any one goal, right?
Chapter Two: Choosing Your First Programming Language
Languages have a lot to do with the applications or environments you want to work on. Java is now a perennial favorite of many organizations because it is ubiquitous. Large corporations use it, Android devices use it, and there’s a large ecosystem for the language. It’s a wordy language, true, but the benefit is that there’s a lot of examples out there to look at and review. JavaScript is a language that has spawned numerous libraries and smaller ecosystems of their own. When you see people asking about Angular, Bootstrap, jQuery, React, etc, those are all specialized JavaScript frameworks. PHP is a great language specific for a large number of existing sites. Python and Ruby are also popular languages that also run in web stacks (Django and Rails, respectively). What you use will depend a lot on what you ultimately want to work on. If your dream job is making iPhone apps, you may want to take a look at Swift. The key is start with where you want to go and then pick what you will work with.
Chapter Three: Paths to Learning
You may be thinking “I don’t have a Computer Science degree” and that’s totally fine. Many of the best developers I’ve know have degrees in completely different disciplines. Whether you choose to go to college, do a coding Bootcamp or use an online resource like freeCodeCamp, the point is you have to put in the time, get frustrated a little and work through the issues you will undoubtedly face.
Chapter Four: What Skills Do You Need?
The foundational skills necessary are surprisingly small. Yes, it helps a lot if you can touch type and do so at a decent speed. Knowing how to use a computer or mobile device well is important especially if you can understand how to open, edit, move and manipulate files and directories. Understanding fundamental math skills and having a good understanding of the scientific method is also very helpful (not mentioned in the chapter and were I to suggest any additional basic skills to include I’d strongly suggest that one ;) ). From there, you will need to learn about how to use the command line of your chosen operating system(s), understanding the basics of HTML and CSS, using a version control system to chart your progress and, on occasion, back up and go to an earlier time to do something different, and understanding of how the Internet works (TCP/IP and HTTP, for example). From there, databases, return codes, error handling, and flow control of programs will come into play. Sounds scary? In truth, it’s fairly straightforward but the devil is in the details. Again, the key here is to understand what you want to do and then plot the course to get there. It will require a fair amount of knowledge buildup and experimentation, as well as false starts and frustrations. Julie goes into some detail in this chapter about the various frameworks available, sample programs and applications you can develop and ways to display them so that people can notice your progress.
Chapter Five: Things to Ignore (at Least For Now)
Depending on what it is you wish to work on, there may be many skills that will be important later on, but that you do not need to worry yourself with at the start or even in the first few years of your progress. You may never have to get familiar with topics like binary, specifics of computer hardware, or the underlying computer networking infrastructure and communicating with the lower layers. There is a list where there are things that will be helpful to understand later on and while I agree with much of the list, I have to take issue with testing being considered not so important. Personal opinion time, I wish more developers would put testing and a testing mindset at the forefront of their learning. It will help encourage more developers to see what they are developing, to begin their work with questions of quality and experimentation in mind and to ultimately help deliver a better product to their users. Chapter Six: Learning Resources
This chapter includes a list of resources to help fill in key concepts and skills you may need. Many of them are completely free, while some have a small cost associated with them (small is relative, of course). Julie also includes a variety of blogs and websites that can also be helpful (I too am a fan of the Tuts sites and encourage people to check it out).
Chapter Seven: Staying On Track
The chapter starts out with this quote:
"Learning to code is more of a motivational challenge than a technical one." -- Quincy Larson, Founder of freeCodeCamp
On the whole, I agree with that. How we keep ourselves motivated is important, and finding our true motive is also critical. Do we want to make more money? A good place to start but may not sustain us in the long run. Chose methods that will help you stay committed to your goals, such as participating in meetups, hackathons, or other projects you can do with other people to get feedback and feel connected to what you are doing.
Chapter Eight: Career Goals
Just as important as what you want to do is where do you want to do it? Do you want to work for large companies or would you be interested in working for smaller organizations? Understanding the tradeoffs for each is important. Large companies can have great infrastructure but very defined ways of doing things. Smaller companies may be more chaotic and struggle with getting to profitability but the sky's the limit with where you can potentially get involved. You can also work with various employment agencies on a contract basis to rotate jobs and gain experience. Once you have a good enough foundation, you could perhaps hang up your own shingle, so to speak, and freelance. Don't be surprised if you find yourself doing a little of all of that, especially in the first few years.
Chapter Nine: The Job Hunt
Remember that advice in Chapter Zero? Here's where doing all of that this whole time should start helping. If you have been communicating with a variety of people along your journey, they may take an interest in what you have put together and speak with those in their organizations that have a hand in hiring. Resumes still matter at a lot of places, but they are taking a backseat to demonstrable ways that you can show your skills. In this day and age, tools like LinkedIn, GitHub, SlideShare, and a blogging platform can do a lot to boost your visibility as well as have lots of examples of demonstrable skills. Additionally, connect with people and communicate with them. The key here is to start this process well before you need to look for a job so that when you are ready, you have already identified people who you can communicate with. Another bonus is that, if you do this regularly, they will likewise know you are ready and can help you find your next gig.
Chapter Ten: Interviewing
Whether it be initial phone screens, in-person general interviews or technical interviews, you will be judged based on how you respond. Having a good handle on a variety of skills and being able to explain them will go a long way in helping you with these interviews. You may be given a coding challenge to complete, either on-premises or as a take-home assignment. Practice a few of these so that you can feel confident that you can do them if given the opportunity or request. This chapter has a lot of practical advice for specific technical interview questions as well as how to negotiate for salary.
Chapter Eleven: Building a Successful Career
Once you get that first job, realize that it's the bottom rung of a new ladder. There's still much to learn and many areas that you can get involved if you choose to. Pay attention to sticking points in the organization and see if you would like to tackle those challenges. See where the rest of the market is going and if you feel that you are ready to pivot if market forces change. Most importantly, never stop learning.
Along with all of these chapters, Julie shares many personal anecdotes of her own journey that has brought her to where she is today. These vignettes help the reader see what choices she made, both for good or ill, that have helped inform the rest of the text.
BOTTOM LINE:
For those who are looking for an in-depth guide to learning how to become a web developer, this book doesn't cover those except for skimming the resources needed to accomplish those goals. This is much more of a field guide to allow you to safely manage the trek and it is filled with a variety of markers that you may find interesting along your journey. As the title says, this is a Career Change guide, and those focusing on the "How To Become a Web Developer" are missing the key in the subtitle. This is a guide to navigating a career change. To that end, it meets its goal admirably.
As in previous years, I have decided to take part in "The State of Testing" Survey and I encourage anyone else who is actively involved in testing endeavors to do the same. Note: I did not say "testers" need to take it, though that's likely who it's directed to. As I have become more involved in software delivery as a process, software testing is a key part of what I do, but it's not the only thing I do.
As I see it, software testing is transitioning. There will certainly be areas where dedicated testing as a role, a responsibility, and a job title will remain for quite some time to come. However, I also see that testing as a dedicated discipline in many organizations, if not disappearing, is definitely getting to be hazier. In previous decades, I might have been worried about that and truth be told, I was. Today, I take heart in the fact that there is much we all can do to be successful and do meaningful work. as I often remind myself, my mentor Ken Pier was fond of saying "there is always work moving from theory to practice".
The following I am borrowing directly from the Practitest QA Intelligence Blog, so I am presenting it in its entirety below (Thanks, Joel and Lalit :) ):
What is the State of Testing?
The State of Testing™ seeks to identify the existing characteristics, practices, and challenges facing the testing community in hopes to shed light and provoke a fruitful discussion towards improvement.
The final report is translated into several languages and shared globally, further expanding the reach and impact this report has on all of us in the QA world.
This is the 5th year that the QA Intelligence Blog is running this survey in collaboration with TeaTime with Testers, and with your help, it can be bigger and more comprehensive than in previous years.
Each year the amount of participants has increased, and the final reports become even more valuable as a culminated reflection of testing trends, challenges, and characteristics.
So there you have it, another chance to take part in the State of Testing Survey is upon us. Are you interested in playing along? If so, click below and let's get to it :). ANSWER SURVEY NOW
I'd like to present the newly retooled The Testing Show. New theme music (courtesy of my band Ensign Red) and what I hope will be a new streamlined format for the show. I've learned a thing or two about doing audio the past few years and I'm hoping to see us transition a little bit to a broader storytelling approach along with the regular interviews that we do.
I joke during the intro in this show that I feel like a bit of a fanboy here, but seriously, I have wanted to interview Saron for a long time. I was a little nervous asking if she'd be on our show with her level of visibility, so I was overjoyed when she said "yes" and even more so at the natural conversation that we had. She's not just a great interviewee, she's an excellent interviewer as well, so there was a really fun give and take on this show. To that end, I likewise decided that my traditional heavy grammatical editing style wasn't suited for this conversation. Some of the audio may sound a little less slick by TESTHEAD standards, but I feel it adds to the immediacy and excitement of the conversation. I'm not kidding when I say I was a bit giddy at a few spots in this episode.
All right, fanboy gushing aside, this episode covers what I think is interesting ground. Saron is perhaps one of the few guests who has never identified as a software tester, but she totally gets testing. What's more, she totally gets the frustration of getting up the courage to commit to learning how to write code (and yes, it takes courage to do it). It takes courage to be continuously frustrated. She also shares a lot of her ups and downs and frustrations that she has had during her own journey, and how she uses that as fuel to help support others on their coding journeys.
We recorded for almost two hours, and it has been a struggle to decide what to keep the focus on for these interviews. I'm hoping I've captured the best of the conversation, but I'll leave that to you all to decide.
If you enjoy listening to The Testing Show, I'd like to ask you a favor. Please go to Apple Podcasts and give us a rating. If you feel we deserve five stars, please give it to us :). If you feel we deserve less, that's fine too, but please leave a review and tell us why you feel that way. Give us a review as to why you think we deserve five stars while you are at it :). We aim to make The Testing Show the best podcast we can and if you have thoughts about how we can make it better, as the producer, I'm definitely interested.
It's that time again, the end of another year. With it a chance to reflect on some of what I've learned, where I've been, what I could do better and what I hope to do going forward.
This year has been a good one for the Testing Show podcast. In the software testing world, outside of the work I do each day, I would say that this has been my most consistent endeavor. I've been pleased with the episodes we have done this year and I am excited about more episodes that will branch away from the typical topics that we normally cover and aim to strike out into other areas that are important to software testing but may not be solely focused on the testing aspects alone. Also, as it will go live in the middle of this week, I can say there will be one noticeable change. New theme music will be part of the 2018 series of shows.
In my workaday world, I had an odd situation that required an adjustment and a change in work habits for me. I started the year with just a handful of people coming to our office to work each day and quickly that changed into my being the only person coming into the office most days. I felt a bit like the lone lighthouse keeper much of the time, though of course, the team communicated regularly through digital means. This year, as I was the one person coming into the office, our parent company decided it didn't make much sense to pay for a large office space that only one person was using. The office was closed and I was transitioned to being a 100% remote worker. This is a first for me. I've had the option to work from home much of my career, but it was a couple of days a week. I've never worked in an arrangement where I was 100% at home, all the time. That's been my reality since October of this year. I'm adjusting, but I do have to say it still feels a bit strange.
On the family front, my son moved away from home to embrace his dream of being part of the music industry in Los Angeles. I'm proud of him for chasing after his dream, but part of me is way too familiar with the entertainment industry and its many promises made but so few kept. He sends me texts that remind me of myself at his age when I was sure I was going to conquer the world. I have to fight the desire to tell him I know that tone so well, but in truth, I don't know his reality. I remember mine. Therefore, I do my best to hold my tongue and just let him tell me what he is doing and keep the peanut gallery comments to a minimum. It's hard, to say the least. On the bright side, he's more interested in the production and marketing end of entertainment, not being the actual performer, so he has better odds than I had ;).
On the physical front this year, as I tested out a variety of fitness approaches, trying to maintain a target weight and chasing metrics to define quantitatively how physically fit I was, I came to some stark conclusions. Numbers are artificial, they can be gamed, they can be detrimental to long-term success, and most importantly, it's entirely possible to "be fit" and feel completely miserable. That was a conclusion I reached this summer. Yes, I was 194 pounds, but I was also anemic and unable to donate blood, I felt tired much of the time, I got sick more frequently. I allowed myself to put a buffer between that lower point and I voluntarily gained back 20 pounds. Since around November, I have hovered between 215 and 225 pounds. It doesn't sound as dramatic, but it sure feels a lot better. In 2018, my goal is to focus more on body composition and worry a lot less about my actual weight.
Some longer-term initiatives I had to decide that I didn't have the energy or ability to do as often. Weekend Testing Americas is still a thing, but I found myself repeating where I'd been before and decided it was better to step away for a bit. I haven't shut it down, but I determined I needed to let some new blood take a shot or let it lay dormant for a bit. I'm feeling like I have some fresher ideas now, so do not be surprised if you see more Weekend Testing Americas sessions in the new year.
On the speaking front, I have kept my pledge to focus on Accessibility and Inclusive Design as my topics of choice, and those will also carry over into the new year as well. As I get older and I discover that my resiliency and "springiness" isn't what it used to be, many Accessibility and Inclusive Design aspects that were at one-time talking points have become "living points" for me. As such, the lack of sites that follow guidelines and the limited testing being done to help sights be more inclusive matters more to me now than ever. Additionally, I've decided that I want to do some more writing on the topic in 2018, with concrete and specific actions people can take.
As my company is making moves to modernize many of their testing frameworks, I'm taking advantage of the changing landscape to try to learn more about setting up a new framework from the ground up. At the moment, I'm championing an approach that uses Angular, Protractor, and Jasmine over our older successful but decidedly proprietary setup. Our testing team has decided to try a number of experiments and see where they lead us, rather than going all in on a particular strategy. To that end, I aim to learn a bunch of things with this approach and I also aim to talk about it as much as I can. This blog has been lean on my "learning in public" experiments as of late. It's time I got back to that.
My thanks to everyone who has worked with me, interacted with me, been part of The Testing Show podcast as a regular contributor and as a guest, shared a meal with me at a conference, come out to hear me speak, participate in a Weekend Testing session, shown support to the Bay Area Software Testers meetup, and otherwise given me a place to bounce ideas, think things through, and be a shoulder to cry on or to just hear me out when I feel like I'm talking crazy. Regardless if you have done that just a little bit or a whole lot, I thank you all.
Here's wishing everyone a happy, healthy and sane 2018. I look forward to talking with you all in the new year and beyond. Also, thank you, Talking Heads, for the song "Once In A Lifetime" as it has provided me so many clever titles for my year-end posts these past seven years (well, I think they are clever; your mileage may vary ;) ).
My elder daughter and I have been working on a number of small projects together over the past few months and every once in awhile, I will get a comment from her where she says "wow, how did you know what to do in that situation? We hadn't faced it before, and you quickly figured out a way to deal with it. How is it so easy for you? Why can't I do that?"
I chuckled a little and then I've told her a maxim that I've used a bunch (and I'm sure I've said it here at some point, too)... "Good ideas/solutions come from good judgment. Good judgment comes from experience. Experience comes from bad ideas/solutions/judgment." In short, she sees that I can come in and consider an idea and implement it (in some things, I do have my limits, and they are legion). What she doesn't hasn't seen is the countless times I've tried similar things, failed at them, regrouped, reconsidered, remeasured, tried again, and repeated this process until I happened upon something that worked.
As a Scout leader, I've had the benefit of decades of teaching a few generations of kids how to do some basic stuff (note, I said basic, not easy or simple). We teach how to tie a handful of knots. We teach some basic cooking techniques. We teach how to handle items like an ax, a knife, and a saw. We teach how to safely use fire. We teach some basic wilderness survival tips. Each time through this process there is always a similar "wave" that I witness. At first, there's an excitement level, but that quickly gives way to a mild boredom. Seriously? This is such a big deal? Snooze! Still, I push on and demonstrate what I can and encourage them to practice what I am showing them. A hallmark of our Scouting year typically takes place three months in for a typical scout. That's the "silent campout". Not silent in the sense that there's no talking or interaction, but silent in that the leaders (i.e. me and the other adults) make it a point to not discuss any of the campout particulars with the troop. They have their campsite, we have ours. they are within eyesight of each other, and we reserve the right/authority to intervene if a situation is deemed unsafe. Outside of that, we let them pick the camp area, bring in all needed items, and then we leave them to it. They construct the camp, they cook their meals, they clean, they tend fires, and do all of the other things that we have taught them over a few months.
Each time, the outcome has been similar. The bored expressions often give way to genuine concern or in some cases panic. Wait, what was I supposed to do at this point? Did I pack what we needed? Did I cook that long enough? Am I going to be able to properly contain the fire? You get the idea. They make mistakes, they get frustrated, and then they approach the problem(s) from different angles. They confer. They discuss options. They experiment. Some of those experiments fail, but some succeed. They note the ones that were successful. The next morning, fewer mistakes, less frustration, and almost no panic. The process, while ragged, gets smoother and more refined. Almost to a person, this experience makes for a change of attitude, and then when we talk about "the basics", they are not so jaded and bored. they realize that basic stuff often is harder to physically do in a regular and smooth manner. Like everything, it takes actual practice and it takes some working through frustration. Do it enough, and you start to actually get good at those basics and then you forget that there was a learning curve at all.
My point with this today is that, too often, I think we approach aspects of what we do (testing, coding, administration, learning new stuff, getting out of our comfort zone) with the same mindset. We start out enthusiastic, we get bored and jaded and then we panic when what was supposed to be so simple doesn't work out to be. It's OK to feel these things. In fact, it's necessary. Over time, as we stumble, learn, practice and perfect, we too might forget exactly what it takes to do basic things and make them look easy. May I encourage you not to? You never know who may be watching and feeling discouraged because they can't seem to "get it". We've been there, we know how that feels. Let's make sure we remind others that basic doesn't necessarily mean easy, and that good ideas/solutions often come from bad ideas/attempts.
Wow, we're at the end of the day already? How did that happen? Part of it was the fact that I started a few conversations with people that cut into talks being delivered, but as is often the case, those discussions can take priority and can often be the most important conversations you have at a conference.
Long story short though is that we are at the closing Keynote for the main two-day conference. Rich Sheridan of Menlo Innovations believes that we can do work that we care about and that we can have joy in the work that we do and in the workplaces we actively move in. Rich shared his story of how he came up into the world of computers and computing starting in the early seventies and how the profession he loved was starting to sap the life out of him and how he was contemplating leaving the industry entirely. He was experiencing the chaos of the industry. Issues, bugs, failed projects, blown deadlines, lack of sales, and all of the fun stuff any of us who have worked in tech recognize all too well. Chaos often ends up leading to bureaucracy, where we can't get anything done to not being able to get anything started.
The fact Rich wants to impart is that Joy is what all of us hope for in most of the things that we do. We often see it as some form but it's often nebulous to us. Additionally, jobs and companies cannot guarantee our success or our happiness. We have to have an active role in it and be willing to make it happen for us as we endeavor to make it work for others.
Why joy? Joy is service to others and being able to see the reaction to that service. IT's why we do the work that we do. We want to see our work out in the world. We want to see it get a response. We want to see people react to it. and we want to have that moment that swells up inside of us and that cheers us and makes us jump for (wait for it!) joy.
It's one thing to say that you want to build a joyful career, but it requires human energy. In most of the work environments that I have enjoyed the most, the work has almost always been secondary. What made the work enjoyable? The people and the interactions with those people are what makes for memorable experiences.
One of the most important things to foster joy is the idea of trust. We have to trust one another. Trust allows us to be open and frank. We can get into hard discussions and deal with conflict in a positive manner. When we can debate issues with trust and consideration, while still being committed to trying to get our issues resolved, we can deal with the hard issue and still be positive and remain friends.
Rich describes his office as a hodgepodge of machines, but the most astounding aspect is the fact that no one has their own computer. People change pairs and move onto other machines every five days, and with those moves, people move onto other machines. That means there is no such thing as "it works on my machine" because there is no dedicated machine for anybody.
Simplicity goes a long way to helping develop joy. Complexity for its own sake sucks the life out of us, and Rich showed the way that they manage their work. It's all on paper. It's all based on the size of commitment, and it's all based on creating meaningful conversations. Pans are then put on the wall, for all to see so that it's completely transparent. Honesty matters and with transparency comes honesty. With honesty and a willingness to express it, empathy comes into play. With empathy, we can see what others see and feel what others feel. To borrow from Deming, as Rich did "All anyone wants is to be able to work with pride" With that pride comes joy.
Rich Sheridan is the author of "Joy, Inc." and it is scheduled to be released very soon. Yep, I want a copy :).
And with that, the two-day technical program for PNSQC is over. Tomorrow will be another work day for me, but I think it's safe to say that I'll be literally buzzing with the kinetic energy that these past two days have provided for me. Thank you PNSQC team for putting on a great event. Thank you, speakers, for sharing your insights and experiences. Thank you, participants, for coming out and participating, and especially, thank you to everyone who came to my talk and offered positive feedback (and constructive criticism, too). Wishing everyone to get back to their destinations safely, and if you are here for the extended workshop day, I hope you all enjoy it and get to bring back great insights to your teams.
Good morning everyone! I actually had a full night's sleep and no need to rush around this morning, so that was fantastic. I should also mention that I was really happy with the choice to go to Dar Salam restaurant last night as part of the Dine Around Town event. Great conversation and genuinely amazing food.
This morning, the theme for 2018 was announced. It will be "On The Road to Quality" and I am already thinking about what I'd like to pitch for a paper and talk next year. No guarantee it will be accepted, but I'm looking forward to the process anyway.
The first talk this morning is "Who Owns Quality in Agile?" by Katy Sherman and she started out with a number of questions for us. Actually, she started the morning with a dance session/audience participation event. No, I'm not kidding :).
Katy shared the example of her own company and the fact that her organization had two pulling interests. In some cases, testers felt they didn't have enough time to test. On the other hand, developers felt like they had too much time with nothing to do. One of the challenges is that there is still a holdover from older times as to what quality means. Is it conformance to requirements? Or is it something else? How about thinking of quality as meeting both the explicit and implied needs of the customers? We want conformance, we want user satisfaction and we want our applications to perform well, even if they don't know what performing well even means. Ultimately, what this means is that Quality cannot be achieved through testing (or at least not testing alone.
In some ways, there's still an us vs them attitude when it comes to being a developer or being a tester in an Agile team. For my view, silos are unhealthy and perpetuate problems. There's an attitude that testing in extra, that having a dedicated tester is a frustrating overhead and wouldn't it be great if we could do away with it? Some developers don't want to test. Some testers struggle with the idea of becoming programmers. Many of us are in between. As a tester that has reported to test managers and to development managers, there's a need to be direct and show what you can bring to the table and to express issues and concerns in a similar way (perhaps not exactly the same but feel confident that both can be taught to understand the issues). In my own work, I have determined that "being a tester" alone isn't a realistic option at my company. There is too much work and there are too few people to do it, so everyone needs to develop their skills and branch into avenues that may not necessarily be their specific job title. Consider the idea that we are all software engineers. Yes, I realize that engineer is a term that has baggage, but it works for the current discussion.
There is a lot of possible cross training and learning that can happen. Developers being taught how to test is as important as testers being taught how to code. Perhaps it is even more important. Testers can learn a lot about the infrastructure. Testers can learn how to deploy environments, how to perform builds, how to set up a repository for code checkout, and yes, the old perennial favorite, work with automating repetitive tasks. Please do not believe that more automation will eliminate active human testing. Yes, it is true that it may well end a lot of low-level testing and that it will eliminate a number of jobs focused on that very low level, but testers who are curious and engaged in learning and understanding the product are probably the least likely to be turned out. I'm mimicking Alan Page and Brent Jenson of A/B Testing at this point, but if testers are concerned about their future at their current company, perhaps a better question to ask would be "what value am I able to bring to my company and in what areas am I capable of bringing it?
One of the key areas that we can make improvements is in the data sets and the data that we use to both set up tests as well as to gather to analyze the output. Data drives everything, so being able to rive the testing by data and analyze the resulting data produced (yes, this is getting meta, sorry about that ;) ). By getting an understanding of the underlying data and learning how to manipulate it (whether directly or through programmatic means) we can help shape the approaches to test as well as the predictions of application behavior.
Is QA at a crossroads? Perhaps yes. There is a very real chance that the job structure of QA will change in the coming years Let's be clear, testing itself isn't going anywhere. It will still happen. For things that really matter, there will still be testing and probably lots of it. Who will be doing it is another story. It is possible that programmers will do a majority of the testing at some point. It's possible that automation will become so sophisticated and all-encompassing that machines will do all of the testing efforts. I'm highly skeptical of that latter projections, but I'm much less skeptical of the former. IT's very likely that there will be a real merging of Development and QA. In short, everyone is a developer. Everyone is a tester. Everyone is a Quality Engineer. Even in that worldview, we will not all be the same and do exactly the same things. Some people will do more coding, some people will do more testing, some people will do more operations. The key point will be less of a focus on the job title and a rigorously defined role. Work will be fluid and the needs of the point in time will determine what we are doing on any given day. Personally, that's a job I'd be excited to do.
This is a 90-minute talk, so I'll be adding to it and updating it as I go. More to come...
Wow, a full and active day! We have made it to our last formal track talk for today, and what's cool is that I think this is the first time I've been in a talk with Lee Copeland that hasn't been physically running a conference.
Lee discussed the ideas behind Lean Startup, which was a book written back in 2011 by Eric Ries. In Lean Startups, classical management strategies often don't work.
The principles of Lean Startup are:
Customer Development: In short, cultivating a market for their products so that they can continue to see sales and revenue, and to help develop that relationship
Build-Measure-Learn Loop: Start with ideas about a product, build something, put in front of customers to measure their interest, then learn about what they Like or Don't Like and improve on the ratio of Like to Don't Like. Part of this is also the concept of "pivoting", as in "should we do something else"?
Minimum Viable Product: Zappos didn't start with a giant warehouse, they reached out to people and sought out what they might want to order, and then physically went to get the shoes that people ordered and sent them to them. Validated Learning: "It isn't what we don't know that gives us trouble, it's what we know that ain't so" - Will Rogers
"If I had asked people what they wanted, they would have said faster horses." - Henry Ford (allegedly) One Metric That Matters: This measure may change over time, but it's critical to know whatever this metric is because if we don't know it, we're not going to succeed.
So what Quality lessons can we learn here?
Our Customer Development is based on who consumes our services. Managers, Developers, Users, Stakeholders. Who is NOT A customer? The testing process. We do this wrong a lot of the time. We focus on the process, but the process is not the customer and it doesn't serve the customer(s). With this in mind, we need to as "what do they need? what do they want? what d they value, what contributes to their success? what are they willing to pay for?"
The Build-Measure-Learn Loop basically matches up with Exploratory Testing.
Minimum Viable Product: We tend to try to build testing from the bottom up, but maybe that's the wrong approach. Maybe we can write minimum viable tests, too. Cover what we have to as much as we have to, and add to it as we go.
Validated learning equals hypotheses and experiments to confirm/refute hypotheses. In short, let's get scientific!
How about the One Metric That Matters? What it definitely does not include are vanity metrics. What does the number of planned test cases mean? How about test cases written? Test cases executed? Test cases passed? Can we actually say what any of those things mean? Really? How about a metric that measures the success of your core business? How do they relate to the quality of the software? Is there an actual Case and effect relationship? Does the metrics listed lead to or inform next actions? Notice I haven't actually identified a metric that meets those criteria, and that's because it changes. There are a lot of good metrics but they are only good in their proper context, and that means that we have to consistently look at what we are and what that metric that matters and what really matters when.
This talk is called "7 Habits of Highly Effective Agile" which is a play on words of the Steven Covey book, hence my silly title. Yes, I'm getting a tad bit punchy right now, but I am lucky in that I get to have an energy boost. Nope, no food or drink or anything like that. I get to have Zeger Van Hese next to me doing his sketch notes.
I've waited years to actually see him do this. How am I going to concentrate on doing a live blog with that level of competition (LOL!)?
Seriously though, "Seven Habits" is a book from the 80s that is based on the idea of moving from dependence to interdependence with a midpoint of independence. For those wondering about the original Covey Seven Habits, they are:
Be Proactive
Begin With the End in Mind
Put First Things First
Seek to Understand, Then be Understood
Think Win/Win
Synergize
Sharpen the Saw
The Agile Seven Habits break down to:
Focus on Efficiency and Effectiveness (make sure that your processes actually help you achieve these, such as cutting down, technical debt, providing necessary documentation, etc.)
Treat the User As Royalty (understand your customer's needs, and what you are providing for them)
Maintain an Improvement Frame of Mind (adapt, develop, experiment, learn, be open, repeat)
Be Agile, Then Do Agile (we have to have internalized and actively live the purpose before we can do the things to get the results. Communicate, collaborate, learn, initiate, respond)
Promote a Shared Understanding (develop a real team culture, break away from roles, stop thinking it's not my job, learn from each other, wear different hats and take on different tasks, pairing as a natural extension, determine what is important)
Think Long Term (develop a sustainable process, pacing that's doable and manageable, making habits that stick and persisting with them)
Well, there's my thoughts. and here's Zeger's. His are much cooler looking ;):
The Ministry of Testing has declared that May should be "30 Days of Accessibility Testing". As in the days of yore when I used to take on these challenges and blog regularly, I'm in the mood to get back to doing that. Therefore, I am looking to write a post every day around this topic and as a way to address each line of their checklist.
24. Learn about accessibility law in your country.
I live in the U.S.A., and therefore, while WCAG 2.0 is the guidelines I aim for, we usually refer to "Section 508" or features being "508 Compliant" because that is a section of the Rehabilitation Act of 1973. Actually, there are two areas in the Rehabilitation Act that relate to disabilities. The first is Section 504, which declares that the act "prohibits federal agencies, programs, or activities from discriminating and requires reasonable accommodation for qualified individuals with disabilities." Section 508 declares that "agencies must give disabled employees and members of the public access to information that is comparable to access available to others." A basic checklist of Section 508 compliance can be seen by clicking on the link.
Notice anything interesting there? Did you see anything mandating that Accessibility is the law everywhere? Nope. Just in the services and the fund allocated for them by the federal government. Is there a strict standard? Again, nope, but Section 508 by virtue of being a policy of the federal government, and with the sheer volume of software seats that the federal government provides, can carry a lot of weight in regard to the design decisions of companies.
I know for a fact that a large agency of the federal government looking to purchase a lot of software from my company was what initiated a thorough review of Accessibility requirements and areas that needed to be updated in our product so that they would buy it. The dollar amount of that deal most certainly played a part in why we undertook a large-scale retrofit of our product to meet Accessibility standards, and again, the standard we measured for that purpose were the guidelines as described to meet U.S. requirements. To meet the broader WCAG 2.0 requirements means we still have a distance to travel still.
The Ministry of Testing has declared that May should be "30 Days of Accessibility Testing". As in the days of yore when I used to take on these challenges and blog regularly, I'm in the mood to get back to doing that. Therefore, I am looking to write a post every day around this topic and as a way to address each line of their checklist.
19. Find 5 accessibility experts to follow on Twitter.
1. Albert Gareev (@AGareev): Albert and I have been friends/compatriots/writing partners/co-presenters for seven years when I made the commitment to get more involved in the testing community in the first place. It turned out that Albert was also actively involved in Accessibility, and thus, when I started working on it as part of my work, Albert became a lifeline of ideas and encouragement. We've worked on several things together, and the "HUMBLE" mnemonic is rightly his, though both of us present it.
2. Alicia Jarvis (@AJarvis728): Alicia has likewise been active in the Canadian Accessibility community along with Albert, and has been a source of advocacy, passion and focus that I've reached out to many times. My first association with Inclusive Design and thinking about it was because of her tweets and advocacy.
3. Ellen Parfitt (@deafieblogger): Ellen is a new one for me, in that I came across her work during this challenge. Her site HearingLikeMe.com has a lot of great insights dealing with hearing loss and working with technology to enhance the experience for those with hearing loss (both primary and incidental).
4. Neil Milliken (@NeilMilliken): Lots of stuff I could point to for Neil, but the AXS Chat Community is a good enough place to start :).
5. Alice Boxhall (@sundress): Another recent discovery during this 30 days challenge. I've enjoyed learning about her and the initiatives she takes part in.
There are of course much more, but if I were to name all of them, we'd be here all day. Start with these five, read what they have written and commented about, and who they interact with. My guess is you'll discover a lot of people worthy of your time and attention.
The Ministry of Testing has declared that May should be "30 Days of Accessibility Testing". As in the days of yore when I used to take on these challenges and blog regularly, I'm in the mood to get back to doing that. Therefore, I am looking to write a post every day around this topic and as a way to address each line of their checklist.
I was away for the weekend and with limited Internet, so I have a couple of entries to do to get back up to date. Therefore there will be some doubled up entries. With that, here's #6:
6. Learn about assistive technologies, and share one you liked (hardware). Whenever I hear about Assistive Technologies, I can't help but think of someone that was a contemporary of mine in the Bay Area music scene who, due to developing Amyotrophic Lateral Sclerosis (ALS), had his musical career and ascent cut short, but never stopped. That person is Jason Becker, an amazing guitarist that first came to my attention as part of a group called Cacophony. He grew up in the San Francisco East Bay area same as me, and we played in many of the same places. I saw him play several times in the mid to late 80s. I had the chance to talk with him just one time, briefly, after Cacophony played The Stone in San Francisco back in 1988. I was 20. He was 18. Shortly thereafter, he became David Lee Roth's guitar player and helped write his "A Little Ain't Enough" album with him.
Jason's Dad, Gary Becker, develop a system of communication called Vocal Eyes. Gary describes the process in this YouTube video:
Basically, it's a board with a movement tracker that allows Jason to quickly spell out and create words to communicate with others. The eye tracking method lets him quickly put words together and, while not seamlessly communicate, it's actually quite fast and he's definitely proficient with it.
In many ways, Jason was the person that first inspired me to want to learn more about Accessibility, and Gary inspires me to always look for ways to keep moving forward when it may seem impossible to do so.
Jason still inspires me today, and thus, it gives me great pleasure to pay tribute to him as part of this Accessibility testing challenge.
If you'd like to know more about Jason and the absolute unwillingness he has shown to give in or give up and to do all he can to keep making music and communicating, I highly recommend seeing the documentary "Not Dead Yet". The trailer can be seen below:
Well, it's the end of another eventful year. Much has happened. I've been involved in many interesting endeavors, and I've learned a lot about myself this year. This was a topsy-turvy year for many, both in the pop culture and political sense. It seems for many we are making decisions to look for ideas and think about things in ways that agree with our views of the world. That's both rational and long term bad for us. I won't be talking about politics with this post, other than to say that I believe local action and local involvement has to be where we all start because that's where we individually have the most control and effect.
The title this year of this post is "Water Flowing Underground", and yes, this is yet again a lyrical nod to the Talking Heads song "Once in a Lifetime". Why did I choose this line for 2016? It felt like this was a year of digging. If I wanted to get to the water that would sustain me, I would have to work for it, and in many cases, work harder than I have before.
First, let's start with a little bit of "Aedificamus". This was a year I focused on being more quantified in my actions. I measured my food. I measured my exercise. I wore a fitness tracker each day. I set a goal and I came darn close to achieving it, and then part of me stopped paying attention. No, that's not really true. The truth is I grew weary of the level of activity and focus needed to hit the aggressive goal I had set for myself. What's more, I discovered that I was capable of being injured in ways that took far longer to be healed than I imagined possible. I developed golfer's elbow (which is odd because I don't play golf). Seriously, though, what that means is that I developed a repetitive stress injury on the inside of my elbow, at the joint where my humerus and ulna meet. It's made lifting weights and doing a number of exercises challenging. I have to be careful as to how I lift things and how I use my elbow. In addition, in the latter part of the year, I developed plantar fasciitis in my left foot. What that has meant is that my previous gung-ho approach to walking 10,000 plus steps each day is now determined by how my foot feels in any given day. The net result is that I gave up some of my progress on my weight loss. I'm still considerably less than I was at the start of this journey, but compared to this time last year, I'm actually up about ten pounds. Still, I am wearing the clothes I bought for the smaller framed me, and they still fit comfortably, but I have a reminder that I need to mend and I need to keep healthy, plus I need to figure out some adaptations to my training and eating so I can get back to making progress, even when my body doesn't want to cooperate.
Next, I made a conscious decision to scale back on several areas so that I could focus on a few key areas I've really wanted to develop. That meant taking a step back from freelance writing and yes, even contributing to this blog, so that I could help bring forth a new venture. That new venture that started this year is "The Testing Show", a podcast that I produce, edit, transcribe and publish each week through QualiTest and on iTunes. I knew going into this that I had a goal for the production quality and listening experience for this podcast. To that end, I think it's safe to say that I've spent more cumulative time on this show than any other initiative I've been involved with this year. As well as being a regular panelist on the show (along with Perze Ababa, Jess Ingrassellino, Matt Heusser and Justin Rohrman), I also edit every show and produce a transcript and show notes for each episode. In short, if you like the flow of the show, the accuracy of the transcript and the relevancy of the show notes, I get to take the credit for that. If you don't like them or find any of the above in need of improvement, I am also the one to talk to about that. Without going into details, I probably spend anywhere from six to eight hours producing each episode. That's because I want the listening experience to be clean, and I want the transcript to be as accurate as possible. Do I have to edit the shows so that every "um", "ah", "like", "you know", and circular verbal tic is removed? Probably not, but I value podcasts that go that distance. Shows like Freakonomics, Planet Money, and Hardcore History are my gold standards. I aspire to have our shows be that clean and that focused. Sometimes I succeed, sometimes I miss the mark. Each time I learn something new and get just a little bit better.
On an additional physical level, I took on what was possibly the biggest trek of my life, as well as the biggest challenge to the way I live and work every day by going off the grid and hiking into the New Mexico wilderness in July of this year. As Scoutmaster of a Boy Scout Troop, we put together an expedition to spend sixteen days in the Southwest, twelve of them at Philmont Scout Ranch and the surrounding Carson National Forest. We hiked for ten days, covered about eighty miles on foot, climbed over a few mountain ridges, dealt with extremes of temperature, and learned how to orienteer for real in spaces where there were no trails. Most of all, I had to make the decision to turn leadership over to a group of 14-16-year-olds and put my trust and faith in them that they would make the right decisions for the ten days we were on the trek. I am very much of the mind that I often do things myself if I don't trust that they will be done the "right way". Well, the Philmont Way doesn't care what the adult leaders think outside of an advisory capacity. What the boys decide determines the outcome, and we agreed to that. Most of the time, it turned out OK. Occasionally, I had to be sneaky and offer suggestions or show where we needed to go, but I was admonished by my co-leader that I needed to keep such interventions to a minimum. We all made it through intact, some scrapes, some bruises, a little altitude sickness here and there, but overall, much better for the experience. What's more, I learned that I had it in me to hand over control to others, and I learned to accept that my way need not be the only way. It about drove me crazy at times, but I was happy for the experience nonetheless :).
On the conference side this year, I decided to focus on my own area this year. Philmont was going to take a lot of time this year, so I decided that I would not travel for conferences this year. I was happy that STPCon came to Millbrae, CA, and I was also happy that the organizers told me, in no uncertain terms, that I had BETTER submit some talk proposals, as they were literally less than five miles from my home. To that end, I presented talks on the Intersection of Accessibility and Inclusive Design and shared a workshop on How to Teach New Testers. Those topics were also worked on and developed more in the Bay Area Software Testers meetup, along with our quarterly Lean Beer discussions, which opened up new areas for me to dig this year.
On my everyday work side, we've been making changes to our core team. Some of our most seasoned veterans have moved on to other endeavors. I've celebrated four years at Socialtext, and I am now the fifth most senior person in our company. That seniority is measured in weeks and months in a few of those cases. This means my leaning on more knowledgeable people gave way to my having to dig even more and learn even more than I ever thought possible. I now feel like the one that people come to for answers, both in the testing sphere and, more frequently, in the programming sphere. While I can safely say I have a lot more to learn in that latter area, I do feel that I am working in an environment that will let me dig as deep as I want to with as much energy as I can muster, and I will be encouraged and helped along the way. That's one benefit of working for what is, in effect, a very small company, even though that company is an acquisition of a much larger one. We are left to run as a scrappy little team, and that scrappy little team encourages everyone to dig if they want to.
So what does 2017 look like? I'm hoping to get back out and participate in conferences again, whether it be as a participant or as a speaker. I'd like to attend some development conferences or some broader industry events, and see if I can help develop a broader message of testing and quality. I'm aiming to expand Weekend Testing Americas to do more events at different times other than just on Saturdays (that's what people have said they want to see, so we will certainly give it a try). All in all, I am optimistic, and if there are areas that I am less optimistic about, I am going to remind myself that if it is within my sphere of influence and control, I best do all I can to influence events and outcomes as much as I can so that I can be optimistic going forward. One thing is for sure, water's flowing underground. If I want to get to it, it's up to me to dig for it. Same as it ever was ;).
