How asking “Can I do that for myself?” made me more T Shaped
By: Heidi Baker
Tags: Software Development, Software Testing, Testing, Quality Assurance, QA

How asking “Can I do that for myself?” made me more T Shaped Heidi Baker Follow Jun 17 · 3 min read

I am a manual software tester. I will have a go at test automation, but it is out of my comfort zone. So, when my manager wanted my Test Team to become more “T Shaped”, I was anxious. I did not feel I was overly technical, and the idea of me coding was laughable. However, my concept of what “T Shaped” meant in an Agile environment evolved and I realised I was already doing it!

Originally, I believed being “T Shaped” meant I would be cutting code and setting up infrastructure, and while this was partially true, I didn’t believe I could do it until I realised, I was. Meanwhile, I was keen to get self-sufficient as a Tester. I was impatient having to wait on a Developer to deploy code to me, so I asked, “Can I deploy the latest code for myself?” and the answer was “Yes”. We had Continuous Integration and Continuous Delivery infrastructure set up, I just needed to navigate my way around Azure DevOps to initiate deployments myself. I wrote myself some notes, occasionally ran into broken merges or failed builds, but quickly I was in charge of my own release management.

Then we did some projects using Containerization. I still wanted to deploy my own releases, but this suddenly involved spinning up containers using a mix of Docker, PowerShell, Kubernetes and writing settings in YAML files. I resisted at first. These were all daunting, geeky tools. But once again I grew impatient of relying on someone else to be available to do releases for me, so I asked, “Can I deploy the latest code myself?”. I sat with a very patient Infrastructure Engineer who ran me through all the pieces of the puzzle. Once I’d done it once with help, I tried to document the process in a way I could remember, but it did take several sessions and many more questions, before I was confidently deleting containers, changing variables in my YAML file and spinning up new containers with the latest code.

On another occasion I was having to make changes to various settings files within Visual Studio code so that I did not have to rely on a Developer to manipulate my test criteria whilst using a very basic test harness. I was branching, pulling the latest code, making changes, compiling, and then building my own local version of the code just so I could run my tests. While I still had to ask for help occasionally, I think the Developer really appreciated my attempts to learn this new skill and to free up their time, so they were more than happy to get me unstuck.

Often on projects there was no Business Analyst, this was a role I could happily step into to pick up the slack for the team. Understanding legacy software and documenting the client’s requirements was much more my wheelhouse. I would be able to merge my testing skills with my BA skills and prepare User Stories with well-defined acceptance criteria for the team to discuss in sprint planning.

Having a Testers holistic perspective, I could comfortably run client demos when needed, and I had enough experience with technical documents to be able to review, and provide good feedback on Architectural Designs, wireframes and build specs. That is when I realised, I’d become “T Shaped”. In a crisis I could keep some of the cogs turning, I could — with a little guidance — quickly upskill to temporarily fill a gap in the team. This is what being “T Shaped” meant. I felt like a much stronger contributor to the team. I owed all my newfound skills to the team around me, they had taken the time to teach me and answer my questions, when at first it would have been quicker to just do it themselves. Their patience in me resulted in a lot of saved time for them in the long run and gave the whole team a sense of pride and achievement. It is this feeling that ensures I will never stop asking “Can I do that for myself?”.