本文へスキップ

ソフトウェアテストのエンジニアリング

デバッグ,テストを科学する      

有限会社デバッグ工学研究所

テストのシンギュラリティ(技術的特異点)policy

方針イメージ

 「コンピュータが人の英知を超えるシンギュラリティが30年,あるいは35年後に到来する」と言われています.2014年12月の情報処理学会誌は,その特集号でした.身近なところでは,コンピュータ将棋とプロ棋士との「電脳戦」の結果を観れば明らかなように,既にコンピュータ将棋はプロ棋士と互角に戦えるレベルに達しており,シンギュラリティは,少しずつ小さな部分から実現しつつあると実感します.

 コンピュータ将棋と同様なことが,ソフトウェア・テストの世界でも起こっています.今から7年前の2008年に発表された2つの新しいテスト・ツール「CREST」と「KLEE」です.長年,人手によってテストを積み上げ派生開発を継続しているUNIX/LINUXにおけるCoreutil(コアーユーティリティソフトウェア)に対して,自動テストを行い,人手によるテストの網羅率を上回っただけでなく,非常に短い期間で16年間見つけられなかったバグを複数検出しました.
 
 Coreutilは,sortやjoinなどlinuxのコマンドとして提供され,現在でも世界中で常に使われているユーティリティであり,規模は小さい(数k以下)が,ロジックは複雑で巧妙に作られている.ソースコードはオープンソースとして公開されており,多くの先人により練られ安定したユーティリティです.長年に渡って積上げられたテストに対し,テスト・ツールは,それを超える能力を示しました.

 少なくとも単体テスト(数Kステップ以下)において,テストのシンギュラリティは,既に実現しており,対象規模拡大の研究が進行中です.既に150Kステップ規模の製品テストが行われており,韓国KAISでは,携帯用のOS(Android)に対してCRESTを使ってテストを行った論文が公開されています.「CREST」や「KLEE」は,単独のツールではなく,様々な技術の積上げによって構成されており,これらの技術を使いこなすには,高いスキルが必要になります.開発元のスタンフォード大やUC Berkeley以外にも,韓国KAISや英国Imperial College Londonでは,そのためのカリキュラムが組まれ育成が行われています.

 世界中でテストのシンギュラリティに関する研究や応用が進行中です.毎年,多くの論文が排出されていますが,残念なことに我が国における研究や応用は皆無に近い現実があります.テストのシンギュラリティ=コンピュータパワーの活用ですが,その反対側は,人海戦術とそのプロセス改善です.日本の多くの企業は,後者の考え方が主流のようで,シンギュラリティ=特異=異物と捕えているのかもしれません.

 どんな変化が生じるのか

 テストにおけるシンギュラリティの結果は明確です.人海テストからコンピュータ支援による自動テストへの変化です.しかもそれらを支える要素技術の多くは既に研究が進みオープン系のツールが提供されています.例えば,Javaのバイトコードに対するNASAのJPFツール群,LLVMのビットコードに対するclangやkleeなどのツール群,あるいはOcamlで書かれたCil系のツール群など,被テストプログラムを抽象構文木に展開し,すべての制御パスを識別する静的解析と各種ソルバーによる実際のテスト用入力値の生成など.あるいは過去のトラブルから機械学習により得た不具合のパターンや.統計手法を用いた探索テスト技法.テスト自動実行の支援環境など多岐に渡る技法とツール群です.

 初期の情報システムが,企業の事務処理における人海事務作業をコンピュータで置き換えたのと同様に,人海テスト作業をシステム化し,合理化と即応性を得る流れは,とても自然な流れです.セキュリティホールを静的解析を使って探索するなど,既に人手では困難な作業の自動化が実用化しています.多くのオープン系ソフトにおいて,サイトでビルド時に 行うmake check による自己受入れテストは,そのテストの程度差はありますが,当たり前になっています.しかし,多様なソフト開発において,銀の弾丸のような汎用的な自動テストシステムが出現するのは,まだまだ先になるため,個別に自分たちの自動テストシステムを構築する必要があります.

 人手に頼ったテスト作業から,コンピュータパワーを使った新た探索的な自動テスト・システム開発へと変化が生じます.自動テスト・システムは,当該開発環境の一部として組み込まれ,開発や保守と連携するので,開発方法にも変化が生じます.アジャイル開発における小さなビルドにおいても,コンピュータパワーを使って単体テストからシステムテストまで自動実行が行われ,エンジニアは複雑に連携するシステムにおいて,一歩一歩,確認しながら仕事を進めることになります.要するに,開発の入口と出口の距離が近くなります.レガシーな一部のシステムを除いて,新たなサービスを週や日の単位で提供し,時間の単位でサービスを安定に保守することが出来るようになるでしょう.具体的な例では,人海テストと比べ納期で2ケタの短縮(数日ー>数時間),品質で中堅テストエンジニアと並ぶテスト網羅を達成できます.

 どうすれば,シンギュラリティに乗れるのか

 その前に,何故,現状が悪化して行くのか?何故,ソフト開発では改善が進まないのか考えてみます.日常業務に追われている現場では,少しづつ改善するアプローチが現実的と考えられた来ました.このアプローチの欠点は,どんどんプロセスが重たくなり,市場の短納期化の要求に答えられず,エンジニアはどんどん疲弊します.工数不足を補うため外部の人手を使うと,その人と人のインタフェースが増加し,さらにプロセスが重たくかつ,個々の作業は単純化し,全体として非効率が進みます.恐ろしいことに,考える力が衰弱し,危機的な状況をが継続するデスマーチに堕ちってしまいます.

 日常に追われているプロジェクトの自力更生に頼った導入は困難です.導入のためには,それなりの計画と投資が必要です.ツールや技術はオープン化しており,その主力は「人」になります.今,進行中のテストのシンギュラリティとは何か,どのように進んで行くのかを掴む@リーダ的な人材,シンギュラリティを支える技術を習得し使いこなせるAエンジニア人材,B対象ドメインの知識を持つ人材を育て,プロジェクトチームを立ち上げることが必要です.

 特にAエンジニア人材の育成がキーになります.何故なら,経験(OJT)で育って来たエンジニアでは,シンギュラリティを支える技術は,触ったことのないツールや技術であり,自力で学ぶにはあまりにも非効率です.学ぶためにツール環境を構築することすら困難です.よって,何らかの育成プログラムとその訓練環境が必要です.弊社は,2013年からこの開発を開始して基礎の部分を実用化し,現在,実践応用向けの開発を行っております.

 シンギュラリティのための@リーダ的人材の育成方法は,試行的な実際のプロジェクトにおいて,コンサル支援を受けながら,計画し,問題の山を解決して行くのが一番合理的です.シンギュラリティがなんであるかを未経験なので,経験者のサポート下で試行錯誤しながら成長します.

 シンギュラリティにおけるドメイン技術者の育成は,ドメイン知識を前提に,シンギュラリティにおいて,何を正しいとするのか?について,Aのエンジニアと共にテスト・システムを設計し構築します.シンギュラリティに関する使い方の技術を学ぶ必要があり,Aの一部,あるいは試行プロジェクトにおけるOJTにより育成出来るでしょう.

 

Debug Engineeringデバッグ工学研究所

テスト技法とTool
問題解決のためのTools