We're getting close I think. As for calculated fields, it's usually ill advised to store calculated values. Nor do I see the point in converting dates or booleans into integers, assuming you really mean integers. Same for determining a part's testing is complete because it adds up to 14 or something.
Not sure what design you have with respect to test requirements and their dates but it doesn't sound perfect. If you had to add fields for test and date should you ever need a fourth test then the answer is that it's not optimal to say the least. I always say that it doesn't matter if you will never need this. What matters is IF you had to do this then it's not right. In that case, you probably ought to at least have a table to show parts and associated test types as records. Even that could be further normalized into test types, you parts table, and tblPartTests as a junction table.
In such a design, a query can show any part info where any tblPartTest record has Null for TestDate. I get the impression that you didn't review the links I posted about normalization based on your posts thereafter. I think lack of normalization is the crux of you problem now, and will continue to throw up barriers as you go. Anyway at this point I don't know what I can do to help as your main issue seems to be bad data input which is allowed due to design.
If I'm way off base with my assumptions on your design, then maybe post a copy of your db or some pics that will show design elements, and do review normalization if you have not already.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.