6ヶ月間、わたしがQAエンジニアをして悩んだこと
▼ 前回の記事
こんにちは、kubopです。note株式会社 Advent Calendar 2022の6日目を担当させてもらっています。
6日目というと… そう、QAが組織化して早いもので約6ヶ月が経過しました。
今回は、当時思っていたこと、それに対しやってきたことを中心に書いていこうと思います。6ヶ月とはいえ、信じられないくらい濃密な時間を過ごしました…。
私が当時悩んでいた事
QA組織がそもそも無かった。全てが0ベース。
「品質文化？何それ美味しいの？」
私自身、QAをしたことがなかった。QAと働いたこともなかった。
「QAってマジで何？」
MTTRがちょっぴり長く、クリエイターさんにご迷惑をかけることも。
「MTTRって久しぶりに聞いたな。」
安心出来る状態でリリースできていなかった。
「リリース時の検証って、なにすればいいの？」
E2Eテストが30-40分もかかっていて皆ぐったり。
「いちいち回すのが面倒だし、テストケースが複雑でわからない。」
機能要件ってQAがどう入り込むの？
「Question Asker」って何。
メトリクスって何をとって、どうすれば分析できるんだろう。
「まずはデータ取らないと始まらなくない？」
全体に関わる施策が多すぎて、全員の同意がとるのが難しい。
「コミュ力って本当に難しい。」
QAについて学んで、シェアする
QAエンジニア初挑戦するぞ！
まずQAが如何なるものなのかを調査することから始めました。
とはいっても調べ方が全然わからない…と思ったので本を読んだり、勉強会に参加しまくることにしました。
具体的に参加したのは、Jasst nanoやQUES、スクラムフェスなど、connpassにあるQA関連のものは片っ端から参加していました。
時に「QAエンジニア」で検索してそれに全部参加応募していたこともあります。
特にJasst nanoのアーカイブ動画は、2-3回繰り返してみたものもあります。
スクラムフェスにある、QA関連のものは社内で実況中継したりしていました。
そんななか、わずかな光明が見えたのはこちらの動画。
この動画にかなり影響をうけて、noteを書いたりしました。
また、こちらの講演がかなり刺さりました。
品質文化を作るぜ！
品質文化醸成のため、まずは認知だ！と思い毎週欠かさず週報を書いています。その中では、以前発生した不具合や今週おきた出来事、さらにはチーム一人一人のひとことまで添えて毎週作成していました。
そんな中で、TotTと(Testing on the Toilet)いうGoogleの取り組みを知り、「俺もやるしか無い！！」と奮起して週報に加えてクイズを出し続けていました。
QAの知識をちょっとずつみんなにわかって欲しい、QAってこんなことするんだよっていう事を伝えようと思って始めました。
まだ無いフローを考える
来たる障害に備えるべし！
MTTRを削減、という前に現状のMTTRを計測し、フローを定義しました。
フローを定義・自動化したおかげで、今では緊急！！となった時は素早く対応出来るようになりました。
安心してリリース出来るようにせよ！
リリースが自由に行われ、検証が行われているのかわからない…といった状態からフローを定義し、整理、さらにE2Eテストを爆速にしました。 全員から同意を得るため、あちこちへ出張して説明をしたり、時にヒアリング会をして納得感の共有が出来るようにしました。
２度同じ不具合を起こさないようにせよ！
同じような不具合を起こさないよう、パターン分析をしており、「よくここで不具合が起きそうだなぁ・・・」というのを分析していました。
なかなか同じパターンにならなかったり、ちょっと違ったり、開発者に浸透していなかったりして難しいですが、issueをひとつひとつ見てコードを見ていました。
まずはデータを取らないと・・・と思っていたのですが、メトリクスの制定にかなり時間がかかりました。「取るぞ」といって取れないのがデータ。初めに決めることが肝要。
サイロを崩す
エンジニア全員と仲良くなるぞ！
QAとエンジニアのサイロ問題は深刻です。
アクターにならずに客観的に品質やプロセスを指摘できる代償に、エンジニアとは隔絶された世界にいってしまいます。
そのため、新しく入って来られた方と2on1(QAチームと)をしたり、毎週火曜日16:00にQA Teatimeをしたりして誰でもWelcomeな場を作っています。
実際に話してみると、問い合わせをしたりする時に顔見知りであるため話しやすかったり、今何に困っているのかを知れてとても良いです。
QA会をやってみよう！
noteのQAチームはTEとして活動することはほとんど無く、だいたいプロセス改善をしていました。
しかし、やはりエンジニアとのサイロを感じずにはいられませんでした。
私としては、仕様検討段階からQAエンジニアが介入し、シフトレフトを実現したいと考えていました。
そのため、QAに依頼すると不具合を見つけてくれる！という信頼感を構築するのが一番良いと思いました。
実例マッピングをして仕様漏れをなくそうとしたり、お触り会をするためにテストケースを作成して不具合を発見出来るようにしました。
来たる仲間に備えるべし！
ここまでnoteのQAとして色々な事をしてきました。
ただ、色々な事をやりすぎて「なにをしてきて、なにを残さなければならないのか」がわからなくなりました。
そのためQAオンボーディングを作成し、新しく入ってくれた仲間に伝えられるようにしました！
こんな感じでnoteのQAが、6ヶ月間全力で走り切った様子や想いを全てこのオンボーディングに込めました。
あとは仲間が増えていき、どんどんnoteのQAを浸透させるだけです。
最後に
私は新卒からサーバサイドエンジニアをしてきてはいますが、QA歴は6ヶ月のまだまだ新米のひよこちゃんです。🐥
サーバサイドエンジニアをしていた時は、コーディングを仕事としていましたが、打って変わってコーディングはしなくなり、やや物足りなさを感じていました。
ですが、そんな私はずっとこんな事を実現できたらいいなぁと思いQA活動をしてきました。それは、
エンジニアが最高の品質で最速でクリエイターに価値提供が出来るようにサポートする事。
クリエイターが気持ちよくnoteを使えるようにサポートする事。
それらのサポートを、QAエンジニアの知識に裏付けられた方法で成し遂げられるようにする事。
です。
まだまだ全然QAの知識は無いですが、これからもより良い品質を目指して、頑張っていこうと思います。
次回の記事は、manbaさんの「noteのインターンで学んだことを書きます」です。
※ この記事はnote株式会社 Advent Calendar 2022の6日目の記事です。
この記事が気に入ったらサポートをしてみませんか？