Each BIT does varying level of testing based on it's runtime budget but there are a lot of very basic tests that don't make much sense until you see your first field report of some register bit "sticking". Its much better to ground a plane that can't add 1+1 than to find that out in mid-flight.
As I recall, they modified the sensors to avoid latch up (extra pullup resister) and updated the FCS software to provide a warning if all 3 sensors return zero output. Even though this wasn't really an error in the FCS software, It could be argued that it failed to detect an erroneous input from 3 redundant sensors that latched up for the same reason.
This is a classic example of a pilot who misunderstood the pre-takeoff checklist procedure and cost the USAF a $325m aircraft.
> During the mishap sequence, the MP started engines, perfomled an IBIT, and had a fully
functioning Flight Control System. Subsequently, the MP shut down engines to allow
maintenance personnel to service the Stored Energy System. During engine shut down,
the MA's Auxiliary Power System (APU) was running. The MP believed the APU
provided continuous power to the Flight Control System, and therefore another IBIT after
engine restart was unnecessary. This belief was based on academic training, technical
data system description, and was shared by most F/A-22 personnel interviewed during
To be fair this seems to be more of a classic
example of a documentation or training problem.
So you could also classify this as a user interface / design problem.
Now, hopefully your system is set up such that race conditions cannot happen, but good luck with that.