こんにちは あるいは こんばんは
主にecbeingのBtoBとBtoCパッケージのQA担当しております【yo】と申します。
さて今回の記事のテーマは『品質の情報発信』についてです。
より良いモノづくりの環境となるようにQAチームメンバーへまたは開発メンバーへ
わたし個人が知りえる知識を意識的に共有しています。
そんなありふれた日常的な日々の一部を紹介したいと思います。
1. QAチームメンバーへの情報発信
試験で見つけた不具合をなぜ見つけることができたのか？をメンバーへ伝える
新たな機能が作成されることでQAチームへ試験依頼が来ます。
試験実施するために要件定義書/基本設計書/詳細設計書を元にして試験書を作成します。
その試験書を作成するときの注意すべき点を過去の試験結果から有効となる考え方を
メンバーへ伝えています。
例を挙げると
・最大値を入力したことでの表示崩れ
・クロスブラウザで動作が異なる
・購入する商品の種類と支払方法による組み合わせ
など細かいことを言い始めるとキリがありませんが、
ソフトウェアテストの７原則にある「欠陥の偏在」の考え方から似た不具合を
見つけられるようにしています。
不具合パッチからどのように不具合検知できたのか？をメンバーへ伝える
本番環境で不具合が発生した際に不具合を治すためのパッチが作成されます。
パッチの内容から試験時にどのように対処すれば不具合が拾えたのかを
メンバーへ伝えています。
例を挙げると
・全角/半角スペースを入れてみる
・エラー発生時、もう一度ボタンを押す
・XSS/CSRFなどセキュリティ攻撃を仕掛ける
など要件定義書/基本設計書/詳細設計書には書かれていない
応用的な試験のヒントが得られます。
購入フロー図から試験の全体像を掴んでもらう
Miroを使ってシステムのフロー図を作っています。
全体像を知ることで試験の考慮漏れを防ぎます。
複雑な処理の時などメンバーからフロー図があって助かったとの声も聞けています。
2. 開発メンバーへの情報発信
品質雑談会の開催
月に一度開発メンバーに集まってもらい、品質をテーマにして日頃の開発での困り事や
実際にあった炎上話などざっくばらんに話す会を開いています。
私自身QA視点とは異なる考え方や意見が得られて大変勉強になっています。
もらってばかりもいられないので
・QAチームがどんな試験のやり方をしているのかを知ることで品質が上がる
可能性があるとの声からJSTQB-FLシラバス説明会を開催する
・Excelベースのレビューチェックシートだと使いづらいとの声からMicrosoft Copilotを
使ってWebベースのレビューチェックシートを作成する
・検討不足/考慮漏れの多いプロジェクトには何が原因だったのかを突き詰めていき
知らなかった/気が付かなかったと人によって知識の偏りがある可能性が高い
とのことでしたのでQAチームが保持するナレッジ資料を展開する
QAとして開発メンバーへ少なからず力添えができたかなと思っています。
まとめ
『品質の情報発信』をテーマに記事を書かせていただきました。
振り返ってみると人に何かを伝えるためには大量のインプットを行って
必要な情報を取捨選択してアウトプットしています。
アウトプットしたことで受け手からの何かしらのリアクションも受け取れるので
結果的に人に教えているようで自分が一番成長できているよなと思っています。
ギブ&ギブの精神で今後も何かしら情報発信をしていこうと思います。
以上、QA担当【yo】がお送りしました。
ecbeing では、新進気鋭なエンジニアを募集しています！ careers.ecbeing.tech
