Software Testers (at AT Internet)
The software testing profession is evolving and has many facets. Positions within companies are varied and job titles encompass very different profiles — analysts, designers, testers, control engineers, test engineers, quality engineers, agile testers, etc. — and sometimes we all have a different understanding of what kinds of responsibilities lie behind these designations.
Most of my contacts immediately think of the repetitive nature of manual testing, due in part to the scope and variety of testing performed over the course of development. The job of the tester is indeed often (and wrongfully) associated with boring and repetitive tasks that consist of following procedures outlined by a test manager or test lead, in order to produce a test report with an OK or KO status for each test case. The exclusively manual validation approach, including non-regression testing, is in fact (according to me — I know that opinions may differ) an outdated view of software testing, even though it is still favoured by some. It is a very good model for those who sell this service but has far fewer benefits for the buyer!
The model presents several disadvantages:
- Non-regression, by nature, signifies that as soon as the validation phase (often mistakenly called “recipe”) is over, and that a new version is released, you have to start over! It is therefore impossible to truly monetize your investments over the long term.
- Validation timelines grow longer and longer, and this slows down deliveries. You may conclude that you need additional testers in order to speed things along, but this is a trap!
- The human aspect is non-negligible: over the long term, very few people will feel fulfilled by repeating the same tasks over and over again. Meanwhile, machines do this very well, and always with a smile!
These testing activities remain relevant if the need is specific, for example if you need to secure a single version of a product or assess the overall quality of a project that is nearing its end. Conversely, it is difficult to integrate this approach as a publisher who continually releases new features within software systems that grow in complexity, and whose output is more and more frequent. At AT Internet, we recognize the value of manual testing, but only within a very specific context further outlined in this article (acceptance).
This is why I decided to write this article: to shed light on the daily activities of a “test engineer” at our company and outline the rare set of skills required to take on this role.
The Tester Position at AT Internet
To understand the tester position, it is best to simply describe the tester’s role, as defined within our company:
“To contribute to the quality of the products made available to customers, through automated validation of new features and continuous detection of regressions within existing features.”
The above task can be broken down into a number of activities, including:
- Test design and implementation (automated, of course)
- Managing tools and test environments
- Reporting and following up on all detected abnormalities
…all in close collaboration with developers. Testers are also core members of the Agile development teams.
Independent, Constructive, and Critical
Above all, testers must have non-technical skills; these soft skills are crucial.
- They must be objective, independent thinkers, and have an excellent sense of customer service. A detected bug can never be regarded as “normal” if it has a truly negative impact at the customer level!
- Testers are also expected to communicate well with developers. Since they are often the bearers of bad news, it is important to ensure that findings are communicated in a constructive manner. The end-goal is to improve the product; and never to criticize a colleague’s code!
- While maintaining a positive attitude, testers must nonetheless approach the product being tested in a critical manner, and most of all, never trust the code — bugs are always hiding somewhere, and the trick is to find them! This is what I call the “professional pessimism” of the trade: remaining optimistic while carefully dissecting an application in order to find the problems and any other issues therein. This isn’t always easy!
Testing Skills
In order to align with our company strategy, testers should know how to perform basic testing. Certification is available through the ISTQB Foundation (though it is not mandatory). The skills required allow testers to effectively analyse features, establish relevant testing plans, design and implement good test cases, and avoid common pitfalls among rookies, for example establishing tests that are dependent on one another, that ultimately verify the same thing, or that tackle too many features at once. Effective testing can be achieved using well-known techniques in the business: analysing limit values, equivalence classes, path coverage and other decision tables, for example.
But that’s not all…
I must admit that this is where things get tricky for us: our tests must be implemented by actual developers! In order to keep up with our continuous product integration, and considering the volume and pace of our deliveries, we have a strong need for automated testing. This is why our testers are also developers. Their skills contribute to the quality of the product and serve other developers, through the implementation of efficient tools and feedback mechanisms that allow them to maintain a good sense of the quality of the code they are producing.
Everyone Plays a Role
“Quality is everyone’s business!” said W.E. Deming. Indeed, everyone has a role to play in this matter; it is not solely the domain of testers or that of an isolated team specifically dedicated to this aspect of our products (in fact, we have no such team). Everyone must take part, and roles and responsibilities are divided according to the testing level:
In some cases, our teams strategically decide to organize manual testing sessions involving various employees, for example to secure the delivery of an application that was insufficiently covered by automated tests, or to deliver features with a high level of business risk. In these cases, an extensive ad hoc recipe is needed, without implementing exceedingly complex validation systems.
Why invest in automated testing?
We are committed to long-term relationships with our customers, which demand trust. We must therefore be vigilant when it comes to the quality of our products in the medium and long term, and this involves managing technical debt, the increasing entropy of systems, and the total cost of ownership (TCO), which testers know well.
As I mentioned in this article, we have chosen to transform our quality-related (or rather non-quality) costs into investments that will gradually help us achieve the following objectives:
- Saving time
- Securing deliveries
- Increasing ease of development
- Improving our planning
- Saving money
Our testers dedicate their expertise to achieving these objectives, and our needs in this area are significant.
Recruitment
Recruitment is not always straightforward, primarily due to the lack of testing training among recent graduates. Testing and automation-related courses in engineering schools remain rare, despite the growing demand for skilled individuals among businesses.
Testers are often developers by training who have stumbled upon the field of testing by chance, or, conversely, individuals who started out in a position interfacing with customers (support, problem-solving…) and subsequently acquired development skills.
Since it isn’t easy to find the perfect combination of tester-developer-analyst-automation expert, we focus on candidates’ soft skills. It is much easier to teach the principles of software testing and script development to candidates with a rigorous work ethic, good analytical skills and strong motivation, than it is to try to instil this kind of rigor among inattentive developers. That said, we are of course always willing to meet conscientious developers who want to put their skills to use in the field of test automation! Where do you see yourself?
Originally published at https://blog.atinternet.com on May 3, 2019.
