これまでのお話
この物語の設定については一昨年のAdventCalendarをお読みください。
あれから“RINA”と“まりまり”は、どのくらい成長したのでしょうか。
それではさっそく、二人の様子をのぞいてみましょう。
シーン1. （わたし転職します！）12:25
まりまり「RINA先輩！ まりまり、もう、おなかいっぱいです！！！！！」
(；´・`)=3
ここは、天神の地鶏居酒屋『おも屋』のカウンター席。
午前中のミーティングが早く終わった関係で、いつもは混んでいて入れない人気店に、フライング気味に二人はやってきた。
狙いは『炙り親子丼ランチ』である。濃厚でコクがある“若宮の地黄卵”と備長炭で炙った“宮崎県産の刀根どり”を使用した親子丼は、あつあつ・ふわとろで絶品なのである。
ベタベタした甘いタレではないものの、丼物は味が単調になりがちである。サラダとキムチで舌をリセットしつつ、食べ進めること10分。気がつけばあと少し。
ラストスパートに向けて山椒（おも屋では七味や一味ではなく粉山椒が付いてくる）をパラパラ振りながらRINAはつぶやく。
RINA「サイドオーダーに唐揚げも頼めばよかったかしら？」
まりまり「いやいやいやいや。🙌先輩、それは食べすぎです。」
RINA「あれ？ まりまり、どうしたの？ 食欲なくない？」
まりまり「なくないことはないんですが、、、。」
RINA「なくなくないですが？？」
まりまり「先輩！ 実は、わたし来月転職します！！！」(๑•̀ㅁ•́ฅ✧
※ まりまりは、座っていたカウンターチェアーをガバっとRINAに向け、真剣な顔でそう告げた。
RINA「えっえっ。待ってまって。話についていけない。」Σ(ﾟ◇ﾟﾉ)ﾉ
まりまり「テストはとても面白い仕事だと思うのですが、『作るところに直接役立ちたい』という気持ちがムクムクと。」
RINA「湧いてきたってわけか。」o(｀・_・´)o ウン！
まりまり「はい。すみません。私自身がバリバリと設計してプログラミングしたいわけではないのですが、“作り手（開発チーム）の思いとユーザー（お客様）の気持ちをつなぐ仕事”をしたくって。ごめんなさい。こんなによくしてもらってるのに。」
※ 『それは自分が作るよりも大変な仕事となるだろうなあ。』とRINAは思ったが、口にはしなかった。『まりまりなら、苦労はしてもきっとなれるよ。』と思ったからだ。
RINA「謝らなくっていいよー。実は私もなんだ。」
まりまり「えっえっ。待ってまって。話についていけない。」( ﾟ ▽ ﾟ ;)ｴｯ!!
RINA「こらこら。」( 艸｀*)
※ RINAは、口に入れた三つ葉をプッっと噴き出しそうになる。
まりまり「先輩もデザイナー志望だったんですか？」
RINA「ちゃうちゃう。私はテストガール。テストが好きよ。」
まりまり「ですよね。それではいずこに。」
RINA「今の会社を辞めて在宅勤務にしようかなと思って。あ。もう12:40だわ。オフィスに戻らなくっちゃ。」
まりまり「今日の夜、ラーメン食べに行きません？」🍜
RINA「いいね。リナは美味しいラーメンが食べたいです！」
シーン2. （竹乃家）19:10
まりまり「“たけのいえ”って長浜ラーメンじゃないんですね。太麺だし。
アッ、あそこに“昔なつかしの味 支那そば”って書いてあるわ。“昔なつかしの味”って言ったって、平成生まれに昭和21年の話を書かれてもねえ。朝ドラの“まんぷく”でしか見たこと無いわ！！」
※ まりまりは、いつも観察眼が鋭い。一分一秒も無駄にしない生き方のようだ。
RINA「私ねー。実はとんこつラーメン、そんなに好きじゃないんだよね。」
まりまり「えっ？ でも、この間、東京から来た人を“一双”に案内していましたが……。」
RINA「そりゃ、博多にいらして、『博多ラーメンが食べたい』って言ってる人を『肉肉うどん』に連れて行くわけにはいかないじゃない。」
まりまり「そりゃそうか。」
RINA「リナも気遣いするのだ。」(୨୧•͈ᴗ•͈)
まりまり「はい。知っています。」
RINA・まりまり同時に 「ところで！」
まりまり「どうぞ。先輩から。」
RINA「じゃあ。ズバッと聞くけど、どちらに転職するの？」
まりまり「A社です。」🏢
RINA「A社って、、、東京の、、、有名な、あのA社！？」
まりまり「はい。先輩は？」
RINA「私はB社よ。」
まりまり「B社も東京じゃないですか！？ 東京でまたキャッキャ・ウフフできますね！！！」
RINA「それはできないわ。だって、私はリモートオフィス、つまり、会社は東京にあるけど、今の福岡のおうちで働くから。」
まりまり「へー。すごーい！ 自宅にネットを引いて仕事するなんて、近未来的ですね！！！！！ そういうの『ハタラキカタ改革』っていうんでしたっけ？」
RINA「うーん。どうなんだろう？ 私は電車通勤がなくなるのがうれしいかな。」
まりまり「先輩は乗り物に弱かったですものね。｣
RINA「そうなのよー。自宅の方が集中して効率よくテストできると思うの。それに、いつでもおやつ食べられるしね。えへへ。」
シーン3. （RINAのおうち）16:00
RINAがリモートワークを始めてから3ヶ月が経った。お気に入りの壁紙に囲まれ、ウッドブラインドから柔らかな蜜柑色の夕日が差し込んでくる午後4時のこと。
RINAお気に入りのウォールナットの一枚板の机の上には24インチのPCモニターが2台並んでいる。いわゆるデュアルモニターである。近ごろ、RINAは、「ウェブのテストをするなら絶対にデュアルモニターよっ！ 24インチが2つで48インチよ！（※）」と言うが、実はちょっと前まではデュアルモニターが苦手だったらしい。
※ ディスプレイの大きさは対角線の長さなので、24インチの横並べデュアルは43インチと呼ぶべきであろう。
PCモニターの壁紙はRINA自身が撮った娘の写真が1分おきに切り替わるようになっている。仕事に疲れたときに見る娘の笑顔は大いなる癒しになるからだ。でも、良いことばかりではない。（何百枚もの写真がランダムで切り替わるため）『次はどの写真かなー？』と、ついつい仕事を忘れて見続けてしまうところが難点である。ときにはデュアルモニターの片方がフォトフレームと化してしまうことさえあるのだ。
気分転換しようとRINAはスマートスピーカーに話しかける。
RINA「OK Google、レキシの曲をかけて。」
Google Home「ジャズ100ネンの、歴史を、サイセイ、します。」
『そうじゃないだろー』、『“きらきら武士”流せ〜。』
スマートスピーカーがイマイチ期待に応えてくれない程度にはリモートワークに不便を感じることもあるけれど、RINAは、この新しい生活パターンが結構気に入っている。
送別会のときに、「みんなの目がなかったら、私なら怠けちゃう。」っていう後輩もいたけど、“会社でも怠ける人は怠けていたし、勤勉な人は誰も居ない早朝でも働いていたっけ……”とRINAは思う。要するに『時間給（Pay for time）』から『成果給（Pay for performance）』に変わっただけ。だらだらと働こうが、チャッチャと働こうが関係ないのである。
RINAはこの3ヶ月で、自然と『生産性良く働いて、早く家族との時間を取りたい』と思うようになっていた。
『リモートワーク、私に合ってる！』とRINAは思った。
ただ、仕事の効率とは全く別に、人寂しい気持ちになることもある。いつもおしゃべりしていた、まりまりがいないからだ。
「ああ、そうだ。」
RINAは思った。
「まりまりは、ここにはいない。否。天神にすらいないのである。」
「たそがれてんなよ！」と、
あさこ先輩の声が聞こえた気がした。
12月の夕空に、あさこ先輩の笑顔が大きく浮かんで見えた。
※注 あさこ先輩は生きています。
シーン4. （探索的テスト？）10:00
リモートワークを始めるようになってから、「口頭ではなく文書でテストの仕方を後輩のヨシタケ君に指導してほしい。」と言われるようになった。
これまでRINAは、数え切れないほどのテストを実施してきたが、テスト仕様書はほとんど書いてこなかった。それでも重要なバグはテストで見逃していないに違いないとRINAは思っている。
（こうみえてRINAはリリース後に、『見逃したバグはないだろうか？』と、しっかりと振り返りをおこなっていたからである。）
次から次へと『これをテストしてほしい』と仕事が舞い込んで来るのでテスト仕様書を書く時間が取れなかったというのも本当のことだが、『明日テストすることを書いて、それを読みながら書いた本人がテストする』ことに何の意味があるのか？ •́ε•̀٥
と、疑問だったからである。ダニエル・カーネマンも、“人はできるだけ損失を回避したいという心理状態をもつ傾向にある”と言ったらしい。
でも、後輩や社外コミュニティのテスト勉強会でテスト技法を教えるときに、
テスト技法を使って、テスト設計を行い、テストケースを作ります。
テストケースには、入力値、実行事前条件、期待結果、そして、実行事後条件を書いてください。特に【入力】と【期待結果】は大切です。
と説明している手前、『言ってることとやっていることが違う』という引け目も感じていた。それでも、『言行不一致だけど、私の環境ではこの方法がベスト』とRINAは信じている。
というのは、以前、東京のテストシンポジウムに参加したときに、“探索的テスト”という『テストのエキスパートのみに実施することが許された奥義』があると聞いていたからだ。探索的テストでは、テスト仕様書を書くことはないという。さらに、どうやら、探索的テストは、Agileでも採用されている“イケてる方法”らしい。
それ以降、RINAは、『私は、テストケースを書いていないのではなく、リナ風探索的テストを実施しているのだ。』と思うことにした。実際にシンポジウムで聞いたやり方はRINAのやり方にそっくりだったのだ。
そこで、RINAは後輩に向けて、テスト仕様書を書くのではなく、自分がいつもおこなっていることを書き出してみることにした。
RINA「ええと。まずは、テスト対象の『出来』の感触をつかむため、本格的にテストを始める前に、ブラウザを起動するところから最後まで、一通りさわってどんなことができるのか、ざっと確認するわね。
そのときにバグがみつかっちゃうこともあるけど、そういうときは“ちゃんと作ってから持って来い！”って叩き返したくなるよね。あまりにバグが見つかるようならテストをやめて、仕切りなおすこともあるわ。」
※ リモートワークを始めてからひとり言が増えたRINAである。
RINA「次に画面ごとにテストするよね。特に［戻る］ボタンは“画面の飛び越し”や“入力した値が保存されるべきかクリアされるべきか”に着目して色々なパターンを丁寧にテストするわ。それから、ブラウザのウィンドウサイズを変えてみたり、タブで入力位置が正しく移動するか、入力後［Enter］キーを押したらボタンを押したことになるかとか、システムフォントや画面解像度を変えてレイアウト崩れが起こらないかどうかも見るよね？ うん、見るみる！」
RINA「そうそう。データベースに文字列を渡していそうなテキスト入力フィールドに対しては、データベースを操作する“SQL文”が入力されても大丈夫かどうか……セキュリティ対策が取られているかどうか……もテストしているわ。新人さんが作ったページは特に念入りにね。」
RINA「最後はエラー処理の確認。入力対象外の文字である絵文字やコントロールコードやタブをCopy＆Pasteで入力してみたり。そうそう、何も入力せずに次の画面に進むのもよくバグるポイントよね。それからそれから。気になるところは全部ガンガンにテストするなあ。」
RINA「えーっと。でも、これって本当に探索的テストっていうんだっけ？ 後輩には正しい知識を伝えたいなあ。」
※ 水出しコーヒーを淹れて一休みだ。☕️
シーン5. （探索的テストの学習）13:00
不安になったRINAは探索的テストについて勉強してみることにした。
手始めに、JSTQBの用語集を読んでみた。RINAは、ソフトウェアテストについて疑問に思うことがあれば、JSTQBのシラバスや用語集を調べることにしている。
探索的テスト（exploratory testing）： 非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。[After Bach]
（出典： ソフトウェアテスト標準用語集 日本語版 Version 2.3.J02）
『テスト実施情報を活用しながらテスト設計をコントロール』って具体的にどうすることなんだろう？ 私がやっているテストと、どう違うんだろう？ これだけじゃわからないやとRINAは思った。
そこで、昔のツテで、YUMO先輩にSlackで聞いてみたところ、秒で返信が届いた。「高橋寿一さんの資料が良いのでは？」という・・・よし。読んでみるか。
（YUMO先輩は、旧職場のRINAの先輩で、職歴20年のベテランテストエンジニアである）
RINA「なになに、Googleでは毎日65,000回のビルド、だ・と・・・。そして、コード変更ごとに自動テストが行われる、、、と。凄い会社だなあ。」
※ RINAは、“2010年にはすでに、そんなことまで実現されていたのか”と驚いた。でも、今は“探索的テスト”の勉強が先である。テスト自動化も気になるが、今は読み飛ばそう。
RINA「『クラウド・アジャイルの新しいテストには、“早い”、“安い”、“そこそこの品質”が求められ、そのためには軽い“探索的テスト”が最適』。
そうそう。これよ、これ。私が求めていた情報はこれなのよ。さすがYUMO先輩！ ところで、やり方は？？」
※ RINAは夢中になってスライドの先を追った。
RINA「探索テストのやり方は、、、『① ソフトウェアを理解する、② テスト設計を行う、③ テストケースを実行する。この3つを同時に行う』・・・。
えっ。えー。これだけ？？？
これってリナの『① どんなことができるのか、ざっと確認する、② 気になるところは全部ガンガンにテストする。』と同じくらい雑な説明じゃない！？」
※ 資料に失望し、YUMO先輩を恨んだRINAであったが、高橋氏の資料は、まだ始めの15ページを読んだところだ。『57ページもあるのだから、この先に、きっと良いことが書いてあるはず。』と、気を取り直してRINAはスライドを読み進めた。
RINA「『一つ一つの細かいテストケースは書かない!』のか、粗い何かは書くのかな？
『テストケースを書く暇があったら実際にテストしようぜ！』、、、うん賛成。
仕様書を読み込めってよく聞くけど、現物を触った方がテストしなくちゃならないことがいくつも思い浮かぶし。やってみるとバグ見つかるし。
はっ。これが、“テスト設計とテスト実行を同時に行う”ってことなのかな。でもこんなこと普通だよね。」
24ページを開いたところで、RINAの手が止まった。
テストプロセス
- 製品の目的を明確にする(Identify the purpose of the product)
- 機能を明確にする(Identify functions)
- 弱いエリアを叩く(Identify areas of potential instability.)
- テスト実行及びバグを記録(Test each function and record problems.)
- 上記を継続的に実行する(Design and record a consistency verification test.)
RINA「ふぅ。探索的テストにもテストプロセスがあるのか。」
※ 高橋氏の資料は12ページを割いて探索的テストのテストプロセスについて説明している。特に“機能を明確にする”と、“弱いエリアを叩く”に力を入れて説明している。
RINA「高橋さんはこの2つを伝えたかったのかも。
高橋さんの言う、『製品がどういった機能を有しているかを知り、重要な機能を理解すること』は、リナの“① どんなことができるのか、ざっと確認する”に対応しそう。
そして、『弱いエリアを叩く』方はきっと“② 気になるところは全部ガンガンにテストする”のと同じだわ。」
RINA「でも、待ってまって。35ページの《タスクシート》って何？」
| 項目 | 説明 |
|---|---|
| タスクの記述(Task Description) | なにをやろうとしているのかを記述 |
| 探索アプローチガイド(Heuristics) | このガイドラインなり、アイディアが探索的テストをどのように進めていくかを記述する。 |
| 結果(Results) | どういう品質のものがリリース可能か。 |
| You can say you’re done when | どのように終わらせる |
| FAQ |
※ 表の2項目め、“探索アプローチガイド(Heuristics)”の説明は上記に加え「やるべきタスクを羅列するのではなく、どういう考え方でテストするかを記述する。例えば動詞を全部羅列するとかもアイディアです。」と書かれていた。
RINA「これは作っていなかったなあ。今度試してみよう。」
シーン6. （後輩と）14:00
RINA「よしぺん、タスクシート、メールしたよー。」
※ “よしぺん”とは、RINAの新しい会社の後輩で、リモートワークをしているRINAとZoomなどでTV会議をしながら業務を進めているモチベーションが高く有能な新人のヨシタケくん（シーン4で名前だけ登場）のことである。
よしぺん「はい。届きました。ありがとうございます。これまでは、『［戻る］ボタンは色々なパターンを丁寧に。』とか『ブラウザのウィンドウサイズを変えてみた？』とかZoomで言われて、そのたびに何でそうするのか分からず、ただただロボットのように操作しただけで、バグがほとんどみつからなかったんだけど、このシート凄いです。もちろん、RINAさんのようにはできないんだけれど、どういう結果を得るために何をしているのか、どこまでやれば良いのかが分かるのでバグが見つかるし、テストが上達した気がします。」
RINA「えー。前だって、『意味わかんない』って質問してくれたら、いくらでも答えたのに。」
よしぺん「大先輩にそんなことできませんって。こっそり勉強して、『いつかはRINAさんみたいなテスターになるんだ』と思うのが精一杯です。」
RINA「えっ。私って、そんな怖い？」
よしぺん「怖いというのとは違います。コウテイペンギンの雄はブリザードに晒されながらも、何も食べないで、足の上に卵を置いて暖め、そして生まれた雛を守り続ける忍耐力を持っているのです。」🐧
RINA「ごめん。その喩え、わかんないや。」
おしまい。
長文、お読みくださってありがとうございます。
もしも、この物語を、少しでも気に入っていただけましたなら、昨年のAdventCalendar 続 テストガールRINA（指教編）も読んでいただけるとうれしいです。