はじめに
こんにちはHRBrainでQAエンジニアをしているmonです。
QAエンジニアをしていると、この仕様なんか使いにくいなと感じることがあります。
この感覚はQAエンジニアとしてとても大事なのですが、テストはしにくいが実運用には適している仕様である場合があり、判断に迷ったりします。
そういった判断に迷った場合や、仕様の見直しを提案する際に心がけていることを記事にしようと思います。
仕様に疑問を持つ
たとえば、計算式やダッシュボードが正しく表示されているか確認する場合には、結果から逆算して操作をしたりします。
想定した結果になるようにデータを仕込む作業をく返していくうちに大元のデータを修正出来たら良いなと浮かんだとします。
機能の目的を整理する
１． そもそも集計元のデータは何を元に持ってきているのかを考える
- 同一人物が操作するのか、複数のユーザーが操作するのか
- 手入力なのか、自動計算で算出しているのか
- 定期的に更新されるものなのか、、、など
→この時点で実運用では起こり得ないと判断がついた場合にはどこかに記すに留めて最後にもう一度振り替えれる様にしておきます
2. どういった場合に起こりうるのか整理する
- 入力ミスをした場合
- 式に含みたくないデータを入れてしまった場合など、、、
3. リスクを整理する
- 修正可能にした場合、競合操作の問題が出てくる
- 修正不可にした場合、１度ミスをするとデータの整合性が取れなくなるなど、、、
私は一旦ここまで出してからエンジニアやPMの方に相談するように心がけています。
相談する際のコツ
発生ケースをなるべく分かりやすくユースケースに落とし込んで説明する
✗ 再現手順のみを説明する（〇〇をした場合に〇〇となる）
◯ 前提の設定を仮置きして加える（全ての操作が完了してからミスに気がついた時、〇〇をした場合〇〇となる）
現状の仕様上のリスクを伝える
誤ったデータのまま修正が出来ないので、機能の目的を果たせなくなる可能性があるなど、、、
メリット、デメリットをなるべく添えた上で代替え案をいくつか提案してみる
✗管理者は後から修正出来るようにする
◯管理者は後から修正出来るようにする
メリット:データを修正することで整合性を取れるようになる
デメリット:複数管理者が居た場合に競合操作を考慮する必要がある
実際の運用でどの程度発生する可能性があるのかユーザーに近い立場の人に聞く（聞いてもらう）
→QAエンジニアと実際のユーザーとでは操作頻度が各機能ごとに異なる為、発生頻度も差が出るのでここはヒアリングするに限ると思います
最後に
テスト実施時に限らず、開発しているソフトウェアを日々触っていると、この仕様ってどうなんだろう？と感じることがしばしば出てきます。
そんな時には、QAエンジニアは品質を保証するのが仕事であり、仕様を決める（変更させる）のではないという意識のもと上記を実践してみると少し仕様について提案するハードルがお互いに下がるのではないか（＝より良いものを作れる環境が出来る）と思っています。
HRBrainでは一緒に働いてくれる仲間を募集しています！
一緒に素晴らしいサービスを作っていきしましょう
HRBRain採用情報