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

はじめに

今年度開催されている各地のJaSSTと同じく、四国も初のオンライン開催となった。四国は例年香川大学で開催される背景から、学生の参加が多い。したがって今回も学生の参加を意識した、初心者向けの2つの講演で構成されていた。
オンライン開催のイベントに参加することの利点として、これまで現地に行かなければ受講できなかった講演を聴くことができる、体調や業務スケジュールによる急遽キャンセルの確率が減る、ということがあると筆者は考えている。今回筆者もオンライン開催の恩恵を受けることとなった。四国に参加することを決めた直後に出張が入り、外出先から移動中に聴講することとなった。

Opening

先述のとおり移動中の聴講となったことで、Zoomの設定に手間取ってしまった。
そのためOpeningから基調講演開始5分程度の聴講を逃してしまった。

講演1
「組込み開発における継続的な自動化の導入 (初心者むけ)」
林 宏昌 氏 （組込みCI研究WG）
喜田 由伎於 氏 （組込みCI研究WG）

組み込み開発におけるシステムテストを対象として、テスト自動化技術の解説とCIの解説を、デモンストレーションを交えて行う講演内容だった。
講演中にもZoomのチャットで質疑応答や参加者同士の意見交換がなされていた。

組込みでのシステムテスト自動化の例

組み込み開発のシステムテストにおける自動テスト環境についての解説があり、テストツールを自作する場合と他社製品を利用する場合とで、それぞれ具体例を交えつつ、課題やコツについての解説があった。
そのうえで、「既存の手動テストをすべて自動化しても意味がない。なにをテストしなきゃいけないのか？本当にこのテストは必要か？を考え、開発プロセス含めて検討することが大事である。」と語られた。

(Q&A)

Q:

自動化のテストの強み・弱みと弱みに対してどのようにアプローチしたらよいか知りたい。

A:

自動テストは、回数を重ねる(回帰テスト)項目を自動化すると効果がある。例えば、開発サイクルで1回しか実行しない項目を自動化しても、ある意味無駄になってしまう。
テスト自動化研究会のHP (https://sites.google.com/site/testautomationresearch/test_automation_principle) で、「テスト自動化の8原則」を公開している。自動化を検討されている方々全員に見てほしい。

Q:

ウェブアプリなどのアプリケーションと較べ、組み込みシステムのテストを自動化する上で大変になるポイントと、それを乗り越えるためにどのような工夫ができるのかを教えてほしい。

A:

ウェブとの違いとして、ハードの制約が大きい。乗り越えるために、ソフトとハードの変換を上手くまとめて考えることができるとよい。

スクリプティングの技法

自動化スクリプトの種類についての解説があった。
5つのスクリプティング技法(リニアスクリプト・構造化スクリプト・共有スクリプト・データ駆動スクリプト・キーワード駆動スクリプト)について、丁寧な図解とご自身の経験を交えながら解説されていた。
その後、組み込み開発のシステムテストを対象としたデータ駆動とキーワード駆動のデモンストレーションが行われた。

CIとは

広義でのCIは、迅速なフィードバックを得るための活動全般である、という定義を示したうえで、組み込み開発におけるCIは、組み込み開発における迅速なフィードバックを得る機会を増やすことで、不具合混入から修正までの時間を短縮し、ソフトウェア全体の品質改善を目指しているという解説が行われた。
その後、CI導入状況やCI導入に対する悩みについて、参加者に呼びかけ、チャットを利用したディスカッションが行われた。
ありがちな課題として、CIを導入するということが目的になってしまうことがあり、そうなると現場に反対されるなどの障壁ができてしまうことが挙がった。その課題に対し、なぜ自分のチームにCIが必要なのか？という目的ベースでCI導入を考えることや周りを巻き込むことが重要である、という回答があった。

HILSを使ったCI

電子制御ユニットECUのテスト装置のうち、システムテストで使われるHILS(Hardware In the Loop Simulation)をCIに組み込んだ事例紹介が行われた。
Jenkinsを用いて、ビルド→ECU(ハード)へのフラッシュ→実車環境でのテスト、という一連の処理を連続で行う事例が紹介された。
これまでは、それぞれの作業ごとに時間が空いてしまっていたが、連続で行えるようになり、待ち時間が減り、実行結果も一覧で見ることが可能になったと語られた。

CI導入時のシステムテスト自動化

ビルドまではCIを使えるが、システムテストまでなかなかいかない。システムテストの自動化までやる必要はあるのか？
この問いかけに対し、自動化する必要性について、講師の実体験を語り、参加者から意見を募った。

講師の体験談としては以下の事項が挙げられた。

• 現場ではシステムテストを軽視していた。自動化なんて物好き、オタクって言われていた。しかし、最近CIを組み合わせたことによってシステムテストの自動化に興味を持ってもらえるようになった。
• 手動テストでバグをみつけると犯罪者・悪者扱いされることがある。自動テストのほうが「ツールが見つけた」ことになるため、和らぐ。

参加者からは以下の声が挙げられた

• 手動で同じテストを繰り返しするのは大変
• 手動テスト実行者の経験や仕様理解度によって一定のテスト品質が維持できないことは結構困る
• 自動だと「人によってテストの判断基準が違う」ということが無いため、テスト結果が確認しやすいと感じる
• (システムが一部変更・修正されたときに)変更・修正点のみの確認にとどまらず、影響範囲を絞り込むのが大変なので、結局全部のテストをやり直すよう求められるケースがある。
• (手動テストでは)手順を同じように再現できていない可能性がある

その他、システムテストを終盤にまとめると手戻りが多くなるため、自動化させてインテグレーションの度にテストできることで安心を得られる、毎回テストができることで、どの機能にバグがあるのか見つけやすい、という解説があった。

講演2
「テストのお悩み相談室 (初心者むけ)」
湯本 剛 氏 (freee)
長島 貴雄 氏 (テクバン)
大羽 正浩 氏 (テクバン)

テストの現場の悩みをテーマとして、登壇者がトークを行い、解決策をアドバイスする講演内容だった。
前半は事前に実行委員・学生・参加者から募った悩みをテーマに、登壇者の体験をもとに解決策をアドバイスした。後半はSli.doを使って参加者に悩みを記載してもらい、投票数の多いものから順にトークを行った。

以下、テーマ(悩み)ごとに、トークの中で語られた解決策を簡潔に記載する。
※筆者の都合により一部テーマについては記録できず

短納期が増えている

短納期だからといって安易にテストを削ればよいわけではない。顧客・開発との合意(どのようなリスクがあって、どこをどの程度テストするかを合意しておくこと)が大切である。

軽微な保守にもかかわらず、回帰テストが不十分なため、問題が出たりする

現状のままだとどんなリスクが有るのかを説明すること、テスト規模の妥当性を互いに確認しあうことが大事。

単体テスト、結合テスト、システムテストに対し、それぞれどの工程で、システムのどの機能を確認して品質を担保するのかが、人によってまちまちになりやすい

マスターテストプランを作成して、初期段階で関係者間で共有する。マスタープランテストがなければ作ってみる。途中参画のときも、マスターテストプランが無いなら後追いでも作ったほうが良い。

再現方法がわからないバグを再現させるのに時間がかかる

市場からの報告バグであれば、再現方法がわからないことで困るのはテスト担当者だけに限らない。組織ぐるみで困っているから、一緒に検討する。または一緒に検討するように上の立場の人に言ってもらう。
ログを残すという手もあるが、すべてのログを残すことに対しては費用対効果が問題視される。ログに頼り過ぎず、自分で解決できることはやる必要がある。再現させるための環境を自動で作れるようにするなど、試行回数を容易に増やせる工夫も必要である。

テスト(テスター・QA)とSEとで、給与に大きな差がある

対等になるようにするためには、テスト以外のことも行っていく必要がある。言われたことだけをやるだけにとどまらず、提案できるような人になっていくことで、周囲にQAの必要性が認識される。
アルバイトの感覚で見られているのであれば、まずは自分の仕事を見直すこと。そして自分の仕事をアピールすること。アピールするためにデータをとり、データで証明する。

上流工程も兼任している開発者が詳細なドキュメントをくれず、入手したドキュメントではザルなテストになる

マスターテストプランの時点で、どんなバグを出したくないのか？を決めておく。
ドキュメントをくれと言うだけでなく、自分で動く。QAがわかっていないことは、他の関係者にもわかっていない。質問シートを作成して提示する。

来年の新人にソフトウェアテストを教えるための教材

JSTQBなどの資格にそった内容で教えている。例えばテストの7原則について、原則を説明するだけでなく、実体験をもとに相手の腹に落ちるような解説を心がける。
座学だけでなく、手を動かすものを用意する。

テスト担当者の担当領域はどこまでのことを指すか？

自分たちで定義する。例えばPMOより自分たちがやったほうがうまくできることは、やっていくほうがよい。お客さんにとっても有益か？を考えたうえで交渉する。

テスト計画書を作成したいのに、いらないと言われ公式に作れない

まずは「あなたはまちがっていない」ということが言いたい。裏でこっそりでもいいから作ると良い。そして必要だと考えてくれる仲間を探す。仲間が現れないならば、社外に出て自分の考えの妥当性を確認する。

Closing

実行委員の大羽氏から閉会の挨拶があった。
初めてのリモート開催だったが、例年より盛り上がった、と喜んでいた。
今回は学生をターゲットにして進めたことと、今回の講演から現場に取り入れられることがあれば嬉しい旨を語り、閉会となった。

筆者感想

講演1については、講演者の実体験に基づいた解説やデモンストレーション・質疑応答や悩み相談などが行われたことで、馴染みやすく具体的に伝わる講演だったと思う。予稿集スライドも学生や初心者を意識して、図解を交えた優しい構成だと思った。また、導入の壁に対して乗り越えることについて、講演者からの熱いエールを感じた。

講演2については、参加者や学生からの生の声に基づく悩み相談であり、参加者もチャットで意見交換していて、とても盛り上がっていた。経験豊富な登壇者からのアドバイスは持ち帰りやすい内容だったと思う。

四国は例年、講演とワークショップがセットになったプログラム構成で、参加者同士の意見交換がしやすい利点がある。今回はオンラインツールの機能を使うことにより、投稿された参加者の声を拾いながら講演が進められたことで、例年の利点がそのまま味わえることになり、非常によかったと思う。
来年はオンライン開催になるのか現地開催になるのかはわからないが、どちらにしても、瀬戸内の地域のみなさまにも、全国各地のみなさまにも、参加を勧めたいと思う。