こんにちは あるいは こんばんは
QA（品質保証）担当のおくやまです。
今回は製品開発のQA（品質保証）が日々どのような活動しているのかを
書いていこうと思います。
①ecbeing／マイクロサービスのQualityGate試験（QG試験）
"ecbeing”という言葉だと色々な意味を含むので、
ここではECサイトパッケージとさせていただきます。
また、ecbeingのオプションとして提供される"マイクロサービス"が数多くあるのですが、
主にReviCoのQG試験を行っています。
さて、ここから細かい話をしていこうと思いますが、
"ecbeing" と "マイクロサービス" で開発方式が異なります。
| 製品名 | 開発方式 |
|---|---|
| ecbeing | ウォーターフォール型 |
| マイクロサービス | アジャイル型（スクラム） |
その違いからQG試験の方法も変えています。
| 製品名 | テスト方式 |
|---|---|
| ecbeing | ブラックボックステスト |
| マイクロサービス | 探索的テスト |
その中身について書かせていただくと、
| テスト方式 | 内容 |
|---|---|
| ブラックボックステスト | 要件や設計書をベースにテスト項目を洗い出し、 対象の振る舞いを確認する。 |
| 探索的テスト | リファインメントとスプリントレビューに参加して機能を 把握する。Miroにマインドマップを用意し、振る舞いを 見ながらマインドマップにメモを取りつつ、テストを進める。 |
というように全然違う動き方をしています。
当初は違いに戸惑いもありましたが、人は慣れるもので今となれば当たり前のように
頭を切り替えて試験を実施しています。
②部内向けに品質に関する勉強会を開催
開発者が製品品質モデル（ISO/IEC 25010）を知ることで、日々の業務に活かして
いただき、品質向上に繋げたいという思いで定期的に勉強会を開催しています。
※補足：品質モデル（ISO/IEC 25010）とは、品質要求を定義し評価するための
枠組みであり、品質を分類・整理する時の着眼点（観点）を与えるものです。
今年の８月に製品品質モデルの全体像を伝え、９月に品質特性【使用性】について、
１２月に品質特性【セキュリティ】についての勉強会を開催しました。
以下、勉強会アンケートからのコメント抜粋で、
- 現況のやり方だと、まだ足りない部分があると気が付けた
- コミュニケーションの取り方と利用者への伝え方を意識したい
と品質を上げるためには、ひとりで抱え込んで間違えに気づかず邁進するよりも、
色々な立場の意見を取り入れていくべきであるという意識の変化に繋がりました。
他にも実例として、とあるプロジェクトの要件定義で
製品品質モデルの考え方を取り入れてみた結果、
- 調査内容に漏れがないかのチェック基準となった
- 製品化する際の引継ぎ内容に漏れがないかのチェック基準となった
という話も聞けており、事前に問題点への気付きに繋がったようです。
③品質の見える化／可視化
ここ最近部内でも可視化の意識が高まりつつあり、QAも色々な可視化を実施しています。
例えば以下のようなものがあります。
- ecbeing不具合分析
社内/社外からパッケージに関する不具合報告の件数と傾向をまとめています。
発生機能、バグ要因、組み込み工程、バグタイプ、バグランク、検出環境などで
カテゴライズしてグラフ化しています。
- ReviCo不具合集計
開発者ではなく第三者から不具合を指摘された件数と傾向をまとめています。
ここで言う"第三者"とは、QA、システム監査、利用者などが含まれています。
なぜ"第三者"と定義したかというと、開発者が取りこぼしてしまう弱点を
炙り出そうと思ったためです。
- インシデント管理台帳
運用中に発生したインシデントの件数と傾向をグラフ化しています。
また、チーム毎に振り返りを行っており、そこで出てきた教訓を
一覧としてまとめています。
まとめた一覧を見返すことにより、チームで起きた教訓の振り返りと
他チームの教訓から学ぶことに繋げています。
④品質に関するモダンな技術を学び取り入れる
テストの自動化について最近ブログ記事などを閲覧していると、
「Autify」「Datadog」などをよく見かけます。
社内でも「Autify」を利用してテストの自動化を実現しようと
頑張っているチームがいくつか存在しています。
その流れに便乗するのかと思いきや、QAチームは違います。
元々、私がエンジニア出身のため、また、費用面を考慮して、
「Playwright」を使ってテストの自動化を目指しています。
今のところ簡単なブラウザの互換性試験を実装できるまでのスキルを
身に付けたのですが、やはり壊れやすく大きなものを作り出そうとすると難しく、
試行錯誤の真っ最中です。
まとめ
上記の説明から日々のQA（品質保証）がどのような活動をしているかを
理解していただけたと思います。
ただ単に不具合を見つけ出すだけでは、不具合の根本を叩いていないので、
不具合はいつまで経っても無くならない。
不具合の根本を見つけるべく、可視化によって不具合の傾向を見つけ出し、
対策を打ったとしても不具合がないからと言って誰もが欲しい製品とはならない。
ただ一つの概念にとらわれず、幅広い分野に視野を広げ、
エンジニアをサポートしながら製品に対する顧客満足度を最大化するために、
これからも頑張っていこうと思っています。
以上、QA（品質保証）担当のおくやまがお送りしました。
