How automated tests change the composition of development teams
On this blog, we talk a lot about the importance of software quality for Askida, but what does that mean in the context of the company’s day-to-day activities? A developer from our team, Claudio, was telling me that when he started working at Askida, he was pleasantly surprised by how many professionals working on quality assurance the company employed. I thought his perspective was very interesting, so I asked him if I could share his experience on our blog. Here’s our conversation!
To get us started, could you tell me a little bit more about your background?
As a developer, I started becoming interested in Agile methodology around the early 2000s. In 2003, I was trained by Ken Schwarber, an Agile and Scrum guru, as a Scrum Master, although I wasn’t interested in becoming a Scrum Master full-time. My goal was simply to better understand the advantages of the Agile methods.
Later, I started trying to incorporate Agile methods at work, but I was working for large companies that didn’t want to change established processes too much. Eventually, “Agile” became a buzzword and people around me started saying that they were working “Agile”, even though the development model was still “Waterfall.” For some project managers, all “Agile” meant was “faster.” I was starting to see some clear advantages to the Agile methods, unit testing, non-regression testing and other similar approaches, so I was a little disappointed. And it wasn’t only project managers that were reticent to changing their development methods, it was also some developers.
What changed when you started working at Askida?
First, Agile methods were already very well implanted and were clearly a part of the company’s culture. Moreover, I was really surprised when I realized how many team members dedicated to quality assurance were part of each team. In other organisations, people will say that they want to deliver quality, but there are sometimes not enough consequences if that’s not the case. Askida, in comparison, really gives teams the resources they need to deliver quality.
The difference between traditional development and Askida’s methods, for me, is kind of like an acrobat who’s walking across a tightrope with or without a safety net. As a developer, Askida’s quality assurance team acts as my safety net. For example, let’s say I introduce new code into a project that breaks a module that was already up and running. If non-regression testing isn’t in place, it might take a while for me to realize there’s a problem.
With Askida’s automated tests, if I introduce an new error in an existing module, I’ll know very quickly, which allows us to control software quality more easily and more precisely.
In what way do these methods change the composition of a development team?
The team I am part of right now at Askida is composed of 23 individuals. Before I joined the company, I worked on a project that was the same size. For the old project, our team was composed of 18 developers, 1 project manager, 1 Scrum Master, 1 architect and 3 QA resources that tested everything manually. It was pretty difficult to keep the project under control. The QA staff kept telling us “Stop inserting new bugs!” because they didn’t want to re-test everything manually. In terms of automated tests, unit testing or non-regression tests, there was hardly anything in place.
My team at Askida right now is composed of 8 developers, 1 project manager and 14 resources that develop scripts to automate tests. The total number of scripts is always increasing, which allows us to expand test coverage. At the moment, my project contains more than 5500 different test scripts, and non-regression tests are in place to make sure that the development team doesn’t introduce new errors in already existing modules. The development process is more efficient for everyone involved, including developers, QA analysts and our project manager, which allows us to deliver excellent software quality and a large, complex project on time and within budget.