9日目です qiita.com
わたしの仕事
テストチームが組織としてあるわけではないので、「テスター」と名乗っています。
最近でいうと、「探索的テストを得意とするQA」というのが近いかもなぁと思っています。
何をしているのか
では、普段している内容です。
- 画面詳細設計書レビュー
- 探索的テスト
- スクリプトテスト
探索的テストとスクリプトテストは、私は厳密に切り分けて考えていないことと スクリプトテストで使っている仕様書も、かなりざっくり（いいように言うと、高位レベルテストケース・・・といっていいかなぁ）したものを 使っています。完全に属人化しているテストです。
わたしは、細かいテストケースも書いていませんし、エビデンスのように「テストした形跡」をほとんど残していません。 不具合やカイゼン案はすべてIssueに記載していますので、問題点はすべて残しています。それらを以てエンジニアと合意をとっています。
わたしたちがやっているテスト自動化（テストコード）
わたしたちの会社では、プロダクトを作るエンジニアがテストコードも書きます。 （SETチームはいません） 現在はテストコードやどのテストレベルに対して書くかは、各プロダクトチームのエンジニアにおまかせしている状態です。
テスターはテストコードを書くべきか
今年発売された、こちらの本に紹介してありました。
- 作者: Jonathan Rasmusson,玉川紘子
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/09/21
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
これからはテスターも得意とする分野でテストコードを書いた方がよいよね（ざっくり）という内容もありました。
そして、そう思っているQAエンジニアも多いと感じています。
私も、テストコードやプロダクトコードは読めるに越したことはありませんし、テストが書けるのはよいなと思っています。
なぜテスターがテストコードを書かないのか
わたしはテストコードを書いていません。
一時期E2Eのテストコードが書けるとしあわせになれるだろうと、 Turnip+ Selenium の勉強をして、インストールおよび少し書くところまではしましたが 結局定着しませんでした。
何がだめだったか
「テストコードを書く脳」と「テストをする脳」が全く別物だったことと、
そのスピード感とスキルが違いすぎて、運用に乗せられませんでした。
（大前提に、そもそも私はエンジニアをしていた時代に、スパゲッティーコード製造機で、プログラムコード書くのが本当に苦痛だったんでした）
探索的テストが得意なエンジニアは、テストコードを書くのは難しいのではないかと思います。
（または超高速でかけてしまう探索的テスターもいちゃうのかもしれません）
動いた反応を見て、次々に関連付けや過去の経験から次のテストをおこなうため、
コードに落としていくのは勝手が違いすぎるんですよね。（なので、実現できる人はめちゃくちゃ凄いと思う）
テスト手順書をきちんと落とし込めるテスターであれば、得意になる可能性はぐっと高くなるのではないかと思います。
それでも、設計とプログラミングコードを書くときに使う脳が別 っていうタイプの人であれば
難しい感覚はわかるかもしれません
では、どうすればよいか
だいぶ言い訳くさい内容になってきましたが、今、わたしが考えているものは次のような構想です。
どこを自動化するか、場所やボリュームを選定する
プロダクトに対して、テストコードを書くべき機能や内容をエンジニアと決めたいと思っています。
現在もいくつかしていますが、もっとわかりやすく、テストのピラミッドを使ったり、テストレベルなど見えるようにしたいなぁと思っています。必要なテストデータの選定をする
「十分なテストケース」はエンジニアの勘と経験に頼っているままにしているところがあります。 そこにテストの知見を入れられるといいなぁと思っています。各人が「すべきテスト」誰がどのテストをするか見えるようにする
現在は「テストをしている」というざっくりとした意識と、Issueの内容しかエンジニアと共有できていないのですが
各々が「しているテスト、していないテスト」誰がどういったテストをしているかをはっきりさせるとお互いが安心できると思います。
エンジニアと話してみた
このエントリーは数日前からコツコツ書き溜めていたのですが、
昨日（１２/８）わたしの上長で兼マネージャー兼エンジニアと話す機会があって、↑の話になりました。
で、できそうなことがあったので追加。
4.お互いに最小限のコストからはじめられるところを探る
私はテストができますし、エンジニアはコードを書いたり、環境を用意したりが得意です。
バグの再現手順をテストコードに書けないか？という話があがったのですが、いきなりテストコードを書くのはハードルが高いです。
でも、バグの出た箇所だけなら、ボリュームは多くありません。ですので
■わたしができること
* Issueを書くことができる。再現手順をテストシナリオのフォーマット（Turnipのようなイメージ）で書くならできそう
■エンジニア
* Issueのテストフォーマットからテストコードを書くならコストがそこまでかからないかもしれない
ということになりました。やっぱり会話大事。近く、わたしたちのテスト自動化はまた新しい道を進み始めるかもしれません。
で、さらに「初めての自動テスト」を読んで、
これらをユニットに落とし込めるかをエンジニアと話し合う→勝手に落とし込んでいる
状態がお互いにしあわせかもしれないなぁと思いました☺
勝手な結論とまとめ
- 得意分野を活かすテストをする
- 自分が持っているテストやバグの知見をエンジニアに共有する
- 足りないテスト、できているテストをエンジニアに共有し、合意をとる
STAC（システムテスト自動化カンファレンス）に参加します
明日開催される、STAC（システムテスト自動化カンファレンス）に、エンジニア2名と参加します。
九州から遠征しますので、この機会に沢山の方とお話したいです。
アドバイスください！
見つけたらぜひお声かけください：）
@rinaにリアクションしてもらえたら、全力で会いにいきます！
