Hello From Cocoa Beach: CAST 2026 is Underway: "How Avoiding Conflict Is Breaking Your Team"

 This is going to be an interesting and different CAST this go around. While I have live blogged conferences for years, I will not be doing much of that this go-around. That is because I am going to be doing live webcasting and video casting. We are launching a Webcast called "Responsive Ilities", we being me and Justin Bench. I will be posting the links to those as they go live. They will be fast clips, fun interactions, and we hope a good representation of the fun we are having here.

There will, of course, be some sessions we will not be vidcasting, such as our morning keynote right now. We are starting the conference with Dr. Jen Fry and her talk, "The Bugs Aren’t the Problem: How Avoiding Conflict Is Breaking Your Team"

The key message here is, "Software teams don’t struggle because they lack tools, frameworks, or technical skill. They struggle because the conversations that should happen… don’t."

I know this to be true, in some capacity, for every job I have ever had, both in my testing life and in the other things I do. I'm the enthusiastic, bubbly dude who likes doing, likes getting cool things done, and if there are conflicts or issues, we just let them roll off, and we figure we will just muscle through with our enthusiasm, and if we just kick enough butt, those issues will just disappear.

"Stop me, oh oh oh stop me.... stop me if you think that you've heard this one before!"

As you all know, I tend to riff on the ideas I'm hearing. I don't summarize the talk; I think through their points, and I take what I'm hearing and think through it with my own experiences.

I am intimately familiar with seeing something that I think might be wrong, but I'm unsure. Or I might want to make sure I can articulate everything before I vocalize my concerns.  Where does that come from? It comes from voicing concerns too early in the past, or thinking something is wrong but not having a full picture. What's the root problem here? I have an anxiety of looking like I don't know what I'm doing. Ever heard the phrase (paraphrased), "If you sit silently, you may be seen as a fool, but you can say what you are thinking and remove all doubt!" Yes, that's real. We all do that to a certain degree. We fear being seen as foolish or unwise, so the easiest tactic is to hold our thoughts until we are really sure. Maybe, possibly, we will gather what we need to make sure we have a thorough understanding and can present everything brilliantly. More often than not, though, life comes at you fast, and you are onto something else. Then when the problem rears its head, and others see it, you sit there thinking, "oooh, I knew that was an issue, but I didn't say anything because I didn't want to look stupid." Well, now the problem is out in the open, and I look more stupid because I held my peace until I was sure. 

Okay, so how can we counteract this very real issue people face? Part of it is practicing these words (again, this is how I handle this, or at least try to).

"I'm not fully sure I have a handle on this, but I'm noticing something that concerns me about [key area]."

"I may be missing something, but are you seeing an issue with [component]?"

"Are you familiar with this [area of misunderstanding] because I think I may have an issue... but again, I'm not sure."

Am I risking being seen as a fool right now? Absolutely. I'm sharing the fact that I'm "ignorant". Understand, that's a loaded word for many, and we hate hearing it about ourselves. Truth is, everyone is ignorant about a lot of things. Ignorance comes from Latin "ignorantia" and "ignorare", meaning "not to know" or "to be unacquainted with". I try to remind myself that "ignorance" is easily solved. I can learn, I can ask, and I can be taught. 

From a different place, I am often seen as the "psychic glue" in a group. That's a phrase a guitar player in one of my previous bands coined for me. He said that I had a tendency, due to my enthusiasm and general overall good nature (I think the phrase now would be termed 'Golden Retriever Energy' (GRE), a phrase that I actually love :) ), I make it possible for people who would struggle to interact a buffer, so that I cam the person in between who, because of my GRE, I can be that central glue point so we can all work together. Conflict doesn't stick to me or affect me when it's other people's conflict. If other people have issues with each other, I can be the go-between and easily smooth that challenge. The problem with GRE is that when the conflict comes to us, we can internalize it and think we are the problem. So we strive to make others happy and be cheerful, to hopefully cause the conflict to dissipate. I'm good at soothing issues. I'm not so good at actually resolving the conflict. The funny thing is that sometimes, my enthusiasm can have me jumping the gun at certain things, and then I get yelled at... but if people are yelling at me, they aren't yelling at each other. Since I have GRE, I can take having people be annoyed with me, and I can laugh or shrug it off easily. Net result: I glue everyone else together, and we function well,,, but you see the problem, right? Being psychic glue can be a good thing when it's applied correctly, but glue can also be messy if it's not applied correctly. Thus, I need to be willing to step back and speak more openly about the conflicts and be willing to not be seen as the happy-go-lucky golden retriever. I may not be able to be that glue at the moment, but I may be able to be the glue that is needed later on.

That's a great start. It's good to be back. Did you miss me :)?

Being a Change Agent with April K Mills (Welcome to PNSQC Live Blog Stream)

Hello all, and welcome to PNSQC, coming at you from Portland State University Place Hotel and Conference Center. Some of you may be hearing concerning things coming from Portland and having been here for two days now in real time, it is absolutely quiet and normal here (though I must confess that the media I have seen of protests with people in frog and chicken suits, I love how absolutely unserious Portland is. We literally started the conference with "The Beat Goes On" marching band (I will upload and link media when I get the chance).

Everyone is a Change Agent

Our first talk/keynote today is coming from April K. Mills, and her talk is "Everyone is a Change Agent". I had a chance to discuss this wth April in our PNSQChronicles vidcast (will link here later), but the key point here is that change agents don't have to be high-power, in-charge people. Every one of us has the capability, and I'd argue the responsibility, to be the change agents our organizations need. To borrow from an idea I agree with a great deal, "everyone needs to stand for something, even if doing so means we have to stand alone".

One of the ideas that April is recommending we start right now to do and be a change agent is to stand against and fight the spread of "AI Slop." How many of us have found ourselves literally struggling with and drowning in AI-generated content in our organizations that seems to say a bunch but doesn't really mean anything? I have run into this a fair bit in social media, but it is absolutely creeping into publications and corporate marketing missives. I saw a person online coin a phrase I have now started using: "AI;DR".

Note: I use this when I am seeing obvious AI output that has been generated, reads as completely soulless, and you can see that much of it is not factual or is genuinely wrong in various areas. In these cases, I do believe that announcing "AI;DR" is an excellent response.

YouTube: PNSQChronicles episode with April K. Mills

One of the things I have always appreciated (and I'm quoting Matt Heusser is the wording here) when I come to conferences like PNSQC is that I am not looking to upend the entire world with everything I learned. First of all, it's not practical, and second, systems are developed over time, and there may well be entrenched interests to overcome. Thus, it's not practical to come back from a conference with everything under the sun to overturn everything we do. Instead, we need to find a few areas that we can implement and do so without needing permission to do those things. All of us can do that. We find a way to add a new approach, process, or method based on what we learned, and then, in a few weeks or months, when people are curious as to how we have made key improvements, we can then say/demonstrate what we have been doing. There may be varying barriers to exactly how much we can do in certain areas, but we can all do something in a different way. 

When we can implement an under-the-radar change, it's often a good idea to try it out quietly and see if the change is worth pursuing. Often, we can determine pretty quickly if our brilliant idea may not be so brilliant (or at least we discover the key contexts that help explain why we haven't tried doing this before). Make no mistake, that in and of itself is often a valuable exercise. 

Sometimes the best question we can ask is "Why?" There is an idea called the "Power Paradox" that comes from the idea that people can only do so much because they don't have the power to make changes. We hear that in politics and senior management all the time. If only we could get the people at the top to agree with us and make the changes necessary. Truth be told, we don't always need to do that, and sometimes, the best way to break down that false assumption of power is to ask why we do something (strategically, don't become the kid in the back seat asking, "Are we there yet?" every five minutes). By asking "Why?" at strategic times, we may not sway the people at the top, but we may get more of us at lower levels to also ask why, and if more of us start asking why, that often triggers those higher up to realize that this is an issue that is not serving the people it intends to. Sometimes it takes more than just asking why, but strategic action often starts from just that question.

Key Takeaway: Being a change agent doesn't have to be a major initiative, and we don't have to reinvent the wheel to be a change agent. We don't need to have the right boss, with the right budget, with the right revenue, at the right time to make changes. Often, we can make changes just by trying to do some different things, and often, we can do them without having to ask permission to do so. Start there first and work your way up :).

Party Down with MS DevOps: Live from #STPCON

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

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

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

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

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

Continuous Testing: Live from #STPCON

Continuous Testing is one of the holy grails of deployment. We've got the continuous integration piece down, for the most part. Continuous testing, of course fits into that paradigm. The integration piece isn't helpful if changes break what's already there and working. From my own experience, the dream of push button build, test and deploy feels close at hand, but somehow there's enough variance that we don't quite get there 100%. This is for an organization that deploys a few times a week. Now imagine the challenge if you are at an organization that deploys multiple times every day.

Neil Manvar is describing his time at Yahoo! working on their mail tool, and some of the challenges they faced getting the automated testing pieces to harmonize with the integration and deployment steps. Some of the ways they dealt with making a change from a more traditional waterfall development approach to an Agile implementation was to emphasize more manual testing, more often. Additionally, the development team aimed to help in the process of testing. Plus in that there were more testers, but minus in that programmers weren't programming when they were testing. Later, the brute force release approach became too costly to continue, so the next step was to set up a CI server using selenium tests, running an internal Grid and coordinating the build and test steps with Jenkins. Can you guess where we might be going from here ;)?

Yep, unreliable tests, need to rework and maintain brittle tests, limited testability, limited testability baked in, etc. Thus, while the automation was a step towards the goal, there was still so much new feature work happening that the automation efforts couldn't keep up (hence, more of a reliance on even more manual testing). A plus from this was that the test teams and the development teams started talking to each other about ways of writing robust and reliable tests, and providing the infrastructure and tooling to make that happen.

This led to a focus on continuous delivery, rapid iteration, and allowing for the time to develop and deploy the needed automated tests. In addition, the new management mandate was regular delivery of software, not just over a period of weeks, but multiple deploys per day. What helped considerably was that senior management gave the teams the time and bandwidth to help them implement the automation, including health checks, maintenance steps, iron out the deployment process, and ultimately enforce a discipline to pull requests and merges so that the deployment pipeline, including build, test, and deployment, would be as hands off as possible. Incrementally updating also improved the stability of the product considerably (which, I can totally appreciate :) ).

Ok, so this is all interesting, but what was the long term effects of making these changes? Ultimately, it allowed QA to expand their skill set and take the busywork off of their plates (or a large amount of it) so they could focus on more interesting problems. Developers were able to emphasize development, including unit tests and more iterative improvement. Accountability was easier to implement, and see where the issues were introduced, and by who. Additionally, a new standard of quality was established, and overall, features were delivered more quickly, uptime improved, new features were deployed and overall satisfaction with the product improved (and with it, revenue, which is always a nice plus ;) ).

Home Field Advantage: Welcome to #STPCON

It's here. After months of waiting working, tweaking and applying ideas, Software Test Professionals Conference (STP-Con) has come to Millbrae, California. I cannot begin to explain how nice it feels to be able to attend a conference that consists of total travel time from my house to venue of less than fifteen minutes.

I had a great opportunity Monday to teach and facilitate a workshop on "Teaching New Software Testers", and I received some great feedback about where the material is on track, where it can be improved, and some new ideas to consider adding to future presentations. Since it's an extra pay item, I'm not going to blog about all of the details from that talk, but if you read my blog regularly, you probably already know what I've covered :).

Tuesday night we had a Meet & Greet at Steelhead Brewery in Burlingame, and I was really happy to have two special guest attend with me; my daughters Karina and Amber. They have both expressed interest about learning more about tech and how it might be something they can contribute to in the future, and it was wonderful to see so many of my colleagues reach out to them, include them in conversations, talk about their careers, and other avenues that might get them excited. I want to give special thanks to Smita Mishra for taking the girls under her wing and introducing them to so many people, and to Ben Kelly for hanging out with them and talking all things Japan and Game of Thrones. On the drive home last night, they were happy and excited to have attended, and mentioned key conversation points and things that interested them.

Today is the first day of the conference proper, and that means the TESTHEAD live blog is now in full swing. There will be individual posts for each session other than mine (I'll post a summary of my session later ;) ).

We start off today with Karen Jonson giving a keynote about "How Nancy Drew Prepared Me to Become a Software Tester", but before she got into the main topic, she gave some great advice for career curation, including encouraging attendees to attend sessions that are relevant to their current work, but to also look for something that makes you stretch or may be outside of your current focus. You may or may not be working at the same company a year from now, but your career carries with you. Attend sessions that will grow you not just for now, but into the future, too.

For those not familiar with Nancy Drew, she's an iconic literary figure in children's books. She has different names in different countries, but she's a young lady who solved mysteries. a quote include in Karen's talk was that "Women in many occupations told of learning from Nancy to see adventures in problem solving and the joy of self-reliance". That's a great description of a software tester, too, isn't it :)? Every product is its own unique mystery. Now, to be frank, I didn't read many Nancy Drew books, but I read the Hardy Boys, which was the mystery series aimed for boys, while Nancy Drew was aimed to girls. If that seems a little closed minded, please realize, I was a boy in the seventies. I did boy things, but later on, I learned more about Nancy Drew, and especially wanted to learn more about her when my daughters came into my life. The Hardy Boys and Nancy Drew books are similar in format, and in delivery. They both let the reader get drawn into problems and challenges, and follow along as the protagonist learns more about the situations, and they get to test out their own hypothesis about "whodunnit". These really are wonderful primers to help encourage young readers to see the mysteries and how they might solve them.

I've been a fan of the metaphor of tester as "beat reporter", but "detective" is a natural fit as well. We often have to take on different domains. They put themselves in unfamiliar situations. They observe, they take notes, the look for situations that could potentially be dangerous, and they present the case to find the "whodunnits". Karen mentions a book called "Making Thinking Visible", and how it allows people to visualize problems. The basic idea is the triplet of See/Think/Wonder. Testing at its core uses these three words, if you step back and think about it. Additionally, another triplet is Think/Pair/Share. We don't want testing to be a mystery, we want to be open and share our findings. The more people that look at testing as cognitively challenging and interesting, the more people will get involved with it, and frankly, we need more testers, even if tester is not part of their title.

Consider the fact that what we think about things changes as we get new information. We are conditioned to think tht changing our minds shows a weakness. It shouldn't. We should embrace the idea that "I used to think.... but now I think..." because that means that we are actively considering what we are learning. We should not get so tied up in our world view, because new information can change the entire trajectory of what we are doing. We should be open to and welcome that, even though that may be uncomfortable. We should embrace active thinking, and we should approach things with wonder. Believe me, that can be hard when you've tested something multiple times. "been there, done that" is not just mind numbing, it's dangerous, because that's the condition where we are most vulnerable to missing things. We get blind to what we see all the time, and we take shortcuts in our heads because we know what's happening... or so we think.

Ultimately, the same traits that excite the imagination the way that Nancy Drew mysteries (and OK, Hardy Boys mysteries for me when I was a kid), they really do give some great parallels as to how we can re-engage and make testing much more interesting.

Agile Leadership Lessons - Live at #AgileTD

Selena Delesie and I have known each other for about five years. I met Selena as one of my co-participants in the BBST classes, and we have had an ongoing correspondence and bumping into each other at events over the past few years. Selena has focused on being a coach and a consultant. She has a broad range of experiences and a unique presentation style, and I'm excited to see her delivering a keynote today :).

Ask yourself, if you could have dinner with any person alive, who would it be? Why? What do like about them? For me personally, I'd like to hang out with Gerald Weinberg and earn a bit about how he got where he is today. I'd also like to hang out with Larry Winget for awhile because I think he's a hoot and his personality is bigger than life.

Selena emphasized that her "must meet" is Richard Branson, and while she didn't get to meet him directly, she did get to interact with him at an event she was attending. She said that some of what she admires about Richard is his ability to listen deeply. We tend to want to make our views known, and by doing so, stake our claim on our knowledge and experience. More important is being able to listen deeply and learn to understand the challenges people are facing. My expertise doesn't matter if the expertise I have won't help the people I'm conversing with or hoping to lead or help.

How can we improve on collecting information and ideas? In general, the best thing is to just stop and listen to the people we are working with. Ultimately, it's all about the people on your teams that you work with. It's important to realize that, if you are going to be a technical leader for a team, your goal is not to make yourself shine, but to make the entire team shine. As a leader, your goal is to help other people be successful. If that's not your thing, you need to consider a different line of work. Additionally, do all you can to make people smile. When people smile, they open up and amazing things happen.

Who can you improve your relationship with? For me, I think it is important to have a good overview of the business as a whole, so foster relationships with people outside of your immediate team. Build relationships with people who can help you understand what is happening in the entire organization. As you learn what other people in your organization deal with, and what their pain points are, we can help alleviate that pain, or look at our work differently.

Be addicted to learning. Discover what domain knowledge exists in your organization, and be prepared to go where the needs are, rather than just what you want to do. For me, the most pressing need in our organization at a time was to understand the entire build process for our software, and that led to me becoming the release manager for our company. Do i know everything about the process? Hardly, but I have a chance to learn and experiment regularly, and provide basic improvements to the process here and there, and that's made a world of difference in my work reality this past year.

We don't learn by following rules. We learn by experimenting, by doing, and yes, by falling over and getting back up again. It's a challenge to learn new things, especially in areas that are not comfortable to us. It's also important to carve out the time to get good at what we do. Part of that requires us being willing to say "how may I be of service to you?" It's not enough to just show up and do things for our benefit alone, we need to be wiling to be of service to each other and our organizations.

Another question to consider is "what problem are we helping to solve?" One member of the audience said "harnessing all of the brainpower of the organization". Another said "to get a better shared understanding of the software we are developing". Another said "hiring more team members". For me, it's "making sense of the infrastructure and feature needs to help identify the real critical issues that our customers need".

Agile means being adaptable and flexible, and yet we still find that old habits die hard. We may think our teams are agile, but in many ways, there is a lot of tradition and process to overcome, and many of the methods we use are often counter-productive. Remember that change is a given, but how you respond is a choice. Don't be afraid of adapting and trying something different.

 

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 :).

Let's Move it Forward - Live from #CAST2015

Today the rubber meets the road. Day one of the full CAST 2015 conference is underway. We have had breakfast, we have introduced the program, and we have announced the election running. To that end, I want to remind all AST members that you have until 7:00 p.m. Eastern time TODAY to cast your vote for next year's Board of Directors.

Last year Karen Johnson and I had a discussion at CAST in New York where we commented on the fact that there was an "echo chamber" developing in the software testing world, and that it seemed that the voices we most needed to hear from we were not hearing from. She and I discussed the idea that the industry seems to value "rock stars", to which I laughed that those who use that term haven't known very many rock stars in real life (I have, and truth be told, they are not necessarily the most reliable people on the planet, but they are often fun to be around and listen to ;) ). Karen has been a solid voice in the testing world, and I was excited to see that she was the opening keynote for CAST 2015.

One of the great things about going to conferences for the first time is that the reaction we most often have is "Oh, wow, I'm not alone!" Getting that confirmation that first time can be huge, and it helps make it possible to frame our place in the world of software testing. Karen has been in the software testing world for 30 years, and like many of us, didn't have any intention of being a tester when she started out. She planned to be a journalist (which I think is really cool because I often look at software testing and journalism to be very kindred careers). Karen shared a lot of highlights from her career, and when flashed across the screen, made clear that she's had and continues to have a remarkable career! I recommend checking out the webCAST video of her keynote when it posts.

The theme of CAST 2015 is "Moving Testing Forward", and that indicates that in many ways, testing is seen as not moving forward. Software development has changed radically these past twenty five years (that's my time frame, since I started really thinking about it when I stated working in IT in 1991). Many of the development techniques have changed, but the way that software has been tested, at least in a number of organizations I have been in, has changed very little. It's easy for testers to feel "stuck" at various points, and when we try to make those forward steps, we often receive push back, and at times that pushback comes from our own colleagues. I had a similar experience in 2009, after nearly twenty years of software testing. I felt like I was doing the same things the same ways, and there was very little I felt I had to show for it beyond what I learned the first few years. Yes I had twenty years experience, but it felt like I had two years experience repeated ten times.

Stepping forward takes courage, it takes a willingness to know who you are and what you are good at. It also means you have to be ready to accept that there are things you are not good at, and often, that's the hardest part. However, it's important to realize that the things you are not good at can be improved, and the things you are good at can be boosted even more by focusing a bit on what you don't feel you are good at. Karen and I look to be on the same page here, and while we realize that there are so many things in the world we will never be amazing at, we can always improve our odds by working on the things we are good at. We can't do that exclusively, and yes, some things that are distasteful or uncomfortable come with the territory. Deal with them, but don't obsess on it.

Another valuable point comes in with who we work for. Karen recommends strongly to do all you can to not work for people you do not respect. If you work for someone you do not respect, your entire relationship will be off kilter. You will know it, and they will know it. When you don't respect who you work for, your best work rarely comes out. When you respect who you work for, it's not uncommon to walk through fire for those people. I've had a few of those experiences, most recently with my dearly departed Director of Quality Assurance, Ken Pier. I can truly say I would walk through fire for him, and I strive today to be worthy of the respect he had for me as well.

There will be office politics. Do not believe you can escape it. You can't. It's part of the culture, and to borrow a recent quote from @DocOnDev... "your office does not have a culture, your office IS a culture". Cultures are dynamic, they are lived, and they are managed, for god or ill, and every one of us is part of that reality whether we like it or not. We cannot choose to not deal with people unless we literally work for ourselves only. I don't have that reality, and I'm guessing you don't either ;).

Karen mentioned that there was a value to having a manager/boss that you worked with instead of for. If you can develop a relationship that is closer to that of a peer, you can make amazing strides. true, you do work "for" someone in the literal sense that they sign your reviews and approve your bonuses and pay raises, but outside of that, it is much easier and more enjoyable to work with people rather than under people. As I said before, one of the great experiences of my career was working with Ken Pier, because he emphasized the working with. He was my director, but he hated being a manager. He wanted to be a doer, and when it came to the work of our team, he shouldered as much work as the rest of us, and often more. He wasn't an office manager or a bureaucrat, he was in the trenches with us, every day, and that make working with him both easy and enjoyable.

Along with managers, we have co-workers. Other testers, programmers, project managers, along with a myriad of other people. An important question to ask is "would I want to work with this person again at another company? If I had to change jobs and companies tomorrow, who would I want to bring with me? Who would I want to leave behind?" those people you identify as those you want to take with you, cultivate relationships with them, not in the sleazy "networking" way, but really get to know them and foster a relationship with them. Let them do the same with you.

Many people think that moving testing forward is about technical prowess only, but in truth it also requires people living and experiencing life. It might seem strange to think of work/life balance as a way to move testing forward, but it is important to keep moving and learning and evaluating to keep from becoming stagnant. the fact is, our living and interacting is what lets us actually excel. There's a phrase that I remember hearing about juggling several balls, and that all of the balls are rubber except for one, and that ball is made of glass. What do you do? The point of the story is that the glass ball must never be dropped. The other part of the story is that the glass ball is never the same thing. At a given time, the glass ball may be family. It may be work. It may be health. It may be leisure. The point is, everything will be bounced and dropped at various times, but we need to be alert and aware at what point in time the glass ball's label has changed, and what it has changed to.

Outside of work, there's many opportunities to learn and interact. Conferences are an obvious one, but there are many other ways to get involved in the community at large. Meetups, message boards, weekend testing, organization involvement, even participating in conversations on Twitter all help to foster that sense of community, but for it to matter, we need to engage. I have often said there are many who are consumers, but few who are active producers. It takes some courage to become an active producer, but the great thing is, we all can, and we can all start right where we are and move forward from there.

OK, I'm going to go help handle open season at this point, so I'll be back with you in another post in a bit. Thanks for following along :).