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.


  1. As a test architect, I faced this kind of situation. N words for 1 Concept. Example: A QA Plan, A master test plan, a test plan, a test strategy, etc...
    So I decided to clear the vision for everybody by creating a wiki dedicated to testing terminology. One page per word.

  2. @ Anonymous,

    Creating a wiki dedicated to testing terminology - Sounds quite interesting to me. But How did you manage the wiki with one page per word? I mean, how did you manage the redundancy of the pages, where the same concept is known differently? I would certainly like to hear more from you.


  3. No terminology is confusing by the nature of its existence. When humans try to communicate terminologies to other humans, there comes another set of confusing words - "Confusing terminology".

    I think as long as there would be testing there would be terminologies to confuse testers

    Testing existed even before people had that kind of work designation. Confusion exponentially increased as more people got added to it.

    So as long as there are humans involved, something is prone to confusion.

    A simple example is with what I have written above. I think some or many might say its "confusing".

  4. Debasis,

    I really enjoy this blog! It is extremely interesting and I have to say that I'm surprised at the quality (and quantity) of information you have provided. I work for a new venture-backed company called uTest ( and would love to hear your thoughts on their model. Their attempting to be the first to create a "community testing" model, creating a global marketplace for QA testing. Anyways, you seem extremely knowledgable and I would love to hear your input (perhaps even the next blog to get your readers' comments?) Thanks and I look forward to hearing from you soon.


  5. I agree with what Pradeep said. No terminology is confusing unless we make it confusing. It becomes confusing when we communicate it in wrong way or the listener may interpret it in other way.


  6. This is definetly a great question and depth of replies points to the basic understanding of terminologies we learn when we first start QA.

    Definetly BVT is done intially when the builds are released to QA for testing. However the next follow up question is how many times do we do a BVT. Some suggestions I have read point to BVT to be done everytime we do a build. However depending on the QA cycle - some orgainizations have builds every day. In this scenario, do we always do BVT after every build - imagine the time spent.

    To me BVT seems to be valuable when the first build is released and there up on it become more repeatative if done everytme.

  7. Hi Debasis,

    Well,i have clearly understood wht does BVT mean.But am again confused with term BAT (Build Acceptance Test) .Will you please explain ,what is the diff. between BVT and BAT?


  8. @ Sneha,

    I guess you missed this line by Shrini:

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

    Though my personal understanding of Smoke Vs. Sanity Testing is bit different, I consider Smoke Testing, BVT and BAT all the same (well, at least as far as their underlining principles are concerned)!

    Hope this clarifies your question. Happy Testing...


  9. Hi Debasis,

    I need to say this first "Excellent blog".I have reas each and every posts in your blog alog with their comments.I have to appritiate you for the response for the people who posts comments.Now,I need to introduce me as a test engineer...I work with web applications.I always have a thirst to know testing in deepth.After reading your blog I have decided to seek ur help for building up my career as a test engineer.Now i am half way reading pradeep's blog too.Please can you give me guidance so that i can be a passionate tester as u define your self and i need to be bcz i am in love with my profession testing...expecting yor reply...


  10. @ Raji (Rajasri),

    Thanks for those kind words and thanks for reading ALL of my posts till date along with the comments (wow)! I guess you might be the second person, in my knowledge to have done so [well, the first person is of course myself, who has read ALL my posts along with the comments :)]

    Coming back to your question regarding tips on how to become a "passionate tester", I guess you already know the magic formula (if there is any)! It needs PASSION! And your comment gives me an impression that you already have such passion. All you need is to direct it in the right direction to go ahead. In the mean time, feel free to let me know if I might help you in anything related to S/W Testing! In worst case, I would say, "I don't know the answer. Can I search for it from some authentic sources/persons and get back to you with a reliable answer?" :)

    Happy Testing...

  11. so many confuerms. likesing t


NOTE: Comments posted on Software Testing Tricks are moderated and will be approved only if they are on-topic. Please avoid comments with spammy URLs. Having trouble leaving comments? Contact Me!