Domain testing is the most frequently used strategy among QA specialists. The different kinds of domain-based testing techniques are used for checking all kinds of programs and applications you may think of, from the simplest games to the most complicated banking equipment. How is that possible? The answer is very simple. QA specialists can’t afford to run all the existing test to define possible weaknesses. That’s why they choose a couple of powerful tests that are going to represent the rest – the most likely and the most dangerous hypothetical situations. Here is your simple explanation of domain testing in software testing with example. What is domain testing? Domain testing is an approach based on dividing the range of possible values of a variable into sub-ranges (software testing domains) with the subsequent selection of one or more values from each domain for testing. To put it simply, in domain testing you think about all the possible tests of certain functions, then group them into sets of smaller tests. The next step is to check cases from each subset, one by one. Input domain testing uses a minimum number of inputs to check the output of a system. The purpose of this process is to prove that the tested system will accept only certain inputs that lie within the acceptable range. The system is expected to deliver the required outputs only and block any invalid input values. Everything that happens between input and output is a mystery at the beginning of the process.                             Despite the wide range of fields for application, the significance of domain testing in software testing methodologies shouldn’t be underestimated. This technique helps to reduce the range of tested values without losing the effectiveness of testing. The correct application leads to a decrease in the number of tests without affecting the quality of testing. What is domain software? Let’s take, for instance, the financial sphere. Banking apps can be used by a wide variety of people regardless of their occupations or other things. The solutions developed specifically for banks and corporations that specialize in finances do belong to domain software. These are the programs that make the functioning of those establishments possible and won’t be used anywhere else beyond. Just like that, health apps you download on your smartphone are not domain software, but the programs installed on hospital computers and tablets are. What is meant by domain knowledge? Domain knowledge is a good understanding of a particular sphere. It means that a person is familiar with specific terms and different nuances of the discipline. Domain knowledge is a huge advantage for a QA specialist. It helps to reduce the delivery cycle and shorten development time, improve customer service and enhance flexibility. Very often this value doesn’t expire after a particular project ends. For instance, payment domain testing is a part of numerous systems. For some spheres, domain knowledge is extremely significant, like online banking, retail, healthcare system, etc. So how to get domain knowledge in testing? QA specialists acquire skills and experiences, both theoretic and practical during the working process when trying to get a better understanding of a product you are working on. It is also useful to read specialized literature and check similar software. What are domain bugs? It would be logical to suppose that domain bugs are the failures determined during domain testing, and that is true. Nevertheless, you understand this better after you find out how to test for them. Every domain is defined by its boundaries. It means that during this kind of tests, QAs work with the points located near directly on the borderlines. Each point allows checking at least two domains at a time, sometimes even more. We focus on different kinds of points to determine all the potential risks: Interior point with all other points that are within relatively small distance located in the same domain. Boundary point has neighboring points both inside and outside of its domain. Extreme point lies between two distinct points of the same domain. On point is located straight on the boundary. Off point is close to the boundary but usually in the adjacent domain (in close domain boundaries).                                     Domain Testing Strategy A testing process always starts with a question. What is the banking domain in software testing? What is insurance domain testing? What domain knowledge does a QA specialist need to handle this specific case? Every domain has boundaries by which it is defined, and points situated near those boundaries are checked during tests. Domain testing strategy is an attempt by a QA specialist to find answers to the questions: What domain should be tested? How to group the values into classes? What values should I test? How am I going to determine the results? Domain testing structure Each software solution has specific points to pay attention to. It is important to identify the variables that are potentially interesting and order them. It doesn’t matter whether a QA assistant decides to start from the smallest and move to the largest or vice versa. When it comes to building the strategy, the process is quite universal. There is a simple step-by-step structure that fits every testing scenario: Decide what can go wrong with boundaries. Find the way to handle each case. Pick several points to test for each recognized error. Use one test point to check the adjacent domains. Check off redundant test points. Start running the tests. Determine if any boundaries are faulty. Verify each boundary of all the domains. What is domain testing with example? The best way is to explain domain testing with example. You already know that the process of input domain testing is about selecting a limited number of test cases from a huge group of possible scenarios (nearly infinite, actually). Some QA experts explain it as a table you are to fill, just like the one below.            Let’s imagine a real-life situation. There is a group of children and a list of activities. They will be awarded tickets to a theme park (or any other entertainment facility) for performing a certain activity. Each will receive a ticket based on the gender and age inputs. In general, the whole entertainment functionality is subjected to the test. Ticketing is one of the domains, on which we are going to focus. Age parameters will be our boundary values that allow building numerous possible scenarios. This is what we know currently:   Children younger than 5 years old are to tell a poem. Boys between 5 and 10 years old are to draw something. Girls between 5 and 10 years old are to sing a song. Boys older than 10 are to compete in sports. Girls older than 10 are to participate in a quiz. Everyone older than 15 is to write an essay. Based on the described above algorithm, a QA specialist groups the values into classes – age groups. After that, it is time to pick the boundary values – the highest and the lowest age value in a group. The next step is building scenarios with the expected results for each. Schematically, it will look like this:   Domain testing by UTOR Domain testing in software testing is a simple and challenging task at the same time. This strategy is based on knowledge, experience, sometimes on creativity and serendipity. The domain testing example explained above proves that QA specialists have some superpowers – to predict software behaviour and protect users from troublesome situations. Worried about insecurities the boundary points might hide? Just leave a message, and we’ll check your product for domain bugs and likely behaviours. https://u-tor.com/contact

More and more clients finally start to realize, how significant testing for a successful release. However, the number of those who remain skeptical and focused on so-called cost-efficient solutions still remains huge. Our current task is to educate a client about the meaning of QA assurance, the mission of a tester, and persuade that testing matters as much as the development. We help to understand if client spends too much or too less on testing. It is not a simple thing to do. Thus, we decided to share some tips for the successful start. #1. Global turnover Numbers are the best argument, especially when it comes to budgets. Nowadays, the global QA & Testing turnover in the field of development amounts to $45 bln.  Why is this number important? It means that all companies, starting from startups and ending up with giants like Apple and Facebook, have QA departments, which control the quality of development. It is an integral part of the development process, highly valued in terms of efficiency and money.   #2. Simple math when a developer/PM tests a product Usually, testing employs around 25-40% of the development time. Let's suppose a developer is going to spend their time on testing all possible cases. Instead of working on the new features for your business product, they are preoccupied with tests. Don’t forget that a developer’s rate is usually 30-40% higher than a QA engineer rate.  You don’t have to be a genius to realize that hiring a QA specialist is not extra expenses. It is a way to save money. Taking into account the fact that an average dev salary is around $5,000, you can save ~1600$. #3. “Earlier” equals “Cheaper” The earlier testing starts, the low development costs are. The price of a mistake is decidedly higher if detected at the end of testing. It is very important to have a team member, who will take care of quality control as the development process unfolds. A QA specialist will keep the product in good condition and prevent the issues that can potentially delay the delivery and mess with the deadlines. Once, we faced a five-month delay due to a crucial security issue detected by a QA engineer before the launch. Obviously, involving a QA at the beginning is a good decision. #4. Performance testing case Here’s a prominent real-world example. There was a case when a website could handle only 1,000 users, although a marketing team expected to have around 1,500 visitors. Consequently, 30% of clients weren’t able to use the website due to performance issues QA engineer could have detected if they had a chance.  30% of users had glitches and experienced problems with website loading. One lead costs approximately 10$, so around 500 of wasted leads accounted for $5,000 negative payoff. The client would spend much less on QA engineer, who would easily detect such issue. #5. Compatibility testing A potential client couldn’t leave contacts due to the compatibility issues on your website or mobile application. The thing is that only QA engineer can do a professional compatibility testing and provide the guarantee that an app works well on the specified devices and browsers. And who knows, maybe that lost client could have changed your business. So it's better to be sure that all browsers and devices are covered, and your potential clients won’t work with your competitors due to some issues on your website. #6. Automation testing Automating testing is not a panacea but sometimes it helps to decrease the time of releases and increase the quality of a product.  Let me share a few numbers. A Manual tester spends 10 hours on regression testing. An Automation tester can pass those tests in 20 minutes. Simple calculations will show that you can save ~ $500-1000 on testing during the next months.  #7. Mindset dilemma Some are wondering: isn’t a developer expected to write apps in clear code with no issues? Yes, in a perfect world. The reality is rather harsh, and clients often don’t take into account the differences between a developer’s and QA’s mindsets. A developer’s job is to build. Their main target is to resolve a task by the means of the code. A tester focuses on checking and challenging this code. Testers simulate various cases and scenarios to prevent troubles and ensure high quality. Their purpose is to find mistakes or trigger them. A developer is responsible for the code, while a tester takes care of the business logic and a user. QA engineer prefers to walk in user’s shoes and report what is super nice and what is far from the perfection.   #8. The area of responsibility Every tester is a professional in his area. Often QA engineers specialize in a particular field they have learned and practiced, for example: functional (business logic); compatibility; security; performance; and usability. While a tester can switch between these types of expertize, a developer isn’t able to provide the testing in all of the spheres above mentioned in a professional manner. It is a completely new world for a developer, while a tester does it professionally. #9. Draw an analogy  Web development functions exactly like a factory. In particular, each has a quality control department. Now, imagine that this part is excluded from the factory. What results do you expect? And what’s important: will you rush to buy their products?   #10. Fuckups happen You can click here to discover an insightful story about little bugs that destroyed products. Ironically, they were likely to be detected by QA engineers. Fuckups happen, but don’t be the main reason.  #11. Be honest to people There are three types of companies: Those that include testing into a development rate in a secret manner.  Those, who propose to invite a QA engineer to a team. Those, who don’t test their product.  The first ones don’t even discuss this aspect with a client. They hire a QA engineer immediately and secretly include the payment in a developer’s rate if needed. When you see that it is extremely difficult to explain who is QA and what is their contribution, go with it. Honestly speaking, we are not the fans of such strategy; we belong the second type. We aim to build clear communication and explain everything to our clients. The third group is very likely to fail. This is how you risk to end up with a three-star (or even lower) rating on Google Play and App Store. In case you want to get more insights - book a call here with a person who wrote this article - Sergey Smaglyuk -  https://calendly.com/smaglyuksa/30-minute-meeting 

“Hey, Sergey we need your support with Software testing asap.”  This message initiated a start of our UTOR company story. Such message was normal for me when I was a freelancer as QA engineer (2015). Too many requests and willing to help more people with the quality of their IT projects pushed me to launch UTOR company a few years ago. When I was a freelancer I had a chance to travel a lot. Honestly speaking it was my dream when I worked in an office - "Travel and work at the same time". So I achieved it! Bali, Ibiza, Gili islands, etc. was a normal workplace for me during few years.  However, after I reached my goal, I created a new one - help people launch their projects without making significant issues at the beginning of the projects and during development. Btw… The main issue of founders is “thinking that QA is a last phase of development”. It's a popular thing for startups. I will write a whole post about it later. So…. So now I am CEO of  UTOR company, I love our current goals, my team, our clients, our speeches at conferences and everything that related to it! I enjoy building such a baby with our team. Thanks, team and our clients!  Sergey CEO of UTOR