ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

JSTQB-TTAシラバスのお勉強 ─ 第1章「リスクベースドテスト」

JSTQB-TTAシラバスのお勉強 ─ 第1章「リスクベースドテスト」 ISTQBのAdvancedレベル「テクニカルテストアナリスト」シラバス日本語訳が出ました。いつ試験が行われるかは微妙なところですが、シラバスの紹介をしてみます。

テクニカルテストアナリストとは何なのか

 実は、ISTQBで定義されているロールの体系を見ても、定義を見つけることはできませんでした。この絵でいう「CORE」で、Advanced Level (AL)はFoundation (FL)の上位に位置付けられており、以下の3つから成っています。

  • Test Manager (テストマネジャー、TM)
  • Test Analyst (テストアナリスト、TA)
  • Technical Test Analyst (テクニカルテストアナリスト、TTA)

 テストマネジャーは一番わかりやすいでしょう。テストの計画・進行・管理・分析を行うロールですね。
 テストアナリストにもマネジメントの知識は要求されますが、どちらかといえばテストマネジャーに対して情報をインプットするという側面が強い。いわゆるテスト技法を駆使したテスト設計であったり、テストツールの導入であったりが仕事の中心と見なされています。

 テクニカルテストアナリストは、(ぱっとシラバスを読んだ限りでは)よりホワイトボックス的な色合いの強いロールのようです。シラバスでは、コードカバレッジや、静的/動的解析が章立てされています。また品質特性については、機能性やユーザビリティなど「ユーザが直接意識する」部分をTAが見るのに対し、TTAはどちらかといえばユーザがあまり意識しない保守性やセキュリティなどに責任を持つことになっています。第4章の「品質特性」でも明らかになりますが、TTAは開発者側が意識すべき内容が多くなっています。

2018/3/21追記

 確かに、TTAについては、こちらの「概要」にきちんと説明がありました! 足元がおるすになってますよ。
 TTAの「ビジネス成果」から引用してみましょう。

Advanced Levelテクニカルテストアナリストは次のビジネス成果を達成できる。
TTA1: ソフトウェアシステムの性能、セキュリティ、信頼性、移植性、保守性に関連付けされる代表的なリスクを認識し、分類する。
TTA2: 性能、セキュリティ、信頼性、移植性、保守性のそれぞれのリスクを軽減するためのテストの計画、設計および実行を具体化したテスト計画を策定する。
TTA3: 適切な構造テスト設計技法を選択し適用する。コードカバレッジおよび設計カバレッジに基づいて、テストが適切なコンフィデンスレベル(確信度合い)を提供することを確保する。
TTA4: コードおよびアーキテクチャ内の代表的な間違いに関する知識を、開発者およびソフトウェアアーキテクトとのテクニカルレビューに参加することで効果的に適用する。
TTA5: コードおよびソフトウェアアーキテクチャ内のリスクを認識しテスト計画要素を作成して、動的解析を通してこれらのリスクを軽減する。
TTA6: 静的解析を適用することで、コードのセキュリティ、保守性および試験性への改善を提案する。
TTA7: 特定の種類のテスト自動化を導入することから想定されるコストおよびメリットを概説する。
TTA8: テクニカルなテストタスクを自動化するために適切なツールを選択する。
TTA9: テスト自動化の適用における技術的な概念や課題を理解する。

 9つ中4つに「コード」という言葉が出てくること、またTAに比べて自動化がより詳細になっていることがポイントかと思います。
 上に書いた通り、より実装に近いところにフォーカスされている印象です。

1. リスクベースドテストにおける、テクニカルテストアナリストのタスク

 それでは、今回は第1章を見ていきましょう。まず、リスクベースドテストとは何だったでしょうか。
 用語集での定義は以下の通りです。

リスクベースドテスト(risk-based testing)
プロジェクトの初期段階からプロダクトリスクのレベルを低減させ、ステークホルダにその状態を通知するテストの方法。プロダクトリスクの識別の他、テストプロセスをガイドする際のリスクレベルの活用もこれに含まれる。

TMでも出てくる言葉なので、軽くこちらのエントリも覗いていただければ。

www.kzsuzuki.com

 識別・評価(アセスメント)・軽減というタスクについてはTMと同じですが、TTAは「技術的なリスクについて」の知識の提供が期待されています。
 ALの3つのロールでいうと、ざっくり分けてTMがプロジェクトリスク、TAとTTAがプロダクトリスクの深堀りをすると考えるとわかりやすいでしょう。

 例として挙げられているリスク例は以下です。

  • 性能リスク(例:高負荷状態では応答時間を達成できない)
  • セキュリティリスク(例:セキュリティ攻撃による機密データの漏えい)
  • 信頼性リスク(例:アプリケーションがサービスレベルアグリーメントで規定された可用性を満たせない)

 リスクの識別や評価については、特に目新しいことは書かれていません。専門家へのインタビューや有識者レビューを通じてリスクを洗い出そうとか、発生確率と影響度を評価しようといった一般論です。

Rex Blackさんの説明

 さて、これはプロジェクト管理でなくテストの話なので、テストを通じてこれらのリスクを低減する必要があります。そのリスクに応じてテストの優先度を決めるのが、リスクベースドテストです。

 リスクベースドテストの提唱者であるRex Black氏の資料、Risk-Based Testing - What It Is and How You Can Benefit(pdf)を見てみましょう。
 この資料では、リスクベースドテストの長所が以下のように述べられています。

  • リスクの高い順番にテストを行うことで、深刻な欠陥から順に見つけていける可能性を最大にできる。
  • テストの工数をリスクに基づいて割り当てることで、リリースまでに残った品質リスクをもっとも効率的に最小化できる。
  • テストの結果をリスクに基づいて測ることで、テスト実行期間中にどれだけのレベルの品質リスクが残っているかを組織が把握し、適切なリリース判定を行うことができる。
  • スケジュール上必要であれば、リスクの低い順からテストを割愛することで、品質リスクの増加を最低限に抑えながら、テスト実行期間を短くすることができる。

 このスライドを見ると、品質リスク項目とその品質特性を並べて、それぞれについて発生確率と影響度を記入しています。リスクベースドテストを紹介している他のサイトでは、縦軸に機能モジュールを並べているものもあります。機能×品質特性で、それぞれどんな品質リスクがあるかのマップを作るとわかりやすいでしょう。

たとえば

 例として、「外部I/Fの変更と機能追加の影響で、性能が劣化するリスクがある」ケースを考えてみましょう。
 まず発生確率について、プロジェクト開始当時は「非常に高い」だったとしても、初期段階でのプロトタイプ評価により思ったほど性能影響がないことがわかれば、「中程度」に変更されます。
 影響について、プロジェクト内部で定めた性能目標値を達成していなかったとしても、ユーザはまったく気にしないかもしれません。あるいはシステム全体の前提を満たせなくなり、リリース自体が不可能になるかもしれません。
 「性能が劣化する」と一言で言っても、その度合いによって確率も影響も異なるので、ものによっては別のリスクとして扱うのがよいでしょう。

 リスクの高いものから順に、対応するテストケースを消化していくことになりますが、そのテストケースも有限なので、リスクがゼロになることはありません。許容される工数と時間内で、受け入れられる程度にまでリスクを低減できたかを判断することになります。

機械学習の分野でも注目される、メタモルフィックテスティングとは何か。

 先日のJEITAのイベントで、メタモルフィックテスティング(Metamorphic Testing、MT)というものを知り、「誰かMetamorphic Testingの勉強会やりませんか?」とブログに書いたところ、ソフトウェアテスト・ヒストリアンの辰巳さんが資料をたくさん紹介してくださいました。ちなみに、一緒に勉強してくれる人は誰もいませんでした。

www.kzsuzuki.com

 ICSE MET'2017のサイトにも、MTについてのスライドがたくさん掲載されていたので、学んだところを紹介してみたいと思います。
 日本語の論文も無償で見られるものがいくつかあるのですが、どちらかといえばMTについての知識は前提として、それを機械学習にも応用してみたという内容なので、基本を学ぶには敷居が高そうです(論文だから当たり前か・・・)。

メタモルフィックテスティングの概要

 まず、Chris Murphy氏の『Applications of Metamorphic Testing』(ppt)が一番わかりやすいです。スライド終盤のサマリには、以下のようにあります。

  • MTは、既存のテストケースから新しいテストケースを生成する手法である。
  • テストオラクルのないアプリケーションにおいて、バグ検出の役に立つことがある。
  • ソフトウェアのメタモルフィックプロパティ(metamorphic property)に強く依存する。
  •  一つずつ、見ていきましょう。

    なぜテストケースを増やす必要があるのか。

     「新しいテストケースを生成する」理由は何でしょう。
     境界値分析や組み合わせテストといったテスト技法は、テスト空間を論理的に絞り込み、効率的にテストケースを減らすための技術でした。なぜあえて、テストケースを増やすのか。
     このスライドでは「だって、テストケースは多ければ多いほどいいだろう?」とあります。手動テスト中心のテスターが聞くと吐血しそうな意見ですね。

     たとえばこちらのICSTの論文『Metamorphic Model-based Testing of Autonomous Systems』(pdf)では、ドローンの飛行や障害物回避のシミュレーションプログラムにMTを応用した例が載っています。ドローンの出発地点と到着地点、その経路にある障害物には無数のパターンがあるので、ある特徴的なテストケースをいくつか通すだけでなく、そこから大量のテストケースを派生させて、プログラムの妥当性を検証することが有効なのですね。

    テストオラクルってなんだっけ?

     テストオラクル(Test Oracle)などという用語を使うのは、I/JSTQBで学んだ界隈の人だけだと思っていましたが、MTの文脈では当然のように使われている言葉です。
     ISTQB用語集に追加された日本語検索機能をさっそく使ってみましょう! 使い方は、湯本さんのnoteから!

    note.mu

    テストオラクル(test oracle)
    テスト対象のソフトウェアの実行結果と比較する期待結果のソース。オラクルは、実在する(ベンチマーク用の)システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。

     テストオラクルがないというのはつまり、「どういう出力なら正しいのか」がよくわからない状況ということですね。

    メタモルフィックプロパティとは?

     「メタモルフィックプロパティ」(Metamorphic Properties)とは一言でいうと、対象とするソフトウェアが備えている「性質」のことです*1。MTでは、この性質から多くのテストケースを導出することを目的としています。

     それってプログラムの仕様そのもの、あるいはそれを変換した高位レベルテストケースのことでは、とも思いませんか? 一般的なテスト技法でテストケースの絞り込みを行わなければ、テストケースはいくらでも追加できそうなものです。
     たとえば、「12歳以上は料金1,000円」という仕様からは、入力である年齢を12歳、13歳、14歳、・・・とし、出力が「1,000円」となることを確認するテストケースがどんどん作れます。

     ですが、メタモルフィックプロパティはもっと別のものです。
     わたしは、「プログラムの仕様として定義するまでもない、自明な性質」と解釈しています。

    メタモルフィックプロパティの具体例

    数値リストから最小値を求めるプログラム

     抽象的な話になってきたので、先の資料から具体例を引用します。
     整数のリストの中から最小値を得る関数 findMinを、以下のように書くとします(バグがあります)。

     「2、1、4、3」というリストを入力にすると、期待値(つまり最小値)は「1」になる、というテストケースは、以下のように表現することができます。

    { {2, 1, 4, 3}, 1}

     さて、このプログラムが持つべきメタモルフィックプロパティには、どういうものが考えられるでしょうか。
     それはたとえば、「リスト内の数字を並び替えても、出力値(最小値)は同じになる」という性質です。このような性質は、おそらく外部仕様として明示されない、「自明な」性質ということができるでしょう。

     この性質に従ってテストケースを生成すると、

    { {4, 2, 3, 1}, 1}

    というテストケースが通らないことがわかり、バグを検出することができます。

    形式的な表現をしてみると

     少し形式的に表現してみましょう。
     プログラムfに対する元のテストケースを {x, f(x)} と表現します。

     元のテストケースの入力値を関数tに通すと、新しい入力値はt(x)、プログラムfからの出力値はf(t(x))となります。
     一方、元のテストケースの出力値を関数gに通すと、新しい出力値はg(f(x)) となります。
     プログラムfのメタモルフィックプロパティとは、すべての入力値xに対して、f(t(x))=g(f(x))を満たすような関数ペア(t, g)のこと。文字列だと全然わからないですね・・・。

     先のfindMinの例では、関数tは「リスト要素の並び替え」に相当します。出力値の方は変わらないことを期待しているので、関数gは恒等関数になるでしょう。入力に「リスト要素の並び替え」という操作を行っても、出力値は変わらないというのが、findMinのメタモルフィックプロパティです。

    一般的にはどんなプロパティがある?

     一般的に、どんなメタモルフィックプロパティがあるのでしょうか。P.22からその例が書かれています。
     元のテストケースが「要素a~fの総計がsになる」というものだったとして、

  • Permute: 並び替えを行っても総計はsと変わらない
  • Add: 各要素に定数を足すと、総計は s+定数*6 になる
  • Multiply: 各要素に定数を乗じると、総計は s*定数 になる
  • といったものがメタモルフィックプロパティとなります。これはだいぶ単純というか・・・数学以外には適用できそうにない、退屈な性質ですよね・・・。
     もう少し違うタイプとして、以下のようなものが紹介されています。

  • Noise-based: 出力に提供を与えないであろう入力(の変化)
  • Semantically Equivalent: 意味的に「同じ」入力。
  • Heuristic: 元に「近い」入力。
  • Statistical: 統計的に同じ性質を示す入力。
  • 数値計算分野以外での応用

     メタモルフィックプロパティが上で紹介したようなものばかりだと、MTは数値計算関連のプログラムにしか応用できないのではと思いますが、Zhi Quan Zhouさんの講演『Metamorphic Testing: Beyond Testing Numerical Computations』(pdf)によると、数値計算関連分野での適用は全体の4%でしかないそうです*2

     この講演で紹介された適用例は、プログラム難読化ツール*3
     難読化ツールのメタモルフィックプロパティには、たとえば以下のようなものがあります。

  • 同じソースコードを入力するといつでも、動作的に等価なプログラムが出力される。
  • 一つのソースコードに対し繰り返し難読化を何度かけても、動作的に等価なプログラムが出力される。
  •  こういったプロパティを利用して、一般的なテストでは必ずしも検出できないバグが、MTであれば検出できるという例を示しています。

     また、オンライン検索での例も紹介されています。一口にオンライン検索といっても、GoogleのようなWebサイトの検索、ホテルや飛行機の空き状況、商品、用語、地図など無数にありますが、これらに共通して言えそうなメタモルフィックプロパティがあります。

     まず一般的な(general)メタモルフィックプロパティとして、以下が考えられます。

    「AがBに包含されている」という関係が成立しているなら、
  • Aの結果はBの結果の部分集合になる
  • Aの結果の数は、Bの結果の数以下になる
  •  この2つ目のプロパティから導出できる具体的な(concrete)プロパティは、たとえば店舗検索において、

    検索する地域を絞ることで、ヒットする結果は絞る前より少なくなる

    というものが考えられます。このメタモルフィックプロパティを利用してテストケースを生成し、妥当性を確認することができます。

    まとめ

     引用した資料に明確に書かれているわけではないのですが、生成されるテストケースが常に「期待値付き」であることが非常に重要だと思います。いくら大量にテストケースを生成したとしても、それが期待値なしであればあまり役に立ちませんし、自動化もできません。

     テスト技法といえば、テストケースを合理的に選択することと思いがちでしたが、「とにかくたくさんのテストパターンが欲しい」「でもテストオラクルがない・・・」という状況において、有効だが数が少ないテストケースから、期待値付きのテストケースを大量に派生させる技術として、メタモルフィックテスティングが有望な技術だということがわかりました。

    *1:他の資料では、「メタモルフィック関係」(Metamorphic Relations、MR)という用語も出てきますが、どうやら同じものを指しているようです。

    *2:Chris Murphyさんの資料では、実際の応用分野として、生物情報学、機械学習、ネットワークシミュレーション、コンピュータグラフィックスなどがあるとのこと

    *3:クラッカーなどに重要なシステムの内部情報を与えることを防ぐためのプログラム。obfuscator。

    「ソフトウェアエンジニアリング技術ワークショップ2017 ~人工知能ブームの中でのソフトウェアエンジニアリング~」に参加

     2017年12月15日(金)に、JEITA(一般社団法人 電子情報技術産業協会)の「ソフトウェアエンジニアリング技術ワークショップ2017」に参加してきました。プログラムなどはこちらをご覧ください。
     テーマは「人工知能ブームの中でのソフトウェアエンジニアリング」。とても勉強になった催しでしたので、許される(であろう)範囲でシェアしたいと思います。

     なお、わたしはディープラーニング初学レベル以下です(堂々)。講演者の方のご発言の趣旨を正しく理解できず、間違った要約をしてしまっているかもしれません。申し訳ありませんが、その際はご指摘いただければ修正・削除いたします。

    基調講演: 機械学習工学に向けて

     株式会社Preferred Networksの丸山宏さんの基調講演では、機械学習の概要や潮流について、幅広くお話しいただきました。どちらかといえば、機械学習のすばらしさよりも、限界や注意点に重点を置かれているように感じました。

    ディープラーニングが合うもの合わないもの

     演繹的な「モデルベース開発」と、帰納的な「モデルフリー開発」、という言葉がありました。
     銀行のトランザクションにように、人間が定義したルールに従って動くシステムは前者。複雑すぎてルールが書き下せないようなものに後者を適用とするというお話です。 後者の開発においては、十分な精度が出るかはやってみないとわからないため、Expectation Controlと、アジャイル的なアプローチ・PoCが必須との注意点もありました。

     品質の判断として、これまでは「レビュー工数」のようなプロセス指標で測定していたところを、ディープラーニングのシステムにおいてはプロダクト自体の性能(判定精度)で示せるのが大きな違い、とのお話がありました。ただ個人的には、「正確に判定できる」というのは品質特性の1つでしかないので、それだけとって「品質を定量的に示せる」とするのは物足りないと感じます。

    機械学習に基づくソフトウェアの難しさ

     技術的な難しさとして、要求定義と品質保証について言及がありました。
     要求定義の難しさは、いわゆる「フレーム問題」と呼ばれるもので、ハイコンテキスト前提の人間の指示を、ソフトウェアがパーフェクトに忖度することはできないという点です。
     品質保証の難しさは、ディープラーニングにおける「何かを変えるとすべてが変わってしまう」(Changing Anything Changes Everything)性質に由来するものです。この性質のもとでは、ユニットテストを定義することさえ困難であるということです。また、adversarial exampleのような新しいタイプの脆弱性が生まれていることも、保証の難しさにつながります。

     またビジネス面の難しさとして、「100%のものはできない」ということに対する社会的な受容が必要ということです。同様の話は、SQiP2016における、デンソーの早川浩史氏のご講演「つながるクルマのセーフティ&セキュリティ」でもあったと記憶しています。そもそも現在のソフトウェアだって完璧なものではないことは明らかなのですが、「ディープラーニング/自動運転車は判定を間違うこともある」ことを社会が受け入れ(あるいは麻痺し)なくてはなりません。

    統計を勉強しよう

     ソフトウェアエンジニアに必要な知識として統計、特に事前確率などベイズ統計の基本的な知識を挙げていました。
     質疑応答では、ソフト屋は統計を知らないといった論調があったように思いますが、割とみなさん統計好きですよね? 僕はそうでもありませんが・・・特に自由d・・・うっ頭が・・・。

    所感

     機械学習のニュースやトレンドをきちんと追っている人には当たり前のお話だったのかもしれませんが、特徴や注意点などの概要をお聞きすることができて有益でした。また、今後テストがますます難しくなっていくことがよくわかりました。
     こんな話もありましたね・・・これも、Changing Anything Changes Everythingの一種だと思います。

    itpro.nikkeibp.co.jp

    AIによるソースコードレビューの変革

     富士通アプリケーションズ株式会社の森崎雅稔さんによる、「AIでソースコードの良しあしを判定する」お話です。Twitterでも話題になりましたね。ニュース記事はコチラ。

    itpro.nikkeibp.co.jp

    何をやっているのか

     記事を読んだだけでは、従来のソースコード解析との違いがよくわからなかったのですが、かなり別ものでした。この技術ではコードの文法や意味を理解させるのではなく、コードを画像のパターンとして認識させて、良い/悪いの判定を行っているのだそうです。
     ここでの判定は「バグの有無」ではなく、保守性や可読性といった内部品質の良しあしです。ただ経験則的に、内部品質が悪いコードを書く人は、バグを作り込むことも多いという相関があり、悪い判定はそうズレないとのことでした。

     なお、単純に画像化するだけでなく、レビューエキスパートの観点が反映される工夫をしています。
     たとえば、いわゆる「複雑度」といえばネストの深さなどで計算されますが、そういう制御構造以外にもレビュアが「複雑でレビューしづらい」と感じるコードの特徴があるので、そういう特徴がうまく画像パターンに現れるようにしているということです。
     ディープラーニングといえば、学習用の加工だけして後は機械に学習させるというイメージを持っていたので、これは意外でした。

    運用面での工夫・苦労

     今回紹介された技術は、少なくとも現時点では既存のコード解析ツールを代替するものではなく、互いに補完するものとしています。既存のツールに加え、今回のツールをSEの日常に自然に組み込んでいくことが大事だとのお話がありました。また、既存のツールのように「ダメな点をひたすら指摘する」のではなく、良い部分は良いと見える化することが、ユーザのモチベーションにもつながると。

     その他、「いいコード」「悪いコード」の収集と、それらのスコアリング(もちろんレビュアによる手動!)に苦労されたとのこと。これは想像に難くないですね・・・。

    所感

     どんどん大量のデータが集まってくるセンサーデータと違って、人間の手による成果物をディープラーニングの入力にするのは厳しそうだと思います。特に教師あり。こんな話もありました・・・。

    itpro.nikkeibp.co.jp

    ソフトウェアの不具合検知・修正への機械学習の応用について

     産業技術総合研究所の森彰さんのお話です。
     「AIによるソースコードレビューの変革」とこちらが、「AI for SE」のカテゴリです。

    AIで何ができるのか

     Fault Detection、Fault Localization、Fault Repairの、3つの分野での応用を紹介されています。検知、同定、修復、ですね。
     重点が置かれていたのは、修復です。
     方法の1つとしては、バグを含んだソースコードの一部を変換し、そのコードでテストを実行するというもの。テストをパスすればスコアが得られるゲームとして、変換を繰り返し行っていくうちに、ものによっては修復ができてしまうそうです。この場合の「修復」は、「既存のテストをすべてパスする」という意味でしかなく、単にテストが弱かったということもあるのですが、それを踏まえても3~4%は「本当に」直るとのこと。

     これも十分、力業という印象を受けたのですが、さらに力づく感があるのが、Vertical Code Transplantingという技術。ある特定の機能を実現するためのコードは、似たものがきっと世界中のどこかのリポジトリにあるだろうということで、それを探してもってきて、それを自分のコードに反映してしまうのだそうです。この「似たもの」というのは、文法構造の類似ではなく、やろうとしていることが似ていなければならないのですが、この「意味的コードクローン」の判定がそれなりにできてしまうので、荒唐無稽な話でもないようなのです。
     自動的にコードが修復されていく世界が未来過ぎたのですが、「GenProg」で検索すると関連資料がたくさんあり、驚きました。

    質問したこと

     今回のお話で気になったのは、ユニットテストが完備されていて、かつ短時間で完了できるということが前提になっている点です。
     たとえばIoTの世界だと、多数の機器が接続された、バリエーション多彩な環境で動作して初めて発現するバグがより深刻だと考えられます。そのようなバグを見つけるにはシステムテストレベルのテストが必要で、その実行はおそらくユニットテストのような時間オーダーでは終わらないのでは・・・という点が疑問で、質問させていただきました。

     そのようなケースは、修復よりまず検知と同定が課題であり、AIによるログのパターン解析が使えるだろうとのご回答をいただきました。
     また上述のような背景から、今後はプロダクトコードよりもテストコードを正確に書くことが重要になってくるとのご意見もいただきました。

    所感

     このような話を弊社の大先輩エンジニアとしたところ、「テストコードを完璧に書くというアプローチと、要件を形式的に書くというアプローチの本質的な違いは何なのか、意見を聞きたい」と言われました。

     テストコードをプロダクトコードに対する要件と捉えると、本質的な違いはないようも思います。
     少し考えて、「前者のアプローチは、適切なテストコードが追加されるごとに、自動的に品質が良くなる(蓋然性が高い)点が違うのでは」といった趣旨の回答をしましたが、それは後者でも変わらないですね。つまり、不足していた仕様を追加すれば、そこから導出されるソフトウェアの品質は上がっているはずなので。

     もう1点、形式的に記述された仕様から導出するプログラムが仕様を完全に満たすのに対して、テストコードから修復されるプログラムはあくまで「いろんな可能性の中で一番よくテストコードをパスしそうなもの」であるにすぎず、すべてのテストコードをパスすることを保証しない(もっとも多くパスすることも保証しない)という点が違うのかなーと思いました。
     みなさんはどう思われますか?(全然所感じゃない)

    Neural Network ConsoleによるDeep Learning研究開発の効率化

     ソニーの小林由幸さんによる、ソニー謹製のディープラーニング研究開発ツールのお話で、ここから2つが「SE for AI」のカテゴリー。  プログラマ向けの関数プログラムである「ライブラリ」と、商用開発に対応したツールである「コンソール」があり、セッションは主に後者のデモでした。
     自社ツールの紹介ではありますが、お金のにおいを感じさせない、開発者の情熱に溢れたプレゼンテーションでした。

     製品紹介は、YouTube上でも見ることができます。
     こちらもディープラーニング学習者ならとっくに知っているものなのでしょうが、わたしは初見でして。
     GUI上で各種レイヤをグリグリ並べて、整形済みデータを流し込むと、すぐに学習が始まって精度も測定される。一番よい精度を出せそうなネットワーク構成の探索も自動でやってくれる。コストに効いてくる計算量もわかる。そしてそのGUIも、SONYらしく美しい。


    Neural Network Console:ツールで体験する、新しいディープラーニング

    所感

     AffineやCNNなどは、プログラミングにおけるif文と同じで、一度理解すればそれで済む。理解したら、コンソールのようなツールでいろいろ試してほしい。というお話がありました。
     わたしは『ゼロから作るDeep Learning』でゼロから学びきれず落伍しましたが、再度立ち上がって一通り基礎を習得し、そのあと堂々とこの手のツールを使えるようになりたいです。

    ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装

    ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装

    機械学習における品質保証のチャレンジ

     国立情報学研究所の石川冬樹さんによるセッションです。
     機械学習に基づくソフトウェアにおける困難と、その打開策についてお話いただきました。

    何が難しいのか

     欠陥に気づくことができるのか、直せるのか。何をもって完成とし、どのようにユーザに説明するのか。
     テスト工程以降のあらゆる工程に困難さが発生することになります。それを解決する方法として、いくつかの手段を紹介いただきました。

    • Metamorphic Testing: 入力をこう変えると出力はこう変わるはず、という関係を活用して多数のテストケースを生成する。たとえばアイテムのランキングの機能があったとして、アイテム群から1つのアイテムを抜いても、残ったアイテムのランキングの上下関係は変わらないはず、という関係を確認するためのテストは、たくさん考えることができる。
    • Search-based Testing: メタヒューリスティックを用いて、スコアを最大にするようにテストスイートやテストケースを生成し、カバレッジを高く、テストケース数を少なくする技法です。
      ・・・これではまったくわかりませんが、辰巳敬三さんによる記事がこちら(pdf)にあります。

     またホワイトボックステストにおいて、コードをカバーするだけではダメで、ニューロンのカバレッジを上げる必要があるとのお話がありました。とはいえこれは人手でできるものではないので、やはり機械による大量入力を回すしかない。また、GAN(Generative Adversarial Network)による意地悪なデータでソフトを試すというアプローチも実用になりそうとのことでした。

    blogs.nvidia.co.jp

    所感

     テスト技法といえば、「無限ともいえるテスト空間をいかに効率よく、合理的に狭めるか」、ざっくりいうと「テストケースをどう減らすか」に焦点を当てたものを捉えていました。
     が、「テストケースをどう増やすか」という真逆の目的をもった技法があることを学びました。短時間で完了するテストケースと期待値をできるだけ多く、自動的に生成し、それを全部流してプロダクトの妥当性を検証するというアプローチなんですね。
     誰かMetamorphic Testingの勉強会やりませんか? 理解できる自信はないのですが。

    総合討論

     5人の講演者の方と会場からの質問による、パネルディスカッションです。
     いろいろなトピックがあったのですが、特に印象に残ったのは「ディープラーニングに基づくソフトウェアが出した答えをどう説明するか」についてでした。単に「学習の結果、こうなりました」では、答えを言われた方は納得できないでしょう。

     富士通の森崎さんは、たとえば「コードが良くない」と判定された理由をできるだけ伝えるようにしているとの答えでした。やはり判定を誤ることもあるので、既存のメトリクスも使って総合的に判断しているとのこと。

     一方、ソニーの小林さんのご意見は逆で、「理解してもらう必要はない」とのこと。なぜなら、人が理由を知りたがるのは、その理由に基づいて人が対処しなくてはならないから。将来的にはその対処を機械が行うようになるので、人の介入は不要、説明も不要になるという見解です。
     森さんのお話にあった欠陥修正にしても、自動で修復されていくのであれば「コードのどこの部分が悪かったのか」を人が知る必要はなくなるのかもしれません。
     ただそうはいってもその見解に誰もが納得するわけではないので、人の意識を変革していく必要があり、それは我々の仕事だ、というご意見でした。

     石川さんのご意見は、「説明できない、ルール化できないからこそディープラーニングを使っているのだから、説明を必須とすると普及しない」というものでした。ただし、社会学的・心理学的に「説明」が必要なのであれば、ディープラーニングでそれっぽい説明を自動生成すればいい、との極論(?)も出ました。

    おわりに

     パネル含め、すべてのセッションが有意義で面白く、ディスカッションも活発で、参加できたのは本当にラッキーでした。
     JEITAさんのイベントは初めてだったのですが、今後もウォッチしていきたいと思います。ありがとうございました!

    【翻訳】「アジャイルテスト」、わたしたちの定義

     『実践アジャイルテスト』の著者である、Janet Gregory、Lisa Crispinの両氏による『Our Definition of “Agile Testing”』という記事を、許可をいただいて翻訳してみました。

    agiletester.ca

     この本、勢いで買って店晒しにしておったのですが、最近やっと読み始めまして、とても気に入っています。あらゆる経験、知識、エピソードをとにかくぶっこんでみた!という勢いと厚さが好きです。つまみ食いでも得られるものがあると思いますので、未読の方はぜひ。

    実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

    実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

     では、以下が翻訳です。

    アジャイルテスト」、わたしたちの定義

     Janetの講義で、学生の一人がアジャイルテストの定義を尋ねてきた。彼が求めていたようなわかりやすくきれいな定義は、3日間の講義の中では得られなかったのだ。
     Janetは自著である『Agile Testing』と『More Agile Testing』を調べてみたが、簡潔な定義はどちらにも載っていなかった。ブログポストにあるものが、最も答えに近いものだった。

     そこで、LinkedInのアジャイルテストのグループと、長く続いているアジャイルテストのYahooグループで質問してみることにした。
     「アジャイルテストの定義はどんなものだと思いますか?」

     多くの人が、アジャイルを定義しようとしたり、定義の中で「アジャイル」という言葉を使ったりしていた。この言葉を使うことにまったく同意しない人もいるが、「アジャイル」という言葉自体は形容詞であり、「アジャイルテスト」という言葉は間違ってはいないだろう。また、テスターのロールではなく、テストという活動自体にフォーカスしたかった。

     すべてのやり取りと、わたしたち自身の考えを踏まえた結果、考えついたのが以下の定義だ。

    アジャイルテストの定義(Lisa Crispin、Janet Gregory)
     開発の始めからデリバリーまでに行われる協働的なテストのプラクティスで、顧客にビジネス価値をもたらす高品質なプロダクトの、高頻度なデリバリーを支える。テストの活動は、欠陥を見つけることではなく抑えることにフォーカスするものであり、「品質に対するチーム全体の責任」という考え方を強め、支えるためにある。

     アジャイルテストは、以下のようなテストの活動を含む(が、これに限られない)。
     具体的な例を挙げて開発を導く。アイデアや仮定をテストするために質問を投げかける。テストを自動化する。探索的テストを行う。性能、信頼性、セキュリティといった品質特性のためにテストする。

     この定義があなたにも響いてくれればいいが、そうでなければコメントを残すか、メールしてほしい。この定義はまだ初めのもの、ドラフトであり、変更したり適応させたりすることに、わたしたちはやぶさかでない。

     すでに寄与してくれた人に感謝したい。有用なアイデアもあればそうでないものもあったが、すべてがわたしたちの検討の役に立った。
     以下は、グループメンバーからもらったコメントや定義の一部である。上述のグループを訪れて、やり取り全体を読むこともできる。

    • 重要なプロダクトを欠陥なしかつ迅速にリリースできるようにする、協働的かつ継続的な活動
    • アジャイルのコンテキストでは、高速なイテレーションと継続的な改善という環境におけるテストであり、変化とプレッシャーに対応するものである。
    • Elisabeth Hendricksonの『Agile Testing Overview』(pdf)を教えてくれた人もいた。これはみなさんにぜひ読んでもらいたいものではあるが・・・、21ページもあり、簡潔な定義とは言えない。
    • イテレーションベースの成果物を支える迅速なフィードバックをもたらすために、短い時間で結果が得られる効果的なテスティング
    • アジャイルテスティングとは、最初の1日目から、プロダクションに提供されるまでの間ずっと取り組むものである。
    • アジャイルテスティングは、ビジネス価値と、顧客が求める品質に直接フォーカスする。アジャイルテスティングにおいてテスターは、品質に対して一丸となって責任を持つ、アジャイル開発チームの一員である。
    • 顧客の視点からテストし、ビジネス価値を高めること。それはプロダクトのゴールなのだから、とても重要だ。Gojko Adzicの「ソフトウェア品質のピラミッド」の言葉を借りると、「使うことができる」(usable)、「役に立つ」(useful)、「成功である」(successful)というのは時に、テストの話だとは考えられていないが、わたしにとって「アジャイルテスター」は、これらすべてのレベルを意識しているべきであり、少なくともどのようにテストすればいいのかをチームに知らせるべきだ。
    • 品質に対するチームの責任感を強める。
    • Karen Greaves and Samantha Laingのテストマニフェストに言及する人もいた。

    わたしたちは、以下のことに価値をおく。
    「最後に行うテスト」よりも「ずっと行うテスト」に、
    バグを見つけるよりもバグを防ぐことに、
    機能をチェックすることよりも自分の理解をテストすることに、
    システムを壊すことよりも最高のシステムを作ることに、
    テスターの責任よりも品質に対するチームの責任に。

    • アジャイルテストは、アジャイルソフトウェア開発において切り離された活動ではなく、切り離せない部分である。
    • アジャイルテストは、バグが起こるのを待っているのではなく、未然に防ぐものである。
    • 協働/アジャイルは、プロジェクトの最後だけ(あるいは最初の少しと最後だけ)でなく、プロジェクト全体を通じてテスターは一緒にいるのだという事実を教えてくれる。
    • ユーザストーリーに対して質問を投げかけたり、受け入れ基準を作り上げるのを手伝ったりすることで、プロジェクトは良くなっていく。バグを見つけるのが遅くなるほど、プロジェクトにとって高くついてしまう。
    • アジャイルテスティングは、サイクルの短い開発でペースを保つためのテストである。
    • 価値とアジャイルマニフェストのプラクティスを支える、テストのプラクティス

     わたしたちが提起した問題に取り組み、探究を助けようとしてくれた、以下の方々に感謝する。誰かを漏らしていたら申し訳ありません。
     Augusto Evangelisti, Tim Western, Gaurangi (Surve) Rawat, Richard Cowling, Vivek Sharma, Wim Heemskerk, Eddy Bruin, Steven Gordon, Lionel Champalaune, George Dinwiddie, Adrian Howard。

    JSTQB Advanced Level - Test Analystシラバスのわからないところ - その1 -

     来たる2017年2月11日(土)、JSTQBの試験が催されます。わたしは、テストアナリストの第1回試験を受験するつもりです。前回のトライアルは受け忘れていました。
     受験料が高いので一発合格したいのですが、もう3週間前となってしまったため、慌ててシラバスを読み始めましたよ。61ページ中、すでに14ページまで読み終わりました。すごくないですか? ちなみに、7ページ目は「シラバスの紹介」で、本文は8ページ目からです。すごくないですか?

     さて、テストマネージャーの方は全章について2周分も学習ブログ記事を書いたのですが、もうそんな余裕はありません。シラバスを読んで、理解できなかった部分を解読するだけの記事を投下していきます。

    1.3.1 テスト計画作業

     以下のような記述があります。

    The documentation must be accurate to be effective. The Test Analyst must allocate time to verify the documentation ...
    正確で有効なドキュメントを作成する必要がある。テストアナリストは、時間をかけてドキュメントを検証する必要がある。

     これだと、テストアナリストがドキュメントを検証するかのように読めます。
     テスト計画の話なので、「ドキュメントの検証に時間を割り当てる必要がある」というのが適切ではないでしょうか。

    1.3.2 テストのモニタリングとコントロール

     以下のような記述があります。

    While the Test Manager will be concerned with compiling and reporting the summarized metric information, the Test Analyst gathers the information for each metric. Each test case that is completed, each defect report that is written, each milestone that is achieved will roll up into the overall project metrics. It is important that the information entered into the various tracking tools be as accurate as possible so the metrics reflect reality.
    テストマネージャがメトリック情報の要約を編集およびレポートする場合、テストアナリストは各メトリックの情報を収集する。完了した各テストケース、記述した各欠陥レポート、達成した各マイルストンを全体的なプロジェクトメトリクスにまとめる。さまざまな追跡ツールに入力する情報を可能な限り正確にして、メトリクスに現実を反映させることが重要である。

     この訳では、whileの意味が失われているのではないでしょうか。
     この文章は、テストマネージャーとテストアナリストを対比したものだと僕は理解しています。つまり、以下のような感じ。

    • テストマネージャー: 要約されたメトリクス情報を集めて報告することに関心がある。overall的。
    • テストアナリスト: 要約される前の個別の情報を成果に保つことに関心がある。each的。

     「全体的なプロジェクトメトリクスにまとめる」には主語がないのですが、この仕事をするのはアナリストではなくマネージャーなのではないでしょうか。

    1.5 テスト設計

     以下のような記述があります。

    Still adhering to the scope determined during test planning, the test process continues as the Test Analyst designs the tests which will be implemented and executed.
    テスト計画作業時に決定されるスコープに従い、テストアナリストが設計するテストを実装および実行して、テストプロセスを継続する。

     これは明らかな誤訳ではないかと。「テスト設計」の節なのに、「実装および実行して」いるのはおかしいですね。
     「テストアナリストは、(今後)実装・実行する(ことになる)テストの設計を行う」というような意味になるかと思います。

    If the author is not the person who executes the test, other testers will need to read and understand previously specified tests in order to understand the test objectives and the relative importance of the test.
    テスト作成者がテストを実行しない場合、他のテスト担当者はテスト目的およびテストの相対的な重要性を理解するために、以前に指定されたテストを参照し、理解することが必要になる。

     「以前に指定されたテストを参照し、理解する」というのが意味不明です。が、原文を見る限り「事前に具体化されたテストを読んで、理解する」ということではないでしょうか。Aさんが事前に定義したテストケースを、Bさんが読んで理解するって話ですね。
     specifiedとかspecificという単語は訳が難しいですねえ。

    1.5.1 具体的テストケースと論理的テストケース

    Logical test cases provide guidelines for what should be tested, but allow the Test Analyst to vary the actual data or even the procedure that is followed when executing the test.
    論理的テストケースは、テスト対象とすべきものに関するガイドラインを提供し、テストアナリストが、テスト実行時に実データや手続きさえも変更することを可能にする。

     まず原則として、テストアナリストはテスト担当者とは違うロールであって、「テストを実行する人」ではないと思います。なので、「テストアナリストがテスト実行時に変更する」というのはおかしいです。
     原文を読む限り、おそらく修飾関係が違っていて、「論理的テストケースはテストすべき対象についてのガイドラインとなるが、テストアナリストは実際のデータや、テスト実行時に従う手順さえも変えることができる」ということではないでしょうか。

    1.5.2 テストケースの作成

    Depending on the scope of the testing, test analysis and design address the quality characteristics for the test object(s).
    テストのスコープに応じて、テスト分析およびテスト設計は、テスト対象の品質特性に対応させる。

     この文章の主語がわからないのですが、「対応させる」だと意味がとれません。
     「テストのスコープによっては、テスト分析とテスト設計において、テスト対象の品質特性を扱う」ということだと思います。

     今日はここまで。
     「訳文に文句つけるならおまえが訳せよ!」って話もありますが、読んでケチつけるのは楽な仕事だって自覚してますので。。。