QAチームをなくすことは、実は悪い判断だったのかもしれない
- ソフトウェア配布で最も遅い部分はテストである。 継続的デプロイが存在する理由はテストにあるため、ここがボトルネックになるのは最適化された状態と見なされる。
- 最適化の習慣と行動は、QAチームをボトルネックと見てこれを取り除こうとする業界の傾向につながった。これによりQAの役割への敬意が薄れ、質の高いソフトウェアを生み出せない問題が発生している。
- 開発者はソフトウェア品質管理をきちんと把握していない。 多くの組織はソフトウェア品質の責任の所在を分かっておらず、QA機能を維持しているところでも、その役割の置き場所を見つけるのに苦労している。
ソフトウェア実践において品質を管理するために必要なこと
- 欠陥追跡: ユーザーがバグに関する情報を提供し、開発者がバグを記録できる方法が必要である。
- トリアージ: バグトリアージは、バグの割り当て、優先順位付け、整理、分類、重複排除などを管理するプロセスである。
- 欠陥調査: バグを再現することはバグ管理の重要な部分であり、実際の問題を把握して解決するためのエンジニアリング上の努力が必要である。
- 集中: 品質に集中する人が会社にいるべきであり、品質とスピードのバランスを取るために品質を擁護する人が必要である。
- エンドツーエンドテスト: システムの所有権の問題は複雑なアーキテクチャによって生じており、これは製品リリース前の実使用テストの不在につながる。
GN⁺の意見
- QAチームをなくすことは、長期的に見るとソフトウェア品質に深刻な影響を与えかねない管理上のミスである。
- ソフトウェア開発プロセスにおいて品質保証は重要な業務であり、これを無視したり軽視したりする姿勢は、結局は失敗につながりうる。
- この記事は、ソフトウェア業界におけるQAの重要性をあらためて照らし出し、品質管理に対する適切な認識と組織内での役割分担の必要性を強調している点が興味深い。
1件のコメント
Hacker Newsの意見
1970年代後半にIBMで製品保証業務を担当し、担当製品（ワードプロセッシングシステム）のテストコード作成とハードウェア構築を行っていた。開発チームにはテストケースを具体的には公開せず、一般的な問題点だけを伝えてバグ修正を促していた。この方法により、発見したバグと開発チームが修正したバグの不一致から、残っているバグの推定値を統計的に計算できた。
QAチームがない組織では、「スニフテスト」という概念を導入していた。これは会社の全員が新機能を短時間（通常は1時間）集中的にテストするセッションで、多数のバグチケットが作られる結果になった。単純なテストが問題を引き起こすことも多かったが、もはや驚くことではない。
15〜20年前に働いていた2社は最高レベルのQAチームに投資しており、彼らは開発者が思いつかないバグを見つけ出すことに非常に優れていた。QAチームは製品を出荷するかどうかを決める最終権限を持っていた。現在は多くの会社が、開発者が自動テストを書き、コードカバレッジに多くの時間を費やすほうが良い方法だと考えているが、実際には動かない製品を数多く見てきた。自動テストが悪いという話ではなく、人間のQAテスターをなくすことへの問題提起である。
組織で最も良心的な従業員は、しばしば最も不満を抱えている。彼らは品質問題を認識し、解決しようとするが評価されず、品質について語ると動きが遅い人のように扱われる。「素早く動いて物を壊せ」型の人たちが報われ続ける一方で、彼らは後始末をさせられることに腹を立て、組織内で気にかけることがキャリアの害になり得ると感じている。
QAはビジネスや上級経営陣によって「コストセンター」と見なされがちな傾向がある。「コストセンター」と見なされる部門で働くのは避けるべきだという考え方もあり、報酬と評価は常に収益を生み出す人々に向かう。QAはより少ない人数でより多くの仕事をこなし、失敗の責任を負わされ、事業をスリム化する必要があるときには最初に解雇される部門になり得る。
QAエンジニアは優れたデバッグ能力を持っている。彼らはパイプライン、ソースコード、テストディレクトリなど、アプリケーションのあらゆる側面で作業しており、ソフトウェアエンジニアがパイプラインのエラーメッセージを読まず、根本問題を無視し、解決策を推測することに何日も費やす場面も少なくない。QAエンジニアに対する軽視は記事で誇張されているわけではなく、QA組織がエンジニアリング組織ほど厳格な面接プロセスを経ていないため、QAエンジニアは劣っていると見なされがちである。
個人的な経験では、実際にエンジニアリング向けのテストを書くQAチームに出会ったことはない。ほとんどのQAチームは「テスト計画」を手動で、あるいはまれに自動化されたブラウザ／デバイステストで実行する。こうした種類のテストには価値があるが、「単体テスト」や「統合テスト」ほどではない。このモデルでは、実際のQAチームというよりエンジニアリングチームが実質的にQAの役割を担うことになり、QAチームはしばしばバグではないものをバグとして見つけて価値を下げてしまう。
マイクロソフトはQAチームをなくして以降、Windowsとクラウド製品でより多くのバグが発生するのを目撃している。