The pattern I have seen with testing over my career shows a strong correspondence with the risk of failure in a project. Big projects are more likely to be tested than small ones, mission critical applications are more likely to be tested than one off marketing web sites, in house systems are less likely to be tested than public facing ones.
That said there are still projects that have been excessively tested and those that have not been tested enough, but these are the minority.
first, get rid of the split between 'testers' and 'developers'. Everyone tests
second, in TDD, the developers code the tests before they code the feature/story
What you have described is not TDD [it may be Scrum though; Scrum is a project-management methodology independent of the development methodology; Scrum is not relevant to your problem]
Scenarios where automated testing is impossible are exceedingly rare. Scenarios where automated testing is difficult, expensive, or inconvenient are much more common - but it is precisely these scenarios where automated testing is needed the most.
From the vague description, I assume the software is drawing something on the screen. If what is being drawn is determined by data, formulas, or functional steps, then at least write automated tests that test to the level of the data/formulas/functional steps. If the screen output is deterministic (the same steps result in the same drawing output every time) then test manually once, take a screenshot, and let future tests compare the output to the verified screenshot. If the screen output is nondeterministic and not governed by data, formulas, or functional steps, then you're in that rare area where automated testing may be impossible. But I doubt it.
I'm guessing that the only reason testing has not been automated so far is that the developers don't care about it. In TDD, the developers do the testing, so they feel the pain of the boring repetition of testing the same 62-step process a hundred times until all the bugs are gone. Nothing will get an automated testing solution developed faster than making the developers do the testing.
Best Answer
The problem with testing any piece of software is that complexity blows up pretty quickly. The fact is, you can't test all possible combinations of parameters passed to your methods. Phadke advocates a Design of Experiments (DOE) approach, which allows generation of the likely list of parameter values that need to be tested.
The idea is that, even though you are not testing exhaustively, most defects cause a "fault region" to occur rather than an isolated point fault. The DOE approach Phadke advocates using orthogonal arrays samples the parameter space finely enough to hit all possible fault regions.
Isolated faults will probably not be identified, but these are generally fewer than fault regions.
The DOE approach gives you a systematic way of choosing the parameter values to vary.