A Developer’s Insight into Testing

The Perspectives

A developer’s goal is to create products that meet the requirements of the owners and end-users and deliver quality products that meet these objectives. When writing code, developers create a plan for how they’ll achieve specific results. While this foresight helps them work efficiently, it often leads to bias during the testing process. Additional factors, like limiting time constraints and conflicting priorities may lead to incomplete or partial testing.

Imagine that a developer is given the simple task of creating a password field with a minimum of eight characters. A developer’s first instinct may be to implement logic that only accepts a password with a minimum of eight characters and return an error message to help guide the user toward a valid password. When testing this code, the developer may do the following:

1. Enter a password of fewer than eight characters to return the error as expected.
2. Attempt to use a password with eight characters for successful validation.
3. Attempt to use a password with eight or more characters.

Assuming the tests are successful, the developer can celebrate and claim success, right? In reality, the developer has done the bare minimum by assuming the end-user is using and thinking of the system in the same way. Developers can easily slip into pitfalls by not considering the user’s perspective when setting goals.

In this scenario, a skilled tester goes a few steps further by accounting for the many possible actions the end-user may take:

• What if the user entered eight spaces by hitting the spacebar eight times?
• Perhaps the user decided to use only numbers, but the logic only validates alphabetical characters.

Luckily, the inquisitive mind of a tester saves the day. At the requirements stage, the tester clarifies what type of characters should be accounted for. During the testing phase, the tester tries several combinations to verify that only a minimum of eight characters is accepted, regardless of the type.

While developers aim to achieve defined goals, testers focus on product delivery and user experience. Testers ask all the questions necessary to ensure clarity, then tests the product as an end-user would to ensure quality delivery.

No Favorites

There’s often debate on which role is more important — developer or tester? Who contributes or adds more value?

There’s a common misconception among developers that:

1. QA and testers are not as valuable as they appear.
2. Developers can run their own tests, and if given the time and resources they can do more in-depth testing.

Unfortunately, it is not that simple. The saying, “Hidden in plain sight,” explains one of the challenges developers face when examining their own solutions. For example, a developer with confidence in their code may fail to completely test certain functionality. However, this bias can lead to overlooked flaws.

Testing requires both technical and non-technical skills, including the knowledge of effective testing processes and approaches, understanding of user behavior, and the ability to assess and resolve technical errors. In addition to writing test cases and plans, creating documentation, reporting bugs, and conducting tests, testers must be able to communicate clearly with their stakeholders across business and engineering. Testing requires logical and creative thinking, analytical ability, attention to detail, curiosity and determination — qualities that make testers a great asset to the delivery of software products.

The development process is also intricate and has its own approach and thought process. Both roles are equally important and operate more efficiently when they find synergy and appreciation of each other’s contributions.

Skilled developers become better testers, and testers become better developers, by understanding the others’ processes and approaches when working on a project. Relationship building creates free-flowing conversation and open dialogue that leads to more efficient processes by reducing delays in feedback and communication and allowing both sides to resolve issues quickly.

Conclusion

While I still have much to learn as a tester, the journey has been enlightening. I’ve learned to approach testing in a new way and understand the various types of testing, which helps ensure that quality is delivered on the front-end and back-end.

I hope my insights help you appreciate the work and thought process of both testers and developers and spark your interest in gaining a new perspective. I invite you to try testing for a week if you are a developer, or try developing for a week if you are a tester. Notice how the processes vary and observe the similarities.

Whether you’re a developer, tester or aspiring engineer, consider joining our team! Check out our latest job opportunities here.