This post is mostly a result of a comment from Rahul. He made the comment on a post on Validation and Verification and I think it was a great idea, so here I am with an attempt to distinguish these two closely related and often wrongly used acronyms viz QA (Quality Assurance) and QC (Quality Control).

First the definitions
Quality Assurance - Quality assurance, or QA for short, is the activity of providing evidence needed to establish quality in work, and that activities that require good quality are being performed effectively. All those planned or systematic actions necessary to provide enough confidence that a product or service will satisfy the given requirements for quality. (As per Wikipedia )

Quality Control - In engineering and manufacturing, quality control and quality engineering are involved in developing systems to ensure products or services are designed and produced to meet or exceed customer requirements. These systems are often developed in conjunction with other business and engineering disciplines using a cross-functional approach. (As per Wikipedia)

And here’s a simple version of mine.
QA - Set of processes to ensure that we do a high quality work. These processess are at all level. In s/w world, this could mean a good template to capture requirements, a check-list for testing team which needs to be ticked before we deliver the s/w, code-commenting procedures so that if someone looks at a code which is done by someone else then it makes sense and so on.

QC - Test the desired behavior. Its about testing and finding faults. QC is not about putting a right process but about exercising the process.

Simple and over. Well, mostly but let me go a little deeper and illustrate this difference with few examples
Continue reading →

I was previously blogging at a blogspot site and over time I realized that I am getting limited in terms of tools there so I opted to do it on my own. Apart from other things which are needed to host and run a website, one of the basic initial things is to identify a name. And after being unsuccessful at getting a domain for the more common names, I was lost and dejected when suddenly I thought of validateverify, checked it and found that this is available.

Over time, I also realized that there are still a lot of people who are googling on these terms, to find their meanings, there differences and so on. While as a software testing practitioner and as a interview-holic person, ‘Validation and Verification’ are ingrained on my mind-slate, I can imagine that there would be lot of people who might just get confused. More so in places where English is not their first (and probably preferred) language.

So lets try to understand these terms and then see their relation vis-a-vis software testing.

Validation - Act of finding whether something is ‘right’ or not. The ‘Right’ is from the perspective of overall need and desire. Whether something is valid or not.

Verification - Act of finding whether something does whats its supposed to do in defined (or may be undefined at the time of testing) condition. Verification is for built behavior, its for smaller nuances and not for the initial big goal.

Let me now take couple of examples to drive these points home.

Continue reading →

With software getting larger and larger, the interaction between engineers who work on various parts of a software has been getting more challenging. While this is not really a big problem for development engineers, the ones who primarily write code, but its indeed a growing problem for ‘Test Engineers’, the ones who test a software and ensure that it does what its supposed to do for the end-user.

Let me take a couple of examples to explain this better. In first case, we would take the case of ‘MS Word’ which is a part of ‘MS Office’ family of products. In second case, we will take a much smaller product like ‘Adobe Reader’ (more popularly knows by its former name ‘Adobe Acrobat Reader’).

MS Word has tons of modules or components or ‘section of codes’ which would have their own small teams. These may be File IO (Open, Save, SaveAs), Fonts, Print, Tables, Mail Merge, Formatting, Bookmarking, Help and so on. Some of these could be common across products, e.g. Fonts handling, Help etc. Each of these small teams will have their own test engineers and most of them test ‘their’ piece within a certain ‘Entry and Exit’ ideal boundary condition. Its always assumed that the guy who is before this node in the value chain would behave well and the guy who is next in chain would also behave well. Thats a wishful thinking.

Lets take an example

Enter Text -> Save File -> Select Text -> bold the text -> Undo bold -> Save -> Close.

In this workflow (a logical sequence of actions performed for a task), lets take the case of the team which is testing ‘Undo and Redo’ function.

Continue reading →

Software Testing is still more in realm of ‘Arts’ than Science, especially when we are talking about testing software products, something like MS-Office or Mercury WinRunner. Unless you are a part of a highly evolved and organized form of testing, in other words, a defined set of test cases on a defined set of test-bed to be executed, you can safely assume that you wont be able to find all the bugs. Being paid to find bugs and still not able to find all is an oxymoron arrangement and as Test Engineers and Test Managers, we need to live in the reality (of not being able to find all bugs) and still do business (find all bugs).

In this post, I am going to talk about a exercise which lots of organizations are started to get into their test-process as an effective tool for finding bugs, which typically act elusive to the ‘Test Engineer’ who is looking at a specific area. This exercise is called by different names like Bug Hunt, Bug Bash, Focus Day, Bug Harvest and so on. We would refer it as ‘Bug Hunt’, just a personal preference, they all work same / similar.

What is a Bug Hunt ?

A Bug Hunt is an intense bug finding mission over a small period of time, from couple of hours to a day, done by people who are not testing that area or that product as normal day-to-day work or may not be ‘testers’ at all, allows all kinds of bugs (some bugs are feature-requests) to be reported and is done to sort of give one big shake to an area or a product before its being shipped.

Continue reading →