CAT GETTING OUT OF A BAG

What the tester is thinking.

「思考を切り替えるのが大変」ではない理由を考えてみました

ソフトウェアテストシンポジウム2021北海道 の事例セッション『役割分担して行うペアテスト』を聴講しました。その中で「思考を切り替えるのが大変」というお話がありました。

たしかに「テスト(Testing)するときの思考」と「バグチケットをBTS*1に登録するときの思考」はちがいます。前者は未知の問題を探し出すために創造的で破壊的な思考、後者は起きたこと(事実)を整理して簡潔にわかりやすくまとめるといった論理的な思考の占める割合が高いのではないでしょうか。そう、脳みその使い方がちょっとちがうのです。

ところが、わたし自身はその二つの思考を切り替えるのが大変とは感じてません。これは面白いなーと思い、バグを見つけてから次のテストをはじめるまでのことと、なぜ大変と感じてないのかを考えてみました。以降、テスト(Testing)するときの思考を「テスト脳」と書きます。

バグを見つけたらプログラマーに見せる

わたしたちのチームはバグを見つけたらチケットを書く前にプログラマーに見せます。どんなことをしていたかを白状し 伝え、状況に応じてログファイルを見たり、もう一度バグを再現させたり、追加で試してみたいことがあれば一緒にテストします。この時点でバグに対する一時調査が終わっていることも少なくありません。
このときはまだテスト脳です。バグの種類や内容にもよりますが若干興奮している状態です。

チケットを登録する

プログラマーに伝えたらチケットを書きます。

  • タイトル
  • システムバージョン
  • 概要
  • 再現手順(わかれば)
  • 画面キャプチャ(あれば)
  • ログファイルの置き場所(あれば)


この段階で、はじめの読者(プログラマー)とある程度、認識合わせができているので「この表現で伝わるかな?」と思い悩むことがないのだと気づきました。
このときは余韻は残っているけどテスト脳ではありません。前の授業が体育(水泳)で身体が心地よいだるさに包まれている感じです。

余談ですが、チケットはほどほどに書いておけばよいことになってます。コーディングした時点ではうまく動くかわからないのと同じで、うまく伝わるかは自分以外の人に読んでもらわないとわかりません。チケットを読んだ誰かが、この書き方だとわかりづらいなとか、そういう意味だったのね(誤解した)とか、具体的な問題を検出した時点で書き直してます。 
この「ほどほどに書いておけばよい」というスタンスは、書き手に余計な時間(時間とはその人の時間ではなくチームの時間)を使わせないという考え方が働いているのだと思います。

テストを再開する

チケットの登録が終わり、テストを再開します。おそらくここで「思考を切り替えるのが大変」と感じるのだと思います。バグを見つける直前のテスト脳に持っていきたいのですよね。

わたしの場合は(もうひとりいるテスターも)バグを見つけたチケットについては、手をつけないことが多いです。プログラマーに見せたときに「もっとやってほしい」とリクエストがあればやりますが、そうでなければ、バグが直ってくるまでテストしません。
わたしたちは、別のチケットのテストを開始します。新しいテストのはじまりです。先ほどのチケットとは内容が異なるのでバグを見つける直前のテスト脳に戻さなくてもいいのです。そこが大きなちがいかなと思いました。チームで扱うチケットの大きさや、チケットの数も関係するのかもしれません。

バグに執着させない

わたしはバグを見つけると芋づる式にいろんなことを試したくなります。一番シンプルな再現手順を見つけるために、どこのなにがバグの引き金になったのかを知りたくなります。他の条件でも同じバグが発生するのかしないのか。確かめたいことが次から次へと出てきますが、それをさせてはもらえません。「バグを見つけたらすぐにプログラマーに見せる」というプラクティスが邪魔をする 防波堤になっています。バグを見つけても、伝わるまでは見つかってないのと同じなのです。プロの無職、曰く「テスターの満足より、いまチームとしてどうしてほしいかの方がだいじ」とのこと。*2

それはもう既知のバグなんだよ。あなたにはまだ誰も気づいていない未知の問題や課題を見つけてほしいんだ。

さいごに

わたしのテスト中における過集中は自他共に認めるところではありますが、それに加えて「思考を切り替えるのがめっちゃうまいのでは?」と思ったりもしたのですが、そうではなかったです。バグを見つける直前のテスト脳に戻す必要がなかったのでした。開発のやりかたのちがいである、と今日のところは結論づけたいと思います。

このようなシンポジウムに参加すると、自分たちが普段やっていることを、ちがう視点で見つめ直すきっかけをもらえたりします。知らないことがたくさんあるのだなぁとあらためて思いますし、気分転換にもなりますね。基調講演と招待講演もとてもよかったです。

*1:Bug Tracking System

*2:プロの無職 == @m_seki

ログイン機能(背景)を公開します

drive.google.com

iCARE Dev Meetup #22 にお呼ばれして登壇したときに、説明上「架空の機能」が必要になりまして、Clean Agile 基本に立ち戻れ (アスキードワンゴ) の 第3章 ビジネスプラクティス(受け入れ試験)に記載してあった「ログイン機能」を使いました。

もしユーザーが有効なユーザー名とパスワードを入力する

かつ「ログイン」をクリックする

ならばシステムは「ようこそ」ページを表示すること

この3行仕様から、どんなことを考えたのか、どんなことを試そうとするのか、大雑把に描いたものが こちらのマインドマップです。当日のスライドでは主に背景(笑)として使いました。*1

このブログをお読みのみなさんと一緒に「ログイン機能」を作ることになったとき、わたしはこんなことを気にしますよ、と伝えることができるかな(そしてすこしでも役に立てたらうれしい)と思い、公開することにしました。*2

*1:普段の開発ではこういうのは描かない。

*2:組み込み系なのでちょっとだいぶ癖があるかもしれない。

大人になってから知る、絵本のもうひとつの楽しみかた

 

Twitterでの会話がきっかけで、45年ぶりくらいに『ねえさんといもうと』を読み直しました。

ねえさんといもうと

ねえさんといもうと

 

やさしくて、ちょっぴりせつなくなる、なんともない日常の、ある日の姉妹のおはなし。願わくば、当時手にした福音館書店版(マーサ・アレキサンダーさん 絵、やがわすみこさん 訳)が欲しかったのだけど、現在は絶版となっていて新品は入手がむずかしいようです。あすなろ書房から2019年に刊行された酒井駒子さん版『ねえさんといもうと』は、もうため息がでてしまうくらい、とても良かった。繊細でやわらかで美しいタッチで描かれる姉妹が、絵本の中で動いているようでした。ふたりの表情の描写も細やかで、福音館書店版よりこころに伝わってくるものが多いと思います。

わたしは「ねえさん」

私には三つ年下の妹がいるのですが、おもしろいことに、当時と同じように「ねえさん」の立ち位置で読んでしまいます。いまとなっては「いもうと」の心情や行動も手にとるようにわかるのに、この絵本を読むときの私は、いつも「ねえさん」なのです。

本当は大好きなおはなしのくせに、読んでいる姿を誰にも(特に妹には)見られたくないという、不思議な絵本でした。だから、お部屋のすみっこか、二段ベッドの上段でこっそりと読んでいたのです。この、なんとも説明のつかないあの複雑な気持ちを、いまも再現できてしまうし、「あのときの複雑な気持ちはね……」と当時の私におしえてあげる、そんなことも可能なのです。45年前の自分と対話できるなんて、絵本はタイムマシンなんだわ!と思いました。

絵本のちから 

45年前、私は家族4人で川崎の団地で暮らしていました。8階のベランダから多摩川や、河川敷のグランドや、蒲田ー川崎間に架かる京浜東北線の鉄道橋を、いつも眺めていました。

目に浮かぶその風景は、フィルム写真のようにすこし色褪せています。懐古するときの脳が、無意識のうちに画像処理をほどこしてしまうのか。それとも、記憶が薄れるにしたがって、いくつかの色彩が抜け落ちてしまうのか。ううん、光化学スモッグのせいで大気が汚染され、目に映る景色が本当に色褪せていたのかもしれないな。(川崎市光化学スモッグについて調べたら、昭和45年度(1970年)の測定開始以来、大気中の濃度が一番高かったのが昭和49年度(1974年)という報告があり、まさにそのころの話です。)


絵本には深層意識に働きかける力がありそうです。ずっと忘れていたことを、思い出そうともしなかったことを、思い出させてくれる。忘れていたのは思い出ではなく、思い出をしまってある記憶領域の検索方法でした。絵本は索引に並んでいる用語のような役目を果たします。

団地の中に響く生活音。流れている空気。各階のおどり場の奥にある、吸い込まれそうな灰色のダストシュート。団地の広場でたまに見かけたポン菓子屋さんの軽トラック。ドカン!という破裂音と香ばしくて甘いにおい。

f:id:miwa719:20210501195857p:plain

河原町団地

お気に入りの絵本

昔のことを懐かしむ。そういうことができるお年頃(状況)になったのかもしれませんね。とにかく、あのころの私と、私のまわりにあったものに、もう一度会いたくなって、よく読んでいた絵本を12冊選びました。

  • 4月 ももいろのきりん
  • 5月 いやいやえん
  • 6月 ちいさいおうち
  • 7月 ロボット・カミイ
  • 8月 おしいれのぼうけん
  • 9月 ぐるんぱのようちえん
  • 10月 おおきなおおきな おいも
  • 11月 おおきなかぶ
  • 12月 てぶくろ
  • 1月 おだんごぱん
  • 2月 そらいろのたね
  • 3月 スイミー

f:id:miwa719:20210501200202p:plain

次点は『エルマーのぼうけん』

1970年代にもあった絵本のサブスク

私が通っていた幼稚園では月に一度、絵本がもらえる日がありました。先生から新しいすべすべの絵本を手渡され「どんなおはなしかなあ」と、わくわくしながら、帰りの園バスに乗りこみました。

ずいぶんあとになって、母から「あれは希望者が購入していたのよ」と教えてもらいました。福音館書店の『こどものとも』『かがくのとも』という月刊誌です。季節やこどもの成長にあわせたバラエティ豊かな絵本を選び、届けてくれる。1970年代もこんなサブスクがあったのです。絵本の多くは母が選んでくれたものと記憶していますが、今回選んだ12冊のうち9冊が福音館書店の絵本なのも、この月刊誌の影響を受けているのでしょう。

半世紀の時を超えて

買い直した絵本を母に見せたら、どんな顔をするのでしょうか。母もタイムマシンに乗り、二人の姉妹の子育てに奮闘していたころの自分や、ちいさくてかわいい(笑)私や妹に再会すると思います。そして、なにかを思い出し「そういえばね……」と話してくれそうな気がしてならないし、それを聞きたがっている私がいるのです。

 

note.com

 

しいばさんのこと

しいばさんに感じる「良いイメージ」は、いったいどこからくるのだろうと、前から思っていた。昨日おしゃべりしてわかった感じがする。いや、5年前にとちぎでお会いして、そのときからたぶんわかっていた。この感じを、忘れないうちに書き留めておこうと思う。

しいばさんは、より良い開発がしたくて、いろんな仕組みを取り入れながら、試行錯誤をくりかえし、チームや組織がいい感じになるようにサポートしている。また、アプリケーションアーキテクトとしても活躍している。

一緒に仕事したこともないし、しいばさんの職場を見学したわけでもないけど、ブログや講演スライドから伝わってくる「それ」から嫌な感じを受けないのは、なんでなんだろうと不思議に思っていたのだ。*1

良いイメージはどこから?

  • 周囲の人たちに気を配り、みんなが気持ちよく仕事ができるようにするには、どうしたらいいかなって、いつも考えてるところ。
  • じぶんの手柄にするみたいなの、まったく感じない(感じさせない)ところ。
  • かっこつけないところ。
  • どこかで見たようなフレーズではなく、自分の言葉で話してくれるところ。
  • むずかしい言葉を使わないところ。
  • 知ったかぶりをしないところ。
  • 人の話をそのまま聞いてくれるところ。
  • ほんとうに自分でやってるところ。(号令をかけるだけ、仕組みを用意するだけではない)
  • いつも穏やかそうなところ。
  • なんでもまず受け入れてくれそうなところ。
  • わからないことはわからないなーと言ってくれそうなところ。
  • 嘘がなさそうなところ。

わたしだって、周囲の人たちが嫌な気持ちにならないように言動には注意してる。たいていの場合はそのように行動できてると思う。しかし「前からそうなってます(だから直さなくていい)」などと言われると「なにーーー!!」(すべてのバグはだいたい前からそうなってるだろ!!!その論理が通るならすべてのバグは直さなくていいってことになるだろ!!そうじゃないだろ!!)という気持ちが溢れ出てしまう。言葉を発しなくても、まわりの人たちに伝わっていると思う。そういうダークな部分がしいばさんからは感じられない。はっ、もしかしたら単にこちらには見えてないだけなのかな。ということは、わたしももうすこし工夫すれば……と、考えてしまうあたりが、惜しいよね。

ラクティスありきではない

これはしいばさんご本人のことではなく、しいばさんがやってること、やろうとしていることについての感想。しいばさんの話は「プラクティスありきではない」と感じるから、気持ちいい。アジャイルアジャイルしてないし、スクラムスクラムしてないのがいい。しいばさんのブログを読むとアジャイルだしスクラムなので、なにを言ってるのか、わからないかもしれないが。

bufferings.hatenablog.com

普段やってることをブログにまとめたり、誰かに伝えるために、わざわざ書き起こそうとすると、どうしてもそういったプラクティス(名前)が前面に出てきてしまう。言葉にするとそうなってしまうのだ。*2

言葉としてのプラクティスは強すぎて、暴力的に感じることすらある。「うちも朝会やってますよ。同じですね!」とか。そうなんだけど、そうじゃないんだよな……同じではないと思うんだよ……と思っている。

「プラクティスありきではない」と感じるのは、どんなときも解決したいことに目が向いてるからだ。昨日聞いた話もまさにそうだった。「うちのチームも朝会をやってみよう。昨日何をやったか? 今日何をやるか? 困っていることは? を、ひとりずつまわして話してみよう」ではなく「開発で問題になる前の個人の気がかりを、なるべく早くみんなのものにしたいな。運用の問い合わせや調査の依頼、突発の対応もあるんだよ。チームとして今日1日をどう過ごすのかの計画を立てたいんだ。どうすればいいかな。エンジニアだけでなく、プロデューサーもいたほうがいいよね。それから……」これらの活動や仕掛けを全部ひっくるめて「朝会」とか「デイリースクラム」と呼んでいるだけに過ぎない。この違いは大きい。

おしゃべりのあと

うちのチームの @vestige_ が「しいばさんが眩しい」とツイートしていて、ほんとうにそうだなと思った。キラキラではないほうの眩しさを感じた。

使用したマイク

使用したマイクスタンド

テスト駆動開発

テスト駆動開発

  • 作者:Kent Beck
  • 発売日: 2017/10/14
  • メディア: 単行本(ソフトカバー)
Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち

Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち

  • 発売日: 2020/08/07
  • メディア: 単行本(ソフトカバー)
ソフトウェアテスト293の鉄則

ソフトウェアテスト293の鉄則

もしかして

druby.hatenablog.com

*1:会社員としてのわたしが「開発プロセス◯◯活動」や「なんとか推進ワーキンググループ」などに、これまであまり良いイメージを持ってこなかったのも影響していると思う。

*2:このへんは、ラムダノートの鹿野さん(編集者)のようなプロの手にかかれば、どうにかなるのかもしれない。

なにがうれしいんだっけ?

先日のテストラジオで「初めてやる機能のテストの話」を聴きながら、そのお題の「自動保存機能」で起きるかもしれない嫌なことを考えていたのですが、そもそもなんで自動保存したいのかな、それを解決できるようになっているのかな、と気になりました。

これは自動保存に関わらずどんな機能でも同じで、仕様どおりに作れたのか?というよりも、作ったことで何がどう変わるのか、何ができるようになったのかということです。要件からブレイクダウンして仕様どおりに作ったのに、まったく役に立たなかったら悲しいですよね。誰も幸せになりません。

◯◯したいの裏側には◯◯できない以外の課題や問題が潜んでいます。開発のはじめの頃はそれをちゃんと意識していたのに、設計や実装やテストといった具体的なフェーズに移ると、だんだんとそれがあたまのすみに追いやられ、結果的にズレていってしまう。わりとよくあるのではないでしょうか。それが悪いことだとは思ってません。きっとそうなりやすい性質があるんだろうな。

なにがうれしいんだっけ?

こんなとき、わたしたちのチームでは誰ともなく「(これを作ると)なにがうれしいんだっけ?」と問いかけます。それまで技術的で熱いディスカッションをしていたみんなの意識を、もともとの課題や問題に急速に戻すことのできる便利なフレーズです。

似たような言葉で『顧客にとっての価値』がありますが、そんな言葉を普段の会話の中で使うと「また難しいことを言いやがったな…」と身構えてしまう人もいるので(わたしです)気をつけてください。


自動保存の例ですと、こんな課題や問題が潜んでいるかもしれません。

  • 保存操作が面倒くさい
  • 入力中に別の用事で席を外して戻るとタイムアウトになって入力し直しになる
  • 入力項目がめちゃくちゃ多くて保存にいくまでが大変
  • 仮保存したい
  • うっかり保存しないで終わりにしてしまうことがある
  • 書いてる途中、ごく稀にだがアプリケーションがクラッシュする
  • 書いてる途中の履歴も取っておきたい
  • ほんとうは版管理したい

完璧な自動保存機能を作っても、解決しないものがありますね。

何があなたをソフトウェアテストに導いたのか

Christin Wiedemann さんの記事(Why Are You a Tester?)を読みました。

thinktesting.com

What brought them into software testing?

何があなたをソフトウェアテストに導いたのか?という問いに対する、わたしの回答です。

140文字におさまらなかった部分を補足して英文にしてみました。(Google翻訳そのまま!)

I am developing a medical device.  One day I embedded a bug that causes serious problems.  Fortunately I was able to find it before it hit the market, but what if it wasn't?  At that time, I was a programmer.  I wanted to know more about software testing. At this very moment I was led to software testing. More than 15 years ago,  I still remember how I felt when this bug was detected late in development.  I was very scared.  When developing software, it's deep in my heart.

日本語訳

私は医療機器を開発しています。ある日、私は深刻な問題を引き起こすバグを埋め込みました。幸い、市場に出る前に見つけることができましたが、そうでなかったらどうなったでしょうか? 当時、私はプログラマーでした。ソフトウェアテストについてもっと知りたいと思いました。私がソフトウェアテストに導かれた瞬間です。15年以上前のことですが、このバグが開発の終盤に見つかったときの気持ちを今でも覚えています。とても怖かった。ソフトウェアを開発するとき、それは私の心の奥底にあります。

Why Are You a Tester?

タイトルにもあるように "あなたがテスターである理由" も問われています。テストの何が面白いのか。テストの何があなたを惹きつけるのか。なぜそれほどまでに熱狂的になれるのか。

前にだれかに聞かれたような気がするな。(あとで書く)

データ移行で起きるかもしれない問題

毎週楽しみにしているテストラジオデータ移行後に見つかったバグの話を聴き、わたしも「データ移行で起きるかもしれない問題」を考えてみました。メモ帳に書き出したものをツイートしたのですが、さらにいくつか追加(編集)したので、それもあわせて載せておきます。

逆引きテスト

今回は「データ移行で起きるかもしれない問題」をお題にしましたが、普段の開発でも "起きるかもしれない嫌なこと" を起点にした「逆引きテスト*1」をしています。それが本当に起きるとしたら原因は何が考えられるだろう。何をどうすればそれが起きるのかを想像し、嫌なことが起きそうな状況を実際に作り、動かして試すのです。

幸運なことに "起きるかもしれない嫌なこと" はモノをつくる前から想像できます。これをできるだけ早いうちにチームのみんなに伝えておくのがポイントだと思います。プログラマーは大きな構造(アーキテクチャ)を念頭に設計や実装面からそれが起きる可能性を探り、嫌なことが起きないような仕組みを入れてくるはずです。テスターはわたしとは違ったアプローチで試してみたいことを考えはじめるでしょう。

起きたら嫌なことや不安なことは思いつくけれど、それを誘発しそうな”何か”がわからなくても伝えましょう。プログラマーは現実の世界でそれが起きないことを理詰めで教えてくれるかもしれません。プロの無職*2やテスターの脳内配線に刺激をあたえ、奇妙な"何か"を提起してくれるかもしれません*3。わたしたちのチームではよく見る風景です。

データ移行で起きるかもしれない問題

  • データ移行処理に時間がかかりすぎる。
  • 少ないデータ数ならすぐに終わるが、データ数が増えれば増えるほど指数関数的に処理時間がかかる。
  • データ移行処理がいつ終わるのかわからない。*4
  • データ移行処理を途中でキャンセルできない。
  • データ移行処理を途中でキャンセルしたあとのデータ移行処理がうまく動かない。
  • データ移行処理がちゃんと動いているのかフリーズしてるのか見た目にわからない。
  • データ移行処理を流して終わる頃に見に行ったらエラーで止まっていた。
  • エラーに関する情報が乏しく原因解明に時間がかかる。
  • データ移行処理中は(インタラクティブが頻繁に発生するので)その場から離れることができない。
  • データ移行処理中は(いつエラーが起きて止まるかわからないので)その場から離れることができない。
  • データ移行処理中にセキュリティ機能が動いて自動ログアウトしてしまった。
  • 全ての項目にデータをきっちりぜんぶ埋めたらバッファオーバーフローで止まる。
  • 食わせるデータは同じなのにうまく動くときと動かないときがある。(e.g. 競合状態は起きないという思い込み)
  • 食わせるデータは同じなのに実行する装置によって失敗する。
  • ストレージが足りなくて失敗する。
  • データ移行が途中で失敗したのでいったんデータを元に戻そうと思ったが戻らない。
  • データ移行中に他の機能は動かない(動いたとしても悪さをしない)という思い込み
  • データ移行プログラムは正常終了したがシステムが動かない。または特定の機能が動かない。
  • データ移行は仕様どおりにできたが本来やりたかったことができない。(お客さまが本当にやりたいことは何なのでしょう?)
  • データ移行後、新しいデータと一緒に使うと動かない。または特定の機能が動かない。
  • データ移行後、システムが動くことは動くが全体的に遅い。または特定の機能だけ遅い。移行前のパフォーマンスがでない。
  • データ移行直後は動いたのに、翌日になったら動かなくなった。システムを再起動したら動かなくなった。
  • データ移行したらオプション機能が使えるようになってしまった。(使えなくなることは気づきやすいが、使えるようになるのは気づきにくい)
  • データ移行処理の際に生成した中間ファイルが残っている。
  • データ移行処理の際に(意識的か無意識かはわからないが)生成したログやファイルがリソースを圧迫。いつかシステムが動かなくなるが原因解明に時間がかかる。(1週間前に動かしたデータ移行処理のせいだとは誰も思わない)
  • 保護しないとならないデータ(個人情報など)がログやファイルに残っている。
  • これではまずいと削除するようにしたがゴミ箱に残っている。
  • 合否を判定するために処理結果を出力するようにしたが、大量に出すぎてまともに確認できない。
  • 上記、処理結果の出力自体を間違える。当然合否判定も間違える。
  • ある特定の項目の移行処理だけすっぽり抜ける。
  • 最後の文字が欠落する。(最大文字数を入れて確認しないと気づけない)
  • 奇数バイトだとおかしくなる。
  • 制御コードが入っているとおかしくなる。
  • 特定の文字が入っているとおかしくなる。文字化けする。途中で欠落する。
  • 同じデータを入れてテストしたので移行先が間違っている問題に気づけない。(e.g. 固定電話No.に"0123456789"、携帯電話No.に"0123456789"を入れてテストする)
  • ソースコードをコピぺしたあとに修正ミスが起きる。(e.g. PhoneNumber01、PhoneNumber02のような項目名)
  • データが改変されている。
  • 現行データの一部を上書きした。
  • 現行データが消えた。
  • 意図せずに整形してしまう。(e.g. データ移行処理を実行した装置(OS)の日付や通貨の表示形式などに引きづられる)
  • 先頭と末尾のスペースを勝手に削る。
  • 末尾に不要なスペースを埋める。
  • 処理の途中で数値型変換がはいり微妙なズレが生じる。
  • データ登録日時を登録すべき項目にデータ移行日時が(意図せず)登録される。(e.g. データを追加した日時が自動的に設定されるようになっている)
  • 移行元に無いデータは移行できない。
  • 移行前と移行後でデータ数が異なる。少ない。多い。
  • 重複したデータが登録される。移行元データにばかり注目していて現行データを気にしてなかった。
  • エラー時のリトライ処理で同じデータが複数登録される。
  • テストデータも一緒に登録してしまう。
  • 移行前と移行後でデータ数は同じなのに、移行前だと表示しないデータが表示される。(e.g. 論理削除データ)
  • 制約に引っかかり移行できない。データそのものに問題があるのかもしれないし、移行順の問題かもしれない。
  • 画面に表示されないデータ(内部的に使うデータ)が移行できてないことに気づけない。
  • データ移行テスト用のデータが作れない。
  • テスト用のデータを作るのに時間がかかるのに十分な時間を取っていない。
  • ずっと同じテストデータを使っている。(途中で入った機能追加や変更にハマるようなテストになっていない)
  • データ移行中に日を跨いだら止まった。移行テストは定時時間(9時〜18時)しかやってないから気づけない。
  • データ移行中に停電が起きた。
  • データ移行テストのために本物のデータを使ったら(こわくて書けない…)

厄介な問題

本番環境で本当に起きてしまう問題の多くは、ここにあげた問題以外で起きます。厄介ですね。問題はいつだってわたしたちの目の行き届かないところに潜んでいます。だから「他にもあるかもしれない」「きっとあるはずだ」と探し続ける必要があります。そうです。わたしごときがすこし考えたくらいで簡単に思いつくはずがないのです。本記事も不定期に追加(編集)することになるでしょう。

*1:わたしがそう呼んでるだけでJSTQBの用語だと「エラー推測」が近いかな。開発やテストに関わる多くのエンジニアが同じようなことを(意識せずに)やられていると思います。

*2:@m_seki

*3:誰かの不安や心配ごとが引き金となり全く別の課題や問題が見つかることがあります。ここにあげた問題のいくつかは他の機能開発(e.g. インストーラアンインストーラ開発)でも起きそうです。

*4:https://twitter.com/akiyama924/status/1359773775772852225