徒然なるままに

学習メモがメインです

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

自分用メモ

最近テストについて学習しています。

現時点(2021/5時点)で品質/テストについて思っていることを書いてみました。現時点での思いなので、あとから「これ間違ってるじゃん」と「別の考えになった」とかなると思います。今後変化があったら変更していく予定です。

この記事は箇条書きになっていて取り留めのない記事になっています。文章化したかったのですが力尽きてしまいました。いずれ文章化...できると良いなあ。

品質の定義
テストの定義
品質向上活動を通じて楽しいこと
品質に拘る理由
これから先
まだわかってないこと

品質の定義

筆者が考えている品質の定義＝ユーザーに対して提供する価値を正しく届けられているかどうかの度合い。
- 品質が良い：顧客に届けるべき価値が正しく伝わっている。
  - バグがない/少ない、使いやすい、ユーザーの求めるモノ/コトに合致していて期待と現実にギャップが無い状態。
- 品質が悪い：顧客に届けるべき価値が正しく伝わっていない。
  - バグが多い、使いづらい、ユーザーの求めるモノ/コトに合致しておらず期待と現実にギャップが有る状態。
  - 狩野モデルでいう「当たり前品質」を充足していないに近いのかも知れない。
品質を考える上ではユーザーを常に意識しておく必要がある。
品質が悪いことは検知できても、品質良いことはなかなか調査しにくいイメージ。
- 使いやすさとユーザーの求めるモノコトに合致してたかはアンケートが一番調査しやすいのかも知れない。

テストの定義

品質活動の一つ。
筆者が考えているテストの定義＝不具合（正確には欠陥）があるかを検査する。
- ユーザーに対して提供する価値が正しく提供できるかどうか確認するもの。その手段としてテストを行う。
検査して品質の善し悪しを図るもの。テストだけを実施しても修正しない限り品質は上がらない。
- 欠陥を直すこと自体はテスト活動ではないと思っている。
- 動的テストにおいてはコードが品質を担保できるか検査する。問題のあるコードを修正することで品質が向上する。
- 静的テストにおいては仕様書が品質を担保できるか検査する。問題のある文章や画像等を修正することで品質が向上する。

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

自分が期待している動作を、実際にしてくれているとき。
リスクを伝えることやリスクを潰すことで感謝されるとき。

品質に拘る理由

品質が悪いと顧客からの信頼が下がる。
- 提供した価値が届いていないことに対して申し訳ない気持ちになる。
開発時テストをやってないと品質が悪く、運用/保守フェーズでのサポート担当は大変。
- サポート担当は顧客に価値が正しく伝わっていない場合、正しい方向へ誘導することが役割だとは思っている。
- ただ、品質が悪いことで顧客から指摘があり、そのたびに謝って神経がすり減っていく。自分が作っていないのに。
  - サポート担当からすると何でテストしてないの？なんでこんなものを出したの？と思ってくる。
- 開発元を信頼しなくなる。
  - サポート担当が開発元をから提示されるリリースすべき内容を一旦放置する。
    - バージョンアップの内容の不具合修正（パッチ）が来るのでパッチのリリースを待つ様になる。
- サポート担当の負荷を減らしたい。

これから先

品質を上げるための支援をしたい。
- 悪いところだけではなく、いい点も積極的に伝えていきたい。
  - 課題や懸念点といった、悪いところだけ伝えてもやる気落ちるとおもうから。
- 要件定義や基本設計といった早いタイミング、より上位のタイミングで品質が悪くなる可能性を少なくしていきたい。悪くなる可能性を早めに見つけたい。
  - ただし、懸念してたけど実際にはそんなに影響しなかったり大した問題ではないこともあると思う。悲観して行動しないことではなく、品質が低下する可能性を想定/認識しておくことを重要視する。
- 自動テスト
- 品質を向上/低下させないためにテスト自体を学ぶ。
  - 目的を達成する一つの手段としてJSTQB FLに合格する。
品質を担保することで、本質的にやるべき他の作業（課題解決など）に従事できる時間を増やす
チームの質も上げたい。どうすればいいかはまだわかってないし、そもそもチームの質って何かわかっていない。とりあえず上げる方法の一つはふりかえりかなと思っている。

まだわかってないこと

「品質」と「質」の違い
チームの質
組織の質
品質がいいことをどうやって検知できるか