In today’s article, I am going to share some thoughts on what I believe the clients are REALLY expecting from us based on my first-hand experience working at client locations with daily face-to-face interactions and collaborating offshore via emails or phone calls.
IT services are an important and integral part of the software industry and customer satisfaction is important to succeed. Each client/organization may be different in their process may follow different protocol, and may deal with different type of businesses.
But, the following factors are common and matter to everyone in general.
What You Will Learn:
5 Things that Client Expect From Software Testers:
#1) Cost Benefit
When you think of selling or buying something, cost plays a major role and it is often one of the important deciding factors. Don’t we all eagerly wait for Black Friday, Flipkart Billion Day sale or Amazon’s great shopping festival? We become crazy buyers during sale time. It is a simple human behavior to expect the right or extra worth for our money.
Companies and customers are not different. Cost benefits boost customer-service relations and it is not uncommon for service companies to lose bids due to lower quoting competitors.
The BIG question now is: How can we show cost benefits to our customers?
These points can help:
- Show them their money’s worth. Justify and provide supporting evidences for your estimates.
- Think of creative ways to save on expenditures.
- Tailor your quote. Instead of sticking to your standard process that costs X amount of money, provide cheaper alternatives. For example: Suggest critical path testing instead of complete system testing.
- Know your competition. A quick reality check of what other service companies are offering their clients at what costs is important to keep your pricing model market relevant.
#2) Quality of Work
Quality and Quantity of work are two very different things.
Gone are the days when the number of test cases created or defects reported used to productivity or quality indicators. Not anymore.
The situation is more like the below image:
A) Know when to say ‘NO’
We all have been in places where we worked overtime, been on call over the weekends, attended late night or early morning calls, etc. However, what we do not realize is that we can say NO if things continue to get worse. Saying NO is the only way we can keep the quality of work and our sanity intact.
When doing so, raise your concern in advance and advocate quality.
Here is a situation I was in and this might give you a better idea of what I am talking about:
My Company won a new logo and as part of migration from an old company to my company, knowledge transfer sessions were planned. We, a team of 6 members traveled to the client site. On the very first day after introduction, we were shared the KT plan. I found my name was tagged against multiple modules. One of those modules should have been totally out of my scope because I wasn’t even aware of that technology; it no way matched to my skills.
I went to the Knowledge transition lead and told him the situation –
- Too many work items were assigned to me, which in turn will hamper quality and my ability to capture 100% in the sessions.
- The planned items had areas where my skills wouldn’t match and since I wasn’t the right fit, I might not understand 100% during the transition.
The lead understood the problem and revised the KT plan.
I hope this helps confirm that: If something is on our plate it does not mean we have to eat it all. Especially not if it means compromising on quality.
B) Test Case Completeness
How many of you agree with me that if we try to improve the way we write test cases, it leads to better quality?
Below are some common mistakes that are common in most test cases:
|Test Case Components||Current Problem||Solution|
|Objective||Objective is the most important part of any test case,this is what makes all test cases different. Common mistakes with Objective is missing clarity. |
Like all test cases created for one functionality has one objective without showing how each test case differs.
|Objective/Purpose of each test case should be clear to explain what functionality and what test condition is going to be tested as part of that test case.
Same functionality can have positive and negative test cases,so objective should be clear enough to show the difference.A good idea is to refer the test scenario for defining objective.
|Pre-Conditions||Many testers totally miss out mentioning the precondition or many will simply copy and paste. Copy pasting leads to errors since each test case might be completely different from another.||Avoid Copy-Paste errors and pay attention to detail.|
|Test Data||This is probably the most overlooked field and most test cases will have it empty or lacking in precise definition||Mention the appropriate data to be entered. Sometimes, it need not be accurate.
For example: User registration can register a user Anna or John and it would not matter. But defining that a valid name that has all characters and should be 4-10 in length can help clarify a lot of things.
|Test Case ID||Over simplified naming or numbering convention. Say, you are testing a login button. Often, the IDs are: |
|Make them more descriptive:
|Reference Documents||Inconsistent Copy-Paste from reference documents or worse, using an incorrect one.||It is always advisable to mention the correct reference document with correct version number, say for some test cases FRS and Tech Specs both would have been referred, so the test case in the reference section should mention both.|
|Test Case Steps||Missing Steps, mostly by testers who know the application very well. They could assume things and skip mentioning the steps. This causes problems to the business, reviewers, and new testers.||Proper steps and sequence should be used.|
To summarize, if small details are taken into consideration in the design phase, the test output quality will be much more superior.
#3) Business Understanding
This is one of the most important factors that customers look for in testers. However, it is sad that some testers believe that their job is to write test cases based on FRS and make no effort to understand the business.
Try to know the business first and then look into functionality; you can envision your client’s needs more and test accordingly.
Here’s an example – FRS states ‘XYZ report should be generated with 3 columns as Date, Name, and Status’. The following are the test cases you will end up with when you take this requirement at its face value:
- Validate report XYZ is generated
- Validate report has 3 columns as Date, Name ,Status
- Validate the data in 3 columns.
But, when you keep the business applicability of this report in mind, you might have to test:
- What is the business purpose of this report?
- Does this report get generated every day?
- Who are the business users looking at this report?
- What is the source of data for this report?
- Should the report be generated if no data is available?
This is just one example, but I guess we all agree that better testing can be achieved by gaining business awareness and expertise.
Whether you are a single individual supporting the customer or a team, your availability should always be checked ().
By availability, it doesn’t mean 24/7 support. It just means clear and upfront communication about time off, alternative plans and being reachable and not going MIA.
Below are some of the models that the services industry follows:
- Staff Augmentation Model – If you are working in a staff augmentation model and are a sole representative from your company it is advisable that the customer is made aware of your work timings and planned absences so that necessary arrangements can be made.
- Managed Projects Model – In a managed project model in which large project teams are formed and headed by delivery/project managers, having a backup resource plan no longer remains the responsibility of customers. PM’s need to manage both planned and unplanned time off’s. In this model, it is advisable that the PM’s try to collect the planned absence data from their team ahead of time and manage accordingly. There are cases where customers request for weekend support or extended work hours. Such cases should also be planned by rotating resources. A team should consist of members who can backup each other if required. The planned details should be shared with the customer.
#5) Scope of Improvement
This is not only desirable in the software industry but everywhere. Bringing improvement is not a one day job. The scope of improvement has to be worked upon continuously and can be divided into 3 steps –
Step #1: Identify
Do a thorough study and identify the areas/scope for improvements. Say, when you are asked to test the same functionality several times using the same process, there will come a time when you will feel that you either want to move out of the project or you change the way it is tested. That’s how improvements are brought in when we are bored of our existing methods, we think of changing and improving.
Step #2: Bring in Improvements
If things were done in a manually you could try to automate few things. When I say automation, it doesn’t always mean buying an automated tool.
I will quote a situation:
I was a part of a database testing team. Our day to day work involved running the same SQL scripts multiple times in a day with a different set of parameters. When we started the project we were fine with these steps but eventually we understood the system better and we thought the same SQL scripts can be run as a part of stored procedures instead of someone manually updating parameters and executing.
Step #3: Evaluate the improvement
Whenever a new process is implemented you will need to ensure that it does work as expected and has no side effects. Extending the earlier example, an introduction of stored procedures, check if the output from the newly created automated way and the output from manual way are the same.
The other part is to monitor the benefits over a period of time to be absolutely sure and present the results to your clients. In our project, we showed the clients a reduction in test execution time by 30% which in turn reduced cost.
In conclusion, I just wanted to mention that each one of us have innate talents and we all have our own unique working styles and these were just some tips that I believe can offer our clients a better service experience.
About the author: This awesome article is written by STH team member Priya R. If you want to write for us and share your experience please let us know here.
Hope you have enjoyed reading this article and found it informative! Let us know if you have a different experience to share.