|
|
|
|
|
by torstenvl
2855 days ago
|
|
I am having a difficult time understanding how you're taking the fact that they did a test and got an outcome, and concluding therefore that they "faked" the test. Let me try an analogy to explain my viewpoint. Let's say I'm testing pre-alpha UI with some users. In the first phase, I give them no explicit training or instruction on the software because I want to see, as a whole, how the thing holds up holistically. Let's further say that, during that first phase, they struggle with the menu system or how to enter commands. Okay, noted. But I still need to check various wizards and dialogs, and I've already brought all these testers in. So instead of sending everyone home while I fix the main menu/command bar/whatever, I construct and direct situations so that all the aspects of the UI are exposed to the user for testing. "Go here and click the arrow-into-a-box button to save the file." "Oh, that's what that is? How come it isn't a normal save button?" "Sorry about that, but go ahead and do that and then see how it goes from there." "Okay!" Would you similarly conclude that I "faked" the test? Do you think the better solution would be to send everyone home? Or just have them twiddle their thumbs for the entire length of the exercise? It seems quite clear, to me, that the correct course of action is to keep testing. Continue to test and try various components of doctrine to see how they hold up. The fact that this Red Team didn't want to use anti-air radar doesn't mean we should waste the opportunity to test our doctrine on how to counter it. |
|