NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'18 Kyushu
HOME > 活動報告 > イベント報告 > JaSST'18 Kyushu
2018年11月22日(木) 於 長崎県美術館
JaSST Kyushu は毎年開催県を変えている。今年は長崎県長崎市で開催された。前日夜の長崎は雨だったが、当日は晴天に恵まれ、寒さが心地よい。メインテーマは「"実践1Day"同値分割の達人」で、ソフトウェアテストの初学者を対象とし、そのファーストステップとなるソフトウェアテストの基礎技術に焦点を当ててプログラムが作成されていた。
10時50分に、共同実行委員長の福田氏による開会宣言でシンポジウムが始まった。開会宣言の概要は以下の通り。
長崎県からの参加者数が最多で嬉しい。企業としての参加者も増加しており、現場での実践を前提に参加されているのだろう。部門では品質検証部門が最多、役割ではテスト/品質担当が最多である。
次に、長崎県立大学の日下部先生が挨拶された。
長崎県のIT従事者数は減少しているので、学部新設などの施策が実施されている。このようなイベントが長崎で開催されるのは嬉しい。
昼休みを挟んで合計95分間のワークショップが開催された。同値分割＆境界値分析をよりうまく使うために、講義と２回のワークが提供された。以下、その概要を報告する。
同値分割と境界値分析は、様々なソフトウェアのテストに適用できる、 メジャーなテスト設計技法である。テスト設計技法の書籍などでは序盤で取り上げられている基礎的な技法とも言える。しかし、現場で活用するのが簡単とは限らない。ワークで手を動かしながら考えてみよう。
両技法ともブラックボックステストの一種で、仕様を元に分析する。コンポーネントテストからシステム統合テストまで、全てで使える。同値分割はテストケースを合理的に減らし、境界値分析はバグが起こりそうな箇所を狙い撃つ。同値分割した結果を境界値分析に使用するという関係性である。
同じ処理をする値を同値クラスとして扱う。入力値だけでなく、出力値や状態にも使える。手順は以下の通りである。
まずは有効な値のグループ（有効同値クラス）と無効な値のグループ（無効同値クラス）に分割する。それから必要に応じて有効な値を更に分割する。順序関係があるものには、数直線を活用すると良い。重なり、大小関係、途切れていないか、などを知ることができる。大小関係がない場合は、オイラー図などを用いて図を書くと良い。
実際に業務で使う値などが良いだろう。割引券の仕様を例として同値分割して代表値を挙げると、入力しようとすると100項目以上のテストとなるところを合理的に4項目のテストに減らすことができる。
同値分割のテストケースを組み合わせて実施する場合の注意点としては、有効同値クラス同士は組み合わせても良いが、無効同値クラスは単体でテストすること。どのテストケースでエラーになったのかわからないためである。
境界値に基づいてテストケースを設計する。境界を狙うのは、問題が起きやすいからである。配送先（1～7箇所指定可能）の例なら、0と1、7と8の間が境界になる。
もし有効同値クラスの途中を誤って無効にするプログラムが書かれていたら、上記のやり方では気がつかない。その場合、一般的に、同値分割で選んだ代表的な値を追加するか、３つの値を使う（配送先の例なら、0|1,2、6,7|8）。ただし、現場では、コストとのバランスで判断する。コードレビューや、よく使う値を用いて俯瞰テストをおこなうことでカバーすることもある。
ここで参加者に問題用紙が配布され、同値分割と境界値分析に関する3つの問題に10分間挑戦した（内容は非公開）。
この２つの手法は、ソフトウェアテストの書籍では序盤に登場し、例題はシンプルである。しかし実践では難しい。具体的に説明する。
目的が不明確だと、余分なテストをしてしまったり、テスト不足だったりする。テストの目的を確認し理解することが大切である。すでに確認済み、今回の改修範囲外、などでテストすべきスコープが変わる。ズームイン・ズームアウトというキーワードで調べてみて欲しい。
背景によりスコープが変わる。例えば、入力値が「数字」と指定されていた場合。小数点、指数表記、先頭0付きは？などの考慮すべき観点がある。例えば、「毎年2/28に処理する」と書かれていた場合。2月の最終日なのか（閏年の場合は2/29）、28日に意味があり固定日なのか、などを明確にする。
国や地域の観点では海外での使用の有無、時代の観点では郵便番号の桁数（昔のデータを取り込むなら5桁も必要）、用途・種類の観点では体温管理の小数点は1桁？2桁？などが例として挙げられる。
変数の型（java int など）、2038年問題（時刻データ）、バイト数（日本語）、などがある。
上記の問題では、目的を理解することが大切である。仕様が渡されたらすぐにテストケースを考えるのではなく、意図や背景を明確にすることが大切である。また、ユーザーとしての自分の経験（プライベートで使用するサイトでのログインなど）、過去のバグの知識、仲間と共有した知識なども活用する。視野を広げて考えることで、バリエーションが増えるが、ステークホルダと品質に関して合意することが大切である。人命に関わることなどは実施する、など。
テストを実施する活動の前後にも活動があることを知っていただきたい。
ここで２回目のワークを実施した（内容は非公開）。
同値分割を実践することで、仕様のあいまいさをあぶり出せる。１人で勉強しやすい技法なので、ぜひ勉強して欲しい。
講義でも説明されていた通り、同値分割と境界値分析はソフトウェアテストを学ぶ際には序盤に登場するので筆者も知っていたが、講義とワークを通して、とても理解が深まった。そして、一番の気づきは「仕様のあいまいさをあぶり出せる」という観点である。ソフトウェア開発におけるテスト技法の重要性を改めて感じた。
講演の冒頭で、九州出身なので講演することができて嬉しいと語っていた。講演の背景は、コンサルティングや教育を実施し、勉強から実践に移る際に壁を実感するので、この壁を超える手助けをしたいとのことである。
技術者が、テスト設計技法を効果的に活用するためには、仲間と力を合わせ、技術力を高め、テスト対象とテスト要求について学び続けることが大切である。チーム成功のために果たさなければならないテストの役割が見えてくる。すると、選択すべきテスト設計技法がわかる。
テスト設計技法とは、「テストケースを作成・選択するための技法」である。主な構成要素は、モデル化、網羅基準の設定、テストケースの作成、である。テスト設計技法を活用することで、目的に沿ったテストを作成でき、テストベースの理解を助け、テストベースの誤り・不整合を見つけることができる。多種多様な技法を使いこなすことで、様々な場面で技法の恩恵を受けられる。入門に適した書籍があるので読んで欲しい。
テスト設計技法を習得することは、やる気があればできるし、参考となる書籍も多い。しかし、技法の選択（使い所）に壁があると感じる。特にテスト分析からテスト設計に至る部分では、テスト設計技法選択の準備として、テストベースを分析し、テスト条件を識別し、テスト網羅基準とテスト設計技法を選択する。選択判断の例として、クラシフィケーションツリー法を紹介する。この技法は、日本ではまだ馴染みがないが、これから注目されると思う。
テスト設計技法の選択の難しさとして、テストは対象の振る舞いのごく一部しか網羅できない（タイミングや割り込みなど）／テストベースは最後まで不足している／ソフトウェアの本質的な妥当性や品質リスクはわからない（製品が売れないなど）／テストリソースの不足は解消しない（必要なリソースは見積もりにくい）、などがある。その状況で、テスト設計技法の選択が求められている。
テスト設計技法の活用所を見つけ、、技法の力を引き出すには、仲間との協業／技術力向上による実現性改善／進化的改善／テストベースとテスト要求の理解を深めることが大切である。中でも、仲間と協業して求められている品質を理解することは、テスト設計の基礎である。また、テスト設計技法のアンチパターンとして、手段と目的の取り違え、などがある。
最後に、具体例を用いて、テスト設計技法を選択する様子が紹介された。
ソフトウェアテストには様々な技法があり、適切に選択することによって、ソフトウェアテストの幅が広がることが、深く印象に残った。また、冒頭で「講演できて嬉しい」という発言の通り、講演者の熱気を終始感じた。
JaSST Kyushu 実行委員３名が発表した。
本セッションは、「気楽に聞いてくださいね。」という講演者の一言で始まった。講演概要は以下の通り。
アルバイトで社会の先生をしていた。そして今でも、何かの教育を行なうときには、（受講者が主体的に）『学ぼう』という気持ちになるように教育することを忘れてはいけないと考えている。また、教育時には、身振り手振り、たとえ話、経験談を交えて、インパクトを感じてもらうことは効果がある。
プロジェクトの規模が大きくなると新しく加わる人達への教育は座学中心になる。マンガは学習と相性が良いので、テストのマインド、バグ票の書き方、などをマンガにし、効果を実感した。自己学習のファーストステップとして良いと思う。
開発者３０人に対してテストチームは最近２人に増えたがまだ少なく、いろんな案件を同時に対応している。あるシステムのテストでは、バグにより連携側のシステムが壊れるのでしっかりテストしないといけない。データを入力してボタンを押す部分のテストで、「○○の文字列が通らないことを確認する」に対して、同値分割を試みたが、テストケースを削減することが難しかった。
テストの実施を自動化したいが、全部自動化するのは大変なので、値を入力して、ボタンクリックし、結果画面のスクリーンショットを撮るまでを自動化し、確認は手動にする。Cypressというツールを用いると、入力やスクリーンショット撮影が簡単にできる。軽くて良いツールなので、みんな使いましょう。
プチ ReverseVSTeP を実践した。社内のテストを良くしたいという思いで活動してきた。苦労したが、テスト要求分析に着目して改善することで少し良くなってきた。
まず、既存のテスト項目を図にして、テスト観点として整理する。なぜテストをしたいのかを考え、テスト観点に足りないものを追加する。同様の観点をまとめる。この活動を通して、開発者と「必要なテスト」の認識合わせができるようになった。
実行委員３名の発表を聞き、ソフトウェアテストに真剣に向きあい、楽しんでいる印象を持った。また、岡崎氏は、JaSST Kyushu（JaSST'13 Kyushu） での西氏の発表を聞き、VSTeP を使い始めたそうだ。JaSST による好循環を実感した。
冒頭の自己紹介では、長崎出身であり、この場で発表できて嬉しいと語った。また、今回の講演資料を用いて、みなさんの現場で勉強会を実施して欲しいと語った。
よりよいテストのためには、テスト技術以外に、システムの対象分野の専門知識や、開発の専門技術・知識が必要であるが、この講演では、それらを支える「テストの基礎」について語る。
「長崎の童歌に関するアプリ」があるとしよう。それをテストする場合、闇雲にテストを作るのではなく、テスト作成のための地図と道具を持ってテストに臨むことが大切である。例えば、地図がないとアメリカにいけないし、将棋は歩という道具だけでは勝てない。だから、基礎は大切である。
バグの影響は大きい。お客様の立場では、買った製品にバグがあると不快な気分になり、不信感を持つ。その企業の他の製品も買わないなどの悪影響がある。メーカーの立場では、バグのために損害が発生し、企業ブランドにも悪影響がある。そのバグをテストで防ぐことができる。バグというモンスターから守ることができる。
設計のための思考と、テストのための思考がある。設計時は収束させていくが、テスト時は発散させる。テスト時は仕様書に記載されていることよりも、むしろ仕様の外側が大切である。仕様書に書かれていないことも思いつかなければいけない。設計時からテスト時には、思考を切り替える必要がある（帽子の被り直し）。
テストケースを作る際、仕様の語尾に「～ことを確認」を足して作っているなら、それは単なるチェックである。仕様書に書かれていないことも発想することが大切である。その際、マインドマップを使ってみると良い。思考に沿って書くので、思考の流れが見える。説明が苦手な新人などがマインドマップを使うことで、指導者は思考の流れを見てアドバイスすることができる。また、分析と設計は一緒に考えた方が良いので、両方をマインドマップ上で行うと効果的である。
５つの軸を紹介する。「プロセス」では、Ｖ字モデルを例として、テストは実行だけではないこと、「マネジメント」では、SQuBOKガイドを例として、進捗管理だけがマネジメントではないこと、「設計技法（テスト観点ベース）」では、ASTER主催テスト設計コンテストが参考になること、「設計技法（テスト技法）」では、多くのテスト技法があり、JaSST'12 Tokyo で作ったテスト技法ポジショニングマップが参考になること、「ツール」では、「テストツールまるわかりガイド」を例とし、テスト実行ツールだけがテストツールではないこと、を知っていただきたい。
まず書籍を読もう、次にWebの記事を読もう、そして現場で実践し復習しよう、コミュニティに参加しよう、シンポジウム・ワークショップに参加しよう、これまでの知識を整理しよう、現場に展開しよう、そして勉強会やシンポジウム・カンファレンスで発表しよう！とお伝えしたい。
会場にお越しのマネージャの方々は、ぜひ部下を社外のイベントに送り出して欲しい。また、現場で勉強会をすると、技術者の仕事に対する意欲が変わるので、勉強会の実施をお勧めする。
池田氏は、地元での講演ということで張り切りすぎ、なんと107枚のスライドを準備してしまったそうだ。「キホンのキ」がテーマの通り、ソフトウェアテストの技術を探究しスキルを高めることの面白さを感じた。胸が熱くなった。
共同実行委員長の松谷氏による閉会宣言。長崎県美術館での開催はいかがだったか。そして「本日学んだことを会社で使ってみたい人は？」という会場への問いに、挙手が多かった。
毎年開催県を変えるというJaSST Kyushu の運営方式は、各県のIT技術者に刺激をもたらしていると感じた。地元の参加者が最多という事実は素晴らしい。そしてイベントの内容に感動した。講演した方々、そして実行委員の、ソフトウェアテストへの愛を感じた一日だった。
記：和田 憲明（ASTER）