What I Learned Testing My First Real Website as a QA Intern
Before this internship, I thought QA meant clicking around a website until something looked wrong. My first real assignment, testing the Singh Engineering Works site, taught me it's a lot more structured than that, and a lot more useful.
Expected vs Actual is everything
The first thing I had to do was make a habit of writing down every problem I found with the website. I had to write it in a way. I did not just say the website looks bad. I said what I expected to see and what I actually saw.For example I expected the website to look nice with colors and a short description of the company near the top.What I actually saw was the description at the bottom and the layout was all wrong.Writing it down like this makes me think about what's really wrong with the website.The website problems that I write down in this way are the ones that the developers will actually fix.They like it when I am specific about the website problems, like the Expected vs actual results .The Expected, vs problems are the ones that the developers can really fix because they know what to look for.
Content bugs count too
I also assumed QA was purely technical, but some of the most important issues I found were grammatical. The company's own description had awkward phrasing like "the firm is guided by mechanical engineers who have decades of experience," when it needed to say whether that was one engineer or several. I ended up proposing two corrected versions depending on which was true. It reminded me that a QA tester is also the last line of defense for how a business presents itself in writing, not just how it functions.
"It looks clickable" is not the same as "it works"
Several buttons on the site looked exactly like functioning elements, location details, contact numbers, "view details" links, but none of them actually redirected anywhere. This became a recurring theme in my testing: static elements dressed up to look interactive. Now it's one of the first things I check on any new page.
Forms need more than a submit button
The booking form had no real endpoint. After clicking submit, users landed on a bare "OK" message instead of a thank-you page, a dashboard, or a "view my booking" option. It's a small thing, but it's the difference between a user trusting that their submission went through and a user submitting the form twice out of doubt.
Small details signal professionalism
I also flagged something as minor as asterisks not being shown in red for required fields. It felt almost too small to report at first. But early on, I learned that QA isn't just about ultimate huge failures, it's about catching the dozens of small frictions that quietly influence a user's confidence in a product.
The takeaway
My first week of testing taught me that a QA intern's job isn't to prove a site is broken. It's to describe, precisely and constructively, the gap between what a user expects and what they actually get. Every bug report I wrote after that first site got sharper because of it.
