In Automated Unit Testing, a white list is a list of those properties that you are particularly interested in testing against.
In white list testing, you specify a list of pages or properties you want to track (the white list) for the test case. When the test case is run, only differences in those pages or properties cause the test case to fail. Differences in all other pages and properties (those not on the white list) are ignored.
By defining white list test cases, you can avoid situations in which test cases end up failing on non-essential changes (whatever those changes might be), and kicking off unwarranted triaging and investigation by the team. Instead of having to adjust the ignored properties lists (basically telling the system what properties are not important), and then someone later adds a property that changes the testing need, white list testing lets testers and other team members focus on the pages and properties that the team has decided are important (the ones on the white list).
For example, given an activity that starts a large process with a correspondingly large clipboard presence (many pages), setting up white list test cases for each page that the process returns is a good way to provide modular test coverage of the process. Each white list test case can cover a different area of the process. Then, if and when one area of the process changes, only that white list test case reports a failure, and triaging and investigation by the team can focus on that one area. This modularization of test coverage can be very useful in a development environment, where there is constant change and you want testing to easily pinpoint the area of failure. Using white list test cases can help testers more easily identify when a bug belongs to a particular developer, because the white list test case is associated with a particular clipboard page.
White list testing is available for activity test cases.