読者です 読者をやめる 読者になる 読者になる

mhlyc -presentation

ソフトウェアテスト、品質に関わること、たまに変なことを書いていくブログです。

第2回盛岡ソフトウェアテスト勉強会レポート

ソフトウェアテスト

第2回盛岡ソフトウェアテスト勉強会

すっかり一ヶ月経ってしまいましたが、主催した勉強会のレポートを上げておきます。

kokucheese.com

会場は盛岡駅前のマリオスでした。写真のビルの会議室で行いました。駅前なのでアクセスもかなり良かったです。

そこまで大人数での勉強会ではありませんでしたが、有意義な議論ができたと思っています! 

以下、各セッションについてレポートしていきます。

 

全体の章立て(コンセプト)

今回の勉強会は、大テーマを「テスト技術者はじめの一歩」と設定し、 登壇者の方々と相談しながら以下のような構成で勉強会を企画していきました。

  • テストプロセス
  • テストレベル
  • テストタイプ

この構成をとった理由には、以下のような背景があります。

  • (経験的に)テスト技法をやみくもに学んでも、すぐには活用できないことが多い
  • テストプロセスやテストレベル、テストタイプなど基礎となる概念を学んだ方が、初学者の最初の一歩としては良いのではないか

なので、今回はこの3本立てとし、ソフトウェアテストへの理解を深めていただこうと考えました。

ソフトウェアテストことはじめ -2016年ver.-

www.slideshare.net

最初のセッションは、私(@mhlyc) が担当しました。

かなり直前まで内容を考えていたのですが、最終的には以下のようなコンセプトに落ち着きました。

  • 実体験に基づく、テストプロセス改善のヒントを提供したい
  • テストプロセスの概要を把握してもらいたい

上記の2点に注意して、セッション内容を検討していきました。発表資料を見ていただくとわかりますが、テストプロセスの概要を示すスライドと、実体験に基づくテスト活動チェックリストから構成されています。

時間内に伝えきれなかった部分もあり、いつか再演したいなと考えているところもあるのですが、チェックリスト自体は(アンケートの結果を読んだ限りでは)なかなか評判も良かったようでホッとする思いでいます。(チェックリストは、資料のp.22に添付しています)

f:id:mhlyc:20161225125129j:plain

 (p.22 テスト活動 簡易評価チェックリスト)

資料を見ていただけるとわかりますが、テスト分析や設計に関するチェック項目はここにはあまり出てきていません。なぜなら、それよりも先に取り組むべき問題も多くあるからです。特に、テスト活動の改善をスタートする場合の第一歩はテスト設計技法など分析・設計の技術ではないことが経験的に多いです。

まずは、普段自分たちの行なっているテスト活動を見直す機会を持つことが大切です。そして、「これは問題だよね」と皆で合意した部分から、少しずつ改善策を検討してみてはいかがでしょうか。

手戻り撲滅!テストからできる手戻り防止策

株式会社ウェブレッジの浦山さんに、開発コストとテストのお話、受け入れテストについてのお話をしていただきました。

開発コストとテストのお話では品質コストや失敗コストについても触れ、失敗コストを減らす戦略としてV字モデルやWモデル、欠陥分析の考え方についてご紹介いただきました。

セッションの中では「通信カラオケシステムのテスト観点を考えてみよう」という内容のワークショップも行いました。参加者どうしで様々な意見が出て、テスト分析の考え方にも様々あることがうかがえました。チームごとにどう進めたのかを聞いてみたところ、以下のような進め方をとったチームがありました。

  • カラオケのメイン機能は何か? もっと細かく考えると、何があるか考えていった
  • プログラムを作った時に、一つひとつのクラスの品質を担保することを考えた。そのあと、使用人数、導入店舗などのビジネス的な背景についても考えていった

  • 採点ゲームが使えるなど基本的な機能から、テスト観点を考えてグルーピングしていった

チームごとに、色々な進め方をとっていたのも興味深かったです。

その後、テスト観点を仕様書ベースで考えるだけではなく「どういう不具合を出すか」をより深く考える必要があるとして、そのための考え方としてテストレベルの解説をしていただきました。

テストレベルは「いつ、どのような不具合を出したいか?」というところに着目すると考えやすいとのことでした。以下のようなイメージです。

  • 単体テスト:実装ミスがないか確認する
  • 結合テスト:インターフェイスの不整合がないか確認する
  • システムテスト:不十分なFeatureを実装していないか確認する

ここでいうFeatureとはFunctionとは異なっており、以下のような説明がされました。

Function: 製品の操作を表す技術用語

Feature: 製品をより良くし、ユーザにとって役立つもの、顧客にとっての機能価値という意味のマーケティング用語

その他、受入テストにおけるユーザの振る舞いやユーザシナリオを利用したテスト分析などについても解説が行われました。ユーザシナリオ分析については実際にワークを行って理解を深めました。

「オンラインショッピング」の題材で実際にユーザシナリオ分析を行いましたが、人それぞれ考えるシナリオが大きく異なっていたのが印象的でした。例えば「注文するものを決めてから、ショッピングサイトにアクセスする」という人もいれば「ショッピングサイトにアクセスしてから、注文するものを決める」という人もいました。人それぞれ利用したい機能も全く異なるということが実感できるワークでした。

最後に、テストレベル、FunctionとFeature、機能がもたらす価値を確認するためにユーザストーリーを意識することなど、セッションで解説された要点をまとめて終演となりました。資料は非公開とのことですが、参加された方々にとっては非常に有益なセッションとなったのではと思っています。私自身も、改めて理解を深める機会となってとても良かったです。

ユーザビリティの重要性 - 仕様通りだけがテストではない - 

最後のセッションとして、テスト業務やマークアップエンジニアとして幅広い業務を経験されている株式会社ヴェス 吉田さんにご講演いただきました。

まず初めにIVECにおける機能テスト、非機能テストについて解説され、その次にJSTQBにおけるテストタイプについて解説されました。ここで、実際のテストでは機能テストの確認にとどまってしまい、非機能テストの確認が不十分になる場合もあるとされました。

その後、非機能テストの中で特にユーザビリティテストに着目し、ユーザインタフェースに関する様々な事例をご紹介いただきました。スマホアプリのメニューやWebサイトの登録画面など、事例はどれも身近でわかりやすいものでした。また、事例ごとにどのような問題があるかだけでなく、改善の例も示されていたのが理解しやすかったです。

興味のある方はぜひ資料をご覧ください。(資料はイベントページに掲載しています。)

最後に、機能仕様に則ったソフトウェアを作れば良いわけではなく、必要なテストを行間を読んで実施する必要があると述べられました。そのためには、作成したテスト手順をただなぞるのではなく、ユーザにとって使いやすいか、また使いたくなるかを意識してテストを行う必要があるとして発表を締めくくられました。

非機能テスト、特にユーザビリティテストの重要性を実感できるセッションでした。 

次回に向けての反省(運営側)

今回は前回に比べてメンバーも増え、告知や準備、セッション内容検討などはより計画的に行えるようになったと感じています。

ただ、運営面での課題点も多く感じており、次回のさらなるコンテンツ拡充、参加者の増加をめざして改善をしていきたいです。また、幸いなことに運営面にご協力くださる方も増えてきました。大変ありがたいことです。力を合わせて、取り組んでいきたいと思っています。

参加くださった皆様、ご協力いただいた皆様に改めてお礼申し上げます。

今後とも盛岡ソフトウェアテスト勉強会をよろしくお願いします!