- DevOps式の最適化でリリース、デプロイ、イメージ管理、ロールバックのボトルネックを減らした後、ソフトウェアデリバリーで最も遅い箇所はテストとして残った
- 業界はテストそのものよりもQAチームをボトルネックと見なし始め、役割への期待は高まったが、待遇悪化、契約社員化、オフショアリング、雇用削減が続いた
- QA組織の解体は経験あるQA人材の士気をくじき、開発者が品質業務を自然に引き受けられない中で、低品質なソフトウェアの問題が大きくなった
- 品質管理は欠陥追跡、分類、調査、品質の擁護、エンドツーエンドテストのように、名前を付けて割り当てるべき実際の業務である
- 品質業務を組織化しなければ、問題を見つけて収拾する人は報われず、速く作って壊す側が繰り返し報われる構造になる
DevOps最適化の後に残ったボトルネック
- DevOpsの実務者たちは Theory Of Constraints を適用し、ソフトウェアデリバリーパイプラインと慣行を強く最適化した
- 手作業のリリース管理、デプロイ、イメージ管理、本番環境のロールバックは自動化の対象になった
- プロダクトバックログから顧客にコードが届くまでの過程で、価値の低い活動は取り除くか最適化すべきボトルネックとして扱われた
- その結果、ソフトウェアデリバリーで最も遅い部分はテストとして残った
- テストは継続的デリバリーが存在する理由でもある
- テストをより速くし、自動化し、並列化することはできる
- ある実践において最も価値のある活動がボトルネックなら、すでに最適に近い状態だという判断である
QAチームをボトルネックと見た業界
- 最適化の習慣は、テストそのものを越えてQAの役割にも適用された
- 統合テストとエンドツーエンドテストを単体テストへ縮小し、並列化しようとする動きがあった
- 人材面では、コーディングができないと判断された人たちを機能単位へ押し込むことも起きた
- 業界は、テストではなくQAチームがボトルネックなのかもしれないと考え始めた
- QAの役割への期待は高まった
- 給与は下がるか、他の役割に比べて上がらなかった
- 役割は契約社員化され、オフショアリングされた
- QAエンジニアの雇用を減らそうとする選択が続いた
QAの役割縮小が生んだ悪循環
- QAに残った人たちは、ますます不利な構造に置かれた
- コーディングが十分に得意な人や待遇に疲れた人はQAを離れた
- 他の人たちはQAに残った人材を「その分野を抜け出せるほど十分ではない人」と見なした
- 新卒者にQA分野を勧める人も減った
- 企業は「この機能はもう置かない、自分たちで何とかせよ」という形でQAと決別した
- この過程は、QAのキャリアを積んできた人たちにとって無礼で士気をくじくものだった
- QAの解体は低品質なソフトウェアの問題を拡大し、多くの組織はソフトウェア品質において誰が何をすべきか分からない状態になった
- QA機能を維持した組織も、すでに損なわれた分野の中で、その役割の居場所を見つけるのに苦労している
「テスター解雇」は解決策ではなかった
- より速いソフトウェアデリバリーのための「ひとつの奇妙な裏技」は、テスター解雇ではなかった
- QA分野を壊したことは、最悪の管理ミスに近い
- 数十年かけて発展したものを破壊した選択である
- 影響は何年もの間感じられない可能性がある
- 組織が問題を実感する頃には、意味のある復旧までさらに何年もかかり得る
- QAの役割で元々壊れていた部分は、いまだ解決されないまま残っている
- 業務の分担は起きず、開発者は追加の報酬、認定、評価制度なしにQA業務を喜んで引き受けるわけではない
- 高機能なQAチームと働いたことのある一部の人材は、その行動の一部をまねることができるが、より新しいエンジニアやマネージャーには何が欠けているのか分かりにくい
- 核心となる原則は、品質保証は仕事であるという点だ
- 他の仕事と同じく、「誰か」がやるだろうと仮定すれば失敗する
- 見えない仕事として放置するやり方も失敗につながる
ソフトウェア品質管理に必要な業務
-
欠陥追跡
- ユーザーがバグ情報を送ることができ、開発者がバグを記録できる仕組みが必要である
- バグは、何が間違っていてどれほど深刻なのかを説明する個別チケットである
- 修正作業そのものを説明するものではない
- 欠陥、再現方法、影響度を含める必要がある
- 最近一緒に働いたほとんどの開発チームは、このような欠陥を追跡していなかった
- 「どうせ直さない」「自分の仕事ではない」「新機能で評価される」といった理由は、低品質な結果を正当化しない
- バグ一覧を管理すること自体が仕事である
-
分類と優先順位付け
- バグ分類は、入ってくるバグを割り当て、優先順位付けし、整理し、分類し、重複排除するプロセスである
- 高・中・低の深刻度の基準を一貫して設けると、組織の助けになる
- かつてはこれを「バグ衛生」と呼んでいた
- どのチームがそのバグを担当すべきかを決めることも業務である
- うまく機能する組織は、外部からの圧力や組織再編の状況でより適切に対応できる
- 解雇があっても品質低下を段階的に管理する
- 組織改編時には特定のバグカテゴリを新しいチームへ引き渡す
- 停止された機能のバグを一括で破棄する
- 外部ストレスや組織改編がまったくないチームなら分類プロセスを無視できる、というのは冗談に近い
-
欠陥調査
- 再現はバグ管理において重要な部分である
- 誰かが「映画のチケットを買おうとしたが、できなかった」という報告を、「名前に非英語文字が含まれる顧客に対して、文字エンコーディングの問題が購入フローを壊した」という形に変えなければならない
- 「この問題は何回発生したのか」「ユーザーへの影響は何か」といった質問には、実際の人間が時間をかけて答える必要がある
- 欠陥調査は、バグバックログにエンジニアリング上の厳密さを適用する仕事である
-
品質に集中する役割
- 最終製品の品質に集中する人が社内にいることには実際の価値がある
- 品質は全員の仕事になり得るが、同時に誰かの仕事でなければならない
- 品質と速度の間の緊張には、品質を擁護する人が必要である
- テストツール、テスト品質、テスト計画には、できる限りうまくやろうとする、意見を持った当事者が必要である
-
エンドツーエンドテスト
- 複数のエンジニアリング組織で最も大きく一般的な問題の一つは、システム所有権である
- アーキテクチャの複雑度増加は、チームとアプリケーションを小さく保つ目的で行われたものであり、これは合理的な戦略になり得る
- しかしその結果、アプリケーションで最も重要な部分に空白が生まれる
- 平均的なチームは、エンドツーエンドレベルでの製品利用と検証をもはや行っていない。理由は難しすぎるからだ
- 製品がリリースされる前に、組織内で実際に使っている人がいるかを確認しなければならない
品質業務を無視したときに起きる組織問題
- 「私たちはアジャイルでリーンで動的だから、こうしたことをする必要はない」という反応が出るかもしれない
- 詳しく見ると、こうした業務はすでに組織内で起きている可能性が高いが、ひどいやり方で実行されている
- 自動車、銀行、医師のような他分野で「私たちは品質保証をしない」と聞くのは、良い経験ではない
- 品質活動を認識し、組織化しなければ、非常に悪い状況につながる
- 最も良心的な従業員たちが、最も苦々しい状態になる
- 品質問題を見つけ、頻繁に解決する
- それに対する認定は受けられない
- 品質上の懸念を提起すると、速度を遅くしようとする人のように扱われる
- 「速く動いて壊す」人たちが繰り返し報われるのを見る
- 自分たちが他人の混乱を怒りながら片付ける立場だと感じる
- このような組織では、気にかける態度そのものがキャリア上の不利益になる
1件のコメント
Hacker News の意見
キャリア初期の1970年代後半、IBM Hursley Park の Product Assurance、つまり QA 組織で働いていた。担当製品であるワードプロセッシングシステムをテストするためにコードとハードウェアを作り、テスト対象システムに対してテストケースを実行していた
見つけた問題は開発チームに一般的な説明だけで伝えた。開発チームにテストケースに合わせさせるのではなく、バグを直させるのが目的だった。その結果、ハイフン付き単語の改行とバックスペース削除でバグを3つ見つけると、開発チームはその領域のバグを4つ直すが、実際にこちらが見つけたものは2つしか直さない、という形になり、残っている実際のバグ数を統計的に推定できた
QA チームがない組織では、スニフテストという概念を導入した。たいてい1時間ほど、会社や部署の誰もが新機能を触ってみるセッションだが、機能は完成済みとされていても境界条件はほぼ必ず壊れていた。すべてのフィールドに
""を入れて送信したり、キーボードだけで UI を操作したり、大きなフォントやブラウザの110%拡大といった単純な条件を試すと、問題がよく表面化し、今ではもう驚きもしない小さな機能開発中は普通プログラマーだけがテストするが、そのやり方が実際のエンドユーザーの使い方と違うことがあるので、特に有用だ
15〜20年前、最高水準の QA チームに投資していた会社2社で働いたが、そのチームは本当に価値があった。QA は、開発者が問題に近すぎて思いつかないバグをうまく見つけ、製品も世界レベルになった
どちらの会社でも、リリースするかどうかの最終権限を QA チームが持つように上層部が定めていたことが重要だった
最近の会社は、開発者が自動テストを使い、コードカバレッジに過度に気を配るほうが良いと考えているが、100% のコードカバレッジがあっても客観的に動かない製品をあまりにも多く見てきた。自動テストが悪いという意味ではなく、人間の QA テスターをなくすことが問題だという意味だ
最近いた会社の QE チームは、テストを実行するために膨大な量のコードを書いており、テスト・認証対象のモジュールよりもコード行数が多かった
それでも、誰もが知っている大手ソフトウェア企業のテストマネージャーが、100% カバレッジを達成したのでもうテストチームは終わりだ、と宣言するのを聞いたことがある
そうした権限があっても、QA の大半が低賃金の契約社員で、指示されたことだけをする会社では、依然としてひどい状態だった
assertTrue(true)だけのテストを書く開発者を見たことがある。常にグリーンで、カバレッジは100%だ同じ人たちは、新機能を作れるのに、なぜテストを書かなければならないのかとよく聞いていた。そしてシニア QA が来て、全部壊していった。あるときは、1分間に F5 を50回押すと、バックエンドがデータベースリクエストを回し続けて
outOfMemoryで落ちるのを見つけた仕様をはるかに超える境界条件を見つけ出すことに誇りを持っており、その価値は十分にある。良い型システムが変更への自信を与えるように、優れた QA も開発者に自信を与える。特にゲームのようにインタラクションの多いアプリでは、単体テストと統合テストだけでパラメータ空間をすべて網羅するのは難しい
組織で最も良心的な社員たちが最も苦々しい思いをしている、という言葉はつらい真実だ。品質問題を見つけ、しばしば自分で解決しているのに認められず、品質への懸念を口にすると、スピードを落とそうとする人扱いされる
「素早く動いて壊せ」側はずっと報われ続け、気にかける人たちはその後始末をしながら怒りをためていく。彼らには、気にかけること自体がキャリア上の大きな損失のように感じられるが、実際にそうだからだ
DBA とインフラ組織も QA と同じ立場であり、近いうちに振り子がまた戻ってくることを願っている
ユーザーがバグを報告し、インターネット経由でアップデートを受け取れるのに、わざわざ多くの金と時間をかける理由はない、という計算だ。ゲームとソフトウェアが物理メディアからダウンロード中心に変わってからは、パッチのほうが安くつくように思える。もちろん、ひどいセキュリティ問題や悪いユーザー体験につながるが、上の人間が利益を最大化する限り、あまり気にしない
POC SaaS 製品を作っているなら、航空電子機器のマイクロコントローラー並みの品質は必要ない。あらゆるトレードオフにはリスクとコストが伴い、良いエンジニアはその違いを分かっているべきだ
QAチームの根本的な問題は、ITチームや管理部門と同じ。仕事をうまくやると、何もしていないように見える。
そのため、自分たちの仕事を「正当化」しなければならない状況が頻繁に生じ、それはたいてい指標への過度な依存から来ている。グッドハートの法則のように、その指標が何の代理値なのか、その仕事の本来の目的が何なのかを理解していないということ。
悪いQAチームは、言うことがあるように見せるために過度に揚げ足を取り、良いQAチームは品質を確認すると同時に、従業員がより高い品質を作れるよう訓練する。
人材全般に訓練不足があると感じる。少し前にフロントページに載った「95パーセンタイルもそれほど大したものではない」という記事（https://news.ycombinator.com/item?id=38560345）も、ほとんどの実務者は能動的に訓練したりフィードバックを受けたりしないので、どの分野でも上位5%に行くのは簡単だ、という内容だった。
企業はアマチュアのスポーツチームではなく、プロチームのように継続的に訓練すべきではないかと思う。採用も「すでにトップパフォーマーか」より、「この人をトップパフォーマーに育てられるか」で見るべきだ。以前の環境で成功したという事実は、新しい環境が大きく異なれば、思ったほど意味を持たない。
ソフトウェア品質に関する記事には毎回、エンジニアたちの広範な無関心を当然視するコメントが多い。状況によるが、人々は自分の組織の局所最適に合わせてただ流され、主導権を手放すことにかなり慣れているように見える。全面的に彼らの責任ではないが、無罪でもない。
反復作業を自動化でなくせばその人のポジションは消えるが、きちんとやると管理者からは一日中座って何もしていないと思われるので、正しくやるインセンティブが小さい。
バグ発見数で評価されていないので、数字を増やすためにくだらないバグを無理やり探すプレッシャーもない。
良い訓練には、技術職の中に十分に広く優れた人材が必要だ。最新技術をすべて知っている必要はないが、でたらめを察知して指摘できなければならない。FAANGも例外ではない。
この記事にも出ているが、本当の核心は、QAがほぼ常に事業部門や上級管理職からコスト部門に見えるという点だ。
コスト部門に見える組織では働かないほうがいい、という仮説を持っている。ボーナス、評価、尊重は常にお金を稼ぐ側に行き、コスト部門はより少ない人数でより多くの仕事を背負わされ、失敗の責任を押し付けられ、会社が縮小するときに真っ先に切られる。ITも同じだ。
この悪循環のせいで、QAのキャリアは、似たスキルで開発者になるより常に難しくならざるを得ない。優秀な人たちは疲弊して、できるだけ早く抜け出し、その構造が自己強化される。
アクセシビリティ、可観測性、良いロギング、テストインフラの改善、CI/CDの調整、安定性、より良いリンティングやアナライザの問題はどれも重要だが、報われるのは機能を素早くリリースしたときだ。
今年はチームとアプリに必要だと思って、そうした仕事に時間をかけすぎたので、年末の業績評価が心配だ。今では、なぜ他の人たちがこれらの仕事を避けていたのか分かるし、来年はもっと目に見える機能リリースに集中するつもりだ。アプリのバグには申し訳ないが、住宅ローンを返すには仕事が必要だ。
組織によっては、QA/QCがもたらす価値を本気で重視している。ソフトウェアより製造業でその傾向がよりよく見られたが、ソフトウェアは本質的により抽象的で、無駄を追跡しにくいからだと推測している。
本当に良いQAとは、楽な道を探す人ではなく、QAの使命を信じる人だ。結局、組織と個人がQAの精神を本心から受け入れるかどうかが価値を生むということで、形式的にだけやっているところも多い。
それでも構わない。より良く、堅牢にする仕事は楽しく、気持ちが落ち着く。壊す仕事はシニカルな人たちに任せる。
ボーナスなどが別のグループに行っても構わない。技術職として十分によい報酬を得ているし、そうした稼ぐ職種の多くは、たとえ実際にうまくやれたとしても、自分を本当に不幸にしただろう。
ソフトウェア品質、コードの保守性、良い設計は、その会社で長く働くつもりがあるときだけ重要だ。
数年後に次の会社へ移るつもりなら、目立つ仕事をして素早く昇進し、その経歴を使ってより高い給料の職場へ行くのが最適な経路だ。数年後にそのプロジェクトが壊れたり保守不能になったりしても、その頃にはもういないので関係ない。
スタートアップも同じように回っている。至るところに刻み込まれたグロースマインドセットが、まさにこのパターンだ。製品が5年後に保守不能になっていても、その時点ではすでにイグジットして現金化しているかもしれない。
そういう人たちを正確に非難するつもりはない。会社自身が使っている慣行であり、人々はそのルールに合わせてプレイしているだけだ。気に入らないし本当に嫌だが、理解はできる。
面白いのは、管理職や役員が離職率、会社へのコミットメント不足、静かな退職に不満を言う場面だ。自分たちが作った毒を自分で味わっているようなものだ。
5年後に技術的負債を抱えて生き残っているなら、多くのスタートアップにとってはむしろ良い問題だ。いずれにせよ5年持ちこたえたという意味だからだ。
QAエンジニアはデバッグも非常に得意なほう。パイプライン、ソース、テストディレクトリに手を入れ、アプリケーション開発とデプロイのほぼあらゆる面を扱う。
QAリードだったとき、パイプラインのエラーメッセージを読もうともせず、Slackで毎日文句を言うソフトウェアエンジニアをよく見た。パイプライン最適化のときも根本問題を無視し、その根本問題から出ている症状を、まるで魔法のように理解不能な問題であるかのように扱い、何日も推測で解決しようとしていた。
この記事にある QAエンジニアへの軽視 は誇張ではない。QA組織がある会社でも、エンジニアリング組織のような厳格な面接プロセスを設けていないことが多く、QAエンジニアは低く評価されがちだ。
QAを尊重するSWEは、本人がQAで働いたことのある人だけだった。軽視があまりに蔓延していたので、結局エンジニアリング組織に戻り、principal engineerとしてのシニアリティや管理職の役割を使って変えようとしたが失敗した。エンジニアリングは自分たちの思い上がりの先を見ることができず、リーダーシップも助けてくれなかった。
解雇される前に勤めていた会社の新しいCTOは、QAの必要性は自動化でなくせると言っていたが、それがどういう意味なのか、例は一つもなかった。良いソフトウェアを作ることに対して、上から降りてくる敬意のレベルはその程度だった。
Microsoftがこの問題が最も顕著に表れている例に見える。QAチームをなくした後、Windowsとクラウド製品のアップデートでバグが目に見えて増えた。
仕事でMicrosoftのソフトウェアとサービスを多用しているので、品質低下について何らかの形で代償を払ってほしいと思う。
個人的な経験かもしれないが、エンジニアリングのためのテストを実際に書くQAチームは見たことがない。
私が経験したQAチームは テスト計画 を作成し、それを手動で実行するか、まれに自動化されたブラウザ・デバイステストで実行していた。こうしたテストにも価値はあるが、単体テストや統合テストほどではないと思う。
このモデルでは、実際にはエンジニアリングチームがQAチームになり、別のQAチームはバグではないものをバグのように見つけてノイズを生み、提供する価値以上のコストを生むことが多かった。
うまく機能するQAチームのモデルを学びたい。手動テストは素晴らしいが、私の経験では限界がある。QAの人たちを貶めたいのではなく、自分の経験を共有しているだけだ。
PMや営業、ほとんどの開発チームよりも、ユーザーに見えるシステム全体を包括的に理解しており、どのボタンを押すと何が起きるかを正確に言える。悪いQAがノイズの源になるのは確かだが、悪い開発者・システム管理者・一次/二次サポートも同じだ。
受けている最中は本当に腹が立つが、成果物の品質はずっと良くなる。
以前のQAはたいていテストを書かず、コードを手動でテストしながら、ユーザーにはしてほしくないような変な行動をひと通り試していた。テストでは一般に捕まえにくい問題やバグを見つけていた。
今ではQAをユーザーに押し付けている。若い開発者たちと働いていると、QAという概念自体がだんだん見慣れないものになっているのを感じる。本番環境にバグが出て、「ローカルで触ってみたときはどうだった？」と聞くと、変な顔をされることが多い。型チェッカーを通ったのに、なぜリリースしないのか、という感じだ。
最近のプログラマーの効率は1分あたりのPR数で測られるので、バグを入れることは問題ではなく、むしろ好都合だ。誰かが本番環境で見つければ、数日後にそれを直すPRをまた出せるのだから。QAがあったら、この流れを台無しにしていただろう。
会社ごとにQA機能の実装方法は異なる。顧客に任せることもあれば、開発者・カスタマーサポート・手動QA・SDETに任せることもある。結局は、リーダーシップが品質をどれだけ重視しているか、QAをどう認識しているかにかかっている。
QAチームがあるなら、プロセスの早い段階で参加するときが最も成功の可能性が高いと思う。優れたQAチームなら、コードが書かれる前にバグを見つけるべきだ。参加が遅くなるほどバグの発見も遅くなり、「コード完了」とリリースの間でより強く圧迫される。QAチームには自動化の能力が必要で、手動テストを繰り返す代わりに新しいテストケースに時間を使えるようにすべきだ。
この記事はかなり身につまされる。QAはときに二級市民扱いされ、仕事をきちんとするための文脈を得られる議論から外される。優秀な人たちが開発やプロダクト管理に去っていくとさらに悪化し、下向きのスパイラルは実際に存在する。
ここで述べているのは リーダーシップの問題 であって、QAの有用性の問題ではない。
QAは初期段階に組み込まれないまま、テストインフラとテスト計画を作ることに時間を費やし、最後にコードの塊と48時間の承認スケジュールを渡され、極度のプレッシャーの中でサインオフしなければならなかった。
だが時には、問題領域を深く理解し、開発を実際に導くQA組織に出会うこともあった。開発と最初から最後まで並走し、品質を高めただけでなく、全員の時間も節約していた。
FoundationDB を作ったときは、品質とテストに執着に近いほど集中していた。そのため Flow という言語まで作り、任意の規模の FDB クラスターを決定論的にシミュレーションし、極端な条件をかけたうえで、システム属性の違反を示し、その違反を引き起こしたテスト実行を完全に再現できるようにした。
毎晩、数万件のテスト実行が行われ、新しいコードがなければ基本的にすべてグリーンになるところまで到達していた。赤になるテストはほぼ常に直近のコード追加が原因だったため、簡単に特定して修正できた。
そのおかげでチームは、新しく入れたバグがすぐに見つかると分かったうえで開発でき、リリース後に トランザクション処理システムの書き換え のような大胆なプロジェクトにも自信を持って取り組めるスピードにつながった。その結果、10倍の高速化も得られた。
結局、品質への集中がスピードにつながり、両者はまったく相反しなかった。これが孤立した現象だとは思っておらず、それが新しいプロジェクトへとつながったが、それはまた次の話である。