テスト分析・テスト設計ができるようになるための道筋を考えてみる
アドベントカレンダーの17日目です。
記述自体は11月に行っていましたが公開を遅らせたのはWACATE2016冬のポジションペーパーに記載した内容をもとにしているから。ということで、WACATE2016冬当日の公開・・・♪
上のツリー図を作成する前に、まずは「障害」として「達成できない理由」を挙げてみます。言い訳だからと消すんじゃなくてまずは出してから考えるのがよいです(見てみると「あるある」なものが障害として挙がっていますよね・・・)。次にそれを克服したらどんな状態になるんだろうね?克服するために何ができるといいんだろうね?と考えます。それを「中間目標」として据えます。その中間目標を並べつつ、中間目標を達成するためにどんなことをやってみたらよいだろう?を挙げていきます。このアクションが難しすぎると着手できないので、できそうなものを書くのがよいなぁと感じています。(もちろん上のほうの目標に対する行動は、いますぐにはできないよねぇという行動になりやすいかなぁと思います。)
テスト分析とテスト自動化のはじめの一歩的なプロセスを考える
最近構想していることについて書いておこうと思いました。
これがいいという話ではなく、こうしてみようかなぁという話です。
背景として、今の現場(ブラックボックスのテスト専門のテストチーム)では、まったくと言っていいほどテスト分析、テスト設計とテスト自動化が進んでいません。現場の特性として自動化できる箇所に制限はあるのですが、それでもできる箇所もあるし、比較的自動化させやすいWebUIを持つものが多いため、その気になれば自動化できます。しかしながらテストコードはおろかHTMLすら書いたことが無いメンバーばかりという難点があります。そしてテスト分析やテスト設計も・・・まぁこれまでの記事でおわかりになるように仕様書の記述からテストケースを挙げることに慣れている状態で、仕様書がないと思考停止してしまう状態です。
そんなところに、どうやってテスト分析と自動化を導入していく?という話。
最初は、UIのテストに使えばいいんじゃない?画面遷移のテストに使えばいいんじゃない?という話があって、チャレンジしたことがあるのですが(ちなみに私ではない)、闇雲に着手するととても範囲が広く、そしてツールの制約などで操作が限られたりするので思ったように自動化できない、確認したいことが確認できない、メンテナンスが大変、などの問題があって定着しませんでした。
更に最近はidは自動採番されるので繰り返しに耐えられず、だけどnameやclassで一意特定できるようには作ってくれていないという問題もあり、暗礁に乗り上げていました。
そこで、以下の方針をたてて考えることにしました。
・テスト対象の実装や自動化ツールに振り回されないようにする
・テストスクリプト作成もメンテナンスも楽なものを目指す
・テスト分析・テスト設計を盛り込んだ上で手動テストと一緒に自動化のプロセスを考える
・「これなら始められるんじゃないか」という気にさせる
まだ記事にしていませんが、実はドメインモデルやロバストネス図の試みの他に、ユースケース図とユースケース記述をつくるという試みを今年から始めていて、ユースケース図およびユースケース記述ならモデルに慣れていない人でも始められるんじゃないか?という見解がでてきました。→これなら始められるかも
そして、ユースケース記述が書けるならユースケーステストができる。ユースケーステストはスモークテストとしても使える。スモークテストはプロダクトのバージョンアップの際に必ず実行するし、ビルドごとに実行することもあるから、自動化させるにはちょうどよい。また、ユースケーステストは操作にこだわらない(シナリオのパスが通ればよい)から自動化させてもあまり制約に左右されない。→まずはWebアプリのユースケーステストの自動化を目指そう!
最初はSelenium WebDriverで試していたのですが、「Selenium実践入門」を読んでGebを試したところ、GebならidやCSSセレクタに頼らずに「Buttonで、テキストに●●と書かれている0番目の要素」という指定ができることが判明。そして言語がシンプルなので面倒くささが軽減される。→作成とメンテナンスが楽になる
そしてSpockを利用することで、When-Thenの記述でスクリプトが書ける。。。これさ・・・つまりユースケース記述がそのまま載るじゃん!!すごーい!べんりー!
Spockは@Unrollを利用することでデータ駆動のテストも実装しやすい。→じゃぁ手順が同じなパラメータ組み合わせテストも自動化できるんじゃない?
という過程を経て考えたざっくりプロセスがこちら
とりあえず自動化させたいテストに着目しているので、その他のテストに関してはざっくりひとまとめになっていますが、他のテストも分析の段階からモデルが作成されてテストに落ちるものもあるよな、とは思っています。
また、ユースケース図を描き、ユースケース記述を書くことで、この段階からの開発活動に関わりやすくなり、認識を共有しやすくなると思っています。特にテスト担当者はミスユースケースを考えやすい立場にいると思っています。
そしてもちろんこれを今の組織やチームにいっぺんに導入するのは無理なので、とりあえずパイロットプロジェクトで枠組みを作り上げるのは私がやるとして、メンバーに対してはまずは部分的に始めよう、じゃぁどこから着手してみようか?という話をしているところです。。。まぁやっぱり最初は分析ができるようになりたいよねー・・・ユースケース図と記述が書ける文化にしていきたいよねー・・・
さてさてどうなりますことやら。
なお、こんなことを考えられるようになるまでに至る過程で、職場のメンバーはもちろんFBでコメントをくださった皆様や勉強会やカンファレンスなどでたくさんのことを教えてくださった皆様、本や記事を書いてくださった皆様の力を借りたことに、とても感謝しています。まだまだ試行錯誤中だけど、自分の中で芯ができてきた気がしています。そしてこれからもさんざんお世話になりそうですがよろしくお願いしますm(_ _)m
発表するということ
「発表する」というよりも、舞台に立つというほうが自分にはしっくりくるのですが・・・
例えば合唱でステージに立つのと、講演で前に立つのとでは共通するものがあるな、と思っています。
私のなかでは大きくふたつあります。その場に世界をつくりあげることと、想いを伝えること。
その場に世界をつくりあげるのは主に合唱のときかな。ホールに白鷺を高く舞わせたり天から一筋の光をすとんと落としたり。ゲネラルパウゼなんて本当にどれだけその場に世界をつくれるかにかかっていますよね(だからゲネラルパウゼで会場に携帯音が鳴った時の悲劇たるや・・・)。講演でも例えばアイスブレイクは場を和ませるという点で世界をつくりあげるほうに入ると思っています。あとは私はそこまでできないけれど講演でも会場を自分の世界にしてしまう方がいますよね。
想いを伝えるのは、楽しさだったり内容だったり。その昔仲間とつくった合唱団はよく若さと仲の良さが伝わると言われましたが^^;あら;
どちらを実現するにしても、会場を見渡せないとか、楽譜や原稿から目が離せないとか、歌詞や内容を自分なりに咀嚼できていないとか、そういう状態では実現が難しくなります。
実現するためには、内容を自分なりに解釈して自分なりに表現できるようにならないといけない。(もっとも合唱は指揮者の意図を汲みつつメンバー全員でつくりあげるわけですが、それでもひとりひとりの想いで構成されるものだと思います。)伝えたいという想いがうまく届くように演じなければならない。
いろいろなことに負けてしまいうまくいかなかったこともこれまでたくさんあったし、これからもうまくいかないこともたくさんあるかもしれない。だけどその時の状態や制約のなかで自分にできることは何だろうって考えてできるだけ自分が持つ理想に近づけられるようにしたいな、と思います。
私は合唱活動のおかげで上記のことは自然と身についたところがあるな、と感じています。もちろんここ数年で学んだこともたくさんあると思いますし、まだまだなところも多い。そもそも今回とりあげたこと以外にも心がけないといけないことはありますし・・・構成とか時間配分とか。
これから発表の経験を積んでいく方がいらっしゃるなら、まずは発表したい内容を自分なりに咀嚼して自分の言葉で語れるようになることを目指すのがいいかな、と思います。伝えることは場数だと思うのですが、ひとりでも声に出してエアの相手に伝えることを意識して練習するのがよいのではないかなーと思っています。
ひとりひとり違うひきだし ---テストを考えるとき---
4月23日に開催されたとてか04でのみわさんの発表から。
じゃぁ私はどうなんだろうな?って考えてみた。
・・・それを書くとながーくなるので、そこから思ったことを書こうと思います。
まず、プログレスダイアログのテストって考えるときに、イメージするものが人それぞれなんだなぁってこと。
私は最初、昔Windowsアプリのテストをしていた頃を思い出していました。
だけど、みわさんのスライドを読み進めるうちに、あぁシステムモーダルって・・・そういえばこの製品が組み込み系でパネルだったらそういうケース多いね。だとしたら割り込み処理って入ることあるよねー(割り込み側が負けなきゃいけない?)・・・裏で勝手に動くものもあるよねー(それは並列処理できなきゃいけない?)・・・って発想が広がるのを感じました。そして、これはPCのアプリの場合とモバイルアプリの場合と組込み系のパネルの場合とWebアプリの場合とではそれぞれ意識することが変わってくるんだなっていうのを改めて実感しました。
そういう点でこのネタは美味しい!みわさん、さすがだなぁ
あとは、経験が長いがゆえに流してしまうことと、なんでも気にすればよいというものではないなというのと、そのバランスって大事だな、ということ。
例えば製品の性能が良くなってプログレスダイアログの表示時間が短くなったとして、それを表示する意味がなくても害もないならそのままでもいいじゃない?ということもある(まぁでもそれならキャンセルボタンはテストできないから実装外そうよとか言うかもしれない)。まだ表示時間が長くなるケースもあるかもしれない。なんでもかんでも指摘すればよいわけでなく、どうします?って問いかけるのがいいんだよなーって思っています(たぶんみわさんはそうしているのだと思います)。 逆に、プログレスダイアログの表示が長くても「そんなもの」と流してしまいがちになることもある。これはみわさんの発表を見て改めて気をつけようって思いました。
あと、プログレスダイアログのテストじゃなくてもはや処理のテストですよね^^;っていうのもありますね(笑) でも一緒に考えますよねーうんうん。
確かにいろんな背景を持つ人と比較すると楽しそう。
他のお題とかもないかなーって考えています。なにがいいかなぁ・・・
テストの活動のはなし
Testingという用語をJSTQBの用語集から引用すると、
「全てのライフサイクルを通じて実施する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価をすること。」
なので、活動全体を示すのですが、
よく、「CheckingとTesting」という対比した使われ方をするとき、Testingは創造的だったり学習の要素が入ったりという意味合いを持つなーという印象を持っています。
最近、JaSSTで情報を得たり話をしたりする中で、自分や自分の周りの活動はどうなんだろう?と考えてみるようになりました。
で、描いてみた→何人かに見せてフィードバックもらってみて今に至る。↓
まずはテスト対象に出会う前に備わっている知識や経験や能力があります。ここで持ち合わせているものが活動に影響するのですが、その話はまた別の機会に書きます。
テスト対象に出会うと様々な情報が入ります。その情報を分析して、不明な点や気になる点を調べたり質問したり仮説を立てて検証したりします。そうして新たな情報を得て更に分析します。そのサイクルをぐるぐる回して共通理解を得たら、そこからテストのスコープを決めたりスクリプトにするテストを決めたりします。ぐるぐる回している間はTestingですが、スクリプトになる時点では期待結果がわかっているのでCheckingになっていると思います。
スクリプトにしないけれど、気になるから「一度やっておく」テストもあります。こちらもすでに想定済みのものなのでCheckingかな?って思います。
上記の流れに対して、分析したのだけれど理解しきれていなかったり誤解していたりということが起こることがあります。たぶん誰にでも起こると思います。この「わかったつもりになる」状態がある、ということに気付きました。この状態に陥るとテスト実装や実行の時点でなにかトリガーがかかって後で気付くことになります。気づいた時点でTestingのループに戻るなぁ、と。
この図があると、なるべくこっちのルートを辿らないようにしたいよね、って話ができるなぁとも思いました。
更に、残念ながら情報を得たらそのまま考えずにテストを作ってしまうルートもあります。悪い意味のCPM(コピーペーストモディファイ)はこちらのルートで作成されるので、概してテスト実行時に気づけばラッキーという状態になります。これもなくしたいよねって話がしやすくなりました。
あと、この図で探索的テストってどこのことを言っているんだろうね?という話もできるなぁって思っています。
探索的テストって、Testingとイコールではないというのが今の私の考えです。本当はスクリプトにできるんだけど様々な理由でスクリプトになりきれない(あるいはする必要がない)ものがあって、それを補うための探索的テストってやるよね?
スクリプトの品質が悪いことを補う探索的テストもやるよね?
この図でTestingとしているループで実装物を触っている場合を探索的テストと呼ぶ人もいるよね?
今後、こういう話をいろんな人としていきたいなぁって思っています^^
・・・って、本当はとてかでここまで言いたかったんだよぉぉ(笑