What Testing a Real App Taught Me About Software QualityWhat Testing a Real App Taught Me About Software Quality

Before my software quality internship, I thought testing was mostly about finding things that did not work: a button that failed, a page that crashed, or an error message that appeared at the wrong time.

Testing a real product changed that view. A feature can appear to work exactly as designed and still leave the user with a problem.

One of the clearest examples came from an account settings page. I entered a different email address, saved the change, and saw the account update immediately. There was no step to confirm that I owned the new address.

At first glance, the feature worked. I asked it to change the email, and it changed the email. But that was precisely why it needed another look.

A successful action can still be a failed experience

An email address is often connected to sign-in, notifications, and account recovery. Changing it is more significant than editing a display name. OWASP puts it plainly: “Changing an email address is equivalent to changing identity.” Its guidance recommends confirming the new address and notifying the existing one.

I reported what I could observe: in the flow I tested, the address changed without confirmation of the new email. I did not need to claim that I had taken over an account to explain why the behavior deserved attention.

That distinction became an important lesson for me. A useful bug report describes what happened, what was expected, and why the difference matters. It does not need to exaggerate the outcome.

It also taught me to look beyond whether an action can be completed. I started asking whether it gives the user enough clarity and protection while they complete it.

The screen size changes the product

Another part of my testing involved smaller screens. It is easy to approve a layout when you see it on a large display with plenty of space. On a phone, the same content has to compete for a much narrower area.

That changes what I look for. Can someone still find the main action? Does the text remain readable? Are graphics and other important content still visible? Does the page require awkward scrolling just to understand what is on it?

These are practical questions for any user who opens a product on their phone. They are also reflected in accessibility guidance: the W3C’s reflow criterion calls for web content to remain available without losing information or functionality when the view becomes narrow, apart from content that genuinely needs a two-dimensional layout.

Testing small screens taught me that responsive design is more than fitting everything inside the width of a phone. People still need to read, understand, and use what is there.

A good connection can hide a weak experience

I also tested with different network conditions. When I use an app on a stable connection, I can easily assume that everyone will see the same quick response. A slower or unstable connection makes me pay attention to different questions.

What does the user see while something loads? If a request takes longer than expected, do they know it is still working? If they try again, is the next step clear?

I do not want to imply that every delay I tested was a confirmed defect. The lesson was that I could not judge the whole experience from my usual connection alone. Google’s web performance guidance likewise recommends simulating slower network conditions and interacting with a page while it loads to investigate how it behaves for users.

A product may feel smooth in the environment where it was built and tested most often. Real users will bring their own devices and connections.

What I now mean by quality

These three areas—account verification, small-screen layouts, and network behavior—seem different. To me, they point to the same idea: testing should follow the user beyond the ideal path.

The email change taught me to question an action that technically succeeded. Small-screen testing reminded me that a page has to remain usable when the space changes. Network testing made me consider what happens when the conditions around the product change.

My internship also changed how I report problems. I try to be specific about the steps I took and the result I saw. Then I explain the possible effect on the user without presenting an assumption as a proven outcome. That makes a finding more useful to the people who have to investigate and fix it.

I still have a lot to learn about software testing. But I no longer think quality is simply the absence of crashes or broken buttons. It is whether people can use a product clearly, reliably, and with confidence under the conditions they actually face.

Sometimes the most useful test begins with a feature that appears to work—and the decision to ask one more question.