In addition to the details comment, I'll advise to make field names intuitive. You will find ID is not, especially when you use it everywhere. You might also want to consider naming related fields with related names. ID > EmailID implies a mistake to me; LotIDpk > LotIDfk tells me a lot more than what you have. You will find this helpful when trouble shooting sql, expressions and code.
Last, be careful of joining everything in a chain like that. If one piece of info in between the beginning and end of related fields is missing, you will likely find you cannot get info out and in. You might be able to get info out, but you may not be able to edit because you will have to use an outer join. As Orange said, we don't know everything about the process but I don't see why you split tests and test info, and is that a table about user email info or is it about testers who test? Names should reflect as close as possible what the entity is because the details get lost in the fog of time.
I advocate queries before forms/reports and that these things should be based on queries, not tables. You can sort, filter or even lock a query, plus if you find your relationship prevents you from editing/appending/deleting from a query in testing (and it needs to do that) you haven't wasted a lot of time building a form that won't work because of relationships or whatever.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.