Table of Contents
At SoftTeco, we always pay close attention to the Quality Assurance process as it’s one of the key success factors for any software project. We also noticed that some of the clients are not fully aware of the intricacies of QA and tend to overlook its importance when it comes to project management and team composition. Hence, we’ve held an interview with Vera Klimova, one of SoftTeco’s leading QA engineers, and asked her questions that our clients most frequently inquire about.
What’s the biggest misconception that clients have about QA?
For some reason, a lot of people believe that the main responsibility of a QA specialist is to find all the bugs before end-users receive the product. So if there is a bug found after the product is released, some clients are really surprised and think that QAs failed their job.
While debugging is indeed our biggest responsibility, there are many factors to consider in order to fully understand how the QA process works. Even if the QA specialist is a great professional with amazing skills and knowledge and he covered the whole product functionality with tests, there is never a 100% guarantee that the end-user will not find a bug. Why is that? Because there are dozens of options of possible devices + Internet connection + other factors – and all of them impact the way the product will look and function.
And if new functionality is added to the existing product, there is always a risk that this new functionality (100% covered with tests!) will “overlap” the existing (also 100% working) functionality and break it.
In order to ensure that new features do not damage existing ones, QA specialists perform regression testing but it can be quite bulky and time-consuming – and the QA process is often tightly limited in time.
What should every client know about QA, in your opinion?
I believe the main thing that clients should always remember is that the QA team has to be introduced to the project at its early stages and not after completing the development phase in order to understand if the product is ready for release or not. If you attract QA at late stages, you will risk the product’s quality and time of delivery.
The reason for that is simple: QA specialists need as much time to prepare and perform testing as software engineers need for product development. The main processes that the QA team works on include analysis and requirements gathering and specification, planning of testing, creation of needed testing environments, preparation of documentation, and testing itself. As well, we also spend some time writing reports and this can’t be omitted because the client wants to know about the progress of testing and its results.
What are the most common issues that you faced in the projects?
One of the most common issues that I come across is out-of-date documentation or lack of it. Here are the reasons why updated documentation is so important. First, it significantly facilitates the onboarding of new employees on the project. Second, it helps reduce the testing time because otherwise, a QA specialist will have to spend too much of it searching for the point of truth. It often happens that a QA specialist prepares test cases for documentation, starts testing, finds way too many inconsistencies, and marks them as bugs – and then it turns out that the documentation is simply outdated so there are no bugs. If such things happen, the QA specialist will have to go through the whole process once again from the start and will also have to learn about the current requirements for the system beforehand. This is why updated documentation is one of the factors that contribute to better testing.
What’s your recommendation for the clients who plan to start a software project?
For sure, my first recommendation is to work on the project documentation from the start. This documentation should contain information about product requirements and it should contain regularly updated requirements, mockups, and prototypes.
As well, it often happens that the development lifecycle gets prolonged and it takes more time to write code than was intended. In such cases, there is less time left for testing and it obviously hurts the product’s quality. Hence, my second recommendation is to always perform time estimation with QA specialists and never cut off their time in favor of coding.
With whom do you work the most: BAs, PM, engineers?
I’d say with everyone because QA specialists constantly communicate with the whole development team, including business analysts and project managers. Here I’d like to state how important communication is: it improves the overall atmosphere at the project, lifts team spirits up, and helps everyone stay on the same page.
As for more personal questions, what do you love most about QA?
I really like the importance of the QA job and the role of QA on the project. QA engineers often have the last say in making a decision on whether to release the product or not. And it’s the responsibility of a QA engineer to provide a report on performed testing and inform all parties involved whether a product is ready for release. QA specialists also provide arguments on whether a product must be fixed before the release or it might contain insignificant bugs and still be released.
Another reason why I love QA is due to permanent communication with different professionals, from developers to clients. Such a wide circle of professional communication helps me constantly improve my soft skills and technical knowledge.
It is important to state though that some of the tasks can be quite monotonous and one has to be ready for that. You often need to check regression testing and it’s normally a big scope of one and the same cases that a QA engineer has to go through to ensure that the existing functionality works as intended. This can be quite boring but there is a solution – you can automate all possible cases so the process goes faster.
Tell us a bit about your QA course: why did you decide to start it and how was the overall experience?
(Vera started her own QA course a while ago and it’s been highly popular among those wishing to start a career in the IT industry)
I decided to start a QA course because I saw a high level of demand for this job. I’ve met many people who were interested in QA but did not know how to start or did not trust the existing courses. So I decided to start my own and I was really overwhelmed with positive feedback!
My course is suitable for people from different backgrounds: from complete novices to those who already worked in the IT industry but wants to change the direction a bit. I give both theory and practical tasks so all my students can learn on real-life examples and hence gain professional experience during the course of education.
This course was somewhat a challenge for me: I wanted to see whether I’m able to structure my knowledge and skills and present them in a clear and informative way. And I guess I succeeded because we are now starting the second group.
Manual vs automated testing: your thoughts?
The main goal of automation is to test frequently occurring cases and detect bugs in simple operations. By simple operations I mean those that do not require a manual QA specialist.
On the other hand, complex specific cases need to be tested manually. Efficient usability testing cannot be tested automatically either. So to obtain the best results, I highly recommend combining both manual and automated testing so you won’t miss a thing in complex cases but also won’t spend time on simple cases.
Comments