[inaudible 00:07:31] when you try to analyze and make sure that your testing is in accordance with expectations and the behavior of the vision of the product, it is definitely going to be beneficial.

That’s basically why we need better identification of test gaps. Now, the way typically that you could try to sort of improve or increase the bar of how you identify those test gaps, it’s almost the way I look at it is cause and effect, right? Your second question about the common causes, I think when we understand the causes and have a mitigation to address each of those causes that invariably translates into sort of like a better approach of identifying test gaps.

Let me talk a little bit about what I feel are the common causes of test gaps that I’ve seen over the years. To me, the number one thing was a communication gap between the business team, the development team and then QA, particularly what happens if you have a time crunch or are in a mode where you are just trying to get the software out. If not every control of a product team or a project team is involved, you might have gaps between communication where the business analyst has told some expectations to the tester versus a different set of requirements, say, to the project manager or the technical team and they implement differently. You might have a gap where you haven’t tested for everything that’s in there. A communication gap and issues are sort of like a common cause. The other one that I see also … especially, like with Agile and those approaches where you don’t have a whole lot of documentation … where this notion of “tribal knowledge” like where you’ve got just information that you heard about while you are in communication with the different teams and it’s not actually implemented as part of the software test documentation, like test cases or what not.

What happens is it then translates really to subsequent heroics of the person who’s actually testing it. Over time, that knowledge might just disappear with the team members who are drifting away from that specific project team.

That also translates into a testing gap where the new resource of a new team member who comes in, who doesn’t have access to the sort of “tribal knowledge,” will not even try to test it and which will result in potential bugs when the product goes live. The other reason that I think also about is where the requirements are non-specific, didn’t get documented or you have a scenario where the requirements are potentially out of sync with the implementation versus what was communicated to the test team.

Irrespective of the methodology, if the test team was told about, “Hey, this is what you need to expect of the behavior of the product” versus what it is really doing that could be where you don’t test for everything that the product is expected to perform and hence skip over some of the key functionality or core items that really need to be better validated for behavior. Something else that I think about also is sort of having an incomplete audience when you are meeting or exchanging information via emails where not everybody associated with the project team is present.

Something else that I think about also is if you are sort of following a waterfall methodology or what not, when you have your phase transitions, you don’t have a formal hand-off where a proper checklist of all of the activities or coverage or traceability has been identified from requirements to implementation or requirements to test case coverage.

Having that as a valid checklist of some sort would help identify any potential gaps that may result. Something else that I think about from a tester’s perspective is also making sure that the testing scope and approach are sort of identified and discussed or reviewed with the development and the business team just so that we get any nuances or gaps that exist from a prior communication mishap or what not able to be discussed and identified, so that way you are identifying potential gaps earlier on rather than it being too late. And then the other big thing that I think about also is like a basic coordination between development and QA.

Particularly, what should happen is the QA team should be hands-on with the development team, making sure they are communicating, talking to them, discussing things in general about the implementation so that way you have a better understanding and insight into how the product is being implemented, which will allow them to make sure that they are testing it in its correct sense and with the in-depth attention to detail that is needed.

One of the other things that I have seen in the past also which causes sort of a gap, if you will, would be if the defects that are logged don’t have the correct amount of detail or business intact against the logic built into its description. For example, if I simply say something is not working as expected without actually putting it in the context of what the overall business work shall need for that is it might be where it gets fixed one item, or that specific detail itself, but then the change may impact other areas. That could be a case where defects are invariably introduced and you don’t have enough coverage to be able to validate that.

Torrey Dye:    Sounds good.

Continue to ask the remainder of the questions from the outline. Focus less on remembering what they are saying and more on what follow up questions you should ask to get more granular details.

You will save yourself considerable time if you record the interview and then get the audio transcribed. This is the secret sauce that has allowed me to write amazing content really quickly. I can capture more than enough information for an article in a twenty-minute interview, get it transcribed and have eighty percent of the article ready and I’ve only spent about thirty minutes of my time.

You will also conduct a better interview and the recording will provide better notes. I find that reading back through thorough notes provides much deeper insights than when I try to take notes myself or recall the conversation from memory.

If the interview is to be done by phone I use Calltrunk to record my calls. You simply enter the number you want to call on the Web site or on the phone app. Your phone receives a call and then your interviewee is called on the same line. When the interviewee receives the call it will show from your number so they will recognize from whom it is coming.

Conducting the interview via phone is another part of my secret sauce. Experts typically have a full agenda and are often traveling. It is hard to schedule in-person meetings with them, but it is easier to get them on a twenty-minute phone call while they’re in the airport, stuck in rush hour traffic or whenever they have twenty minutes between meetings.

If the interview is to be done in person I use a Yeti Blue microphone. The Yeti Blue is a professional quality USB microphone that plugs directly into your laptop and it only costs $99, so it is perfect on a budget.

My laptop is a MacBook Pro so I use the free edition of Apple Quicktime to do the recording. I’ve played with a lot of audio software and Quicktime is so simple that it is my favorite. I end up editing the audio in another application, which I will walk you through later.

If you have a Mac, open up Quicktime.

Go to file and choose new audio recording.

 

 

 

Press the upside-down white triangle and make sure the Yeti Blue microphone is the microphone in use. When it comes time to start the recording, simply hit the red circular button.

When it comes time to stop, hit the button again. At this point your recording is untitled and I haven’t found an intuitive way to save, but when you close the file it will provide you a way to save.

 

Step 3: Interview Transcription

Once the interview is complete, have the audio transcribed. If you used Calltrunk to record the interview they can transcribe it for you with just a click of the mouse. I typically use Rev.com for the transcription. They often get the transcription to me on the same day and only costs one dollar per minute.

I did not get the transcriptions when I first began writing articles from interviews. I instead would listen to the interview and write the article. I found this to be less effective for two reasons.

First, it took me far longer to get quotes from the audio than it takes to get the entire interview transcribed and my time is more expensive than one dollar per minute. I save considerable cost by paying twenty dollars for a twenty-minute interview to be transcribed. More importantly I get a few hours back to focus on something more critical.

Second, by getting the full transcription I reduced the time it takes to write the article by eighty percent (that’s a guesstimate). As I will describe in a moment, it only takes a little bit of time to polish up the transcription into an amazing article.

 

Step 4:  Interview Polish/Edit

Once you receive the finished transcription it will be in the format that you read from my example above. You will want to first cut out all of your questions, speaker labels and the unnecessary dialog and reformat the text to a normal page layout.

You will go through the remainder of the text and polish it to read as if it were written instead of spoken. For example, I transformed the following paragraph as shown below:

 

Before Polishing

Yes, absolutely, I think what would be helpful for me also to get my thoughts together is first let me give you some of the key reasons I think why identifying test gaps is important and then probably talk a little bit about how better to do it better. Obviously, when I think about the reasons why test gap identification is critical is probably around three main reasons. The very first one is the reason why we don’t want any gaps in testing is so that there are no defects in the end product that gets delivered, right?

What I have the biggest fear about is when you have an incomplete product out in the marketplace, you will have very unsatisfied or dissatisfied end users, which invariably reduces their overall perception of the quality of the product and what it can actually do for them. Then, hence, it sort of translates into a lower adoption of your product, even though it might be beneficial for their marketplace or their use. They will just not adapt to it because they second-guess everything that is coming out of the product.

The other obvious reason also is when you do have defects that have been identified when you go live, the relative cost of fixing those defects when something is in production is much higher. Previously, there are so many studies and all that, that have been done to show you that finding a defect way earlier in the process is much cheaper than doing it after it goes live. The later you find something that is a bug, the more expensive it is.

To me, those are the key reasons why making sure there are no defects which essentially are an outcome of test gaps potentially that should be avoided. Why identify them? I think one of the key reasons, again, is just keeping the overall satisfaction of the product high. If you have a service that you are used to, you do not want to get any sort of breaks in between. You don’t want the product when you try to use it or go to a Web site for it to be down.

In your sort of mission critical perception of your business mode where you want to be able to use the product as a tool, getting things done more efficiently, more effectively. Every time I have something that I need to do, if I try to access the product and it’s down for whatever reason or it’s not performing to what I expect it to perform, it’s going to have a business cost. Making sure that you have better ways or have more [inaudible 00:07:31] when you try to analyze and make sure that your testing is in accordance with expectations and the behavior of the vision of the product, it is definitely going to be beneficial.

 

After Polishing

It is critical to be identifying test gaps continuously. First, this is to ensure there are no defects in the end product that gets delivered.

Second, when you have an incomplete product out in the marketplace, you will have very unsatisfied or dissatisfied end users, which invariably reduces their overall perception of the quality of the product and what it can actually do for them. This translates into a lower adoption of your product, even though it might be beneficial for the marketplace or users. Users will not adopt your software because they second-guess everything that is coming out of the product.

Third, the cost of fixing defects when software is in production is much higher. There are many studies (find example study) that show fixing a defect early in the development process is much cheaper than fixing the defect after the software goes live. The later you find a bug, the more expensive it is to fix.

These are the key reasons why making sure there are no defects which essentially are an outcome of test gaps. Why identify them? One of the key reasons is keeping the overall satisfaction with the product high. If you have a service that you are used to, you do not want to get any sort of breaks in between.

When a user has something that they need to do, if they try to access the product and it’s down for whatever reason or it’s not performing the way they expect it to perform, it’s going to have a business cost. Making sure that you have better ways to analyze and make sure that your testing is in accordance with expectations and the behavior of the vision of the product, it is definitely going to be beneficial.

You will want to edit the text to be in the optimal structure now that the text is more readable. You may need to move some sentences around, make additions and/or subtractions. Here is how I further polished the text to be in my preferred format. First I added a couple of introductory sentences:

You already know continually identifying test gaps is important, but are you doing it? Sadly, chances are you aren’t. Although continually identifying test gaps is critical to software companies, most quality assurance teams are satisfied with mediocrity.

Why is it critical?

Next I added the polished interview text, further polish the text and rearrange the sentences:

You already know continually identifying test gaps is important, but are you doing it? Sadly, chances are you aren’t. Although continually identifying test gaps is critical to improving software companies’ customer satisfaction, revenue and profit, most quality assurance teams are satisfied with mediocrity.

Why is it critical?

Defects create dissatisfied end users, which invariably reduces their overall perception of the quality of the product. A lower perception of quality can translate into lower adoption and ultimately less revenue.

When a user tries to access the product and it’s not performing to what they expect it to perform, it’s going to have a business cost.

Defects cost more to fix in production then before the release goes live. The later you find something that is a bug, the more expensive it is to fix.

You will want to go through the entire interview in a similar fashion as the example above. This process typically takes me under an hour and I have often done it in about twenty minutes including the 1,200 word article that I used for this example. So the total time it took me to send the initial interview request, record the interview and write a 1,200 word article was forty-five minutes. How often have you written an amazing article in forty-five minutes? Better yet, it only took a twenty-minute phone call for the internal expert.

 

Step 5: Interview Review

You will want to do a couple more things before publishing.

First, you may want to see if you have any questions that could make the article even better. Or, you may notice areas of the article that could be richer if they included examples or numbers. Go ahead and make a list of these and send them to your expert and whomever else may be able to help. You can also do a little web research if you feel comfortable.

Second, you should send it to your expert. She can make sure everything is technically sound. She can also make changes that she feels makes the article sound more like her. The review is an area where the process typically bogs down, but I find that when the expert has only done a phone interview, she typically reviews the article quickly. As I said in the beginning, they don’t feel as much ownership.

 

Summary

Using these tactics has allowed me to create much more engaging content in a fraction of the time it used to take me. I can come up with an idea for an article about a topic that I know nothing about and have a completed, amazing article by the end of the same day.

I used to work for a company where it would often take our thought leaders six to eighteen months to complete a white paper; now my clients are able to get them done in a day.

I hear B2B marketers constantly wishing they had more content; maybe this used to be you, but now you have no excuse. Start quickly producing all those awesome content ideas you have!

Have you found other ways to speed up the content creation process?

About The Author

Torrey Dye is a B2B Marketer and founder of FunnelCake Labs.
FunnelCake Labs helps B2B companies create amazing content more quickly.Google+
www.hypersmash.com