How testing of Banking/Insurance Domain is different then any other website testing?

Question

I have been in software industry for a long time now. I have seen that experience in Banking Domain(tested banking websites e.g. Axis bank, Yes Bank etc)or Insurance Domain asked separately as a skill set.
I always wonder:

1. how testing these websites is different than testing any other complex (non-banking/insurance)website like Gmail, facebook or other nicely coded reputed websites.
2. Don't they follow testing methodologies, agile, scrum, write-execute test cases, talking to Dev team, evening morning calls with stake holders, and so so many other things.

I always believed that its testers IQ, experience and Product knowledge (understanding of product) what matters. But some how this thing has come in trend that people put this as separate skill set or study. They put more stress on this keyword Domain Knowledge.
Most of the time it is even difficult to say which domain I am working for. Suppose website I am testing provides job search plus selling professional resume writing tools.
In this case domain is search-engine domain or e-commerce or banking domain or is it 'search-engine cum e-commerce cum banking' domain.

Answer 1

Testing in every domain is different because any testing requires domain-specific knowledge. During my career, i worked in such different domains like:

• mortgage loan servicing (non-performing = overdue loans, which require lost of complicated handling, like knowledge that in West Virginia there are differences in foreclosure procedures per county). We had contractors but we farmed only "easy to explain" tasks to them because of the long learning necessary for some tasks.
• bioinformatics (until they realized that it is easier to teach a person with MS/PhD in biology to program in Python than to teach a programmer biology), where understanding that some results do not have biological sense was crucial when debugging my software.
• aviation support and flight planning (where amount of regulation and plain physics is mind-boggling).

Testing a site like Gmail or Facebook is different in a sense that any average smart user "knows" how to use it, so average smart user does have all domain knowledge needed (or can gain it by reading few pages on manual).

To break into new domain you need to have other relevant skills, and company needs to be willing to spend (sometimes significant) amount of time to bring you up to speed in particular domain. So i.e. to test banking you need to be expert in the testing technology/tools they use, and there should be only a limited supply of skilled experts with such domain knowledge.

Answer 2

Companies like it when new potential employees have similar experience because in theory it gives them some familiarity with the industry, terminology, rules and regulations, common technologies and maybe even with theirs or similar products (as a basis for comparison). In theory it also makes it easier (or more familiar) for recruiters and managers to exclude those without experience - unless you are a top candidate.

I've worked for both large Banking and Insurance companies and (again it will depend on what areas within those industries you work) it took some time to understand the complex terminology and models that underpin their business.

For example I worked on a loan origination system for a bank. I considered myself fairly literate in finance and the US economy but it still took me a good six months to get comfortable with the details of how loans are made, how the whole US economic system dealt with buying and selling those loans, the large number of regulations in place, what happens when loans conform to standards, when they don't and when those came into effect.

Now there are quite a few test techniques that can be used by testers without knowing much about the product -> QuickTests. But often in order to do deep testing we need an understanding of the product and the other factors that influence product design which generally require experience.

There are a lot of factors and skills important to testers like testing skills, critical thinking, systems thinking, technical skills, etc. not just IQ and experience.

Another piece to the puzzle of acquiring domain knowledge is where you fit into the puzzle. The bank and insurance company I worked for were large multinational companies which meant I tested a very small piece of a large application. Basically that means I specialized in one specific domain and I only needed a fairly limited understanding of the others. This is a different approach than if you are the sole tester in an organization with several different and distinct product and you are expected or asked to test each one. If this is the case you have to set up rules and make it understood you can realistically only test / learn about one product at a time.

Answer 3

As Chris has said, domain experience means that - in theory - a candidate won't need the lengthy domain learning time that's needed.

For instance, I'm currently working in payroll and HR management. To be able to effectively test my employer's software, I needed to learn how payroll and HR management works, and the US regulations that the company needs to follow. It took me six months to be comfortable with the domain - and close to a year to consider myself moderately familiar with it.

There's always going to be a learning period for an organization's software, but an employee who's familiar with the business domain doesn't have the learning curve (or in some cases, cliff with a wicked overhang) that comes with learning the software and the business domain at the same time.

That said, for permanent positions, a highly skilled candidate who can demonstrate that they learn quickly isn't necessarily going to be passed over for a weaker candidate with more business domain knowledge.

The business domain is the primary focus of your business - these tend to be quite broad, like "banking", "insurance", "HR management", "ticketing", and so forth. Your employer might focus on a small facet of the larger category, such as "banking/online card processing" for a company that builds credit card processing plugins for other organizations to use. If you're not sure whether your experience fits into a business domain, it probably doesn't - but that's no reason not to apply for the position if your experience is a good fit for all the other requirements.