NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'19 Hokuriku

S2) 基調講演
「開発プロジェクトにおけるテストマネジメントの基本と実践」
湯本 剛氏 氏（ASTER）

開発におけるテストの役割

冒頭で、工数を表したグラフを示し「ソフトウェア開発においてテスト工数はどれくらいの割合を占めているか。」と湯本氏は会場に問いかけた。再開発や新規開発、改良開発などの状況によってテスト工数はばらつきがあり、人のアサインを間違えるとテストが終わらずリリースが遅れる羽目になる、テストのやり方をうまくやるかやらないかでプロジェクトが成功するか失敗するかが決まると述べた。

2つのテストの役割

まず1つめとして、テストは品質の良いものを世の中に送り出すための大事な手段である。実物がどうなっているかはテストしないと不明で、実物の中にどれだけバグが潜んでいるか、それを正しく映すというのがテストの重要な役割である。

2つめは、テストは開発ライフサイクルの主要な活動であることを前提に、技術職として決められたQCDを達成すること。これをどれだけ効率的にできるかがテストの重要な役割である。上手いテストをするとは、「テストの活動をクリティカルパスにしないこと」である。

テストプロセス

活動を具体的に明らかにし、共有可能にするのがプロセスの大事な意味である。テストプロセスには何があり、どう評価するかがポイントとなる。

テストプロセスの改善モデル「TPI NEXT」

テストプロセスを改善するためには技法や手法だけでは難しく、多くの依存関係や想定外の対応を余儀なくされるため、プロジェクト全体を考えた上で改善する必要がある。
テストプロセスの改善モデルとしては「TPI NEXT」があり、「利害関係者との関係」「テスト業務の専門性」「テストマネジメント」の3つが改善の対象となるキーエリアのグループである。

利害関係者との関係

• テストの必要性を理解してもらえているか
• テストをする人たちが開発の奥深くまでどれだけ関与できるか
• どういう開発か、何をつくるかを理解していれば良いテストができる

テスト業務の専門性

• 技術者が手法を理解し、効果的な場面で活用できるか
• 技術者のプロ意識をもっているか
• テスト設計スキルやテストツール等を使いこなせるか

テストマネジメント

• 与えられたコストとリソースの中でテストをやりきれるか
• テストフェーズより前でどれだけバグを防げるか、事前にレビュー等でバグをつぶせるか
• テストの情報をどれだけ客観的に、感覚値ではなく具体的な数字でだせるか
• バグの管理や、バグを分析してプロジェクトへフィードバックできるか
• テスト成果物の管理と、その再利用ができるか

テストの活動の組織化

テストをボトルネックにしないための施策は以下の3つである。

テスト活動の組織化

情報の可視化、一元管理してみんなが見えるようにすること。

テスト活動の前倒し

開発メンバーをフル活用し、早い段階からレビューやテスト計画などのテスト活動を行うこと。

テスト担当者の技術レベルの向上

効果的な改善活動のためにはテスト担当者の技術力が必要である。

まとめ

テストが品質に貢献するのは当たり前という前提から、テストをクリティカルパスにしないように、上手く運営するのがマネジメントに求められていることである。
そのためにはテストプロセスを改善し、テストの役割を担うことが大切である。

筆者感想

「テストをクリティカルパスにしない」という言葉がとても刺さった。
そのための活動をプロセスとして明示化し、見直し、カイゼンするというマネジメントの重要さを改めて感じた。

招待講演
「そのレビュー、大丈夫ですか？～現状レビューの問題発見・解決」
安達 賢二氏（HBA）

はじめに

レビューは、欠陥検出・予防、生産性向上などへの有効な活動として認識されているが、様々な問題や課題を抱えている現場が多くある。この講演では事前にアンケートで集めた現場の声を元に、現状のレビューの問題点や解決の方向性を持ち帰ってもらう内容である。

レビューの現状

事前アンケート「記載されていない項目に対してレビューで指摘できるようになるには？」

これはレビューで最も実施する必要がある。ソフトウェアテストとレビューの明確な違いは「書いていないことを見つける」ことがレビューの大きな役割であり、みんなが認識していることがちゃんとできるのか、はテストである。

レビューで最も期待されている、書かれていないことを見つける方法の例としては以下である。

• 過去事例から確認する（自分たちのくせを反映する）
• 表現方法を変える（自分の言葉で言い換える）
• 利用者の背景やシーンから読み解く
• 前のフェーズの成果物や関連成果物との整合を見る等

事前アンケート「レビューに適した人数は？」

最適は3人～5人。人数が少ないほうが一生懸命考えることができ、さらに他の人の意見も聞けるのでレビューア側の学びにもなる。人数が多くなるほど、自分は見なくても大丈夫という気持ちになり無駄が多くなる。

事前アンケート「レビュー観点を明確にしていることが必要だと思っているが、この考え方はどうか」

その通りだと思うが、さらに必要だと思うのが、作成者が「こういうところを見て」と言えることが大切である。自分が苦手なところを伝えてからレビューしてもらうともっと良い。レビューアだけではなく作成者もレビュー観点を同じように伝えられなければならない。

事前アンケート「レビューのスキルを定量的に測定できる方法はないか」

レビューは、このスキルさえ定量的に測定すれば大丈夫というものはないが、レビュー力というものに置き換えることができるとすれば、以下の2つが必要である。

• 情報元を見て仮説を立てられる仮説力
• レビュー対象に対して「要するにこういうことだよね」という要約力

事前アンケート「プロジェクトの全体工数に対してどれだけレビュー工数をかけるか」

調べた結果、10～15%くらいが適切で5%を切ると欠陥が大きくなりやすいという調査結果がある。

レビューで効果を高めるための3つのポイント

できるだけ（無駄な）レビューをしない

レビューすべきものだけをレビューする

レビューの質を高めるために運用方法や観点を見直すだけではなく、対象の質もあげなければならない。作成者自身のセルフチェックも大事であり、レビューの開始基準に満たない成果物はレビューをしないという判断も必要である。

集合形式レビューの時間を最小化する

集合レビューを行う場合のレビューア稼働率を工数で分析すると、各レビューアに無駄と思われる時間帯が発生していたため最小化する必要がある。

一度のレビュー規模を小さくする

レビュー対象の量が多い場合は、作成途中での区切り毎にレビューすることによって無駄を省くことができる。また、学習と認識合わせとレビューを同時にできるモブワークも効果的である。

ぼんやりレビューを行わない

対象を決めて重みづけを決めた上で、効果的なレビュータイプを選択する

レビュータイプによって得手不得手があるので、レビュータイプを理解し、対象やレビュー目的や状況によって使い分けることでより効果的なレビューができる。レビューを準備するタイミングでレビューの仕方を設計すると良い。

狙いを定めてレビューを行う必要がある

情報を読み解いて仮説を立てて実際に検証するというプロセスの中で、あらかじめ「どこにどんな欠陥がありそうだ」ということの狙いを定めておくとより効果的にレビューができる。

人間特性を考慮して運営を設計する

レビューでは受け取り側に気づきを与えることが重要であるが、レビューアとレビューイのコミュニケーションスタイルの違いによって受け取られ方が変わる。そのため、レビューアは「指摘される側が受け取りやすい指摘の仕方」をレビューイによって使い分ける必要がある。コミュニケーションスタイルを分析し、自分たちがどんな特徴を持っているか相互で理解し、伝え方を変えると効果的である。

レビューをやりっぱなしにしない

レビューを実施したあとに、評価とふりかえりをして、レビューをより良くすることが重要である。

感想

レビューの大きな役割「書いていないことを見つける」ということをもっと意識しようと思った。
聴講者から事前にアンケートを募集し、それに対して具体的な回答をするという講演内容は聴講者にとってはとても持ち帰ることが多く、素晴らしい講演と感じた。

セミナー1
「ユーザー事例から見るテスト自動化ツールの効果的な活用方法」
福地 義博（アシスト）

はじめに

株式会社アシストは、お客様に「ITソリューション」と「ソフトウェア・サポート」を提供する「パッケージ・インテグレーター」である。
提供しているテストツールは、負荷テストツール、機能テストツールであり、今回は製品紹介と共に導入事例を紹介していく。

導入事例1 「通信業における回帰テストの事例」

手動での回帰テスト時の課題として、テスターの属人化、テストデータの作成に時間がかかる等があった。その課題を解決するために、「Unified Functional Testing」というテスト自動化ツールを導入することで課題を解決してきた。

ツールと方法論を利用/検討することで、テスト実施プロセス全ての自動化に成功。具体的な効果としては、工数削減率20%、回帰テストカバレッジ100%、テスト結果のエビデンス取得の自動化を実現し、システム品質の向上に貢献した。

回帰テストを円滑に進めるポイントとしては以下である。

• 事前の動作検証をし、ツールの適用範囲を見定める
• 既存テスト手順を見直し、自動化に向けた最適なテスト設計を行う
• 製品の習得コストを意識する
• 適用範囲は小さく始め、見極めを行う
• 期待値を明確にする
• UI変更に伴う既存自動化資産をメンテナンスしやすく部品化する
• テスト推進者/チームの設置を行う

導入事例2 「印刷業における負荷テストの事例」

過去に発生したサービス停止トラブルの調査が難航していた状況を解決するために、「LoadRunner」という負荷テストツールを導入、さらにアプリケーション性能管理（APM）ツール「JENNIFER」を導入することで問題点を明確にし、具体的な課題を洗い出すことに成功した。

負荷テストを行う際によく発生する問題を解決するポイントとしては以下である。

• DBの蓄積データ量に伴い、処理性能の想定を行った上で負荷テストでの検証を行う
• ユーザーアカウントと権限の準備をし、リハーサル時に稼働確認を行う
• システムで利用可能なデータを事前に洗い出す
• 負荷テストの実施回数や目標処理件数に応じてデータを準備する
• サーバリソースの確保を行う
• 負荷テスト開始時の負荷量を緩やかに設定する
• 負荷量を見直し、適宜調整を行う
• ロードバランサー設定の確認、調整を行う
• ネットワークにおいて想定負荷がかかるように、トラフィック量を確認する
• ハードウェアにおいて想定負荷がかかるように、ツールが推奨するハードウェア端末を予備台数含めて準備する

セミナー2
「ツールを用いたテスト自動化と継続的インテグレーションの実現」
福地 義博（テクマトリックス）

はじめに

テクマトリックス株式会社とは、最新のIT技術を活用し、顧客企業のビジネスモデル変革と企業競争力の強化を支援するITのスペシャリスト集団である。いかに早く市場にリリースするかが重要になっている昨今、テストの自動化やビルド・テスト・デプロイなどの一連の流れを自動化することがリリースを早める上で効果的である。
今回は、UIテストの効率的な自動化ツール、組織的なCI/CDを実現するツールの紹介をしていく。

UIテスト自動化「Ranorex」について

テスト自動化の目的と効果として、コスト削減、効率向上、品質向上の3点がある。
UIテスト自動化の課題は、複数のプラットフォームへの対応やテストスクリプト作成/保守の負荷等あるがオールインワンのUIテスト自動化ツール「Ranorex」であれば様々な課題を解決することができる。

「Ranorex」の特徴

• 様々なテクノロジー（デスクトップ、Web、モバイル）をサポート
• マウス・キーボード操作を記録し、リプレイが可能
• 見た目や座標に依存しないオブジェクト認識が可能
• モジュールの管理・再利用が可能であり、モジュールを変更した際は参照しているすべてのテストケースに自動反映が可能
• GUI上のデータソース・データバインドを設定可能、イテレーション毎にレポートを生成することが可能
• オブジェクトの存在検証からUI要素の画面ショット比較が可能
• 標準的なプログラミング言語（C#、VB.NET）をサポートしており、より高度なテストスクリプトの作成が可能
• JenkinsなどのCI環境とのシンプルな連携が可能

「CI環境構築サービス」について

CI/CDの導入は「開発だけではなく、リリース、フィードバックなどを含めたサイクルを早め、製品の価値とチームの力を最大限に高めるための継続的・組織的なカイゼン活動」が必要となる。理想的なソフトウェア開発で、多段階CIシステムを導入した場合と未導入では、変更した内容が反映されるまでの時間に70倍の違いが生まれる。多段階CIシステムの導入により開発チームの生産性が向上し、品質の良いソフトウェア開発に繋がるのである。ただし、理想的な開発プロセスの「CIパイプライン」を設計しないとCIシステムを導入した効果が限定的になる場合がある。テクマトリックス社のCI環境構築サービスとは「Certified CloudBees Jenkins Engineer」が環境に合わせたJenkinsのインストールからジョブの作成・保守を行うサービスである。

「CI環境構築サービス」サービスの利用メリット

• ソースコードの早期チェックによりバグ解決数の向上や、コードレビューの工数が削減可能
• ビルドやソースコードチェックの定期実行により、開発されるコード品質が均一化。作業品質の向上が実現可能
• 自動化や構成管理が適切に行われるようになるため、運用のルール化・標準化が可能
• 手間のかかる構築・教育を支援することにより、短時間で開発現場に自動化基準を導入可能

全体の感想（筆者感想）

今回のJaSSTでは、筆者が現場で抱えていた課題を解決するためのヒントをたくさんもらうことができた。
このヒントを元に現場のプロセスの見直しやレビューのカイゼンという活動に繋げていきたいと思った。
また、東京以外の地域のJaSSTには初参加だったが、講演内容はもちろん、北陸の食事やお酒も非常に美味しく、大満足の1日であった。

ソフトウェアテストへの熱意あふれる方々とJaSSTという場を通じて会える体験はなかなかできないと思う。
初回開催にして120名の方が申し込まれたことから、北陸におけるソフトウェアテストの需要の高さもうかがえ、来年のJaSST Hokurikuがますます楽しみである。