はじめに
どうも、元QAのエンジニア @Syahu_Writer です。
今回は、元QAが開発チームにjoinしてから行った品質向上のための施策について紹介していきます。
大なり小なりいろいろとやってますが、代表して以下3つを話します。
・開発プロセスの改善
・シナリオテストケーステンプレートの改善
・不具合の再発防止
開発プロセスの改善
以下は当初の開発フローを図に書き起こしたものです。
この図から読み取れる問題点はざっくりと、
・すべて直列のフローだが、並列処理にしていいものも混じっている
・テスト完了レビューといった、不要で実際に行われていないものがある
・レビューのタイミングが悪く、大きく手戻りが発生する箇所がある
という状態でした。
それを以下の通り修正しました。
・並列にして問題ないものは並列にする
・不要なプロセスは削除する
・手戻りが最小限となるようにレビューを設置する
また、開発フローでは表せていない、以下の問題点もありました。
・出荷日の前日にテストが終わる日程で計画されている
→バッファが存在しないため、テストで問題が出た場合に出荷日やスコープの変更が発生する
・実際に出荷されるものを利用してのテストが一切されていない
→テスト用のものと出荷物に乖離があった場合、気付くことができない
それらについても、
・出荷日の2営業日前に評価までを終わらせるように日程を変更し、バッファを持たせる
・評価者テストでは実際の出荷物を用いてテストを実施する
と変更を行いました。
開発フローの変更による効果測定は難しいですが
（変更以前の状況をほとんど体験していないので）、
バッファは年に数回利用していることから、
出荷日が予定より遅くなってしまうことや、
急に出荷物の中身を変えることによって発生し得る不具合を、
未然に防ぐ効果は出ているのではないかと思います。
シナリオテストケーステンプレートの改善
先述した開発フローから察した方もいらっしゃるかもしれませんが、
私の所属している開発チームは全員フルサイクルエンジニアです。
自分たちで設計、開発し、
自分たちで評価、出荷し、
自分たちで質問、問い合わせの対応まで、
すべてを実施しています。
つまるところ、多くの開発者の方には馴染みが薄いかもしれませんが、
結合テストやシナリオテストも自分たちで行っています。
（開発フローに書いてある「評価者テスト」は「≒シナリオテスト」です）
シナリオテストの詳細は一旦置いておくとしても、
開発者が行う単体テスト等とは全くの別物だという認識はあるかと思います。
その通り、全くの別物であるのですが、私がjoinした当初は、
単体テストもシナリオテストも同じテンプレートで作成されていました。
初見時、誤って同じテンプレートを開いてしまったのかと目を疑いましたが、寸分違わず同じでした。
ということで実際のテンプレートや作成した詳細は省きますが、
手塩にかけて1からシナリオテスト専用のテンプレートを作成し、
それを運用しています。
不具合の再発防止
品質を向上していく上で最ももったいないことは、
・一度起きたことをもう一度起こしてしまう
・誰かが引っかかったことに他の人がひっかかる
です。
「似た不具合をやらないよう気を付けます」
は品質向上に寄与できません。
人は忘れる生き物ですし、疲れていたらすっぽ抜けるし、
その不具合が起きたのを他の人は知らないかもしれないし、
新しくjoinしてきた人は教えない限り100％知りません。
これを解決するには、
・ナレッジ化し、誰でも常に確認できるようにする
・開発プロセス上、必ず確認するようにする
ように整備しました。
特にミソなのは2つ目の「プロセス上必ず利用する」ことです。
作っても使わなければ、忘れ去られて廃れます。
ということで、
・コードレビュー用
・開発者テストレビュー用
・評価者テストレビュー用
の3つのナレッジを作成し、それぞれレビュー時に確認することを手順に含めました。
中身は、不具合をチェックすることのできる観点表になっています。
また、作成しただけでは、
「一度起きたことをもう一度起こしてしまう」
ことは防げません。
まずは自分で、各種レビューや不具合が発生した時に、
それを防げる内容をそれぞれに追記していきました。
自分たちが起こしたことでなくとも、
世の中で起きた不具合の話で応用できそうなものは、
随時取り込んでいきました。
さらに、
「不具合を発見できなかった≒ナレッジに観点が不足している」
ということですので、
不具合を発見次第、再発防止策を検討し対応するようプロセスを追加し、
その再発防止策の一端に「適切なナレッジに観点を追加すること」を含めています。
（もちろんナレッジ追加以外の手も取っています。）
これは結構目に見えて効果が出ていると実感することができます。
・自分でOKと思っても、レビューでナレッジを元に指摘される
・各種テストがナレッジを元に確認するケースが増える
・実際に過去出してしまった不具合を、レビューやテストで引っかけた
などなど、実際の数はカウントしていませんが、有用だったと感じています。
まとめ
今回は、元QAな私が開発チームにjoinしてから試みたことを3つ、ざっくりと紹介させていただきました。
「今見えている地雷をまず撤去する」「マイナスを0にする」という
駆け出しタイミングで実施したことですので、
まだまだ、もっと良い手法があると思っています。
開発フローの各処理について細かく定義したり、
QA時代に実現できなかったテストケーステンプレートを作ったり、
再発防止策のいろんな例などなど、
紹介したい細かいことはたくさんありますが、
それはいつか折があれば書かせていただきます。