Automation Testing Functional Testing Industry Wisdom

Technical vs Domain Tester | Which type are you?

As of writing this article, we both are looking out for bigger & better opportunities in QA Testing. While our job search, a peculiar but prominent distinction popped up – Technical vs Domain Tester. Yeah! We know both are necessary for a successful QA career, but after certain years of experience your resume tend to incline towards one or the other. We are not Rajinikanth after all 😛 Deepanshu worked in the Banking domain for 5 years before switching to Enterprise Content Management (2 years) and recently moving to Salesforce CRM solutions. Whereas Kanchan’s total 7+ years of experience has been in the Banking domain. Deepanshu has worked on Selenium, HPE UFT, TOAD, SOAPUI, HPE ALM, Content Server, Salesforce, etc. whereas Kanchan is more focused on leading a team & developing domain expertise. While we both search for jobs, one thought was sure to be discussed – what’s better? Who wins the Technical vs Domain Tester tug-of-war? Nah! It’s not a comparison between Deepanshu and Kanchan (we are together after all ;-)) but comparison between two different kinds of resume!

Technical Tester

Now-a-days every other organization is asking a list of tools you should have hands-on experience with. Be it Selenium, HPE UFT, SOAP UI, Languages like Java or C#, Load Runner, JMeter, etc. The list is endless…

A Technical tester is more focused on technology, i.e. different Testing techniques, Technical testing, Tools usage, deep-diving into application technicalities, etc. Emerging roles like SDET, Performance engineers, Automation experts are a real proof of growing demand for technical testers. Industry is moving away for Manual-only testers. But a Manual Tester can also be technical in the sense – coverage analysis, test techniques, testing strategy, effective testing, etc. The focus is on testing processes and tasks at-hand and how he/she can better implement the Testing techniques.

  • Test Expert: Not everyone understands that Software Testing is a systematic activity. It’s not ‘click-here-and-there’. With different Test levels, methods, techniques, types, tools, strategy – Software Testing in itself is a vast profession. A Technical tester knows ‘How-to-test’ correctly.
  • Bug Hunters: Technical testers are the bug hunters. It’s not like domain testers are not 😛 but Technical testers just love finding defects.
  • Tech-savvy: Needless to say, technical testers are aware about the latest technology trends and how Testing fits into the bigger picture.
  • Flexible: Technical testers are more flexible in switching to & learning altogether a new domain if that allows them to apply some new Testing approach or tools. I.e. if it offers something new to them, technically.
  • Suggestive: Technical testers are willing to contribute to the overall design & architecture of the application. They are more interested in these kind of discussions with the development team.
  • Not just Bug, Debug: They don’t just find bugs, they also try to find the root cause which in turn helps developers and the overall delivery.

Domain Tester

Each industry is different when it comes to their way of business, hence the required skill set also varies not only from the technical perspective but also from the business perspective. In simple terms – Domain is basically a grouping based on the type of business rather than technology/platform. Almost all IT companies organize their projects in different verticals based on different domains. Some of the common domains are Banking, Retail, Insurance, Healthcare, E-commerce, Telecom, etc. After certain years of work experience, people tend to move to managerial aspects where you are required to have expert domain knowledge to bring in new business.

In simple terms – “Testing is context driven”. It’s good if you already know the ‘context’ to be tested 🙂 anyone can ‘Check’ but not ‘Test’. The difference is same as a novice driver and an experienced one.

  • Suggestive: The job will be done anyway, but a domain expert can be suggestive. He / She can provide feedback, suggest for improvements, and be an active participant in a lot of decision-making meetings.
  • Prioritize: A Domain expert can help prioritize the test areas most relevant to the application.
  • Requirements: Quick understanding of requirements and thorough analysis.
  • Effective: Better simulate the business flows and end-user actions, i.e. effective test scripts.
  • Roles: Testers with domain expertise can play multiple roles like requirement analysis, client interaction, pitching for new business, training, etc.
  • Defect Triage: Knowing how the application will be used and how it is expected to perform, will tell QA whether a given defect is trivial, significant, or critical.
  • Client Relationship: Helps in building Client relationship since domain experts are likely to use business language while reporting & communication.

Technical vs Domain Tester

Let us reiterate that there is no clear distinction between a Technical and a Domain tester. But over a period of time you might relate to either one. Whether you are pursuing the SDET or the Test Architect role OR the Team Lead & Managerial role. Also the characteristics are neither exclusive nor exhaustive. One might find himself/herself falling in both the categories. It pays in the long run if you are clear about your career goals, i.e. you can focus on developing core-strengths required for these kind of roles. Both Technology and Domains are vast – just like Testing, it helps to start as early as possible.

Technical vs Domain Tester

What are your thoughts about the current hiring market? Are organizations moving away from the Domain expertise to Technical know-how? Or the vice-versa? Does this distinction makes sense? Or organizations want both, i.e. Tech-savvy Domain experts? If you are currently looking for a job, you might relate to this distinction. Feel free to share your thoughts in the comments section below…

Leave a Reply

Your email address will not be published. Required fields are marked *