So in this case a definition of "done" as "Functionally complete, with all images and layout" would have prevented the whole discussion.

These kinds of things are communication issues. If the project tasks are completed but the feature isn't really "done" then there may be some room for improvement in the task description and requirements gathering and documentation. For something like this, depending on the size of the project, of course, it may help to have a developer that is the final say on tasks. They know everything about the software, so they know what every feature should do. Call it "Scrum Master" or "Point of Contact" or "bellybutton", but they are responsible for closing the task when finished.

I worked for one boss long ago who was obsessed with the word "done." No one could ever figure out what his definition was, but he wielded like Thor's hammer. If software that had been deployed for six months broke and had to be fixed, he'd scream "I though you said it was done! Why are you still working on it."

This process of gathering requirements and creating software out of nothing, while managing so many different people, personality types, and areas of expertise, takes time to evolve. Make sure you have AARs (after action reviews) to evaluate your process. If something wasn't actually done, but everyone thought it was, figure out why. Was there something you could have done to see the problem? Is there something that could be done differently next time?

First, never let a developer who has wrote a feature to write a test case for it. The test case must be written for someone else before the developer starts to work. If the developer tells someone what to test, then the tester is useless. The developer is biased and will never think of testing some stuffs (say, put a 10000 letters text inside a "Username" input field). It's not because he's a bad programmer or he's stupid, but the developer is trying to make something work and all his effort is into that.

This is not possible if you have a really small team. I worked for years where there were many projects and only 5 programmers. Each person was completely responsible for multiple projects. Most of the developers didn't have tests for anything. The just hacked the code and prayed it would work.

Also, test driven development is based on doing exactly the opposite of what you're describing.