Thursday, August 11, 2016

Finding Allies in Testing

 
Hello World! Hello Friend!
   It
can be a lot to take in when you first move into a new environment, with a new job, and new applications to learn. Some of the basics are the same, but the little things, the details that matter, that do trip up users, are the issues that you need to learn quickly to make headway on any project with longevity.

Maybe you aren't the best tester for that particular product, with a lack of knowledge, but you want to be. How do you get to that point? Reading documentation can get you part of the way, but that can be time consuming and often out-of-date.

How can you get the latest and greatest info, and understand some of the pain-points your app users are going through without necessarily doing an intensive week long training pouring over every inch of GUI and code available? Well, if you have other testers on your team, that could be as easy as doing some pair testing sessions with them to get up-to-speed. If you don't, where could you go then?

Customer Service Reps are an ally

For anyone with a team or even the lone tester, if you don't have deep knowledge of the application, the next stop for you should be your customer service department. Whatever the CS manager will let you sit in on or experience with their CSRs, do it. Plan to shadow calls or chats. Sit in on trainings they have. Talk with feature experts and get their first hand knowledge about the app and about the users.

Not only does this get you valuable information right from the start of any kind of job, this also develops a model of goodwill and trust with the customer service people. This alone is worth it's weight in gold. Having a good reputation with the CS team, means they will communicate with you trends that they see happening with the application, or customer complaints that could give you valuable information when looking at the next feature story or upgrades to an app. If your acceptance criteria could affect things with customer service, having a customer service viewpoint could be invaluable for that feature story. Working on defects becomes much easier having access to the person that wrote the defect and understanding the customer that reported it.

Go out of your way to understand this team and you have created the best ally you can have in the fight to raise the quality of any application.

Professional Trainers are the Front Line

If you are lucky enough to have a customer service team and professional trainers who routinely go into the field and demo your product, or perform the set up, definitely find a few friendly ones that are willing to share their experiences.

Professional trainers could be training users with different parts of the product. Especially areas that deal with billing or finances. They could be doing setup and initial on-boarding for a client that doesn't have the internal structure to train people to use the application they want to use. {Often this happens in the domains of education, health/medicine, logistics,  human resources, finance. There are probably others, but those are the ones I have experience with personally.} Going onsite with a professional trainer can be a wealth of information in observing users and understanding the questions users are asking. Those questions should serve as beacons for testers when looking at usability and accessibility for their users. You also gain first hand information about issues rather than waiting for the first draft of the story or the first draft of the feature code to land on your desk.

In return, fostering a relationship with a professional trainer can give them credibility when they talk about the product with first hand knowledge from the development team. Communicating in an informal way, letting them understand the process the development team is in can give a trainer ways to help work around current issues they might be having with the app. This can also foster a better client relationship for the professional trainer since they can say they know someone on the development team that is willing to listen to issues.

A Story: I once sat in on a professional training session for medical software. They were demonstrating the billing section. I had used the application for a year or so now, and I was one of the main people testing the billing section with the updated reports and transaction logs. I went to the training because it was offered to the company, not just the other trainers, and I thought it would be a good way to get more knowledge about what I was working on as well. During the session, the trainer presented the workflow and I was surprised. How I had been taught internally to use it, wasn't at all the workflow the users were using or the trainers were training. I showed the trainer the workflow I knew  and she indicated users literally couldn't use it that way because they needed to wait for a 3rd party process to happen before they could go to the next part of the workflow. Also, the order of the tabs were not it the process order customers were using, making the workflow even harder for users since they had to wait for this 3rd party acknowledgement to happen. Our internal tool, that mimicked the process of the 3rd party inadvertently caused us to change how we were using the billing section for testing. When I brought this information back, people on the development team were as shocked, if not more so, than I was to discover this issue. They wanted it to be easy to use, and thought it was, but we had made it harder without realizing it. Doing the professional training suddenly became a value add and more people were encouraged to go to the next one.

Product Management/ Product Development are Natural Advocates

 I haven't worked a job yet where the product management team, along with business analysts and product development folks, {or whatever flavor you have driving your development cycles} lacked a deep product knowledge and customer understanding. This knowledge is absolutely valuable and when you are on any project, and some of the best, most immediate answers to questions usually come from this team of people doing market research and study. They hope that decisions they are making will further the future of the product and be profitable. They often comb through defects, understand what usability problems plague users {and already have ideas to fix them}, while maintaining a high level knowledge of the tech stack and talent pool they are working with. I have personally worked as a business analyst for a week, writing up two stories, researching issues that might come up and then dealing with all the questions and acceptance demos that resulted once those stories made it to the pipeline.

Another Story: I will never, ever say product development or business analyst job is easy work. First of all, you have to be able to write effectively, communicate with developers and management on two different levels, and think about how to resolve problems that come up during the development cycle. And if your solution wasn't correct, you have to own that too. I once covered a BA's vacation. I created two stories, based on defects we had in the backlog. I wrote the acceptance criteria and even created some screen shots about how I thought the UI should change to fix those issues. I'd been doing QA for about four years now and thought about switching to the BA position because I can write pretty well and communicate well. And it seemed like a way to add another level to my ever growing skill set.  Writing the stories was the easy part, and that was still pretty complicated. They were reviewed and PDs asked questions about my requirements and acceptance criteria. Both stories went through several revisions. But once they were done, the real work started. It took about three weeks before they ended up in the development pipeline. I was responsible for seeing these two very small defect fixes through to deployment. I was asked questions on a regular basis for two weeks. I even attended the scrum meetings for the team the stories were assigned to. This was all while I was doing my own testing work and attending my own team meetings. I can say, without hesitation, that shit is hard. You have to be on point in meetings and you have to have answers in a reasonable amount of time. You have to have your team trust the answers you give them and you need to trust their feedback. It's a lot of freaking trust. A lot. Anyone that says otherwise is bullshitting or doesn't understand the amount of work needed to make sure one story, let alone a whole project, works and won't mess up other pieces of the puzzle. Additionally, if you are bad at product development, it shows, faster than any other job on the development team. It's a lot of pressure and I have a lot of respect for people that stay in that role for a long period of time.

I know for a certain that you can work with your product team to gather more information or understand usability problems. They should be a go-to source for any tester, any developer, really anyone on a team, for product knowledge. That might be stating the obvious, but sometimes that has to be done. People forget that they have access to someone that can help and you can certainly help them. Cultivate these relationships and keep them going even after you move onto another team or another company. You never know when someone might have knowledge which can help you solve a problem.

The Valued Customer

If you can have customer contacts, absolutely make them. Customers can be a wealth of information and knowledge about your system under test. They might not know all the in's and out's but they can tell you what they like and don't like about the product. Getting this information directly instead of via Customer Service puts a face on the users. When you ask the users questions and they can answer because they know the domain they are working in well, and they can see what you are trying to do with a product, you are getting insight into your user. Some companies advocate "Dog Fooding", and that's OK too. But the biggest problem with that is you know too much sometimes. You know more than a normal customer, so it's easy to dismiss minor issues because you might know what's causing them or that they might never be fixed. But those are the things you should go after and advocate fixing, even if it's only a minor annoyance. Those minor things can turn into major losses depending on the product and the customer.

The more contact you have with customers the more your work means to them as well. They might not understand what you do in software development, but they understand that you are trying to make the product work for them. They will tell you things they might not tell a customer service person or even their sales rep because you might listen more or be willing to bring an issue up in a product meeting when you can.

A Small Caveat

Be somewhat careful with cultivating these relationships to not accidentally circumvent a process or divulge information which shouldn't be used outside of the company or a department.The goal here is to be cooperative and open, but not so much that the relationship becomes an issue and the company takes steps to mitigate or manage contact between the departments or people and customers.



Allies are everywhere, if you understand what you are looking for and who might best help you with your questions, they can be easy to find. They are also some of the best unskilled testers available. They use the product just as much as you would, maybe even more, and understand things at different levels that could give you valuable insight. That insight alone can be your first line of defense in preventing defects and a poor user experience.

No comments:

Post a Comment