「この1冊でよくわかるソフトウェアテストの教科書: 品質を決定づけるテスト工程の基本と実践」
を読み、個人的に品質管理についての解像度が上がったので共有いたします。
【結論】
普段、デバッグの業務をするだけでは気づけないようなポイントが数多く紹介されていました。それと同時に、実際の業務に落とし込んだら、品質管理がもっと良くなるという確信を得ることもできました。
7ページ～
ソフトウェア関連のトラブル事例として挙げられているケースの一つに、新型コロナウイルス接触確認アプリ「COCOA」をAndroid端末で利用した場合、通知が来ないようになっていた。
この障害が発生した原因として、
・急激な新型コロナウイルスの拡大に伴い、急ピッチで開発が進められた
→通知が来ないという障害が発生し、本来の役割を果たせなかった(短納期開発に潜むリスクが顕在化した)
と説明されている。
https://www.mhlw.go.jp/stf/newpage_16532.html
【感想】最近のことなので、聞き覚えのある話題だと思います。実際に使っていて、バグがあるなと思った方もいらっしゃると思いますし、潜在的に察していて、気づいた頃には使うのをやめていた方もいらっしゃるかもしれません。
11ページ～
品質要素を「当たり前品質」「一元的品質」「魅力的品質」の3つに分類したもののことを「狩野モデル」といいます。
「当たり前品質」：充足されていて当たり前であり、不充足の場合は不満に感じる機能のこと。
「一元的品質」：充足されていると満足し、不充足の場合は不満に感じる機能のこと。
「魅力的品質」：充足されていると満足し、不充足の場合は「仕方がない」と感じる機能のこと。
【感想】品質を担保するといっても一つの基準しかないわけではないということを言語化されています。開発者は、どの機能がれに該当するのか、早めに知っておくべきですし、常に固定とは限りません（例えば、一元的品質だったものが当たり前品質に変わることもあります。）
78ページ～
同値分割テスト、境界値テスト
同値分割テスト：テストの工数を減らす方法。電話番号(国際電話などを除き、10桁か11桁しかない)を例に使うと、弾かなければいけないのは0~9桁と12桁以上なので、「0~9桁」と「12桁以上」から1通りずつ、計2通りのテストをすればよいとする考え方のこと。
境界値テスト：欠陥は協会に潜んでいる可能性が高いので、仕様条件の境界となる値とその隣の値に対してテストを行うテスト技法。
【感想】デバッグを行うときに、他よりもリスクが高いポイントと、外してはいけないポイントを教えてくれています。
152ページ～
組み合わせテスト
複数ある設定を組み合わせた場合の動作確認も必要。「単一の条件だけでは発生しないが、複数の条件が組み合わさった際に発生する欠陥」を見つけるため。
【感想】網羅的に確認することの重要性と同時に、ここは外してはいけないというポイントを教えてくれています。
253ページ～
記述の粒度
あまりに簡略化した抽象的な記述だと、読み手によってさまざまな解釈ができ、誤解が生じる危険性が高まる。ただし、詳しく書いてあるほど良いわけではない。適切な記述の粒度で、文書に起こすことが求めれる。
【感想】特に我々の会社では、昨日に詳しくないアルバイトさんがデバッグを担当することも少なくありません。そういった方々が作業を詰まらせることがないように、必要最低限かつ簡潔に「やってほしいこと」が書かれていなければならないんだと改めて感じました。
270ページ～
不具合報告書
良い例と悪い例が挙げられていました。
・開発者が、一目見て内容が分かる
・検出環境（端末、OS、バージョン、ID+パスワードなど）
・感情的ではなく事実を書く
・適切なランク付け
・エビデンス（主にキャプチャ）
【感想】同じくデバッグに関することで、こちらは開発者ではなくデバッグの担当者が心掛けたいことになります。
必要な情報が伝わる簡潔な文章を書けるように、自分も勉強していきます。テクニカルライティングの技法を知ったうえで適切に使えるといいと思います。
309ページ～
テスト自動化
【書いてあったこと】人間が行っているソフトウェアテストを、コンピューターに実行させること。テスト実施工数の削減を目的とし、その先にある品質の強化、競争力の強化を目指して行われるが、工数やコストがゼロになるわけではないことを把握しておくべき。
【感想】人手には限界があるので、いずれ検討しなければいけないことだとは思います。他社の事例もキャッチアップしていきます。