As an experienced “functional test manager” I was offered an assignment as a test manager for an operations manager company,an infrastructure testing task testing the build of a new platform for one of their customers. No doubt, this was out of my technical comfort zone. Should I dare to say Yes?
Working As A Test Manager
As you have probably already guessed, I took on the challenge, or else this story would have ended here. As a functional test manager, you still have to deal with technical issues. You come across test environments that do not work, firewall openings that should be open, but isn’t, integrating systems that don’t connect etc. You still don’t need to have a lot of in depth knowledge about the technical aspect of the system. A little knowledge goes a looong way. And for the rest? You just go to the “technical people” and ask them to fix the problem so you can start testing.
I think I am not the only one having considered the technical aspect, the infrastructure, to be at least somewhat out of scope. It was mostly a matter of choice, perhaps, because it was a threshold for me to understand. I sort of set an invisible line. “I can go this far, but no further. That will be too complicated. Too technical”. So one of the reasons for me to take on this challenge was to take this opportunity to learn more about infrastructure and infrastructure testing. And since everyone in the project knew that I wasn’t “a techy”, I was allowed to ask all the “silly questions”. And I made sure to take advantage of that!
I would like to share one challenge I faced, and give a few tips that you can do in your own projects.
One of the first things I discovered in my new project was that the test terminology was created for the software development phase. The software development phase is the phase that comes after the phase that where we were living in. So we had to start with redefining the test terminology. What is the system test for us? What is system integration test for us? And the attached image is what we came up with
In the figure above, the red boxes are my project’s activities, the grey box is the installation of application components from the developers, and the green box is the acceptance test from the customer. There might not be much revolutionary here, but some might have to think twice about the distinction between system test and system integration test in our case. The reason for this is that for us, the system test will contain test of interfaces with integrating systems (checking that the system reaches other systems IP addresses), which normally is part of the system integration test. For us it was part of setting up the system according to specifications. The next step for us was to verify that the new platform still worked with the application layer. That became our system integration test. We integrated our system, the infrastructure layer, with the application layer.
What can YOU do?
Even though you might not have the interest or opportunity to go “all in” like I did, there are still things you could do to make your day easier.
1.If there are problems that are recurring release after release, consider if there is anything you can do to help. Can you sit down with the “technical people” to look at checklists or routines in order to better coordinate everyone’s needs?
2. If test environments often are delayed, can you attend some of the status meetings of the technical team, to get an earlier indication of such delays, and adjust your activities accordingly?
If there are technical areas that tend to have problems more often than others do, I’m sure that the people working with it will be happy to tell you about their area of expertise if you ask them. You might find it helpful to understand more about it. Maybe they need help to escalate something. Then you might be able provide that help by letting the right people know it affects testing and time-to-market.
