This morning I watched a short video where the presenters looked at a UI element and asked questions on determining if it was "correct". It's a short (six minute) video, so please take a minute to view it for context. The overall theme is that rather than focus on whether something is correct, testers should determine if a problem exists. Those two concepts are highly related, and it's not worth (imo) trying to determine which is the focus of testing - especially since I think I could make a reasonable argument for either.
What got me thinking was the question the presenters were trying to answer - Is this arrow graphic in the drop down list correct? They discussed whether it looked right, looked similar to other drop down list arrows, was it the right shape, is it something I recognize, etc, and most importantly, is there a problem? Most of the video elaborates on these points.
I don't have a problem with the ideas presented in the video - however I do think that a better example may have made more sense. In my mind, as soon as the question "How do you know if this arrow is correct" was asked, I would have written a test to grab the window and either compare a snapshot against a known good bitmap, or pull the id directly from the resource section of the relevant dll (in this case, mso.dll), and compare directly against the resource (yes, the resource could be wrong, but it would help me isolate the problem). As far as knowing what the error should do, I could compare against the spec - or, if I was working on an agile team, against the behavior described in the relevant user story.
I suppose I like the ideas - I suppose I would just approach things differently given this example.