How to do system testing of power window switches in real car environment

Question

I am planning to write test specifications for verification, validation of power window switches:

driver side: auto up/down, manual up/down, door lock, window lock
passenger, rear right , rear left: window up/down switches

One low-end variant has anti-pinch for only driver side window, and the high-end variant has all doors with anti-pinch function.

The customer has various system requirements.

I would like to know test method, test setup to test the switches requirements in real car environment.

I am also interested in understanding various ways to break the system testing with negative test cases.

Let me know if any more information is required. I would gladly share it.

Answer 1

I would proceed in this order:

1. Happy Path
2. Negative Test Cases
3. Edge Cases
4. Implicit Requirements

Happy Path: These are based on the functional requirements as described by the requirements doc or the person requesting the feature. This is the most basic ruleset that must govern the system. If this set of rules doesn't work, either the developer or tester did not fully understand the design constraints, or the PM did not create clearly defined requirements.

Negative Test Cases: These are also based on the functional requirements. They may not be explicitly expressed. They can be found by asking the PM, "What happens if...". Such scenarios in this instance can include what happens when the window is up and the Up button is pushed. The general rule here is that the system should respond gracefully. Popping a fuse or breaking a window would be a fail.

Edge Cases: This is where Exploratory Testing shines. Exploratory testing is the simultaneous discovery of the behaviour of the system, creation of the test suite, and understanding the system under test. What sort of things can go wrong that aren't listed in the requirements? What happens if one of the switch connectors works loose, or becomes corroded? What if a ground wire breaks? What if the car voltage drops? What if the motor fuse blows but the controller fuse is OK? What if the motor is wired backwards?

Implicit Requirements: This goes one step further than functional requirements. These are requirements that must be in place to create a pleasing experience for the customer, but they typically aren't thought of until they breach customer expectations. Things like performance, usability, reliability, repeatability, cost show up here. If it takes an hour to roll up the window the functional requirement is met, but the implicit performance requirement is not. If holding the Down button for an extra second causes the window to roll down all the way 9 times out of 10, the functional requirement is met but the repeatability requirement might not be. If the switches give out within the manufacturer's warranty period, the functional requirement is met but the reliability requirement may not be.