Go to Qiita Advent Calendar 2024 Top
LoginSignup
11
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

エムスリーキャリアAdvent Calendar 2019

Day 2
@akrwtnkinエムスリーキャリア株式会社

「テスト設計コンテスト'20 U-30クラス チュートリアル」が面白かった話

Last updated at Posted at 2019-12-01

①はじめに

  • アドベントカレンダー2日目。書きます！
  • 「テスト設計コンテスト'20 U-30クラス チュートリアル」が面白かった！という話です。
  • イベント詳細や参加時のメモだけを読みたい場合は、「④テスト設計コンテスト'20 U-30クラス チュートリアル」をご覧ください。
この記事を書いた私のレベル感(折りたたみました！)
  • この記事を書いた私のレベル感 　
    • QAになって3ヶ月目を迎えました。
    • 3ヶ月よりも前までは、C#でWindowsフォームアプリを主とする開発をしていました。
      • 業務の中で自分で基本設計をした機能についての開発、単体テストケース作成、単体テスト実施、結合テスト実施はおこなったものの、結合テストやシナリオテストのテストケース作成の経験はありません。
      • 当時はテストについて**「ワタシ！ テスト！ ツクル！ ジッシスル！」**という枠組みでしか捉えておらず、そのことに課題意識があり2019年8月のJSTQB FLに挑戦しました。
      • また、TDDを知ってNUnitを使ったユニットテストの導入を試みたものの、具体的にどこを自動化すれば効率がいいのか皆目見当がつかず、当時は挫折してしまいました。
      • プロジェクトで色々な難しさに直面する中で、どうすれば手戻りが減りかつ品質の良いプロダクトが作れるのだろう、そもそも「品質が良い」とはどういうことだろう、と考えていたときにQAという職種やアジャイル開発などを知り、QAとして転職をしました。
    • テスト技法やテスト設計の流れについてはJSTQB FLである程度「知った」ものの、「知る」と「分かる」、「分かる」と「できる」の間にはまだ段差があるなと感じています。

②そもそも「テスト設計コンテスト」　#とは

  • 主催は、NPO法人 ソフトウェアテスト技術振興協会（ASTER:Association of Software Test EngineeRing）
  • 「テスト設計成果物の良さ」を競うコンテスト。
    • バグ出しコンテストではない。
  • 「今年のテストベース(お題)はこちら！」というのが発表されて、そのテストベースに沿ったテスト設計成果物を作成する。
    • テストベース発表から提出期限までは数ヶ月あり、地方予選と決勝があり、１日で完結するタイプのイベントではない。
      • 大人版の「高校生クイズ」感がある気がする。
      • 甲子園感もある気がする。
  • U-30クラスとOPENクラスがある。
    • U-30クラス：30歳以下が参加できる。2017年から始まった。
    • OPENクラス：年齢制限なし。
  • 予選と決勝がある。
    • U-30クラス：予選は書類審査のみ、決勝は書類審査＆プレゼン。
    • OPENクラス：予選も決勝も書類審査＆プレゼン。2011年に始まった。
  • 一人で出てもいいし、チームで出てもいい
  • 個人での出場と企業での出場で参加費が異なる
    • 個人(一人でもチームでも)：調整中 ※2020年1月29日現在
    • 企業(一人でもチームでも)：調整中 ※2020年1月29日現在

③では「テスト設計コンテスト チュートリアル」　#とは

  • 「テスト設計コンテスト」自体の流れの説明もある。
  • 「何をどのような順序で考えながらテスト設計を行っていくと良いのか」という部分について、実際に考える時間や周りの聴講者との簡単なワークの時間も設けつつ解説がある。
  • 「チュートリアル」も「U-30クラス」と「OPENクラス」で分かれており、この参加レポで扱っているのは「U-30クラスのチュートリアル」。

④テスト設計コンテスト'20 U-30クラス チュートリアル

  • 開催場所：freee株式会社
  • 開催日時：2019年11月25日（月）19:00～
  • 講師：大段智広さん
  • 参加費：無料
  • テスト設計コンテスト'20 U-30クラス チュートリアル 公式HP
  • 募集していたConnpassのページ
  • 当日のスライド
  • 「テストを開発するプロセスをイメージできるようになる！」をゴールとして、以下の流れでチュートリアルが行われました。
    1. テスト観点の整理をして網羅的にあげよう：テスト要求分析
    2. テストフレームを考えよう：テストアーキテクチャ設計(テストコンテナモデリング)
    3. テストコンテナとその間の順序関係を考えよう：テストアーキテクチャ設計(テストコンテナモデリング)
    4. テスト観点からテスト値を網羅しよう：テスト詳細設計
    5. テスト開発を意識して進めてみよう
  • 以下のレポの中で「(p1)」などと出てきたら、当日のスライドのページ番号を指しているものと思ってください。
  • 以下の1～5は講義を聴きながら取ったメモです。
    • 下手に要約をしようとすると大切な部分も削ってしまうかもしれないと思ったため、メモをほぼそのまま載せてあります。

1.テスト観点の整理をして網羅的にあげよう：テスト要求分析

  • Myersの三角形問題についてのテストケースについてからスタート(p5)
    • 個人で少し考える時間を取ってから、隣の人とテストケースを発表し合う時間
      • だいたい同じだったが、お互いに新たな発見もあった
  • どうでしたか？
    • 出しても出しても終わらない。仮に簡単な仕様でも難しい。
    • 人によって、テストケースの表現が異なる。
    • 何をどれだけ網羅しているかを考えるには、そのケースだけを考えていたのでは難しい
    • 網羅的なものだけでなく、ピンポイントにバグを狙うようなケースがある。
  • 「テスト観点：テストすべきこと」
  • 抽象化して考えると、テストケースを網羅しやすくなる
    • 「これは、抽象化するとどういうことをチェックしたいテストケースなんだろうな」でテスト観点をあぶり出す。
    • その観点をもとに、「この観点からすると、具体的な値で何か足りないものはないかな」を考える。
  • トップダウンとボトムアップ/具体と抽象
    • トップダウン：「このテスト観点からすると、具体的な値で何か足りない値/ケースはないかな」を考えてテストケースをあぶり出す。
    • ボトムアップ：「この値/ケースは、抽象化するとどういうことをチェックしたいケースなんだろうな」を考えてテスト観点をあぶり出す。
    • トップダウンとボトムアップを循環させながら網羅していく。具体と抽象を行き来する。(p15を参考にしたメモ)

基本的なテストの方針2つ

  • (1)網羅
    • 保証型「もれなくやるぞ！」
    • 手助けになるのはラルフチャート。仕組みの外観のテンプレート。
  • (2)ピンポイント
    • 検出型「これ起きたらやばいな！」
    • 起きて欲しくないこと
      • HAZOP
      • バッファオーバーフロー
      • バグ
      • 後工程でバグを引き起こしそうな罠や弱点

「テスト観点てなんぞや」

  • 一言に「テスト観点」と言っても、抽象度がある。
  • どれが「テストケース」なのか、よくわからなくなってくる。
  • だから今回はこのような定義で進めましょう。
    • テスト値：3
    • テストのパラメーター：辺の長さ
    • テストケース：(3,3,3)テスト値の集まり
    • テスト観点：テストパラメータやテストパラメータを抽象化したもの
    • テスト観点をテスト条件と呼んだりもする。

注意点

  • 仕様書に書いてある仕様や文や単語を書き写しても、テスト観点は網羅できない
    • そもそも仕様書が完全な状態で存在することはあまりない
  • テスト観点は多面的にあげる必要がある
    • 一面的にやると漏れやすい
  • テスト観点をあげるだけでバグが見つかることもある
    • 開発者が考慮していなかった観点
  • 「網羅した風」のテスト観点の文書や納品物を作るのが本質でなく、網羅しようと多面的に様々なことを考えつくすのが本質です
  • 「どんなテストをするのか」というのを利害関係者とコンセンサスを得るためなのだというのを意識

2.テストフレームを考えよう：テストアーキテクチャ設計(テストコンテナモデリング)

  • 人によって簡単なテストケースもあれば複雑なテストケースもある
  • **「テストフレーム：テストケースの構造」**を考えよう
  • テストの関心ごとはテストフレームによって異なる
  • テストフレームに沿ったテストケースの構造を作成する
  • テストフレームを考えて、テストケースを作っていけば、テストが見やすくなる

3.テストコンテナとその間の順序関係を考えよう：テストアーキテクチャ設計(テストコンテナモデリング)

テストコンテナ：テスト観点やテストフレームをまとめたもの

  • テスト観点やテストフレームが増えてきたら、テストコンテナにうまくまとめあげると見通しの良いテスト設計になる
  • テストコンテナの種類
    • テストレベル
    • テストタイプ
    • テストサイクル
    • その他
  • テストコンテナは各組織で定められたものを使うことが多いため、あまり自分たちでは設計したことがないと思う。が、テストごとにテストコンテナを設計する方がうまくまとまる。
    • 既存のテストコンテナに対して、「なんでこうまとまっているのかな」をリバースエンジニアリングしてみることから始める
    • 良いテストコンテナ
      - 結合度が低い
      - 凝縮度が高い
      - テストコンテナの関連性や順序をモデリングする

テストアーキテクチャ：テストコンテナ間の前後関係や並列関係を決めたもの

  • テストコンテナ同士の関係性を意識

4.テスト観点からテスト値を網羅しよう：テスト詳細設計

  • 意外とここがつまづきポイント
  • 挙げたテスト観点をどのようにテストケースに落とし込んでいくか

テスト詳細設計4つのポイント

  • (1)テスト観点がどのようなタイプのテストモデルなのかを見極める
  • (2)テスト観点を充分に詳細化してテストパラメータを導く
  • (3)網羅基準を定める
  • (4)定めた網羅基準でテストパラメータを網羅するようにテスト値を設計する

テスト値には2つのタイプがある

  • (1)テスト値が直接テスト手順の一部として実施できるもの
  • (2)テスト値からさらにテストデータを導く必要があるもの
    • テストパラメータやテストモデルを特定せずに、闇雲にテストケースを上げるのは質の高いテストではない。
    • テスト観点に対して、どのような網羅基準を持ったテストケースのセットであるのかをしっかりと説明できる必要がある

テストモデルには4つのタイプがある

(1)範囲タイプ：ある連続した範囲を意味するテスト観点を網羅するときに用いる
  • 網羅基準例
    • 代表値網羅：テスト値は少数に収まるが、漏れが発生する
    • 境界値網羅：範囲が開いているときは自分で定める必要があるが、よほどよく検討しないと漏れが発生する
    • 全網羅：漏れはないがテスト値が膨大になるため現実出来ではない
      • 例
        • テストパラメータ：パスワードの文字列長
        • テストモデル：範囲タイプ
        • カバレッジ基準：境界値網羅
(2)一覧表タイプ：複数の要素からなる集合を意味するテスト観点を網羅するときに用いる
  • 網羅基準例
    • 代表値網羅
    • 境界値網羅
    • 全網羅
      • 例
        • テストパラメータ：ブラウザの種類
        • テストモデル：一覧表タイプ
        • カバレッジ基準：代表値網羅(シェア80％以上)
(3)マトリクスタイプ：2つ以上のテスト観点の組み合わせを網羅するときに用いる
  • 網羅基準例
    • 代表値網羅
    • N-wise網羅：N+1以上の段数の組み合わせの網羅を意図的に無視することによって現実的な数でNまでの組み合わせを全網羅する
    • 全網羅
      • 例:ペアワイズテスト
        • テストパラメータ：OS、アーキテクチャ、ブラウザの組み合わせ
        • テストモデル：マトリクスタイプ
        • カバレッジ基準：2-wise網羅(ペアワイズ)N=2のときが「ペアワイズ」
(4)グラフタイプ：丸と線で図を描けるようなテスト観点を網羅するときに用いる。状態遷移図など。

  • 網羅基準例

    • 代表パス網羅
    • ノード網羅
    • リンク網羅：矢印
    • Nスイッチ網羅：状態遷移図
    • 全パス網羅
      • 例:状態遷移テスト
        • テストパラメータ：ログインステータスの遷移
        • テストモデル：グラフタイプ
        • カバレッジ基準：1スイッチカバレッジ

  • どういう風にテストモデルを作るのか、というのを学ぶ

5.テスト開発を意識して進めてみよう

  • JSTQBのテスト開発プロセスだとざっくりしすぎているから、もっと開発プロセスを細かくする
    • テスト要求分析
    • テストアーキテクチャ設計
    • テスト詳細設計
    • テスト実装
    • テスト実施
  • テストベースからいきなりテストケースを作るのは無理筋
  • テストケースを開発成果物と捉えて段階的に詳細化していく必要がある
  • コンテナで分けていれば、人に渡すときにも便利

⑤感想＋α

  • 当日は会社のQAチームで「『テスト設計コンテスト'20 U-30クラス チュートリアル』のチュートリアル(「テスト設計コンテスト'20 U-30クラス チュートリアル」で何をするのかホームページを見てみたり、OPENクラスの優勝者の成果物をみながらディスカッションしたり)」をしてから、「テスト設計コンテスト'20 U-30クラス チュートリアル」に参加してきました。
  • 事前にスライドは読んでいたもののいまひとつピンと来ていなかった部分が、チュートリアルで少しずつ繋がってきたり体系化されてきたり整理されてきたりした気がします。
  • 「業務中に出てきたあのときのあれはこういうことだったのか！」といった気付きがたくさんありました。
    • とはいえまだ整理しきれていないとも感じています。
    • それらを整理するためには「整理するための時間」を取るのも大切かもしれませんが、それ以上に**「整理しきれていないことを自覚しつつ、自分なりにテスト設計を考え抜く時間」**を取ることが今の私(まだ実務経験が十分でなく、テストに関して自分の頭で考え抜いた経験が浅い)にとっては重要なのではないかと思いました。
    • テスト設計を考え抜くに当たって本チュートリアルで学んだことを参考にすることで、まだ整理できていない部分も徐々に腑に落ちて自分のものに出来るのではと思っています。
    • そして「整理しきれていないことを自覚しつつ、自分なりにテスト設計を考え抜く時間」を取るのに最適なのが「テスト設計コンテスト'20 U-30」に参加することなのでは…！？ということで、現時点でASTERの公式HPに掲載されている「テスト設計コンテスト'20 U-30」の情報を以下にまとめました。

⑥テスト設計コンテスト'20 U-30クラスの流れ

  • 参加登録開始：2020年1月下旬
  • 参加登録締め切り：2020年3月3日（火）
  • 書類選考予選の成果物提出締切：2020年5月11日（月）
  • 書類選考予選の審査結果発表：2020年6月22日（月）
  • 決勝戦の成果物提出締切：2020年8月9日（日）
  • 決勝戦の開催日程：2020年9月26日（土）
    • ※上記は全て2020年1月29日現在の情報です。
    • 本記事の中で「調整中」となっている「参加費」については、公式HPが更新され次第更新しようと考えております。

⑦さいごに

11
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
11
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?