Milos Najdanovic, QA at HTEC Group
Why Quality Assurance and not Software Tester?
The testing should be only a part of a QA job process. Quality Assurance is much more than that. A QA must be involved in all parts of the project. A QA needs to write automation tests, think of the creative test cases, know good UX practices, see flaws in the design, be familiar with modern apps and websites, have developed soft skills, be agile… but most importantly a QA must be responsible, reliable and their word must be the last one when deciding to release a product.
The testing should be only a part of a QA job process. Quality Assurance is much more than that.
When to get involved?
It is a great idea to involve a QA in the early phase of the project, while planning and designing are in progress. This way a QA can get to know the project to the tiniest bits and even in that early stage see the potential issues. Introducing a QA during the project setup is crucial because it is most cost-effective to make changes then, as opposed to when the software is nearly finished, and the deadline is fast approaching.
How does the QA process go?
While developers are working on first testable units, QAs keep themselves busy with writing test cases or scenarios. The more detailed they are, the more issues could be discovered. In the long term projects, the next step would be to automate parts of the testing. For most projects, this still seems to be a big investment, but automation can, in the long run, be very efficient and cost-effective because it can perform regression tests and with continuous integration prevents deploying codes that have issues. Having automated tests gives more free time to the QA to test edge cases and really get into the role of an average user, seeing the software through their eyes.
What can be automated?
A QA engineer above everything else must be a people person.
How to tell a developer his code
sucks is awesome but can be improved?
A QA engineer above everything else must be a people person. Newsflash, nobody likes being told their work is not good, and your job as a QA is to point out flaws. Most importantly, people involved in the project must come to an agreement that finding bugs is not personal and is not a result of developers’ bad work. Bugs are a natural part of the software development, and even the code, language, and tools that are used to develop something have bugs themselves. Once a developer accepts that a QA is not there to criticize and that everyone has the same goal – to build a great product, there will be no tension in the team. Even when we come to terms with this, it is still up to the QA to know how to approach each member of the team. Additionally, you must describe these issues in great detail in the bug tracking tool (for example Jira) for everyone in the team to understand. So, besides investing in researching new tools and test methods, a good idea would be to also work on improving social skills.
If you liked this article