An interesting milestone just happened today, and I wasn't really even aware of it. I came in to work this morning and received a nice message from a co-worker in another division wishing me a Happy 2nd Anniversary with Socialtext.
Wow, two years?!
It seems like so much time in some ways, and it seems like so little as well. I remember first getting here, being nicely thrown off the deep end into our setup and getting my development environment running, and acclimating to life in a testing team after so many years of going it alone. Within those two years, we have seen changes, we've seen ups and downs, we grown and contracted, we've realigned and integrated, and I've had my chance to learn a few new tricks.
Looking back, I realized that I hadn't updated my Meandering posts for the last couple of years. This is meant to be a chronicle of my career path and the many places it has taken me. It also seems appropriate to mention a few other things that are taking place in my reality that might explain the limited postings lately here on my blog. For those curious about both, please read on.
As we last spoke, I was working with a young and energetic Agile team in the guise of Sidereel.com. The work I was doing introduced me to performing automation in a way that was unique to a front facing role, while still allowing me to delve into writing automation for myself and my efforts. The code was treated like development code, checked into Git, distributed with each release, and expected to run and pass before we went forward with deployments. It was an enjoyable experience and gave me a chance to dive into Ruby and Rails more than I had previously. I dedicated much of my free time to absorbing Zed Shaw's book "Learn Ruby the Hard Way" and putting those skills into practice. Any book on Cucumber, BDD, ATDD, Ruby or automation I could get my hands on was fair game, and I devoured as many of them as came my way.
Part of me was hoping that this would light a spark in me to become more enthusiastic about writing code and taking on more coding responsibilities. Well the latter definitely proved to be true, and I will say that I found myself learning quite a few neat tricks around object-oriented programming. I also picked up some understanding of modern web design and full stack development. However, that boost in joy and confidence and a surging love for programming, that didn't quite happen. In some ways, I still look at writing code the same way I do about cleaning out the garage. It's a necessary task at times, but not something I want to do every day. Actually, to be honest, I like cleaning the garage a little more than that.
One indelible change in my life happened while I was at Sidereel, and it's one I will feel the after effects for the rest of my life. On August 29, 2011, while I was riding my skateboard from work to the train station, I hit a crack in the road, and I was sent flying. The landing was bad. I broke through my right tibia near my ankle, and snapped my right fibula up near the knee. The resulting surgery, and plate put in my leg to allow the tibia to knit back together, took me of my feet for a month, and made it necessary for me to work from home full time for six weeks, until I could get back to walking far enough to make the trek from the train station to the office. The resulting experience showed me that I could be effective both in person and even when I was on my own at home for an extended period. At the same time, it made me start to wonder how much of the team I actually was, if I could do so much of my work outside of the core scrum team.
As many testers have probably seen, integrating with an Agile team is often an unusual dance. I would have to say that Sidereel did a good job of balancing the programming requirements and fulfilling the goals and objectives that makes for an Agile team, but more times than not, I felt like my being an embedded tester was a secondary thing. The Programming team was Agile, but I was a Waterfall tester. to be fair, I do not think that was at all the intention, but that's just how it worked out. Often I found myself struggling to understand what issues really mattered, what areas belonged to who, and how I could communicate effectively. If I asked too many questions, I was a disruption. If I asked too few questions, I was aloof. More to the point, I found that I didn't have anyone else I could really talk to if I had questions about my methodology and approach, and how I could work more effectively with the team. Over time, this became a wedge. I didn't want to see it then, but I can now appreciate the fact that my desire to insert myself inside of the team early in the process was what I wanted to do, but it wasn't what they wanted. My view of an Agile tester and the teams view were different, and I didn't appreciate that fact until later.
As a lone tester on such a massive product with so many moving parts and interactions, I had my share of misses and "whoops" moments. There were times when things that seemed like obvious "why didn't you catch this" situations happened regularly enough to where I just didn't want to talk about them. In my mind, just keeping up and doing my job, and being careful were the essential elements to being successful. However, that slowed me down, and I was perceived to be the bottleneck. For many of the situations, I think it was absolutely correct.
One of the most frustrating situations to find yourself in is to have one on ones with your director and to hear "you are doing a good job, but...". As the months progressed, I felt like the "but" in that line was becoming more and more pronounced. You missed this issue. You are taking up too much of the developers time. You need to be more independent. You need to focus on deeper and more critical bugs. Every one of these was true, don't get me wrong, and every time I sought to do exactly that, yet every time we cam back around, it felt like the same conversation. My friend Matt Heusser calls this situation the "I want a rock" problem. The idea is that someone asks for a rock. When you bring them a rock, they say "that's not the rock I want, I want a different rock". Over time, as we keep bringing different rocks, it becomes clear that what is being requested is not the rock being presented, it's who is doing the presenting. It was becoming clear to me that being a Lone Tester in this environment was perhaps too much for me. Perhaps if we had all been clearer on the expectations from the outset, or how we all wanted to work together, the outcome could have been different. Regardless, I found myself in a situation where there was mutual frustration. the programmers weren't happy, and neither was I.
I sent out a message to a few of my friends, saying I was feeling frustrated, that perhaps my role as a Lone Tester was burning me out, or that I was possibly not the best fit for Sidereel at this stage of the game. In short, I wanted to explore other options. I was open to managing a team, or mentoring other testers, or doing something with an organization where my only stipulation was "I don't want to be a Lone Tester this time around". Shortly after I sent that message, my friend Ken Pier contacted me and asked if I'd be interested in joining his team at Socialtext. Ken had met me two years before through Matt. He'd been to several conferences and meetups where I had participated and been a correspondent. He'd attended a few of my talks, including my "Balancing ATDD, GUI and Exploratory Testing" presentation. He had also read my blog for the past couple of years. In short, Ken knew what I could bring to the table, and what I could not. He explained that he was building a team of seasoned testers; he wanted people on his team who really understood software testing, and he proved to me that he understood it to, as well as what it can and cannot do. Through further conversations with him, and some casual conversations with some of his co-workers, I made the decision to hang up the Lone Tester mantle and focus on being a team tester once again.
Over the past two years, I have worked with a team of awesome people. They introduced me to a Kanban approach to software development, had me get intimately involved again in automation, albeit in a way that was totally different than anything I did at Sidereel. I also was asked if I'd be willing to take on a special initiative. We had performed an accessibility audit and had discovered many areas where we needed to make improvements, and the testing needs for that would require someone willing to spend a fair amount of time with screen reader and dictation software, among other things. I decided that, yes, I would be interested in doing that. I had no idea at the time that what I'd be asked to do would have such a fundamental effect on what I do, but in the ensuing two years, accessibility has become one of my core competencies, and the language of and advocacy for accessibility features would come to permeate so much of my world view. Prior to this, I had next to no understanding of what Accessibility really meant. Now, I'm the go to person.
Another thing that was also very helpful is the fact that Ken (my director) is a member of the Association for Software Testing. He understands my involvement as a board member and as an instructor, and has actively encouraged the initiatives we have championed through AST be used here at Socialtext. I've also been able to use Socialtext as an application for various testing challenges, such as Weekend Testing and the Software Testing World Cup. that feedback has helped us make a better product, and that connection to a broader community of testers has been a long term commitment of Socialtext as well (did I mention that Matt worked here before I did? If I didn't, let me fix that. Matt worked at Socialtext before I did, so he plowed a lot of ground that allowed me and the rest of my team to reap the harvest he'd sown years before).
This year, I was selected to be the President of AST, with the full backing of my team at Socialtext. Being able to be the advocate for testing that I see myself being, as well as doing work at a company that is fun, engaging and interesting, with a team of people with as much experience as I have, if not more, and the opportunity to mentor younger testers when we get the opportunity... it's been a lot of the reason these past two years feel like they have gone by so fast.
So what pearls of wisdom can I share since my last Meander?
-- it's important to understand how your team works. More important is understanding how your team wants to have you work with them. It may seem trite or silly to say "make sure you understand what your programmers want from you as a tester", but it's not a trite question at all. They are your customers, you provide a service to them. It is in your best interest to understand what makes them comfortable and helps make for a mutually effective relationship.
-- you cannot test quality in, you can only tell people where issues may be. This keeps getting hammered into me everywhere I work, but I think it bears repeating. At the end of the day, I do not make the choices as to what ships and what doesn't. I can be overruled, and I need to be OK with that. If my information helped them reach a decision, then that is good enough.
-- being a lone gun is hard, and it can be lonely. Moving to a team does not automatically fix that. A team has to engage in a different way, but it also require a meshing of personalities and work styles. I came in with an idea of "I know testing, I'll be able to swing everyone around to my way of thinking in no time. truth is, I learned a whole lot more from my team than I thought I would, and realized that I didn't have all the answers. Not by a long shot! With a team of seasoned veterans (of which I am one of the younger ones, I might add ;) ), we've melded our skills and abilities quite well.
-- be willing to take on a "problem child" issue when it is presented to you. When the opportunity came up to work on accessibility issues, no one else was enthusiastic about working on it. I could say "ignorance is bliss" because I said "sure, I'll do that" with the attitude of "how hard could it be?". Well, when you find yourself surrounded by machines that are rapidly talking at you, or you find yourself plugging in a headset mike to "talk to" your computer on a daily basis, it can get irritating. Still, working through the irritations can help you develop unique proficiencies, and then being the person people can rely upon to consult on issues around that area makes up for a lot of annoyances, and now, I actually like tinkering with the accessibility tools.
-- automation is an ongoing need, and more and more businesses are utilizing it to get the repetitive stuff off of their plates. Do not fight this, in fact, do your best to become part of the flow. Whether that means you actually program, or consult with those who do, put yourself into the process. What you learn may have large impact on the amount of time you spend doing repetitive tedious busywork. If you can automate that busywork, then you save your eyes and your energy for much more interesting territory to explore :).
My thanks again to Socialtext for what has thus far been a very rewarding and engaging two years. I look forward to what tomorrow brings!
No comments:
Post a Comment