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

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

勘と経験ってなんだろう?

11月3日に盛岡でちょこっとお話をしてきました。

https://www.slideshare.net/shizubanban/20171103-moriokatest-banpdf-81792387 

探索的テストについて話をしてほしい、ということでした。探索的テストとはなんぞや?という話ではなく、私が実際どうやって探索的テストをしているのか?というあたりが聴きたいということで。
その後、主催者側から、「アドホックテストの時に何をしたらいいか悩んでしまうことが多く、どのような経験と勘を頼りにしてテストを進めているのか知りたい」というメッセージが届きました。

・・・経験と勘ねぇ・・・よく言うんだけれどねぇ・・・

その後更にヒアリングしていくなかで、同じようにテスト実行をしても発見するバグの数に違いがあり、それは勘、経験、センスなどによると思うという話がでてきました。

・・・そうなのよね。そこらへんのワードが出た時点でなんか止まっているのよね。
私自身も、勘とか経験とかセンスとかそういったものはあるよね、とは思います。
もう少し言うといくつか特性が必要でそれをどれだけ持ち合わせ、うまく組み合わせて能力を発揮させているイメージがあります。

でもそれだと属人性だから仕方がないよねっていう話で終っちゃう。そういうのを求めてはいないわけですよ。現場も、今回の参加者も。

じゃぁなにをしたらいいんだろうね。
まずは自分たちが思っているものを外にだすのがいいんじゃないかな?
きっと、勘という言葉に対する認識はそれぞれ違うよ。
経験ってひとことでまとめているけれど、どんな経験が必要か見つめていないよ。
・・・そう思ってみんなで考えて共有するワークをいれてみました。

実際、参加者のみなさんは、それぞれ少しずつ異なる見解を持っていました。各自が抱く見解を見せないままに「勘」とか「経験」で済ませてしまうと、なんか共通認識を持っているようにみえて全然共有できていないんですよね。

そして、私は「勘」に対してこう考えている、という見解を紹介しました。
もちろん直感というものもあると思いますし、他の見解もあるはずです。ただ、コントロールできるものを示すことで、なにをしたらよいかが見えてくると思いました。

私は、勘が働くときには何かしらのコンテキストが存在していると考えています。
なにもコンテキストがなければなにも思いつかない。気付くとき、考えるときには常に土台となるなにかがある。それを「情報をつなげる」と表現しました。
土台となる情報があって、新しい情報が入ったときに、情報をつなげて考えることで発想が行われる。
探索はつまりそういうことを行っているのではないでしょうか?

一方の経験ですが、これは仕事上の経験だけではないんですよね。雑学のレベルから、普段の生活から、人との交流から、生きていく中で得る様々な情報が役に立つことがある。だけどそこから得た情報をそのまま蓄積しても上手く使えなくて、自分の中で一般化させることで活用範囲を広げると上手く使えるようになる。

そして、情報をうまく活用するには、好奇心だったり観察力や俯瞰力だったり、洞察力だったり、学習理解力だったりと、いろいろ必要であることは感じています。(勘とは?に対してこのような特性や力を挙げている方もわりと多かったです。)ただ、だからといって属人性だけで片付けてしまうよりも、トレーニングできるところはあるはずだし、情報を活用することが必要なんだねっていうことを意識したら暗記だけではダメなことや情報そのものを集めるだけでなく一般化できなきゃうまく活用できないことも見えてくるんじゃないかな?ということを伝えようとしました。伝わったかなぁ?

ちなみに、このスライドにもロジックブランチを利用して、情報を因果の関係でつなげて示しています。情報をつなげる解説に対して情報をつなげるツールを用いてみたのです。
ソフトウェアテストの活動において考えるときに、ロジックブランチはとても相性が良く使いやすいと思っています。

 

余談ですが、私のStrengthsFinder TOP5って、
1 収集心
2 適応性
3 内省
4 着想
5 慎重さ
なんですよね・・・・・
幅広く学習し、場当たり的に対処でき、よく考え、発想し、判断して疑うんですよ^^;
あーもうそうですねまさにそのとおりですって自分で納得しちゃいました。

テスト設計者の思ったとおりにテスト実行してもらえないとき

テスト設計からテスト実行までを一人で行っていた人が、テスト設計だけを担当してテスト実行を他の人に任せるようになったときに、テスト設計者の暗黙知が表現できていないなどの理由でテスト実行者が異なる認識でテスト実行することがある、「ここまでみてほしい」と思うところまでみてもらえない、というもどかしさを感じる、ということを経験したことがあるかたはどのくらいいるのでしょうか?

私も初めてこのケースに遭遇したときは「なんでそこまでみないのっ??!」と驚いたり、自分でできたらこんな見落としはしないのに・・・と思ったりしました。。。今でも思うことはありますね(^^;

このようなことが起こると、テスト設計時の狙いが実行時に漏れてしまうため、なるべくテスト設計者とテスト実行者のずれを少なくしたいと思うのですが、その際に「誰でも同じようにできる」を目指してしまうことがあります。特に10年前とかそういう傾向が強かったように思います。しかしながらその結果が嬉しかったかというと、メンテナンス性の悪いテストスクリプト、殺虫剤のパラドクスになりやすいテストスクリプトというものができあがり、テスト実行時に気付いて欲しい他の問題にも目がいかなくなるという問題が起こりました。

これらの現象をロジックブランチにしてみました。
※使い勝手がよいのでastahのアクティビティ図のツールをつかっていますが、アクティビティ図ではなくてロジックブランチです。バナナ型はさすがにないので楕円で代用。
f:id:shiozi:20171016170215p:plain

もし、テスト設計者と実行者が異なる場合、かつ、テストスクリプトに対してテスト実行者が違う解釈をすることを防ぐならば、結果として、誰もが同じようにテスト実行できるテストスクリプトを目指そうとする。その結果として嬉しくないことが起こる。

逆に、もし、テスト設計者と実行者が異なる場合、かつ、テストスクリプトに対してテスト実行者が異なる解釈をすることを許容するならば、結果として、テスト実行者によって実行内容が異なってしまう。こちらのケースではテスト設計者の想定外の不具合を見つけることができるかもしれないけれど、テスト設計者の意図したテストは実行できないことがある。その結果として嬉しくないことが起こる。

この問題については解決法は一つではないと思うし、組織やプロジェクトの背景により対策は変わると思います。
私が考える案として同じくロジックブランチで示してみます。
緑のところが追加した部分。

f:id:shiozi:20171016171035p:plain

私は、人が実行する場合はテスト手順や値に自由度を持たせるほうがよいと思っています。そのほうがテスト実行者の思考がかたまらないのと、テストウェアとしての再利用度が上がると思っているからです。そのかわり、確実に「そのテストは何を確認したいのか?」というテスト設計者の意図を記入しています。あとは、テスト実行者もいろいろ考えて試せると信頼するほうがよいと思います。

そして、考える必要が無いほどのテストスクリプトであれば、できるだけ自動化を目指したほうがよいし、そのようなテストは繰り返し行う可能性のあるテストに絞り込んでいくほうがよいと思っています。

もうひとつ、テストの値や操作方法を入れ替えることが容易にできるような、再利用の仕組みを考えることも有効だと思います。これは自動化であれ手動のままであれできることです。その仕組みをもつテスト管理ツールもありますね。

みなさんの現場ではどうしていますか?それはなぜですか?その結果どうなっていますか?そんなことをこの様に図にしてみることで、「ここはこうしたらよいかもしれない」「ここが変わればよいかもしれない」ということに気付くかもしれません。

処理の組み合わせのはなし

もう10年以上も昔になりますが・・・ビデオレコーダーのテストを担当していた頃のはなし。ビデオレコーダーって結構いろんなアプリが搭載されているんですよね。テレビチューナーからの映像を映したり、録画をしたり、ビデオファイルを再生したり、音楽ファイルを再生したり、番組表データを取り込んで表示や操作をしたり、録画予約をしてタイマー稼働させたり・・・そうなると、システムとしてはそれらのアプリが同時稼働したり割り込みをしたり排他をしたり・・・ということが起こるのですが、当時はその確認をしなきゃいけないとは思っていてもどうやってテストケースを作成してよいかがわかっていなくて、結局どうしたかというと縦軸横軸にそれぞれのアプリを並べて勝ち負け表を作るしかなかったのでした。。。とにかく組み合わせをみよう!みたいな感じ。(いいわけですが、私がそうだったというより組織としてその方法しか知らなかったのです。)(あ、たしか私の担当箇所は細かくタイミングを区切って膨大なテストケースにした記憶が蘇ってきた・・・;)

月日は流れ、最近ではようやっと私に図を描くという能力が備わり(笑)
少し前に、テストにおける「組み合わせ」を考える機会がありまして、そのときに処理の組み合わせで確認する必要があることをまとめておきたいなぁと思ったのでした。

 

f:id:shiozi:20170728194530p:plain

処理Aと処理Bが同じ機能(アプリ)であることもあるし、異なることもある。
どちらもテスト対象であることもあるし、片方が外部のものであることもある。
それぞれで担当が異なっていたり、片方が外部であるときに、仕様検討が不足しやすかったりする。いずれにしても、そのシステムがどういう環境で、どういうユーザーに使われるか?を意識する必要がある。
もう少し突っ込んだ話をすると、処理Aの中にも細かい処理があったりして、その処理ごとや処理の区切りのタイミングなんていうのを意識しないとダメなこともある。そのときは処理Aに区切り線が必要になる。

仕様策定のときにこの図が頭にあるのがいいなぁって思っています。もちろんテストを考えるときにも。

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

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

スタートとエンドを描きましたが、それ以外の矢印は順序ではなく因果関係を示しています。楕円は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