目的：
ソフトウェアテストの革新方法についてご検討いただきます。
私どもが開発中の手法のアイデアをご紹介します。
ねらい：
開発に参画していただける仲間を募集中です。
ーーーーーーーーーーーーーーーーーーーーーーーーーー
現在私たちは、
生産性を２倍にするエンハンス業務の革新手法を開発中です。
その中核を担うのはシステムテストです。
極端な場合、エンハンス業務の２分の１はテストに費やされています。
変更修正結果で、万一のことがあってはいけないからです。
やや門外漢の私は、
マーク・ヒュースターとドロシー・グラハムという英欧の実務家が
発刊した４６０ページに及ぶ大著「システムテスト自動化 標準ガイド」
も調べてみました。
関心事にピッタリの書名でしたが、
結果は期待外れでした。
私の関心事は、以下の２点です。
１．テストデータをどのように準備すればよいか。
２．リグレッションテスト（回帰性テスト）はどうすればよいか。
リグレッションテストとは、
変更していない箇所が元通りであることの確認です。
１番めの点の問題意識は、
テストデータの作成は以下の面から省力化の敵だということです。
１）どのようなテストデータを作成すればよいかについて頭を悩ます
（時間も使う）
２）多くのデータを作れば検証にも時間を要する。
３）少ないデータでテストをすれば、検証漏れが発生し手戻りとなる。
４）下手をすれば本番で障害を発生させる。
現状は、テスト当事者も管理者も障害発生を怖れ
「過大」なテストデータでテストしているのです。
したがってテストデータ作成の課題は、
いかにして必要十分なテストデータを作成するか、です。
２番目の点は、より厄介です。
変更仕様が期待どおりに実現できているかのポジティブなテストは、
手間の優劣はあっても、それなりにできるでしょう。
しかし、あってはならない「予想外」の間違った手入れによるミスを
見つけるのはたいへんです。
あらゆるミスの可能性を考えるとテストデータは莫大になってしまいます。
おそらくテスト省力化テーマの検討対象としては、
ポジティブ面の機能テスト（正当性テスト）よりも
ネガティブ面のミスを防止するリグレッションテストの方が重要でしょう。
ところがなんと、この２点について具体的にどうしたらよいかについて、
この大著には記載がありません。
本書の中にこういう記述がありました。
良いテストケースを設計するためのテスティング技法も
重要なトピックではあるが、本書の対象外だ
（私たちの次のプロジェクトである）。
なお、（本書の）以降で「ソフトウェアテスティングの自動化」といった場合、
それはテスト実行と比較の自動化のことであり、
テスト設計やテスト入力作成の自動化ではないので注意してほしい。
私の知りたい第１点は対象外ということです。
なぜかと言うと、私の推定ですが、
どういうテストデータを作成すべきかは適用業務の内容の問題であって
たいへん失礼ながら、ソフトウェア専門家の埒外の問題なのです。
また、こういう図が載っていました。
これはテストの全貌を知る上でたいへん有効なのですが、
私の知りたい第２点はこの表の中の
「テストの前提条件のセットアップ」に含まれていて
回帰テストという言葉は出てきますが、それをどうしたらよい、
ということについては直接的な回答はしていません。
つまり、ポジティブな機能テストとネガティブな回帰テストは
渾然一体となって把握されているようなのです。
ーーーーーーーーーーーーーーーーーーーーーーーーーーー
そこでその後、私たちはこの二つの課題について
以下のような方向で解決しようとしています。
この図の「正当性テスト」の部分を多少説明したのが次の表です。
この新手法の特長は以下のとおりです。
１．テスト検証条件の自動化を実現する。
開発中手法ですので詳しい説明は省略させていただきます。
２．テストデータ作成の半自動化を実現する。
どのようなテストデータが必要であるかは、
人智に頼らざるを得ませんが、それを助ける情報を提供します。
必要な条件が決まればテストデータ自体は自動生成します。
自動化ツールが本格的には対象としていないテストデータ作成は、
このような半自動化方式によって省力化が可能となります。
３．リグレッションテストの実施方法はこうする。
これから具体化しますが、
正しく処理が行われていることの確認をする正当性テストが
終了してから分離実施することで、新しい道が開けると考えています。
こういうように、
システムテストの自動化テーマも新規開発を中心に考えるのではなく、
エンハンス業務の場合という特定条件の中で検討すると、
革新的な解が得られるのです。
0 件のコメント:
コメントを投稿