プロダクトのスケールと品質をどう両立すべきか 10X 、LayerX 、AutifyのCTOに訊く品質保証の本質 を読んだ
QAの専任のメンバーは今はいない状態です。プロダクトマネージャーのメンバーがテストを取りまとめてくれていて、カスタマーサクセスのメンバーや、それこそソフトウェアエンジニアやデザイナーを巻き込みながら、みんなでテストをしているのが現状ですね。
専任のQAメンバーがいない場合、↑↑みたいな感じでテストすることもあるのか。なるほど。
上から下からみたいな話がテストではよくあると思います。E2Eみたいなかたちで、ピラミッドの上から攻めていく。ただ上からだと、テストの局所性があまり取れません。
「なんでこれバグったんだっけ？」がわかりづらかったりするので、下の単体テストから攻めていく方法があると思うのですが、下からやるとメチャクチャエンジニアリソースを食ってしまって、速度にけっこう影響すると思っています。なので、今は上からメインでテストをやっています。
そう、単体テストはとても大事なのだけど、エンジニアの負担が大きいと思うので、最初はこういう戦略アリだと思う。あるいは、単体テストよりも少し粒度の高いAPIテストから始めるとか。現実的に割くことのできるリソースを考えながらテスト方針を考えるの、ちゃんとできていてすごいなと思った。
そもそもスピード、スケール、品質はトレードオフだとはあまり思っていなくて、品質を上げることこそが開発速度を生む面があると思っています。障害対応にけっこう時間が取られてしまったり、質の低い挙動によって時間取られたり、遅くなったりということも大いにあると思います。
これは僕も同意。例えばテスト自動化の場合は、プログラマへのフィードバックが早くなるから、その分だけ不具合の検出が早くなり、不具合修正工数が減る。そうすると、削減した工数の分だけ早くリリースできるようになる（もちろん、リリース時期はそのままにして機能を追加開発したりディープなテストに費やしても良い）。早くリリースすると、ユーザーからのフィードバックを早く得られるようになるので、最終的にプロダクトの競争力が高まる。品質に力を入れることで、攻めた活動がしやすくなるのだと思う。
なので、入ってもらいたい方はそこのバランスが取れる方ですね。ちょっと一歩引いた目線で、サービスの品質を考えられる方。顧客に価値を届けるってどういうことだっけみたいな議論ができて、「この機能はそもそもいらなくない？」「このほうがシンプルじゃない？」「なんでこうしないの？」みたいな話ができる方ですね。
今の事業にとって大事なものが品質なのか、スピードなのか、機能性なのか、、をきちんと把握しておくと、的を射る意見が言えるようになるのかなと思った。ここ、今の自分はちょっとできている気がしないので勉強になる。
「スピード感のある開発をどう実現するか」を意識することで、QAとしての自分にできる活動が少し広がる気がする。
