NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'21 Tokai
HOME > 活動報告 > イベント報告 > JaSST'21 Tokai
2021年12月3日(金) 於 オンライン開催
第13回JaSST Tokaiがオンライン開催された。実行委員を含め、約150名もの参加者が集った。
実行委員長の矢野氏より、今年のテーマである「みんなでやろう！ ソフトウェアファースト時代のテストの在り方」の紹介と、軽快でシュールなジョークが交わされた。
途中、「実行委員長挨拶では場が温まらない」と自虐を挟みつつも、参加者が月曜から頑張れるようにしたいと締めくくった。
近年、ユーザーの求める製品をいち早く市場へ投入することが求められており、ウォーターフォールからアジャイルに主流が切り替わりつつある。この変化に伴い、品質に対してどうしたいのかというフレームワークと、その具体的な作業指針が求められている。これに対しては、テスト担当者と開発者で協力し、取り組みを考える必要がある。実際の現場ではリファクタリングへの取り組みが不足し、コードが汚く・長く・複雑になり、市場バグの流出原因となっている。
そこで、本講演では以下の2つを主題として掲げた。
本講演での品質の定義を「有限な時間の中で、最適な品質を探す」とした。その切り口として上流で効率的なテストを行う、(クリティカルなバグの検出を目的としない)膨大なシステムテストは無意味とした。前者はバグを予防する視点を含み、単体テストで担保しているか、ユーザーが求めているソフトウェアかどうか事前に妥当性確認されているかなどをあげた。後者は、バグを狙えない・実行速度の遅いような組み合わせテストは注意が必要だと促した。
上流品質を担保するために最低限すべき活動として、単体テスト、リファクタリング、要件仕様のテストケース展開の3点を紹介した。
コードカバレッジの網羅率に適切な値はないとしつつも、目安としてエラーハンドリング処理以外を網羅できる75%がよいと話した。これはテスト担当者が原因を分析する際のしやすさ、単体テストが正しく書けているか判断する一つの基準でもある。上記の対応が難しいレガシーコードでは、「2:8の法則」や着手した時より少しだけ網羅率をあげるとよい。「2:8の法則」とは、コードの2割の箇所に対して単体テストを記述し、8割以上のバグを狙う活動である。2割の重要な箇所の特定方法として「よく変更されるファイル(Hotspot)」「長いファイル」「複雑度が高いファイル」は統計的にバグが多発するとした。
リファクタリングの対象選びでも「2:8の法則」を適用できる。Hotspot値・複雑度共に高いものを対象にすると効果的である。また、FPあたりの労働時間の増加や複雑なコードのバグ修正成功確率などのデータを、開発者やマネージャーに示すことで、リファクタリングの納得感を得られるとした。
システムテストレベルでバグを検出するのではなく、レビューの段階で見つけられるものは見つけたい。その手段を紹介した。
要件仕様の漏れを防止するため、要件仕様とテストケースのトレーサビリティは必要である。たとえアジャイル開発であっても、開発者は要件仕様を文書化することを推奨する。これによりテスト担当者のシステム理解度が上がると共に、レビューにより要件仕様への正確性を積み上げることができる。要件定義を明確に行わないことで不具合は2.7倍になるというデータが紹介された。
テスト担当者の品質のフレームワークの考え方について説明した。
ウォーターフォールではテストレベルを重ねることで、単体のバグであっても後工程で検出することができた。一方、アジャイルではテスト担当者はイテレーション内で各テストタイプを担保する方法を考えなければならない。それだけではなくシステム全体を理解したうえで、どの部分の品質が低く、どこがテストできないのか、しなくてよいのかの特定も必要である。例えば、Race Condition（スレッドセーフ)などテスト実行の難しい箇所に対して明確にし、開発者へのレビュー実施の確認をする必要がある。
続いて、自動化の取り組みをする際には、イテレーション内のスピード感に耐えられるか確認しなければならない。特にシステムテストレベルの自動テストは実行時間やメンテナンスコストがかかる点に気をつけなければならない。非機能系の要求も含めたすべてのテストは夜に開始し朝に終わることが好ましい。これにより翌日に開発者は安心して開発できるようになる。CI/CDを回したタイミングで出力される定量的な品質指標を確認し、コードの網羅率を管理することもテスト担当者の役割の一つである。
最後にNext Stepとして、新規に書く関数だけでも単体テストを書いてCI/CDフレームワークにいれること、品質分析をすることから取り組み始めるとよいと締めくくった。
穏やかな語り口調で、身振り手振りを交えられており、聴衆を引き込むようなライブ感が印象的であった。
本講演ではテスト担当者として、開発者や単体テストとの関わり方について沢山のヒントが散りばめられており、システム全体やビルドパイプラインに関与する必要性も強く感じた。テスト担当者に対してそっと背中を押してくれる、素晴らしい講演であった。筆者も限られた時間の中で効果の高い活動ができているか、定期的にふりかえっていきたい。
筆者はテスト本をエンジニアに興味を持ってもらえるか不安になっていたが、長友氏のエンジニアが一番テスト結果を気にされているかも、との話を聞いてハッとさせられた。同じ知識を共有すると、話しやすい環境が生まれるということで、読書会の開催は思っていたよりも敷居は低く、やり得であることに気づかされた。
プロジェクトの開始時にQCDのトレードオフスライダーを作ると、優先度決めが早くなりプロジェクトを進めやすくなる。例として優先度D>Q>Cのお行儀の悪いテストを紹介した。実はテストケースがテンプレート展開されていることにより、お行儀のよいテストケースよりカバレッジは高いと話した。
テスト活動への様々な状況に対して柔軟に対応する姿勢や、テンプレート化により設計を早くする方法は参考にしたい。
組織のプロセス改善をする第一歩として、JSTQBのAutomotive SPICEをすすめた。シラバスでは各プロセスの中で何をするとよいのか書いてあり、テストのアーキテクチャを組み立てる際の全体感の参考になると話した。プロセスのアセスメントを参考にすると共に、本事例のような上流でバグの作りこみをなくす活動が広がってほしい。
テスト管理ツールを利用して、開発プロセスとテストプロセスを融合させて、製品・サービスの品質に対して、地図・テストの戦術を作り共有する活動をしたいと語った。最後に、井関市のTestLinkの情報共有とテストの街「葛飾」の紹介があった。テスト管理ツールを起点とした、テスト活動の幅広さを感じた。
エンジニアを5年経験したのち、QAを15年以上経験されている。日系電気メーカー、外資系ECサイトを経て、2019年から渡米してAmazonに在籍している。現在アメリカの西海岸に住んでいる。
製品開発の体制(役割)はSoftware Development Engineer(SWE) / Quality Assurance Engineer(QAE) / Software Development Engineer in Test (SET, SDET) / Technical Project Manager(TPM) / Product Manager(PM)であり、TPM はスケジュール・課題管理などの、プロジェクトを推進する人である。その上の役割として人に関わる仕事の割り振りをするPeople Managerがいて、更に上にはProgram Managerがいる。
QAEに関する組織としては、以下3つがある。
評価軸は日本と異なるのではないかと語った。
最後に伝えたいこととして、以下について語った。
植月氏は本講演のトピックを事前にSNS上でやり取りをされていたことや、当日の質問の多さから日本との違いについて興味の高さを感じる講演だった。
QAE1名で期待される役割すべてをこなすことは難しいと話されたとおり、厳しい制約の中でどこにフォーカスするのか考えられていることがひしひしと伝わってきた。そのような環境でQAアーキテクチャやパイプライン設計を含めたすべての活動はとても洗練されたものとなるだろう。そのためか無駄なテストは省き、自動化100%の対象は単体テストもE2Eも目指すとの刺激的な発言もあった。
今回いただいた刺激をもとに、同じQAとして担当領域を広げると共に、洗練された活動を目指していきたい。
テストアーキテクティングへの工夫が年々求められるようになり、その背景は2点ある。1点目は、DevOpsでデプロイメントパイプラインを洗練させる例をあげ、様々なフェーズでのテスト活動を高度に連携させ、開発全体で優れた価値創造やアジリティを実現する開発スタイルが求められているためと説明。2点目は、イテレーションごとのテストの断片に対して、全体の品質保証として整合性を確保し、プロダクト品質を継続的に担保することが求められるためである。そのような状況においてプロジェクト全体のテストアーキテクチャに求められる役割は次のものがあげられる。テストが妥当であることがわかり、個々のテスト活動のみでは対応できない困難な問題や流動的な要求への対応ができ、メンバーが自律的に関与できることである。
テストアーキテクチャに対する要求はステークホルダーやプロジェクトフェーズ・テスト活動のフィードバックをうけて刻々と変化する。そのような状況に対応できるように、テストアーキテクチャの観点として構成要素・構造・環境・連携の4つに注目し、アーキテクティングの進め方として大きく分けて要求の分析・設計・評価と改善について語った。
最後にワークを通して、GSN（責務構造ツリー)の記述とパイプラインモデルのシナリオ評価を行い、参加者の理解を深めた。
初心者に寄り添うように、とても丁寧な構成と沢山の言葉を尽くして、テストアーキテクチャについて説明いただいた。いくつかの用語の定義を理解することで、テストアーキテクチャの姿や、開発ライフサイクルへの関連など、筆者自身の理解の広がりを実感した。
本講演を通して、テストアーキテクチャがアジャイル開発や小さいプロジェクトにも有効なこと、テスト対象やテスト活動だけでなくテスト担当者の自律性やスキルアップにも触れていたことなど、役割の大きさを感じた。また、高橋氏の講演ではリファクタリングの重要性が語られたことを踏まえ、テスト担当者としてテストを適切に育てる仕組みを作れていないことを感じた。
沢山の学びを得た結果として筆者自身何がわからないか、わからないという、ずいぶん遠い所まで来てしまった。まずは手を動かして一つ一つトピックを理解していきたい。チームとして品質をどうしていきたいのか、強く意識し、話しあえていなければよいテストアーキテクチャは構築できないと感じた。
セッション5の各SIGとワークショップの発表者から、セッションで盛り上がった内容の報告が行われた。
最後に実行委員長の矢野氏より来年も頑張っていきたいと、プログラム終了の挨拶で締めくくった。
筆者はテスト担当者として、システム全体の品質やビルドパイプラインに携わりたいと考えていた矢先だったため、沢山のヒントをくれた今回の企画に感謝してもしきれない。
すべての講演のメッセージとして共通していたことは、テスト担当者として頭を使い、活動の幅を広げなければならないということだ。User, Biz, Devの要求を把握したうえで、製品全体の品質を把握し、テスト戦略・アーキテクチャを通して、パイプラインや自動テストを構築する。更に、短い期間での製品リリースに追従するために、活動の優劣を判断できなければならない。また、継続的な活動をするために、チームとして成長できる環境でなければならない。
考えることが多く、とても頭を使う時間だったが、最後はあっと言う間に終わってしまった。
月曜から頑張ろうという気持ちになった。
記：平田 将乙