30 Mar
Dive into the world of Quality Assurance Specialists - interview
NetInteractive continues to grow. In 2020 we expanded our team by 19 people. During this time, our quality assurance department also grew, which now results in up to 9 employees. Therefore, I decided to talk to them about their work to help the rest of the team and clients (not only ours) understand their role in software projects.
The ideal way to get to know them better and find out what is important to them in their work and how they perceive their job was to interview them.
Below I present their answers and invite you to meet the NetInteractive Quality Assurance team, not only from the professional side, but also to notice their character, sense of humor and friendly relations that were born and developed in our company.
What is the role of a quality assurance specialist?
He is primarily responsible for verifying that the software and the system are working properly. In part, his responsibility is to detect bugs and defects and then report them to the development department. Testing is very important before any change or update to the software. It can be said that the QA specialist is a member of the software development team and acts as a complement to the work of a developer, who would find it difficult to predict, where in the software, bugs can appear and unexpected failures may occur.
The software QA specialist deals with ... software testing 😅. However, it is not only about the so-called clicking and looking for bugs - he also prepares scenarios and test cases, reports found bugs and checks if they have been fixed, participates in team meetings, etc. Some QA specialists write and maintain automated tests, where programming knowledge is also required.
It seems to me that the main task of a software QA specialist is to ensure the quality of the product. We cannot allow uncertain functionality to be released to the client. The most important thing is to cover as many test tracks as possible. It is not known whether, for example, the reverse order of adding products to the basket will not affect the amount of the discount that should be charged. So, to sum up, it is the QA specialist's responsibility to anticipate and test every possibility of the given functionality and verify it. The more test cases covered, the lower the risk of errors after a production run.
The QA specialist primarily tests the patience of developers, product manager and client 😉, but seriously, apart from the obvious activities of finding and reporting bugs, he also has to face the pressure to finish as soon as possible. You need to be able to find a compromise and know when you can actually give up some tests in the name of meeting deadlines, and when you have to stand your ground and say that a given thing cannot be delivered on time.
What is the difference between manual tester and automation testing specialist?
Manual tester, as the name suggests, deals with testing performed manually by a human. To a large extent, his work environment does not support any additional tools or scripts. In this case, his responsibilities do not include knowledge of scripts and programming languages, but on the other hand, his work often seems to be quite time-consuming.
In automated testing, the tester performs tests using dedicated scripts and appropriate software. This method allows to adequately execute tests in a short time and with high repeatability. Therefore, the test machine gives us only information about how the system behaves in standard use. Sometimes it is necessary to analyze them and repeat the case manually.
An automated tester is more of a programmer because requires some knowledge of coding and understanding of the environment in which we work. Manual testing is nothing more than clicking tens, hundreds of times similar paths looking for errors. I have the impression that most people with an analytical mind, willingness and determination to work can become a manual tester. All you have to do is to be willing to break something, describe how you did it and the work is done by itself 😉.
The manual tester differs from the automation tester in the way the system tests are performed:
- The manual tester goes through the test scenarios by himself - 'clicking' everything on his own
- The automation tester creates code which, when run, performs the steps defined by the tester in a much faster way than a human.
But it seems natural to develop a manual tester into an automation tester as you gain experience, NetInteractive gives you such a possibility😊.
The boundary is quite fluid, but it is commonly accepted that a manual tester is a "clicker", i.e. a person who imitates the end user and tries to detect errors that the user may encounter. An automation tester has a different range of skills, because apart from what a manual tester can do, he must also have knowledge (at least basic) about programming and writing scripts. However, there are more and more tools that allow you to create a simple test automation (eg Postman) that a manual tester can deal with, so I wrote that "the boundary is quite fluid".
How do we know if the current software behavior is correct or it’s a bug?
The workflow of work in each project is different, first the analyst describes the task and hands it over to the programmer for implementation. Once the implementation is complete, the task is handled by the QA specialist. Any behavior that he perceives as abnormal can be consulted with the developer. However, usually the QA department is involved in a project, from the very beginning of the task, so they know how the functionality should behave.
The QA specialist should be in the project from the beginning of designing new system functionalities, so that he knows the client's requirements, but also actively participates in this process, ensuring additional quality and his own perspective. QA specialist's task is also to create documentation and test scenarios so that later on it is easy to find out what the customer wanted to achieve and how a given functionality is supposed to work.
What is the biggest challenge in the QA specialist work?
Of course, it all depends on what you are currently working on and on what project. There are some lighter and quicker tasks to complete and some more difficult things for a few hours, but overall I think the biggest challenge is to keep patience, because doing the same thing over and over again, sometimes countless times, can be counterproductive.
The biggest challenge may be the monotony of the work, spending a few days on one task to cover it with test cases, in a percentage at least close to 100%. The more time we spend on one task, the less opportunities we see. It happened to me that after 4 hours of testing a given functionality, I reported that the project was ready for deployment without seeing a typo in one of the main headers.
Could you please tell me what would happen if there was nobody from the QA department in the project?
It seems to me that the QA specialist not only tests the software, but also cares about the quality of work throughout the project. By paying attention to the smallest errors in management and design, it reduces the risk of corrections later in development. The answer is simple: If a QA specialist wasn't there, at least one more developer would be needed 😊.
The lack of a QA specialist causes, among other things, that errors that could have been caught and repaired in advance, get on the so-called "production", where their occurrence and repair causes much higher costs. The general rule is that the earlier the defect is caught at the stage of software development, the less expensive its repair will be.
Chaos, death and destruction...and more bugs 😅.
How to know when we should stop our testing?
In testing, it is assumed that testing never ends. The lack of a defined end-of-test criterion means that testing is never-ending, so the costs associated with it are also infinite. Following this line of thinking, we can come to the conclusion that the price of testing is so high and frightening that testing becomes invaluable. A good way to determine the cost of software testing may be simply asking a question in the direction of a potential customer:
How much would you like to spend on testing?
Then we will be able to tell him what we can offer. The moment of completion of the tests may also be determined by:
- exhaustion of funds for further tests or project,
- time for testing elapses,
Therefore the test termination criterion should always be a product quality level, sufficient enough for public presentation.
Only the tester should decide about software testing. Meeting deadlines can be problematic, but if there is a vulnerability in the functionality, it should be corrected before releasing the version to the customer. If most of the test cases are covered and the functionality is found to be correct, it is a sign that the testing can be finished.
The moment when testing should end is most often determined by the so-called termination criteria - which include, among others: cost, schedule, measures of diligence (code/functionality coverage, etc.), however, in practice, software testing often never ends, the projects/functionalities that are tested just change.
Software testing should only end when the work on the system is complete and a certain percentage of the total system is covered by tests, of course in practice there is also the financial aspect and this cannot always be achieved.
Final words
To sum up, I hope that the above text will make our customers more familiar with the work of our QA department and will allow them to appreciate their value and importance for projects. I also hope that our QA specialists, while reading this article, will appreciate their own skills as well, and see that they all look at the same things in a similar way.
Przeczytaj polską wersję wywiadu:
Related Post
We're 5* rated on:
We're 5* rated on:
