「ソフトウェアテストの7原則」についての社内勉強会を実施しました

はじめに

Graatでは、昨年10月から社員のスキルアップを目的とした「Graat勉強会」が、月一ペースで実施されています。
5月23日の勉強会のテーマは「ソフトウェアテストの7原則」でした。

ソフトウェアテストの7原則とは、ISTQB（JSTQB）で記載されている、あらゆるテストで共通に使える一般的なガイドラインです（詳しくは、ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03 をご覧ください）。

前半、 @nihonbuson さんの 業務でも活用できるソフトウェアテストの7原則/Seven_Testing_Principlesを全員で読み合わせた上で、後半、ソフトウェアテストの7原則について参加者から挙げられたトピックをリーンコーヒー（Lean Coffee）形式でディスカッションしました。
雰囲気を掴んでいただくため、今回はディスカッションの様子を一部ご紹介します。

ディスカッションの様子

原則3. 早期テストで時間とコストを節約

参加者から、「設計の妥当性をチームでレビューするのも早期テストにあたるのか？」という問いかけがあり、JSTQBではレビューがテスト活動の一環だと定義されているという紹介がありました。
さらに、チームに人がいない場合はどうレビューを実施するか？ とディスカッションが発展し、プロジェクトとは無関係の後輩に作業のながら聞きで良いので自分の設計内容を聞いてもらうという手法(ラバーダッグ・デバッグ)を実践した経験が紹介されていました。

原則5. 殺虫剤のパラドックスにご用心

同じ殺虫剤を使い続ける（同じテストやテストデータを実施）のもダメですが、闇雲に殺虫剤を増やすだけでは、やることが際限なく増えてしまうジレンマ(「新しいパターンのバグがみつかると、そのパターンを常にやらねばー、ってなってチェックリスト地獄が発生する」)が参加者から挙げられ、多くの共感が寄せられました。
上記のジレンマを解消するため、定期的にテスト内容を断捨離したり、効果的なテストを導入するために発生したバグに対してなぜなぜ分析を実施しているというチームの例が紹介されました。

原則7. 「バグゼロ」の落とし穴

多くのソフトウェア開発プロジェクトで、いまだに「バグゼロ」が基準になりがちな理由についての話し合いになりました。
ビジネス側が「バグゼロ」を要求しているのではなく、実は（外部品質でのみ評価されがちな）システム側がビジネス側に「バグゼロ」を提示しているからではないか、という意見があがりました。
また、「テスト」の定義がビジネステストのイメージではなく、システムテストのイメージのみで語られているからでは、という意見も含めた様々な意見が挙がり、ディスカッションは白熱しました。
最後には、「システム開発側の人が、原則の1つでも理解できないなら外れてもらったほうがいいと思う」という過激（？）な意見も飛び出していました（笑）。

感想

個人的には、毎回思うことですが、誰かが質問を投げかけると、必ず誰かかから実践経験や解決のヒントが返ってくるのがすごいと感じます。
アーキテクトである代表の鈴木を始め、フロントエンドエンジニア、DevOpsエンジニア、テスト系コミュニティの運営者、アジャイルコーチなど様々な職種の方がいるGraatならではだと思います。

勉強会のアンケート結果

おわりに

今回は、「ソフトウェアテストの7原則」についての社内勉強会のディスカッションの様子を一部ご紹介しました。
Graatでは、アーキテクト、フロントエンドエンジニア、DevOpsエンジニア、、アジャイルコーチなどが多彩なコラボレーションしながらエンタープライズ大企業のDXを目指しており、様々な職種を募集しています!!
もしご興味あれば、お気軽に採用ページを覗いてみてください
最後までお読みいただき、ありがとうございます!