This is my own version of Lesson Learned in Software Testing
I am a huge fan of James Bach, a software tester who has a very humble profile and well respected in the industry. His voices are sharp in the testing world. He criticizes many things that we the tester sometimes misunderstood. He is the one of virtually convinced me to take my first job as a software tester (I was a software developer before my job as a software tester). He and some fellow testers are publishing a very nice book called Lesson Learned in Software Testing and they called their approach as context-driven approach. I am adopting some of their approach to software testing, and learn many things from their book. In that book, they provide me with some lessons in which they learned throughout their career in software testing. In several articles, I will create my own version of Lesson Learned in Software Testing.
Lesson 1: You are the headlights of the project
I was read that part from their book a day before I had a dinner with newly formed QA team in our company and the CEO of the company. It was a nice dinner. We are only 3 people in QA team, and this dinner is especially held for our new member who just enter his 4th day in the company. I am quite passive in that discussion because I have my boss beside the CEO and I don't have right to put our opinion in that discussion except for some degree. Eventually, I got a chance to speak up about my own opinion. And a big voice inside my head is resonating and I remember about a very wise word "Our responsibility as software tester is like a headlight for the team". So, I said to them "In my opinion, my responsibility is like a headlight for the team, to make it clear for the team about the state of the product". At that time, I don't think every people would understand what I meant, but the CEO said that he like my example of headlight and adding more practical example. He said "I like that example of headlight. You know, when we are driving with headlight turn offed, we are slower, that's happen with our development team too. When we are leaving the customer experienced and facing our bug, and they report a bug, we need to immediately fix the bug, because it affects our customer. So, the team would need a context switching from developing a feature to immediately fixing the bug. That's make our development slower. That's context switching makes the development slower. And when we have a (red: good) QA (red: tester), our light on, and we can drive faster.
I was surprised. I don't think that would be understandable even by my fellow QAs, but the CEO got it, and I loved that it happens. What I love is now I, the team, and the CEO (top management) know how its like to be a tester and what to expect. Now, I know the CEO's expectations better.
More than that, I am feeling happy to know what is headlight matters for him. Now, I purposefully become the headlight of the company and the company purposefully understand that they have a headlight on their toolkit and more importantly how to use it well.
