「新たな概念やアイデアの実現可能性を示すために、簡単かつ不完全な実現化(または概要)を行うこと。原理のデモンストレーションによって、ある概念や理論の実用化が可能であることを示すこと。このPoC/プロトタイプ開発においても、プログラムを書いた成果物がある以上テストはセットなのですが、業務として関わった経験者は少ないかと思います。今回は私のいくつかの経験から、通常の製品開発のテストとの違いで見えてきたところなどを書ける範囲で書いてみたいと思います。テストの立ち位置の違いとあるプロジェクトにおいては、私はソフトウェア開発の初期段階から参画していました。テストプロセスの策定、不具合DBやフローの構築を行い、その後少人数のテストチームが結成されるとテストリーダー的ポジションでやっていました。テストの方針や、テストで使用するデータの選定、テスト実行後は結果分析を行い、次のテーマを決めるといった流れです。開発チームのよろず相談(リスク分析を一緒に考えたり開発ツールの提案とか)の窓口だったり、AI開発など情報の少ない分野の技術調査といったこともしていました。自由にやらせてもらっていましたが、開発チーム(HW/SW)は当初テストエンジニアが何をするんだろう?と思っているような雰囲気は若干あったような気がします。それは通常の製品開発においては要求と仕様がある程度はしっかり決まっていて、その工程の中でテストがあるのが普通ですが、実験的な仕様と実装を繰り返しているわけですから、変更も当たり前にあるわけで、テストをメインにする人間がプロジェクトにいることが不思議に思われていたんでしょう。した若干の距離感も感じ取っていたので、テストエンジニアにありがちな"待つスタンス"は取らず、意識的に"見える動き"を心掛けていました。テストのアプローチの違い上記のプロジェクトでは改良開発だったので、ベースとなるソースコードと新規で書かれるものは混在しつつ、仕様書もあったりなかったり、とにかく全体の把握も難しい状態でした。そこでテストの立ち位置としては、まず全体像を捉えるための活動を進めていきました。スペックアウト(※1)でソースコードから構造の理解を進めるためのモデリングをしたり、USDM(※2)を用いて機能分類の策定と、仕様を自然言語化し、要求(仮)と紐付けを行うといった活動です。この時点ではテストの「テ」の字もありません。した要求仕様化をテストチームが先導することは工数も要して大変ではあったのですが、USDMのレビューによって仕様の不明点が明確になったり、結合テストもイメージしやすくなるなど、メリットも多かったです。仕様が明確になってくると、テストの可能性の模索になります。テスト環境で必要な機材・費用を調査したり、テスト戦略(方針)~設計も進めていくことになりますが、ここで、製品開発との違いを明確にしておく必要が出てきます。PoC/プロトタイプ開発においては、テストによって不具合を出すというより、変更や追加された仕様によって何が起きたか、問題や課題を抽出する方に重きを置いた方が良いと考えます。すると、基本的に反復に向いたテストの構築が必要になるでしょうし、結果を比較する仕掛けも作っておく必要があります。ログを解析をしやすいマクロを書いたりします。上記を踏まえて、テスト戦略は以下のような感じで立てました。他にも色々やっていますが、基本的にはパフォーマンステストをメインに据えています。検出する不具合の違い(ODC分析)不具合はBTS(バグトラッキングシステム)でチケット管理するのですが、起票の際にODC(直交欠陥分析)を導入し、分析しやすい運用にしていました。ODC分析というのは、バグ報告時に発生のトリガーや、修正時には原因・影響などを決められた選択肢で振り分けることで、バグ発生における全体的な傾向を捉えることが出来る仕組みになっています。導入が容易なので、私はどのプロジェクトにおいても採用し、分析の一次切り分けとして活用しています。(ただPoC/プロトタイプ開発においては品質はややおざなりになりがちなので、ODC分析が上手く活用できるかは未知数な面はあります)さて、PoC/プロトタイプ開発におけるODCの傾向はどうか、属性別に見てみたいと思います。案件情報はもちろん持ち出せないので、経験上のざっくり感だけ、属性別に多い選択肢のみ表示します。誤り:80%、漏れ:20%ここから傾向を読み解いてみます。不具合の発生トリガーは"基本動作"が多かった。結合テストで抑えきれていない(反省点)。動けばいい、という感じで実装しているのも要因か。過ちは繰り返されそうまとめ~PoC/プロトタイプ開発を振り返ってPoC/プロトタイプ開発ということでパフォーマンステストに拘ると、基本的な不具合を見逃し、結果的に開発が遅延することになります。対策として、スモークテストなどリリース後に基本動作を広く捉えるテストアプローチが必要だったかもしれません。PoC/プロトタイプ開発だからといって仕様書を書かずに進めてよい、という道理もなさそうです。とあるプロジェクトにおいてテストチーム側の主導で要求仕様書を作成しましたが、それ以降の開発チームとのリンクにはもっとやりようがあったように思います。まとめでもないですが、PoC/プロトタイプ開発だからテストをどこか省略してよいなんてことはなく、むしろしっかり機能を広くテストで抑えておくことが、結果的に手戻りを無くすことに繋がる。テストはどんな開発だろうとしっかり考えないといけない、という結論で今回のコラムは締めたいと思います。名前を記憶しておくコメント:SpecialPRスポンサーからのお知らせPRHOLLY関西在住のテストエンジニア、HOLLYです。キャリア10年を超え、コンサルやセミナー講師の機会も増えてきましたが、ずっとエンジニアであり続けたいですね。趣味はバンドとゴルフ。久しぶりの対面研修で思ったことよく学びよく遊びよく寝る、頭の回転が良い子供がたくさん育つ国になるといいな。新着記事SpecialPR@ITメールマガジンのお申し込み新着記事をいち早く知りたい、オリジナルコラムを読みたい――メールマガジンに登録して、@ITを120%使いこなそう。ITmediaはアイティメディア株式会社の登録商標です。