Chapter 3: Focus on the Product and not on the Role

I learnt this aspect from a video on Google’s testing process. From the video, it has been embedded in my head that only thing that is important about any software is its appreciation by the end-users. Like any other engineering product, any software should make life simpler for the end-user. The end-user only cares for this aspect and does not care who in the organization made this happen and who contributed to compromise on this aspect. So, it is important for every department in any organization to have a single point agenda to make life simpler for the end-user.

On joining the team, I found that IT QA was a very hard-working team. However, they were treated as the dumbest department in the IT. This was not unusual as in any organization as it is always perceived that the most intelligent resources are engaged in the development unit and the hardest working people are involved in the operations unit. However, the fact is that the resources in QA need matching the brains of the development team and the brawn of the operations team and thus should have a combination of both aspects. The Mobily IT QA had both the brains and brawn needed for being a great utility for the organization. However, they were the most abused department as it was the most convenient point for attributing a failure. If a product failed or did some nonsense, the Operations would blame the IT QA for inadequate testing and Development would blame IT QA for not bringing the aspect of failure to attention earlier. Development never focused on the fact that they are expected to produce quality product and thus it should hurt their pride if bugs surface in their produce. Similarly, Operations never focused on the fact that given any circumstance, they needed having processes and workarounds to be deal with the situation before it resulted in a mess.

The first thing I did at the beginning of the year 2012 was to send New Year Greetings to the team urging them to forget about any negatives and ignore any perceptions and align for one and only one goal. The goal was that we, as a department, need focusing on only one aspect and that is that the end-users of Mobily products must have the best experience with our products and nothing in the world would deter us from achieving this goal. If a product experience caused concerns to any customer, whether internal or external to the organization, we would record the same as a failure on our department. We were practical and only included the products and systems where IT QA was involved in testing as our focus area.

Given the velocity required of Mobily IT (over 800 projects planned for 2012), it was necessary for IT QA to be able to catch the defects early in the SDLC to be able to decrease the volume of tests needed conducting. This was easier said than done. The first impediment was that not all requirements were documented. Most testing requirements were conveyed verbally with specifics of what IT QA needed testing. Doing so, we could never prove our role, as IT Development would only suggest testing for what they perceived as required. They would not have the same global consideration like a testing function. We took a strategy for improving the quantity and quality of requirement documentation by softly making known this issue to the top most people of the Mobily IT. This helped partly as the quantity of the requirement specifications increased marginally. However, having the documentation was not enough as unless it could be analysed destructively, we could not find flaws and thus we could not cut test requirements. To be able to analyse the requirement documents and the design documents created from the requirement documents, we needed the knowledge of the products and the systems across the entire team.

To increase the knowledge across the team, we had to look up to the IT Development Teams. This meant that we would need their time, which was not always available. So, we had to do this internally. We planned that every week one person would give knowledge about one aspect of one product or one system to the entire IT QA Team. It was made mandatory for the entire team to attend these sessions. Further, providing these lectures were added as a KPI for every Team Member and for every Team. To start this program, I held the first session on NRTRDE. I was pleasantly surprised that not many people knew about this system. Also, I was surprised by the enthusiasm the session generated.

The following weeks, we had regular sessions and we were never challenged in finding a speaker. We soon found that there was enormous knowledge available within the IT QA. The only problem was that the knowledge was segmented. The team members in the Consumer product testing group did not know about the products and systems of the Corporate products and vice versa. Similarly, except team members of the Transformation Teams, nobody knew about the upcoming changes to the IT Stack. All team members knew about the regular channels of service delivery and only the e-Business team knew about the e-channels. So, these sessions were proving to be very useful. The team members were also clearly enjoying themselves as they were discovering many things whose existence they never knew about.

We conducted the sessions on every Wednesday between 9:00-10:00 AM (KSA Time) and no IT QA Team Member was allowed to be engaged in any other activity during this period. Syed Naeem did a very fine job of coordinating these sessions from Riyadh. Venkojee did a great job of collecting the team members in the MIT. We connected through video conferencing between the two sites. This also proved a great opportunity for team members to get to see their counterparts across the 2 sites. This was especially good for the Lady team members working out of Bangalore, as they never get an opportunity to come to Riyadh and interact with the team in Riyadh. The sessions in Riyadh was followed by a breakfast before we launched ourselves to the Business As Usual (BAU).

Towards the end of March2012, it became possible for IT QA to announce that IT QA would provide for Requirement Review and Design Review as a service in a limited quantity. We soon found that we were producing useful reviews and it was helping the IT Development Teams. However, this service could not live its life during 2012 as we were flooded with projects and soon could not find time for this aspect. It can be argued whether I should have persisted with this as this could have possibly reduced the volume of test and thus allowed us a better platform to meet the demand. However, I focused on Risk Based Testing and compromised on this aspect, as my calculation was that the team needs further maturing in knowledge to fully take advantage of this aspect of Quality Assurance.

However, we did not loose focus on the product. We decided to enhance our pro-active testing ability. So, we added weekly regression runs for the e-Portal Application and BMS (our alternate CRM) and Oracle BRM (our Billing and Charging system). E-Portal regression runs would test most part of the IT solution stack, as the transactions needed flowing through most parts of the IT solution stack. Similar, was the case with BMS. However, BMS was primarily a query system as most transactions were done through Siebel CRM. The biggest gain was achieved from the BRM weekly regression runs. We focused only on checking for the charging scenarios, as other transactions would get tested through the Siebel Regression Runs and the e-Portal Regression Runs. The BRM regression runs were extended with quality control of the Bill Runs.

Prior to every bill run, IT QA was involved in conducting tests for checking for the appropriateness of the generated invoices. As it was not possible to test for invoices from all the different combinations of customer segments and products, it was decided to create a control group. The control group would focus on the most important packages and customer segments for the month and through a program, we extracted a reasonable number of customer accounts whose invoices would be validated end-to-end. This exercise proved very useful as the number of billing issues reduced. The reduction in billing issues was due to multiple improvements from IT Development and IT Operations. However, the role of IT QA cannot be marginalized in this aspect.

In 2012, we did not quite meet what we planned to improve the customer experience with Mobily products. However, we have embarked on the journey in earnest. With this focus being firm, it will not be long before we meet a reasonable level of satisfaction from our work.

English: QA
English: QA (Photo credit: Wikipedia)
Advertisements

This site uses Akismet to reduce spam. Learn how your comment data is processed.