Confusing Terminologies in Software Testing - A Case Study!

Couple of days before, I received an email from a blog reader (Lakshmi NSMV) asking me the following query:

What is Build Verification Test (BVT)? What are the things that are taken into consideration while performing BVT? Is it the tester’s responsibility to perform BVT?

At first glance, it did look like yet another testing question that is often asked in software testing interviews (as if there is no other better question to judge the skill sets and competency level of the candidate)! If you have attended quite a few number of interviews for the post of a software tester, then chances are high that you might have already come across such buzzwords like BVT, Smoke Testing, Sanity Testing, Build Acceptance Testing and so on.

Well, I could have given a pretty straightforward reply to Lakhsmi’s question via email describing my understanding of Build Verification Test (BVT), how I define it and how I approach it. But I doubted if that could have helped her in any way. After all that would have been *my* definition of BVT and could have differed from others. Curiosity [to hear how others understand and define Build Verification Test (BVT)] got the best of me and I decided to contact few testers and seek for their definition of BVT. Here is the result:

Me: How do you understand (define) BVT (Build Verification Testing)?

Ashok: As per my experience BVT is - when we get a build to test, we will be verifying whether it is suitable for further testing or not. Using sanity testing and without any formal test cases we will be going through here and there to find any show stoppers. If we are not able to accept the build we will discard this build, switch over to the earlier build (provided there is one) and continue testing the earlier build.

Kiruba: According to my knowledge, after the build has been released, we will do the retesting and regression testing. It is build verification testing.

Santhosh: BVT is verification of the build by a Release Engineer. This BVT focuses on the main functionalities of the application. BVT is also called as Build acceptance test. Any build that fails the build verification test is rejected, and testing continues on the previous build.

John: This test is the first test, which we conduct as soon as we get the build from development team. Here we check/verify whether the build is usable, understandable, stable or not. Mainly we concentrate on whether the build is working or not and usable or not etc.; means verifying the build.

Ravi: BVT is nothing but Sanity Testing where we verify the final build to test its sanity or cleanliness.

After reaching this point, I had started questioning my decision to ask other testers for their understanding of BVT. Because, my own understanding of BVT was already diluted and on the verge of shattering as I had started getting confused hearing all these variations in the definition of a terminology as common as Build Verification Testing (BVT). As I was wondering whom to contact next who could come to my rescue and help me come out of such confusion, I spotted Mr. Shrini Kulkarni to be online on Google Talk! Thanks to him for instantly responding to my IM. Here is an excerpt from our conversation.

Me: Hi, hope I am not disturbing you. I wanted to hear your way of understanding (own definition) for Build Verification Testing.

Shrinik: BVT... Let me think...

Shrinik: It is a cursory method checking that few basic functions are working fine and the build is ready for more thorough testing. Typically BVT should not run for more than 30 mins to 1 hr and it is typically automated. You might confuse this with smoke test, sanity test or build acceptance test. Technically all mean the same or I can spin my own story to create my own definition.

Smoke Testing = Build Verification Testing (BVT) = Sanity Testing = Build Acceptance Testing (BAT)

More than the names it is important to understand the underlying principle. Here the underlying principle is "cursory checking" before detailed testing. You might decide to call it as "Debu's" testing. :)

Me: This is one of the reasons why sometimes I wish testing world were free from buzzwords, terminologies and abbreviations! Thanks a lot for guiding me on this.

Shrinik: It (testing world) cannot be (free from misleading terminologies and abbreviations)! We can only keep a constant eye on terminologies.

Me: You are right.

Shrinik: As Michael Bolton says: “People might use different words and mean same thing or people using same word might mean different things”. Hence, it always helps to clarify. James (Bach) some times says when confronted with a new word: "I might be doing the same thing as this word. But not by that name"!

Me: That is an interesting way to deal with terminologies that are not-so-familiar to us. Once again thanks a ton for responding to my query.

I think as long as there would be testing there would be terminologies to confuse testers. Having our own definition for a software testing term is just fine, as long as the definition reflects our own understanding of the term under question and as long as it fits well to our context and work environment. The actual problem seems to start when people start taking their own definitions as the universal definitions and start expecting others to understand things in the same way as they understand it. Asking such buzzwords in a job interview and expecting the candidate to reply in a way that exactly matches our own definition is, in my opinion, inappropriate, unreasonable and inhuman to some extent! How can we be so obtuse?

How to deal with Confusing Terminologies in Testing?

A tester’s questioning skills can come in handy while dealing with terms that are either new or confusing to him. As Shrini rightfully pointed out above, seeking for clarification is the first step to get rid of such confusion. Testing world is full of traps. And a good tester always tries to clear traps by asking relevant questions capable of revealing important information. Same strategy can also be applied while dealing with an alien term in testing as you hear it for the first time. When confronted with such a new word, ask what the person actually means when he uses such word/term/para-phase/abbreviation. And the reply could surprise you! You might discover that you already might be following the same testing principle, but might be using a different name to denote it. Asking for clarification, can demystify most of those dangerous looking terminologies and in turn can help you add some new words to your testing vocabulary! As a bonus, it can help a tester while communicating with different circumstances like:

a) attending a job interview.
b) discussion with a tester who belongs to a different testing community/country/organization.
c) communicating with different stakeholders (developers, clients, managers etc) of the project who use different terms to mean the same testing principle or vice versa.
d) communicating with fellow testers.

How do you deal with the confusion arising from misleading testing terminologies? What do you do when you are presented with a term that is new to you? I am curious to hear you. Voice out your ideas by Commenting!

Happy Testing…

Share on Google Plus

About Debasis Pradhan

Debasis has over a decade worth of exclusive experience in the field of Software Quality Assurance, Software Development and Testing. He writes here to share some of his interesting experiences with fellow testers.