NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'19 Tokyo
HOME > 活動報告 > イベント報告 > JaSST'19 Tokyo
2019年3月27日(水)～28日(木) 於 日本大学理工学部 駿河台校舎１号館
JaSST'19 Tokyoが日本大学理工学部駿河台校舎一号館で開催された。
筆者が参加したセッションの内容を以下に報告する。
本セッションでは、Ultimate SoftwareのTariq King氏がAI 駆動自動テストの研究内容と現状について発表した。
現在のAutomation Testは、「Automation」といいつつ実はManualだ。人間が「正しいこと」を定義しているためだ。AutomationのコードをManualで作り、人間が結果を確認しなければならない。
Tariq氏は本当の意味の「完全な自動化」ができるか、人間の関与無しに、ソフトウェアをテストできるかを研究した。AIが人間によるサポートなしに自律してテストできることを目指さなければいけないと語った。
AI（Artificial Intelligent）とは人間の真似、知性を模倣するものである。AIはIA（Intelligent Agent）であると言える。自らの状態を分析して、行動をリアルタイムで適応させることができる。機械学習とはアルゴリズムを自ら学び、これまでの経験に基づいて推論することだ。「xならy」という事例を渡すだけで学習し、特徴から推論することができる。これは、クラスタリングという考え方である。
プログラムは、データを受け取ってトレーニングベースで正答率を上げる。トレーニングの方法には、「教師ありの学習」、「教師なしの学習」、「強化学習」の3つがある。
AISTは、ソフトウェアをテストするためのAI System、AI Systemをテストするための方法、そして最終的にはSelf-Testing（自己診断）とSelf-Healing（自己修復）が可能なソフトウェアの設計を目的とした新しい分野である。
ソフトウェアは、新機能の追加や既存機能への作用などで複雑さが増していく。従来のテストではソフトウェアの複雑さに応じたテストをすべて実行することはできない。そのため、複雑さから生じる膨大なるテストと実際のテストカバレッジのギャップが広がる。AI駆動自動テストは、そのギャップを少なくすることが重要である。AIを用いてテストを自動生成し、より多くの範囲をカバーすることが可能となる。
Tariq氏は、AGENTというプロトタイプを紹介した。このプロトタイプはトレーニングデータを使用してWebサイトを探索し、その行動・分野・フォームを評価することを自律的に学習する。AGENTは、テスト可能なパターンが認識されたときにWebアプリケーションを探索し、テストフローを適用する。
GitHubからUltimate Software(*)を検索すると、AGENTを使用できる。
* Ultimate Software：
https://github.com/UltimateSoftware/AGENT
共通のドメインの人達がコミュニティを作って活動することで、そのドメインの汎用は可能だと考える。多くの人に実践してもらい、それを共有してほかのシステムに使ってトレーニングさせていく必要がある。「自ら実践し、理解することを推奨する。」とTariq氏は語った。
講演を聞く前、AI Driven Testingは、AIが作成したテストケースを自動で実行するシステムであると想像していた。Tariq氏が考えるAI Driven Testingは、AISTというソフトウェアテストのためのシステム自体のテストと、自己修復を可能にすることを目的にしており、想像を大きく上回る内容であったため大変驚いた。
講演の全体から、技術が実用化されるのを待つのではなく、技術を学び、コミュニティで共有し、自ら取り組んでいくことで実用に近づくのだと感じた。筆者はこれまでAIに関しての書籍を読むのみであったが、AGENTというツールを用いてAI Driven Testingの知識を深めていきたいと思った。
HBAの安達賢二氏が、プロセス改善モデルの特徴と適用方法や注意点と、JaSST'18 Tokyoで発表した事例「TPI Nextを活用したチームメンバーへの問題意識から始めるテストプロセス改善」の拡張版を紹介した。
プロセス改善には「問題、課題ベースの改善」と「プロセス改善モデルベースの改善」がある。TPI Nextは「プロセス改善モデルベースの改善」に該当する。
今回発表するプロセス改善は、「問題、課題ベースの改善」と「プロセス改善モデルベースの改善」のハイブリッド版である。
プロセス改善モデルは、ソフトウェア開発やテストで成果を上げている組織やチームが実践していることを観察し、その共通的な特徴を体系化、モデル化したものである。プロセス改善モデルの中身は、解決すべき問題や乗り越えなければならない課題を解決するための手段（施策）の集合体である。使いこなすためにはその関係性を理解できなければならない。自らのコンテキストにとって重要なことが欠けているなら足しこむ、重要でないならば除外すればよい。プロセス改善モデルは「モデル」であることから一般化されており、重要な事以外は省略されている。背後に隠れた前提条件を読み解き、適用することが必要である。
3グループ（SR：利害関係者との関係、TM：テスト管理、TP：テスト業務の専門性）に16個のキーエリアと146個のプラクティスがあり、16個のキーエリアのそれぞれに初期・コントロール・効率化・最適化の4レベルが定義されている。このモデルをベースにアセスメントを実施し、成熟度を判定する。改善目標やビジネスゴール達成に寄与するキーエリアを中心に、改善をすすめることができる。
TPI Nextの特徴は以下である。
プロセス改善モデルは、「重たい」「難解」「効果が実感しにくい」といった問題点があり、プロセス改善モデルを理解してからでなければ、迷走、頓挫、自然消滅してしまう。最初にTPI Nextのキーエリアに対してアセスメントを行ったが、正しい評価結果か、実態に合っているかの不安があった。結果には多くのNGがあり、どこから改善していくかがわからなかった。
そのため、まずはチームの振り返りコメントを収集→整理して詳細化した。そして、再度、整理→分類というように改善対象の特定を行った。次に、TPI Nextによるテストプロセス全体像と要素を把握し、関係者の問題意識が集中している個所を特定した。関係者の問題意識というリアルなQCD問題関連事象や困りごとを掘り下げて把握することで、改善目標の設定ができるようになり、当初のセルフアセスメント結果の有効な修正が可能になった。また、改善すべきターゲットの候補を決めるため、QCD問題関連事象や困りごとは問題構造図を作成して単純化し、再整理を行った。問題構造図から効果がありそうな施策の方向性を検討し、関連するTPI Nextのキーエリアとプラクティスを洗い出し、関連したプラクティスから改善施策の要件を検討することができた。
安達氏が発表した事例では実際の問題事象や困りごとといった「感情」や「事象」「出来事」「結果」をコアにしている。本アプローチの利点は、TPI Nextの146個のフルアセスメントを行わずとも、16個のキーエリアにメンバーの問題意識をマッピングすることで、改善対象領域を特定できることである。プロセス改善に取り組みながら、TPI Nextの理解度向上に応じて、活動深度を進化させられる。一方で、構造分析実践スキルが必要なため、当初は有識者の支援を受けるなどの対策が必要である。
本アプローチは「自分たちの今を知る」ことで実務メンバーの心に灯をともし、自ら走り始めるためのものである。徐々に自らを活かすことができるようになった場合、「自らのミッションを明確にし、それに従う」ことにチャレンジする必要がある。ミッションや目的達成のために、プロセス改善モデルを有効活用できるようになる必要がある。
筆者は普段の業務の中でソフトウェアテストを行っているが、プロジェクトの問題を解決させるための方法に悩んでいたため、本講演を大変楽しみにしていた。実際に聞いてみて、「実際の問題事象や困りごとをコアにしている」というところに惹かれた。これらの技術はすぐに身につくものではない。だからこそ学習し、理解を深めながら徐々に取り入れていきたいと思った。
本セッションでは富士ゼロックスの秋山浩一氏が、これまでの「トラディショナルなQA（品質保証）」の基本的な考え方を紹介し、LIFULLの中野直樹氏が「先進的なQA」今日の現場で行われているQA部門の取り組みの事例や課題について紹介した。
「品質保証」は定義しにくい言葉である。
例えば、「A社の車はぶつかっても安全」「B社のハンバーガーはできたてでお待たせしない」といったことが品質保証できているということである。抽象化すると、「○○の△△は××」となる。（○○：自社名、△△：商品名やサービス名、××：提供している価値）
「△△」に入るものが「品質が保証できているモノあるいはコト」である、と秋山氏は説明する。「××」をより良いものにすることを「品質改善活動」と呼ぶ。
品質保証は、「対象物が明示的、または暗黙的に期待されている要求やニーズを実現した商品やサービスであること」の確信をお客様に与えることである。
お客様の価値にフォーカスした先に利益があり、結果が付いてくるというのが品質保証の基本的な考え方であり、これらの品質保証を実現する「全社的活動を推進する部門」が品質保証部である。
近年、今までになかったテクノロジーが発表されており、それらは今後の製品に活用されるだろう。品質保証の分野においてもそれらにどのように向き合うのか方針を考えていく必要がある。
ソフトウェアテストが十分であったことは、何を根拠に判断すべきか。
３つのプライオリティをつけて紹介する。（Ａ→Ｂ→Ｃの順でプライオリティが高い）
「Ｂ」は「要求を満たしていること」で良いと思っていても、近年はサービス過多の時代であることから競合に対して不足が無いことが重要である。
顧客満足のために製品が作られているのなら、本当に評価されているかを考えていく必要がある。
1）認識の不足
品質には「使用性」が存在するが、ノウハウが確立されているとはいいがたい状況である。デザイナーや専門家と議論することが重要であり、我々がどう評価すべきかを考える必要がある。
2）知識の不足
利用時の品質を評価するには、人間の行動を理解していなければならない。製品品質だけでなく利用時品質にも責任をもつために、必要な仕組みを考え定義していく必要がある。
デプロイメントパイプラインにもQA（品質保証）が関与すべきである。品質保証の組織は、DevOps文化の中でリリース高速化やテストの最適化などに貢献できると考える。
※デプロイメントパイプライン：コードをデプロイするとテストが自動で行われ、Passするとユーザーの本番環境に届く仕組み
バランスのとれたQCDと生産性を高めるために、品質保証部と開発の関係はどうあるべきか。
案１）マイクロマネジメント型QA
問題発生を防ぐためにプロセスを細かく手順化し、管理する。
案２）サーバントマネージメント型QA
自分たちのことは自分たちで考えて実施させ、不足や要求に対して必要なサポートをする。
会場の参加者にどちらの案が有効かアンケートを取ったところ、案２へ挙手した参加者が多く見られた。中野氏は、どちらが正しいかはこの場で決めることは出来ないが、品質保証部・開発の双方のモチベーションを維持できることが最高の組織であると語った。
品質保証部と開発組織がどのような関係とするかを話し、どこに責任を持つのかを決めるべきである。
本日発表したことはQAだけでは成しえない。開発組織と共に協力してモチベーションを阻害しない組織づくりをしたい。
品質保証の基本的な考え方とこれからのQAの姿について知ることができた。
共通して言えることは、品質保証はどこかの部署や誰かがやることではなく組織で取り組むことだということだ。自分が所属する部署のことだけを考えがちになっていたが、組織全体で顧客が満足する品質を目指すことの重要性を学んだ。
本セッションでは、テストマネージャのエキスパート達が3つのテーマに対して、テストマネジメントで「鉄則」として行っていること、考えていることなどを紹介・議論した。
『欠陥管理がうまくいかないのはエクセルのせいではない』（町田氏）
最近では、欠陥のトラッキングツールを使用することがあるが、これまでの欠陥管理はエクセルを用いることが多かった。しかし、欠陥管理が上手くいかない原因はツールでは無く、プロセスの問題である。「欠陥管理のワークフローやバグの書き方を決めておくなどルールを決めることが重要である。」と町田氏は語った。
湯本氏は「ツールはメンバーである」とし、「メンバーと同じように誰が面倒をみるのか、どのように使用するのかもセットで考えなければならない。」と語った。
『転がし続けろ』(湯本氏)
欠陥のチケットを起票してから音沙汰が無い状態が問題である。「転がす」というのは、常に状況を更新やステータス変更を行い放置しないということだ。例えば、開発チームが複数ある場合に、どのチームが担当するか決まらないことがある。それを防ぐために、欠陥状況の確認会議を開いて滞留している欠陥を確認する。また、滞留しない仕掛けを作ることも大切である。チケットにいつから再テストが出来るのか、日付を入力する欄を設けて入力してもらうことが効果的である。
『欠陥レポートタイトルはすべて記憶しろ』(長谷川氏)
IDや数字で呼ばずに具体的なバグの内容で会話したい。「あの登録できないバグどうなった？」など、プロジェクトで何が起こっているか意識できるためである。バグのタイトルにもコツがあり、タイトルだけで何が起こっているかがわかるように書くことが重要である。また、長谷川氏のチームではバグ票にわかりやすいタイトルを付けることを推奨するため、「声に出して読みたいバグ票コンテスト」を開催しており、一例として「組織を異動させると上司だけ異動して部下がついてこない」というタイトルを紹介した。
『念入り肝入のものはNG』（湯本氏）
テスト計画は1度作成しても必ず変更することになる。いかに変更に合わせていくかがテストのプロジェクトマネジメントの難しいところである。まずは、決定しなければならないことや、計画書に記載すべき関係者との合意事項が何かが決まっていれば良い。詳細な作業計画よりも先に、コミュニケーション計画やテストレベルのスコープについて合意すべきである。
『安心しろ、奇跡は起こらない』(長谷川氏)
奇跡が起こるつもりで計画しないこと。例えば、テスト1ケース15分の見積もりを「10分くらいになら短縮できるだろう」という見積もりに変えて計画を立てたとしても、計画通りには進まない。「慣れているテストだから1ケース8分」、「今回はバグも出ないだろう」と日程に当てはめるように計画しがちであるが、そのような奇跡は起きない。無理に日程に当てはめるのでは無く、日程に合わせた際に起こるリスクを検討するべきである。テスト計画が100点になることが大切なのではなく、決定すべきことが決定したらテスト計画を作成し、その後状況の変化に合わせて随時更新しなければならない。
『テスト計画はみんなのために』（町田氏）
テスト計画はプロジェクトマネージャー、開発者、顧客、経営層など様々なステークホルダーへ報告し合意をとらなければならない。しかし、八方美人な計画は不可能なためバランスを取って折り合いをつけることが重要である。全ての情報を全てのステークホルダーに知らせる必要は無く、伝えるべき人に伝わるように書くべきである。また、計画の数字のみを確認するステークホルダーも存在する。そのような層に対して、定性的な事柄を含めて報告しなければならないと考える。
このテーマの最後に、JSTQB Advanced Level Test Manager シラバスの一部を紹介した。
1.2.1 テスト計画作業
各テストレベルにおいて、テスト計画作業はそのレベルのテストプロセスの開始時に始まり、そのレベルの終了作業が完了するまで、プロジェクト全体を通じて継続する。
パネリストたちは、シラバスで『プロジェクト全体を通じて継続する』と書いてある部分について、「計画はプロジェクトの初めに立てるだけではなく、継続して更新することが大切だと実感している」と述べた。
『ツールとパトロール』(長谷川氏)
進捗管理にはテストマネジメントツールを使用すべきである。進捗状況を担当者ごとではなく1人のところへ、つまりテストマネジメントツールに集約する。テストマネジメントツールで見えない状況や問題を把握するために、現場のパトロールによる聞き取りをすることが大切である。パトロールすることで、テストエンジニアはテストに注力できる。また、大きなプロジェクトの進捗管理では、進捗の確認に1日を費やしてしまうこともある。正しい情報がテストマネジメントツールに集約されているだけで、テストマネージャの仕事は楽になる。しかし、テストマネジメントツールは導入するだけでは効果は得られない。「1日の終わりにこの情報を入れてから帰る」というように、利用時のルールを徹底しなければならない。
『親身になるな』(湯本氏)
リリース直前になると「テストは足りているか」と各所から不安の声が上がる場合がある。しかし、テストを追加しないこともテストマネージャの重要な仕事である。テストを完遂させるためには、目的が異なるテストフェーズの中に全く違うテストを差し込まないこと。バグ検出の傾向を見て、追加で必要なテストがあれば別枠で実行すべきである。
『見えている数字に騙されるな』(町田氏)
進捗は合格数で管理しなければならない。進捗数はテストに合格した数なのか、実行した数なのか、数字の定義や意味を理解すること。意味を取り違えると、不合格が多いにも関わらずテストを消化しているように見えるため、合格した件数で進捗状況を判断するべきである。数字の定義の認識を合わせて、自分が報告する際にも正しく伝えなければならない。
長谷川氏は、会議の出席やバグ起票をすることを見積もりに入れておかなければ、計画と実際の進捗が合わなくなるため、1日あたりのテスト実行時間は6時間程度とするべきであり、8時間で見積もってはならないと語った。
筆者は、過去に参画したプロジェクトで、不具合やインシデントに対するレスポンスが無いことでテストの進捗に遅れが発生したことがあり、この問題を解決したいと感じていた。そのため、欠陥管理の「転がし続けろ」という鉄則はすぐに実践したいと思った。どのテーマも実際の現場で起こり得る問題に対して参考になることが語られ、大変有意義な時間であった。
はこだて未来大学の松原仁氏が、人工知能はどのような歴史を経て現在に至ったのか、人工知能に何ができて何ができないのか、人間と人工知能はどう付き合っていくべきかについて講演を行った。
人工知能の専門家の中でも明確な定義は無く、研究者の数だけ定義がある。工学的には、人間のような知性を持った人工物（コンピュータ、ロボット）を作ること、数学的には、コンピュータを題材にして知能を研究することである。人間の知能、感情、心とは何なのか。人工知能を研究するということは人間とは何かを研究することにつながる。
人工知能は3回目のブームである。今回のブームは、ディープラーニングが大きなきっかけとなっている。ディープラーニングを用いた技術として、音声認識・自動運転支援・コンピュータ将棋などが挙げられる。コンピュータ将棋は、1975年頃に研究が開始された。40年前、コンピュータ将棋や囲碁は、人間を超えられないと言われていた。しかし、2013年にプロ棋士に勝利し、2017年にはポナンザというコンピュータ将棋が、佐藤天彦名人に勝利した。将棋や囲碁はルールが明確で範囲が限定されている状況で解を早く求める。人工知能が得意とすることである。ルールが不明確あるいは、範囲が非限定の状況で解を早く求める場合、人間の方がはるかに得意である。
知能の側面の一つに創造性がある。創造性は人間だけのものでコンピュータには持てないという主張がある。しかし、コンピュータ将棋は新手を創造した。現在の機械学習のほとんどは、人間のデータから学習するが、コンピュータ将棋は人間より強くなったため、教師が人間ではなくなった。実際に、プロ棋士はコンピュータ将棋が指す手の意味を理解できなくなっている（ブラックボックス化）。コンピュータは、人間から学習したデータから、人間が思いつかなかった創造性を手に入れたと言える。
これまで、人間よりも賢い生物はいないと言われていたが、人工知能は人間を超える。これからの人工知能との付き合い方を考えなければならない。
コンピュータ将棋が人間に勝利したことはニュースで知っていたが、AI自身が新手を創造したことは知らなかった。AIの歴史と、実際に導入されている事例についてもわかりやすい内容であったため、楽しみながら聞くことができた。
筆者は、昨年初めてJaSST'18 Hokkaidoに参加した。そこでJaSSTというシンポジウムのすばらしさに感銘を受け、JaSST'19 Tokyoへの参加を決めた。
ソフトウェアテストは自動化が活発になっているが、基調講演ではAI駆動による自動テストという最先端の技術について学ぶことができ、改めてソフトウェアテストの発展の可能性を感じた。全体を通し、『ソフトウェアテストの技術やよりよい品質は誰かが実現するのではない。関係するすべての人達が考え、行動し、コミュニティが活発になることで実現されるものである。』ということを強く感じた。
記：吉田 絵理（JaSST Hokkaido 実行委員）