Paul Roubekas wrote:it seems like the assumption that a developer can guess what needs to be tested puts a lot of faith on a human
One thing I have found that helps mitigate the risk of relying on a
single person, i.e., a single point of failure: working closely with other developers and your users.
Working with other developers, as in doing pair programming or mob programming, really ramps up the game and allows you to inject different perspectives into the development/design process. You get more discussions about "what if" situations and hence, more ideas on how to test the system. Of course, the team members need to have good working relationships with each other and there should be a good balance of experience vs inexperience. In my experience, this kind of collaborative development that comes from pair/mob programming is usually more enjoyable and productive than solo programming. And there seems to be more motivation across the board to learn new techniques, new technologies, and even little things like keyboard shortcuts to be even more productive. It's the atmosphere of cooperative competition, I think, that drives good developers to strive to be even better when they see what their peers are doing.
Getting your users involved and engaged in making progress is the best way I have found to stay focused on what matters and on track with feature implementation. When users help write acceptance tests, they get the opportunity to share their own perspectives which can reveal other aspects of testing that developers might miss. Additionally, the users get the visibility into the progress that they so often need to feel comfortable with the schedule and any changes to it that the development team proposes, and they are better assured that they and the team are on the same page as to what should be built.