As a Test Manager I oversee the testing in a project or program – I am usually the only testing specialist in the project, so, I need the right leadership skills and the right tools to succeed. I have to own the data about the testing and quality activities.
As the test manager I need to facilitate a quite a range of testing activities:
Business Analysts  or similar within the project
End users or end user representatives
I need to balance that I need to know what’s going on (with regards to testing) but without micromanaging the people being involved in testing and quality activities. My role is to facilitate that testing things happen – like the project manager making project things happen. I cannot own the activities without owning the data about it. I need to cover the full spectrum of tests – from engineered (RDA and CI/CD) to people-based (scripts and exploration).
The most practical tool for a test manager with this scope is PractiTest, as there is more to testing than just the test cases . The old term “ALM”  comes to mind – it is still relevant when I look for a full test management tool. I need to cover both the “inputs” to testing (requirements, tickets and user stories) and the “outputs” (bugs) in one location. I need the requirements and user stories in my tool, as I need to base my test analysis and planning on the delivery model (that may not always be agile). I need the bugs in the testing tool too, as bugs can happen in any work product of the project: documents, code base and even the tests. PractiTest acknowledge that there is more to IT projects than code.
I appreciate the key driver of PractiTest – that all activities happen in-flow. You don’t have to change window, stack pop-ups or go to another tool in order to run the tests or create bugs. Creating bugs happens in context of the test case and seamlessly moves all data about the run to the bug. Everything you need to do is context-based, and available to you on screen. And it has some cool features of read-only links to graphs for management reporting, and a smart built-in “rapid reporter” for exploratory testing notes.
It can be a challenge to switch to PractiTest if you are in a compliance setting, if you need on-Premise or if your team generally uses Azure DevOps (the tool formerly known as TFS). To get the full potential of Azure DevOps, though, you need the full Microsoft Test Pro licenses, so it’s not a free tool either – nor is DevOps intuitive for testing things doesn’t have the code available. As with Azure DevOps PractiTest is also SaaS only, with multiple data centers for regional data compliance. As there is always inertia towards a commodity it won’t be long before there is no good arguments to have test management tools on-Premise and for the tool vendors to provide the compliance certificates (ISO/SOC really should be sufficient, IMO).
Out of the box PractiTest supports the categories of testing above (engineered, scripted, exploratory) and has the necessary integrations too: Surefire for unit testing, Maven for CI/CD, Jira, ServiceNow or any other ITSM for requirement input. There is even a two way integration to Azue DevOps. As the web design is “responsive” it could probably run off a tablet. That would enable easier test documentation for field tests. It would be even better to have a small version of it on a phone and be able to use the camera for “screen shots”.
And I need
to own the data around all of this, if I want to in in charge of the testing
(and not only the testers). We are very few software testing specialists on the
project team, but as the manager of testing I need to cover many other people
performing the testing. This transforms my role from test management to one
about leadership, coaching, and facilitation of testing being performed by the
SMEs – and anyone else really.
It’s really that simple, yet awesomely profound. And a typical Gerald Weinbergquote, like my other favorites of his points:
No matter how it looks at first, it’s always a people problem (The second law of consulting)
You’ll never accomplish anything if you care who gets the credit
Things are the way they are because they got that way
Quality is value to some person
Regarding the last quote; which was later extended with “who matters, at some time” by Bach, Bolton. Once I had an argument about how to deliver quality. The other side held towards IEEE definition of delivering the expected. But even when he did, he failed to see that the unmeasured and irrational parts affected the value to the customer. I agree completely with The Cowboy Tester that knowing works of Weinberg is a measure of seriousness.
For many of us learning whether or not you know about @JerryWeinberg is a kpi for how serious you are about testing as a career and craft. You don’t have to agree with him, but you should know him.
Weinberg worked not only with testing, but among other things also consulting and organisational change management. I did not know that when reading “Making Sense of Change Management” (Cameron & Green 2012). I literally jumped up and started laughing while reading the quite serious elaborations to the Satir Change model – the authors found that Quality Software Management: Anticipating Change (1997) is a “masterly book on change, but with a title that might not appeal to everyone“. It might not appeal to change scholars, but definitely appealed indirectly to a lot of people in testing.
Recently (August 2018) Jerry died aged 84. Not a boss – yet a leader.
Less Test Managers and more coaches. That’s how I see it going.
Fittingly as he inspired the first post with his talk “How I Lost My Job As a Test Manager” presented at Test Bash 2015. This post is a further elaboration of the Shift-Coach test management trend. Here are some of my experiences:
I have been assigned to an agile development team to introduce them to 3 Amigos, Test data driven test automation and such things. The purpose of my involvement was to enable the team to continue the practices without me, and without testers besides the business analyst / product owner (See The domain expert is the tester) as they are doing Shift-left. Similar to an agile or scrum coach, my approach was to look at it as a change in the way of working.
Another project is an infrastructure project, there are no testers only technicians configuring Cisco routers that by software can replace firewalls, iron ports, VM servers and other network equipment. The project has to implement 80+ of these, so I setup both a test process and an ITIL change request process acting as a test and release manager – another quite frequent trend. I could continue in the project for the duration, but instead I setup guidance and leave when it’s sufficiently in place.
This might be similar to a test architect, a (internal) test consultant activity. It has nothing to do with diminishing testing. Rather I see it as more testing happening, something that would not have been done without the coaching from a test manager. It’s all about finding a test approach that is fit for the context.
The competence of the test coach is to have enough change management expertise (people skills) and test management expertise (domain skills) to know how to coach and facilitate the change. Should test coaches test too, perhaps when required, but not necessarily. The activity is primarily to up-skill the team to continue on their own.
The “Test Coach” is a trend similar to “shift-left” and all the other shifts in testing and test management. I see it as a pattern, and what I read from the threads and discussions is that many test managers gradually shift towards test coaches.
I honor of the World Autism Awareness Day 2017: I have reward systems for myself and my two sons with autism. The principles are as follows:
Reward the behavior we want more of. Don’t reward required activities, but reward when we choose to do help with chores. Ignore when we choose not to, do not remove credits.
Rewards are things you would not get otherwise. Verbal praise and encouragement are given even so. You have to earn it – and get it when you finalize (a deal is a deal).
We use token economy and postponed gratification. Training for the mash mellow test improves forward thinking.
Rewards are usually LEGO. Specific piece request from Bricklink. Every token/mark is a ten’er (DKR 10).
The boys (13+11) have been rewarded for doing the dishes, preparing food, taking out the garbage etc. Initially 15 tokens gave a trip to McDonalds, but as mastering progressed the rewards became bigger. One time 50 tokens/marks was needed for a reward. The options to help (“The Mark Menu”) was at one point over 20 chores. Over time they lost interest in saving but did the chores anyway, so some of the chores where made required. One day the oldest added “Do not fight” to the list of required (non-rewarding) activities 😉 Next up is to save for a game on Steam..
I’m being rewarded every time I run (5K, outside. Half a mark for treadmill), for my morning exercises and a few other thing I struggle with. I have just finished a sheet of 140 marks that I worked on since September 2016). The new target is to buy myself first a Bugatti and then a McLaren. Not a new minivan..
Shift-Deliver is a label I choose to put on the changes the roles and activities of the TEST MANAGER, when the test manager moves towards (also) being involved in the ITIL change requests, delivery management, configuration management and branch management that happens when the solution goes from the test phase to production. Another label could be “TestOps” as presented here, as the intersection of Testing and Operations. TestOps have been identified for along time. ….Interesting. 🙂
In my IT outsourcing context, this is less about software, and more about solutions. In at least two of my long term enterprise scale projects, half the job was test management (of operations) projects, half the job was regarding ITIL change management. My change management activities was mostly making sure that
the process was followed
that information was provided to the stakeholders
that testing happened
risk mitigation happened
I was hired as “the quality guy”, but expanded the role over the time I’ve been on the team to take ownership of all of our build and release infrastructure as well. Basically, I’m responsible for everything from the moment code is checked in, until it hits our production servers
To use a quote by Alan Page. Again Alan is a representative of what happens with regards to trends in testing. He might be wrong, as well as I. I try to label the trends to understand them. These four trends that I have spotted are not mutually exclusive, neither do they all four need directions. Change is happening to the classic test manager rolle of going through the motions of test cases and documents. This is clear when looking into these posts:
The ground breaker for this trend, is to me, the talk “How I Lost My Job As a Test Manager” presented at Test Bash 2015 by Stephen Janaway. Stephen explains how reorganization of the test manager role forced him to be more a facilitator than embedded in the teams. Similarly many other great test managers talk more and more about people skills and coaching, especially in agile projects. I want to define shift-coach around the facilitation testing activities, and place testers that doubles as scrum masters in the Shift-Deliver trend.
In traditional (v-model) projects testing has often included people that were not professional testers; – in user acceptance tests this has often been business subject matter experts. The testing was done by someone with the best knowledge of the topic, and that may not have been the professional tester. That more and more projects do this – more and more, is a big challenge for many testing folks. But it is a significant trend in testing world of 2016.
You’ve heard the rumors, and you’ve seen it happen. An organization or development team decides they don’t need testers, and you have big questions and massive concerns. Is quality not important anymore? Are they irresponsible or idiotic? Are their hats on too tight? Do testers still have jobs?
Alan Page is a career tester who has not only gone through the “no-tester” transition, he’s taking it head on and embracing it. Alan will share experiences, stories, strategies, and tactics (and failures) on how he’s taken everything he’s learned in over twenty years of software testing, and used those skills to have an impact on software engineering teams at Microsoft. Whether you’re going through this transition yourself, think it may be coming, or just want to tell someone what an absurd idea this is, this is the talk for you.