In my previous post, I emphasized the non-testing activities I do to contribute in my team. Reading it through a day later, I realized it contributes to the idea that many people around me have on not understanding what testing is. When I emphasize the other stuff, I implicitly leave out the testing work other than bringing in the mindset of critical thinking and value-orientation.
I wanted to share a story of how it is important, in my experience, to do hands-on testing and not just hang out and contribute by talking and helping others.
At a point of my career, I was working in a customer-contractor setting in a multimillion project. I was assigned the role of a test manager, which meant a lot of meetings and a mix of planning and testing. As I was on the customer side, I had a tiny part-time acceptance test team to work with, on a huge and very complicated system. After all, this was the last bit of testing after all the contracted layers.
With reading the specifications and trying out a couple of scenarios, we learned that the system could possibly work as specified, but not fulfilling its purpose. It was a data processing system that gathered data from various external sources and put it together to sum up a financial decision, with very complex logic. If the financial decision was incorrect, the system was of little value.
As a test manager, I was at a choice point I did not realize I was at. I implicitly chose to talk with stakeholders more, to find a way to communicate the first lesson and with the context at hand and the structures of the contractor, it was a major effort. While I chose to invest my time on the communication aspect, I chose not to test so much personally. I could not be at two places at once. My tiny part-time team tested and I supported them, but as I was not testing myself, the hands-on testing effort was very small.
I remember many combat-like scenarios of discussions in the various committees with each party finetuning the arguments. But there was no common goal. The contractor goal was to deliver in schedule what had been specified. The fact that specification would be incorrect would not slow down that train that would pay them the money. And there was no better specification - as I learned later, acceptance testers needed to hands on test how the system would behave to know what they needed to specify. One experience in particular was such a scene I still laugh thinking about it: I had two colleagues in test kicked out of a board meeting with a minute warning time because they were employed by other contractors, on the premise of "business secrets" - just as we were working on an expensive decision that would not be as positive for the contractor if the test managers would be included. The politics drained a lot of energy.
Looking back at all that energy, it was wasted. With an explicit decision of myself testing - with little budget on testing, the hands-on empirical information would be more valuable than the politics game. The hands-on empirical info would have helped in transforming the politics into something we could actually act on. I know it would, since someone else, with a different resourcing model, had both parts, and the testing results part changed the game.
The lesson I learned is one that Elisabeth Hendrickson emphasizes with the phrase "Empirical evidence trumps speculation. Every. Single. Time". The real information from testing is important. Theories are only theories. Regardless of the test role I feel I'm assigned to, it's still testing, not theorizing about testing that could be done given enough resources. There's always a choice and it comes down to me making the choice.
I learned to choose to test. Hands-on, yet incomplete is better than the plan and communication. Testing to get actionable examples of things we should know of is valuable and game-changing information in the projects.
That's what I spend most of my time on. Knowing from personal experience what works and what not. All the other stuff I can contribute on in the project comes from that core: disciplined hands-on testing to transform theories into empirical evidence.
I wanted to share a story of how it is important, in my experience, to do hands-on testing and not just hang out and contribute by talking and helping others.
At a point of my career, I was working in a customer-contractor setting in a multimillion project. I was assigned the role of a test manager, which meant a lot of meetings and a mix of planning and testing. As I was on the customer side, I had a tiny part-time acceptance test team to work with, on a huge and very complicated system. After all, this was the last bit of testing after all the contracted layers.
With reading the specifications and trying out a couple of scenarios, we learned that the system could possibly work as specified, but not fulfilling its purpose. It was a data processing system that gathered data from various external sources and put it together to sum up a financial decision, with very complex logic. If the financial decision was incorrect, the system was of little value.
As a test manager, I was at a choice point I did not realize I was at. I implicitly chose to talk with stakeholders more, to find a way to communicate the first lesson and with the context at hand and the structures of the contractor, it was a major effort. While I chose to invest my time on the communication aspect, I chose not to test so much personally. I could not be at two places at once. My tiny part-time team tested and I supported them, but as I was not testing myself, the hands-on testing effort was very small.
I remember many combat-like scenarios of discussions in the various committees with each party finetuning the arguments. But there was no common goal. The contractor goal was to deliver in schedule what had been specified. The fact that specification would be incorrect would not slow down that train that would pay them the money. And there was no better specification - as I learned later, acceptance testers needed to hands on test how the system would behave to know what they needed to specify. One experience in particular was such a scene I still laugh thinking about it: I had two colleagues in test kicked out of a board meeting with a minute warning time because they were employed by other contractors, on the premise of "business secrets" - just as we were working on an expensive decision that would not be as positive for the contractor if the test managers would be included. The politics drained a lot of energy.
Looking back at all that energy, it was wasted. With an explicit decision of myself testing - with little budget on testing, the hands-on empirical information would be more valuable than the politics game. The hands-on empirical info would have helped in transforming the politics into something we could actually act on. I know it would, since someone else, with a different resourcing model, had both parts, and the testing results part changed the game.
The lesson I learned is one that Elisabeth Hendrickson emphasizes with the phrase "Empirical evidence trumps speculation. Every. Single. Time". The real information from testing is important. Theories are only theories. Regardless of the test role I feel I'm assigned to, it's still testing, not theorizing about testing that could be done given enough resources. There's always a choice and it comes down to me making the choice.
I learned to choose to test. Hands-on, yet incomplete is better than the plan and communication. Testing to get actionable examples of things we should know of is valuable and game-changing information in the projects.
That's what I spend most of my time on. Knowing from personal experience what works and what not. All the other stuff I can contribute on in the project comes from that core: disciplined hands-on testing to transform theories into empirical evidence.
