技術者は要求仕様に対して、「できません」と答えてはいけません。
「それを実現するには～～～～すればよいのです。」が正解です。
GUI関連がバグの温床になって何十年経つでしょうか。
いまだにこんな言い訳がまかり通っているようです。
GUIっていうのはさ、相手が人間でね。どんな操作するか分かったもんじゃないわけよ。
だから再帰テストつっても簡単にはいかないわけね。
総当りったって、１００も２００もボタンがや設定があってね、内部状態だって数千通りあるんだよ。それも正常系だけで。
いくらバグが多いからって言ったって、総当りテストできないよね。
結局、人間の目で見なきゃいけないわけだし。
GUIに限らず、ソフトウェアの試験において総当りはコスト効果が低いため、品質工学的には直交表でコストパフォーマンスを向上させるのが常識化しつつあります。（ほんとかよ）
いまどきはGUIレイヤ部分でスクリプトを流せるようにして、定型の操作（正常系と異常系）を連続実行できるようにして画面のスクリーンショットをバイト君にチェックさせるのがフツウでしょうね。（マジデェ）
ソフト変更したら、同じスクリプトを流して、許容できる画面遷移をするか確認するだけです。もちろんシステム自体の起動までスクリプトで制御できるようにしておくべきです。
しかしそれでは、ほんとうのGUI部分をテストしたことにならないわけで最終的には本当のシステム・本当の装置でテストをする必要があります。
そこをなんとかするのに使えるものは冶具として作ってもかまわないし、以下のようなものを買ってきても良いわけです。
A-qual：Quality Commander 3：組込みソフトウェア自動検査システム
どちらも満足にできないというのなら、あ～たの権限や発言力がしょぼすぎるか、説明がへたすぎるだけのことです。予算というのは、決定事項ではないのですから。
関連リンク
