Software development is big. It is a vast and dynamic world. Many of us try different concepts in software engineering, and so do I. Tester by day, developer by ni… after-noon (because I sleep at night). Every day I switch my tester hat for my developer hat and vice versa. The moment I switch my game mode, I feel like I am switching characters. A whole different person, Gollum and Smeagol! But really… I’m not switching personalities. It’s the mindset that makes a U-turn. And just like software development is big, that U-turn is pretty big as well. Let’s break down what happens when I switch that hat and what can be difficult about it.

Build mode: Unleashing my creativity

I am passionate about creating applications, which is why I enjoy wearing my developer hat. Being creative and artistic takes the spotlight while crafting a new idea. Focusing on constructing new features for new or ongoing projects is a great way to learn the ins and outs of software development. But the real beauty of application development shows itself when you have to go under the hood. When creating features, it is very important to make them efficient. This comes with puzzling over different data structures like an array for fast reads of your top 3 players, or a LinkedList for adding items to your shopping cart at lightning speed. Or maybe the question is whether to use the Strategy Pattern or the Factory Pattern for your implementation. So many questions! So many learning possibilities. I’m working towards a working product that people can use. Developer hat is build mode on.

Detective mode: The analytical mind flourishes

As the sun rises, and I start my daily work routine, I get my testing hat out of the closet. Now it’s a whole different ball game. I become the Sherlock Holmes of software. Investigating every single possibility to trigger flaws in the application or code. You might even call it a little bit of ethical hacking. It is not unusual if systems crash or sensitive information is laid bare after revealing a weak spot. These are grave security issues. Though I profile myself as a calmer test engineer (As a test engineer, I prefer to stay calm and composed when tackling challenges), but I know some who go into Rambo mode and battle cry: “How can I break this code with my code?!” They are hyped, which is fine. Don’t get me wrong, we’re not here to destroy the developers’ hard work. We are assisting them in creating safe, secure, and reliable applications. Protecting users from software that does not function properly. Nobody likes to use software that contains a bunch of bugs, this is a nightmare for the user and bad PR for the company. Testing is detective mode on.

The difference between the two hats isn’t the technical part. In both modes, we write lots of code. If the contrast is not coding, then what is it? It’s the goal you’re trying to reach. Developing is building features for the user, and testing is about building confidence in the features.

In between creative and analytical mindsets: the challenges of transitions.

Exchanging hats doesn’t come without a trial. The U-turn switch I talked about earlier, shouldn’t be taken lightly. Implications may occur if the switch is done wrong. Failing to transition from the creative mindset of a developer to the critical mindset of a tester may result in overlooking potential flaws in the code. This error could lead to higher bug rates, affecting the overall quality of the software. There are two main challenges that need to be addressed:

Mindset

Imagine you are working as a developer on a new e-commerce platform. Your task is to create a secure and user-friendly payment feature. In the developer mindset, you are focused on building features such as implementing various payment methods, ensuring a smooth user interface, and optimizing the code for performance. Your focus is on innovation, efficiency, and delivering a feature that adds value to the application.

Now, it's time to switch hats and become a tester. Your goal is to ensure the payment feature does not only work, but is also secure and not prone to error. Your mindset transitions to identifying potential flaws in the code. You start considering scenarios like what happens if a user enters invalid payment information, or none at all?

During this transition, you must shift from the creative thinking of a developer to the detective thinking of a tester. It requires stepping back from the pride and excitement of your code and adopting a critical eye to evaluate the robustness of your own work. This change in mindset requires you to anticipate flaws that you didn’t think about during the development process. Stepping away from your pride and excitement brings me to the second challenge:

Emotional detachment

I know as a developer you create a beautiful bond with your code, why wouldn’t you? It’s your creation. Your thoughts and creativity are invested in that code. When you put on your test hat, it’s time to let go. You have to emotionally detach from your code. You have to approach your feature like you have never seen it before. You have to take an objective eye. Identifying mistakes and breaches in the system, demands a cold shoulder towards your code, which trust me, is not an easy thing to do.

Mastering smooth transitions in mindsets: The beauty of controlling the U-turn

Now, learning how to cope with these challenges comes with the experience of switching modes frequently. Imagine the possibilities of being able to change hats whenever you want, without any struggle.

Controlling the U-turn is a recipe for very clean, stable and secure code. Let’s create a simple feature of adding an item to a shopping cart. As a developer you already know how to implement it the most efficient way: A LinkedList to add items very fast. You start writing unit tests and build the feature side by side.

From your testing experience you instantly think about the things that might go wrong with such a simple feature: null values, non-existing products, query injection,… You incorporate these flaws into your unit tests and thus in the feature its code. You see where I am going? Utilizing the two hats creates features with confidence.

Not only leads this synergy to working and confident code, but also to user-centric development. When I’m implementing features, I sometimes forget the experience from a user’s perspective. In my head, the feature is simple and easy to use. That is because I have been working on that code for a while. The puzzle is already made in my head and I know exactly what input my feature expects. Though, perhaps this won’t be the case for someone who uses it for the first time. The testing hat brings usability testing to the table, where it can identify issues related to usability, accessibility, and overall user experience. The collaboration of the two hats results in code that works well but is also user-friendly.

Though both are very admirable software engineering paths, switching between the two hats comes with challenges and they should not be ignored. But, when addressed and mitigated, opportunities come forth. Opportunities to create applications that are not only working, but also applications that users can trust on.