Three looks at your project in our software house: Agile Delivery Lead
- February 15
- 2 min
Who is a Quality Assurance engineer? What is his role in a project? Are the people in this position satisfied when they find a mistake? Do they feel complete as a part of the team? Maciej Lorenc, QA at Hicron Software House, tells us all about it.
I am a QA. It means I take care of the project’s quality. My overall task is to ensure the final effect on the level that was agreed with the client in the beginning. As for day-by-day tasks, I do testing, which means that I focus on the product.
We work scrum on the projects, in teams consisting of developers and testers. Each teams must have all the necessary competences to implement a given project. The organiser and supervisor of this work is Scrum Master. At Hicron Software House, Agile Delivery Lead often plays that role, and Paulina told more about ADL look in this series. The person that gives us tasks is Product Owner, and to them the team is responsible to. Usually, it is a person from the client’s side.
Or do they come after some time, when there is actually something to test?
We should be a part of the project from very beginning, because we need the knowledge about the product and the team’s activities. On the first stages we can also suggest some solutions. Our work is not only about finding bugs and fixing them. We check the functionalities on very early stages of the project. This is the time when we create a whole process of ensuring the quality. We answer a lot of questions: should we implement automated tests? In what scope? Are pipeline’s defined correctly? Should we improve anything in the process, or maybe add something?
One more thing. The most basic graph in every testing manual is the one that show, how much the cost of fixing a bug increases over time. Which means: the faster we find a bug, the faster – and cheaper! – we will fix it.
Coworking with developers can be very different. Tester must have a lot of soft skills, because sometimes finding a bug in your own code can be taken very personal. You need to know how to act in such cases, and how to cooperate with people of different characters.
Testers’ tasks should have strictly defined acceptance criteria. When they are clear, it makes our job easier, but also prevents possible misuses. But the truth is that we only point out the elements that, in our opinion, needs improving. The final decision is not based only on our arguments.
The development team is not an ice factory. They can suggest amazing solutions, all they need for that is to know the business goal. If you ask us to change the button’s colour, we can do this. But maybe the goal was not to have a different colour, but to increase click rate of that button? Knowing that, we could suggest different, probably better solution. This aspect is even more important for the testers, who checks how the functionalities work – so they simply must know the broader context.