テスト設計コンテスト'20 OPENクラス チュートリアル 参加レポ

【OPENクラス】テスト設計コンテスト'20 チュートリアル イベント概要

開催場所：freee株式会社
開催日時：2019年12月2日（月）19:00～
講師：西 康晴さん
参加費：無料
Compass
ASTERのHP
U-30チュートリアルの参加レポ
当日のスライド

• ※ページ番号がずれているかもしれません。ご容赦ください。

チュートリアル メモ

全体像

1．テスト開発プロセスとは
より精度の高いテストの実現にはプロセスが必要です。ここでは、テストプロセスの必要性と各工程の内容を説明します。

2．TRA（テスト要求分析）
テスト対象物を多くの観点から理解することが精度の高いテストを実現します。
ここでは、分析観点の導出や分析結果のアーキテクチャへのつなげ方などを過去の成果物を例にして説明します。

3．TAD（テストアーキテクチャ設計）
テストアーキテクチャが適切に設計されることで、テストの高精度化や資産化が可能になります。ここでは、過去のテストアーキテクチャの成果物を例にして説明します。

4．TDD・TI（テスト詳細設計、テスト実装）
分析、設計を経たテスト情報を実行可能にするために詳細設計ならびに実装方法を説明します。

5．テスト開発のTIPS
講師らの過去の経験も踏まえ、テスト開発プロセスを現場に適用する際のポイントを紹介します。

6．2017決勝のテストアーキテクチャの実例概説
過去のテスト設計コンテストの決勝に残ったテストアーキテクチャを例に、実践に役立つテスト設計について具体的に解説します。

OPENクラスのチュートリアルでは、U-30クラス チュートリアルの内容は既知として説明を開始する予定です。
予めU-30クラス チュートリアルの資料も確認してきてください。

※上記はASTERのページから引用しました。

---

0．はじめに

• オープン版のテスト設計コンテストのコンセプト
  • 全部理解されると困るから、次から次に振り落としていくスタイル

1．テスト開発プロセスとは

より精度の高いテストの実現にはプロセスが必要です。ここでは、テストプロセスの必要性と各工程の内容を説明します。

p3 テスト開発プロセスが必要である

• テストレベルやテストタイプが10も20もあるテストにはテスト戦略を立てることが必要だが、それができているものが少ない。
• 日本にはテストマネージャーがいる
  • マネジメントと戦略立案の2つを担っている。これは問題。
    • これは基本的には別のロール、スキルセット
• アジャイルなどの機敏化

p4 テスト設計からテスト開発にコード化する

• テスト設計からテスト開発にコード化する
• コーディングとソフトウェア開発は違う
• テストの勉強だけすればテストのことができるようになるのではない。ソフトウェア開発に必要となる思考力やモデリング力を身につける。
  • 「いかに良いテストをするために、きちんと考えるか」だけを紹介。

p5 ソフトウェア開発プロセスとソフトウェアテスト開発プロセスを対応させる

• ソフトウェア開発プロセスとソフトウェアテスト開発プロセスを対応させる
  • 種類や抽象度を表している。
  • この手順通りに行くのか、手戻りはあるのかは会社やプロジェクト次第。
  • テストケースがどのような抽象度で記述されるかは無秩序。
    • 抽象度をコントロールしてマネジメントすること

p6 プロセスの細分化をする理由

• プロセスの細分化をする理由
  • 4つの工程は、使う頭が違う
    • テスト要求分析：何をテストすべきか
      • どのような使われ方がありうるのか
      • どのようなユーザーが使うのか
    • テストアーキテクチャ設計：どのような区分けをすべきか。全体像の把握。
      • どのようなテストタイプがあるか
        • 似ているものの共通点や相違点
    • テスト詳細設計：具体的にテストケースを上げていく。網羅＆ピンポイント。
    • テスト実装：テスト実施環境に関する知識が必要になる
    • テスト実施：
  • 色々なことを一気に考えることはできない。分けることで、どこを自動化できるかがわかる
  • 一色に考えていると、どこを自動化すべきかがわからない。

p7 テスト観点とテストケースとテストスクリプト

• テスト観点とテストケースとテストスクリプトをきちんと区別する
• テスト観点：テストケースの意図を抽象的に書いたもの
• 区別せずに全部まとめて考えようとすると、「そんなことやってないでさっさとテスト手順かけよ」と言われる。
  • そこから守るためにも、しっかり工程を分けることが大切。

p8 モデリング

• モデリング
  • 絵とか図でわかりやすくする

p9＆10 テスト観点の具体例

• テスト観点の具体例
• テスト観点はテストケースの「意図」を表している
• 目的のわからないテストケースを実行するのは時間の無駄です
  • 必ずテストケースは意図を持っていないといけない。

2．TRA（テスト要求分析）

テスト対象物を多くの観点から理解することが精度の高いテストを実現します。
ここでは、分析観点の導出や分析結果のアーキテクチャへのつなげ方などを過去の成果物を例にして説明します。

p12 準備、分割、構築と納得

• 開発の上流でサービスを作るために使ったものは、テストでも要求の源泉になる。
• テスト要求の源泉の準備
• テスト要求の獲得と分割
• テスト要求モデルの構築と納得

p13 テスト要求の源泉の準備

• テスト要求の源泉の準備
  • 入手できるなら入手
  • 自分たちがユーザーの代わりになって考える
  • 現状、デグレどの程度出てる？
• 開発が完璧なら、テストはおおむねいらない
  • だからテストが必要
  • ジレンマに立ち向かうのが、我々テストエンジニアの勇気
• バグが流出した際に、原因を特定する必要がある。実際にテスト要求分析をする時間がなかったとしても、「観点が抜けたからなんだ」「観点はあったが、ケースが抜けた」「ケースがありすぎて抜粋をミスった」「環境を使いこなせずに出ているバグを見逃したのか」が分析できる。

p14 テスト要求の獲得と分割

• テスト要求の獲得と分割
  • どんなユースケースがあるか
  • どんなバグがありそうか

p15 テスト要求モデルの構築と納得

• テスト要求モデルの構築と納得
  • テスト要求モデル：テスト観点のモデル
  • 本チュートリアルでは階層構造で説明するが、これは好みの問題
  • 絵を描くと、複数のエンジニアがそれを見て「あーでもないこーでもない」と話せる
    • みんなでそれを囲める
  • 目的：自分たちのテストチームのステークホルダーに納得してもらう
    
  • テスト要求モデルは、「正解もゴールも定義出来ない」
    • どこがゴールかというのは「これでもう全部かな！！」と納得できるところ。
    • そこにいかに明確な基準をつけられるか。

p16 テスト観点を挙げる時の注意点

• テスト観点を挙げる時の注意点
  • 仕様書を書いてあることを書き写しても、テスト観点は網羅できない
    • 「それっぽいもので考えたふり」は、テスト設計コンテストでは予選落ち決定。
    • こうやれば上手くいく！ではなく、このように考えていくことで上手くいくかもしれない
  • テスト観点は多面的に
    • 開発「あ！その観点抜けてた！」テスト実施せずともバグが見つかる
  • テスト観点をあげただけでバグが見るかることがある
  • 網羅した風のテスト観点の文書や納品物を作ろうとせず、網羅しようと多面的に様々なことを考え尽くそうとする
    • ワイワイ議論して、考え尽くす
    • 最初から完璧を目指さない。今の自分たちのものをモデル化して、「あ〜私たちまだまだだね〜」としみじみやるのが大切
    • テストは、みなさんの組織の技術的限界までにしか保証できない。
      • 「これ以上ないわ〜」の部分が限界
      • バグが出たら、「何が足りなかったのか」振り返る
        • その振り返りで限界を超えていく

p17&18 テスト観点モデリングの2つのアプローチ

• テスト観点モデリングの2つのアプローチ
  • トップダウンとボトムアップ

p19 テスト要求モデルの全体像をどう整理すればいいか、に唯一絶対の解はない

• テスト要求モデルの全体像をどう整理すればいいか、に唯一絶対の解はない
  
  • モデルを鵜呑みにせずに、色々試してみて自分に合ったものを使えばいい
• 全体像の構造によってモデリングの質がかなり左右される
  • 第一レベルがダメだと、他もダメ

p20 テスト観点モデルのリファイン

• テスト観点モデルのリファイン
  • 質の高いモデルにするためにリファイン
    • 同じ単語だが、各々が考える意味が違うときがある。そこを揃える
    • 組み合わせテストがないと不安症候群
      • その組み合わせは本当に必要なんですか
      • 我々はプロダクトの品質のためにテストをしている。テストをするためにテストをしているのではない。

3．TAD（テストアーキテクチャ設計）

テストアーキテクチャが適切に設計されることで、テストの高精度化や資産化が可能になります。ここでは、過去のテストアーキテクチャの成果物を例にして説明します。

p22 テストアーキテクチャ設計(TAD)

• テストアーキテクチャ設計(TAD)
  • 「テストスイート：テストケースが集まったもの」の全体像を把握しやすくしつつ、後工程や派生製品、後継プロジェクトが作業しやすくなるように テスト観点をグルーピングしてテスト要求モデルを整理する工程
    • テストコンテナモデリング
      • テストタイプ、テストサイクルなど同じようなテストをまとめている
        • 機能テストと機能性テストの違い？
        • トマト銀行
        • 何が同じで何が違うか
    • テストフレームモデリング
      • 「エクセルの列見出しです」
      • モデルベーステスト
      • みなさんが現場で一生懸命考えていることに名前をつけてあげたのが、このチュートリアル。言語化すると考えやすくなる。

p23 大規模なテスト設計では、複数のテスト観点をグルーピングして扱いたい時がある

• 大規模なテスト設計では、複数のテスト観点をグルーピングして扱いたい時がある
  • 絵を描く
    • ああでもないこうでもない
    • 他人の脳みそを使えば、脳みその数は倍になる！
    • 安心と堕落は違う
    • 納得感の交換
    • 我々はナメられてる。絵を描かないからだ。
    • みなさんは、エンジニアです。エンジニアはすべからく図を描くものです。

p25 テストコンテナモデリング

• テストコンテナモデリング
  • 観点を分けておけば重ならない
  • テスト要求分析のサブツリーをそのままコンテナにしてしまえばいい
    • 戻ることを躊躇しないほうがいいです

p26 まとめかたの基本

• まとめかたの基本
  • 同じ時期
  • 同じ趣旨
  • 繰り返し
  • テストコンテナ間の関係がなるべく疎になるようにまとめる
    • 例：ファジング
      • コンテナの切り方が下手だと、あるテストケースの実施結果が別のテストケースの実施結果に影響してしまう。なるべく依存関係を切って、シンプルに保つ。

p27−29 自分なりのテストコンテナを考えてもよい

• 自分なりのテストコンテナを考えてもよい
  • Addiction validation：ゲームホリック的な
• SoEやSoRのテストコンテナが混在することもある
• テストコンテナの粒度も自分なりでよい

p30 テストアーキテクチャ設計における責務の分担

• テストアーキテクチャ設計における責務の分担
  • 分担の仕方に正解はない
  • そのように分担させた妥当な理由が説明できることが大切

p31&32 テストコンテナの責務:テスト設計意図

• テストコンテナの責務:テスト設計意図
  • テストには様々な設計意図があり、しばしば混在するため、 (サブ)コンテナとして同じ設計意図に揃えた方がよい
    • 意図を明確にする
  • テストコンテナの設計意図とテストケースの意図は連動するべきである
    • 食い違っている場合は、同じ観点でも、意図が変わってきてしまうかもしれない
• テストコンテナの責務:設計種別類似性
  • 設計種別類似性は、設計者の頭の使い方の類似性である
  • Design direction(設計方向性)2種類の頭の使い方
    • 順設計:Forward design
      • 条件まずあげる
    • 逆設計:Backward design
      • これさせたい
      • スキル低い人にさせようとすると危険
  • Design positiveness(設計肯定性)
    • Positive test design:肯定的テスト設計
    • Negative test design:否定的テスト設計
      • 「バグがないこと」は、「Positive test designで、表現がネガティヴなだけ」
      • 今すぐにわかろうとしなくていいです。しまっておいてください。

p33 テストピラミッドやSPLITというアプローチもある

• テストピラミッドやSPLITというアプローチもある
  • テスコン、ピラミッド、SPLITの話をしている
    • 提案している人の数よりも英単語の数の方が少ない
      • 「type」という用語
      • 使っている人が違えば、その単語が意味するところが全然違う
        • 「違い」を意識する
        • 「シナリオテスト」が示しているものの具体例を聞く
        • コンテナなどを使ってモデリングしてあげる

p34 重視する品質特性が違えば、アーキテクチャ設計が変わる

• テストスイートに求められる品質特性によって 異なるテストアーキテクチャの例
  • 重視する品質特性が違えば、アーキテクチャ設計が変わる
  • 何を重視するかによって結果が変わる

p35&36 探索的テスト

• 探索的テスト
  • エキスパートによる非記述的なテスト
    • 創造性を発揮
    • 素人に触らせるモンキーテストとは違う
    • ラーニングと探索は違うインテンション
  • チャーターとセッションでマネジメントを行う
  • テストアーキテクチャ設計時に考慮しておく必要がある
  • ポイント
    • 探索的テストで何に着目するかはエキスパートに依存する
    • 探索的テストは万能ではない
      • 学習したか
      • 野生に還ったかルソー？
      • おしゃべりするといい

p37&38 アジャイル開発におけるテストアーキテクチャ

• アジャイル開発におけるテストアーキテクチャ
  
• アジャイル開発でもTDLC(テスト開発ライフサイクル)や テストアーキテクチャに関する技術が必要になる
  • アジャイルは、必要なドキュメントをちゃんと書く
  • チケットの中身をなぞるだけがQAの仕事ではない
  • 「開発の最初から関わる」
  • 悪さの知識：「どういう風に操作ミスをするか」
• ユーザの価値にフォーカスする：開発の要求を一緒に考える
• 変化・成長しやすいダイナミックなテストであることをキープする
  • テスト側の技術的負債を増やさない
• チーム全員でテスト(QA)を行う
• チーム全員で考えてチーム全員で賢くなっていく

p39&40 イテレーション型テストアーキテクチャの設計

• イテレーション型テストアーキテクチャの設計
  • 意思決定
  • イテレーションコンテナの設計
    • 前のイテレーションテストをすることはなるべく避けたい
  • 非イテレーション

p40 フルスタックQAエンジニアを目指そう！

• フルスタックQAエンジニアを目指そう！

41〜46飛ばし

p47 テストフレームモデリング

• 複雑になってしまうのは、手動でテスト手順書を作ってしまってからリバースしてしまっているから。

4．TDD・TI（テスト詳細設計、テスト実装）

分析、設計を経たテスト情報を実行可能にするために詳細設計ならびに実装方法を説明します。

p57 テスト実装

• テスト実装

5．テスト開発のTIPS

講師らの過去の経験も踏まえ、テスト開発プロセスを現場に適用する際のポイントを紹介します。

p59

• 「実感できないならやらない方がいいんじゃないですかね！！」 ### p60
• テストのリバースエンジニアリングおすすめ

6．2017決勝のテストアーキテクチャの実例概説 p68

過去のテスト設計コンテストの決勝に残ったテストアーキテクチャを例に、実践に役立つテスト設計について具体的に解説します。

根拠

• なぜこれをしたの？

多面的な関係との根拠

スコープとその根拠

これで本当に俯瞰しやすい？

• これ使えばいんじゃね！？はNG
• 意味を熟考し、言語化して論理的に順序立てて説明してほしい
• 常に全体像を俯瞰して捉えてほしい
• みなさんの直感を信じてください。それを言語化してください。言語化できない部分を大切にしてください。
• コンテストに参加することで、みなさんの業務での熟考度や俯瞰度を反映します。
• テストのことだけではなく ソフトウェア開発に必要となる 思考力やモデリング力を身につけよう

Q&A

※TDDの質疑だけ

Q P38「コンテキストによっては、TDDでのテストを品質の保証の役割に使わない方がよい」とあるが、使う方が良い場合とそうでない場合をどう区別すれば良いか？
A きちんと要求を細分化して、各要求に対するテストコードが書けている場合は品質保証の役割に使って良い。逆に、スキルの低いプログラマーが、要求とは無関係に実装を小分けにした場合のテストコードは品質保証の役割に使うべきではない。なお前者の場合、適切に要求が細分化されているのであれば、最終的なパスカバレッジは100％になるはずである。

• このQ&Aは自力でメモが残せていませんでした。
  • カルバートさんありがとうございます！

感想

• 太字にしたことを明日からの業務に活かす！
  • ふりかえりをして自分たちの限界を超えるというのはなんかいいなと思った。
  • 絵を描く！！！！
• 色々なことに対して、「なんとなく」をやめようと思った。
• 使っている人が違えば、その単語が意味するところが全然違う、というのがいちばんの収穫だった。
• 探索的テストをするときは野生に還ろう。