Not every time software testers would come up against a system for which they have a good amount of field knowledge regarding its contextual working and core business functions.

Most of the time they (testers) have to learn, adapt and gain the understanding about these systems going beyond the traditional approaches, it is however by the passage of time, that they are able to learn about workings, loopholes and its creative use.

Why Domain knowledge is important?

“Start where you are. Use what you have. Do what you can.” – (Arthur Ashe)

Having the expertise in domain is as same as the difference between a novice driver and an experienced driver. The novice driver does not experiment with speed, shifts and brakes. She is too focused on the control of the car with an element of fear of the road. Whereas on the other hand, the experienced driver has developed a road sense, and is aware of the fear. She uses variations in speed, knows how the brake works in neck to neck traffic and how to reach a destination in a fuel economic way.

Same difference occurs when a tester is faced first time with a system, and then using the right heuristics develops the expertise to use that system.

On a side note, we need to find the “potentially important” bugs in a finite time frame and all of them. If we don’t know about the system and its working, we can never find them.

This is one such short yet true story …

One fine day I was called in by the project manager of our website development team, who was interested in giving me a testing assignment regarding their real time event tracking and management site. Besides other features regarding hangouts, events and happenings, this site was location based and specifically designed for England.

What was that website?

It was fundamentally a search engine, which searches for the events and happenings across England and lists the one that is nearest to your location. How does it track your location? Well, a user provide where she is in the search parameters.

Where does the event data come from? Well, it was entered on real time basis via another location, and these systems, the front end website and the backend data handler were integrated via admin module, very interesting work for that time in space.

What was I supposed to do?

My job was to conduct black box testing and report bugs along the way. It was then I heard the sweet word of “Domain”. He asked me; do you have the knowledge of this domain?”

I said “What exactly do you mean?”

He replied “Well there are two here; One, the knowledge regarding how “Search Engines” works, and two, “Whatever happens in England, does not necessarily be happening in other cities around the world!”

How do I go about it?

There were 2 visible paths I could take, one was the “General knowledge” of a tester feeding in with experience and common sense; which is by the way, very important for a tester

For this general knowledge part, it was somewhat under the hat, as I knew how search engines work and can play around and generate wild ideas about keyword and search strings. On the other hand the knowledge about “England” was the tricky part.

The search was bread crumbed in the manner of, Categories, Dates, Location and Event. Once the user provided all 3 or a partial the search results were listed. Further on the user can proceed to bookings to the third party site or tag these results as a wish list.

Then there is the contextual knowledge which feeds in the “Domain”. This is where the real test of the tester comes. Because to gain this knowledge, you need to get out of the comfort zone, use all your abilities and then re-learn everything.

For this tester part, I need to be sure that the search results which were coming in are from the right location, right address and each time the results does not differ from the previous ones. I also needed to inert variations in my usage of the website. Including cross browser testing, missing elements in search results and leaping and creeping the boundaries – especially the date fields.

Okay this was great – but I was not in England, I was in Karachi. As this system was based on location searches and sorting them out accordingly, I have to place myself in England, on a particular address, searching for a particular event, which is also near my location, or for a location, where I would be in the near future, or for someone who has requested me to find that event, for her location, etc. etc to murky world scenarios

The Testing:

How I tracked an address for a location, using the maps? I needed to verify the search results with some solid de-facto data, because with each search I was getting the events, and then their addresses. The list gives the user an option to sort the events, on the basis of “nearest to you”, “Date wise” and “Location Wise” – so date and location was easier, as it was visual, but for nearest, I need to know for sure.

The second thing to learn was about how addresses were formed. For England it is highly organized and coded. For example:

Business Address with Dependent Locality

The parameters were allowing me to search on the basis of the event name and date only. Address was fed in from the data entry portal. So as a black box tester, I have to devise a heuristic approach to identify loop holes in the searches.

So it was time to Google England and its maps and then learning how addresses are formed – very interesting indeed!

I pulled the map out, and instead of focusing on London, I moved to the suburbs of London. I picked a viable location, a town, which also reflects the Post Code and Post Town – hence, I searched the event in that town. What we found out later that the system was fetching records on the basis of town name, and code, not on Code and then town name. This was creating confusing results for the searchers. So if we have a near possible likes of two town names in different village areas, we are getting them on the same list, where one of them is no near then anything within 60 km!

End Notes:

Whenever as a tester you encounter a system, and the thoughts started to ring in your mind about “how would you test it”, take a deep breath. It will take time; it will take coordination, research, analysis and then building up a story. The best way to do it is the system which offers you all the information you need. You need to tap the right area to start.

In so many words, the “Domain” knowledge is the key element to achieve completeness in your testing. If you don’t have the proper in depth domain experience, then you need to acquire it, because that is what’s going to make your testing creative. You would know which area to tap and where the bugs can reside.