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.

Wednesday, August 3, 2016

The First Full Hour - An Experience in Public Speaking

"No plan survives first contact with the enemy" 

Nineteenth-century Prussian military commander Helmuth van Moltke


I prepped for a month an a half. I initially thought about all the ways to help the developer group I was speaking to understand that testing would be good for them to get a handle on. I had a lot of starts and stops. Different slide views. Different ideas even. And what came out in the end was more of a "Let's talk mindset and how I think about testing and what you can do." rather than a "Let me preach the word of testing!!"

I read my notes. Spoke them out loud. Modified for context. Modified for approach. Paced the floor of my office. Mumbled to myself until my dogs looked worried about me and hoped that it was enough to explain to the group and have the group understand what I was trying to get across to them.

Talking for a whole freaking hour is really, really hard! I didn't appreciate how hard it was until I was standing at the front of the room, with 18 people staring at me. Friendly faces, some I had even spoken with. All I could think of was, please don't let me do something stupid like burp, or pick my nose or flail around needlessly.

I started with the introduction, like just about everyone does. I then I explained this concept I have about the mindsets of problem solvers. There were some nods and people were still looking at me which was good. But I think maybe I spent too much time on it if I was honest, or I just could have jumped into explaining how I think and then ask them how they think about testing and then try to explain, but alas, that method only occurred later while I was driving back to work, thinking about what I said.

The second part of the talk was meant to be more interactive and I asked questions about what testing they already had, about processes and even about development styles. People didn't mind and it even sparked some conversations. I think this was good, but it could have been more interactive to a degree. I could have had volunteers explain what they were doing on those projects as well, instead of just noting that they did certain things like unit tests or acceptance testing. One kudos for me on that; when I ask if anyone was doing acceptance testing, and immediately I was asked to clarify what I meant, and I had a definition ready. I had managed to think ahead and the definition it was in my notes because I wasn't sure I would actually remember the definition. Trust me, I didn't. It's not that I didn't know it, it just that I for the life of me, couldn't have given a clear definition if it wasn't right in front of my face. I don't think in definitions. I just do because I understand the concept. But it was a huge win for me that small moment, because it meant, at least to me, that I understood my audience.

The third part a little better I think. I spoke about a cross section of testing that could be done by coding types, which involves code reviews, unit testing, pair developing, and code or commit comments. This was taken fairly well. The idea of doing positive code reviews and being less attack and more questioning, and maintaining a positive level of interaction so that they can all better their work through critiques seemed to be also well received. I also talked about risk based testing as a way of planning at least some testing efforts. I also mentioned Test Fests and Unit test parties as a way of getting help and making things eventful. People seemed to like that concept a lot.

I took questions at the end. I felt like I did well with those. I felt though, when I was asked about the agency experience, and having to maintain different tech stacks and moving around on different projects, how could they handle that better and my comment was - "LEAVE NOTES. If you aren't going to stay on the project but know about an optimization or a part that could give someone issues in the future, comment on it in the code. It takes less than 30 seconds and it pays a lot forward." I don't know if that was the only thing they could have done, but it was my best answer to that question. If there are other ideas out there, I'd like to get to know about them.

It was over a lot quicker than I thought it would be. I planned ahead and had water ready when my throat went dry. I'm not sure how people speak without drinking water during some part of the hour they are speaking. I had an immense sympathy for speakers then. Water also helped when my voice started to waver a little. It caused me to have a small panic because to me it sounded like it was nerves coming through. But it was just dry throat. Funny how the sound of your voice can freak you out and put you in a state you weren't in only mere moments before. Actually, it's not funny, but I'm glad I planned ahead and I was brave enough to stop and take a drink.

I also clung to my notes like they were a life raft. It's amazing how much practice and time you can put into a talk and suddenly have it all woosh out of your head like a speeding train with no breaks leaving you standing at the station of "doh!". The notes definitely saved my bacon several times over. It's why I make them, it's why they are there, but I was a little disappointed in myself for having to refer to them so often.

And being on the train of self analysis, I could have added more slides with the talking points on them instead of just sticking with one main talking point slide. I had five slides total. I figured since it was a conversation, and I practiced, the slides weren't really that big a deal. I could have done better with that and helped myself out with not looking at my notes so much. I know now for next time.

It was a absolutely thrilling learning experience. It was very much like the lighting talks I have done but much longer and with a bit more pressure since I was getting paid for this one and people expected some useful information out of it. I was also recorded, so the vid should be interesting once I get a copy of it. I don't know if I'm going to be brave enough to watch it myself. While I feel like I did well, and I got a lot of head nods and agreements and such, which are all good signs in my book, I rambled on with some points. And I worried that wasn't connecting with my audience on everything I was trying to convey.

Also, I'm really good at telling stories, and the experiences I've had could have highlighted a lot of my points, but I didn't get comfortable with that concept until the end and I had a chance to tell a story that related to code comments. The story connected very well. People got it. I had a small AHa! moment to tuck away for later. 

Mostly, I'd really like to speak again. I don't think I'm horrible at it and I might even be mostly good. The thought that sticks with me most, which comes back to me when I start panicking that I completely bombed is knowing that even the most talented people that speak for a living have these problems. Stand up comedians have these problems every time they work on new material. I've seen some prep shows. Not everything lands, not all the bits work. Sometimes they have to rework things so that it makes sense or they just toss it out. If I look at it from that point of view, I have lots I did well, and things I can do better for next time. I think that's all anyone could ask from a speaking experience. I'm not at the level of Mrs. and Mr. Obama, but it was also a solid first effort. And hopefully there will be many more to come.

Postscript: The quote above isn't about developers, hopefully people understand that. I included it, and this goes back to the telling stories part, which it appears I'm still learning, because, one of the team members I spoke with asked me how I prepped for the talk and I explained it and then mentioned the quote about plans not surviving and such. He actually finished the quote I started to say. It was a nice beginning. So I made it the beginning of my article here. Best laid plans and all that.

Sunday, July 31, 2016

Mel's Take-Aways: #30daysoftesting

"Happiness lies in the joy of achievement and the thrill of creative effort." 

- Franklin D. Roosevelt


I found the exercise of #30daysoftesting a great way to think of other day-to-day things that I know I automatically apply my testing process to. While I wasn't successful at completing all of the challenges, I did a large number of them. A few I posted out on twitter and some I kept to myself or took notes of for future reference. 

Here are some of the highlights from the #30daysoftesting I enjoyed:

#2 - Take a picture of something you are doing at work - This was probably pretty creative for many of us that have NDA agreements. Mine was happenstance since I was installing SQL manager on Windows 10. I had a lot of woes that day, but I worked them out. 

#7 - Find an accessibility bug - While I didn't find a bug exactly, this was the inspiration, along with the movie Finding Dory to write something more about accessibility problems and issues with software and how they handle disabilities. 

#10 & 16 - Attend an event/ Attend a non-testing event - If you haven't heard or seen a tweet from me talking about Women Who Code or Chick Tech, look these two groups up. They are all over the world and they are doing great things for tech in general. One of my most inspiring moments came from doing a lighting talk at a Women Who Code meetup. 

#14 -  Step outside of your comfort zone - I've been working on FreeCodeCamp.com. I recently finished my first project for it, which is a tribute page for Sally Ride. I'm going to share it here, as sort of a double down on #14. It has been really hard for me to take time to code. Even then, I borrowed a lot from other people's work, but the modifications are my own. I just like playing when I have time and learning as I go along.

#17 - Find and share a quote that inspires you - If you missed the quote from Peter Welch, I suggest looking up his blog. It's pretty epic and funny.

#28 - Summarize an issue in 140 characters or less -  I'm wordy. I think I tried and failed to do this several times and ended up with multiple tweets. Ah well. 

Overall, while I wasn't able to completely get through all the challenges, I loved this idea, and I loved the attention the testing community gave to this idea. I hope it comes back around again, and gives us all more to learn and talk about down the road.