Software Test Engineer Intern

This is a short write-up of what that internship involved and what it taught me, kept at the level of engineering ideas rather than internal specifics.

Two pieces of work, in order: make the automated test framework fast, then widen its coverage. The order was the whole point.

A test suite is only as useful as the number of times it actually runs. This one was slow enough that developers skipped running it locally and waited for CI instead, so feedback on a change arrived long after the change was written, and the coverage on paper did not match how much testing was really happening before code merged.

So the headline task, expand automated test coverage, had a precondition hiding under it: the framework had to be worth running in the first place.

Adding tests to a slow framework does not just leave the problem in place, it compounds it. Every new test pays the same fixed overhead on every run, for everyone, indefinitely. Widening coverage first would have made each run more expensive and pushed developers even further toward letting CI do it.

I profiled the framework to find where time in a run actually went, rather than guessing, and focused on the fixed cost each test paid before doing anything useful: setup and teardown, environment and test-data preparation, and repeated work that could be done once and shared. Bringing that per-test overhead down speeds the whole suite up in proportion to its size, which is exactly the property you want when the plan is to grow it.

Once a full run was cheap enough to be routine, adding coverage was worth doing. I concentrated on the behaviour most likely to regress and least likely to be caught by a quick manual check.

Because the framework was now fast, the new tests were something developers ran as they worked, not a report they read later.

This is where I stopped seeing testing as a separate step bolted onto engineering. Coverage, speed, and defect rate are not three metrics, they are one problem from three angles: a fast suite gets run, a run that happens catches things early, and things caught early never become defects. Slow the suite down and all three degrade together.

It was also my first time in a real codebase with real users on the other end, and the first time I saw how much a piece of internal tooling shapes the way a whole team works day to day.