SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

「EuroSTAR 2018」レポート

テスターは「まだ」死なない~テスターの武器となるTQEDやBDD【EuroSTAR 2018】

「EuroSTAR 2018」レポート 第4回

  • このエントリーをはてなブックマークに追加

 ヨーロッパ最大規模のソフトウェアテストカンファレンス「EuroSTAR Conference 2018」がオランダのハーグで開催されました。本稿の前半で紹介させていただくセッションは、Adam Roman氏による「Increasing the tester's creativity」です。テスターの生産性を劇的に向上する方法TQEDとは、いったいどういうものなのでしょうか?(執筆担当:藤原史和)

  • このエントリーをはてなブックマークに追加

テスターの生産性を劇的に向上する方法TQED

 どうやってテストすればよいか? どうやって良いテストを設計すればいいのか? これらを学べる機会はそう多くはありません。なぜならば、それぞれのプロジェクトは、まったく異なったコンテキストで運営されていたり、製品もそれぞれ違うコンセプトで作られていたりするからです。

 さまざまな製品やプロジェクトにおいて、問題を正しくモデリングできて、シンプルで容易に理解でき、柔軟性があって、さらにアイデアを与えてくれる……。そんな夢のようなモデルがあれば、みなさん使ってみたいと思いませんか? この「Increasing the tester's creativity」というセッションでは、一つの答えとしてTQEDというテスト設計技法を紹介しています。

 講演者のAdam Roman氏は、ポーランドのJagiellonian大学コンピュータ科学研究所の離散数学部門でアシスタント・プロフェッサーとして教鞭をとられており、ソフトウェア品質保証、機械学習とAI、理論計算科学を専門とされています。

TQEDモデル

 TQEDモデルはとてもシンプルな構成です。

  • ステップ1:テスト対象を次の4つの要素に分解して考えます。それは、時間(Time)量(Quantity)イベント(Event)そしてデータ(Data)です。
    • 時間: 平均的な利用時間、長くかかった場合、すばやく利用した場合など
    • :平均値、最大値、境界値など
    • イベント:変数の作成、メソッドの呼び出し、ボタンの押下、ファイルの名前の変更など
    • データ:入力データ、ブラウザのクッキー、ファイル名など
  • ステップ2:ステップ1で出てきた要素を組み合わせて、どうやってテストするかを考えます。

TQEDモデルの実践

 簡単なチケット自動販売機を考えます。この販売機は下記のようなユーザインターフェースを備えているものとします。

 5セント硬貨、10セント硬貨、25セント硬貨、1ドル札、2ドル札、5ドル札を入れる口があり、通常チケット選択、安売りチケット選択、そしてキャンセルと購入ができます。TQEDモデルに従うと次のように分析できます。

ステップ1: 要素に分解

 上記のように、要素に分解していきます。

  1. :購入できる最小値、最大値、そしてその境界値など
  2. イベント:ボタンを押す、変更する、硬貨/紙幣を入れる、チケットを印刷する、電源をオン/オフする、キャンセルするなど
  3. データ:マシン内のチケット数、合計金額、 有効な硬貨/紙幣、無効な硬貨/紙幣など
  4. 時間:平均的な購入時間、購入に長くかかった場合、すばやく購入した場合など

ステップ2: 要素を組み合わせる

 次に、整理した要素を組み合わせていきます。

  1. データ:硬貨の種類×量=境界値
    • 5セント硬貨だけでチケットを買ってみる
  2. :境界値×データ=合計金額
    • チケットを買える最大で考えてみる
    • さらに1.+2.を組み合わせてみる:チケットを買える最大金額に対して全部5セント硬貨で購入してマシンは壊れないかなど

 モデルは、要素を組み合わせて、それらをまとめるというステップをとります。これはとても汎用的でありシンプルですが、効果的なアプローチです。

 TQEDは強力なフレームワークであり、テスト設計においてテスターの生産性を劇的に高めます。しかし、そもそもテスターに分析能力がなければ、いくらフレームワークが優秀でも効果は期待できません。いうまでもなく、フレームワークはただのツールであり、分析をするのは私たちです。

 このフレームワークは、『Thinking-Driven Testing』という書籍でも詳しく解説されています。また、チュートリアル資料はこちらで公開されています。

会員登録無料すると、続きをお読みいただけます

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

次のページ
BDDによるソフトウェアテスト自動化

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
「EuroSTAR 2018」レポート 連載記事一覧

もっと読む

この記事の著者

EuroSTAR 2018レポートチーム(ユーロスター2018レポートチーム)

岡本 明 アクセンチュア株式会社 テクノロジーコンサルティング本部 シニアマネージャー 千葉真弓 アクセンチュア株式会社 テクノロジーコンサルティング本部 シニアマネージャー 藤原 史和 楽天株式会社 サービス品質保証グループ マネージャー 米山 允章 株式会社メルカリ QAエンジニア 藤原...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/11239 2018/12/10 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング