I'm still not understanding why you have more than one table.
I'd probably do it this way:
tblDevices
DeviceID
DeviceType
SerialNumber
DateManufactured
Inactive (Y/N)
TblProblems
ProblemID
DeviceID
TechnicianInitials
ProblemDescription
DateResolved
TblTest
TestID
TestDate
TestPerformedBy
ProblemID
TestDescription
TestResults
Test Comments
etc.
If I am understanding you, you will have a bunch of devices. There will be
one record for each device stored in the devices table.
Each device could have one or more (or none) problems. Each of these
problems would have an entry in the Problems table. This is a classic
one-to-many relationship to the Devices table.
Each Problem will have one or more tests performed. Again, this is a
classic one-to-many relationship to the problems table.
As far as forms, you'd have a form to enter/modify/deactivate devices. This
form will be bound to the Devices table. You'd have a second form to enter
Problems. This form would allow you to select the Device# from a drop-down
list and enter the other Problem data. Personally, I'd display the device
type next to the device number, but it would not be editable on this form.
This data would be bound to the Problems table. A third form (or maybe a
subform on your problems form) would be bound to the Test table.
You could do a lot with subforms here. On your device form, you might have
a subform that displays all the problems associated with it. Or, maybe just
the unresolved problems?
Lots of options.
Note that I would probably not use tech initials, I'd have a fourth table
where I maintained my technicians. I'd assign each one a number. I'd also
store their name and include an Inactive checkbox. On your forms, you'd
enter the tech number. In your reports (or displays on your forms) you
could show their name or initials.
Your current layout/description sounds like you are trying to create a
spreadsheet, not a database. Access is a relational database, and the data
must be entered in a normalized method. If you want spreadsheets, use
Excel.