CAT GETTING OUT OF A BAG

What the tester is thinking.

回答はぜんぜん急いでません!!!

開発中のプロダクトを動かしているときに「あれ?おかしいな?」となるのは、みなさん何度も経験していると思います。そのあとどう行動されているでしょうか。

システムダウンしてしまうような重篤な問題なら、あなたはチームのみんなに一番早く伝わる方法で伝えるでしょう。では、そこまで急がなくてもよさそうな違和感ならどうでしょうか。その違和感を調査するのに適任と思われるプログラマーHさんが、ここのところなんだか忙しそうな気配を醸し出していたらどうでしょうか。

昨年までのわたしは全員同席のチームに所属していたので「急がなくてもよさそうな違和感」でも、すぐに割り込んで誰かに伝えていました。朝会でストーリーについて議論しているときにAさんの顔色が変わったなとか、Bさんの体調が良くなさそうとか、そんな些細なことも自然に感じとっていました。

現在のチームは全員同席ではなく、みんなの本当の状況がわかりません。オフィス自体が(固定席を設けない)フリーアドレスですし、そもそもわたし自身が週2日出社+在宅勤務です。チームにJoinしてはじめの頃は、開発スタイルの違いにおおいに戸惑い、みんなの状況が見えないから慮ってしまって割り込みにくい → いやいや、いま言うべきだろ!と葛藤していました。

そこでこの状況を逆手に取って「見えないから割り込んでいいか!」と思うようにして、すぐに伝えることにしています。なので、忙しそうな気配のするHさんにも、すぐにその違和感を伝えます。大抵は(予想どおり)急がなくてもよいものですが、たまに思わぬ問題につながる糸口が見つかることがあります。

仕様どおりに動くけど、実際に使ってみたらやっぱり気に入らない場合もあります。わたしも仕様に口を出して揉めに揉めて「これでいこう」と決めたので、さすがにちょっと言いづらい。リリースまで時間もあるので、来週の開発ミーティングで話せばいいか....と頭の中のわたしがささやくのですが、出社している日は(やや重い腰を上げて)プロダクトマネージャーに話しに行きます。そして「やっぱりそう思いますよねぇ」となり、開発ミーティングを待たずに、次のアクションにつながることも少なくありません。

  • 思わぬ問題につながる
  • (何かを待たずに)次のアクションにつながる

このようなこともあるから「すぐに伝える」のは良いことだと信じてやっているのですが、こういった行動のひとつひとつが「開発自体の素早さ、スピード感」を醸し出しているのではないか、とも思います。

タイトルの「回答はぜんぜん急いでません!!!」は、すぐに伝えたいけど、すぐに回答が欲しいわけではないですよ(回答はあとでも大丈夫ですよ)を伝えるときに使うフレーズです。昨日もHさんに違和感を伝えるときに使いました。あのチームでは使わなかったフレーズです。*1

*1:じつは「回答はぜんぜん急いでません!!!」と伝えても、わりとすぐに回答をもらえてます。miwaの圧の可能性….

テスト実況について(おねがい) #miwaテスト実況

仕事中の「プロダクトを動かしながら試すことを動的に変化させ違和感を見つける行為」をオンライン(社内)で流しながら、ゆるーくやってみようと思っています。このブログを読んでくださっている多くの方はその様子を見ることはできず、たいへん心苦しいのですが、もし視聴できるとしたら、

  • なにを知りたいか(なぜ知りたいのか)
  • どんなことに注目したいか
  • 興味あること(Testing全般)

など、ぜひ教えていただきたいです。

たとえば「その操作をした理由が知りたい」なら、普段は黙ってテストしてますが*1、考えていることを呟きながら操作しようとなりますし、実況するときはまわりの人たちの迷惑にならないようにテレキューブに移動してやろうかな、と行動に変化がうまれます。その呟きの源泉(考えの元になったもの)に興味がある等、ぼやっとしたものでも嬉しいです。

いただいたご意見は本記事に追記しようと思っています。すでに同じようなご意見が出てる場合でも、どれくらいの方がそう思うのかがわかって嬉しいのでぜひ教えてください。そしてこの試みで得られたことを何らかのカタチでいつかみなさんにお伝えできたらいいなと思っています。

*1:@m_seki によると表情に変化があるとのこと。ひどいことしてるときは、ひどい顔をしているそうです。ひどい顔とは…

雇入時の健康診断(やらかし)

転職して1か月。雇い入れ時の健康診断を受けてきました。これは雇い主が労働者を雇い入れた際に労働安全衛生規則第43条で義務づけられているものです。これまでも年1回の定期健康診断と、半年ごとの特定業務従事者*1の健康診断を受けていて(これらも労働安全衛生規則第44条、第45条で義務づけられています)長年勤めていると健康診断も特別なことではなく「いつものあれ」になっていたのですが、今回は問診票の既往歴や家族歴がきれいになくなっていて、転職するとホントいろんなものが初期化されるのだなぁとあらためて思った次第です。

健診当日、地図を見ながら指定された施設を訪れ、受付を済ませ、更衣室に入ってびっくり。ここは高級ラウンジか!!!

  • 新しい施設とは聞いていたけど、さすが横浜!更衣室もおしゃれだな〜〜〜〜
  • 全体的に落ち着いた色調でラグジュアリー(これから健康診断とは思えない)
  • 間接照明とスポット照明で浮かびあがるソファが上質なのは座らなくてもわかるぞ
  • おっと、角にあるのは透明な冷蔵庫!いろんな飲み物が用意してある!
  • 検査が終わったら飲もうっと(前日21時から何も口にしてないので喉が渇いている)

ラウンジ奥にあるロッカールームで優雅(?)に着替えて、あたたかみのある木製ロッカーの扉を閉めました。


3時間後。すべての検査が終わって更衣室に戻ろうとしたのですが、半透明のガラスドアが開かない。あれ?と思ってドアに手のひらを近づけてみたけど開きません。

受付の女性を呼び「更衣室のドアが開かないんですけど?」と伝えたら

受付「ここはドック用のラウンジです!ていうか、どうやって入ったんですか!!!

みわ「ふ、ふつうに入ったんですけど……(回答になっていない)

受付(暗証番号でドアを開ける)「ドック用のラウンジですので、中のモノはさわらないでくださいね

みわ「はい……(高級ジュース、飲めないわ…

というやらかし(セキュリティインシデント)を発動しました。ごめんなさい。

資料:労働安全衛生法に基づく健康診断

 

*1:前職では「ラジウム放射線、エックス線その他有害放射線にさらされる業務」に従事していた

モノづくりは"良いものにしよう"という会話のキャッチボール

この記事は、システムのある機能(機能a)のふるまいを変更したときに「テストが足りないかも?」と思ったテスターが、実装者のプログラマーMさんと会話したときの記録です。一部ハイコンテクストで非常にわかりづらいので、まずはじめに会話の概要とこの記事で伝えたいことを書いておきます。

開発現場での会話が、miwaのシステムの内部設計の理解を助け、お客さまの現場での製品の使われ方をMさんが深く知るきっかけになった。miwaが知りたいと示した内容から、Mさんは自分が当たり前に知っていることを自認し、同時に相手(miwa)が知り得ないことに気づく。心配性のmiwaは気がかりをMさんに伝える。その心配はMさんに伝播し、Mさん自身の行動をすこし変えることになる。毎日の小さな会話のひとつひとつは、自分たちの開発やテストをあらためて見直す機会となり、それらがより良いものになるよう変化をうながし、わたしたちのモノづくりに地続きでつながっている。*1

2025.05.09(金) 16:32(トワイライトゾーン*2)

🥷miwa「Mさん、おつかれさまでーす。

Mさん「な、なにか見つけましたか?

🥷miwa「見つけてないです(笑)

🥷miwa「あのね、ちょっとご相談というか、Mさんたちが機能aで実装してくれたストーリーなんですけどね。

Mさん「あ!さっきチケットみました。miwaさんが試したこと書いてくれてますね。

隣にいるペアのプログラマーKさんも手を止めて会話に混ざってくる

🥷miwa「そうそう、それです。もう見てくれたんですね。ありがとうございます。試した範囲ではちゃんと動いてましたよ。素晴らしい!!

Mさん「よかったー。

🥷miwa「でね、自分で試したことがテスト(テストケース)に書いてあるのか気になっちゃって。調べた感じだとこの表のとおりなんですけどね。

試したこと テストが書いてある場所 備考
A 本チケット  
B 本チケット  
C チケット1000  
D    
E   レイアウト違いで2種類
F   Referenceの切り替えで3種類
G チケット2000  
H    

 

Mさん「はいはい。

🥷miwa「テストがないのもありますね。

Mさん「ありますね。

🥷miwa「Dはテストがないですけど、たとえば、Aを試すことで自然にDのふるまいもカバーできるから、わざと(意図的に)書いてないとかですか?

Mさん「そうですね。実装的には同じところを通ってます。

🥷miwa「なるほどー、そうなんですね。ほかのE、F、Hも同じですか?

Mさん「同じです。

🥷miwa「いちおう、ねんのためというかなんというか、今回の変更の元になったチケット(ふるまいを変更する前のストーリー)を見てみたんですけどね、(そのチケットを画面に表示しながら)こちらのテストはOLD-Test(今回ふるまいを変更したことでテストが通らなくなるので識別子を入れて管理している)になってますよね。

Mさん「そうですね。

🥷miwa「で、OLD-Testに書いてあるテストをおさらいしてみたんですが、ここに書いてあるテストのこれね(指で指し示す)これが今回のストーリーではなくなっちゃった感じがするんですよね。この表だとEにたいするテストになると思うんですけどね。

Mさん「たしかにー。

🥷miwa「でも実装として同じところを通ってるなら、Aのテストでカバーできるのもわかるんだよな……。

Mさん「あーー(Aのテストで)カバーできるのがわかるのは、自分が実装してるからかー。実装を知らない人は、なんでテストがこれだけでいいのかわからないですね。

🥷miwa「うん。わたしもいまMさんに教えてもらったからわかったけど、わからなかったです。とくにHなんかはAからするとだいぶ遠いというか、うーん、想像できないなぁ…。

Mさん「あれ、Hも同じはずだよね?(Kさんの顔を見ながら)あとでちょっとコードを確認しておきますね。

🥷miwa「ありがとうございます。

🥷miwa「あとね、これはわたしの個人的な心配なんですけど、今はこれで大丈夫だとして、これから設計や実装がどんどん変わっていくじゃないですか。

Mさん「ですねぇ。

🥷miwa「たとえば1年後に、Eのふるまいはどうなっているのが正しいんだっけ?ってなったときに、Aのふるまいから正解にたどりつくのは結構大変になるんじゃないかと思うんですよね。開発日記を順に読んでいけば、まぁわかるといえばわかるんだろうけど。*3

Mさん「たしかに。テストを書かないなら書かなくていい理由を残しておくとかしないと大変か。

🥷miwa「ですです。

🥷miwa「あとね、この先いつになるかわからないけど、機能aやその周辺に変更が入ったとして、うっかり直し忘れてEが置いてけぼりになったりしたら、AのテストだけだとEがおかしいことに気づきづらくなってしまいそうで……心配なんですよね。

Mさん「たしかに……。

🥷miwa「この機能aはわりとよく使うんですよ。だからなんとしても!どんな場面でも!頑丈にしておきたいんです。

Mさん「そういえば、似たようなやつで機能bがありますよね。機能bでも機能aと同じようなことができますが、機能aとのチガイがよくわかってないかも、、、

🥷miwa「するどい! たしかに機能aと機能bは似てますね。でも使われ方がちょっと違うんですよね。

臨床現場でお客さまはどんなときにどういう使い方をするのか、それぞれの機能の嬉しさはなにかを話しながら、機能aと機能bのチガイがわかるように実際にやってみせる

Mさん「なるほどーー、こういう使い方をするなら機能aのEのテストは追加しておいたほうがいいですね。

🥷miwa「わたしもそう思います。テストがないところ、もう一度みていきましょうか?

Mさん「はい!

MさんとKさんが、表を見ながらこれはテストを追加したほうがいいね、この切り替えできるタイプの3つは使い方の括りとしては同じだから、代表して1つ書いておけばいいかな……と話し合ってるのを頷きながら聞いているmiwa

2025.05.09(金) 16:51(ひととおり見直しが終わって)

🥷miwa「うんうん。いい感じです。よかったー、ありがとうございます!

Mさん「こちらこそ、ありがとうございました!

🥷miwa「あっ、テストを追加するのは来週でいいですよ。

Mさん、Kさん「はい、来週追加しますー

🥷miwa「ありがとうございます。楽しみにしてます〜〜

あわせて読みたい

 

*1:会話の中では「良いものにしよう」なんて言ってないところがポイントです

*2:トワイライトゾーン:あとで書く

*3:結構大変:このケースだと正解にたどり着くまで3分以上かかるなら大変、という肌感覚です

昨日の正解は今日の正解ではないかもしれない

ソフトウェアテストの小ネタ - Qiita Advent Calendar 2024 - Qiita 17日目の記事です。

 製品開発、特にテスト(checkingではなくtesting)*1で難しいのは、自分の中での正解を持つ一方で「自分は間違っているかもしれない」と疑わなくてはならないところです。これは、だから自分は間違っていない=正しい、を証明するために証拠を集めたり、製品や開発やテストに必要な、ありとあらゆる知識や技術を身につけましょう、という話ではなく、たとえ証拠を集めたとしても、たくさんの知識や技術を身につけたとしても、本当にそれが正解かはわからないぞ!という態度で臨まないと、テストなんてできないよね、という話です。

 みなさんお気づきのように、本当にそれが正解かはわからないのに、実際にテストするときには、なんらかの期待値や正解が必要になる、という矛盾があります*2。わたしはこの矛盾を受け入れるために、全力で導いた「なんらかの正解」を「これは今日の正解だぞ」と考えるようにしています。そして明日になったら「昨日の正解は今日の正解ではないかもしれない」と考え、あらたな気持ちで製品に向き合い、今日もまた全力でテストするのです。今日の正解って、昨日の正解の仮説と検証も受け継いでいるんですよね。わたしくらいになるとcheckingでも疑いますよ。Enjoy testing!

あわせて読みたい

arborosa.org

*1:多くの先達が『テストの定義』を語られています。わたしがこよなく愛するテストの定義は G.J. Myers[1979] の『テストとは、エラーをみつけるつもりでプログラムを実行する過程である。』です。この記事の「テスト」は「製品開発のすべての工程、期間において、まだ誰も気づいていない未知の問題をみつける行為、活動」をイメージして書きました。

*2:テストだけでなく、日々のすべての判断や選択、たとえば、外部仕様を決める、設計を見直して実装を書き直す、無数のテストから限られた時間でやるべきテストを厳選する…も同様です。

JaSST東北名物ワークショップを体験して思ったこと #jassttohoku

JaSSTソフトウェアテストシンポジウム-JaSST'24 Tohoku に参加しました*1。この記事では、そこで行われたワークショップ『クラシフィケーションツリー技法』を体験して思ったことをメモしておきます。技法自体の紹介やワークショップの詳しい内容については触れないので、参加した方にしかわからない部分が多々あると思います。

また、当日配布されたアンケート用紙に感想を書かずに提出してしまったので(へとへとで頭がまわりませんでした)実行委員のみなさんやこのシンポジウムがうまくいくように尽力された方へのフォードバックと感謝もお伝えできればと思います。

ワークショップを体験して思ったこと

クラシフィケーションツリー技法は言葉としては聞いたことがあるくらいで知りませんでした。書籍『ソフトウェアテスト技法ドリル』であれだけ勉強したのにどういうことだ?と思ったら第1版には書かれてなかったのでよかったのですが(そういうことではない)第2版 にはクラシフィケーションツリー技法が追加されています。*2

優しさにあふれていたワークショップ

ワークショップに参加する側の気持ちって、これからどんなことやるんだろう(やらせられるんだろう)と多少なりとも不安があるものです。JaSST東北のワークショップは導入フェーズがものすごく丁寧。どんな技法なのか、どのように使うのかをわかりやすく紹介してくれます。それを聞いていればチュートリアルが解けてしまうスタイルは、誰一人として置いていかない優しさにあふれていて、大好きです。

お題選定が秀逸 x ムーブメント爆誕

演習はシンプルでわかりやすいお題なのに、考え方や解き方にバリエーションがつけられるようになっていて(実行委員のみなさんの思惑通り?)あんなに短い時間でもちゃんと悩めたのがよかったです。自分の頭で考えないと身につかないんだよね。

今年は注目すべきムーブメントがありました。手を動かしながら問題を解いていくと「知っている → わかる」が体感できるので、うれしくなってしまうんですよね。それが表出して誰ともなく自然と拍手がわきあがってました。とても心地よかったです。

JaSST東北のワークショップは頭が疲れることでも有名ですが、ハマる人にはハマり、わたしのようなリピーターも一定数いますので、このよろこびの表明とみんながみんなを褒めたたえるムーブメントは、来年から定番になるかもしれませんね。

時間に制約がある中でどう対処していけばよいのか

時間に制約がある中でワークをやるので「もうすこし考えたいぞ」の気持ちが残るのは仕方のないことですが、他のグループの成果物を見せてもらいながらお話(どういう気持ちでこうしたのか、何を優先したのか、悩んだところはどこかなど)を聞いていたら「もうすこし考えたいぞ」が、うまく消化していく感じがしました。

時間に制約があるのは仕事でも同じなので、やりたいこと、やるべきことに、どう対処していくのか、どう折り合いをつけていくのかーーのようなテーマについても、なんらかの示唆を与えたのではないでしょうか。そういうテストのお悩み、わりと多かったよね。

シンポジウム全体としてまとまっていて流石です

話がそれてしまいましたが、成果物を見学するターンで各グループで説明する人を残したのは大正解だと思います。基調講演の「説明できるテスト」とも動的につながり、シンポジウム全体としてもきれいにまとまっていて流石だなあと思いました。井芹久美子さんによる基調講演『説明できるテストをつくるためにできることを考える』は、なにもかもが素晴らしすぎて雑に感想を書きたくないので今日は書きませんが、もしかしたらわたししか気がついてないかも!と思うのは「この講演自体が基調講演の内容を体現していた」ことです。この講演内容を参加者が理解できれば、行動してもらえる。そのレベルまでみんなを引き上げてくれるような内容になっていたと思いませんか?

自分の開発やテストに対する考え方の癖がダダ漏れ事案

最後のワーク、仕様変更(機能追加)の演習は個人的にめちゃくちゃ面白かったです。普段の製品開発ではほぼほぼこれしかないので、自分の開発やテストに対する考え方の癖(仕様書とコードは一致していないかもしれないし、仕様書だって間違っているかもしれないし、この仕様だって本当に良いものになっているのか?)があふれ出てしまい、同じグループのまこっちゃんさんとsaeさんの思考にバイアスをかけてしまったかもしれない…と、今になって反省しております。

正解は一つではない

ワークショップ全体をとおして何度も聞いた「正解は一つではない」という言葉も印象的でした。製品開発って単純な正解探しのようなものではないのでね、チーム全員の脳みそを使い、意見や知恵を出しあって、そのときの最善で最適な解を探し続ける旅のようなものかもしれないな、と帰りの新幹線の中でしみじみと考えてました。

次回は西暦2025年(仏暦2568年)5月30日(金)開催!

今回も大満足のワークショップでした。次回も参加したいです。講演者の井芹久美子さん、実行委員のみなさん、このシンポジウムがうまくいくように尽力されたすべての方々、それから参加者のみなさん、ありがとうございました!

あわせて読みたい

miwa719.hatenablog.com

 

*1:今年のJaSST東北は現地参加のみの開催でした

*2:第2版も持っているのに読んでないことがバレてしまった