DogQuestionary #2: Sharing DogQ Expertise With a Highly Proficient QA Specialist

How does it feel to test a testing tool? A sincere talk with Egor Nedelko.

DogQ is all about unique people that drive our company and move it forward. Today we’re thrilled to introduce you to our brilliant, 100% talented, and highly experienced QA specialist Egor Nedelko. He is one of those people who helps create the DogQ no-code testing tool and day by day makes it better. The story of his life, the insights he shares, and the advice he gives on testing – we promise they are going to excite you. As a bonus, here you’ll find cool guides and secrets on using DogQ for various testing needs. Are you ready? Here we go!

Hi, Egor, thank you for finding the time to share your expertise! Please, tell us firstly a bit more about how do you find yourself on the IT path?

I would lie if I say that I always knew I would end up in IT, even though computers have always been a part of my life. When I was growing up, my brother was constantly tinkering with computer hardware, teaching me to assemble and disassemble PCs along the way. At times our room looked like a workshop with spare parts scattered all over the place.

As a teen, a new-found hobby got me glued to a computer screen for hours on end. I used to edit videos and do 3D modeling. By that time I was a sophomore at a linguistic university and began to lose interest in languages. They weren't challenging anymore, so I realized that after graduation I would probably regret opting for a line of work that didn’t bring me satisfaction.

I had to find something else. I knew my way with computers and had a good level of English at my disposal, so I put two and two together. Besides, in those days working in IT was something prestigious and promised very enticing perspectives. Despite the fact that for my parents, being able to establish an internet connection was already enough to call me an “IT guy”, I decided to dive into this field deeper. Thus, my journey in the IT field began.

“I had to find something else. I knew my way with computers and had a good level of English at my disposal, so I put two and two together.”

Wow, what a story! Speaking about DogQ: how did you join the team, and was it a long journey to do this?

I know quite a few stories of long and arduous roads to this promised land and I knew mine wasn’t going to be easy since I had no real technical background. Surprisingly, it didn’t take that long, but my road did have a few turns.

Following advice on how to get started, I began to study testing. However, being a good QA specialist nowadays often requires knowledge of technologies that are used to build web apps, like HTML, vanilla javascript, frameworks, network protocols, SQL, algorithms, and designer tools. As I was learning them, I became really interested in programming.

There’s a stereotype that testing is aimed at breaking an app, so to say, rather than creating something new. This idea appealed to me and I thought: “Well if I’m learning all this stuff that programmers use, I might as well become one.” So I decided to focus on that and set a deadline for myself for when to start trying to get employed.

But as days went by, and the deadline came, I still had no confidence in what I had managed to learn to become a front-end engineer. At the same time, while I studied stuff like HTML and js, and created my pet projects, my testing skills grew as well, and I realized that testing and development have lots in common. I’ve become really interested in testing.

Then one day, a friend of a friend, familiar with my situation gave me a tip on a company that was in the process of scaling and looking for a manual QA specialist. I passed the interview successfully and it would be an understatement to say that I was really excited about that.

What is working in a startup company like? And if you compare your team with a football one, which role will be yours?

First and foremost, I would say that working in a startup involves fewer people which makes it easier to get familiar with everyone in a team, build up trust and create some kind of a comfort zone. To my mind, this is a huge advantage, as I think when you work on a project with thousands of people around you, it makes you feel like your contribution to the project is minor. For many, this can be a drawback because people like to feel their work valued, and here at DogQ, we do value each other’s contributions a lot.

Also, it’s easier to get feedback in startups because, once again, you have a few people on your team and know everybody, so we often help each other, sharing some responsibilities. And when the next feature or the next deadline depends on your contribution it’s in everybody's interests that you do the absolute best that you can. So we help each other out as much as we can.

Compared to a football team, I would assume my role is a Midfield. Like these players, I can shift positions. Sometimes I stay in the rear, working on my direct tasks that I get from the dev team. But when there’s not so much to do apart from constantly running regression tests, I can be assigned to do research on some competitor for example. That makes me feel a little like I’m venturing out of my usual playfield. Or I can be asked to help with reviewing the documentation or developing ideas on possible improvements. These are more creative tasks I don’t think I would get if I worked in a huge company.

“In a startup, it’s easier to get feedback, as you have a few people in your team and know everybody. We dive into the product deeply, share our responsibilities, and help each other out as much as we can.”

What is your daily routine and role in the team? I just wonder, how does it feel to test a testing tool?

The first thing I do when I start my work day is check new tickets, features, or fixes to test, as if there are new fixes that need to be tested, it should be done ASAP, so devs can close the ticket and move on. If there aren’t any, this usually means I have some ongoing extra assignments, so I proceed with that.

When testing new features, I test everything the old way, paying attention to small details as I go through the checklist. If there are any discrepancies between the expected and the actual behavior, I make a report for one of our developers to take care of that. If not, I update my checklists to include new tests and then try to automate what I’ve just tested manually inside DogQ.

Testing a testing tool involves, you guessed it, using it on itself. We call it dog feeding. But to say that it feels special or unique somehow wouldn’t be true. It’s an app like any other and the approach I use to test it is the one I would use for any web app I guess.

Alex Zaytsav, DogQ’s CEO about the QA process in the startup that creates a testing tool:

“I would describe it as eat “eating your dog food”. So while we as any startup have to sacrifice some of the best testing practices in favor of development speed we are still paying a lot of attention to the quality of our product. And we are taking that to the next level – testing DogQ via DogQ. We have an established process from identifying test cases to reporting and fixing any issues. And any issue found is getting its own Scenario so the same bug never gets to production twice. It helps us to be confident in every release and ensure that everything works as expected. But besides that it allows us to understand our customer’s pain points and how to improve our product overall.”

By the way, what is your personal testing method? How do you strike the right balance between manual and automation testing to cover the full functionality of the app?

Nothing fancy, really. I follow some well-known principles:

1. Firstly, I believe that you need to get a good account of the application you’re testing, and really go deep into its workings to be able to test it well.
2. Next, it’s better to approach the process according to the “divide and conquer” rule. It’s about splitting the app into manageable pieces and testing them one by one.
3. Then goes, of course, system testing with creating tests depending on the results of other tests and so on.

Striking the right balance between manual and automated is very important. Some areas can be less suitable for automation than others. Of course, I try to push the envelope about what kind of tests I can automate, but when I need to create a test and it’s not that really suitable for automation, I ask myself is it worth the effort? Or should I rather develop an algorithm for how to test this thing by hand quickly and efficiently? And if everything hints at the latter, I move the test to the “manual” checklist.

Thus, I think striking the right balance is simply to automate tests that can be automated, test manually those that can’t, and distinguish one from another. Sometimes, I double-check something manually to see the process with my own eyes, and to stay in touch with how everything looks on the site. It’s really important because it can be easy to fool yourself with the thought that everything can and should be automated. Well, it can’t. Not yet at least. And if you try, I think you’re bound to face some unexpected mishaps and risk ruining the final result.

“I think striking the right balance is simply to automate tests that can be automated, test manually those that can’t, and distinguish one from another.”

Let’s talk a bit more about the DogQ tool functionality. From your point of view, what is the core advantage of using DogQ if compared to manual testing?

Automated testing surpasses manual tests by a huge margin. It’s designed to do the job more efficiently in terms of time and resources. By saving time, automated tests help boost coverage and get continuous testing, which would be almost impossible to do otherwise.

Also, it’s about precision. When doing things by hand, you always need to include the human factor: a chance you misclick or make a typo, somehow fail the test, force a redo, or even worse – not failing it, but simply not testing something properly. With DogQ you carefully build the test once and it will precisely repeat the instructions every time you click ‘Execute’.

For me, DogQ is also like an organizer. I find it incredibly useful to have all my tests and checklists in one place, structured into projects and modules, where I can edit them at any time. This is much more convenient than storing everything in separate text documents and tables.

“With DogQ you carefully build the test once and it will precisely repeat the instructions every time you click ‘Execute’.”

What is the most valuable feature of the DogQ testing tool from your point of view? And which feature do you use most frequently?

Hands down the most valuable feature for me is the ability to schedule test executions. Basically, you tell DogQ what tests you would like to run, and how often you would like to run them, and it does the work for you.

However scheduling wouldn’t be as convenient and robust if other key features weren’t in place, so make sure they are. The same goes for the ability to pack scenarios into modules. The bigger the project, the more test scenarios there will be. So instead of picking certain scenarios in the project for regression tests and scheduling them one by one, we can put these tests into a separate module and schedule them once. Of course, if each scenario is working properly.

Also, DogQ allows you to set notifications. Every team member can configure in what cases they want to receive notifications and where they want the notifications to be sent. The combination of the above-named features works wonders, freeing your time and headspace for other creative tasks you can get involved in.

“You tell DogQ what tests you would like to run, how often you would like to run them, and it does the work for you.”

Please, imagine that I’m a DogQ user with a need to test a complex cloud-based app with numerous features. What is the best way to do it? Where should I start?

To be clear, there can be no ultimate guide to testing: after all, every project requires its own approach. But let’s try to make a generalized step-by-step guide that you can use as a starting point while creating your testing strategy.

• First and foremost, read the documentation of the app you’re going to test and develop a test plan;
• Then split the application into modules and make checklists for every meaningful feature and element in these modules. The first list, of course, should consist of checks that everything works as expected;
• After that, think of ways to break the app, negative tests can shed light on various unexpected vulnerabilities;
• Don’t forget to take care of security: include all the common validation checks, then try to look at the app from a hacker’s point of view. This may require some knowledge that is not common among QA specialists, so consult your colleagues.
• Your checklists should continue to grow as you look at the app from different angles. When all is set and done in terms of the planned tests, allow yourself to explore. Do some monkey testing, observe and follow your intuition. Complex applications have lots of features and the more features they have, the more situational relations there can be. A feature might work as expected, but if you mix in a random toggle, a button, or some other condition and then try the same feature, it might surprise you.

“When all is set and done in terms of the planned tests, allow yourself to explore. Do some monkey testing, observe and follow your intuition.”

Continuous testing is a very important part of Quality Assuarance so it’s paramount that you create a module of regression tests. These should be atomic and independent of others as much as possible so that you don't experience ‘Failed’ statuses due to the order of execution or unmet preconditions. Schedule the module and let DogQ keep an eye on the app's core functionality.

When the dev team implements something new or fixes a bug, don't shy away from executing this module by hand – this won't affect the schedule. From time to time, do it the old way. This helps to stay in touch with the subject matter and almost always helps to find something that automated tests did not cover.

Finally, a word of advice for newcomers to QA: if you're new to a project, establish good connections with the team. It's not something that learning courses teach, but as a tester, you will be talking to your team a lot.

From your experience, what is an ideal way of using the “testing in team” feature? And when is it better to work on your own?

I think teams in DogQ make the most sense with big applications and testing scopes. Obviously, you don’t need help with clicking the “Execute test” button, but you certainly can benefit from having extra hands when it comes to creating tests. Having more people on your team can boost the creation of your suites drastically. On the other hand, I think working alone can be more suitable for smaller projects. DogQ can perfectly cater to both scenarios.

Can I reuse the once-created test case in other scenarios? Can you, please, explain in plain words, what is the Macros function and how to use it right?

Macros is a set of steps packed into one, which you can insert into other multiple tests. It’s easy to use and can be ridiculously efficient in optimizing your test scenarios. The general idea should be “one macros – one action”.

An obvious example is logging in. From our experience and feedback, in 90% of projects in order to test something on a website, you need to sign-in first. Even the simplest sign-in form involves entering your e-mail, password, and clicking a button, which in DogQ transforms into about 6 steps. Now imagine adding these steps to the beginning of all of your tests. And what happens if you change your credentials at some point?! With Macros, we can pack all the steps related to logging in into just one step. To push the automation even further we set the Log In macros as the Default First Step in the project settings.

That way every scenario we create will already include it, which means we can forget about the routine precondition and focus on the test itself. And if for some reason you need to change your credentials on the site you’re testing, you make the respective adjustments to the macros and it updates the values in all the tests it’s used in.

What are the DogQ features you are working on right now? Can you share with us your plans for the upcoming releases?

We’re constantly analyzing the feedback we receive to get a better understanding of what we can improve and prioritize features on our roadmap. One of the things under development right now is a test recorder. It will allow users to play back the execution of their tests and we hope it will become a powerful tool that will be able to help users navigate their way through complex scenarios.

Also, soon we will be introducing tools for cross-browser testing. It will be possible to run the same tests in different environments and via different browsers. With such a feature DogQ should outclass its competitors as far as cross-browser testing is concerned.

Plus, we’re now exploring new marketing and review platforms to present DogQ there in the nearest future, collect more feedback, and see how we can make our customer experience even better. This means a significant piece of work including content update, and maybe a design overhaul of our documentation section, as well as some other user assistance features. But we are ready for it, as we want DogQ to be as welcoming and user-friendly as it can be.

“We’re constantly analyzing the feedback we receive to get a better understanding of what we can improve and prioritize features on our roadmap.”

By the way, how do you see your work routine in the long term, when all testing tools have become automated or even codeless? Is this a positive or negative scenario?

Indeed, automation of testing is developing in leaps and bounds with no end in sight. I think QA specialists are generally okay with that. I believe there’s always going to be stuff you can’t automate the testing of. Besides, codeless or not, creating an automated test also takes time. And at a high development rate, there are always things that are changing, so building tests for those will require some manpower.

In general, automated tests have made our job a lot easier, allowing us to forget about endless monkey testing and boost test coverage with fewer resources than before. So, whatever heights test automation reaches in the future, I think this is a good scenario.

“Automated tests have made our job as QA specialists a lot easier, so whatever heights test automation reaches in the future, I think this is a good scenario.”

Thanks a lot for such an informative and exciting interview! As a top QA expert, what else recommendations can you give to DogQ users?

Even though DogQ is not rocket science, ideally, you should start with our documentation. There is plenty of useful information on how to use the product as well as guides on some advanced techniques to further improve your workflow.

We have a trial period you can use to play around with the tools and explore the functionality. And you really should! Mastering the power of codeless test automation will enable you to do a lot more in a lot shorter time span. And all that without even knowing the first thing about code and all the technologies web apps are built with.

If you find yourself at a loss or face any questions you can’t find the answers to in our manual, feel free to contact us directly. There’s a designated form at the bottom of the main page. Our team will be glad to help you resolve any issue!

Alex Zaytsav, DogQ’s CEO about Egor Nedelko:

“As part of an early startup company, Egor is not only one of our QA engineers but a jack-of-all-trades. He ensures overall product quality, helps to understand and define the future roadmap, writes the documentation and, what is the most unique about Egor’s day-to-day work, supports our customers, and helps them to be more efficient with DogQ. We can’t be happier about Erog’s contribution to DogQ and he is a very valuable member of our team.”

* * *

This is the end of our interview with a bright QA specialist Egor Nedelko. How did you find it? What insights have excited you most of all? Did you find something that resonates with your experience? Please, feel free to share your thoughts with us on LinkedIn and Twitter, we’ll be happy to discuss them all! Plus, if you have any questions concerning our product, DogQ no-code testing tool, feel free to ask them, and our specialists will give you a professional consultation for free.