An evolution of the testing industry and testers

I’m not a leading thinker in the software testing field (Captain Obvious I know), but I do think about the field and, as often as possible, as deep as I can think about the trends that are influencing my field and how it impacts me moving forward. Looking at one’s field or practices analytically or theoretically can be helpful to help reign in some of the “pragmatic drift” that occurs as we deal with the realities that are thrust upon us day-after-day. I have been interested to gauge the field of those attending the Agile2015 conference about where they see the trends for software development and software testing, in particular, are currently and where they might be headed. Most likely this same question would produce different answers if put to people attending the CAST 2015 conference (possibly radically different answers in some cases).

I had the chance to attend an AMA (Ask Me Anything) style session with Elizabeth Hendrickson (twitter handle: @testobsessed) and asked her what she saw about the growth (what I really meant to say was change) of the field of testing over the next 5 years. Elizabeth’s answer, as I heard it, was that she didn’t see growth in the testing industry over the next five years. Maybe she meant for traditional testers, I’m not sure because we were running out of time, but that is a sobering thought for someone that identifies as a tester currently. If (and that might be a big if) the software industry is moving towards more combined engineering and probably fewer test specialists (or testers) overall or certainly as a ratio to the number of other developers or team members, what does that mean for testers working in agile environments and for our next jobs (because let’s be honest we should all be preparing for our next jobs, that’s just the way careers and the world of work, especially in technology, are today)?

What does that mean for job openings that people hire for? Does that mean they will be just hiring software developers in general? Is the future of agile teams to have no dedicated testers, but to have T-shaped people who have testing skills and any “testers” in the organization work with different teams to try and ramp up those types of skills?

Sometimes I feel like that is what people are saying without saying it, but I could be interpreting things wrong and I certainly don’t have a wide gauge of the industry beyond what I’m reading in blog posts and on twitter. I’m certain that there is plenty of manual script-based testing still happening and remnants that will hang on for a long time, but as these practices spread and entrench, it feels like the role or number of dedicated testers will shrink. When other industries experience a shift or change, some roles have to change, shrink or go away.

Frankly, I’m fine with change and I’m increasingly of the opinion that the role of testing moves further “left” into the development and design phases as we get better at “being” agile in our software development. It feels like that is where the industry and trends are moving (at least it is one probably evolutionary possibility for the field). What is hard to know for someone who isn’t seeing that style of development is to understand what that looks like, what new skills should be developed and then how to evangelize that to other team members and management when it also flies in the face of what they see as the traditional role of testing. I suppose that is why change is hard. The long term reality, however, is that not changing individually while facing a shift in industry is even harder.

*Note: These thoughts have been percolating for a while and represent my thinking and perceptions about what I think other people are saying (which might be incorrect, they are my perceptions after all). The session I attended at Agile2015 this afternoon really just spurred me into trying to put my thoughts into words to clarify both the questions I still have, as well as what my current thoughts are on the topic.

On the development of ideas in a team

(This is a post from my previous blog that I migrated over because I thought it was valuable and it’s a new home for my blog)

Implementing new ideas within a team or an organization is an interesting and challenging process. I am seeing the challenges of this process both at my team at work and in my role as a volunteer in a local youth organization. The context for my team at work is what changes to our tests and testing processes are we going to make to continue improving how and what we test. In regards to the youth group I’m involved with, it is how deeply will we adopt particular programs and processes and how should we plan the program for the youth that we run (including things like funding, length of the plan, parental and youth involvement, etc). Implementing great ideas (like the development of great software really) can be fraught with challenging details that can easily derail even the best of ideas. At work, for example, we just finished up a major release and are beginning to discuss/reflect on ways that we can improve our process for the future. One of the challenges I am finding is that I have ideas about what I would like to change, but the actual way in which the change is implemented in some ways seems like a harder challenge to crack. What processes are going to be created to actually effect the changes envisioned, how committed is the team to the change, do they capture the big picture vision of why this is being done and what the change is hoping to accomplish. These are important, but potentially challenging details. It takes both a will and good implementation to overcome the sheer inertia of how a team (or an individual) is accustomed to working. Great ideas, implemented or adopted poorly, are as likely to fail as poor ideas that are implemented poorly.

One particular challenge is how ideas are spread and adopted throughout a team or organization. Almost inevitably, in a team of any size, there will be some differences in opinions about particular ideas or changes. How these differences are addressed and resolved play a huge part in how well ideas and changes are spread and implemented and often times this part is just incredibly hard and slow. I’m left wondering how can teams appreciate, celebrate even, the differences in opinions and talents while still being capable of adapting and changing. This can be particularly difficult when some team members feel like the status quo is acceptable and feel no motivation to change.

That is the question I’m left pondering these days. How can I effectuate change I feel is necessary? I wouldn’t consider myself a “boat-rocker” by nature. I’m not particular fond of conflict and promoting change almost inevitably invites conflict or friction. Is some conflict inevitable in the development of the ideas? My experience leads me to believe that yes, it is inevitable. The greater the size, the more likely and diverse the conflict will probably be. So the companion question is, how can we manage conflict to help improve an idea without poisoning the relationships and morale that is necessary to make the changes or ideas successful.

I have more questions than answers at this point, both in regards to my youth group involvement and my team at work, but I felt like I needed to capture some of my thinking. We’ll see where things continue to develop. I have lots more thinking to do, but these general ideas seem clear for me as I try to move forward:

Favor action

People are as important as ideas

Embrace flexibility and experimentation with quick feedback loops (Are we asking ourselves frequently what experiments are we running this week, this sprint, this month, this year?)

Ask yourself implementation questions first, things like (What would this look like? What would other team members need to be successful? What conflicts to process or people might occur?)

Here are some quotes that seem especially relevant (though I would encourage viewing all of the quotes from the URL that I sourced the following two from, they are terrific!):

Follow effective action with quiet reflection. From the quiet reflection will come even more effective action.
Peter Drucker

Thinking is easy, acting is difficult, and to put one’s thoughts into action is the most difficult thing in the world.
Johann Wolfgang von Goethe


The Value of Surprise in Observation

I was reading a back issue of Better Software magazine recently and came across Lee Copeland’s article about surprise and observation. In his article he makes the case for the value of surprise and how we should not treat it as a dreaded result (which he admitted to doing at times as a manager). My favorite quote from the article is his statement:

“When we are surprised, it may be that we have simply been oblivious to events in our world.”

I found that to be a profound statement. Do we value surprise in our lives, including the types of surprises that come at us at times that make us feel uncomfortable? As Lee points out (and I have heard Scott Hanselman share in an excellent talk), it is vital that we ignore lots of information that we are faced with on a daily basis. Most of it is irrelevant, not worth even passing attention, and even valuable information exists in such a quantity that we have to ignore some of it. What we should not do, however, is ignore what surprises can teach us about what we have been ignoring. Lee shares some Weinberg wisdom (Jerry Weinberg that is) about avoiding the maintenance of an “oblivious culture” that willfully chooses to avoid observation about the world (and its people and processes) or ignores the information that does not match what is believed to be true. In other words, they are failing to capitalize on the value that the surprise could have revealed if it had not been ignored and tossed away.

So the next time you are surprised by something, at work, home or somewhere else consider using it as an opportunity to reflect on what you might be ignoring and what that surprise could help you learn. Some questions I came up with that could help with this (in software testing and elsewhere) are:

Ask yourself what is happening?
What does it mean?
Is it important? Why?

So next time, don’t just enjoy (or fear) the surprise you are faced with, but learn from it too.

Welcome Back to my Blog

I needed to get blogging again, wanted to try Azure, and so I thought I’d give Project Nami along with my Visual Studio Dev Essentials credit to host the blog, so here goes. The main topics for my posts will be my experiences as a software tester (with a DevOps focus) as well as some commentary on technology today and my experiences with a variety of those technologies (in particular Microsoft technologies but technology in general – hence the name of the blog Technophile Tester). I should add that I’m writing this on Microsoft Edge on Windows 10 Mobile (Lumia 950) using the Microsoft Continuum dock setup (lots more on those things later).

I’m sure I will get around to getting this blog dressed up a bit with a better theme and all, but it’s really designed to be less about configuration and more about having an outlet for my thoughts and opinions again. I hope you’ll add me to your RSS reader (you do use one of those don’t you 🙂 ) – otherwise I suppose you can subscribe via email to receive updates when I publish a new post (which I do hope you’ll do if you don’t use an RSS reader).