知識ゼロのプロダクトにつくるテスト戦略
2.7K Views
December 12, 24
スライド概要
2024/12/09に開催された【増枠】Sansan VS サイボウズ - 品質向上Tips冬祭りで発表した資料です。
【増枠】Sansan VS サイボウズ - 品質向上Tips冬祭り - connpass
https://sansan.connpass.com/event/335070/
サイボウズ株式会社の主に開発本部の資料を公開するアカウントです。
関連スライド
各ページのテキスト
知識ゼロのプロダクトにつくるテスト戦略サイボウズ 開発本部 massan
massan21.4新卒入社 - サイボウズ開発本部kintone新機能開発のQA24.7 ~ kintone拡張基盤チーム（QA）チームのひとりQAとして、新機能の試験設計から担当領域全般の品質向上活動などまでいろいろ福岡在住好きなもの2
kintone拡張基盤チーム・開発エコシステムの支援をミッションに、kintoneの拡張機能（プラグインや連携サービス）の開発基盤を開発・保守するチーム・APIなどの整備・kintone向けのSDK, CLIツールなどのOSSの提供cli-kintonekintone JavaScript SDKkintone Java Client3
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の機能かが分かればOKJava 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