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

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

どうしてそうなった?を考える

少し前に炊飯器を新しく買い替えました。

炊飯器もいろいろ進化していて、ごはんは美味しく炊けるしどうやらパンも焼けるらしい。色も白じゃなくて嬉しい。(家電は白じゃないほうが好き。そしてできるだけその空間にあった色にしたいと思っている!)

だけど一点困ったなぁと思っていることがあります。

f:id:shiozi:20180117180501j:image
炊飯器の内蓋を外してしまうと外蓋が閉まらないのです・・・内蓋を洗って乾かしている間は蓋が開きっぱなし;炊飯器は蒸気が出るので湯沸かしポットと一緒にスライドする台に置いているのです。だけど写真のように天井があるので、ポットを使う度に蓋が擦れちゃうよ〜・・・

ところで、どうして内蓋を外すと外蓋が閉まらないつくりになったんでしょう???
商品の企画者ではないから背景は推察でしかないのですが、考えてみました。

内蓋を外すと外蓋が閉まらないようにしたかったのではないかな?
どうしてそうしたかったのかな?
きっと内蓋を取り付けるのをわすれて炊飯しちゃうケースがあるんじゃないかな?
そのまま炊飯すると蒸気だけでなくお湯とか米とかが吹き出しちゃうんじゃないかな?
それを「使う人が気をつける」ではなくて、気をつけなくてもそういう事象が起こらないようにしたほうがよいと思ったのではないかな?

そんな風に考えたら、あぁそうかそりゃそうしたいよねって思ったのでした。

だけどやっぱり困るんですよね(笑)
そして私はこういうマイノリティーな立場になることがなんか多いんですよねぇぇ・・・(;・∀・)

何を探しているのか?

テストを行うときに「バグを探す」と言われるのだけれども、私はそういう感覚かと問われると、そうである場合もあるけれどいつもそういうわけではないなぁ、と答えます。
常に間違い探しをしている感覚はあまり無いんですよね・・・

仕様に関する何かしらの情報が入ってきたときに、条件反射的に思うのは「この仕様で起こりうることはなにか?」「なにか忘れられている気がかりはないのか?」「前提条件が崩れる何かがないか?」ということであって、それは間違いとかじゃないんですよね。頭が可能性を探ろうとしている感覚がある。
気になることに対して対策が用意されていたら「おぉ、素晴らしい!」って思うし、用意されていなかったら「どうなる?どうする?」と開発側に確認してみる。その確認タイミングがたまたま実装後だったらバグとしての報告になっちゃうかもしれないけれど、バグを見つけたいわけじゃない。

実装物を操作してテストを行なっているときは、操作に着目して、バグを見つけようと思っていることが多いかもしれない。だけどそのときは、探すというよりお決まりのパターンを試すって感じなんですよね・・・探してないよなぁって。探しているのは「お決まりのパターンが適用される箇所」な気がします。
そして、実装物の操作がテストの目的ではなくて仕様の学習だとしたら、先に書いたように気がかりを探す。なるほど、目的によって分けているかもしれません。

最近は実装物を相手にするよりもドキュメントを相手にすることが多いし、実装物を相手にするときも仕様の学習をしていることのほうが多いから、あまりバグを見つけようとする機会が無くて、だから余計に「バグを探す」感覚が無いのかもしれません。

そして、バグを探すとか間違いを探すとかいう言葉は、テスト担当者を疎ましい存在にしやすくなっているんじゃないかなぁとも感じていて、だから探しているものは何なのか?を考えるのは思っているより大事なことなんじゃないかなぁと感じたのでした。

仕様を理解するということ

この記事を書く前に、いや似たようなこと以前に書いたっけ?って確認してみたら、やっぱり書いていました・・・ネタ自体は「仕様を理解しないでテスト実行してもよいのか?」という話だったので今回言いたいこととはちょっと違うかな。

仕様を理解する=仕様書を読む、仕様書に書かれていることを(表面的に)理解するということではない

だけど、仕様書を読めば仕様は理解できるって思っている人は多いのではないかなぁ?そして、仕様書を読めばテストケースは作れるしテストできると思っている人もまだまだ多い。

だから、開発者とテスト担当者が分かれている場合に、仕様を共有しようという考えに至らないのかなぁ・・・でもそういう組織って開発者同士でも仕様を共有しきれていないと思う。実際そういうケースに遭遇することがある。

 

仕様を理解するというのは、仕様書に書かれている文章がわかるということではないよね。
文章は読めばわかる。読んでわからない用語を調べれば、文章としてはわかる。
だけど、それは理解したことにはならない。
仕様を自分の言葉で説明することができるかというと、できない。

仕様を理解するためには、
仕様が定められた背景、根拠というものを知る必要がある。
そして、仕様書に記された文章の裏に暗黙的な情報が隠されている。
それらを見出して自分の中で考え咀嚼して初めて理解できる。

そしてその理解が必ずしも全員一致しているとは限らない。
だから理解の内容を共有して認識を合わせる必要がある。

そんなことを普段の開発活動で行っているだろうか?
開発担当者は行っているかもしれない。
テスト担当者はそこに存在しているのだろうか?
・・・これまで私が関わってきたところの多くは残念ながら仕様の共有が行われていませんでした。

 

私は、無駄なテストというのは仕様が共有されていないときに「心配だから」とか「念のため」とかいう理由で追加されてしまうテストの中に含まれていることがあると思っています。肝心の仕様が共有されていないから見当違いなテストを行っていたりする。
(その他にテストレベルを意識せず重複させてしまうテストも無駄なテストになりますが、ここで言っているのは完全に意味のないテストです。)

もうひとつ、
仕様を理解したらすべてのテストケースが作れるわけじゃない。
仕様を理解した時点で見えてくるものがある。それは仕様の外側にあるもので、テストは仕様と外側にあるものとをつなげて考える必要がある。
だから、テスト担当者が仕様を理解するのは前提にある必要条件なんだと思っています。必要条件が揃わずにテストを考えようとしても、そりゃ無理だよね・・・

 

だから、もしテストが独立している組織であれば、開発者はテスト担当者との仕様共有をないがしろにしてほしくないし、テスト担当者は仕様を理解したうえでさらに仕様を補う役割を担っていることを自覚してほしい・・・と願っています。

 

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

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