株式会社オズビジョンの @terra_yucco です。
2020/01 現在、オズビジョン 6 年目。内部ではちらほら配置換えもありつつも、なんだかんだでこの 6 年の大半はメインプロダクト「ハピタス」を見ています。
前置き
現在、品質向上のために仕様統括＋品質管理というロールを担っております。
主な役割は、着手が決まった案件について、以下の項目のそれぞれについてレビューの必要性があるかを判断し、必要となったものはレビューをすること。もちろん担当チームは自分たちでも確認をしますが、仕様統括という形で全体のつながりも意識しながら追加で確認しています。
- 要件定義
- テスト設計
- リリース・反映手順、動作確認手順
- 後日確認手順
- 切り戻し手順
ansible のコードや、aws 関連のスクリプトの場合はコードを見たりもしますが、基本はプロダクトのコードは見ません。
なぜこんなロールがあるのか
一時期、リリース前後に不具合が頻発することがあったため。また、検出した不具合は、単純なテスト忘れや確認漏れが多く、誰かがチェックしていれば防げたんじゃないかと思われるようなものも多かったため。
どんな点に気を付けて見ているのか
仕様統括として
要件定義
- これまでの機能との相反・不整合がないか
- ユーザステータスの遷移
- 既存データとのドメインチェック
テスト設計
- 動作テストにおいて、提供機能のハッピーパスがテストされているか
- 機能的に見落としている、重要な組み合わせパターンはないか
- 事業的に意味を持つ、入力値のバリエーションはないか、ある場合はテストパターンに含まれているか
リリース・反映手順、動作確認手順
- 複数機能をリリースする場合、前後関係は正しく保たれているか
- 機能にダウンタイムが発生する場合、調整はされているか、メンテナンスが必要な場合は調整済か
- 動作確認手順は、実際にリリースする変更部分の動作を確認できるものとなっているか
全般
- 過去に出た不具合と類似の事象が発生しそうな場所はないか
品質管理として
若手のメンバーも多いので、かなり一般的な見方をしています。これは主にテスト設計の確認に適用しています。
本来は DB 設計やセキュリティ観点なども要件定義で見たほうが良いのですが、これは現状では各チームに移管しています。
基本
- 誰が見ても実施する内容がわかるテスト設計となっているか
- 期待するインプットが明確か、全て洗い出されているか
- 期待する想定の結果が明示されているか ※「正常であること」などは想定結果ではない
単体観点
- 各ドメインの値、境界値
- カバレッジ
結合観点
- 状態遷移を伴う場合には、実際に遷移させるテストを行う設計になっているか
- 既存の機能に影響する場合、その機能全体の通しのテストも行う設計になっているか
全体
- 必要なテストが、コードレベルの UT などとマニュアルテストを合わせて網羅されているか
効果
普段の業務にプラスオンして何名かのメンバーで分担していますが、レビューを間に挟んで別の人の目を入れたということはいい方に働いており、このレビューをしっかりやった案件ほど不具合が出ないという結果にはなっています。
ただし当たり前ながら QCD の CD を少し犠牲にして Q を上げている結果にはなっているので、次はここに何らかの手を打っていきたいと考えています。
これから
既に一回実施していますが、このレビューを通して得られた知見を社内にシェアし、将来的には特別なレビューを挟まなくても各チームで品質向上に取り組んでいければと考えています。
皆さんのレビュー観点などももしあればぜひ教えてください。