はじめに
ちょっとだけ僕の経歴をお話させてください。
現在ソフトウェアエンジニア3年目の福土です。
前職では受託✖️オフショア開発をしており、発注元の会社のPMやテックリードの方が決めた要件をもとにフィリピンのエンジニアと開発を行っておりました。
その時
- 自分の作ったプロダクトが誰に使われているのか？
- どんな価値が提供できているのか？
- どれくらい会社への利益貢献ができているのか？
が見えずこのまま見えないコスト構造とお客様の顔と向き合いながらエンジニアを続けるわけにはいかない！と思い、ログラスに転職しました。
この時の僕のテストレベルは0、、、
『ポケットモンスター 赤・緑』でいうところのマサラタウンでポケモン持たずに草むらに飛び込んでオーキド博士に「あぶない とこだった！」と言われる状態
かろうじてユニットテストとインテグレーションテストの違いはわかる程度で、品質保証のためにはテストのカバレッジを上げればあげるほど良いという、なんとも頭お花畑くんでした。
その状態から転職し、社内のエンジニアがシフトレフトの声をあげて品質向上に努める開発組織というログラスという環境に飛び込みました。
そんな環境の中、社内Slackにて「WACATE2024 冬」というイベントが開催されるという共有がされ、ソフトウェアテストのイロハもわかっていなかったため意を決して1泊2日のソフトウェアテストワークショップに挑戦しました。
WACATEとは？
WACATEとは"Workshop for Accelerating CApable Testing Engineers"の略でテストに興味のある若手に向けて学びや横のつながりを促進するワークショップです。
年に2回開催されており、夏は1つのトピックを深掘り冬はさまざまなトピックを幅広く学ぶ場となっています。
参加してみて、初参加の方やQAエンジニア1,2年の方が多くソフトウェアテストについて知見が少なくても十分学びがあり、また積極的な発言や交流が行える安心感のある場であると感じました。
参加して学んだ3つのこと
今回WACATEに参加して学んだことは3つです
- 品質保証はQAだけが取り組むものではない
- コスパが悪い全数テストはやらなくて良い
- リスクには重みづけができる
1つずつ紹介します。
品質保証はQAだけが取り組むものではない
ソフトウェアテストのワークショップということで、品質保証は誰の責務か？といった講習を受けました。
そもそもの品質とは？ですがWikipediaを引用するとISOでは以下のように定義されています。
対象に本来備わっている特性の集まりが，要求事項を満たす程度
私の前職のような受託企業の場合、この要求事項は発注元の企業様のPMやテックリードエンジニアの方の定義した受入基準にあたります。
一方の自社サービス企業の場合、要求事項はサービスを利用しているお客様の要求になります。
この品質保証について、日本では以下の順序で品質への向き合い方が変わったと登壇者のブロッコリーさんからお話がありました。
- 検査重点主義
- 工程管理重点主義
- 新製品開発重点主義
それぞれについて簡単にまとめます。
検査重点主義
こちらは検査を重点的に行うというもので、製品を作るための生産部門に対して「誰かが悪いことをするかもしれない」という性悪説に基づいて、検査部門を設けて製品の品質を担保しようというものです。
厳しく管理することが品質担保に繋がり、品質を担保する部門が明確に分かれています。
工程管理重点主義
最後を検査すれば良いという検査重点主義とは異なり、工程管理重点主義では工程によって製品を全て良品にしょうというものです。
ワークショップの場では「品質は工程で作り込め」という言葉が引用されていました。
3現主義が提起され、3つの「現」である
- 現場に行って
- 現物を見ながら
- 現実を語ろう
によって作業員だけではなくトップも巻き込み品質保証を努めていたようです。
新製品開発重点主義
これまでは生産過程を管理して品質保証をしようというものでしたが、ここで生産前から品質解析を行おうという考えが広がったようです。
この時、作る過程のみならずどのようなものを作るのかという設計フェーズや製品が届いてからのアフターサービスも含めて品質保証を行うようになります。
講習では「品質は設計と工程で作り込め」という言葉が引用されていました。
そして最近のソフトウェアテストでは以下の観点が重要になってきているようです。
品質の第一義は顧客満足であり、品質の保証で言えば第一に顧客に受け入れられる必要がある
以下のブロッコリーさんのTesting Manifestoの翻訳記事にも書いている、テストマニフェストの2つ目の原則である
バグの発見 よりも バグの防止
が重要とされ、検査という評価によってのみ品質保証をするのではなく予防に主眼を置くようです。
ここまでの説明を受け、テストがあくまで受け入れテストの位置付けであるといった検査の側面やコードの保守性を上げる位置付けにあると考えていた自分にとって「顧客に価値を届ける」ことこそ品質保証で向き合う課題で、誰かが決めたテスト項目を手動テストすることだけが品質保証と考えるのではスコープのあまりに小さい取り組みなのだと気づきました。
また、品質保証はQAや開発者だけが向き合う課題ではなく、そのサービスを提供する誰もがお客様の要求を満たすための設計に関心を持ち関与することが大事だと思いました。
コスパが悪い全数テストはやらなくて良い
テストといえばカバレッジが大切で、いかにテスト項目の網羅性を高めるかにフォーカスしてこれまでテストを書いてきていました。
しかし利益を生み出す企業に属する1エンジニアとしてはコスト感覚を適切に身につけなくてはいけません。
今回のセミナーに参加して気づいたのはテストケースが減らせるということです。
経済学の用語に収穫逓減の法則というものがありますがこれはテストにも言えることで、ある程度のカバレッジを満たすために取り組むことは容易だがそれ以上は取り組む量に対して恩恵はどんどん逓減していきます。
この課題に向き合うために取り上げられていたテスト技法の1つが２因子間網羅です。
因子が複数ある場合に全ての因子間の水準を組み合わせる方法では、テストケースが爆発的に増えてしまいます。
2因子間網羅の例
例えば3因子が全て4つの水準を有するとします。
その場合、4^3で64通りの組み合わせがあります。
この組み合わせ全てでテストを行うことは大変です。
そこで2因子間網羅によってテストを行います。
2因子間網羅を使った場合2つの因子間での網羅率は100%とし、3因子以上の因子間の網羅は厳密に行いません。
これは以下記事でも言及がありますが2因子の組み合わせによって約8割から9割の欠陥が見つかるからです。
例えばジャケットを例として3因子存在するテスト対象に対して2因子間網羅を用いた場合以下のような組み合わせになります。
| サイズ | 色 | 素材 |
|---|---|---|
| S | 赤 | 綿 |
| M | 青 | ポリエステル |
| L | 黒 | 毛皮 |
| XL | 白 | デニム |
| S | 青 | デニム |
| M | 黒 | 綿 |
| L | 白 | ポリエステル |
| XL | 赤 | 毛皮 |
| S | 黒 | 毛皮 |
| M | 白 | デニム |
| L | 赤 | 綿 |
| XL | 青 | ポリエステル |
| S | 白 | ポリエステル |
| M | 赤 | 毛皮 |
| L | 青 | デニム |
| XL | 黒 | 綿 |
上記の表を見るとサイズという因子から見て色と素材はそれぞれの組み合わせが全て存在することがわかるかと思います。
このように2因子間の組み合わせにおいての網羅率は100%とすることを2因子間網羅と呼びます。
これによって64通りあったテストケースが12通りにまで減少し、テストのコスパをよくすることができます。
2因子間網羅の講習を通じて、テストを行う対象への仕様やコードレベルでの理解をする必要があり、その対象に適したテスト技法を選べるスキルが問われる、それができてこそコスト観点も意識したテストが行えると学びました。
他にも様々なテスト技法を学ばねばな、と感じた次第です。
リスクには重みづけができる
リスク分析の工程には
- リスク識別
- リスクアセスメント
があるというお話の中ではリスクに優先順位をつけられるということを学びました。
時間が十分にあり開発の時間もたくさんある場合にはリスクは全て検証できるかもしれません。
ただし実際は、限られたリソースの中で顧客に価値を届ける必要があります。
その時に必要なのがリスクアセスメントです。
リスクアセスメントではリスクの優先順位づけをするために2つの観点の積をとって考えます。
リスク影響度
リスク影響度では、そのリスクによって引き起こされる損害の大きさを数字で重みづけします。
例えば決済システムを開発している場合、決済トランザクションのデータ漏えいといったリスクは発生するとユーザーの信頼を失うだけではなく法的な罰則や罰金を課される可能性があり非常に影響度の大きなリスクと考えられます。
一方でシステムのレイアウトが崩れて決済を行いづらいといった場合は先ほどのリスクと比べて影響度は小さいといえます。
リスク可能性
リスク可能性では、そのリスクが実際に発生するかもしれない推定確率です。
例えばシステムのトップページで発生してしまう事象であればログインしたユーザーの全てが遭遇することが考えられるため、リスク可能性は高いといえます。
一方でシステムのメインユースケースに含まれない箇所で発生するリスクは、発生する確率が低いと言えるためリスク可能性は低いということができます。
これら影響度と可能性の観点からリスクに重みづけを行いそのリスクに沿ったテスト技法を選んでテストを行うことをリスクベースドテストと呼びます。
ワークショップでは影響度と可能性を4段階で評価していきましたが、この段階は3~5段階と可変であるようです。
| 機能名 | リスク影響度 | リスク可能性 | リスク優先度 |
|---|---|---|---|
| 決済トランザクション | 4 | 4 | 16 |
| トップ画面 | 1 | 3 | 3 |
| 返金機能 | 4 | 2 | 8 |
品質リスクに重みづけを行うことで、リソースが限られたプロジェクトだとリスクの高いテストケースは必ずパスしてからリリースを行い、リスクの低いテストケースでは必ずしもテストをパスさせる必要はなくても良いといった意思決定を行うことができます。
これによって顧客への価値提供が早まり、いち早く顧客からのフィードバックを得られると共に最低限の品質を担保することが可能となります。
まとめ
上記のような学びはまだまだ一部で、その他にもソフトウェアワークショップなのにユーザビリティの講習があったり、アクセシビリティについて語り合ったり、他社の品質担保の取り組みを知れたりといった非常に有意義な時間となりました。
"品質保証をするのは"みんなの責任と考えるとピンと来ませんが、"顧客価値を届けるのは"と言い換えるとしっくりきます。
詳しい人には間違っていると言われるかも知れませんが、詰まるところ品質保証とは顧客に価値が届けられるか設計段階から向き合うことであり、その意味においては私のような1開発エンジニアであっても作るだけではなく届けることを主眼にプロダクト開発に向き合うことが大切であると改めて認識することとなったソフトウェアワークショップでした。
WACATEの主催に携わってくださった皆様、本業お忙しい中ワークショップを企画し実施していただきありがとうございました！
株式会社ログラスは「良い景気を作ろう。」をミッションに、企業経営を推進する次世代型経営管理クラウド「Loglass 経営管理」を開発し提供しています。
Discussion