知識ゼロのプロダクトにつくるテスト戦略

知識ゼロのプロダクトにつくるテスト戦略 サイボウズ 開発本部 massan

massan 21.4 新卒入社 - サイボウズ開発本部 kintone新機能開発のQA 24.7 ~ kintone拡張基盤 チーム（QA） チームのひとりQAとして、新機能の試験設計から担当領域全般の 品質向上活動などまでいろいろ 福岡在住 好きなもの 2

kintone拡張基盤チーム ・開発エコシステムの支援をミッションに、kintoneの拡張機能 （プラグインや連携サービス）の開発基盤を開発・保守するチーム ・APIなどの整備 ・kintone向けのSDK, CLIツールなどのOSSの提供 cli-kintone kintone JavaScript SDK kintone Java Client 3

kintone Java Clientにテスト戦略を策定しました 4

もくじ｜kintone Java Clientにテスト戦略を策定しました ・背景 ・テスト戦略策定｜目的とスコープの設定 ・機能テスト設計 ・運用しながら改善 ・まとめ 5

背景 過去にほか部署から移管されたkintone Java Clientの品質保証活動の強化として、 テスト戦略を立てることに - kintone Java Client: kintoneのJava利用者向けREST APIクライアント - テスト戦略なし、仕様書なし - ユニットテストとE2Eテストはある程度ある 個人的には未経験の要素が多いプロダクト - APIクライアントの試験したことなし - Javaのコードを真面目に読んだことなし 6

テスト戦略策定｜目的とスコープの設定 目的 比較的すぐにまとまった ・安心して開発を継続できること - 新機能追加やライブラリ更新時などのデグレードの不安を軽減する ・ユーザーに品質の担保されたJava Clientを使ってもらう スコープ ある程度 網羅的に、時間をかけて検討 →困った時のISO規格！ということで、 品質モデルを参考に、エンジニアとQAで話し合いながら定める 7

テスト戦略策定｜スコープ 品質モデル（ISO 25010）を参考に、エンジニアとQAで話し合いながら定める 短期、中長期的に抑えたい観点を網羅的に探せる 品質特性をそれぞれ全て見ると多少時間がかかる - 関連ドキュメントを調べたり、エキスパートに相談したり スコープ内 例 仕様書はない APIクライアントとしてカバー済みのエンドポイントが叩ける、など 機能試験全般ができそう 機能適合性 ◯ 性能効率性 × 大量のリクエストが送られた場合、などはkintone側の観点 使用性 ◯ テスト項目としては無し 実装レビューの段階で検討したり、動作確認で気づきがあれば積極的 にフィードバック セキュリティ ？ エキスパートに相談 … 8

機能テスト設計 探索→コード読む→エンジニアに相談 を繰り返して観点出し・設計 探索的テストの要領でプロダクトを触ってみる 目的：仕様、挙動を学習する、使用イメージをつける 探索 コード 読む エンジ ニアに 相談 できるところまでで、ソースコードと既存のテストコードを読む 目的：Java Clientのテストとして必要な観点を得る 上記で出た疑問点や、設計したテストをエンジニアに共有 目的：疑問点の解消、エンジニア視点でテスト設計レビューをもらう 9

機能テスト設計｜探索 Explore it! を参考にしました - 探索的テストのやり方、tips、事例などが書いてある - ホワイトボックステストができないとき、先入観があるときなどに 便利 - 社内で勉強会があるなど、手に取りやすかった 使ったtips例 - その機能/プロダクトでできることの動詞/名詞を並べ、組み合わせ て観点を探す 動詞：アップロードする、更新する、.. 名詞：ファイル、スペース、アプリ情報、.. - 変数の型にとらわれすぎず、パラメータに入れられる値を列挙する 記号、空白、null、JISコードの文字、.. 10

機能テスト設計｜コード読む 正直、詳細な振る舞いを理解するほどは読めない… → APIクライアントの機能試験として、kintone（本体）かJava Clientの機能かが分かればOK Java Client → ← → ← リクエスト レスポンス kintone テストする例 テストしない例 - リクエストが抜け漏れなく作られること - kintone側が行うアクセス権の評価 - Java Client側のバリデーションやエラー判定 が正しく行われること - 存在しないアプリへのリクエストなど、 Java Clientでなくても同じ結果になる ケース - Java Client側で用意している列挙値 - IDEでコード補完ができること - .. - .. 11

機能テスト設計｜エンジニアに相談 設計した機能テストのレビュー依頼 / 疑問点を共有 - エンジニア視点で不要なケースを削り、懸念あるケースは足す - 自動テストとして実装できるかも意見をもらう よかったこと - テストケースがブラッシュアップされ、効率があがる - テスト戦略を一緒に立てたので認識がわりと揃っている - QAの手が足りないときエンジニアにもテスト実施をお願いできる 12

運用しながら改善 実際に設計した機能テストを手動実施、自動化するとコストが大きくなった - 他の担当プロダクトに比べて使用頻度 / 変更頻度 低 - これまで目立った意図しない挙動は発生していない - 自動テスト（E2E）がメソッドごとに10件弱あり、設計・実装にレビューが1,2往復発生 …etc コスト対期待効果のバランスを調整 - E2Eはメソッドごとに基本１ケース、ユニットテストでよい観点はユニットテストにしてもらう E2Eもエンジニアに設計、実装してもらい、QAで実装後に確認 - 繰り返し確認するほどでもない挙動は手動テストのみ - 問題があった際の認識合わせ（切り戻し / ユーザーには古いバージョンを使ってもらう、など） 13

まとめ 14

まとめ 知識ゼロのプロダクトとして、kintone Java Clientにテスト戦略を策定 - コードが読めない側、読める側どちらの視点も持ち寄ったり、品質特性など俯瞰して眺めるこ とで安心感あるテスト戦略が立てられそう - エンジニアなどと積極的にコミュニケーションをとって、担保したい品質の共通認識ができる とよさそう - 共通認識があるとよりよいテストも書ける - 懸念が出たとしても、対応や優先度決めのコミュニケーションが少なくてすむ これから - 他の担当プロダクトでテスト戦略が必要になったときにも応用できそう - Java Clientが大きく仕様を変えるときに効果が測れるかも 15

ありがとうございました 16