ソフトウェアテスト勉強会～テスターと創る開発現場～
先日こちらの勉強会に参加してきました。
参加した感想と今後の抱負について、つらつらと書いていこうと思います。
@m_sekiさんのお話
Rubyのコミッタをされている@m_sekiさん。CheckingとTestingの話を皮切りに、テスターと開発者のロールについてお話しされていました。CheckingとTestingの説明については@m_sekiさんのアップされている資料をご覧ください。
開発者とテスターのロール
@m_sekiさんは、開発者とテスターのロールについて以下のように説明されました。
開発者
- ほしいものを実現する
- 仕様を具体化する
- 実装を考える
- プログラムを書く・直す
- テストする
テスター
- ほしいものを実現する
- 仕様を具体化する
- 実装を考える
- プログラムを書く・直す ←ここがない
- テストする
テスターはプログラムを書かない。あとは同じである、とされました。
ここは私は意外だなと思いました。私なら以下のように説明すると思います。
（私の思う）開発者
- 顧客の要求を要件として定義する
- 仕様を考えて実装する
- （仕様ベース・構造ベースの技法を主に使用して）テストする
（私の思う）テスター
- 要件定義の内容に致命的な漏れがないか確認する
- 仕様や実装方法を、テスタビリティの観点からレビューする
- （仕様ベース・経験ベースの技法を主に使用して）テストする
タイトルにある「テスターと創る」とあるように、ロールとして作る側・チェックする側みたいな分かれ方をしていません。共同作業的に作っていく姿勢なのだなと印象に残りました。
良い製品とは何か
テスターは開発者に比べて、「良い製品とは何か」について、気にかける領域が広がると言われていました。
開発者はどうしても、目の前に実装すべき機能やユーザストーリーがあります。なのでより詳細な、個別な分野に詳しくなる傾向があります。
しかしテスターはプログラムを書かないので、個別なところではなくより全体的な視点で「良い製品とは何か」について考えられるということです。
テスターが増えることによって起こること
テスターが増えることで、以下のようなことが起こったそうです。
- 異変の認識から、それが確信に変わるまでの時間が短縮される
- 再現しないバグの数が低減する
- 見つかるバグの多様化
私も今QAチームとして複数人でテストを考えていますが、これらの項目はどれも強く共感しました。
Testingの帽子をかぶる時間
テスターとテスターで相乗効果があるのだから、テスターと開発者での相乗効果もあるのでは？と考えたそうですが、ある程度の効果は出たものの、そこまで顕著ではなかったそうです。
テストのうち、特にTestingについて考える時間というのはテスターと開発者でかなり異なっていて（テスターの方が長い）、それが相乗効果の大きさに影響しているのではとのことでした。
@miwa719さんのお話
@m_sekiさんのお話を踏まえ、テスターと開発現場との関係、その周辺のお話をしていただきました。
開発とテストが分かれていない
@miwa719さんのいる開発現場では、開発とテストは分かれていません。設計の時には「これはどうやって検証する？」といういわばテスト設計のようなことを常に考えるそうです。なんとなくWモデルの考え方に近いものを感じました。テストを重要視していることがうかがえます。
設計と一緒にテスト設計を考えるのは、実際に行うのは難しいのではと思って質問しました。しかし回答は思ったのと違いました。「どう作るのかを考えるなら、それをどうやって検証するかもいっしょに考えるのは当たり前」といった感じの回答を@m_sekiさんからいただいたと思います。どうしてそんなに開発者のテストに対するモチベーションが高いのか？ということも質問したのですが、単に「製品を見ているだけ」とのことでした。
徹底した品質志向
@miwa719さん、@m_sekiさんの表現では「製品を見ているだけ」と言われていましたが、私はそこに製品品質に対する強烈なこだわりを感じました。
結局、製品の品質にこだわる文化がありさえすれば、そのための取り組みに注力するのは確かに「普通のこと」だといえます。根本的に目指すべき共通の目的がはっきりしているから、開発者もテスターも迷わずに動けるのではないかと思いました。
その現場では、「仕様通りです」という回答をするとブーイングを受けるそうです。なぜなら、過去の仕様が正しいとは限らず、常に「製品としてどうあるべきか」を考える必要があるためです。本当に色々な人に聞いていただきたいお言葉だと思いました。
また、何か不具合に通じるような違和感がある、とテスターである@miwa719さんが話すと、周りの開発者はそのおかしさを理解しようとしてくれるそうです。しっかり自分事としてとらえて、話を聞いて考えてくれるのだそうです。改善の姿勢が素晴らしいと感じたのですが、これも当たり前の光景とのことです。
新人歓迎ルーチン
どうやって「製品のことを考える」という文化を醸成したのか？という疑問を多くの参加者が感じたようです。私もそうでした。
@m_sekiさんは、回答の一つとして「新人が来たときに、どんな教育をするか」という新人歓迎ルーチンについて教えてくださいました。新人が来たときに行うこととして、以下のような項目を挙げられました。
- チームの理解
- 製品の理解
- ペアテスト
- 全体の構成の理解
- ビルド、コードの登録手順の理解
- 得意な機能を一つ作る
新人にはいち早くチームの理解、製品の理解を進めてもらうのが重要と考えていて、朝会と朝会の二次会（朝会でわからなかったこと、気になったことを聞く）というのを行うそうです。また、ペアテストもかなり効果があると話されていました。
特に、「この製品にはどんな価値があるの？なんの役に立つの？」という認識を共有することが非常に大事なのだそうです。確かに、それを理解しているかどうかはテストの良し悪しにかなり関わってきそうです。あとは全体の構成を理解していってもらうこと、ビルドやコードの登録といった手順を理解してもらうと話されていました。
その中で得意な機能を一つ持ってもらうことで、自信にもつながるし良い影響があるとのことです。これは自分の経験からも共感しました。
最初は一人だった。でも問題を感じている人はいた
最初は、@m_sekiさんが「全部のチケットをテストする」と決めて実行したそうです。（そのチームではテストをチケットで管理しているそうです）その当時は「製品の品質が良くない。なんとかしたい」と思っている方も少なからずいて、まずは「俺が全部テストするから！」といって始めたそうです。でも、実際にやってみるとテストすることによって精神的に安心感も得られることがわかったそうです。@m_sekiさんはこれ（毎日増えていくテストを、全部やること）を「忍者式テスト」と言われていて、過去にJaSSTで発表したこともあるそうです。（「忍者式テスト」で検索すると出てきます）
古いチケットも、全部テストする
今でも、古いチケットは全てテストしているのだそうです。もちろん一気に全てのテスト（数十万に上るのだそう…）は一気に回せないので、その日の「オススメチケット」を決めてテストするようにしていて、一定の期間オススメチケットを回し続けることで全体をテストできるという仕組みとのことです。なお、テスターの行うテストはいわば「特別オーダー」で、そのオススメチケットとはまた別に考えたテストを行うのだそうです。確かに、一定の期間テストを回せば自動的に全部のテストを実行できるというのはかなりの安心感があると思いました。
チケットのメンテに気合いを入れすぎない
もちろん古いチケットが陳腐化してしまうこともあります。ただ、そこで全てを直し切ることにこだわるのではなく、あくまで見つけた時に都度直すようにしているそうです。
@miwa719さんの一日の時間割
続いて、@miwa719さんの職場での一日の過ごし方についてお聞きしました。
ちょっと厳密な時間はずれているかもしれませんが、以下のような感じでした。
8:50〜 朝会１
9:00〜 朝会２
10:00〜 テストの朝会
10:30〜 テスト
12:00〜13:00 昼休み
13:00〜14:00 テスト
14:00〜14:10 休憩
14:10〜15:10 テスト
15:10〜15:20 休憩
15:20〜16:20 テスト
16:20〜17:00 夕会
17:00〜18:00 テスト
朝会が複数回あるのは、それぞれ別のチームの朝会に出ているそうです。テストの朝会では、「どのへんを狙ってテストする？」とかいった会話をするのだそうです。
また、１時間くらいテストすると集中が切れてくるので、適度に休憩をはさむと言われていました。集中しすぎているときは声をかけてもらったりするそうです。
確かに、自分もテストをするときは途中で集中が切れてしまうことがあります。時間をある程度決めて休むというのも効率が上がって良さそうだと思いました。
テスターの思う怪しいところ
@miwa719さんのお話を聞いて思ったのは、あらゆる情報がテストにつながるヒントになるということです。
まず、以下のような箇所はバグが出やすいそうです。
- 開発者同士で揉めているところ
- 開発者が混乱しているところ
- 開発者が心配しているところ
揉めているところでは、以下のようなことが起こっていたりします。
- 途中で仕様が変わった、実装方法が二転三転した
- いちどうまくいかなくて、仕切り直しになった
- 前まですごく議論してたのに、急に話題に上がらなくなった
- 他の議題に時間を取られ、あっさりと検討が流された
これもよくわかります。仕様や実装方法がコロコロ変わるところは自分も気をつけています。
また、レビューしていたとしてもなかなか均等に成果物を見られるわけではありませんから、詳しく見ているところとそうでもないところと分かれてしまうのもありがちだと思いました。
開発者が混乱しているのは、以下のような感じになっているそうです。
- チケットがわかりづらい
- 文章が長い
- コードが文章になっている
- 説明を聞いてもよくわからない
確かに、説明を聞いてもわからない、文章がやたら長いとかは自分も経験があるのでよくわかりました。おそらく、理解度がまだ浅いために文章や説明が整理できず冗長になってしまっていたりするのだと思います。
開発者の心配は、開発者の様子から感じ取るのだそうです。
- 場の雰囲気
- メンバーの顔色
- 声のトーンなど
ここが特にすごいと思いました。確かにこれらも有益な情報の一つとなるのですが、なかなかここまで観察できている人は少ないのではないでしょうか。また、気になったところは随時ほぼ日手帳にメモして、後から見返すのだそうです。
チケットにも怪しいものがある
チケットにも怪しいものがあるそうで、以下のようなものは特に怪しい匂いがするそうです。
- とにかくたくさん書いてある
- コードっぽい説明になっている
- 「調査中です」「仕切り直します」などと書いてある
「開発者が混乱しているところ」と重なっているものもありますが、チケットのわかりづらさから開発者の混乱につながるのではと思いました。
あとは、あっさりしすぎているところやうまく行きすぎているところも怪しいと感じるそうで、結局はどんなところも怪しさは感じてしまうとのことです。
また、先述の通り開発者がとても熱心に（明らかなバグ出しのテストも含め）テストを実施するので、Checkingのテストではバグはほとんど出ないのだそうです。なのでとにかく情報を出すこと、拾うことを意識されているように思いました。その中で、やはり開発者との精神的・物理的距離は重要なのではと感じました。また、チケットを読んで「こんなことができるようになるんだな」と初見で感じたものは特に重要視していて、そこと実際に動かして見たときとのギャップも確認するようにしているそうです。
個人的に感じたこと
以下に個人的に感じたことを書いていきます。
QAとテスターのロールの違い
お話を伺って感じたのは、組織のQA技術者とテスターのロールは実は大きくちがうことがあるということです。具体的にいうと、自分が所属しているQAチームとはロールや文化が全く異なっていました。私のいるところではそこまで開発者との距離は近くないし、役割分担の意識ももっとテストと開発で分かれていると思います。
どういう役割分担だから良い・悪いではなくて、役割分担にあったメンバー構成になっているかとか、役割分担がメンバーの共通認識になっているかが重要なのではと思いました。役割分担が明確になっていれば、どこをカバーする必要があってどこを任せたらいいかわかって対処がしやすいからです。バレーボールでいうお見合いみたいなのを減らすことができます。
コミュニケーションは技術である
開発チームの朝会にテスターも参加して情報収集をするというのは、私も経験がありますし効果があると思っていました。
ですが、@miwa719さんのお話を聞いて「そんなもんじゃない」と思いました。
@miwa719さんの行なっているコミュニケーションは、技術だと思いました。顔色を見たり、声のトーンを感じたり、微妙な雰囲気、空気の違いを感じ取ったり…。ここまで意識してコミュニケーションをとっている方が一体どれだけいるでしょうか。
また、コミュニケーションの機会を積極的に設けているのもポイントです。現場では@m_sekiさんが自分の仕事をあえて持たずにメンバーの様子をみたりアドバイスをしたりしているそうです。朝会もとても活発的で、別のチームが勉強のために朝会を見学しにくることもあるのだそうです。さらには、@miwa719さんが別のチームの朝会に参加して、あまりに不安な雰囲気を感じて緊急ミーティングを提案したこともあるのだそうです。まさにコミュニケーションが危機察知の手段として機能しているのだと思います。開発者、テスターが一緒になって製品について話すことも、テストに良い影響を与えているのでしょう。
端的に言ってしまえば「コミュニケーションを密にとる」とか「仲良くなる」みたいな話なのかもしれませんが、私はそこにとどまらない技術的なものを感じました。自分はQA技術者として仕事をしていますが、開発者とのコミュニケーションについては改善の余地があると強く感じました。
アジャイル開発のエッセンス
本編では触れられていませんでしたがアジャイル開発のエッセンスがうまく取り入れられているように感じました。見通しのたてやすい開発単位としてユーザストーリーを作成し、何を実装しなければならないのかと同時にどうやって検証したら良いのかを常に考えるようにしている仕組み（というより、文化？）はとても良いなと感じました。
明日から実践してみようと思ったこと
私はお話を聞いている途中からすごく悩み始めました。というのも、せっかくお話を聞いたのだから仕事に活かしたいわけですが、いかんせん文化が異なりすぎてどこから真似したらいいのかなかなか見当がつきません。
それでもお話を聞いて私なりに考えたのと、懇親会の場とかでアドバイスいただいたのが以下の内容です。
1. 過去のバグ票を読み込む
@miwa719さんは、気になったキーワードでチケット管理システムを全検索し、テストのヒントに使うそうです。
そしてスゴイのは、記憶装置的な意味では、脳がプライマリでチケット管理システムがサブということです。
どういうことかというと、過去どんなバグがあったかはみんなが覚えているそうなんですね。にわかには信じがたいことです。チケットのメンテナンスにそこまで厳密さが必要ないというのも頷けます。あくまでチケット管理システムはサブの記憶装置というわけです。
過去のバグ票を読もう、というのはよく言われることではあるのですが、そこまで熱心に読み込んではいなかったと反省しました。もっと色々読んでみようと思いました。
2. 日々感じた違和感、気になることを手帳に残して時々見直す
@miwa719さんの言われていたことで、「ほぼ日手帳に気になったことをメモして、時々見返す」というのがとても良さそうに思いました。
特に同じ製品を長くテストしていると、なんかこの辺が怪しいなとかはなんとなく感じることがたまにあって、それが結構当たる気がします。なので、ちょっとした違和感とか感じたことはメモしておくのがいいのだろうと思います。
3. 開発者と仲良くなる
私は以前、開発のテストにヘルプとして入って以来関係性がとても近くなって、テストがやりやすくなったり教えてもらいやすくなったりした経験がありました。なので、コミュニケーションの重要性は強く感じます。
なかなか、場の雰囲気や声のトーン、顔色といった情報まではつかめないことも多いです。しかしそういう小さなところも拾い上げていって、テストに活かせるように考えていこうと思いました。
4. もっと製品のことに興味を持つ
やはり根本は製品の方を向いていることだと感じました。この機能は何に使うのか、これを作るとなんの役に立つのか。色々想像しながら、製品としてどうあるべきかということを意識しようと思いました。
5. どうしてそうするのか？と考える人を増やす。仲間を作る
やはり、製品としてどうあるべきか考えるにあたって「どうしてその仕様で良いのか？」などと疑問を持ったり、理由を考えたりすることがとても大事です。なのでそういった疑問を持つこと、またそう考える仲間を増やしていきたいと思います。
@m_sekiさんが話されていましたが、最初は一人でも、多数派になってしまえば少数派の人は「俺がおかしいのかな…？」と考え始めるのだそうです。なので、しっかり製品の方を向く文化を作るために、レビューなどの場を通じて根気強く発信していけたらと思いました。
文化が大きく異なっていても、取り入れられるところは確かにあります。少しずつでも取り入れて、現場を改善していけたらと思いました。
おわりに
@m_sekiさんと@miwa719さんとは初めてお会いしました。
@m_sekiさんには懇親会でもいくつか質問をさせていただきましたが、優しく色々教えていただいたり、「どうしてそう思ったの？」などと逆に質問をされたことで気づきがあったりしました。本当にありがとうございました。
@miwa719さんは「妖精のような方」と伺っていたのですが、なるほど確かに素敵なオーラの方でした。私の要領の得ない質問にも熱心に耳を傾けていただいて、本当にありがとうございました。
私の後日談
さっそく、次のテストが始まるにあたって「QAのとこじゃなくて、開発者の○○さんの近くでテストしたいんですけど」と言ってみました。物理的距離を縮める作戦です。
開発者の○○さんには「えっ、ちょっとこわいんですけど…」と言われました。なにか勘違いされている気がしないでもないですが、これで少しでもテストを良くできたらいいなと思いました！
