What exactly is a web analytics software tester?

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:

• Unit testing/component integration (automated)

• System testing/integration (automated)
  • Testers (or developers whenever necessary)

• Acceptance testing (or “recipes”) (manual)
  • Product representatives (product owners, product
    managers)

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?