Over the last year I have looking to work myself out of the test manager role and into a more advisory role. And by April 2021 I was given the formal title change from Senior Test Manager to Senior Advisory Consultant.
I have had the title “Test manager” probably since 2008, so it’s been a while. In the companies, where I have been employed, the Test manager title has never been with line management (hire/fire). Rather it has been similar to a project manager, with a focus on the testing deliveries of a project, release or program.
I will still be leading test activities, but my role for the future will be more about enabling someone else doing the testing or someone else having a testing problem to solve. There are plenty of test activities done by people in non-testing roles – it’s the activity that matters.
17yo: Dad, do you not know how old I am - and what I can do myself?
Me: Oh, I know buddy. As you are learning new stuff, I am unlearning to help you
While this quote from my kitchen about a week ago, as all to do with the young man learning the ropes of life and me unlearning to always to help them and their 15yo sibling out – there is an key parallel to leadership and building self reliance in teams. My role these days are less about direction and (micro)managing a team of testers on a project, more about enabling others to succeed with their testing both in the delivery teams and in the board room.
When testers talk about SUT (System Under Test) there seem to be an implied context of it being software, developed, bespoke software to be specific. Let me broaden the notion of a SUT using Wardley Mapsand with that illustrate how testing can add value across the board.
Bespoke software (aka Custom built) is where the solution (SUT) is built and maintained tailormade to a specific company by a specific team that answers to order giver. When you build and maintain an app or web site for a company and is embedded in the team delivering the code base – it’s usually in a bespoke context.
Experiment/emerging example: Built an internal web site to do some simple public service case management. Write it based on MicroSoft .Net and IIS technology. The solution is new and novel, so interaction with the user is important.
All the commotion on buiding MVP experiments and interaction with the Product Owner are usual symptoms of a genesis situation. As the processes mature and products emerge, the solution development becomes more an customization activity.
Customization example: Implement Dynamics 365, SiteCore, SalesForce etc – but taylor and code them to your specific purpose. I have worked in a project taking Dynamics 365O and creating custom forms to handle public sector health events.
The last class of software “development” is the pureplay configurations of standard solutions. This is the context of SaaS – pay the license and get started. Think SAP or Office Applications, anything that is so accepted that it’s almost free (OpenOffice) and kills the IT department.
Let me draw this on the axis of Wardley Maps Evolutions:
Similarly we can add the underlying infrastructure to the drawing. As solutions move to the cloud and infrastructure becomes code, the system under test could very well be code around infrastructure. Initially bespoke infrastructure experiments (in perl?), and as time moves – even infrastructure becomes a commodity in the form of Amazon S3.
So where is your SUT? – what is the path down the stack? Because there is a huge difference between testing custom code for cloud services, as compared to product customization on actual physical owned hardware.
Let’s think testing outside the bespoke areas on the map too. Some current examples I am working on are:
Infrastructure transition of 700 serves from being owned to being hosted
Application transition of 50+ applications from being owned to being outsourced
Transformation of a standard form management solution
Implementing a standard system for ITIL case management
These projects have no code, the SUT is either a server, an environment (collection of servers), a form, a process or something else. While we do know a lot about testing in bespoke software contexts, the practices for testing in transition and transformation are emerging practices! This gives us and extra layer. And this is where it gets interesting.
There are plenty of standard practices (SAFe, agile..) but the practices for testing in the context of transition is yet to materialize.
The same model can be applied to IT as a whole. IT support and end user computing (devices, desktop operation) are to the very far right as commodity services. While on the far left is the constant experimentation and tinkering (of AI, ML and RPA) to become actual products.
If we only see testing as part of building bespoke software we fail – we fail to see the horizontal and vertical contexts, where the testing disciplines can add similar value and impact.
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:
One of the ways I lead the team of testers in my project is through delegation of power from my own role…
1) A test manager in my group asks guidance. The members in the project team does not reply the requests or give them the information they need. As a test manager in the project they don’t have the theoretic power, but not the practical power… I send them back with all my powers – to tell them that because I said so, they should be respectfull. I don’t mind taking “stars” of my shoulders and giving the power of my role and position to someone junior to me.
2) A tester on my project team approaches me to ask for permission to create tasks on our task board. I immediately grant them a “do every thing you need to do, without asking“-permission. By all means take the initiative and ownership. I probably fail to manage everything, so we need to work together on this. By all means go ask the developer, create test cases, find things we didn’t know – think.. and test.
Sometimes I think, this is perhaps a Danish “equality” culture – but then I realize it is a collaborate approach for the modern knowledge worker. It works equally well with people from both India, Denmark, Philippines and China.
My style is not to CONTROL – but to facilitate KNOWLEDGE. In my team the team is the star…
Not all my projects are thundering successes… Different early decisions have set the scene – but still the play, so to speak, Â have been full of lessons in what testers find – when asked open questions:
A team had previously synchronized information in the old context, so they where invited to test the new solution… which turned out would eliminate the need for synchronization. but nobody had troubled them to tell them so.
That the development team was not acting agile, sprints and scrums in words only
That the biggest PBI (product backlog item) in hours, actually was to get GUI automation of modal-windows to work.
That despite having a requirements sheet, the actual value of the sheet was zilch
That despite putting in extra hours and overtime, the quality and stability of the delivered did not improve
That the biggest problem towards integration was problems between .Net and java implementation of SOAP
That simple requirements on virus scanning documents, was both hard and expensive to solve
That part of the project deliveries was upgraded business guides, when tested they needed corrections too
Calling them all defects or even software bugs, does sound odd to me, because those that really take time is not the software issue it self, but misunderstandings and due to not knowing everything (will we ever). Standards tell you that testing finds risks in the Product, the Process and the Project – it seems to me even more we find issues in management decisions, architecture decisions, cultural issues, organisational change… it’s just software but it does have a business impact.
Remember how the brain reorganized itâs neurons when information stopped coming in? Just because the âwiringâ is fixed and the information flow is restarted doesnât mean that the brain will start listening! Second, the brainsâ map of sensory information coming from the hand has been distorted, and the brain will have to relearn the hand-map again.
Itâs very much like a management board having to learn how to include information they havenât had for a while, in their decision making.
Complexity is a Matter of Perspective 