JaSST1'18 Kyushu 「単なる仕様チェックから卒業してテスト技術力を高めていくために」

単なる仕様チェックから 卒業してテスト技術力を 高めていくために ～抑えておきたいキホンのキ～ 池田 暁 NPO法人ASTER 理事 NaITE（長崎ＩＴ技術者会）代表 2018/11/22（木）於 長崎県美術館

自己紹介

自己紹介 NPO法人ASTERやNaITE、SQiPやAFFORDD等に参画しています 情報通信系→医用系→自動車系と渡り歩いています 現在は社内のテストプロセス改善活動を取りまとめています テストに関する書籍を執筆したり、イベントや勉強会にて講師をしたり、 コンテンツを作って公開したりしています 長崎県長崎市の出身です 今日は地元で発表できてとても嬉しいです！ 2018/11/22 © Akira Ikeda 3

NPO法人ASTERとは ソフトウェアテスト技術の普及振興に取り組んでいるNPO 全国各地でJaSST（ソフトウェアテストシンポジウム）やセ ミナーを開催しているほか、勉強会を支援します 全国各地でJSTQBによるテスト技術者認定資格試験を運営し ています その他、様々な調査活動や研究活動に取り組み、 様々なコンテンツを提供しています 是非ASTERの公式ページをご覧下さい！ http://aster.or.jp/ 2018/11/22 © Akira Ikeda 4

• http://aster.or.jp/

NaITE（長崎ＩＴ技術者会）とは 長崎出身や在住，かつて在住など，長崎になんらかの関わ りや興味を持っている技術者の交流会としてスタートしま した 長崎とありますが，興味がある方はどなたでも気軽にご参 加いただけます 長崎現地にかかわらず，全国各地で勉強会やイベントを開 催しています ■NaITE公式サイト SIG活動にも取り組み，マインドマップから始めるソフト ウェアテスト 読書補助ガイド」や「はじめてのバグ票シ ステム ～導入実践ガイド」を無料にて公開しています！ http://naite.swquality.jp/ ■Facebookページ https://www.facebook.com/NagasakiITEngineers/ 2015年4月に開始した 完全ボランティアの有志活動です！ 2018/11/22 © Akira Ikeda 5

• http://naite.swquality.jp/
• https://www.facebook.com/NagasakiITEngineers/

NaITE（長崎ＩＴ技術者会）とは # 開催日 内容 開催地 第19回 2017/01/21 数学を学ぼう 第20回 2017/04/08 プロセスモデル CMMI にまつわるちょっと深イイ話 第21回 2017/04/22 PSP概説＆体験ワーク（おかわり） 第22回 2017/05/20 はじめてのバグ票システム～導入実践ガイド － 2017/07/01 Agile Japan 2017 第23回 2017/07/16 Scrum入門＆Agile japan 2017 長崎サテライト参加報告 第24回 2017/09/17 テストカタマリー 第25回 2017/11/11 欠陥モデリングワークショップ＆解説 神奈川 # 開催日 内容 開催地 第26回 2018/01/20 『ゆるファシ』体験ワークショップ 神奈川 － 2018/02/02 3rd 長崎 Software Quality and Development Gathering 第27回 2018/05/27 ケースメソッド体験ワークショップ 神奈川 第28回 2018/07/21 プロダクトオーナーシップ ＆ Agile Japan 2018 参加報告 神奈川 - 2018/09/15 Agile Japan 2018 長崎サテライト with NaITE ～数学の知識を利用したソフトウェアテスト～ 神奈川 神奈川 定期的に，長崎内外で 勉強会やってます！ 東京 勉強会 神奈川 長崎サテライト with NaITE 長崎 東京 ワークショップ＆解説 神奈川 長崎 長崎 是非ご参加ください！ ＆ 一緒に企画しましょう！ http://naite.swquality.jp/ 2018/11/22 © Akira Ikeda 6

• http://naite.swquality.jp/
• https://nagasaki-it-engineers.connpass.com/event/47962/
• https://nagasaki-it-engineers.connpass.com/event/53088/
• https://nagasaki-it-engineers.connpass.com/event/55801/
• http://nagasaki-it-engineers.connpass.com/event/32873/
• https://nagasaki-it-engineers.connpass.com/event/58974/
• https://nagasaki-it-engineers.connpass.com/event/63088/
• https://nagasaki-it-engineers.connpass.com/event/67603/
• https://nagasaki-it-engineers.connpass.com/event/74306/
• https://nagasaki-it-engineers.connpass.com/event/67240/
• https://nagasaki-it-engineers.connpass.com/event/87025/
• https://nagasaki-it-engineers.connpass.com/event/92789/
• https://nagasaki-it-engineers.connpass.com/event/93810/

はじめに

よりよいテストのために必要な技術・知識 ドメインの 専門技術・ 知識 テスト技術の 専門技術・知識 開発の 専門技術・ 知識 このあたりの話は、井芹さんや 実行委員の皆さんのセッションで得られます！ 支える・繋がる テストの基礎 本講演ではこのあたりの話をします 2018/11/22 © Akira Ikeda 8

本日のゴール （本日はテストの“キホンのキ”がテーマです） • テストには日々取り組んでいるけれど、改めてどういった活動でどういった 技術が必要なんだろう？ • 本セッションはテストに取り組み始めた方やテスト初級者向けに行います。 テストといいつつ単なる仕様チェックになりがちな状態を卒業したい、テス ト技術の全体像を掴みたい、テストの技術を高めるために勉強を始めたりス キルアップに取り組みたいと考えている方向けに、抑えておきたいキホンの キをお話しします。 – テストを行なう意義を振り返り、テストに必要な思考をおさらいします – 単なる仕様チェックから抜け出すための手段の１つとして、マインドマップを使っ たテスト分析・設計の基本を紹介します – テスト技術の全体像をイメージするために、構成要素を5つの軸から捉えます – そのうえでそれらの勉強やスキルアップを始めるためのモデルケースやヒントをお 伝えします。 • テスト技術力を高めていくためにはテストそのものについて自分なりのイ メージや地図を持つことが重要です。是非この機会にイメージを掴み、具体 的な行動を起こすヒントを得ましょう！ 2018/11/22 © Akira Ikeda 9

ここで問題です ｰ長崎の童歌 でんでらりゅうば でてくるばってん でんでられんけん でーてこんけん こんこられんけん こられられんけん こーんこん 2018/11/22 © Akira Ikeda 10

でんでらりゅうアプリに関する仕様 指定のURLにブラウザでアクセスするとテキストボックスがひとつ、判定ボタ ンがひとつ表示される でんでらりゅうの歌詞を入力し、判定ボタンを押すと、入力が間違っていない か判定される 判定結果が正しければ歌が流れる 判定結果が誤っていればＮＧと表示される • さぁどういうテストをしようか？ • 解法を探し、手を打たなければ。。。 • さっき同値分割/境界値分析は習いましたが。。。 2018/11/22 © Akira Ikeda 11

地図がないと闇雲になる 地図がないと、むやみに解法を探すことになり不効率 2018/11/22 © Akira Ikeda 12

道具を知らなければ、手を打てない 道具の種類と効果を把握しておかないと、適切な手を打てない 2018/11/22 © Akira Ikeda 13

本日のお話で意識してほしいこととご注意 意識してほしいこと • 自分の知っていることと知らないこと • 自社/現場の状況と比較し、何が同じで何が異なるのか • 自社/現場の現状況をよりよくするためにどのキーワードが使えそうか • 自社/現場の先々をよりよくするためにどのキーワードにアンテナをたてておけば よいか ご注意 • 個別の技術詳細については関連文献に委ねます（後で深掘り・調査できるようにポ インタを示します） • 「ソフトウェア品質」そのものについての議論は取り扱いません • 本資料に登場する会社名、製品名などは、一般に各社の登録商標または商標です 初級者は明日からの改善のために使えるキワードードやヒントを得て下さい 中級者以上の方は、自分の知識の棚卸しや整理としてお聞き下さい 2018/11/22 © Akira Ikeda 14

本日のアジェンダ 五つのキ 1. 【機】とらえ直そうテストの意義 2. 【規】テストに必要となる思考 1～3に 重点を 置いて 話します 3. 【紀】テストの分析設計～マインドマップを利用して～ 4. 【伎】テストの全体像をイメージするための5つの軸 5. 【企】始めてみよう テストのスキルアップ 6. おわりに 2018/11/22 © Akira Ikeda 15

機：物事がおこるきっかけ 1.【機】とらえ直そうテストの 意義

ソフトウェアテストってなんだろう？ ソフトウェアテストっ てなんだろう？ テストの経験は豊富な はず でも，説明するのは案 外難しい • ソフトウェアをテストする ことだと言うのは簡単だが • ソフトウェアを動かして みて，変な動きを確認す ること？ • 処理速度が速いかどうか 試すこと？ etc… • 今までの人生，散々テスト を受けてきたはず • 学校の定期テスト，大学 受験，車やバイクの免許， 入社試験 • つまり，皆さんはテストの プロ • 改めて考えてみると漠然と していませんか？ • だから，テストを行うこと の意義も理解しにくいし， 定義も理解できない • 意義とイメージがつかめれ ば，テストの重要性も理解 できる 2018/11/22 © Akira Ikeda 17

ソフトウェアテストを行う意義 ソフトウェアテストを行なう意義 「ソフトウェアテストを行うと，ソフトウェアが作られていく過程で入 り込んでしまう“バグ”を発見することができ，そのバグを開発者が修 正することによって，ソフトウェアを利用者が安心して利用することが できるようになる．」（Akira Ikeda, Mikio Suzuki, 2007） • バグ（不良）を発見することができる – テストをやらないと，多くのバグは発見できない – テストで発見したバグを開発者がデバッグすることで，品質が上がる • ソフトウェアを利用者が安心して利用することができる – 変な動きをしないからこそ毎日継続的に使い続けられる – テストは，実際に使う立場になって行うことが重要 – 自らお金を払って買ってもいいと思える製品を作るという意識 – テストは，お客様に安心感という価値を提供する 2018/11/22 © Akira Ikeda 18

バグが与える影響 とある場面 ～お客様の立場～ • ある日スマホを買ってきたら，次のような現象が出た – – – – – アンテナは3本立っているのに，メールが送信できない メールを表示したら文字化け アドレス帳に登録できない，何も操作しないのにデータが消える 目覚ましが設定どおりに鳴らない 操作中に無反応になったり，勝手に電源が切れる などなど・・・ • どう思うでしょうか？ – – – – あきれる，イライラする，腹が立つ 場合によってはクレーム電話 最悪，同じメーカのものは二度と買わないかもしれない さらに，同じメーカの全然別の製品も買わないかもしれない 2018/11/22 ソフトウェアにバグが残っている（混入している）と， 不快な気分になり，安心感もなくなり，不信感を持つ © Akira Ikeda 19

バグが与える影響 とある場面 ～メーカの立場～ • ゲームソフトの出荷後，フリーズなど致命的な問題が発見された – 回収・交換する場合，どういう対応が必要になるのか – ① ゲームソフトの回収 – ② バグの調査と分析 – ③ バグの修正 – ④ 修正されたバグについてのテスト – ⑤ 新しいバージョンの製品の生産 – ⑥ 新しいバージョンのお客様への送付 • 以下の例で考えてみる – – – – 出荷本数：10万本，回収費用：1本700円 ②～④にかかる人数：15人（時給2000円） ②～④にかかる時間：１ヵ月（8h×30d=240h） 生産費用：1本500円，送付費用：1本700円 2018/11/22 © Akira Ikeda 20

バグが与える影響 とある場面 ～メーカの立場～ – ① ゲームソフトの回収 – 10万本 × 送料700円 ＝ 7,000万円 – ② バグの調査と分析～ ④ 修正されたバグについてのテスト – 15人 × 時給2,000円 × 240時間 ＝ 720万円 – ⑤ 新しいバージョンの製品の生産 – 10万本 × 一本あたり500円 ＝ 5,000万円 – ⑥ 新しいバージョンのお客様への送付 – 10万本 × 送料700円 ＝ 7,000万円 – ①～⑥までの合計 – 7,000万円 + 720万円 + 5,000万円 + 7,000万円 ＝ 約２億円！ – このほか，損害賠償や，新聞/TV広告，電話窓口の設置などのコスト – コスト以外にも，不買運動や風評被害，最近なら批判Blogなどブランドに影響 たった一つのバグが数億円の損害を与えるほか ブランドに大きな影響を与えることもある！ 2018/11/22 © Akira Ikeda 21

（参考）「史上最悪のソフトウェアバグ」ワースト10 1962年7月22日――火星探査機『マリナー1号』： • マリナー1号は打ち上げ時に予定のコースを外れたが，これは飛行ソフトウェアのバグが原因だった。地上の管制センター は大西洋上でロケットを破壊した。事後調査により，鉛筆で紙に書かれた数式をコンピューターのコードに置き換えるとき にミスが起き，これが原因でコンピューターが飛行コースの計算を誤ったことが判明した。 1982年――旧ソ連のガス・パイプライン： • シベリアを横断するガス・パイプラインの管理に旧ソ連が購入したカナダ製のコンピューターシステムに，米中央情報局 (CIA)のスパイがバグを仕掛けたことがあるという。旧ソ連は当時，米国の機密技術を密かに購入しようと――または盗み出 そうと――しており，このシステムを入手したのもその一環だった。だが，計画を察知したCIAはこれを逆手にとり，旧ソ連 の検査は問題なく通過するが，いったん運転に入ると機能しなくなるように仕組んだとされる。この結果起きたパイプライ ン事故は，核爆発以外では地球の歴史でも最大規模の爆発だったという。 1985〜1987年――セラック25： • 複数の医療施設で放射線治療装置が誤作動し，過大な放射線を浴びた患者に死傷者が出た。セラック25は2種類の放射線―― 低エネルギーの電子ビーム(ベータ粒子)とX線――を照射できるよう，既存の設計に「改良」を加えた治療装置だった。セ ラック25では電子銃と患者の間に置かれた金属製のターゲットに高エネルギーの電子を打ち込み，X線を発生させていた。 セラック25のもう1つの「改良」点は，旧モデル『セラック20』の電気機械式の安全保護装置をソフトウェア制御に置き換 えたことだった。ソフトウェアの方が信頼性が高いとの考えに基づく判断だった。 • しかし，技術者たちも知らなかった事実があった――セラック20およびセラック25に使われたOSは，正式な訓練も受けてい ないプログラマーが1人で作成したもので，バグが非常にわかりにくい構成になっていたのだ。「競合状態」と呼ばれる判 明しにくいバグが原因で，操作コマンドを素早く打ち込んだ場合，セラック25ではX線用の金属製ターゲットをきちんと配 置しないまま高エネルギーの放射線を照射する設定が可能になっていた。これにより少なくとも5人が死亡し，他にも重傷 者が出た。 WIRED「「史上最悪のソフトウェアバグ」ワースト10を紹介」より引用 2018/11/22 © Akira Ikeda 22

（参考）「史上最悪のソフトウェアバグ」ワースト10 1988年――バークレー版UNIX(BSD)のフィンガーデーモンによるバッファー・オーバーフロー •最初のインターネットワームとなった通称『モーリス・ワーム』は，バッファー・オーバーフローを悪用し，1日足らずで2000台から6000台のコン ピューターに感染した。原因となったのは，標準入出力ライブラリー・ルーチン内の「gets()」という関数のコードだ。「gets()」関数はネットワー ク越しにテキストを1行取得するように設計された。しかし，残念ながら「gets()」関数は入力を制限するようには作られていない。そのため，あま りにも大きな入力があった場合には，接続可能なあらゆるマシンをワームが占拠する元凶になった。 •プログラマーは「gets()」関数を使用コードから排除することで問題に対処しているが，C言語の標準入出力ライブラリーからこれを削除することは 拒否しており，この関数は現在も存在している。 1988〜1996年――『ケルベロス』の乱数生成アルゴリズム •ケルベロスは暗号を使ったセキュリティーシステムだが，乱数発生器に与えるシード(種)が適切でなく，真にランダムな乱数が生成されていなかった。 その結果，ケルベロスによる認証を用いているコンピューターについて，非常に簡単な方法で侵入可能な状態が8年間にわたって続いた。このバグが 実際に悪用されたかどうかは，今も定かではない。 1990年1月15日―― 米AT&T社のネットワーク停止 •米AT&T社の長距離電話用交換機『4ESS』を制御する最新版のソフトウェアにバグが入りこんだ。このため，4ESSは隣接するマシンの1つから，ある 特定のメッセージを受け取るとクラッシュするようになってしまった――そしてそのメッセージとは，クラッシュした交換機が復帰した際に，隣接す る交換機に送信するものだった。 •ある日，ニューヨークの交換機がクラッシュし再起動した。するとそれが原因で隣接する複数の交換機がクラッシュし，これらの交換機が再起動す ると隣接する複数の交換機がさらにクラッシュし，この現象が延々と続いた。しばらくすると，114台の交換機が6秒ごとにクラッシュと再起動を繰 り返すようになった。この影響でおよそ6万人の人々が9時間にわたって長距離通話サービスを利用できなくなった。修復のため，技術者たちは1つ前 のソフトウェアをロードした。 1993年――インテル社製『Pentium』(ペンティアム)による浮動小数点数の除算ミス •米インテル社が大々的に売り出したPentiumチップが，特定の浮動小数点数の除算で誤りを引き起こした。たとえば，4195835.0／3145727.0を計算 させると，正しい答えの1.33382ではなく1.33374となる。0.006％の違いだ。 •実際にこの問題の影響を受けるユーザーはごくわずかだったが，ユーザーへの対応から，同社にとって悪夢のような事態につながった。概算で300万 〜500万個の欠陥チップが流通していた状況で，インテル社は当初，高精度のチップが必要だと証明できる顧客のみをPentiumチップの交換対象とし た。しかし，最終的にインテル社は態度を改め，不満を訴えるすべてのユーザーのチップ交換に応じた。この欠陥は結局，インテル社に約4億7500万 ドルの損害を与えた。 2018/11/22 WIRED「「史上最悪のソフトウェアバグ」ワースト10を紹介」より引用 © Akira Ikeda 23

（参考）「史上最悪のソフトウェアバグ」ワースト10 1995年／1996年――『Ping of Death』 •[ピング・オブ・デス，不正なピングパケットによる攻撃]分割送信されたIPパケットの再構成を行なうコードのチェックとエラー処理が不十分だった ため，インターネット上の好きな場所から不正な形式のピングパケットを飛ばすことで，さまざまなオペレーティング・システム(OS)をクラッシュ させることができた。影響が最も顕著に現れたのはウィンドウズ搭載マシンで，この種のパケットを受け取ると，「死のブルー・スクリーン」と呼ば れる青い画面を表示して動作が停止してしまう。しかしこのバグを利用した攻撃は，ウィンドウズのみならず，マッキントッシュやUNIXを使ったシ ステムにも多くの被害をもたらした。 1996年6月4日――『アリアン5』フライト501 •欧州宇宙機関の開発したロケット，アリアン5には，『アリアン4』で使われていたコードが再利用されていた。しかし，アリアン5ではより強力なロ ケットエンジンを採用したことが引き金となり，ロケットに搭載された飛行コンピューター内の計算ルーチンにあったバグが問題を起こした。エラー は64ビットの浮動小数点数を16ビットの符号付き整数に変換するコードの中で起こった。アリアン5では加速度が大きいため，64ビット浮動小数点で 表現される数がアリアン4のときよりも大きくなってオーバーフローが起こり，最終的には飛行コンピューターがクラッシュしてしまった。 •フライト501では，最初にバックアップ・コンピューターがクラッシュし，それから0.05秒後にメイン・コンピューターがクラッシュした。その結果， エンジンの出力が過剰になり，ロケットは打ち上げ40秒後に空中分解してしまった。 2000年11月――パナマ国立ガン研究所 •米マルチデータ・システムズ・インターナショナル社(本社ミズーリ州)が製作した治療計画作成用ソフトウェアを使っていたパナマの国立ガン研究所 で，放射線治療で照射する放射線量の計算を誤る一連の事故が起きた。 •マルチデータ社のソフトウェアでは，健康な組織を放射線から守るための「ブロック」と呼ばれる金属製のシールドの配置を，コンピューターの画 面上に描いて決めるようになっていた。しかし，同社のソフトウェアではシールドが4個しか使えなかったにもかかわらず，パナマ人の技師たちはこ れを5個使いたいと考えた。 •技師たちは，真ん中に穴を持つ1個の大きなシールドとして，5個のシールドをまとめて表示させれば，ソフトウェアをだますことができることを発 見した。だが，そうした配置にした場合，穴の描き方によってこのソフトウェアが返す計算結果が違ってくることにはまったく気づいていなかった。 ある方向に向けて描くと正しい照射量が計算されるが，違う方向に描くと必要な照射量の最大2倍の量を推奨してきたのだ。 •少なくとも8人の患者が死亡し，さらに20人が過剰照射によって深刻な健康被害を受けたとみられている。技師たちは，コンピュータによる計算結果 を手作業で再チェックする法的義務を負っていたため，殺人罪で起訴されることになった。 WIRED「「史上最悪のソフトウェアバグ」ワースト10を紹介」より引用 2018/11/22 © Akira Ikeda 24

ソフトウェアテストを行う意義 • ソフトウェア製品に – バグが残っている（混入している）と，不快な気分になり，安心感もなくなり，不信感を持つ – 混入したたった一つのバグが数億円の損害を与えるほか，ブランドに大きな影響を与えること もある ソフトウェアテストを行なう意義 「ソフトウェアテストを行うと，ソフトウェアが作られていく過程で入 り込んでしまう“バグ”を発見することができ，そのバグを開発者が修 正することによって，ソフトウェアを利用者が安心して利用することが できるようになる．」（Akira Ikeda, Mikio Suzuki, 2007） はて？ なんだか意義が足りないような･･･？ 2018/11/22 © Akira Ikeda 25

ソフトウェアテストを行う意義 テストはお客様，企業双方にメリットがある！ ソフトウェアテストを行なう意義 「 ソフトウェアテストを行うと，ソフトウェアが作られていく過程で入り込んでしまう “バグ”を発見することができ，そのバグを開発者が修正することによって，ソフト ウェアを利用者が安心して利用することができるようになる。 また，出荷後にバグが出ないことでソフトウェアの回収と修正に必要なコストを削減 し，企業のイメージ低下，ひいては倒産を防ぐことができる。」 （ Akira Ikeda, Mikio Suzuki, 2007 ） 」（Akira Ikeda, Mikio Suzuki, 2007） • たった一個のバグが，お客様に不利益を与えるどころか，企業の業績を左右することもある • 場合によっては企業の倒産により職を失ったり，企業や社会に損害を与えたことで，個人に損害賠 償責任が発生することも ソフトウェアテストにしっかりと取り組むということは， バグというモンスターから 実際のお客様のみならず，企業や社会， そして自分や家族を守ることでもある 2018/11/22 © Akira Ikeda 26

（参考）テストとは？（ISTQB-FL） • テストとは何か？ – テストとは何か，に対する一般的な認識は，テストを実施すること，すなわち，ソフトウェアの実行 であることが多い。ソフトウェアの実行はテストの活動の一部であり，全部ではない。 – テストの活動は，テスト実施の前後にも存在する。例えば，計画，コントロール，テスト条件の選択， テストケースの設計と実行，実行結果のチェック，テスト完了基準の検証，テストプロセスやテスト 対象システムに関する報告，テストのまとめや終了作業(テストフェーズが完了した後)がある。テス トにはドキュメント(ソースコードを含む)レビューや，静的解析を実施することも含む。 – 動的テストと静的テストは，方法は違っても同じような目的のために使え，テスト対象のシステムだ けではなく，開発やテストのプロセス改善のための情報提供もできる。 • テストの目的 – 欠陥を摘出する。 – 対象ソフトウェアの品質レベルが十分であることを確認する。 – 意志決定のための情報を示す。 – 欠陥の作りこみを防ぐ。 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02 から引用 2018/11/22 © Akira Ikeda 27

【演習】調べてみようソフトウェアテストの定義 〇〇〇氏の定義 IEEE・ISO・JIS等の規格での定義 職場やプロジェクトでの定義 2018/11/22 © Akira Ikeda 28

規：行動や判断のよりどころとなる基準。 2.【規】テストに必要となる 思考

ソフトウェア開発で必要となる基本的な思考 設計のための思考 テストのための思考 ※ご注意 様々な考え方があると思いますが、 本講演ではわかりやすさを重視して、このように単純化してお話しします 2018/11/22 © Akira Ikeda 30

設計とは問題領域を狭めていく行為 人間の世界 計算機の世界 問 題 領 域 の 特 定 ・ 具 体 化 要望や要求 計 算 （機 機世 能界 化へ ）の 転 写 要件 仕様 問題領域を狭めていく 2018/11/22 © Akira Ikeda 31

設計時の思考 設計では要件を，計算機世界上で「こう動くべき」「こう動かないべ き」に分類・具体化・定義することで問題領域を狭めていく（計算機の 振る舞いを定義する→仕様化） め計 て算 い機 くと し て 扱 う 問 題 領 域 を 狭 2018/11/22 に「 「 定ここ 義うう し動動 てかく いなべ くいき こ べ」 とき で」 ， 仕様外 こう動かないべき （異常系仕様） こう動くべき （正常系仕様） © Akira Ikeda 32

テスト時の思考 テストは仕様化された事柄について「その通りに動くか」を確認するだ けでは不十分で，「それ以外で何も起きないのか」も確認せねばならな い。 こう動かないべき （異常系仕様） こう動くべき （正常系仕様） 仕様を確認するだけでは 単なる動作チェック 2018/11/22 問「 題そ 領れ 域以 を外 広で げ何 ても 探起 索き しな てい いか く」 に「 加仕 え様 ，が そ の 通 り に 動 く か 」 それ以外（仕様外） こう動かないべき （異常系仕様） こう動くべき （正常系仕様） テストではむしろ 「仕様外」を扱うことが重要 © Akira Ikeda 33

テストすべきことの発想（認知） • チェックすべき対象は「仕様として書かれていること」，テストすべき対象 は「仕様外」と捉えるとわかりやすくなる • 仕様書に書かれていない「仕様外」をどれだけ発想・認知できるかが勝負 仕様外 こう動かないべき （異常系仕様） こう動くべき （正常系仕様） 仕様書に書かれていることから チェックすべきこと発想すれば良い（容易） 2018/11/22 仕様書に書かれていないため， 思いつかなければならない 仕様領域に近いところは 比較的仕様書から発想しやすい 仕様から遠いところは 仕様書によらない発想も必要 「 と行 い間 うを こ読 とむ 」 この仕様外に対応していくための1つの手段と して「テスト分析」と「テスト設計」があり， テストすべき事柄を発想して整理する手法と して「テスト分析設計手法」がある © Akira Ikeda 34

テストにおける思考のまとめ • テストを考えるとき，設計時とは違う思考パターンであることを理解 しておく（逆方向の思考である） – 設計は問題領域を狭めていく思考 – テストは問題領域を広げていく思考 – テストは仕様化された事柄について，「仕様化されたものがその通りに動くか」と 「それ以外で何も起きないのか」と問題領域を広げていく – 仕様を確認するのはチェック，仕様外を確認するのをテストと考えると良い • これらの一連の行為として「テスト分析」と「テスト設計」があり， テストすべき事柄を発想して整理する手段として「テスト分析設計手 法」がある テストに取り組む場合，思考を切り換える必要がある いわゆる「帽子のかぶり直し」である 2018/11/22 © Akira Ikeda 35

【演習】抑えてみようテストの思考 【仕様】 こう動くべき こう動かないべき それ以外 2018/11/22 © Akira Ikeda 36

紀：筋道や順序を追って整理・記録する 3.【紀】テストの分析設計 ～マインドマップを利用して～

皆さんどのようにテストケースを作っていますか？ 仕様書等 テストケース 単なる転記 初級者 (仕様例) ボタンを押すと音が出る (テストケース例) ボタンを押すと音が出ることを確認 初級者の悩み ・テストケースのヌケが多い！ 語尾を付け足して ・異常系のテストケースが抜ける！ 完成させる，単なる ・機能を組み合せを考慮したテストケースがかけない！ チェック止まり！ ・テスト技法の使いどころがわからない！ ・組織で積み上げられたノウハウが活用できない！ ・自分の経験が再利用できない！ などなど…… 2018/11/22 © Akira Ikeda 38

皆さんどのようにテストケースを作っていますか？ 仕様書等 どんな音？ 押し方は？ テストケース タイミング は？ 類似ソフト は？ ユーザは？ 昔どうしたん だっけ？ いろいろ発想する 上級者 テストケースを書く前に，思考を発散させながら，かつＭＥＣＥを意識し て考える．なので，初級者に比較してテストケースの抜けが少なくなる！ また，弱点をつくようなテストケースが作成できる！ 上級者はテスト観点を発想/検討したうえで戦略的にテストケースを作成する ・テストを行うにあたって，テスト観点をしっかりと考える 「機能」「プラットホーム」「エンドユーザ」「ドメイン特性」「組織のノウハウ」など ・テスト観点の階層や関連，組み合わせを考える ・不適切な仕様（仕様バグ）は摘出 → 設計部門に確認・修正依頼 ・テスト観点全体の構成を俯瞰して，重み付けや実行順番など考える 仕様書に書かれてい などなど…… ないことも発想する 2018/11/22 © Akira Ikeda 39

実に多くを考えることが必要であるが… 考えるっていっても 頭の中だけじゃ 大 変 だよな とりあえず， テストケース表を使って 考えようかな？ どうせ最終的には エクセルの表になる わけだし ただ、テストケースの表現形式を使ってテスト設計を行うのは難しい 2018/11/22 © Akira Ikeda 40

では，どういった記法(ツール)を使うとよいのだろうか？ 表で観点を出す， つまりブレストは 難しいな～ 試行錯誤できる 記法がいいな できれば構造化 しやすいものが いいかも 整理するためには 全体を俯瞰 できなくちゃ でも，発想力を刺激し てくれるものでないと， 観点が抜けちゃう！ じゃぁ，そのような特徴をもつ 発想支援ツール，マインドマップを 使ってみたら？ 2018/11/22 © Akira Ikeda 41

マインドマップの利用イメージ（コンセプト） 仕様書 テストケース 初級者 マインドマップを描く マインドマップを書くことで， ・単純な仕様の転記がなくなる ・仕様書に書かれていないことにも思考が誘導される ・「考える」行為を明確に実行できる 2018/11/22 © Akira Ikeda 42

つまり，「テストの思考」を実践するための道具としてマイ ンドマップを活用する テストケースの品質に大きな影響を与え， かつ，仕様外への発散思考が特に重要な ・テスト分析 ・テスト設計 にマインドマップを使ってみよう ・マインドマップの概要 ・マインドマップの適用を見据えた テスト分析＆テスト設計の作業と勘所 ・マインドマップを使った作業手順 を説明します 単なる仕様チェックから卒業するための 手段の1つとして持ち帰って下さい 2018/11/22 © Akira Ikeda 43

2018/11/22 © Akira Ikeda 44

マインドマップとは？ • トニー・ブザンにより考え出された図解技法 – 脳の仕組みを取り入れたもの – 思考に沿って描いていく – 図を取り入れる – 自分の深層意識にアクセスする Wikipediaによる解説 表現したい概念の中心となるキーワードやイメージを図の中央に置き，そこから放射状にキー ワードやイメージを繋げていくことで，発想を延ばしていく図解表現技法。 この方法によって複雑な概念もコンパクトに表現でき，非常に早く理解できるとされ，注目さ れ始めている。 人間の脳の意味ネットワークと呼ばれる意味記憶の構造によく適合しているので，理解や記憶 がしやすい。 また本来は紙とペンで描くものだが，コンピュータ上で描くための専用ソフトウェアもいくつか 存在する。 2018/11/22 © Akira Ikeda 45

マインドマップの特徴の一例 バードビュー MECE 学習が容易 半構造 発想力が刺激される 思考の流れの見える化 •全体を俯瞰し易い •項目それぞれが重複することなく，全体集合として漏れがない •基本的なルールは単純で，紙とペンがあれば始められる •フリーなルールであるために，柔軟に構造を変更可能 •描いているうちに他の項目との関連などから新たな発想が生まれやすい •深層意識へのアクセスし，情報を引き出す •中心から外に対して思考が放射的に広がる これらの特徴を上手く生かそう♪ 2018/11/22 © Akira Ikeda 46

済 2018/11/22 © Akira Ikeda 47

「テスト分析」と「テスト設計」 テストケースの作成 テストの実行 作業/概念で分ける テスト分析 仕様等の理解・整 理・検討・テスト 観点の目付け テスト設計 テスト観点の発 想・検討・整理， テスト技法の適 用 ここにマインドマッ プを使うぞ！ 2018/11/22 テスト実装 詳細テストケー ス・スクリプト等 の作成（適切な フォーマットに表 現） テスト実行 テスト実装に より作成され たテストケー スを実行し， ログを取る テスト報告 テストの結果や ログを整理し、 当該テストレベ ルでのテスト活 動を評価する ※注意 本講演ではテスト観点の発想はテ スト設計で行ないますが、 他の手法ではテスト分析で行なう 場合もあります。 © Akira Ikeda 48

開発作業とテスト作業のおおまかな対比イメージ ソフトウェア開発 要求分析 顧客要求を分析し，ソフトウェアとし て実現可能か検討する 設計 分析結果に基づいて，設計モデルの作 成や仕様の決定を行う 実装 モデルや仕様に基づいて，プログラム 言語を使ってプログラムコードとして 実装する プログラム 2018/11/22 テスト開発 設 計 仕