このエントリではゴリゴリの開発者ではない人間が、QAとしてアプリケーション開発チームに参加した後、実際にチームメンバーにお願いした内容を紹介する。
※この記事は以下のエントリ(英語)を和訳・追記したものです
medium.com
前提として
書いた人のスペック
ここ数年仕事としてソフトウェア開発はしてなかったけど、個人的にHTML5+JSベースのツールを公開したりはしていた。
求人票に書かれていた条件は次のような感じで、アプリケーション開発に関する知識は求められていなかった。
- 日本語と英語でコミュニケーションがとれる
- 文章でバグの内容を説明できる
そこへたまたま
- アジャイル＆GitHub/カンバン/チャットツールベースのプロジェクトを経験している
- GingerbreadかHoneycombくらいまでの古いAndroidアプリ開発の知識がちょっとある
- テストケースを自分で作れる
- MaterialDesign万歳
みたいなスキルセットで参加したので、1ヶ月ちょっと働いたあたりで「ちょっと待遇面について話そう」ということになった。そのときした話がこのエントリの元になっていて、待遇面の変化についてはまた別に書く。先に言っておくと時給が3割以上上がった。
どういう仕事をしているかというのはこの前別のブログに書いた。
growgrass.hatenablog.com
読んでみて欲しい人
このエントリは次のような人にとって役に立つかもしれない。
- チームが大きくなってきてQAを雇いたいなーと思い始めたマネージャー
- すでにQAと仕事をしていて、実機を使ったテストを依頼する開発者
- 元々開発やってて初めてQAとしてプロジェクトに加わる人
1. 開発者の事情は不必要に考慮したくない
当たり前なんだけどユーザーの大半は開発側の事情を知らないし、考慮しようとも思わないので、QAとしてはそういう実際のユーザーの気持ちを尊重していきたい。
例えばバグを報告したときに「KitKatではそのAPI使えなくて〜」とか「実装するのめちゃくちゃ難しくて〜」みたいな開発者側の情報は書いてもいいけど、それよりも先に「バグなのか仕様上しょうがないのか」「直すのか直さないのか」を答えてほしいという気持ちがある。
メンバーに誠実であろうとしてロジックとか閾値とかOS仕様を説明したくなる気持ちはすごく分かる。分かるけど私は読み飛ばしていくからな(後述)。
2. テストの方法や質問への回答を明確に書いてほしい
結果的にたまたま偶然開発知識がある人間が参加してしまったけど、QAとして開発知識を持たない人間を雇う利点は客観的なブラックボックステストができるということだと思う。開発側の事情に忖度して「これ変だけど仕方ないか」って考え始めるともう人の手でわざわざ端末操作して目視で確認する意義がなくなる。
あと本来読まなくていいものを読んだり、確認しなくていいものを確認したりするようになると、限られた時間内で上げられる成果が小さくなるので極力やりたくない。
何人かで協力してバグを修正したり新機能を実装していく中で、「これは他のメンバーのために残しておいたほうがいい」と判断した情報をTrelloのカードに追記するのはすごくいいことなのでやってくれていいんだけど、私がいちいち「誰向けの情報か」を判断せずに読み飛ばせるよう、開発者向けの情報とQA向けの情報は明確に区別して記載してほしいというお願いをした。
3. フォーマットは守ろう
ここまでに挙がったことはフォーマットを守ってコメントを書けば達成できるので全然難しいことじゃない。
- 確認してほしい環境(弊社の場合DeployGateのビルドバージョン)
- 確認してほしい箇所
- どうなっていてほしいか(もしくはその逆)
動作確認に必要な情報って基本これだけなので、開発メンバーの間で共有しなければいけない話は<hr>とか入れて区切るとかインデント下げるとか2秒でできる工夫をしてほしい。
以前はTrelloのカードにPull RequestのURLが貼ってあるだけみたいなカードでも動作確認していたんだけどあまりにも精神衛生によくないのと、純粋に効率が悪いので「今後はねーから！」宣言をした。これは具体的に言うと
- Pull RequestのMerge元のブランチ名を確認して
- ブランチ名から配布パッケージを探して
- Pull Requestのコメントを読んで再現手順を確認して
- 実機で動作確認をする
という手順で作業をすることになる。最初のステップで既にGitHubを使った開発知識がないと詰むし、PRに再現手順書いてるならそれカードにコピペするだけで私がリンク踏む必要なくなるよね？と念押しした。
ただ弊社環境、CIが止まってビルドされるまで時間がかかることがよくあるので、そういう場合はDeployGateの配布パッケージを書く代わりにブランチ名を書いてもらうようにした。
4. 変な質問をするかもしれないけど実装者を責めているわけではない
「変な質問」というのはほとんどが開発者にとって当たり前であることを確認するような質問で、もちろん実装者を責めているわけではない。実際にあった例でいうと「SMS送信の権限与えてないのにSMSに返信できるのはOKなの？」みたいな話。
人間は良くも悪くも慣れる生き物なので、ずっと同じ機能を実装していると慣れて見落とすことがある。「テスト用の文言を入れたままリリースしてユーザーに指摘される」みたいなミスは最悪だけどいろんな会社のいろんなプロダクトでよくある。そういうミスを防ぐためにPull Requestを送って複数人の目で確認してQAが実機で確認する、というプロセスを踏んでいるので、品質を上げるためだと思ってほしい。
最後に
デザイナーと開発者とQA、なんなら事務方を加えてもいいんだけど、みんな目指すべきゴールは「ユーザーの満足」なので、良いものができるように協力してやっていきましょう。
tl;dr
この日本語版を書いていて思ったんだけど、
みんな目指すべきゴールは「ユーザーの満足」なので
最後のこの部分を見失いがちなプロジェクトが巷にはすごく溢れているんじゃないだろうか。リーダーとか営業とか役員とかホールディングスとか受注元とかの顔色を窺って「いかに無難にそのプロジェクトを終わらせるか」が目標になってしまうケースは今までたくさん見てきた。
なので、こういう「ゴールを見失わないチーム」にいられることはとても幸せなことだし、できれば世の中の全てのチームが(業種問わず)そうなればいいよねと思う。
もちろんこういう気持ちになれるのは金銭報酬とか拘束時間とかの待遇に納得しているからなので、そういう合意を取らずに綺麗な目標だけ押し付けてくる職場は当たり前だけどよくないと思う。
