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

オープニング

爽やかな秋晴れの中、香川大学 幸町キャンパスの研究交流棟5階でソフトウェアテストシンポジウム2019四国が開催された。
実行委員長の高木氏より、開催の挨拶が行われた。

「今年で第12回目となる本シンポジウムは、例年、講演とワークショップで構成している。
本日のシンポジウムで仕事に役立つ知見を持って帰れるようにして頂きたい。
大学で開催していることから学生も一部参加している。」とのことであった。

筆者感想

学生がシンポジウムに参加されていることは、テストに関して興味を持ってもらうきっかけになると考えるため、とてもうれしく感じた。
オープニングセッションを聞きながら、これから始まる講演やワークショップのことを考えてとてもワクワクした。

基調講演
「これからの開発に役立つソフトウェアテスト」
湯本 剛 氏 （freee）

自己紹介

社会人をテストエンジニア一筋で25年勤めておられ、現在はfreeeというスタートアップの会社でテスト師匠として働いている。また自身で会社を立ち上げて、テストのコンサルティングを実施している。他に、ASTERの理事やISOの幹事を実施している。

以下に講演の内容を記載する。

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

テストの役割は以下の2つである。

1. 品質の良いものを世の中に送り出すための大事な手段
2. 開発サイクルの主要な活動（開発した人が作ったものをどれだけ大丈夫か確認する）

テストは鏡である（自分たちの状況を映し出すものである）ため、ソフトウェアの状況を正しく映す必要がある。
テストを納期に間に合わせ、決められたコストで実施するためには技術を学ぶ必要がある。
技術には、作業スピードを上げる技術（自動テストやTDDテスト）、スコープ（どこまでを見て、どこまでを見ない）を決める技術などがある。

2.テストプロセス

活動を具体的にあきらかにして共有可能にするのが「プロセス」である。
共有可能にしないとコストがかかる。理由は、開発は一人で実施しないため、プロセスが決まっていない場合、担当者のアウトプットがわからず、聞き取り調査を行う作業が発生するためである。

テスト実行の活動は、実施するだけでなく、テスト環境やデータを準備するテスト準備や状態をマネジメントする作業も含む。
テスト準備においてもテスト計画やテスト分析が必要で、本番環境で動作確認する際に、何を見る必要があるかを決定する。
　（何をどこまでテストするかを分析し、その後、適切なサンプリングを行うためにどれだけテストを実施するかを決める。）
ISTQBが定義するプロセスには、計画、モニタリングとコントロール、分析、設計、実装、実行、テスト完了作業がある。
これらの活動は、シーケンシャルに実施するのではなく、計画をしながら分析を行うことがある。

3.いまどきの開発

大規模システムは何十ものシステムを経由してやっとアウトプットしていて、解きほぐせないものとなっている。
トレンドが1年経過すると変わっているため、完成した時には時代遅れになってしまう状況である。
今、本当に欲しいものがわからないため、不必要な機能まで実装されている。

現在、システム開発に求められていることは、トライアルアンドエラーを繰り返して学習していくことである。
繰り返しのスピードを速くするためにリリース単位を小さくし、世の中に出したいものが出せているかフィードバックを得られるように努力している。
試さなければわからないことを試さない、は今どきではない。

4.テストの変わることと変わらないこと

ソフトウェアテストの7原則は変わらない。

1. テストは欠陥があることは示せるが、欠陥がないことは示せない。
   理由はテストでサンプリングしかしていないからである。
2. 全数テストは不可能
   実施するには膨大な時間がかかり、不可能である。
3. 早期テストで時間とコストを節約
   早期テストを実施すると早く悪い部分を修正できるため、時間とコストを節約することが出来る。
   後工程で見つかると誰が直すか、などの打ち合わせ作業が発生し、コストがかかる。
4. 欠陥の偏在
   あるモジュールに欠陥が集中することである。集中する部分は、複雑な仕様や、新しい技術を使用している、モジュール作成者間の仲が悪い、が挙げられる。
5. テストは状況次第
   自動運転とFacebookではテストが異なる。
6. 殺虫剤のパラドックス
   同じテストを実施していると、そのテストからバグは出なくなる。
7. バグゼロの落とし穴
   バグがゼロになるまでテストしたと言ってもゼロにはならない。

5.開発のトレンドとテストへの影響

複雑にしない、作成を早くする、を実現するために、今どきの開発でチャレンジしていることは以下の4つである。

・オープンソースの利用

開発ベンダに依存せず、自身でコントロール可能な開発スタイルとなっている。ベンダに依存すると開発をベンダのルールに合わせなければならない。
ある機能のプロトタイプ作成がオープンソースのサービスを組み合わせることにより短期間で可能となっている。

・クラウドの利用

インフラ調達が瞬時に可能である。費用は掛かるが、オンプレミスで作成するより安価である。
システム運用と管理が分離しないため、リリーススピードが向上する。

・アジャイル開発

の開発が出来て、少しずつ作成しながら微調整が出来る

・マイクロサービスアーキテクチャ

今までのモノリス（モノリシック・アーキテクチャ）のような全体的に考えたアーキテクチャではなく、機能毎に考えられたアーキテクチャである。

上記を利用することで、テストの観点で過去に抱えていた問題と異なる問題が発生している。

・オープンソースでは開発に合わせたテストツールが必要

開発言語に合わせたテストツールが必要になる。また、オープンソースのバージョンがアップデートされる毎にテストが必要になる。
メインフレームとは違い、自分で責任が取れるようにテストする必要がある。

・クラウド

本番環境でテストしなければならないため、機能トグルを使ってテストする必要がある。
クラウドの性能や信頼性を把握するためのテストが必要である。

・アジャイル開発

QAがチームに入り込んでテストを実施するが、開発者とQAでテスト実施するスコープや内容を常に意識合わせをしなければ、何をテストしているか分からなくなる。
また、リグレッションテストが主役となる。自動テストで大事なことは、様々な人（プロダクトオーナーやカスタマーサポートの人など）がテストケースに何をテストするかを気軽に足せるように工夫することである。テストケースを追加する仕組みがソースコードへ直接実装する方法である場合、プロダクトオーナーやカスタマーサポートの方にとって敷居が高い。しかし、仕組みがテストケースをエクセルに追記していく方法である場合、テストケースを提案する敷居は低くなる。

・マイクロサービスアーキテクチャ

単体テスト、統合テスト、システムテスト、ユーザ受け入れテストと実施するのではなく、単体テスト後にマイクロサービス毎のテストを実施して、全体を統合してビックバンテストを実施するようになっている。
マイクロサービス毎の結合点が保証されているかをテストする。

6.これからの開発に役立つソフトウェアテスト

いまどきの開発のテストあるある

コストを適正におさめることで、品質が低くなりすぎる傾向になる。サービスが売れてくると、品質を適正なレベルに引きあげて簡単に落ちないようにするためにQAを大量増員する。すると、コストが増大する。QAの大量増員することを自分はスーパーリッチな松プランと呼んでいる。
開発する時間よりQAの時間が長くなり、複数のプロジェクトを兼任しているQAがボトルネックとなる。

理想的な将来

開発チームでテスト作業が行えるようにする。QAが入り込んでも良いし支援していくでも良い。
上記のようにすることでQAの時間がスーパーリッチな松プランより短縮できる。
リグレッションテストの自動化をすることで、デグレードの予防を常に行う。

テストの何をどうかえるのか

開発とQAが別チームというアプローチからチーム自身が品質に対する判断を行う。
すぐに修正／リリースできる欠陥は許容してテストしないことも大切である。ただし、人命に関わる話は別として、である。
ビッグバンテストは、リリース直前に欠陥を検出するので、大きな手戻りを発生させることがある。手戻りを少なくするため、ビッグバンテストではなく、作りこむ毎にテストする方法に変更する。
常に品質改善を意識して開発を行うようにメトリクスを変える。

テストの変えてはいけないこと

テスト計画を作成して役割分担をあいまいにせず、品質リスクの合意をする。
テスト分析を行い、「テストのさじ加減」が出来るように対象を理解し、テストの目的を見失わないようにする。
テスト設計で探索的テストを実施する場合、テストチャータに境界値やデシジョンテーブルを記載する必要がある。そのため、テスト技法の知識を学習し、活動の基礎体力をつけておくことが大切である。

7.まとめ

テストの役割はプロジェクトの状況を映し出す鏡であり、その役割は変わらない。
テストがクリティカルパスにならないようにして、効率的にテストを行う。
テストはコンテキストに合わせて実施する。

筆者感想

現在のソフトウェア開発の動向が伺えて、今後のテスト活動について考えるきっかけとなった。
筆者もソフトウェアテストに従事しているが、アジャイル開発のテスト経験は無く、リグレッションテスト部分で関わってみたいと感じた。
講演のストーリーが、テストとは、プロセスとは、との切り口でとても分かりやすかった。テストは現状を映し出す鏡であるとの表現は綺麗に感じた。

ワークショップ
「ソフトウェア開発におけるHAZOP入門」
小川 清 氏 （名古屋市工業研究所）
柏原 一雄 氏 （デンソークリエイト）

自己紹介

柏原氏は2000年にデンソークリエイト入社し、テストカバレッジ関係、SQIP関係で活動している。
デンソーでPMO等を経験し、現在は車載ソフトウェア開発のミドルウェアのプロジェクトマネージャを行っている。
小川氏はNPO法人TOPPERSプロジェクトの理事、ISO/IEC 15504 co-editor、工学博士・技術士として活動されている。

ワークの目標

HAZOPを3回実施して、利用するときのポイント、現場での利用場面を、体験を通して獲得する。

HAZOP説明

HAZOPとはHazard and Operability Studyの略で、化学工場などで、事故の原因をどのように抑えるかを考えた手法である。
国際標準となっている手法である。特徴はガイドワードを元に発想していく点である。
ガイドワードが抽象的でわかりづらい、時間がかかる、どこまでやればよいかわからない、後から追加されたもの（早、遅、前、後）は使わないなどの誤解があるが、ワークを通して誤解を解いていく。

ワークの内容

3人1組で実施する。個人作業10分、班作業10分、全体報告5分、移動5分、合計30分を1セットで3セット実施する。
3人はそれぞれ利用者、テスター、開発者の観点でワークを行う。3セットの中で役割を変えて実施する。
ワークの注意点は、30点を目指してすすめる。隣の方の30点と合わせると60点になると捉える。
また、班作業において、皆が報告できるように、挙げた項目が少ない人から実施する。

まとめ

内容を箇条書きで記載する。

• 想定外が一件でも気づくことができれば価値がある
• 設計図を使うことで、矢印のあり／なしで想定外を出しやすくなる
• HAZOPのやり方にこだわらない方が良い
• 短い時間で1つでも想定外を見つけることを目標にして活用できる
• 現場に導入する場合は誘導語(ガイドワード)を絞って実施して、良いと判断された場合は全体に広げて使用すると導入しやすい

筆者感想

観点を利用者、テスター、開発者と変えて仕様書を見ることで違う想定が出てくることを体感することが出来て、非常に楽しくワークを行うことができた。
チームの方から出てくる想定外は、自分とは違う発想で出てきており、とても興味深かった。
シンポジウムという場で、見ず知らずの方とワークを行ったが想定外を洗い出すという共通の話題で盛り上がり、親睦を図る方法としてHAZOPを活用出来る可能性を感じた。
自身のチームで想定外を出す必要が発生した際に是非活用したいと思った。

クロージング

JaSST'19 Shikoku実行委員の大羽氏より閉会の挨拶が行われた。
今までは講演＋ワークショップの形で進めているが、他に実施することを現在検討されているとのことで、その際はご協力をお願いしたいとのことであった。

筆者感想

JaSST'19 Shikokuに参加し、講演を聴講して、技術向上したいとモチベーションアップできた。また、ワークショップで参加者と交流を多く持てたことで、充実した時間を過ごすことができた。
今後もJaSSTシンポジウムに参加して技術向上を行っていきたいと思う。