Change in the World of Testing: New Misconceptions From Old Folklore

There are many stories that we tell in the testing field. Folklore is a way to pass on knowledge from older generations to the new generation. These stories are the result of insightful experiences that are amplified when we realize how common these experiences can be and they become myths that we pass on to our next generation.

Stories are used to transmit knowledge from one generation of the family.

This article will examine some of the modern myths about testing, testing roles, testing methods, and testing personnel. These myths are also dispelled, revealing the truth about today's situation. These stories felt real and plausible back then, but they would be shocking today.

Tester is an interim role before becoming a developer

Unfortunately, testers are often viewed as less qualified than developers. A tester's ability and willingness to learn is often overlooked, especially when it comes to automation topics. This can negatively impact the tester's self-awareness, and eventually lead to the belief that the role should be temporary. While it might be the goal to grow into a role of development and earn respect from peers, this attitude devalues the job that testers are currently being hired for.

Are testers less 'valuable' than developers today?

It is important to remember that testers and developers, although sharing the ultimate goal for a functional piece of software, serve very different purposes during the software development process.

There is a lot of work that needs to be done. You need skilled, competent people to do this work well. Many developers have made the transition to testing. There are also testers who love to test, even though they started out as developers.

Instead of thinking that testers should look up at developers, why not encourage them to do the same? While there will always be things that we know better than others we should also remember that each member of the team has a wealth of knowledge and experience. If we are curious, we can all learn from one another in every role and at all levels of experience.

"Works on My Machine", - Developers Say

This is a common refrain: developers say "It works with my machine", while testers respond "We don’t ship your machine." Who says that? Our experience shows that the story is not always about a developer, but we know better. It is more common to hear "It worked on my machine" from testers.

Software is now designed keeping fragmentation and device diversity in mind

Our work is outgrowing our machine. Although we may still be able to run code locally, virtualization and containerization allow us access to a variety of environments and verify that the code works. Even with containers, the developer reality has changed: software that is designed to run on one machine now works better and is more widely known.

Pay attention the next time you hear "It works with my machine" Although it may sound like a tester, bugs can only be manifested under certain conditions. This is a problem that affects all of us. Product owners will want to work with concerned teams to fix bugs if'my machine" is a device or environment that could be at risk. This will allow for the end of the 'works with my machine' myth.

Developers Do Not Perform Deep Testing

Testers often refer to the difference between 'developers' and 'testers. One common accusation against testers is that they don't practice deep testing, and that testers keep this bastion.

Deep testing might be a question you may ask. Deep testing is a special investigation that aims to uncover results that other testers may miss. It is used to judge problems that have been introduced into production. It might be tempting to ask ourselves, "How did they miss that?" This bug would have been easy to spot by us.

Every member of the team is responsible to ensure quality

We have found that both developers and testers can practice deep testing, but at different levels. This is contrary to popular belief. Developers test their code at the implementation level while testers focus on the bigger picture. This includes the usability and expressiveness, validity, meaningfulness, and compliance to specifications.

Deep testing can be performed by many developers around difficult-to-reproduce bugs. Developers can deliberately control variables that were identified with testers. Developers' abilities are undermined if deep testing is only done by testers. The team can collaborate across roles to achieve effectiveness, depth, and collaboration that none of us would be able to do on our own.

Both are essential roles in software development and both have an interest in creating high-quality products.

Testers are at risk of conforming to preconceptions about developers' testing abilities. This is a dangerous thing.

Testers are information providers. They don't make decisions or speculate on causes.

We tell stories, in one way or another about the place where testing ends. The emphasis on providing information implies that someone else is responsible for taking action based upon the information. This is especially true in bug reporting and release decision-making.

Testers often have relevant insights and information that can enhance release decision-making

In the belief that business representatives might have more information than testers, we tend to leave decision-making about release releases to them. It is their job to decide about releases. We have found that business representatives are more likely to share information with teams and create guardrails that empower them to make release decisions. Testing is an active part of that decision.

Business stakeholders need to have sufficient information in order to empower teams. This is where testers really shine, as they do deployments and rollbacks in the event of unexpected results.

There are also stories about people reporting symptoms of problems while speculating on the causes. These stories are intended to warn developers that they don't welcome speculation or advice on the cause of problems. The story continues to state that instead of helping developers, you will only irritate and annoy them.

Many developers expect testers to be more analytical. Developers prefer testers to be involved in debugging sessions and not just report the symptoms. It is normal to be curious about the causes of problems beyond what you see.

Testers are often able to retrieve more information than other roles due to their inter-team connections and holistic view of the application being tested. This is done by asking specific questions and enriching the answers with relevant information.

100% Tested Before Production

Today's systems are becoming increasingly complex systems of systems. Value chains are built from pieces of different development teams, whether they be internal or external. Architecture requires us to challenge our assumptions. It is no longer possible to say that developers always know what they have done. Implementation is a lot about configuring and testing another subsystem to ensure it meets our purpose. We don't know everything the old way, especially in the new world of microservices or AI algorithms that we orchestrate.

Today, testing in production is more common.

End-to-end testing does not mean testing the entire system. It is pointless to see something fail without understanding why. We need more architectural deliberation. We need to think about trust chains. This means that we should not test things that have been tested in order to make room for testing new things. Updateability is the ability to change parts of the system, without fully testing it - this is not negotiable.

Stories have also been told about the possibility of testing in production. Because we know there will be a future version, it is possible to test for missing functionality with the production versions. This is something that we couldn't take as a given before.

Testing Users Don't Have to Code

Online conversations often revolve around people seeking work in the IT industry, but not programming. Most people respond by suggesting that they take up positions such as product owner, scrum master or designer. It is possible to tell a story that testers don't write code, which is true and valuable. Although this is true in large part, it doesn't capture the diversity of testing work. It also fails to address the question of how it is unnecessary to refer to our work as "not programming".

Being able to 'read' code is just as important as writing code

Development is not complete without testing. It is true that the old saying "I can program anything if it doesn't need to work" still holds true. Programming is more than just coding. A tester has the superpower of being able to see what has changed in code.

This is a tale that will be remembered for generations to come. We wanted to create functionality that would allow us to list files and then delete them. Correct implementation of the code that logs the files to be deleted was achieved. The code was not complete when we looked at it. It was easy to add the missing code, but not so simple as to forget it in the first place.

Programming is a complex process and code reviews can be a benefit to testers, even if they spend little time programming. Programming is complex and there are many layers to it. Every day brings new opportunities to learn.

We conclude this controversial topic by encouraging you to reflect on the stories that you tell.

How will the world change if we continue to tell the same stories to future generations?