This is a great question and one that many organizations face.
I recommend keeping the test code and the application code together because this will, at the highest level, help keep (or perhaps 'force') application and automation developers closer to each other in many other ways.
It would be 'easier' to have the repos separate, however this is a very short-term view and it is a view that promotes each group to focus on their own work only and not consider the other party's contribution as part of the same puzzle.
To make the same repo approach workable, reliable, helpful and less painful to use consider the following practices:
- Continuous integration
- No pending tests
- Full involvement of both groups in planning, grooming and 3 amigos
- Work on a reliable test suite that can be trusted, e.g. test failure rate less than 0.1%
In the large view, avoid:
- different repo,
- differrent location (e.g. offshore),
- different sprint (e.g. sprint+1)
because they all push devs and testers apart and the point of testing should not be so much a defensive 'does it work / is it broken' for go / no-go decisions, instead testing should be providing immediate and valuable feedback to developers about code that needs to be fixed or improved. Companies that fully master this have moved from deploying every six months to deploying every few minutes. This is what the largest silicon valley companies do now. Netflix, Facebook, etc.