Is manual testing very easy? A comparison…

Lately there was a question on LinkedIn, is manual testing very easy?

My answer in short was that it depends on you and your skills.

Inspired by the blog from Michael Bolton about “Counting the wagons”, I came to a an analogy that might be fitting here.

Testing is like moving a vehicle. It depends on your skills if it is easy, challenging or impossible.

The software is the vehicle, so imagine everything from skateboard, bicycle, motorcycle, cars, transporters, trucks, helicopter, plane, boat, cruise ship to a spaceship. To bring in some variance, old models, contemporary models, completely new designs, from broken to running fine.

The test assignment can be anything from check if its running, check some particular functionality, like breaks, running errands with or without a shopping list, driving from A to B, with or without a map, discover new spaces.

The environment for your software is anything from prototype to mass-software, so from first tests in the simulator, driving on a test or empty race track to driving downtown Beijing in rush-hour.

For reporting your drive-out you might have only your brain, a co-pilot who tracks things on a map, a black box, onboard video, radar.

If the damn thing breaks down, do you hand it over to the mechanic/engineer, “this is broken”, do you look under the hood and tell him, you think that something with the turbo is wrong, when you go from 80 to 100, or you deconstruct the thing to tell him, where the issue is.

For coaching/managing do you have a co-pilot, an instructor, a fleet manager, a customer (e.g. taxi), or simply a boss telling you to get the job done. Or are you working on your own, just for fun. Driving around with some friends.

So if testing is easy for you depends on your skills, your experience and how fast you learn and adapt.

Advertisement

Looking for a mentor

I’m looking for a mentor in testing now for about a decade. I finally found one…

In the beginning of my career I shared the same situation with most coworkers. We were transferred from a development/consulting department to the test department, which was a promising business for my former company back then. We had three big test projects in parallel. With big I mean 50+ people assigned to the testing part of the projects. So every department/team that was not so successful became transferred to test, due to the high need of people. That was my start in testing.
But everybody in my new team was also coming from a development background, so we learned only the testing basics that were taught back then in ISEB test foundation and the rules that were set up by the more experienced colleagues. They were not good testers (at least not in my current view), but good managers for (test) projects of that size. What I learned best in the first five years, was mostly managing. I was managing my 3-man-team, supported my team lead for a 10-15-man-team, and excelled in leading a team in big test scenarios covering the complete system stack for phases of ~2 weeks.

When I finally became a test manager back then, I had a mentor in the first couple of months pushing me to become a good test manager. But my mentor left the project and I was there on my own again. The following 4 years, I was a coach for new test managers, the go-to-guy for nearly the complete project and also some other departments we were working with and even the customer. But no one was there to guide me, no one to challenge me, but myself. Nearly 10 years in testing and managing and no I idea what I was doing, because I was not really that good, better than many others maybe, but not good.

What I realized only over the last year is what my problem was. I was a more or less context-driven tester and test manager, loving to explore, learning, adapting to the current situation, caught in the processes and demands of a 50-70 people test factory. I was not able to understand that problem, and why I was mostly frustrated for the last two to three years in that project. And the ancient processes forbid to act context-driven. And if it wasn’t the process, then it was the team that refused to change. So I finally left.

With my new job I came back to testing, and I caught the fire. I love to test. I’m not an expert or even remarkable at it, but I work on it consciously and consistently.
But again, no one in sight to learn from, at least not testing. I have several good colleagues, all of them across the ocean. The test team in Europe is me and about two to seven team members, rookies or beginners, needing guidance themselves. Again, no mentor left for me.

But I finally found my mentor. Me! I define, where I want to go, what to learn next, where I want to get better. I take my sources for improvement from the community. Anything that is shared in my timeline on Twitter I scan for interesting discussions, blogs, books and videos. There are of course several people to look up to, people of inspiration. I would love to have some budget to visit a conference, to meet some of them in person, or take the RST, or having time to take the BBST.
I found out, in the end you need to be your own mentor. Kick your own butt to learn and get better at what you do. Colleagues, coaches and mentors will help you with that, but when it comes to find and walk your way, you are on your own.

I envy companies like Moolya or the Barclays GTC or the awesome PerScholas project, because they have great people there to look up to, to follow after. But in the end, even they need to find their own way. Even those mentors can only show you the rough direction where the path is or how it might be looking like. You need to walk the path alone. If you have the chance to interact with the community or friends or colleagues, you have (changing) company on the way, helping you, pushing you forward, making it easier. But you still need to do the walking on your own.

The CDT community empowers me to be my own mentor, finding a way to define myself. I’m only at the beginning of that way, but finally I have at least the feeling to be on my way.