The 6 Cs Model for Planning a Rewarding Day for Testers

What can make a typical day at work, a rewarding day?

This question came up when recently I was running a pair testing session with some Dev / QA team members. During the peer review of one of the bug reports, we realized that the bug report ‘may not be entertained sincerely’ and hence it needs to be improved.

This realization triggered a bug report cleanup session and in the next twenty minutes, we prepared two improved versions of the original bug report. Only one of them won the (virtual) ‘Report in the Bug Tracking Tool’ competition. That was a sincere conversation around bug reporting heuristics, dev/test relationships, competency, and other factors. The session helped all of us in building a stronger relationship and put aside our egos, to achieve a common goal.

Lessons Learned: A Peer Review session is useful. You learn something new, always all the time. I learned not to lose curiosity and the benefits of listening to people from different technical & experience backgrounds.

So, coming to the question - What could be those rewards (feeling) factors?

Now ‘What can make a typical day at work, a rewarding day?’ seems to be a very general question and there should be (and there are!) so many answers (Individual and team level) to this question. See some examples below (from my experience)

• The team reported 20+ bugs today and 30% of those fall in S1-S2. Fixing those S1-S2 will save $2,500 for our new customer. Joy and Impact!
• Mr. efficient tester has tested a new application today and summarized it well in just two hours. Efficiency!
• Test management was done very well, and we got a pat on the back. Appreciation!
• The release went well and the customer engaged us into a new testing assignment. Growth!
• Mr. competent tester learned/created a new tool in excel that can help us in checking complex calculations. Competency!
• I explained the product and found critical areas of improvement in UX and the PO accepted those and backlog is re-prioritized accordingly. Credibility!
• The client sent a monetary reward for the bugs we reported and helped them avoid a release day embarrassment. Monetary Rewards!
• The client appreciated our efforts and gave more autonomy to testing. Feeling Important!

I congratulate you, if you are reading this and if you have ever asked this 'Reward' question to yourself / your teams and your answers were different and way deeper than these sample answers. Context, culture, and maturity level varies and hence the answers to this same question as well.

What I concluded in the next 20-30 minutes: Question reframing and the next set of questions

So, I think it is not unsafe to assume that feeling of joy, impact, excitement, appreciations, growth, feeling important and some other subjective/objective results have the potential to make someone feel a typical workday as a rewarding day.

But is this joy, appreciation or growth, or whatever, is just day to day based? Shouldn’t it be planned in better ways? How to plan typical days such that it becomes a rewarding day almost all the time?

The answer cannot be NO and I decided to work on finding some answer(s). But I thought that the original question needs a cleanup ??

So, what makes a day rewarding could be reframed as ‘What framework of actions should I systematically build so that I have choices to decide if my day was a rewarding one or not?’ The reframing seems useful, and it allowed further questions to emerge, such that…

• How can I be more useful and contribute better?
• How can teams help each other in becoming more effective, efficient, and teamwork focused testers such that, each day we test better?
• How can we coach each other such that we identify the value and work on that value realization and feel good about the job that we do?
•  How can we help someone understanding (better than someone knows today) the software testing and the challenges & opportunities that it offers?
• How can I help someone by encouraging them to ask the above four questions to themselves and find answers and do a self-assessment?
• What further questions can / should be added to make our days more rewarding?

The 6 Cs model, as I think of it

These handfuls of counter questions made me realized that maybe we all, already have a model in our head that can easily answer those questions. Those answers are nothing BUT the commitments that we need to make to ourselves as testing professionals. This model seems to be just so common knowledge-based that I am assuming that everyone practices it implicitly.

Still, I wanted to draft a representation (the one that I have in my head) out and wanted to see that if it makes sense to explicate this model? For this article, I narrowed down the scope and I chose ‘Testing and Bug Reporting’ to start a discussion on this model's implementation value. I do not think that it tries to prove or establish anything. I am not even talking about productivity improvements here. It seems to be very basic.

 Here we go

My theory of this implicit model goes like this as far day to day testing and bug reporting related activities are concerned.

At the core, my competency helps me in making decisions about my commitments for the day. My commitments allow me in performing the important testing activities and produce results that matter. When I courageously communicate the results or work products to the internal/external stakeholders, I target to achieve credibility and hence compatibility with the stakeholders.

This resultant compatibility helps me building better competency and then the cycle goes on.

Words have similar words: Meaning & Significance is up-to Human testers and their context

Below are the images captured from my google search efforts. I found the ‘Similar’ feature of google search results very helpful for me as far as this model’s explication attempt is concerned. There is a reason that I gave a snapshot of multiple similar meanings of the 6 Cs. The reason is that on a typical day I change different testing hats. Each “C” takes a different priority, sense of involvement, learning, and performance sensitivity.

Based on my hands-on testing context and experience, I highlighted those helpful similar words that I think are well known to me. If you have come so far, thank you for your time and patience. I stop here and I let you feel free to look at each snapshot and plan for the action items that you can /should take and build expertise on those (If Applicable).