テスト自動化を始める前に、アジャイル・DevOpsチームが考えるべきこととは？ アジャイルテスティングの実現に向けた分析と戦略 を読んだ
全体的に参考になりそうだと感じた。
テストと品質の現状分析、業務の整理をするときに便利そう。
テスト自動化におけるゴール設定はとても大切です。ゴールを明確にしなければうまくいっているかどうかもわかりません。
テスト自動化の戦略を建てる上では、やっぱり期待・目標・課題感を言語化しておくのが大切だよね。そう、テスト自動化自体はすぐに始められるかもしれないけど、ちゃんとできているのかを確認するためにゴールが必要。
しかし、単体テストの実装が少ない現場では、なかなか単体テストのカバレッジを高めるのは難しいはずです。そういう場合は、一時的にUIテストでシステムやサービスを包み込み、壊れてもすぐ気がつけるようにしてから、単体テストやAPIテストのカバレッジを高めていく作戦もあります。
テスト自動化の戦略については、ここが勉強になった。
LayerXのQAへの取り組み〜アイスクリームの誘惑に負けるな〜 を読んだ
プロダクトのスケールと品質をどう両立すべきか 10X 、LayerX 、AutifyのCTOに訊く品質保証の本質 を読んだ
QAの専任のメンバーは今はいない状態です。プロダクトマネージャーのメンバーがテストを取りまとめてくれていて、カスタマーサクセスのメンバーや、それこそソフトウェアエンジニアやデザイナーを巻き込みながら、みんなでテストをしているのが現状ですね。
専任のQAメンバーがいない場合、↑↑みたいな感じでテストすることもあるのか。なるほど。
上から下からみたいな話がテストではよくあると思います。E2Eみたいなかたちで、ピラミッドの上から攻めていく。ただ上からだと、テストの局所性があまり取れません。
「なんでこれバグったんだっけ？」がわかりづらかったりするので、下の単体テストから攻めていく方法があると思うのですが、下からやるとメチャクチャエンジニアリソースを食ってしまって、速度にけっこう影響すると思っています。なので、今は上からメインでテストをやっています。
そう、単体テストはとても大事なのだけど、エンジニアの負担が大きいと思うので、最初はこういう戦略アリだと思う。あるいは、単体テストよりも少し粒度の高いAPIテストから始めるとか。現実的に割くことのできるリソースを考えながらテスト方針を考えるの、ちゃんとできていてすごいなと思った。
そもそもスピード、スケール、品質はトレードオフだとはあまり思っていなくて、品質を上げることこそが開発速度を生む面があると思っています。障害対応にけっこう時間が取られてしまったり、質の低い挙動によって時間取られたり、遅くなったりということも大いにあると思います。
これは僕も同意。例えばテスト自動化の場合は、プログラマへのフィードバックが早くなるから、その分だけ不具合の検出が早くなり、不具合修正工数が減る。そうすると、削減した工数の分だけ早くリリースできるようになる（もちろん、リリース時期はそのままにして機能を追加開発したりディープなテストに費やしても良い）。早くリリースすると、ユーザーからのフィードバックを早く得られるようになるので、最終的にプロダクトの競争力が高まる。品質に力を入れることで、攻めた活動がしやすくなるのだと思う。
なので、入ってもらいたい方はそこのバランスが取れる方ですね。ちょっと一歩引いた目線で、サービスの品質を考えられる方。顧客に価値を届けるってどういうことだっけみたいな議論ができて、「この機能はそもそもいらなくない？」「このほうがシンプルじゃない？」「なんでこうしないの？」みたいな話ができる方ですね。
今の事業にとって大事なものが品質なのか、スピードなのか、機能性なのか、、をきちんと把握しておくと、的を射る意見が言えるようになるのかなと思った。ここ、今の自分はちょっとできている気がしないので勉強になる。
「スピード感のある開発をどう実現するか」を意識することで、QAとしての自分にできる活動が少し広がる気がする。
テストプロセス改善で93件あった市場バグが10件に！ ソフトウェアのバグを削減しよう【実践編】 を読んだ
そうそう、最近はこういう記事を読みたかったんですよ、という内容だった。
テストプロセス改善の手順について、きちんと言語化して構造的にまとめられているので頭の整理をすることができた。
特に大変そうなのがスポンサーシップの確立で、場合によってはテストプロセス改善は他部署にも影響が出る場合がある（今回の場合だとRedmineの導入だろうか）ので、旗振り役は影響力の大きい人がやると良さそう（なるほど、だから社長直下が好ましいと書かれていたのだろうか）。
↓↓は、なんかの役に立ちそうなので覚えておこう
調査の結果、点検をおろそかにしている企業では、不具合を発見できる確率が30～50％である。それに対し、適切に点検をしている企業ではこの値が70～90％にまで上がる。さらに、CMMI（能力成熟度モデル統合：Capability Maturity Model Integration）などの開発プロセスを評価するガイドラインを導入し、きちんとテストをする企業では最高で99.99％にまでなる
第三者検証に関するアンケート調査結果 2021年版 を読んだ
アンケート回答者は、主にリソース不足とスキル不足に課題感を感じている様子。一方で、コストや得られる効果が理由でテストの外部委託を敬遠している回答者もいた。
スキル不足に関しては、品質保証技術の教育に商機がありそう。ただ、セミナー形式だと（忘れてしまう、セミナー終了時点でモチベーションが消えてしまう、などの理由で）伝えた技術が実戦まで到達しない可能性があるので、現場で実際に活用しながら教えるような形式だと効果ありそう（なんだろう、コンサルとかコーチとか、そういう名前になるのだろうか）。
リソース不足に関しては、実際にテスト量が膨大な場合もあるし、実はテスト工数を過剰に見積もってしまっている、という場合もありそう。前者の場合は外部の力を活用しつつ自動化で少しずつ工数削減、後者の場合はコンサルのような形で外部の力を借りて工数を妥当なラインまで減らす、という対応が取れそうだと感じた。
コストオーバーによる外部委託不採用は会社の事情で仕方がないにしても、得られる効果が不明瞭、、というのは、第三者検証会社が商談で上手に説明できていなかったということなのだろうか。他の可能性として、回答者の職種がさまざま（SE、研究開発職の回答者が比較的多い）であるため、第三検証会社の活用をイメージしにくいと感じた回答者がいたのかもしれない、、とも思う。
テストの外部委託をしたことのない会社の立場から考えると、スキルに課題感はあるもののコスト的に外部委託を断念しなければならず苦しそうな感じがした。成熟した会社ならまだしも、スタートアップなどは「まずプロダクトを作る」というところに集中する傾向があるように思えるので、品質保証のスキルアップや活動改善にお金と労力を割きたくても割くことができない、という事情もありそう。
