この記事について
- 対象：WebサービスのQA担当者
- 概要：WebサービスのQA立ち上げ時における留意点
- 読了までにかかる時間：3分
テーマ選定の背景
複数のWebサービスの初期段階のQAを担当した結果
(当然ですが)運用QAにはない留意点が共通して存在したのでメモとしてまとめようと思います。
あくまで経験に基づくものなので網羅性などはなく
こういうものもあるのかという意識で読んでください。
留意点メモ
テスト開始前
数段階に分けたテスト計画の提案が必要になる
立ち上げ時はリソースの制約が厳しく、特に費用に関しては厳しくみられるケースが多いです。
そのため全ての機能を組み合わせまで考慮してテストを実現することは困難です。
そこであらかじめQAの方で数パターンの検証方針を検討しておくことで
QAとして譲れない部分は必ずテストに組み込むストーリーを作ることが重要です。
(そしてだいたい最少工数のパターンが選択されます)
QA側での仕様書管理が求められる
私の現場では仕様書がないことも多く、
あったとしても更新が反映されておらず実装と合致していないことも散見されました。
また更新している場合でも、QAに連携のないサイレント修正が頻発し
仕様書を基に作成したテストケースが実装とそぐわないものになることもありました。
その対策としてQA側で毎朝仕様書の更新状態を確認するという体制を構築しました。
QA側が行う作業として本来は過剰なように思いますが
時間的リソースも限られる場合は初期フェーズのみという制約付きで巻き取る場合が多いです。
開発⇔QAの連携体制が必須である
「QA側での仕様書管理が求められる」にも関連しますが当初よりQA側で行う作業が増える場合があります。
そういった場合、多くは開発側から見えづらいため
理由なくQA側の進捗が遅いと映ってしまう可能性があります。
このような認識齟齬を解消するため朝会による状況報告会を実施しました。
認識齟齬が発生したときの手戻りを考えると工数的に多少無理をしてでも行ったほうが良いと思います。
テスト設計時
テストケースに落とし込みづらいバグが多い
アプリゲームのような動的なテスト対象ではないものの
初期段階となるとテストケースに落とし込みづらい項目でのバグが散見されます。
そのため一定の能力/経験を持ったテスターをアサインするか
テストケース作成にかなりの工数を割く必要があります。
私がテストケース作成を担当した際は全工程で一番テストケース作成に時間をかけた覚えがあります。
参考までにテストケースに起こしづらい項目でのバグを記載します。
- サービス内の広告ごとに文字/画像/アイコンの大きさが微妙に異なる
- 一部機能の読み込みが他より若干時間がかかる
- 特定の繊維方法の場合に画面が真っ白になる(確率で発生)
- タップしたハイライトがページ箇所によって異なる
感想
まとめようと思った背景として自身の気の緩みがあります。
定常の業務としてゲームのQAを担当しているため
静的なテスト対象であるWebサービスはゲームより検証は楽だろうという心構えで臨んだ結果
想定よりもかなり工数がかかってしまったという過去があります。
もちろん新規だから大変だったというのもありつつ
Webだからこそ細かい修正が頻発したという特性もあると思うので
今後WebサービスのQAを担当する方の参考になれば幸いです。