PoC/プロトタイプ開発におけるテストで見えてきたこと
PoC(Proof of concept／概念実証)はWikipediaの記載をお借りすると、
「新たな概念やアイデアの実現可能性を示すために、簡単かつ不完全な実現化（または概要）を行うこと。あるいは原理のデモンストレーションによって、ある概念や理論の実用化が可能であることを示すこと。」とあります。
このPoC/プロトタイプ開発においても、プログラムを書いた成果物がある以上テストはセットなのですが、業務として関わった経験者は少ないかと思います。
今回は私のいくつかの経験から、通常の製品開発のテストとの違いで見えてきたところなどを書ける範囲で書いてみたいと思います。
テストの立ち位置の違い
とあるプロジェクトにおいては、私はソフトウェア開発の初期段階から参画していました。
テストプロセスの策定、不具合DBやフローの構築を行い、その後少人数のテストチームが結成されるとテストリーダー的ポジションでやっていました。
テストの方針や、テストで使用するデータの選定、テスト実行後は結果分析を行い、次のテーマを決めるといった流れです。
また開発チームのよろず相談(リスク分析を一緒に考えたり開発ツールの提案とか)の窓口だったり、AI開発など情報の少ない分野の技術調査といったこともしていました。
かなり自由にやらせてもらっていましたが、開発チーム(HW/SW)は当初テストエンジニアが何をするんだろう？と思っているような雰囲気は若干あったような気がします。
それは通常の製品開発においては要求と仕様がある程度はしっかり決まっていて、その工程の中でテストがあるのが普通ですが、実験的な仕様と実装を繰り返しているわけですから、変更も当たり前にあるわけで、テストをメインにする人間がプロジェクトにいることが不思議に思われていたんでしょう。
そうした若干の距離感も感じ取っていたので、テストエンジニアにありがちな"待つスタンス"は取らず、意識的に"見える動き"を心掛けていました。
テストのアプローチの違い
上記のプロジェクトでは改良開発だったので、ベースとなるソースコードと新規で書かれるものは混在しつつ、仕様書もあったりなかったり、とにかく全体の把握も難しい状態でした。そこでテストの立ち位置としては、まず全体像を捉えるための活動を進めていきました。
スペックアウト(※1)でソースコードから構造の理解を進めるためのモデリングをしたり、USDM(※2)を用いて機能分類の策定と、仕様を自然言語化し、要求(仮)と紐付けを行うといった活動です。
この時点ではテストの「テ」の字もありません。
こうした要求仕様化をテストチームが先導することは工数も要して大変ではあったのですが、USDMのレビューによって仕様の不明点が明確になったり、結合テストもイメージしやすくなるなど、メリットも多かったです。
※1 スペックアウト：設計書の不足を補うためにソースコードから必要な設計書を起こす行為
参照 「スペックアウト」で ソースコードを理解しよう
※2 USDM：要求と仕様の記載方法を定義したもの
参照 USDM（Universal Specification Describing Manner）の基本
仕様が明確になってくると、テストの可能性の模索になります。テスト環境で必要な機材・費用を調査したり、テスト戦略(方針)～設計も進めていくことになりますが、ここで、製品開発との違いを明確にしておく必要が出てきます。
PoC/プロトタイプ開発においては、テストによって不具合を出すというより、変更や追加された仕様によって何が起きたか、問題や課題を抽出する方に重きを置いた方が良いと考えます。
そうすると、基本的に反復に向いたテストの構築が必要になるでしょうし、結果を比較する仕掛けも作っておく必要があります。例えばログを解析をしやすいマクロを書いたりします。
上記を踏まえて、テスト戦略は以下のような感じで立てました。
- 重要(メイン)機能は結合テストを実施する
- システム全体を動かすパフォーマンステストをリリース(機能追加、修正対応など)毎に反復的に行う
・工程リストを作成し、各工程の開始～終了までの時間を測定し比較する
・工程毎の定性的チェックリスト(大まかな精度確認) - パフォーマンステストはタイムリーに課題・問題をフィードバックするため、一日で完了できるボリュームにする
- パフォーマンステストの10回に一度、使用性に関する評価を入れる
- パフォーマンステストの数回に一度、定量的な精度評価を入れる：時間を要するためタイミングは相談
他にも色々やっていますが、基本的にはパフォーマンステストをメインに据えています。
検出する不具合の違い(ODC分析)
不具合はBTS(バグトラッキングシステム)でチケット管理するのですが、起票の際にODC(直交欠陥分析)を導入し、分析しやすい運用にしていました。
ODC分析というのは、バグ報告時に発生のトリガーや、修正時には原因・影響などを決められた選択肢で振り分けることで、バグ発生における全体的な傾向を捉えることが出来る仕組みになっています。
導入が容易なので、私はどのプロジェクトにおいても採用し、分析の一次切り分けとして活用しています。
(ただPoC／プロトタイプ開発においては品質はややおざなりになりがちなので、ODC分析が上手く活用できるかは未知数な面はあります)
さて、PoC／プロトタイプ開発におけるODCの傾向はどうか、属性別に見てみたいと思います。
案件情報はもちろん持ち出せないので、経験上のざっくり感だけ、属性別に多い選択肢のみ表示します。
(属性別の選択肢を詳細に知りたい方は、ODC分析の書籍やWebにて情報を調べてみてください)
※ODC分析おすすめ書籍 「ソフトウェア不具合改善手法 ODC分析」(日科技連出版社)
＜検出時：Opener Section＞
発生トリガー・・・ 基本動作:80％
インパクト・・・ パフォーマンス:70％、完全性/安全性:20％
＜修正時：Closer Section＞
欠陥タイプ・・・ アルゴリズム/メソッド:50％、機能/クラス/オブジェクト:30％
修正対象・・・ コード:90％
起因・・・ 誤り:80％、漏れ:20％
ここから傾向を読み解いてみます。
- パフォーマンステストがメインなので、インパクトが"パフォーマンス"なのは妥当
- インパクトに"完全性/安全性"が20%程度 ⇒ 安全設計を確認の上、テストしないとケガするかも・・・
- 不具合の発生トリガーは"基本動作"が多かった。これは機能観点でパフォーマンスを測る前に何らかの機能不具合で止まっている
⇒ 結合テストで抑えきれていない(反省点)。とりあえず動けばいい、という感じで実装しているのも要因か。 - アルゴリズム/メソッドの問題であるのに、コード修正でしか対応していない
⇒ 仕様を書かないことによる弊害か？ ⇒ 過ちは繰り返されそう
まとめ～PoC/プロトタイプ開発を振り返って
PoC/プロトタイプ開発ということでパフォーマンステストに拘ると、基本的な不具合を見逃し、結果的に開発が遅延することになります。
対策として、スモークテストなどリリース後に基本動作を広く捉えるテストアプローチが必要だったかもしれません。
また、PoC/プロトタイプ開発だからといって仕様書を書かずに進めてよい、という道理もなさそうです。
とあるプロジェクトにおいてテストチーム側の主導で要求仕様書を作成しましたが、それ以降の開発チームとのリンクにはもっとやりようがあったように思います。
まとめでもないですが、PoC/プロトタイプ開発だからテストをどこか省略してよいなんてことはなく、むしろしっかり機能を広くテストで抑えておくことが、結果的に手戻りを無くすことに繋がる。つまり、テストはどんな開発だろうとしっかり考えないといけない、という結論で今回のコラムは締めたいと思います。