こんにちは。kintone 開発 QA の massan です。
この記事では、kintone を操作するためのCLIツール cli-kintone のテスト戦略を策定したお話をご紹介します。
QA が 0 人のチームから相談を受けた
kintone 開発には当時、 cli-kintone の開発をはじめとする、エコシステム開発者の開発者体験向上をめざす kintone DXチーム（以下、開発チーム）がありました。
＊本記事は主に 2023 年ごろの内容です。現在は kintone DXチームは解散しており、類似の担当領域を持ち、開発エコシステム支援をミッションとする拡張基盤チームが新設されています。
cli-kintone についてはこちら：
cybozu.dev
複数の機能をもち、数年に渡りユーザーに利用されている cli-kintone ですが、それまではソフトウェアエンジニアによるユニットテストや動作確認で期待する挙動が担保されていました。
開発メンバー全体の状況や過去不具合を考慮した結果、kintone DX チームに別チームの QA 2名(筆者含む)がサポートで入ることになりました。工数の都合でチーム異動までは難しかったため、一時的なサポートという形になりました。
そして、テスト戦略の策定や自動テスト強化を始めることになりました。
テスト戦略を策定
ゴールを定める & 状況を理解する
まずとりかかったのは、ゴールを定めることです。QA が開発チームの外からサポートするにあたり、以下のようなマイルストーンを設定しました。
- QA 内でテスト戦略の敲き台を作成
- 開発チームにヒアリングしながら推敲
- テストケースの洗い出し、自動化するテストの実現方法の検討
- テスト戦略の定着、安定稼働させる
また、チームの状況を理解するため、 cli-kintone にはどんな機能があるのか、提供したい価値は何か、ユーザーはどんな人たちか、過去不具合にはどんなものがあるか…など、手を動かしたり質問したりしながら整理していきました。
QA 内で敲き台を作成
QA 内ではテストの目的と、おおまかなテスト観点をまとめていきました。
テストが手薄と感じている開発チームメンバーの声として、新機能開発やリファクタリングによってデグレードが発生することへの心配がありました。これを踏まえ、テストの目的は品質の担保された cli-kintone をユーザーに提供すること、そして開発メンバーが安心して開発を進められること、としました。
テスト観点については、機能適合性、互換性、セキュリティなど、品質モデルに基づいた項目を一つ一つ確認していきました。たとえば、 cli-kintone は kintone のレコード書き出し、読み込みができるので、互換性は kintone のバージョンが上がっても動作すること、などの確認です。
開発チームにヒアリングしながら推敲
テストの目的とテスト観点を大凡まとめたら、開発チームに紹介してみました。
開発者視点から目的やテスト観点について違和感・感想を共有してもらったり、深掘りすべき観点があるかなど QA 側から質問したりし、スコープにいれるテスト観点をまとめていきました。（個人的に、 プロダクトについてたくさん質問をすることは QA の大事な役割だと思っています！）
また、具体的なテストケースをいくつか挙げて、その自動化の実現方法も検討しました。
CLI ツールの自動テストは私たちにとって未知の領域だったので、 QA 側でも社内外の例を探したり、具体的な手順イメージを共有したりしつつ、開発チーム側に調査・選定をしてもらいました。
それから
テストの目的、スコープ、実施方法の認識合わせをし、テスト戦略が形になりました。
その後はスコープをカバーするテストを QA が設計していき、開発チームによるテストケースのレビューを通しながら自動テストが実装されていきました。
自動テストの基盤構築、実装までは開発チーム視点の以下のスライドをぜひご参照ください：
まとめ
長く使われる製品が多い環境でテスト戦略を考える機会はあまり多くはありませんでしたが、 QA 間で協力したり、開発メンバーと密にやりとりを重ねることで地に足のついたテスト戦略ができたかなと思っています。
当時 ISTQB の Foundation Level を取得したばかりだった私としても、とても貴重な経験になりました。
作成、運用されてきたテスト戦略は現在、新設の拡張基盤チームに引き継がれています。
拡張基盤チームの活動についても発信していくつもりですので、ぜひ今後の記事にもご期待ください！
最後までお読みいただき、ありがとうございました💐
