In the context of an embedded system, interface testing is most likely to refer to testing the interface between the embedded system and whichever external system is using it.
For instance, if the embedded system is the software driving something like a pin pad/payment terminal with touch screen, card reader, and so on, interface testing could include:
- sending transaction information to the device and verifying that it displays correctly
- checking the display of options on the device
- checking the device can correctly read a credit/debit/chip/touchless card
- checking the device correctly responds to touch input
- checking the device correctly handles user signature
- checking the device correctly handles pin pad entry
System testing would focus more on transaction flow - that is, sending transaction information, making payment using the device, and receiving completion information in order to generate a receipt. Interface testing is more focused on the interaction between the modules.
That said, I don't know how the ISTQB would define it, but I suspect the definition would be similar (if more academically worded)
Update January 24, 2020
Following the discussion in Comments, a few more thoughts:
Let's say your device has a class CardInformation
with methods GetCardNumber()
and CheckPin()
.
GetCardNumber()
calls Display.CardSwipePrompt()
, Input.ReadSwipe()
, and `Input.GetCardNumberFromSwipe()'.
CheckPin()
calls Display.PinPrompt()
, Input.ReceivePin()
, and Input.CheckPinAccuracy()
If you are testing the integration of CardInformation
and Input
, you'll use stubs for the two Display
methods called, and you'll need to use some kind of fake or shim to inject values into the Input
ReadSwipe()
and ReceivePin()
methods, but you will be able to check the accuracy of the CheckPinAccuracy()
and GetCardNumberFromSwipe()
methods.