Dreamland-夢と想いと小さな工夫

自分の中にある想いだったり日常の工夫だったりをすこしずつ書いていこうかなぁって思ってます。

気ままなテスト実行のはなし

そういえば自分のテストの実行スタイルの話をしたことがないなぁ、と思いまして・・・
・・・典型的な私の行動例です。実際はもうちょっと複雑になるけれど、だいたいこんな感じ。
なお、スクリプトテストの最中も、疑問点が浮かんだ時点で即スイッチが入って探索に行っちゃいます・・・なので私にスクリプトテストの進捗率を求めちゃいけないと思うのよ・・・笑

スタートとエンドを描きましたが、それ以外の矢印は順序ではなく因果関係を示しています。楕円はand条件を示しています。
※astahのアクティビティ図を描くためのアプリを利用して描いたのでアクティビティ図だと思われたみたいなので補足しておきます。図の表記法としてはアクティビティ図ではなくロジックブランチを利用しています。ただスタートとエンドを加えたかったので明示的にロジックブランチと言うのを避けました。

みんなはどうなんだろう?同じなのかな?違うのかな?
現場は素直にスクリプトテストから始めるケースが多かったかなぁ・・・

f:id:shiozi:20170719210556j:plain

発想や気づきはなぜ足りないのだろう?

テスト分析をするときに、テスト条件を出すのだけれど、
手法を使っても上手くテスト条件を出せなくて
結局出てきたものは仕様書を整理したもの、というケースによく遭遇します。
(たぶんこういう話は過去にもしているのだけれど^^;)
 
ツールを使いこなせていないから、というのもあるとは思うのですが、それだけじゃないなぁ、という感覚を持っています。
発想が足りないんだよね。発想が。
んー、発想か?気づきが足りないのか??
 
じゃぁその発想とか気づきって、何で足りないんだろうね??
なーんて夜中に考えていたらふと思ったことがあって、
 
仕様書を理解することと仕様を理解することは違うんだよな。
仕様を理解することと要求を理解することも違う。
仕様書を理解しようとする人はその手前になる仕様に気づけなくて、
仕様書と仕様を理解しても、その手前にある要求に気づけなくて、
更にその周りに付随する「気になること」に気づけないんじゃないかなぁ・・・
 
要求で抜けるもの
要求から仕様に落ちるときに抜けるものと加える必要のあるもの
仕様から仕様書に落ちるときに抜けるものと伝わらないもの
 
ここらへんを意識すると何かが変わったりするのかなぁ?
 
ほかになにかある?
なんか頭の片隅で「もにょ」って反応がくる。まだあるのかな?
あまり深く考えたことがないんですよね、わたし。
他の人が同じようにするためにはどうしたらいいの?っていうのはここ最近の課題ではあるけれど・・・
 
あと、よくその「漏れるところ」を埋めるために「ドメイン知識」という言葉で片付けられるけれど、それだけじゃないのも感じる。
確かに知らないことはどんなに振ってもでてこないからドメイン知識は大事なのだけれども、だからドメイン知識を持っている人はテスト条件を出せるって考えには賛成しないのです。
ドメイン知識を持っているけれど上手くテスト条件を出せない人も見てきたから。
 
ソフトウェアテストって、本当にいろんなことを考える仕事だと思います。
そこなのかな。私が続けている理由って。

テスト分析・テスト設計ができるようになるための道筋を考えてみる

qiita.com

アドベントカレンダーの17日目です。
記述自体は11月に行っていましたが公開を遅らせたのはWACATE2016冬のポジションペーパーに記載した内容をもとにしているから。ということで、WACATE2016冬当日の公開・・・♪

 

意欲的になるっていうのは比較的簡単かなぁと思うけれど、意欲的になっても行動に移すのは難しいなぁと思っています。そして意欲的にさせるのは更に難しいと思っています。みなさんはどう感じていますか?
そこに到達したい!実現させたい!やってみたい!と思っても、自分が目指すところに行くための始めの一歩がみつからなかったり、始めたものの次にどうしたらよいのかわからなかったりと、なかなか思うようにたどり着けないことが・・・私自身にも周りにもあるなぁと感じています。
 
例えば・・・よく耳にするのが「テスト技法を学んだのだけれども、それを現場で使うためにどうしたらよいのかわからない><」。テスト技法を実際の業務に取り入れられるようになるためには技法を学ぶだけでは無理というケースです。さてどうしましょう・・・
私の職場ではテスト自動化をうまく導入できていなかったり、テスト分析プロセスがなかったりします(テスト設計もまだまだ^^;)。それにはいろんな背景があります。障害となる要素が多いんですね。今年になってその課題にがっつり向き合うことにしたのもあって、ATT(アンビシャスターゲットツリー)を使って達成するための道筋を考えてみました。ATTの下の方にある行動を起こすことで段階的に中間目標を達成していくことで上にたどり着ける、というのを示した図です。

f:id:shiozi:20161123175011p:plain

上のツリー図を作成する前に、まずは「障害」として「達成できない理由」を挙げてみます。言い訳だからと消すんじゃなくてまずは出してから考えるのがよいです(見てみると「あるある」なものが障害として挙がっていますよね・・・)。次にそれを克服したらどんな状態になるんだろうね?克服するために何ができるといいんだろうね?と考えます。それを「中間目標」として据えます。その中間目標を並べつつ、中間目標を達成するためにどんなことをやってみたらよいだろう?を挙げていきます。このアクションが難しすぎると着手できないので、できそうなものを書くのがよいなぁと感じています。(もちろん上のほうの目標に対する行動は、いますぐにはできないよねぇという行動になりやすいかなぁと思います。)

f:id:shiozi:20161123174932p:plain

テスト分析がうまくできないのはテスト対象の理解ができていないからだ、という仮説は昨年から持っていたのですが、ATTを作成することでそれを論理的に見せることができるようになりました。まずはテスト対象を理解するために仕様書に頼らなくてすむようにしよう。図がかけるようになろう、その練習から始めよう。って。(そのための学習スライドを作成していて、少しずつ学習して慣れてもらおうとしているところです。)
 
もちろん、この図を描いたからといってそのとおりになるわけではないし、「まずはここから」というところに着手してみて、その結果をもとに次はどうしようか?って常に作戦をたてて変更を加えていく必要があります。だけど始めの一歩があまりに難しかったりうまくいかなかったりしたら先に進めません。やってみた結果がどうであれ次に繋げやすい一歩をみつけるのが大事です。ATTやロジックブランチなどTOCfEのツールを使うことでそういう考え方をしやすくなったのが最近の私の収穫かなぁと思っています。
 
p.s.
TOCfEのツールはテストの活動の中でいろいろ考えるための手助けをしてくれます。それを実感しながら過ごしています。もし興味を持たれましたら一緒に勉強しませんか?

テスト分析とテスト自動化のはじめの一歩的なプロセスを考える

最近構想していることについて書いておこうと思いました。
これがいいという話ではなく、こうしてみようかなぁという話です。

背景として、今の現場(ブラックボックスのテスト専門のテストチーム)では、まったくと言っていいほどテスト分析、テスト設計とテスト自動化が進んでいません。現場の特性として自動化できる箇所に制限はあるのですが、それでもできる箇所もあるし、比較的自動化させやすいWebUIを持つものが多いため、その気になれば自動化できます。しかしながらテストコードはおろかHTMLすら書いたことが無いメンバーばかりという難点があります。そしてテスト分析やテスト設計も・・・まぁこれまでの記事でおわかりになるように仕様書の記述からテストケースを挙げることに慣れている状態で、仕様書がないと思考停止してしまう状態です。

そんなところに、どうやってテスト分析と自動化を導入していく?という話。

最初は、UIのテストに使えばいいんじゃない?画面遷移のテストに使えばいいんじゃない?という話があって、チャレンジしたことがあるのですが(ちなみに私ではない)、闇雲に着手するととても範囲が広く、そしてツールの制約などで操作が限られたりするので思ったように自動化できない、確認したいことが確認できない、メンテナンスが大変、などの問題があって定着しませんでした。
更に最近はidは自動採番されるので繰り返しに耐えられず、だけどnameやclassで一意特定できるようには作ってくれていないという問題もあり、暗礁に乗り上げていました。

そこで、以下の方針をたてて考えることにしました。
・テスト対象の実装や自動化ツールに振り回されないようにする
・テストスクリプト作成もメンテナンスも楽なものを目指す
・テスト分析・テスト設計を盛り込んだ上で手動テストと一緒に自動化のプロセスを考える
・「これなら始められるんじゃないか」という気にさせる

まだ記事にしていませんが、実はドメインモデルやロバストネス図の試みの他に、ユースケース図とユースケース記述をつくるという試みを今年から始めていて、ユースケース図およびユースケース記述ならモデルに慣れていない人でも始められるんじゃないか?という見解がでてきました。→これなら始められるかも

そして、ユースケース記述が書けるならユースケーステストができる。ユースケーステストはスモークテストとしても使える。スモークテストはプロダクトのバージョンアップの際に必ず実行するし、ビルドごとに実行することもあるから、自動化させるにはちょうどよい。また、ユースケーステストは操作にこだわらない(シナリオのパスが通ればよい)から自動化させてもあまり制約に左右されない。→まずはWebアプリのユースケーステストの自動化を目指そう!

最初はSelenium WebDriverで試していたのですが、「Selenium実践入門」を読んでGebを試したところ、GebならidやCSSセレクタに頼らずに「Buttonで、テキストに●●と書かれている0番目の要素」という指定ができることが判明。そして言語がシンプルなので面倒くささが軽減される。→作成とメンテナンスが楽になる

そしてSpockを利用することで、When-Thenの記述でスクリプトが書ける。。。これさ・・・つまりユースケース記述がそのまま載るじゃん!!すごーい!べんりー!

Spockは@Unrollを利用することでデータ駆動のテストも実装しやすい。→じゃぁ手順が同じなパラメータ組み合わせテストも自動化できるんじゃない?

という過程を経て考えたざっくりプロセスがこちら

f:id:shiozi:20160919224046p:plain

とりあえず自動化させたいテストに着目しているので、その他のテストに関してはざっくりひとまとめになっていますが、他のテストも分析の段階からモデルが作成されてテストに落ちるものもあるよな、とは思っています。

また、ユースケース図を描き、ユースケース記述を書くことで、この段階からの開発活動に関わりやすくなり、認識を共有しやすくなると思っています。特にテスト担当者はミスユースケースを考えやすい立場にいると思っています。

 

そしてもちろんこれを今の組織やチームにいっぺんに導入するのは無理なので、とりあえずパイロットプロジェクトで枠組みを作り上げるのは私がやるとして、メンバーに対してはまずは部分的に始めよう、じゃぁどこから着手してみようか?という話をしているところです。。。まぁやっぱり最初は分析ができるようになりたいよねー・・・ユースケース図と記述が書ける文化にしていきたいよねー・・・

さてさてどうなりますことやら。

なお、こんなことを考えられるようになるまでに至る過程で、職場のメンバーはもちろんFBでコメントをくださった皆様や勉強会やカンファレンスなどでたくさんのことを教えてくださった皆様、本や記事を書いてくださった皆様の力を借りたことに、とても感謝しています。まだまだ試行錯誤中だけど、自分の中で芯ができてきた気がしています。そしてこれからもさんざんお世話になりそうですがよろしくお願いしますm(_ _)m

発表するということ

「発表する」というよりも、舞台に立つというほうが自分にはしっくりくるのですが・・・

例えば合唱でステージに立つのと、講演で前に立つのとでは共通するものがあるな、と思っています。
私のなかでは大きくふたつあります。その場に世界をつくりあげることと、想いを伝えること。
その場に世界をつくりあげるのは主に合唱のときかな。ホールに白鷺を高く舞わせたり天から一筋の光をすとんと落としたり。ゲネラルパウゼなんて本当にどれだけその場に世界をつくれるかにかかっていますよね(だからゲネラルパウゼで会場に携帯音が鳴った時の悲劇たるや・・・)。講演でも例えばアイスブレイクは場を和ませるという点で世界をつくりあげるほうに入ると思っています。あとは私はそこまでできないけれど講演でも会場を自分の世界にしてしまう方がいますよね。
想いを伝えるのは、楽しさだったり内容だったり。その昔仲間とつくった合唱団はよく若さと仲の良さが伝わると言われましたが^^;あら;

どちらを実現するにしても、会場を見渡せないとか、楽譜や原稿から目が離せないとか、歌詞や内容を自分なりに咀嚼できていないとか、そういう状態では実現が難しくなります。
実現するためには、内容を自分なりに解釈して自分なりに表現できるようにならないといけない。(もっとも合唱は指揮者の意図を汲みつつメンバー全員でつくりあげるわけですが、それでもひとりひとりの想いで構成されるものだと思います。)伝えたいという想いがうまく届くように演じなければならない。

いろいろなことに負けてしまいうまくいかなかったこともこれまでたくさんあったし、これからもうまくいかないこともたくさんあるかもしれない。だけどその時の状態や制約のなかで自分にできることは何だろうって考えてできるだけ自分が持つ理想に近づけられるようにしたいな、と思います。

 

私は合唱活動のおかげで上記のことは自然と身についたところがあるな、と感じています。もちろんここ数年で学んだこともたくさんあると思いますし、まだまだなところも多い。そもそも今回とりあげたこと以外にも心がけないといけないことはありますし・・・構成とか時間配分とか。

これから発表の経験を積んでいく方がいらっしゃるなら、まずは発表したい内容を自分なりに咀嚼して自分の言葉で語れるようになることを目指すのがいいかな、と思います。伝えることは場数だと思うのですが、ひとりでも声に出してエアの相手に伝えることを意識して練習するのがよいのではないかなーと思っています。

ひとりひとり違うひきだし ---テストを考えるとき---

4月23日に開催されたとてか04でのみわさんの発表から。

sssslide.com

 

じゃぁ私はどうなんだろうな?って考えてみた。
・・・それを書くとながーくなるので、そこから思ったことを書こうと思います。

まず、プログレスダイアログのテストって考えるときに、イメージするものが人それぞれなんだなぁってこと。
私は最初、昔Windowsアプリのテストをしていた頃を思い出していました。
だけど、みわさんのスライドを読み進めるうちに、あぁシステムモーダルって・・・そういえばこの製品が組み込み系でパネルだったらそういうケース多いね。だとしたら割り込み処理って入ることあるよねー(割り込み側が負けなきゃいけない?)・・・裏で勝手に動くものもあるよねー(それは並列処理できなきゃいけない?)・・・って発想が広がるのを感じました。そして、これはPCのアプリの場合とモバイルアプリの場合と組込み系のパネルの場合とWebアプリの場合とではそれぞれ意識することが変わってくるんだなっていうのを改めて実感しました。
そういう点でこのネタは美味しい!みわさん、さすがだなぁ

あとは、経験が長いがゆえに流してしまうことと、なんでも気にすればよいというものではないなというのと、そのバランスって大事だな、ということ。
例えば製品の性能が良くなってプログレスダイアログの表示時間が短くなったとして、それを表示する意味がなくても害もないならそのままでもいいじゃない?ということもある(まぁでもそれならキャンセルボタンはテストできないから実装外そうよとか言うかもしれない)。まだ表示時間が長くなるケースもあるかもしれない。なんでもかんでも指摘すればよいわけでなく、どうします?って問いかけるのがいいんだよなーって思っています(たぶんみわさんはそうしているのだと思います)。 逆に、プログレスダイアログの表示が長くても「そんなもの」と流してしまいがちになることもある。これはみわさんの発表を見て改めて気をつけようって思いました。

あと、プログレスダイアログのテストじゃなくてもはや処理のテストですよね^^;っていうのもありますね(笑) でも一緒に考えますよねーうんうん。

確かにいろんな背景を持つ人と比較すると楽しそう。
他のお題とかもないかなーって考えています。なにがいいかなぁ・・・

テストの活動のはなし

Testingという用語をJSTQBの用語集から引用すると、

「全てのライフサイクルを通じて実施する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価をすること。」

なので、活動全体を示すのですが、
よく、「CheckingとTesting」という対比した使われ方をするとき、Testingは創造的だったり学習の要素が入ったりという意味合いを持つなーという印象を持っています。
最近、JaSSTで情報を得たり話をしたりする中で、自分や自分の周りの活動はどうなんだろう?と考えてみるようになりました。

で、描いてみた→何人かに見せてフィードバックもらってみて今に至る。↓

f:id:shiozi:20160423102357p:plain

まずはテスト対象に出会う前に備わっている知識や経験や能力があります。ここで持ち合わせているものが活動に影響するのですが、その話はまた別の機会に書きます。

テスト対象に出会うと様々な情報が入ります。その情報を分析して、不明な点や気になる点を調べたり質問したり仮説を立てて検証したりします。そうして新たな情報を得て更に分析します。そのサイクルをぐるぐる回して共通理解を得たら、そこからテストのスコープを決めたりスクリプトにするテストを決めたりします。ぐるぐる回している間はTestingですが、スクリプトになる時点では期待結果がわかっているのでCheckingになっていると思います。

スクリプトにしないけれど、気になるから「一度やっておく」テストもあります。こちらもすでに想定済みのものなのでCheckingかな?って思います。

上記の流れに対して、分析したのだけれど理解しきれていなかったり誤解していたりということが起こることがあります。たぶん誰にでも起こると思います。この「わかったつもりになる」状態がある、ということに気付きました。この状態に陥るとテスト実装や実行の時点でなにかトリガーがかかって後で気付くことになります。気づいた時点でTestingのループに戻るなぁ、と。
この図があると、なるべくこっちのルートを辿らないようにしたいよね、って話ができるなぁとも思いました。

更に、残念ながら情報を得たらそのまま考えずにテストを作ってしまうルートもあります。悪い意味のCPM(コピーペーストモディファイ)はこちらのルートで作成されるので、概してテスト実行時に気づけばラッキーという状態になります。これもなくしたいよねって話がしやすくなりました。

 

あと、この図で探索的テストってどこのことを言っているんだろうね?という話もできるなぁって思っています。
探索的テストって、Testingとイコールではないというのが今の私の考えです。本当はスクリプトにできるんだけど様々な理由でスクリプトになりきれない(あるいはする必要がない)ものがあって、それを補うための探索的テストってやるよね?
スクリプトの品質が悪いことを補う探索的テストもやるよね?
この図でTestingとしているループで実装物を触っている場合を探索的テストと呼ぶ人もいるよね? 

今後、こういう話をいろんな人としていきたいなぁって思っています^^

・・・って、本当はとてかでここまで言いたかったんだよぉぉ(笑