SHOEISHA iD

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

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

「Agile 2018」レポート

アジャイル開発におけるテストとは? その未来とは何か?【Agile 2018】

Agile 2018参加レポート 第2回

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

リスクに立ち向かう探索テストとその手法

 こちらも同じくDan Ashby氏によるセッション「"It's a trap!" - How not testing risks is a huge risk」のレポートです。このセッションではソフトウェアテストに潜む「リスク」に注目した内容でした。

 まず、「リスク」とは何でしょうか? 辞書を調べると「ネガティブなことが起きる可能性」「ビジネスやエンジニアリングの場で潜在的に起こりうるイベント」などがでてきます。ソフトウェア開発におけるリスクにはどのようなものがあるでしょうか?

  • ビジネスリスク
  • 人員的リスク
  • プロジェクトリスク
  • プロダクトリスク

 ソフトウェア開発に関わる方であれば、上記のようなリスクは誰もが経験したことがあるはずです。

 ここで、簡単な演習として「イス」をどうやってテストするかを考えることになりました。イスをテストする場合、どのような観点でテストするでしょうか?

  • 座ってみる
  • 高さを調整する
  • ローラーが付いているので動かしてみる……

 セッションでは、いろんな観点が参加者からでてきましたが、氏は参加者に以下のように問いかけます。

  • そのアイデアがすぐに出てきましたか?
  • それらのアイデアをどのように整理するとよいでしょう?
  • そのアイデアはどういった情報をカバーしていないでしょうか?
  • そして、どういったリスクをテストしようとしたでしょうか?

 テストの目的とは「情報を明らかにすること」です。その中で特に、リスクを明らかにしていかなければなりません。

 ここで氏から、明らかにするべきリスクを見つける手助けになるモデル図が紹介されました。あらゆるレベルでプロダクトのリスクを考慮し、シンプルに以下の質問によってリスクを切り分けます。

 「そのリスクは重要だろうか? 我々はそのリスクを考慮すべきだろうか?」

 この質問に対して「Yes」と考えた場合、Test Charterなどのツールを使ってさらに調査を進めていきます。Test Charterとは、探索テストを実行する上で利用する手法です(Test Charterについては後述します)。

 開発プロセスごとのリスクを見てみましょう。開発する前、開発中、開発後、で見つかる情報は異なります。

 例えば、リスクに対する意思決定をする場合、開発前のフィードバックがもっとも早いものとなり、開発後になるともっとも遅いフィードバックとなってしまいます。バグを見つけて報告する……というのは正しい行動ではありますが、根本原因を解決する正しい解決方法とは言い切れません。

 いうまでもなく、早期のフィードバックほど重要なものはありません。

 しかしながら、ソフトウェア開発にはたくさんのテストが存在し、さまざまなテストを見ていくと、「テストフェーズでやるテスト」になってしまう傾向があります。例えば、セキュリティテストやパフォーマンステストをソフトウェア開発後に行っているとすれば、フィードバックも遅くなってしまうわけです。

 そこで探索テストが登場します。まだ明らかでないリスクを発見するために、探索テストが利用できます。

 探索テストにはTest Charterという手法が有効です。調べてみると、本来は「Actor, Purpose, Setup, Priority, Reference, Data, Activities」といった項目を埋めていくようですが、上記のようにシンプルなフォーマットになると、アジャイル開発で使われるユーザーストーリーのように見えてきます。

  • データ型のリスクを発見するために
  • ものすごくたくさんの文字列一覧を利用して
  • コメントボックスを探索する

 他にも「データによる負荷のリスクを発見するために、10000文字を1回のリクエストに利用して、アカウントAPIを探索する」という書き方もできるので、APIテストといったシステムのバックエンド側のテストでも使えます。

 氏のセッションには「Heuristic(試行錯誤的な。経験則)」というキーワードが何回も登場します。「Testing & Quality」トラックにはたくさんのテスターが参加していましたが、探索テストのような自動化できない部分をテストする手法に、テストの未来を感じます。

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

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

もっと読む

この記事の著者

Agile 2018レポートチーム(株式会社メルカリ)(アジャイル ニセンジュウハチ レポートチーム)

菅原 史晴 QAエンジニア 木下 祐実 QAエンジニア 近藤 久志 QAエンジニア 藤原 大 Automation & QA グループ エンジニアリングマネージャ

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

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

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/11033 2018/08/11 09:00

おすすめ

アクセスランキング

アクセスランキング

イベント

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

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

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

メールバックナンバー

アクセスランキング

アクセスランキング