CAT GETTING OUT OF A BAG

What the tester is thinking.

愛すべき不完全なテストケースについて

「完璧なテストケースなどといったものは存在しない。完璧な絶望が存在しないようにね。」村上春樹さん風 (『風の歌を聴け』より)

 

わたしはテストケースに完璧を求めていない派だけど、こうなる前までは”完璧”とか”漏れがない”とか…なんだろう理想のテストケースを追い求めていたように思います。

だから手を動かしてテストする時間より、理想のテストケースを作るために考える時間のほうが多くなる日もあって(テスターなのにテストしてないのでは!)と不安になることもありました。

何をどれくらいの密度や深さで、どのようにテストしたらよいのか、強弱は?テストする順番は?…それらを考えることもテストの一部なんだけど、やはり実際にシステムやソフトウェアを触って動かして、はじめてテストの価値が生まれるというか、生を与えられたように感じてしまう。

とにかく漏れのない完璧なテストケースを作って、きちんとテストしたい!と言う気持ちが強かったのは確かです。

 

そんなわたしが、なぜ、完璧なテストケースを求めなくなったのか、それで平気でいられるようになったのかを考えてみました。


1. イテレーション開発がそれを許してくれなかった

完璧なテストケースを考えてると、あっという間に開発に置いていかれます。

考えてみればウォーターフォールでの開発だって時間の制約があるんだから同じなんだけど、毎日、毎週締め切りがあるのは大きい。

で、どれくらいのスピードかと言うと、JSTQBシラバスに載ってるテストプロセス(テスト計画、テスト分析、テスト設計、テスト実装、テスト実行、評価&レポート)を短いときは1日で全部やるイメージです。とにかく今のチームの開発のスピードがめちゃくちゃ早いので、テストのサイクルも必然的に早くなります。

 

開発手法のせいで、完璧なテストケースを作らせてもらえないわけですからね、さぞかしモヤモヤするんだろうな…と思いきや、そうでもなかった。だいぶ適当な人間なんだなぁとあらためて思いました。*1

 

2. 不完全さが新しいテストケースをつくる

すでに存在するテストケースをそのまま実行してもバグはほとんど見つかりませんが、そのテストケースに対する疑問やテストの不足を補うようなテストをすることで、バグを見つけることができます。*2
プロダクト(テスト対象)の品質自体も大きく関係しそうですが、わたしたちのチームで見つかるバグのほとんどがこれです。

またチームのメンバーが完璧なテストケースではないことを知っていて、それを容認していることも大きいと思います。開発しながらテストケースも一緒に育つ感じ。子供を育てながら、親も一緒に成長するのと似ています。そこには愛がありますね。

 

3. 完璧なテストケースは存在しないことを受け入れた

1と2がわたしの中では大きいのですが、最後にこれも。

でも諦めているわけではないんですよね。より良いテストを目指して、不完全なテストケースと共に、これから先もまだまだ新しいテストケースを開発していくし、イテレーション開発に組み込んでみたい中長期のテストケースもある。だから(完璧なテストケースは存在しないんだから)やり過ぎに注意しなさいよ!くらいに思えるようになったんじゃないかな、と。

 

テストケースについて書いてみたくなったのは、これを読んだからでした。残り2回も楽しみです。

 

 

 

*1:適応能力が高いことにしたい。

*2:このことは多くの人がそう感じているようなので、そろそろこの現象に名前をつけてもいいと思う。

気の持ちようを変えるのは大変なんだよねって話し

これとてもおもしろいエントリでした。気の持ちようを変えるための、具体的でお手軽なアイデアですね。

 

過去にわたしも「そんなの気の持ちようなんじゃないの?」と言われたことが何度もあるし(それはそれで勇気づけられたことも確かなんだけれど)本屋さんにずらりと並んでいる自己啓発書やスピリチュアル本にも、確かそんなことが書いてありますね。
だから世界は気の持ちようでどーにでもなるんだと思います。

でもね、気の持ちようを変えるために、わざわざ自分で自分の気持ちを高めたりすること自体が大変なんですよ。そのうちそんな自分で自分の気持ちを高めている自分を冷めた目で見る自分が現れて(なにやってんの?)(ミサワなの?)などと言い出すので、当初の目的も忘れ、お恥ずかしくなってきます。*1

 

あれ、何の話しをしてたんだっけ?
ああ、気の持ちようを変えるのは大変なんだよねって話しでした。

 

ところで、うちのチームはバグはドラゴンではなくバグと呼んでいますが、チーム内でしか通用しない言い回しというか隠語みたいなものが、いくつも存在します。朝会とか、開発中の普段の会話の中でそれを使っては、みんなでクスクスしてる。わりとシリアスな場面でも関係なくそれは使われるんだけど、そんなときは必要以上に入っていたチカラがふっと抜けたりしてね、精神衛生上とても良いのです。開発に笑いは必要だね。

 

 

 

*1:だいぶ大人になったので自分自身のことを冷静に観察できるようになっている。

JaSST'15 東北に参加します

JaSSTソフトウェアテストシンポジウム-JaSST'15 Tohoku

今回のテーマは「レビュー」なんですね。楽しみだなー。

参加申込みしたときにレビューに関するアンケートがあったので、こんなことを書いてみました。安達さんのお話(ウォークスルーで疑似体験)や倉貫さんと西見さんのライブコードレビューから何か見えてくるといいなあ。

 

Q7. プロジェクトで作成されるドキュメントについてレビューを実施されているか教えてください。

◎レビューをしている

 

Q7でレビューしている方はレビューのやり方について具体的にご記入ください。

状況に応じて対面、机上レビューを実施しています。

はじめに何についてレビューしてもらいたいのかを宣言します。逆にレビューしてもらいたくないことを宣言するときもあります。

対面でのレビューは、あらかじめ時間割りやゴールを示しておくことが多いです。

朝会でのチケットの読み合わせもいわゆるドキュメントではないですが、レビューの要素が強いです。

 

Q8. プロジェクトで作成されるソースコードについてレビューを実施されているか教えてください。

◎レビューをしている

 

Q8でレビューしている方はレビューのやり方について具体的にご記入ください。

わたし自身はテスターなので参加してませんが、周りのプログラマを見ているとしょっちゅうレビューしてる感じ。ペアプロはよく見かける光景だし、誰かのモニタを数人で囲んでコードを見てなんかやってます。必要だからやってるんだと思います。

 

Q9.レビューする場合、困ったこと、うまくいかなかったことがあれば教えてください。

レビューで指摘されるとムキになって反論?というか言い訳?いや説明する人がいます。こちらは単にコメントしただけで責めるつもりは全くないので、びっくりしてしまいます。なんか悪いことしたような気持ちになってしまうときがあるので、どうにかなるなら、どうにかしたいです。

 

Q10.レビューについて何かお聞きしたいことがありましたら、ご自由にご記入ください。

レビューはレビュー自体というかみんなで意見を出し合って紆余曲折しながらすり合わせをしていく過程そのものが大切というか肝だと思ってますが、レビューすることが目的になってしまう残念なレビューもあります。ふたつのレビューの分かれ道はどこにあるのでしょうか?

 

品質特性とバグの聞こえる化

午前中に見つかったクリティカルな問題が、お昼休み前には原因が分かり一安心。

会話(問題が起きる前にどんなことをしていたか)とログでだいたいのことは分かるんだなあ。これって品質特性で言うところの「保守性(解析性)が高い」ということだよね?すばらしいなあ。

午後になって、対応してくれたプログラマSさんに「もう原因が分かっちゃったんですねー。早くてびっくりした。すごーい!」と言ったらSさん、

隣でmiwaさんがテストしながら「あ…」て言ったでしょう。気になって(コーディングする手を止めて)miwaさんの画面を見たらあれ(深刻な状態)ですからねー。その場でログとらせてもらってすぐに見れたからですよ!

なんだかわたしまでほめられた気分。うれしいな。

 

今回のケースは”テスターが問題を検出してからプログラマに伝わるまでの時間”がゼロでした。世の中にはこんなメトリクスがあるのかどうかわからないけど、とにかくコードは日々変化してしまうので、この時間は短ければ短いほどいい。多分みんなそう思ってるはずです。

 

ところで、わたしはほぼ毎日プログラマの隣でテストしているのだけど、あれ?おかしいな?と思った時、真剣にコードをかいてるプログラマに話しかけるのは、少々気が引けてしまうのですよね。

朝会で今日対応してるチケットがどれとかだいたい把握してるので、今まさに重要で繊細なところを直してるのかもしれない、ここで声をかけたら思考を妨げちゃうかも…と思うわけ。

 

さっき検出した問題がプログラマに伝わるまでの時間は短ければ短いほどいいと書いたけど、そうなの。アタマでは良いと分かってはいても、なかなか行動に移せないことって、ある。(それはわたし自身の内面的な問題で他人にはどうでもいいような些細なことだったりするのだけど…)

そんなこと、ありませんか?

 

だからそんな時は問題の大きさによって「ん?」とか「あれ?」とか「あわわわ」とか声に出してみようと思います。これなら気が引けないね。だって独り言だもん。

うまくいけば周りのプログラマたちがシグナルを受信して、わたしのモニタを覗きこんでくれるはずだ。

誰も気がついてくれないときは、いつも通りチケットを発行しますね。

 

Feelingを大切にするということ

先日行われたJaSST'15 Tokyoのマイケル・ボルトンさんの基調講演はとても良かった。なにが良かったのかって。それはわたし(たち)のやってるテストが間違ってないんだな、ということがわかったから。

うーん「間違ってない」というのは言葉の選び方として適切じゃないな。正しくはボルトンさんの提唱してるRapid Software Testingのアイデアのいくつかをわたしたちのチームでは(たまたま)行っていて、はじめて聞くボルトンさんの話しに「うんうん」「そうだよね」「わかるわ~」という風に共感できてしまい、単純に嬉しかったのかもしれない。

 

そう、わたしたちのチームでFeelingはとても大切にされている。それは表示がちょっとずれてて気持ち悪いだとか、ボタンが一瞬チカチカするとか、この画面だけ雰囲気が違うなーとかいった視覚に関するものから、なんとなく動きがもっさりしている、昨日より応答が1、2秒遅くなったような気がするんだけど・・・といった体感速度に関するものなど実にさまざま。(そういうチケットにはオノマトペが使用されることが多い)

 

そしてこのFeelingを適用する範囲は製品そのものだけにとどまらず、仕事のやり方や態度についても同じだったりする。

 

わたしたちは毎朝チケットを読み合わせるんだけど「その直し方だとヤバいかも」と設計のおかしさや将来的な危うさに関する匂いを嗅ぎつけたり、今日の作業内容(どう実装する)を話すその○○さんの言動から「○○さんは混乱してるっぽい」ということが分かったりする。今日は一度も視線を合わせてこないんだよなーといったことで、そのシグナルが立ったりもするらしいし、体調や機嫌もバレる。

ちなみに、わたしがノリノリでテストしてたりすると異常値っぽいフラグが立つようですよ。気をつけなければ。

 

そうした「おかしさ」を感じることができたとしても、それを受け取る側の態度も重要で、例えば、テスターが見つけた「おかしさ」や「違和感」を、プログラマが「それはそういう仕様だから」とか(そんなのどうでもいいじゃん、面倒くさいなぁ)とかいったスタイルで接してしまうと(そういうのは言葉になってなくても分かるのよ)、それ以降テスターはそういったFeelingを起点とした報告はしなくなる。きっとね。

そして、これはわたしの場合だけど、わたしの感じる「おかしさ」や「違和感」を何がなんでも直して欲しい、という気持ちはない。わたしがなぜこれをおかしいと感じるのか。それをチームのメンバーにも分かってほしい。うん。それだけです。

 

幸いわたしが属している2つのチームはFeelingを共有する基盤みたいなものができていて、テスターから報告されたFeeling(例えば「おかしさ」)についてどう取り扱うのかをチームのみんなで話し合っている。

ちなみに、こういった報告はテスターだけじゃなくてプログラマからも報告される。思ったことや感じたことを素直に表現してもいいチームの雰囲気ができあがっているのは、わりとポイントかもしれないね。

 

話を戻すと、その結果コードが修正されることもあれば、仕様から見直しが入ることもあるし、時には「おかしさ」をチームで受け入れることもある。そのようなときは「おかしさ」の発生頻度やユーザーの困り具合、それを修正するためのコスト、修正しない場合のリスクなど様々な観点で話し合う。いずれにせよ「おかしさ」について、チームとしてその時点でのベストと思われる判断がなされる。

もちろん「おかしさ」自体が間違っていることもあって、その場合はテスター自身が製品やテストのやり方について学べる機会となる。

 

Feelingを大切にするということは、自分たちの作る製品やチームのメンバーの仕事のやり方や態度に興味を持ち続け、日々こころの目で感じながら注意深く観察し、みんなが感じたFeelingに対し真摯に向き合い、チームとしてそれをどう取り扱うのかを決めていくことなんだと、2つのチームを見てわたしはそう思う。

 

品質とは何か

大学生の娘が夏休みで帰ってきたので、宇都宮まで映画をみに行ったときの話し。
目的地まであと20分というところで、車のエアコンの挙動がおかしくなりました。

 

熱風しかでてこない。

 

車内の温度と湿度が急上昇する中、落ち着いて関連しそうな機能をいじくってみた。
 
  • 温度、風量、風向きの設定を変化させる
  • エアコン機能のオン/オフ切り替え(上記設定との組み合わせ)
  • AUTO機能のオン/オフ切り替え
  • 車の再起動(エンジンを切る→エンジンをかける)

 

やっぱり熱風しかでてこない。
壊れたな...。

 

エアコンを止めて窓を開けたら、もっとひどいことになったので閉めました。20分後、ふたりとも汗だらだらになりながら目的地に到着しました。久しぶりに娘とデートできる嬉しさもあり、先に車屋さんに行って見てもらうという発想はありませんでした。今日は涼しくなってから帰ろう。それに、地下の駐車場に何時間か入れとけば、エアコン直るかもしれない。
 
6時間後。
やっぱりエアコン直ってなかった。
むむー。
 
窓全開にして走り出したら、少し前に降った雨(夕立)のおかげで、ぬるい風がビュンビュン入ってくる。後部座席で「とーばーさーれーるー」とか言って、長いストレートの黒髪をなびかせてはしゃぐ娘。
 
運転しながら、考えてました。
 
ちょっとした不具合の原因を調べていったら、システム上の大きな問題が見つかった、というようなケースもあるよなー。走行中いきなりエンジンが止まったりしたらそれこそ困るし、やっぱり早めに見てもらおう。
 
近くのトヨタカローラ店とトヨペット店に行ってみたけど、やってませんでした。

 

そうか、お盆休みか!
しかたないなー。直るまで極力出かけないで、ひきこもろう。

 

1時間後。
 
薄暗くなってきたのでスモールライトを点けて、今日の映画楽しかったねぇなんて話していたら、オレンジ色の明かりのついたトヨタカローラ矢板店が見えた。
 
受付のそばにいた、日焼けしたエンジニアに声をかけました。
 
「あの、エアコンが効かなくなってしまって。予約してないんですけど、見ていただけますか?」
「大丈夫ですよ。中でお待ちくださいね。」
 
15分後。
 
「この部品が壊れてました。」
 
iPhoneのキューブ型のAC充電器のようなものを見せてもらう。
 
「部品を交換して確認してみたんですが、特に問題なくエアコンも使えるんで、もう大丈夫です。」
 
ほっ。よかった。
 
「ありがとうございました。本当に助かりました。」
「おいくらになりますか?」
 
「ああ、交換した部品は新品ではないので、いいですよ。」
 
エンジンをかけるとエアコンから冷たい風が出てきました。
 
嬉しかったこと
 
  • 受付時間ぎりぎりで、しかも飛び込みだったのに、嫌な顔せずに丁寧に応対してくれたこと
  • 原因を突き止めてくれたこと(しかも短時間)
  • エアコンを直してくれたこと(しかもタダ)
  • 帰るとき、深々とおじぎをして見送ってくれたこと
 
当たり前のことなのかもしれないけど、どれもこれもすばらしい。たぶんエアコンが直らなくても、感動して帰ってきたんだろうなあ。
 
これはいったい何品質なんだ?
 
品質を語るときはデータで語れってよく言われます。今回の件だって、MTBFやMTTRを出そうと思えば出せるけど、そういうのじゃないんだよなあ。どこかで見た「顧客満足度No.1」とかいうキャッチフレーズでもない。
 
数値では表せないけど、体験したらそれはもう強烈な記憶として刻まれてしまう品質って、何なのかしら?
 

10日でおぼえる C#入門教室

  • この本のすごいところ「10日でおぼえられない!」
  • (あーとんさんなら)「10日でおぼえる C#入門教室」
  • "本書はプログラミング経験ゼロの状態から始めて、10日間で中級レベルまで一息に駆け上がることを目標にしたプログラミング入門書です。" 
  • 初心者の壁は「書き方」、中級者の壁は「読み方」
  • ”中級者になるには、プログラムから定石や設計思想を読み取る力が必要です。"
  • ”大量のリストに何をなぜ行っているかの説明を入れて読み下せるようにしています。”
  • ものすごく丁寧(ここまで書いてあるのは見たことないなー)
  • 注釈がよい
  • かなり文系の書物
  • 読み物としても大変面白い
  • まとめると「おすすめです!」