2019-07-30

QAを１年間やってみての振り返り

こんにちは。カメゾーです

1ヶ月ほど前から、リモートでのメンタリングを始め、序盤は初歩的な指摘が多かったのですが、少しずつより本質的な指摘をする場面が増えてきました。
その中で、昔は自分もこんな風にやってたなぁと思うことが多々あるので、今回はQAという仕事を始めてからの振り返りを書いていこうと思います

「QA」という未知との遭遇

2017年の4月に現在の会社に入社し、技術部の先輩方の自己紹介を聞いていて、「QA」という単語を始めて耳にしました。QAという職種について軽く説明していただきましたが、ゲームのバグ出しのように、ひたすらゲームを触って色んなことを試す感じなのかな、程度の理解でした。

ある時、手が空いていたということもあり、QA業務を手伝うことになりました。
初めて実施したテストは、エクセルファイルをアップロードして、データを一括で登録する機能のテストでした。
具体的には、アップロード画面の文言間違ってないか、アップロードに何秒かかるか、この操作をした時エラーになるか、このボタンが表示されるか、など、初歩的なテストで、人によってはつまらないと感じる内容かもしれませんが、僕にとってはテトリス的な楽しさを感じました。機能を分解して、1つずつ確認していく作業が合っているなーと思っていました。

失敗から学んだこと

QAチームにJoinし始めの頃は、ただただテストをしているだけになっていたと思います。テストケースに沿ってテストをして、期待値と違う結果になれば不具合として報告する、作業をこなしているだけになっていましたし、それが間違っている、と思っていませんでした。
ある時、お客様から不具合報告があり、その内容を見ると、ついこないだリリースした機能が原因となっていました。。。テストをしたから大丈夫、と思い込んでいた僕は、これまでやっていたことは違っていたと痛感しました。要は、ユーザーにとって良いものとなっているかをQAはチェックしなければならず、テストケースはあくまでこういうことを確認した、というエビデンスに過ぎないということを悟りました。

QAの次に使うのはユーザーである、という視点

どこかのイベントで聞いた受け売りですが、今回振り返りをして改めてこの視点に気づかされました。
開発者が実装した機能はQAが確認しますが、QAである僕がテストした機能は誰にも確認されず世に放たれていってしまうのです。既存のユーザー、未来のユーザーが使い続けるであろう機能と考えると、やりがいがある反面、ちょっと恐ろしいなとも思えてしまいます。
さらに、もし、テストしている中で自分だけが気になったことを放置してみようものなら、それが原因でバグが起きた時の精神的ダメージは計り知れません。そして後悔しながらテストする悲しみもあります。

バグがない事が普通なので、バグ起きなければ安心、バグが起きたならdead、というハイリスクローリターンな仕事ですが、その分やりがいもある仕事だと改めて感じました。今回は自己満記事になってしまいましたが、これまでの思考を整理できよかったと思います！日々の業務で忙しいとは思いますが、皆さんも是非書いてみてください！

2019-07-09

リモートでメンタリング、はじめました。

こんにちは。カメゾーです。

最近、7pay問題で、QA界隈はざわざわしていますが、社会を風刺したいい感じのブログとか書けないので、普通の内容で書いていきたいと思います。

2ヶ月ほど前に、大学4年生の学生がアルバイトで弊社のQAチームにジョインしました。しばらく、メンターがいない状態だったためメンターをつけることになり、ほとんど会話したことがない僕がメンタリングすることになりました。
しかし、僕は東京オフィス、彼は沖縄オフィスに出社しており、物理的距離を解決するため、リモートでのメンタリングという~~無茶振り~~非常にチャレンジングな施策を打つことになりました。
なので今回は、リモートでのメンタリングをするにあたって、考えたことや実践していることについて書いていきたいと思います。

考えたこと

3ヶ月の目標立て

最初は、メンター（僕）側で、業務目標と業務外の目標（人間性の部分に関わるところ）をざっくり立てました。業務目標については、各月の目標を定め、業務外の目標はメンティと話しながら決めていきました。

関係性構築のために、Zoomを繋ぎまくる

関係性が築けていないと、メンティから質問が来なかったり、不安なことを吸い上げられなかったりするので、以下のタイミングでZoomを実施することにしました。

朝一に今日やることの確認
朝の段階で、今日のタスクを進める上で障害になりそうなことを潰しておき、Zoomが繋げられない時でも一人で仕事を進められるようにしています。
夕方にその日の振り返り
「今日やったこと」「うまくいったこと」「うまくいかなかったこと」「不安なこと/気になること」を書いてもらっています。これに対し、フィードバックがあればしていくのですが、文字でフィードバックや注意されると結構怖いです（実体験）なので、Zoomで会話しながら、納得のいく振り返りになるようにしています。
それ以外に、両者Zoomができる状態の時
まだ環境に慣れてない頃は、「これって聞いていい事なのかな...」「何からやっていいのかよくわからない...」「聞きたいことあるけど、忙しそうで声を掛けにくい...」など、質問していいのか戸惑うことが多々あります。（皆さんもそういう時代があったと思います）そういった疑問が生じる度に何十分も手が止まるのは非常に勿体無いので、Zoomを繋ぎっぱなしにしておくことで、気軽に声をかけやすいような環境にしています。

リモートでやることの気になる点

今どんな状況かがわかりにくい。
結構パツパツなのか、ちょうどいいのか、余裕かましているのか、ここら辺が見えにくいので、どれぐらいタスクを振っていいかとかがわからないです。
作業をしていることはわかるが、どんな風に作業しているのかもわかりにくい。
あくまでも例えですが、右クリックでコピペとかしてないよね？、めちゃくちゃゆっくりタイピングしてないよね？みたいなところが見えないので、根本解決に向けたフィードバックがしにくいなぁと思いました。
業務時間内でしか交流できない。
いわゆる飲みニケーションができないってことですね。メンティのパーソナリティがわからないので、業務外の事情を考慮できずにフィードバックしてしまうんじゃないか、という漠然とした不安は常にあります。

2019-06-30

QAプロセス改善の取り組み

こんにちは。カメゾーです。

今回は、少し前にやったQAプロセス改善的な取り組みについて書きたいと思います。

経緯

QAの主な仕事は、毎月の定期リリース前のテストです。お客様や社内から不具合報告や新規の要望がきた際、改修/実装判断もQAチームで担当しています。改修/実装GOが出るとチケットを起票し、ざっくりとした方向性を開発チームに伝えて、チケットを回します。そして、リリース1ヶ月前には次リリース対象を決めて、QA期間（2-3週間）に突入します。

しかし、QA期間に入って初めてどのように改修/実装されたかをQAチームは知るため、類似機能との仕様差異が生じていたり、改修内容の認識が開発チームとQAチームでずれていたりで、QA期間中の差し戻しが多くなってしまうことがありました。差し戻しによって、QA期間が延びてしまうことや、再修正が間に合わずリリースを見送ることになってしまうことがありました。

やったこと

QA期間中の差し戻しを発生させないためには、最初からどういう風に改修/実装してもらうか伝えたらいいのではと考え、「チケット起票の時点でテストケースを書く」ということを実施してみました。

結果

実施前

7件 / 18件（差し戻し件数/リリース対象総数）

実施後

1件 / 23件（差し戻し数/リリース対象総数）

うわ・・・差し戻し件数、減りすぎ・・・？と思わず言いたくなるほど効果が出ました。とりあえずやってみようか〜という感じで実施してみたので、まさか本当に減るなんて...という気持ちでした（笑）

テストケースを事前に書くことで、開発チームとQAチームの間で認識のズレが起きることもなく、改修/実装中に問題があればその時点で開発の方からQAチームに連絡が来るため、早い段階から軌道修正することも可能になりました！

今後に向けて

しばらく運用を続けてみて、新たな問題が発生しました。それは、テストケース作成待ちのチケットが溜まってしまい、開発チームへチケットを回すスピードが遅くなってしまったことです。（そりゃそうだろ、なんて言わないでください）

リリースまでのスピードとリリース後の質が担保できるよう、今後も色々と試していきたいと思います！