ソフトウェアにおける品質/テストについて、自分が思っていることを取り留めもなく書いています。2022/3時点での考えとしてのスナップショットとして記事にしています。抽象的な部分もあるので、また見直したときに具体化していこうとしています。

前回の記事はこちらです。 tagoaskubeya.hateblo.jp

品質とは

筆者が考えている現時点での品質の定義＝ユーザーに対して提供する価値を正しく届けられているかどうかの度合い。

品質が良い＝顧客に届けるべき価値が正しく伝わっている。  
→Failureの発生件数が少ない、使いやすい、ユーザーの求めるモノ/コトに合致していて期待と現実にギャップが無い状態。
品質が悪い＝顧客に届けるべき価値が正しく伝わっていない。  
→Failureの発生件数が多い、使いづらい、ユーザーの求めるモノ/コトに合致しておらず期待と現実にギャップが有る状態。

この定義は今までの筆者自身の経験から考えているものなので、定義が正しいと思えるほどの自信は全くない。品質についてはまだまだ学習中。

設計と開発と品質とテストの関係

開発者がテストをすると「自分が作ったものに間違いなんてない」といった確証バイアスがかかりがち(筆者自身の経験)なので、テストの専門家は必要と考えている。

テストは不具合(Error, Fault, Defect, Failure)があるかを検査する。検査することで品質の良し悪しを測ること、ユーザーに対して提供する価値が正しく提供できるかどうかを確認でき、品質を上げるための支援ができる。

動的テストにおいてシステムが品質を担保できるか検査する。問題のあるコードを修正することで品質が向上する。
静的テストにおいては仕様書が品質を担保できるか検査する。問題のある文章や画像等を修正することで品質が向上する。

テスト活動だけでは欠陥を修正することは出来ないため、直接的に品質向上することは出来ない。テストを実施しても、開発側でコードを修正しない限り品質は上がらない。
そのため、品質の向上のための作業は開発チームにやってもらう必要がある。

また、設計とテストは不可分なのではないかと考えている。(ここでいうテストはCheckingとしてのテスト)
設計は何がどう動くか期待する結果を考える作業、テストは期待する結果がほんとに来るか正しいか確認する作業、と考えている。テストを考えれば設計できるし、逆もまたしかりで設計を考えればテストできる、というように強い関連性があるのではないか。テストを学べば設計にも役に立つかもしれない。

品質にこだわる理由

品質が悪いものをリリースした場合、運用/保守フェーズの担当者に負担が掛かる。

・自分が作っていないのに、リリースしたものについて顧客から指摘され、そのたびに神経を使う
・不具合改修、データリカバリ、顧客説明といった本質的でない作業が発生する
・なぜテストしてないのか？なぜその状態のものをリリースしたのか？と疑心暗鬼になる

別の点としては、提供した価値が正しく届いていないことに対してモヤモヤする。Failureが多いならば、例えばシステムでは本来「効率性」といった価値を提供しているはずのに、顧客はFailureが気になってしまい、提供している価値が見えづらくなってしまう。ほかのメンバーが「品質が悪い、テストしっかりしてないだ」と言っていた。そもそも品質って何？テストはどうやればよい？を考え始めた。

品質にこだわることで得られる効果

期待できる効果としては以下を想定している。

届けるべき価値を妨げる要因である不具合(Error, Fault, Defect, Failure)を可視化できることで、どこに問題があるかを把握できる
テスト工数が最適化できる
開発者が開発に専念できる
顧客からの欠陥(Failure)指摘件数を減らすことで、顧客からの信頼を減らさない
保守工数を増加させない

品質向上活動を通じて楽しいこと/うれしいこと

自動化しているとき。もともと何かを作り上げることや組み立てることが好き。そして、自動化に取り組んでいているときは、自動化することで面倒な作業の時間を減らせることを想像しているので、楽になる未来を考えて明るい気分になっている。
期待している動作と実際の動作が一致しているとき。テストを実施しているときに、一つテスト項目が消化しているときは達成感を得られるため。
テスト設計/実装しているとき。複雑なものを解剖してやってるぜ感を得られる。

手動テストと自動テスト

自動化できる部分は積極的に自動化していきたい。大前提として、テスト手法やテスト設計といったテスト活動の知識が必要。
そして、何でも自動化すれば良いわけではない。自動化の工数と自動化して得られる恩恵を考慮して自動化を検討する必要がある。例えば、リリースが少ないのであれば、毎度テストを行う必要がないので自動化による効果は薄い。クリティカルな部分は自動化の余地はあるかもしれない。リリースが多いならば、毎度リグレッションテストを手動でやることはコストがかかるため、自動化することによる恩恵は多いはず。

これから先の姿

開発者と協力しながら、品質向上を主としてチームをより良い方向へ進化させることができる存在になる。 理由としては、開発者の作業によって品質が向上できるため、そしてより良いものを作るためにはメンバー間が必要不可欠なため。

手段

チームの各メンバーの力を底上げする
- ふりかえり
  - カイゼンのサイクルを作り出す
  - 人/チームに影響を出すために行う
- スクラムマスターの知識(スクラムマスターの知識を持っていないのでこの辺はふわふわしている)
  - チーム/グループに対して支援する役割
  - 開発者が開発に集中するための支援を行う
自動化できる部分は自動化する
- 自動化計画、設計、実装
- CI/CDパイプライン
要件定義～開発のフェーズから品質を作りこむ(シフトレフトの実現)
- テスト容易性の検討
- レビューの実施
効果的なテストを実施する
- 計画、設計、実装
設計/コードの品質をレビューする
- プロダクションコードを理解することで品質を確認
- 最低限、軽微な修正はできる状態を目指す

まだ理解できていないこと

品質マネジメント(QM)、品質保証(QA)、品質コントロール(QC)、テスト活動の関係性
テスト自動化の手段と目的
- ユニットテスト、APIテスト、E2Eテスト、CI/CDなど
テスト計画やテスト分析でやるべきこと

徒然なるままに

学習メモがメインです

ソフトウェアにおける品質/テストについて思っていること(2022/3ver)