We’re happy to announce a series of insightful interviews with HYS Enterprise experts – developers, testers, software architects, project managers, and other specialists – who will share their professional and industry-specific knowledge. 

We’ve gathered questions only experts with hands-on experience can answer. Our team members will be answering these questions to help you dive deeper into issues and get a better understanding of our company’s processes. 

Meet Vladimir Arutin, QA Engineer at HYS Enterprise, ISTQB® Certified Test Manager (Advanced level), and a certified quality assurance training instructor.

Over the last three years, Vladimir has specialized in various methodologies and software testing technologies including Test-Driven Development (TDD), Behavior-Driven Development (BDD), continuous integration, and manual and automated testing. He’s constantly learning new things and has experience teaching, mentoring, and participating in various QA conferences as a speaker. 

Vladimir will answer five questions to give you valuable insights into what quality assurance is and how it’s done at HYS Enterprise. His answers will help you make a more informed decision about how to build effective testing processes for your project. Without further ado, let’s go to the interview. Enjoy! 

What’s the optimal ratio of testers to developers on a project? 

There’s a lot of buzz around this question, as it impacts how fast and successful the entire development process is. Getting deeper and deeper into this issue, you can find various answers: from 1 tester to 3–5 developers to a staggering 1:1 ratio, which at first sounds impossible. 

The truth is, there’s no optimal ratio. It’s not even that testers may differ in experience and professional and domain knowledge. The reason is that every project is unique and requires an individual approach. The structure and teсhnologies, size, timeframe – all of these factors are different for every project, and they influence the required number of testers and developers. Moreover, with projected growth, the need for resources changes.

Every time we decide on how many testers to get involved in a project, we proceed from the scope of quality assurance tasks, not from the number of developers.

The main indicator I use during such an assessment is ROI (return on investment). The value achieved from implementing some testing activity (as well as from adding a new team member to a project) should significantly exceed the costs. This approach allows our clients to understand what they pay for, what benefits they gain and why.

What projects need test automation (and which can go without it)?

Test automation – as well as the Internet of Things, artificial intelligence, big data, the blockchain, and cloud computing – remains one of the major trends in software development. At the same time, that doesn’t mean every single project needs it. 

You can be 100% sure that you need test automation if: 

Your project lasts a year or more. The number of tests you need to execute during regression testing grows steadily, which translates into a huge load of routine tasks. And routine tasks are what you should get rid of immediately. Testers should test, not perform the same test cases all over again.

You maintain several versions of the product and release patches and service packs for each. The reason in this case is evident: testing of different configurations is a routine. And, as we know, they must eradicate routines.

You develop a service focused on processing and transforming data. Manually entering data, visually analyzing results, sending requests, and analyzing responses are the last things humans should do every day. They’re jobs best left to computers. Moreover, if your project requires frequent load testing, manual testing would be helpless and inappropriate. 

You use an Agile development methodology with short iterations and frequent releases. In this case, the project grows steadily, and there’s no time to execute regression tests manually during sprints. At the same time, it’s crucial to know that everything works correctly, especially in places where testers didn’t check. 

When using test automation, it’s necessary to combine UI and API tests smartly. All functional tests (negative, positive, pairwise, etc.) should be moved down to API level. At the UI level, we should only use acceptance tests, which are known as Happy Path or End-to-End scenarios.

However, it’s important to recall that you shouldn’t – and can’t – automate everything and completely eliminate manual testing.

Automation should be seen as medicine: use it only when you have reasons and when it makes sense for you. Always remember that unreasoned and baseless automation ‘just for fun’ may simply turn into a waste of time and money.  

What does the quality assurance process look like at HYS?

We all know the expression fail to plan, plan to fail. That’s why all the main activities and resources of a project, as well as entry and exit criteria for testing, are captured in a test plan.

From there, we start defining requirements. At this stage, we analyze requirements, assess possible risks, and set priorities. Then, based on test conditions, we design tests and assess test coverage. Right after the test implementation stage, when the test environment, test suites, and test procedures are ready, we embark on testing.  

But that’s not always the case. Sometimes we have to work in very short iterations and with frequent changes, so we don’t have time to write low-level test documentation and plan in detail. In such cases, we act like a SWAT team – distinctly, quickly, resolutely and calmly, applying mainly experience-based test techniques and putting first things first.

During the testing process, we collect various metrics, create required work products, and report the status of quality assurance activities. The goal of all these steps isn’t just to verify the workability of a product or system. It’s to prevent defects, enhance the product, and improve its quality based on the principles of software testing and best practices we have.

What is continuous testing and what projects need it?

Continuous testing is a strategy for evaluating the quality of a product through every step of the Continuous Delivery process.

The goal of continuous testing is to test early and test often – to test everywhere and automate. 

During this process, automated tests are executed as part of the software delivery pipeline to obtain feedback on the business risks associated with a software release candidate as rapidly as possible. When you test continuously, you test on an ongoing basis, from unit and integration testing to production testing and live testing. 

Continuous testing is used for projects that use the Continuous Integration process, where application architectures are increasingly distributed and complex, where applications are released from every two weeks to thousands of times a day, and where the time available for test design, maintenance, and especially execution decreases dramatically. In such complex systems, an application failure is a business failure, and the main goal of continuous testing is to get continuous feedback regarding the level of business risk in the latest build or release candidate as soon as possible.

What are the top five factors that make quality assurance successful? 

From my experience, there are a huge number of factors that determine if the QA process will be successful. However, here are the most crucial points I’d like to highlight: 

Proper planning of all testing activities. As the saying goes, “there’s no favorable wind for the sailor who doesn’t know where to go.” Planning the budget and required resources well, building a strategy, and defining approaches and testing tools are the keys to success for each and every development project. 

Communication. Whether it’s communication with a client, management, third parties, or inside the team, communication is one of the most important things if you want to build smooth and efficient processes. The art of understanding each other, interpreting each other’s words correctly, asking questions, and getting timely answers is what I call good communication. When each member of a project is on the same page and has a common vision, the entire process is set up for success.

Teamwork. Much like with a football team, where you can invite the best stars and well-trained players to the team, in development, you can hire engineers with the perfect skills and proper knowledge. Either way, you’re doomed without teamwork. Interoperability, teamwork, and dedication to a common goal are what make a dream team, and they’re some of the key factors of successful testing and development in general.

Skills and knowledge. Professional and domain knowledge, as well as technical and soft skills, also have a great impact on a project’s success. It’s crucial to be agile, to be able to flexibly adapt to changes and have the potential for self-learning. That’s why our engineers study a lot and try to sharpen their skills by gaining versatile hands-on experience.

Desire to go the extra mile. One of the most important principles that differentiates us from other companies is our commitment to anticipate and exceed our clients’ expectations. We want to do more, do it faster, reach the best quality possible. Each project is like a child for us. We completely dedicate ourselves to it and we want to give it our best experience and knowledge.

We’re responsible for this project so we do more, better, and in advance. This extra service and caring attitude to a product have long been an unspoken rule at HYS.

We don’t just test software; we offer full-cycle quality assurance services and always exceed our clients’ expectations. Based on our experience and skills, our clients get not only good performance from us but also solutions and ideas. We help them solve their problems and develop their vision. That’s why we are called HYS Enterprise, and that’s really the way we’re Helping You Succeed.