はじめに
プロダクトとQAを繋ぐブリッジ業務を行い、テスト設計や障害削減を行うのがテスト管理者です。
そのテスト管理者にとって何が必要なのか、どんな心構えで開発側と向き合わければいけないのか、考えは様々ですよね。
今回は第一弾として【テスト設計と改修】について共有させていただければと思います。
偉そうなこと言ってますが、私の体験ベースで感じたことなので、生暖かい目で読んでいただけると幸いです！
設計と改修で起きた苦悩
管理者に必要な技術として、テスト設計は一番最初に思いつくのではないでしょうか
項目を作成するのはもちろんですが、前任者が作成した項目の改修も業務の一部として加わってきます。
1から項目を作成するのは仕様書か読み解けば簡単なのですが、すでに項目があるものを改修するのは、前任者がどのような意図で項目を作成したのかがわからず、中々削減に踏め込めないことがしばしば...
「これは削減していいのか？それともこの項目がないと障害が発生するのか？」と四苦八苦しながら改修したのを昨日のことのように覚えています。
何が苦悩だったのか
上でも「前任者の項目改修が苦悩」と記載していますが、何が苦悩だったんだ！と思いますよね。
自分が担当しているプロダクトのテスト項目で起きていた"本当にあった項目の話"です。
①:項目が属人化している
一番多いのではないでしょうか
長年そのプロダクトを担当している人にしかわからない,テスター歴が長ければわかって当然という前提である項目がとても多く、項目はあるが障害が発生していまうケースが多々ありました。
②:必要最低限の確認しかない
仕様書から項目を作成するのは簡単ですが、起こりえるイレギュラーな確認項目がありませんでした。
新規施策を追加した際の既存部分へ起こりえる影響への考慮、新規アイテムを組み合わせた時に起こりえそうな不具合を確認する項目がなく障害につながるケースが多数発生していました。
③:同じ項目が重複している
時間があったら再度チェックしたかったのだろうか...
④:アイテムなどの効果を考察する項目がある
おぉっ？んんっ！？
考察した結果、どうしたらいいのかが全くわからない...いやまず「考察」ってなんだ？動作確認でもないし...
「これテスト実行者はどうやってチェックしてたんだ...」とテストの体制が不安定でした。
この問題点を見たときに、「あ、今まで開発が見ていてくれていたんだ...それか今迄運よく発生してなかったんだ...」とヒヤリしたのと同時にQAの存在についても考えさせられました。
Let's改修！
①~④までの問題点を洗い出せたのでここから項目の改修開始です！
自分の中でまず改修するにあたって、下記を解決策とおいて項目の改修を行いました。
①:テスト初心者でも出来る項目にする。
属人的ではないと見つけられないものを項目化し、だれでも出来る項目を改修
②:イレギュラーチェック,影響範囲の項目をテストケースに追加
フリーデバッグだと経験則で検知にばらつきが出てしまうと考え、それなら項目化してしまえ！という考えで項目化
③:重複している項目を削減
項目の粒度的に2度見る必要がないと判断し、削減
④:テスターが曖昧にチェックしている個所を聞き出し項目を修正・削除する
一番苦労したのが上記でした。
テスターから「ここの項目がわからないです」と質問来たときに「いや、君先月もこれ確認してるで」というやり取りが多発していました。
その部分を改修・不要な部分を削減しました。
結果、5500項目の削減と障害も45%削減が出来ました(´◔౪◔)۶ﾖｯｼｬ!
まとめ
あくまで私のやり方でおこなったテスト項目の改修方法なので
これが正しいやり方でもなく、もっと効率よく削減と改修が出来るし、方法はもちろんあると思います。
しかしながら、その人がいなければテストが出来ない環境というのは、急にいなくなってしまったときに障害が発生するリスクとなりうるので、テストの標準化を目的としている方に、参考になればと思います。