この記事はテックタッチアドベントカレンダー4日目の記事です。 3日目は taisa による GORM v2 触ってみた Major Features 編 でした。
SET (Software Engineer in Test) チームの @terunuma です。最近買ったおすすめの品は4サイクルの刈払機です。ちょっと重いですが、燃料がガソリンで調達しやすいし馬力があって背の高い草も刈り切れるのでオススメです。実家の雑草も簡単に一掃できました。
この記事は何
フロントエンドエンジニアから SET へ転身するにあたって読んだ書籍、スライド、テストソフトウェア（フレームワーク）などを紹介するものです。自分のようにテストに本腰を入れて取り組もうとした人が同様にテストについて調べる時の手助けになればと思い書きました。
テックタッチの SET はどんなことをするのか？
まだ SET となって数ヶ月ですが（そしてまだまだ手探りですが）、現在は以下のような業務に取り組んでいます。
- プロダクトの自動テストの実装・運用
- パフォーマンステスト、負荷テストの計画・運用
- ソースコードの CI への静的／動的テスト組み込みのサポート、実装、運用
- QA・自動テストなどを有効に取り入れた開発フローの設計・運用
一般的な SET が扱う領域だけではなく、QA エンジニアや PM が取り組むべき内容も含まれています。このような中で、自分に求められている役割が何なのか／何をどこまですべきなのかを把握するために様々な文献を読んでいます。
読んだもの
今回の本題です。書籍やスライドなど読んだ順で紹介していきます。
Making your UI tests resilient to change
UIテスト、要素の指定に class や id を使わずに label や text content を使ったほうがいいよというお話。
get the element with the class name
username-field...
"Wait," they say. "How am I going to find the element with the class name
username-field?""Oh, just open your devtools and..."
"But our users wont do that. Why don't I just find the field that has a label that says
username?""Oh, yeah, good idea."
ユーザーが見つけるものを基準にテストクエリを組み立てた方がよい、という主張。Kent 氏の Testing Library はこの主張を元に開発されていて、input に隣接する label やボタンのテキストを基準にクエリを書くことができる。
テストから見えてくる グーグルのソフトウェア開発
Google はどのようにテストをしているか、を紹介している書籍です。SET & TE がどのような仕事をしているか、の中にテスト手法や自動テストコードの実例、筆者の考えなどが混在しているので全てをしっかり読もうとするより流して全体を読むと読みやすいです。 個人的にはこの辺を押さえて読むとよかったです:
- テストを規模で分類している。Sテスト、Mテスト、Lテスト
- SET はチームで最も広い視野で製品を見ている
- ACC 分析でプロダクトの重要な機能を理解し、テストプランを立案する
- 付録A: Chrome OS のテストプラン、付録B: Chrome のテストツアー（自分でプランやテストツアーを作る際に非常に参考になる！）
エムスリーのQAチームが目指すもの
www.slideshare.net
エムスリーさんの発表スライド。 「低コストで高品質の製品を創り、高速リリースが可能な開発チームを創る」ために何をすればよいか？
- 開発プロセスに上流から関わる（最終QAの評価しかしない、はやらない）
- テストケース数やバグ検出数を KPI にせず、顧客に必要なテストにフォーカスして少ないテストで品質を保つ
- 開発者とQAエンジニアのフェーズ毎の役割表（とても参考になる表！）
テスト自動化の理論と技術と戦略：LINE Developer Meetup Tokyo #39 – Testing & Engineering
LINEさんが 2018 年に実施したテストのイベントのレポート。 にしさんの QA への取り組み方、テスト設計についてや LINE の現場・組織でどのように自動テストが導入されているかなど。
- 学術・理論面の話：にしさん
- 現場での技術の話：大園
- 現場での戦略の話：伊藤
テスト観点に基づくテスト開発方法論 VSTePの概要
https://qualab.jp/materials/VSTeP.130510.bw.pdf
PDF 資料。 NGT/VSTeP によるテスト観点図の記述についてなど。 従来の CPM （コピー＆ペースト＆モディファイ）法ではなく、テスト観点をモデリングするという発想。
所感
SET になろうと考え始めた当初は E2E テストのカバレッジを増やしたりマニュアルテストの自動化を進めていけば品質が上がるだろう、くらいの解像度でしか見えていませんでした。上述のような文献やドキュメントを読み進めていくにつれ、仕様・テストの全体像を知ることや必要なテストケースを取捨選択するなど戦略に基づいての運用・実装が必要であるという理解を得ることができました。
目の前のテスト自動化などのタスクに盲目的に取り組み忙殺されるのではなく、プロダクト開発の戦略上で有効なテストを自分やチームで理解して取り組んでいけるようにする成果物や体制づくり、啓蒙活動を行っていきたいです。
まとめ
紹介した記事やスライドは非常に内容が濃い／深いものばかりですので、SET としてやっていきたい／テストに興味があるという人はぜひそれぞれの書籍・記事を読み込んでもらいたいです。テストを積極的に取り込んで優れたプロダクトを生み出す人たちの助けになれば幸いです。
明日の記事は misty の Elasticsearch を使っていくために最低限知っておきたいこと です。お楽しみに！
