ビットキーで初めて触れたテスト技法とその活用

この記事は株式会社ビットキー Advent Calendar 2023 14日目の記事です。
今回は2023年3月に株式会社ビットキーに入社しました、Software QA Build所属の@takumi_sakaoが担当します。

自己紹介

簡単に自己紹介させてください。
2023年12月現在、3年目のテストエンジニアの坂尾卓海です。
エンジニア経験として、サーバー構築の自動化を推進するインフラ開発に1年半ほど従事した後、テスト領域へ進出し第三者検証としてテストエンジニアのキャリアを歩んでいます。
現在は、株式会社ビットキーで自社プロダクトのテスト分析〜テスト完了まで担当しております。テスト業務の経験としては、1年半ほどの新人です！

はじめに

Software QA Buildはビットキーで立ち上げから1年ちょっとの新しいチームです！
その新しいチームの中で、筆者がどのようにテスト技法を活用しているのか、またテスト技法をどのように学んできたのかをこちらで紹介していきます。

テスト技法とは

テスト技法とは、ソフトウェアテストのテストケースを作成するための技法です。
テスト技法には、同値分割法、境界値分析、デシジョンテーブルテストなど、さまざまなテスト技法が存在します。テスト技法を活用することで、テストケースの抜け漏れを防いだり、効率よくテストケースを作成することができます。

一言で「テスト」と言っても、やるべきことは多岐に渡ります。
検証対象の機能が複雑であればあるほどテストすべきことは多く、テスト実行が猥雑になることがあります。また、機能が単純であったとしてもテスト実行が単純になる訳ではありません。開発されたプロダクトが市場に出る時期も決まっており、テスト活動には常に期限があります。
そこで検証すべき観点の漏れがない、かつ効率よく検証するための方法として、テスト技法が存在します。

テスト技法の活用

テストプロセス(ビットキーの場合)

本題に入る前にビットキーのテストプロセスについて説明します。
ビットキーでは主に２週間を1スプリントとして、1週間でテストの準備、残り1週間でテストの実行というサイクルでテスト活動を行っています。新規の機能追加や不具合修正などはJIRAチケットで管理しており、チケットごとにテスト分析〜テスト完了まで実施しています。

スプリントが開始する前には、テスト計画を行い現状のリソースを鑑みて検証ボリュームを開発と調整しています。
テストの準備では、テスト分析〜実装までを行なっています。主に2日ほどでテスト分析を実施し、残り3日でテスト設計と実装を行なっています。
テストの実行では、テスト実行〜完了まで行なっています。テスト実行は２〜3日で確認テストを実施し、残り2日でリグレッションテストを行っています。検証が完了したのちテスト完了報告を実施しています。

カレンダーで表現すると以下のようなスケジュールです！

テスト技法の選定

ビットキーでテスト設計を行う際は、主にデシジョンテーブルテストを活用しています。
デシジョンテーブルテストは、様々な条件で挙動が変化するソフトウェアの機能に対して、すべての組み合わせを漏れなくテストする際に有効なテスト技法です。条件の組み合わせが視覚的に分かりやすく、組み合わせの考慮漏れを防ぐことができます。

弊社プロダクトはソフトウェアの機能が複雑であり、様々な条件によって挙動が変化します。複雑な機能に対しては、複数の観点が絡み合い単純なテストでは網羅することができません。そのため、すべての組み合わせを網羅でき、観点の漏れを防ぐことができるデシジョンテーブルテストを選定しています。

筆者は、ビットキー入社後に初めてデシジョンテーブルテストに触れて、OJTでデシジョンテーブルテストを学んできました。デシジョンテーブルテストに触れた当初は、観点の洗い出しや網羅性に欠ける部分があったものの、今では抜け漏れなく観点の洗い出しができるようになってきています。
テスト観点を抽出する場合には、同値分割法や境界値分析を使用しておりデシジョンテーブルテストと組み合わせてテスト活動を行っています。

テスト活動の例として弊社プロダクトの「workhub」を参考にします。

workhubには会議室やワークブースを予約するという機能があります。
この予約機能をテストする際に、必要な観点として以下のようなものがあります！

• 誰が予約するのか（法人・個人・ゲストetc）
• どこを予約するのか（会議室・ワークブース・ロッカーetc）
• いつ予約するのか（当日、未来日）
• 利用時間はどのくらいか（30分、1時間、10時間）
• 何人予約するのか（1人、5人、10人）
• 予約導線はどこからか(admin・pass・App)
• 重複予約の可否はどうか
• 予約の履歴は正しいか

また、ユースケースを考えた際の予約に関連した観点として以下のようなものがあります。

• 支払方法は何か（請求書払い・クレジットカード払い・口座振替）
• 課金方法は何か（従量都度・従量定期・フリーパス）
• 予約による請求は正しいか
• 予約時間に合わせて正しくドアの開錠ができるのか
• 予約に伴う解錠権限は正しいか
• 解錠方法は何か（顔認証・パスコード・QRコード・NFCカード）
• 予約に伴う受付の有無
• 予約に伴う共用部の通過は可能か

予約機能といっても様々な要素が絡み合っており、テストすべき要素やその組み合わせなどの観点を洗い出します。
毎回全ての要素を組み込んでテストを実施している訳ではありませんが、導入予定の機能や修正内容を担保できるような観点を組み込んだ検証が必要になります。
全てを網羅したテストは現実的に難しいため、ここでテスト技法を用いて観点の漏れがないように、かつ効率よくテスト活動を実施しています。

デシジョンテーブルテストのポイント

デシジョンテーブルテストを使用する場合、抽出した観点を因子と水準に分類分けしています。

因子：検証すべき観点のメイン要素
水準：因子に紐づく要素の内訳

上記「wrokhub」の予約機能を検証する観点で考えると…

誰が予約するのか　　　→　　アカウント種別：これが因子
アカウント種別の内訳　→　　法人・個人・ゲスト：これが水準

というような構成になります！

デシジョンテーブルテストは、テスト観点を網羅する方法として下記の2種類に大別されます。

• 全網羅
  • 因子・水準のすべての組み合わせを検証します。網羅性は高くなりますが、テストすべき組み合わせ数は多く、テストの実施コストがかかります。
• 水準網羅
  • 1つの水準を必ず1回はテストする方法です。組み合わせの観点ではなく、単一の水準確認を最低限のパターン数で確認することができます。
    こちらの方法は、全網羅と比較すると網羅性が下がりますが、テストの実施コストを軽減することができます。

ビットキーでは主に水準網羅を用いてテスト設計をしています（もちろん必要に応じて全網羅も実施します）。因子と水準を用いてテスト設計、そしてテスト観点ごとに期待値を設けてデジションテーブルを作成しています。

デシジョンテーブルテストのポイントとしては、最低限検証すべき観点を網羅しプロダクトの品質は担保しつつ、限られたリソースで期限内に完了できるようにテスト設計することです。

注意点として、デシジョンテーブルテストでは再現できない組み合わせパターンが含まれる場合があるため、テスト実行時に再現が可能かという点を確認する必要があります。

下記画像は、workhubで会議室やワークブースを予約した際の解錠についてテスト設計したデシジョンテーブルの一例になります。一般的なデシジョンテーブルとは少し構成が違いますが、ビットキーは以下の構成でテスト設計をしています。

テスト設計では、観点の漏れがなく、かつ工数内に収まるようにテスト技法を活用してテスト設計をする必要があります。

テスト技法学習のオススメ書籍

自己紹介であった通り筆者のテスト経験は浅く、まだまだキャッチアップ段階です。
そこで筆者が独力で学習する際に参考にした書籍をご紹介します。

こちらの参考書はテスト初学者向けの参考書となっています。
テスト技法の説明とともにその場でworkができる構成になっており、筆者にとってちょうど良い難易度の練習帳でした！

構成として以下の流れでテスト技法を学ぶことができます。
1.同値分割法と境界値分析
2.デシジョンテーブルテスト
3.状態遷移テスト
4.組合わせテスト
5.総合問題

こちらの参考書を学んだことで、業務で実施していたテスト分析やテスト設計において、なぜその観点が必要になるのかというロジックを明確にすることができました！
また、なぜその観点が必要であるかもより合理的に判断できるようになったと思います。

終わりに

テストエンジニアらしくテスト技法について書いてみました。
ビットキーには入社9ヶ月ほどですが、アドベントカレンダー参加の機会を得られたのは大変ありがたいことだと思っています。

本記事がテストエンジニア初学者やテスト技法活用の参考になれば幸いです。
最後までお読みいただきありがとうございました！！

15日目の株式会社ビットキー Advent Calendar 2023 は @Qtikimtna さんが担当します！