Android Test Night #5 - Androidテスト全書の回の聴講枠に当選したので参加してきました。
会の間考えたことにハッシュタグをつけて流していて、いくつかリアクションがあったものがあったので、今回はその補足をする記事です。
前回のこの↓記事同様エモーショナル強めの内容になってしまうのですが、テスト(あるいはチーム開発)どうしていくよ?という話題でもあるのでこちらのブログで書きます。
前提
- Android派のAndroid/iOSアプリテスター
- 週4勤務(10:30-18:00)のアルバイト
- 過去に業務系/Web/Androidアプリの開発とWeb/Androidアプリデザインの業務経験あり
- 自動テストやCI/CD環境は開発者がやってくれます
本題
QA側から「やるやら」を宣言しておく話
自分はホワイトボックステストをやらないと(理由も明確にして)宣言していて、絶対にパッケージングされたアプリでテストするぞと言っていると自分がアサインされる頃にはCI環境ができているか設計中とかでとてもいいです #android_test_night
— wifeofvillon (@wifeofvillon) November 30, 2018
前提に書いた通り今の職場にはバイトとして参加しているのですが、スキルセット的に本来開発者がすべき作業までやれてしまうことがあります。
スタートアップで人員も少ないのでそれ自体はいいことだと思うのですが、
- ブラックボックステストはパッケージングされたアプリですべきだと思う1
- コードを読んでしまうと2開発者に忖度してしまう
- 作業範囲が広がると体力がもたない3
などの理由から「ここまではやる」「ここからはよっぽどの非常時ならやる4」「これは絶対にやらない」をなぜそうしたい(したくない)のかも伝えた上で何卒よろしくと開発メンバーにお願い5しています。
各社の開発体制やQAの権限・待遇・スキルにもよるのですが、現在のプロジェクトでは今のところ開発メンバーからの納得も得られてい(ると思ってい)ます。
ドキュメント書くために開発が遅れるのは嫌だという話
昼間ちょうど「仕様の固まってない画面・フローのUIテストをどうするか」という話になって、開発者に仕様変更の都度カードにコメント=ドキュメントを書かせるのは時間がもったいないので、ある程度塊になってから渡してほしいという話を開発者としました
— wifeofvillon (@wifeofvillon) November 30, 2018
「QAがテストを書くことはないのか」という話題が出た時に呟いた内容です。QAがテストを書いて効果が上がるかは、繰り返しになりますが、開発体制とQAの権限・待遇・スキルにもよると思います。
そして開発体制次第では開発者からQAに仕様を伝えるのにめちゃくちゃコストがかかることがありうるとその日のちょうどこの日の昼間に思ったので開発者に伝えていました。
例えばユーザー登録のフローを画面ごとに分けて開発している場合、1画面できる度にこの画面はフローの中のこの部分でこれこれこういう動作をするからこれとこれを確認してね……というようなコメントをカードに書いてもらっていたら、開発者がコメント=ドキュメントを書く時間がトータルですごく長くなる6し、フローを細切れにした動作確認はそれこそ手動ブラックボックステストに不向きだと感じるので、この場合ならユーザー登録のフロー全部できたから、デザインがまだなのでそれ以外の動作を確認してね……くらいの大きさになってからmentionしてほしいと伝えています。
ということでQAがテストを書く話に戻すと、QAチームの中で例えばAppiumを使って正常系UIテストの一部を簡略化するのはスキルと待遇によってはアリだと思うんですけど、仕様が変わり続けている状態でかつ仕様を決める場にQAがいない場合、かえって効率が悪くなる可能性があるなと思います。
今のチームでは、QAへの仕様展開が不十分で手戻りが発生するの不健康だと思うなぁと伝えたところ理解を得られたので、最近は開発者に展開するときQAチーム(ぼっち)にも展開してもらえるようになったので完全にコミュニケーションの勝利です。
他所の手動テスト事情が知りたい
この前「テスターです」「自動化の人ですか?」「いえ手動です」って言ったら「つらいですね」って言われたんですけど他の会社のQAとかテスターの人がいたら話をきいてみたいです #android_test_night
— wifeofvillon (@wifeofvillon) November 30, 2018
今回書いたことについて「いや普通やろ」と思う人もいれば「スタートアップ&非正規雇用バイアスじゃん」と思う人もいるはずで、というか私の以前の職場やリアル知り合いにもソフトウェア検証や品質保証が主業務の人はけっこういるんですけど、手動テストのことを話す場って探しにくいというか、どう探したらいいのかわからん……しかし話を聞きたい……と数ヶ月くらい考えています。
おいしいものを食べつつ手動テストのことも話す会があったらぜひお誘いいただけると嬉しいです。
tl;dr
「は〜私開発よりQAの方が向いてる気がしてきた……テストやってる人の話が訊きたい……」と言い始めた頃に@usaganikkiさんから「君の場合外山さん @sumio_tym をフォローするといいよ」と言われて、今回も「は〜めっちゃ4章いいこと書いてあるな……」と思ってたんですけど、お話ししそびれたのでなんかこう強くなりたいなと思いました。
あとたまごサンドと唐揚げがめっちゃおいしくて貧血気味の体に染み渡りました。会場スタッフのみなさんもお疲れ様でした。
システムテスト自動化 標準ガイド CodeZine BOOKS
- 作者: Mark Fewster,Dorothy Graham
- 出版社/メーカー: 翔泳社
- 発売日: 2014/12/17
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
システムテスト自動化 標準ガイド (CodeZine BOOKS)
- 作者: Mark Fewster,Dorothy Graham,テスト自動化研究会,伊藤望,玉川紘子,長谷川孝二,きょん,鈴木一裕,太田健一郎,森龍二,近江久美子,永田敦,吉村好廣,板垣真太郎,浦山さつき,井芹洋輝,松木晋祐,長田学,早川隆治
- 出版社/メーカー: 翔泳社
- 発売日: 2014/12/16
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る
-
会中もCI/CD環境込みでテストすべきっていう話がありましたがまさにそれです↩
-
あるいは「何故できないかを知ってしまうと」↩
-
タフな働き方ができないので今の働き方に落ち着いています↩
-
リリース直前なのにWerkerのキューが溜まりすぎて処理しきれていないときに、ローカルで未mergeのPRをビルドするケースなど↩
-
納得してもらうための材料は普段から集めるよう心がけています↩
-
今のチームのメインプロダクトは全体の最新仕様を網羅しているドキュメントがなかったので私が手のすいているときに書いています See more: Pixelaを使ってGitHub Wikiの芝を生やした - びよーんのつま。↩