はじめに
メリークリスマス
私は某通信会社でサードパーティーや社内のDeveloper向けのプロダクト（以下、Developer Productと称します）のテストチームのleadを担当しています。
主な作業としては各リリースに対してのテスト計画、分析・設計～実装、そしてテスト自動化なども行っています。
経歴も簡単に紹介すると、
- テスターからのキャリアスタート
- 一般ユーザー向けのプロダクトでE2Eテスト中心に担当
- 現在配属されているプロジェクトで初めてDeveloper Productを担当
本記事ではテクニカルな背景が無い私がどのようにDeveloper Productのテストに挑戦したか、その工夫をしたためます。こんな方法もあるんだなという感じで読んでいただけると幸いです。
Developer Productとは？
下の図で示している通り、プロダクトの最初の利用者は開発者です。
つまり、私たちにとってのユーザは一般の方ではなく、システム開発を行う開発者ということになります。
こうした開発者向けのプロダクトをDeveloper Productと呼んでいます。
特有のテストの難しさ
一般の方向けのプロダクトとDeveloper Productの違いは何なのか、どちらのサービスのテスト活動にも従事したことがあるため比較してみました。
■一般の方向けのプロダクト
画面設計書が詳細にあったためテストがイメージしやすく、テスト仕様書も比較的つくりやすかったです。
■Developer向けのプロダクト
1. 利用シーンを想像しにくい
Developer Productを使ってどのように開発するかは開発者次第です。
そのため、Developer Productを組み込んだサービスがどう利用するのかを想像した上で、プロダクトがどうあるべきかテストを考える必要があります。しかし、開発経験のない私は開発者がどのように利用するかをイメージすることが難しかったのです。
2. インプットの難易度が高い
画面設計書だけでなく、APIの仕様書やシーケンス図、コンポーネント図などを読み解く必要がありました。
（更に私たちのプロジェクトのドキュメントは全て英語で書かれていますが、テストチームは英語があまり得意でないため細かい説明の仕様書などは人により認識がブレてしまうこともありました。）
3. 技術的な用語が飛び交う
ミーティングでもslack内でも会話は技術的なものがメインとなっています。そのため、話の内容を理解するには、CookieやSessionなど一般的なWebアプリケーションの知識に加え、RFCに準拠したHTTPの仕様、認証認可の仕組みなどを理解する必要がありました。
4. テストチームのみがノンテクニカル
これは私が所属するプロジェクトの体制の話になりますが、以下のような構成になっており、テストチームのみが開発知識が無いという状態でした。
- Product Manager 1名
- Project Manager 1名
- Developer 12名 *Front-end/server/iOS/Android
- Test Team 6名
展開した施策
「違いは理解したけど、開発知識無いのにDeveloper Productのテストなんて出来るの？！」と思ったそこのあなた。結論から言えば、可能でした。
自身の圧倒的な知識不足から来るもどかしさで、心がすり減った日々もありましたが、なんとかなるものでした。私は主に以下二つを意識していました。
- 同じコンテキストで話せるように前提を揃えにいく
- 関係者を積極的に巻き込んだコミュニケーション
それでは次に、具体的な施策を説明させていただきます。
1.理解を深め、人に説明できるようにした
Before
開発の設計MTGに参加せず、完成した仕様書のみを確認する
After
1. 開発定例MTGに参加し、検討中の段階から議論されている内容を把握する
2. 把握した企画・設計内容を自分の言葉でテストチームのメンバーに説明する
--
テストチームはそれまで案件内容を主にドキュメントからのみ把握していました。
プロジェクトの一員として、上流工程から携わっていきたいという考えから開発者の定例MTGに参加し、検討中の段階から議論されている内容を抑えるようにしました。
プロジェクトに配属された当初は開発知識も無い上にサービスに対するドメイン知識もなかったため、ハイコンテクストな開発定例の内容を理解するのに、これまで経験したプロジェクトの何倍もの時間が掛かってしまいました。
その中でも出来る限り細かくメモを取るようにして、分からない用語や技術的な要素は調べるようにしました。
そして、技術的な話でいまいち理解が追いつかない時は、MTG内容を自分なりに整理した上で、理解が合っているかどうか関係者に確認するようにして、自分の中で納得感を得たり違和感を払拭したりと少しずつ開発者と前提を揃えていきました。
また、議論されている内容をテストチームのメンバーに自分の言葉で説明するようにもしました。メンバーに共有することの狙いとしては、自分の言葉で企画や機能の背景を人に説明することでサービスの利用シーンをより具体的にイメージできるようにしたかったためです。
説明することにより、以前はテスト直前に仕様を知る状態でしたが、この取り組みを行うことで前もってテスト対象の重要性や難易度なども伝わるようになりました。
2.テスト内容をプロジェクトメンバー全員へ説明する
Before
プロダクトマネージャーがドキュメントのみでテスト内容を把握する
After
開発者含め全員にテストプランを共有して、レビューを受ける
--
テストチーム単独の施策ではなくプロジェクト全体で決めた施策となりますが、開発定例MTG内でテストプランを口頭で共有するようにしました。
「この修正でこういう影響があるため、このテストを行います」ということを自分の言葉で説明するために、技術的な要素を理解しておかなければなりません。そのため、この場も自身の理解促進の一端となりました。
また、以前、開発チームとテストチームが仕様に対してズレた認識をしており、実装もテストも各々考えたもので対応していたため、後になって仕様について再度確認し合うといった事象が発生したこともありましたが、共有方法を変えたことによりプロジェクト全体でテスト内容の同期が出来るので、微妙なズレも軌道修正することができるようになりました。
案件が重たい場合は、全員に共有すると時間を取ってしまうため要点だけを説明するようにして、詳細部分は別でテストチーム主催でテストプラン共有会をひらくなどのアレンジも加えています。
3.テスト条件はマトリクスで表現して伝える
Before
全てのテストケースに対してレビューを受ける
After
マトリクスで表現したテスト条件を確認してもらう
--
以前はテストケース内容をすべてレビューしてもらっており、時間が掛かる上に、詳細なテストケースをいきなり確認することになるので文章の羅列で視認性も悪く、網羅できているか抜け漏れに気付きにくい状態でした。
そのため後になって、過去にリリースした機能の特定のテストが出来ていなかったと気づき、更に、実は仕様も考慮されていなかったということもあり追加対応の時間が掛かってしまうこともしばしばありました。本当はテスト設計時点で気付くことが出来るような、寧ろ気付くべき内容だったのです。
テスト条件をマトリクスで表現して伝えるようにした結果、時間の効率化と、視認性が高まったこともありテストチーム内に限らず開発者もレビューがし易くなって、テストの抜け漏れを防ぐことが出来るようになりました。
おわりに
プロジェクトにアサインされた当初は、正直言えば難しすぎてどのような対応をすべきか分からないことが本当に多くありました。
プロジェクト内で開発知識を持っていないのはテストチームだけというコンプレックスを抱かざるを得ない状態ではありましたが、人間関係力や課題解決能力などのノンテクニカルスキルは最大限に活かしつつ、Developerプロダクトを担当する上で開発未経験だとしても技術的な部分に対しては避けて通れない向き合うべき対象だと思い、本記事のように向き合い方を工夫しました。
- 開発定例MTGに参加する
- 議論内容を自分の言葉で説明する。必要に応じて調べる、開発者に聞く
その結果、テストスキルやノンテクニカルスキルの更なる向上を私自身実感できるようになりましたし、プロジェクトメンバーからの評価でも以下のような言葉をいただけて他者からの信頼も得ることができたと思っています。
Developer Productのテストは簡単ではないですが、あなたと良いコミュニケーションを取ることでAndroidのパーツをうまく管理することができました。あなたはいつも私がAndroidにどのような変更を加えたのかを理解しようとしており、十分な品質を確保するために総合的なテストを行っています。 さらに、あなたは開発者がテスト範囲をよりよく理解できるように、テストドキュメントの改善に役立てるための意見を私にも確認してくれました。
私はテクニカルスキルが必要な場面でもノンテクニカルスキルを活用してテスト活動が出来ることを学びました。
今後もノンテクニカルスキルの強みは持ち続け、開発知識もさらに伸ばして貢献範囲を広げていきたいと思っています。
ここまで読んでくださってありがとうございました
最後に、あなたの"いいね"が励みになりますので、どうぞよろしくお願いいたします。