yoshitake_1201’s diary

テストのこととか、ペンギンのこととか書きます。

「ソフトウェアテストをカイゼンするいくつかのアイデア」を聴いて思ったこと #jassttokyo #50QuickideasTests

jasst.jp

2024/3/14(木)と2024/3/15(金)にあったJaSST'24 Tokyoに現地で参加して、その中のセッションの1つ、 「ソフトウェアテストカイゼンするいくつかのアイデア」を聴講して、講演中に思い浮かんだことやその後考えたことがあったので、せっかくなのでそれぞれ書くことにしました。

※ 講演の様子を細かく書いたレポート的なものではないです
※ 自分について
 ・Web系システムの受託開発会社のテストチームのリーダー
 ・システムを動かしてテストする
 ・たまーにE2Eの自動テストを作ったりもする
 ・システムのジャンルや規模は様々
  ・HP/ECサイト/転職サイト/大学の研究室用のなどなど
 ・継続して追加開発しているシステムもある

講演資料

speakerdeck.com

「時間経過を待つのではなく、イベントを待とう」

講演では「Loadingアイコンが出るまで待ってます、ならwaitやsleepじゃなくてそう書いたほうが良いよ」という話があり、自分もその通りだなぁと思った。 だけどそう思う一方で、自分はこのコードを書くことがまだある。 自動テストに関連するイベント(システムテスト自動化カンファレンス/ソフトウェアテスト自動化カンファレンス)や 自動テストに携わる多くの方のブログでもこれは言われているし、おそらく自動テストの「キホンのキ」的なものなんだろうなぁと思う。

でも自分がいざ自動テストを書く場面になると、自分の「とりあえずすぐ書けるレベルのコード」がwaitだったりsleepだったりなので、 一旦そう書いて「他のコードが自分の想像通り動いているかな?」って試して問題がなかったら、その後にwaitやsleepの部分をそう書かなくて良いように作り直している。

「とりあえずすぐ書ける」っていうのは「コードが動かなかったときに、疑う優先度が低い部分」という感じかなぁ。 自分の場合は、講演中に鉄平さんが言われていた「ある要素が表示されるまで待つなら、そういう風に書けば良い」というケースがほとんどなので、本当とてもごもっとも。 この辺りまだまだ力が足りない部分だなぁ。

「テストを作業項目に沿ってグループ化したり構成したりすることを避けよう」

講演中も質問もあったけど、説明が難しそうなアイデアだったなぁと感じた。

自分は、このアイデアの説明や質問を聴きながら「操作が同じだからといって、目的の違う複数のテストを、1つの操作でまとめてやるのは避けよう」ってことかなぁと思った。 「1つの操作であれもこれもそれも確認してはだめだよ」みたいな感じ。 テストという仕事をやり始めた初期の頃(6 ~ 7年前ぐらい)は、「効率よくテスト実行を終わらせるにはどうしたら?」っていうのをよく考えていた。 極端に言うと「このケース、手間が多い(同じ操作を何回もやらないといけない)から非効率だ」みたいなw

いつからかは忘れたけど、今はこういった考えはしなくなった *1
この「1つの操作であれもこれも」みたいなやり方は「テストして不具合を見つけたり問題ないって確認することが目的」ではなく「テストを終わらせることが目的」になっているんだと思う。 テストやテストケースを終わらせることは、普段のお仕事では求めてないので、このやり方はやってない。

あと、このやり方はテストがうまい人ほどやってて負担が大きくなるんだろうなぁって思う。 例えば、「1つの操作で4つの別々の事柄を確認しないといけない」のと「『1つの操作で1つの事柄を確認する』が4つある」だと、「一度に気にしないといけない最低限のこと」は後者のほうが少ないので、後者のほうが良い。 自分の身近にいるテストがうまい人は「気にしないといけないこと」はもちろんテストするけど、テストを始めると、テストケースには存在しないことをどんどんテストしていってくれる。 テストを始める前に気になってたこともテストしてるだろうけど、テスト中にシステムを動かしてみてから「さらに気になること」ができる。 そして「さらに気になること」をやると、「さらにさらに気になること」ができる、という感じなんだろうと思う。 こうしてテスト中に気になることが増えていくので、「一度に気にしないといけない最低限のこと」が多いと、気にすることの数が爆発してしまうので、しんどくなるんだろうなぁと思う。

ということもあって、自分はなるべく「テストの目的」ごとにテストケースを考えるようにしてるんだけど、 「あ、これとこれ一緒に確認したほうが良いかも」って思って、複数の目的がくっついたテストケースを作ることがたまにある *2 *3

だいぶ元のアイデアから逸れてしまった。
本に書いてある内容とはたぶん違う気がするので、ブログを書き終わったら改めてアイデアを読んでみる*4

「テストコードは書くためではなく読むために最適化しよう」

講演中、「例えば、自動テストで検索のテストを書いてるんだったら『〇〇をクリックする』じゃなくて『検索する』って書こうよ」的な話があったんだけど、自動テストだけじゃなくて手動テストでもそういう場面あるなぁと思った。 あと、手動テストの話だけど、自分は『〇〇をクリックする』って書くときも『検索する』って書くときも両方あるなぁと。

「〇〇をクリックする」って書くときは、検索のテストの中で詳細なステップを書きたいときとかで、例えば以下の感じかなぁ。

 ・検索のテスト
  1. 〇〇ページを開く
  2. □□にXXと入力する
  3. ◯◯をクリックする

講演で出てた検索を例にしたけど、検索のときはここまで細かくは書かないかもしれない。 検索を実行する方法が複数あったら(たとえば、検索ボタンだけでなくEnterでも検索できるとかなら)書くとは思うけど、いずれにせよ状況次第な気がする。

具体的に書きたいときは、どちらかというとテスト手順が難しいときかなぁ。 「外部連携しているシステムを使わないといけないから、操作手順をいつもより細かく具体的に書いておこう」というときとかはかなり具体的に書いてることが多い。 テストと言うよりはマニュアルに近いかもしれない。 未来の自分たちに向けて、例えばこの先追加開発などがあってもう一度この操作をするときとかに思い出せるように、と思って具体的に書くことがある。

あと、講演では自動テストの話が主だったけど、自動テストの場合はより読みやすさが大事なのかなぁとも思った。 このテストは、「検索機能」をテストしたいのか、それとも「〇〇をクリックする」というテストをしたいのか。 この場合「〇〇をクリックする」は検索を実現する1つの手段のように見えるから、「検索する」って書いてあるほうがテストしたいことがわかって良いなぁと思った。

「自動テストは頻繁に実行し、割れ窓はすぐ塞ごう」

これも自動テストだけでなく手動テストもそうだなぁと思う。 自動テストと手動テストだと起きる事柄が変わってくる気はするけど。 でもどちらにせよ、窓を塞ぎやすいような状態にしておくのがコツかも、と思った。 修正する習慣をつけることで、と資料に書いてあるけど、面倒くさがりな自分からすると、こういうのは習慣にするまでが結構大変。 だから「修正しやすいようにするにはどうしたら?」とか「修正したくなるようになるにはどうすれば?」っていうのをよく考えている *5

手動テストの話になるけど、テスト中にテストケースを書き換えれるようにしたりとか、テストケースをマスターからコピーして使うというタイプのテストケースには、マスターへのリンクを張っておくとか。 地味だけどそういうちょっとしたことをやっておくと、すぐに修正しやすくなる。 あとこういうときは、チームメンバーがすぐ修正してくれるというのがとてもありがたい。 「自分じゃなくてチームメンバーがやってくれる」というわけではなくて「チームメンバーがやってるし自分もやらないとな」という動機が生まれるのでやりたくなる *6

おわり

講演で紹介されたアイデアは11個あったんだけど、さすがに11個書くと大変なのでその中から特にいろいろ思ったものを書いた。 講演とても良かったなぁ。 本の解説もありつつ、鉄平さん自身の話もいっぱいあって「訳者オススメの本書籍の使い方」っぽく感じた。 Xにも書いたけど、読書会をしているように感じる講演だったなぁ(他の方の質問に、「えっ、それって〜」と声を出しそうになった)。

あと「ソフトウェアテストカイゼンする50のアイデア」は、正解じゃなくてアイデアが書いてあるのが良いんだろうなぁと思う。 アイデアだから「自分のところだとこっちのほうが良いかも?」といった感じで、紹介されているアイデアに更にカイゼンを加えることができるし。 もしも「ソフトウェアテストカイゼンする50の正解」とかだったら微妙だったかもしれない(その場合は、正解じゃないよね〜とかどうやったら良いかなぁとかいう議論が起きそうだからそれはそれで良いのかも)。

現地で参加できたのも良かったなぁ。 同じセッションに参加した人とちょっと会話できたりもするし。こういうのは現地のほうがやりやすいので良い。 楽しい時間だった。 書籍、読めてないアイデアがまだまだあるので、読んでいこうと思う。

www.shoeisha.co.jp

*1:きかっけはVSTePおかわり会関西出張版かなぁ?「全員が気になったことをテストする」っていうのが効いていった気がする

*2:そういったテストケースを作ると、そのテストの最中にsaeさんがわかりやすく疲弊するので、すぐにわかる

*3:最近もPush通知のタイミングとアプリ上の画面表示のテストケースを一緒にしてしまって大変なことになった

*4:読んだらやっぱり違ってた。忍者式テストっぽい話に読めた

*5:それでも思いつかなかったら気合でやるか、だって仕事でしょ?が発動する

*6:良い意味でやらざるをえなくなってる

気になったことを丁寧に扱おう #テストアドカレ

qiita.com

この記事は、ソフトウェアテストアドベントカレンダー2023の1日目です。

「良いテストをするなぁ」と思う人達に共通してるところは、仕事が丁寧というか、テストが丁寧なところだなぁと最近よく思う。 丁寧なポイントは分解するといくつかあるんだけど、その中でも「気になったこと」をとても丁寧に扱ってるなぁと思う。

例えば、一昨日。
同じチームのsaeさんがテストをしているとき「あれ?」と声を上げた。 よしたけが「どうしたの?」と聞くと「ここの機能がうまいこといかないんですよね」と画面を見せて説明してくれた。 たしかに、普通に触っているのにうまく動いてなかったので、なんでだろうね、と原因を探った*1。 その結果、その機能はちょうど改修されている最中であるっぽいというチャットをよしたけがみつけた。

「じゃあ今動いてないのはしょうがないのかぁ。とりあえずそのままにしとくか」

よしたけがそう言うと、saeさんは「んー」と怪訝な声を出してから「ちょっと聞いてみます」と言ってからすぐに、その機能を開発しているエンジニアにチャットを送った。

そうしたら、その機能は改修中ではなく、不具合(デプロイが正しく当たってない)ということがわかった*2


いろんな場面を思い浮かべてみると、自分が一緒に働くテスターは気になったことを「まぁいいか」とはしていない。 気になったことがあったら内に留めてない。
動かしてみたり、人と話したりして確かめている。

「そんなの当たり前でしょ」って思うかもしれないけど、この当たり前をやっていて、やり続けているのはとてもすごいことだと思う。 「これ気になったけど、なんか忙しそうにしてるし言わなくていいや」「他にもやらないといけないことがあるし」とか言って、サボりたくなるときもあるんじゃないかな。 自分は昔、そういう風なことを思って、気になることを雑に扱ってたときがあった(今はこういうことはやらないようにしている)。

良いテストができるようになる方法はいろいろあると思う。 ただ、その中でも1番身近な今からでもすぐにできる方法は、気になったことを1つ1つ丁寧に扱うことだと思う。 これを続けると、積み重なっていって、それが当たり前になって、不具合を逃さない、良いテストができるようになるんだろうなぁと思った。

気になったことを丁寧に扱おう。

*1:すぐに担当のエンジニアに確認するときもある

*2:一応自身のフォローをすると「もしsaeさんがそのままにしておく」って言ったら自分は「やっぱり聞こうか」と言うようなめんどくさいやりとりではある

とちぎRubyの勉強会 拡大版 参加ブログ #toruby

2023/8/5(土)にあった、とちぎRubyの勉強会 拡大版の感想ブログ。
自分用の覚え書きなので、参加してない人は読みづらいかも(参加してると読みやすいというわけでもない)。 toruby.connpass.com

前座

track8さんによる前座。
エスト・サイド・ストーリーのてんどん、面白かったなぁ。 3年前にあったとちぎRuby会議09(たぶん初オンラインのやつ?)でお手紙を書かれていたのはこの方だったのか〜と勝手にちょっとしみじみ。 ゆるっとしてて良かった ウエスト・サイド・ストーリー見たことないから、お盆休みに見てみようと思う。 magazine.rubyist.net

せきさんの割り込みの話と契約の話

せきさんの話を生で聴くのはたぶん4回目。
(とてか05JaSST Review'19JaSST'19 Kyushu→今回)。
テストやチームじゃない話を生で聴くのは初めてでなんだか新鮮だった。

speakerdeck.com

割り込みっては実はポーリングだった的な話。面白かった。 途中で話にもあったけど、割り込みは特別な何かだと思ってた人に自分は該当する。 実はちょこちょこと確認しててなんだかかわいいなぁと思った。

speakerdeck.com

assertの話は、最近「『ソフトウェアテストカイゼンする50のアイデア』読書会を聴く会」でも少し話にあげてくれたなぁって思い出しながら聴いた(ちょうどそのあたりの回をaki.mさんがブログに書いてくれている。ありがたい *1 *2
「せきのコードのバグが以上に少ないのはなぜか問題」は、どれだけ少なかったのかとっても気になった。 あと、少ないってことは0ではなかったってことだと思うので、そんな中どんなバグがあったんだろう?っていうのも。

せきさんは自慢がうまいので聴いてて楽しかったなぁ。 asserについての理解が全然ということがわかったので、ひとまずassertについて調べてみることにする。

ruby.wasmハッキングガイド

speakerdeck.com

なかじまさんのブラウザでRubyをキメると気持ちいいという話。
自分がRubyを書かないからなのか、キメる気持ちよさが最初はピンときてなかった。 でもギークな話を聴いていき、最後に実際に動かしてもらった画面で.rbのファイルがネットワークタブに表示されてブラウザ上で動いているのがわかったときは自分も「おぉぉ!」と感動したから、少しだけわかったかもしれない。
あと、ブラウザ上で動くってことはRubyを試す機会が増えるから自分も勉強しやすい(試しやすい)のかなぁ?とか思った。
それと、もしお仕事でruby.wasmを使うとなったときに、Rubyを書いてる会社の数名は「ブラウザ上でRuby動いてるんですよ。すごくないですか!?」と嬉々として言ってそうだなぁと想像できたから、たしかにキメると気持ちよさそうだって思った。 なかじまさんが見せてくれたシステムがとてもきれいですごかった(最初、表示されている文字は画像かなぁと思っていたら、文字はプログラム中にあったのでびっくりした)。

研鑽Rubyプログラミング勉強会

「研鑽Rubyプログラミング」の読書会。
普段のtorubyでやっていることらしく、今回は、第5章「エラーに対処する」の最初から。訳者の角谷さんの音読で進行した。 訳者による音読、とても貴重な体験だったなぁ。

Rubyを書かないからついていけるか心配だったけど、自分でもわかりやすいテーマと内容だったのでだいぶついていけた気がする。 特に言語によって同じような場面でも失敗したときにエラーを返すのか、例外を発生させるのかといった思想の違いがあるというのを知れたのがよかった。 自分は普段全然意識しないから、そんな違いがあるのか〜!となった。
あと「コードで書くと2 ~ 3行で伝わることを、日本語で説明するのが難しい」(うろ覚え)といった話が出てて、たしかになぁと思った。配列の要素がないところを参照して〜とか言わなくてもコードを書いたら何したか伝わるのすごい。
ただ、後半になると、Rubyの具体例が出だして自分はよくわからなくなってしまった(具体例が出るとわからなくなる、っていう珍しい体験だった)。だけど、みんながうんうんうなずいてたり、同じようなところでん?となってそうなのが感じれて面白かった。あと、終わってから「これってそう感じるものなの?」と一緒に行った後輩に聞いたら「そうですね」って教えてくれたので、そういうものだったらしいこともわかってよかった。

あと、オープニングだったっけ? 「研鑽Rubyプログラミング勉強会のターンで本はなくてもいいんですか?」という質問に米澤さんが「大丈夫ですよ」って答えた後、角谷さんが「Lambda NOTEでお求めいただけます」って返してたやり取りがまるで打ち合わせしたみたいにきれいでとても面白かった。

続きを読んでみたいなぁと思ったので、福岡に帰ってからちゃんと原著も買った(中級から上級のRubyプログラマーではないけど、自分自身のプログラミングを改善するために原則とトレードオフを学ぶことに関心のある方には当てはまるのでよし!)。

研鑽Rubyプログラミング ― 実践的なコードのための原則とトレードオフwww.lambdanote.com

GAIとRuby

speakerdeck.com

酒匂さんによるGAI(Generative AI)を使った事例や応用の発表。6月のSS2023で話された内容を元にさらに追加もあるという感じだった。

個人的に、SS2023での酒匂さんのお話がめちゃくちゃ良くて、酒匂さんの資料を参考に、実際にChatGPTを使ってコードを生成してテストツールをいくつか作ったりしてた。 そんな中もう1度、酒匂さんのお話を聴くことができたのはとても幸運だった。特によかったのが伝えることと翻訳することの部分のお話をもう1度聞けたこと。 モデルの表現方法をAIに任せるというのは自分もいくつか試してみようと思った。 そして紹介される事例もお話もすごいことだらけだったんだけど、何よりも、そんな風に使おうと思う(使い方を思いつく)ところがすごいなぁと自分は思った。

テストの健全性とコンテキストにおける重要度の変化について思ってることを話したい!

今回の「とちぎRubyの勉強会 拡大版」をやるきっかけになったというヨシオリさんのターン。
誰かが言ったことに参加してる人がそれぞれ考えて、気になることがあったら口に出して、もし言いづらくてもついポロッと口に出しちゃったりしてそうな、よい時間だった。 50分しっかり脳みそを使ったおかげで自分はヘトヘトになってしまった(もちろんよい意味で)。 直前に芋ようかんを食べてなければダメだったかもしれない。芋ようかんとても美味しかったです。

プログラムを書くのを生業にしてる人が多い中で、テストについての考えを聞けたのよかったなぁ。 あと、たしかせきさんか米澤さんが言ってた「時間は限られてるからお得なテストはなんだろうって考える」っていうのは真似して使おうと思った。 うちのチームもテストを減らしたいんじゃなくて、もっとテストしたいんだよね。っていう話を、福岡に戻ってからsaeと話した。

それから、めちゃくちゃ一方的な思い出なんだけど、ヨシオリさんを知ったのは、とてか05のとき。 120秒LTが時間切れになり途中で終わるやいなや、すごい勢いでホワイトボードに2回目の名前を書いて、「で、続きなんですけど」ってLTの2回目をしてて「めっちゃアツい方だなぁ」って思った。 その短い時間だけだったんだけど、そのときのことがなんだかとても印象的で、今回のテーマを見たとき、せきさんたちととちぎでどんな話するんだろう?って気になって今回参加したいなぁって思った。 そして参加してよかったって思う(もしこの思い出が間違いだったりもし違う人だったら…それでも今回参加できてよかったのでそれはそれでよし!)。

LTのターン

覚えてることをつらつらと。

  • タイマーがとってもよかったなぁ。かっこいいし。ちゃんと拍手や歓声も出るのよかった。モードの切替がサクッとできてるの良いよなぁ。使い勝手良さそう
  • ルービックキューブうまくてすごかった。練習用のあるのすごい。作ったのかな?
  • 本めちゃくちゃ読まれててすごかった。感想がところどころ秀逸でおもしろかった
  • Rubyにまつわるクイズおもろかった。みんな結構正解しててすごい。最後の問題が単語なのか言語なのか気になった
  • TDDでFailになったのをさらにAIが直して〜っていう話。すごい世界だった
  • 自己紹介に自分のレントゲン写真を使ってる人を見たの、かれこれ4人目でびっくりした。栃木では流行っているのかもしれない
  • ボルダリングすごかった。ちょっとずつ繰り返してできるように〜ってところがとても好き
  • 舞踏!(チグリス・ユーフラテス?に住む人々の文化の本、面白そうだったけど舞踏の印象が強すぎて忘れた…)
  • 読書会のBGMの原曲があったの知らなかった(忘れただけかも)。原曲とてもよかった
  • 推しにあったときの気持ちめちゃくちゃわかる。自分も一度遭遇したことがあるけど、頭の中が真っ白になったなぁ
  • 自分は最近あった珍しい事象(DBリセット事件)の話をした。120秒には間に合わなかった

おわり

本当は翌日にでも書きたかったんだけど、移動もあったし当日頭をいっぱい使ったのもあって疲れたので今日にw(でも今日書いているのでよし!)
ブログを書きながら当日のことを思い出して、あーよい時間だったなぁ、って何度も思った。

それに今回は会社の後輩と一緒に2泊3日で行ったんだけど、行きの飛行機、新幹線、前日の夕ご飯、当日終わってからコンビニへ買い物に行く道中、帰りの新幹線、東京での食事中などなどの時間でずーっと開発に関わる話やとちぎでの話もできて、それも楽しくてよかった(帰りの飛行機では自分は疲れ果ててずっと寝てた。後輩氏はずっと読書してたらしくすごかった)。

あ、あととっても重要。
ソフトウェアテストを改善する50のアイデア」に鉄平さんからのサインをやっともらうことができた! コメントまでいただけてとても嬉しかった。25番はよしたけです。

www.shoeisha.co.jp

それから今回、セコンさんに大変お世話になったし、差し入れにあったシフォンケーキがふわふわでとても美味しかった…。感謝しかない。

あれからまだ一週間しか経ってないのかぁ。もっと前だったようにも感じる。めちゃくちゃ濃い時間だったなぁ。また行きたい。
いいtorubyだった。

おまけ①

前日の夜に入った、黒磯駅の近くにある「Pico Pizzeria」ががとても美味しかった。 野菜もお魚もお肉も美味しくて。またとちぎに来たときは絶対行くと思う。 pico-pizza.jp

おまけ②

今回キャリーケースを新調したんだけど、それがとてもよかった(OltimoのOT-0861-46)。 まぁまぁ力がないので、元が軽い & キャスターのロックがめっちゃ便利だった。

lojel.co.jp

6つのミスについて思うこと #テストアドカレ

qiita.com

この記事は、ソフトウェアテストアドベントカレンダー2022の1日目です。

人はミスをする。

そう思いながら生きているので、自分や他の人がミスをしても「まぁしょうがないかぁ」とよく思います。 そもそもミスっていうのは誰かが勝手に決めたことなので、ある状況ではミスだけどある状況ではミスではないってものですし。 ミスってただの行動でしかないですよね。

でもやっぱり「この行動はしたくないなぁ」と思ったりもします。 だけど、そういうときに「次はやらないように気をつけよう!頑張ろう!」とはならなくて、「なんでこの行動をしたんだろう?*1」「この行動をしたくなった理由はなんだろう?」を想像して、そこから「どうやったらこの行動をしたくならないだろう?」を考えることが多いです。 頑張ってもたぶんできないし、気をつけられないときもあるし。その行動をしたくなくなる方が良いなぁと思っています。

www.jisha.or.jp

そんな折「うっかりミスはなぜ起きる―ヒューマンエラーを乗り越えて―」という本をたまたま読んでいたら、ミスの分類や発生条件について書かれていることを知りました。 この本には、ミスしたくなる心理やエラーそのものについての考え方やアプローチの方法など広く紹介されていて、読んでいてかなりグッときてこのブログを書き始めました。 グッときた部分はいくつもあったのですが、その中から「判断、決心の段階でのエラーを引き起こす『心理的心構え』」として分類された6個のミスについて、思うことをつらつらと書くことにしました。

判断、決心の段階でのエラーを引き起こす「心理的心構え」

判断、決心の段階でのエラーを引き起こす「心理的心構え」
① 懸命ミス
② 確信ミス
③ 焦燥ミス
④ 放心ミス
⑤ 多忙ミス
⑥ 無知ミス
引用元:芳賀 繁(2019年)『うっかりミスはなぜ起きる―ヒューマンエラーを乗り越えて』中災防ブックス(P38~P40)

① 懸命ミス

① 懸命ミス

作業者が組織に忠実で、まじめに任務を達成しようと懸命にのめり込んで発生するエラー。

忠実でまじめ。だからこそ起きてしまう、というミス。なかなか面白いですね。 自分も、たまになってるなぁって思います(別に自分が忠実でまじめですごいでしょ!とか言いたいわけじゃない)。 だけどこの状態に陥っていることは自分ではなかなか気づけないんですよね。

自分がやるのは、自分がチームメンバーにテストするシステムの使い方を説明するときに、チームメンバーから「なんでこの操作がいるの?」とか「この機能ってなんでいるの?」って言われて説明できない、みたいなケース。 聞かれる前まで、自分の中ではわかった気でいたんだけど、いざ説明しようとすると自分の言葉で説明できなくて、理由をあれやこれや考えて説明するんだけど、チームメンバーからは「全然ピンとこない」って言われる。 そして自分も、説明しながら「あれ、これ自分も全然説明できない」って気付いて、「じゃあちゃんとこの理由を聞いてみよう」となります。

自分以外のことを考えてみると、何か質問したときに「〇〇さんが言ってるからこれでいい」とか「お客さんがこう言ってるからOKです」って返ってくる場面もこれに当てはまりそうな気がする。 あとは、チケットの修正をする人が「テストチームからのチケットは全部書かれた通りに対応しないと!」って思ってそうなときもかなぁ。

「相手が言っていることは正しい!」と疑問を持つことができずに信じ込んでいる状態。 視野が狭くなっていて、捉え方によっては何も考えずに作業しているようにもなっているので危ないですね。

この状態のまま進むと危ないので、自分たちは「〇〇が言ってるから」っていうワードが出たら「ほんとに?」とか「□□のときそれだと困るかも?」って言ったりしています。 あと「チケットは一回全部読んでみてね」って言ったり提案系のチケットに複数の期待結果を書いたり。 視野がなるべく広がるようなことをやってるんだなぁって思いました。

② 確信ミス

② 確信ミス
熟練者やベテラン作業員が、一連の流れに従って習慣化された行動を、思考や意識的チェックなしに遂行し、まったく疑いもなく間違いの方向に突き進んでしまうエラー。

これありますねぇ。 当事者は、さも当然のように堂々と振る舞っているので、間違っていることに周りも気付かなかったりするので面白いですね。

自分がよくやるのはチケットの読み間違えや、チャットの読み間違えかなぁ。 特定のワードだけ見て「あぁ。このことか」って勘違いしたまま返事を返すと会話が噛み合わない。 「いや、たぶんそれじゃなくて…」って返してくれるので、すぐに会話して自分が勘違いしていたことがわかる、っていう感じ。

①の懸命ミスとも似てるなぁって思うんだけど、②の確信ミスは「はいはい、こんなもんでしょ。大丈夫大丈夫」みたいなまじめじゃないものが混ざっている気がする。

だけど、このミスはテストにはうまく応用しているときもあるなぁとも思います。 自分がシステムに慣れている状態で、新しいメンバーにテストに入ってもらったとき「この操作すると壊れたんですけど」みたいな感じで気付いてなかった不具合が見つかる。

テスターとして「慣れてきても、慣れてないようにテストする」ってやったりもするけど、それでも自分以外のメンバーが本当に新しい感覚でテストするとその鋭さには敵わないなぁって思います。

③ 焦燥ミス

③ 焦燥ミス
就業時間までに作業を完了してしまおうと焦ったり、交通渋滞に巻き込まれながら時間に間にあうようにといらだったり、タイム・ストレスが人間の冷静さ、慎重さを崩して、判断、決心を誤らせること。

これはとてもわかる。本当にあるあるだし、この6個の中だと自分は1番嫌いなミスです。 時間に追われると時間が気になってしまって、本当に気にしたいことがおざなりになってしまう。 しかもたちが悪いのは、このミスをしてしまうと「時間があったら」とか「余裕があったら」っていうどうしようもない言い訳をしたくなるし、個人的にはとてもつらい。 そしてチームメンバーにもこのミスをしてほしくないので、このミスを生まないように特に気をつけているなぁって思いました。

気をつけ方は、時間を気にしなくていいようにタスクを調整する。 当たり前のことだけど、これに尽きるかなぁ。 そして理由もないのに「このテストを2時間で終わらせてください」っていう本当に余計な時間の管理は絶対にしないし言わない。 テストするときに下手に時間を決めると、たぶんその人の中での優先順位が「時間通りに終わること」になってしまうので、「ここ気になるけど時間通りに終わらせないといけないから、確認しなくていいや」って気持ちが生まれやすくなるなぁって思います。 それに「2時間テストしてください」って言って1時間で終わったら、残りの1時間ダラダラとテストするのも違いますもんね。

もちろん、じゃあいつまでも無限にダラダラとテストしていいか?というとそうでもないので、焦らず気になることがなくなるまでテストする、という感じ。 この塩梅はチームメンバーのテストの雰囲気から想像したり、会話して確認しています。

④ 放心ミス

④ 放心ミス
単純作業の連続、単調作業、退屈な監視業務、心配事、疲労、睡眠不足などから意識水準が低下して起こるエラー。

「単純作業の連続〜」と「心配事/疲労/睡眠不足など」で要因は違うけど、1つのミスにまとめているのが面白いですね。 前者と後者で対策が違ってくる気がするけど、「どちらも意識水準が低下してる」と言われるとなるほど!となりました。 このミスも起こしたくないですね。 起こさないようにそれぞれ気をつけてるなぁと思いました。

単純作業の連続については、一気にやらない/一気に割り振らない、ペアでやるようにしています。 例えばローレベルテストケース(手順が細かく書かれているテストケース)を自分が作ると、どうしても確認項目が多くなってしまうんですよね。 それをチームメンバーにやってもらうんですが、「はい!このケース全部やってください!」ではなくて、「一旦ここまでやってください」って感じで切り取って渡す感じ。 場合によってはその他のケースを非表示にして渡したりもします。

あと、1人ではなく2人でやる。 2人になるだけで全然単純じゃなくなるんですよね。変なミスに気づけたり、他の不具合が見つかったり、サボりたくなってもサボれないし、逆に疲れてきたら休もうって言えるし。

「心配事/疲労/睡眠不足など」については、その日はもう仕事しないで って自分にもメンバーにも言う。 「いやいや、がんばります」って言ったり言われた時期もあるんだけど、その状況って普通の状態じゃないので、本当にミスするんですよね。 なんならミスしていることにも気づけなかったりしますし。

「普通じゃない状態でテストするとどういう行動になるのか?(自分がどういうミスをするのか?)」を知るというのが目的ならいいけど、それが目的じゃない状態でテストすると結果的に全員が困ることになりやすいですし。 これも終わったあとに「体調悪かったからしょうがないね」って言い訳したくなるので、嫌なんですよね。 なのでこういうときはチームでは潔く休むことにしています。

ただ、稀に休めない状況もあるので、そのときは体調不良であることを伝えた上でお仕事するようにしています。 これが隠されるといろいろとつらくなりますよね。

⑤ 多忙ミス

⑤ 多忙ミス
緊急事態、複雑な非定常状態、自動化装置の不具合などにより、突然作業量が増加し、時間的余裕がなくなり、判断の質が落ちたり、パニックに陥るためのエラー。

外から見ているとわかりやすいミスですよね。 「あの人忙しそうだからなにか見逃しているかも」って感じで。 このミスはあるあるだよなぁて思ったけど、自分のチームは、お仕事的にこのミスが発生する状況にはなりづらいなぁって思いました。 あるとするなら「なんとか今日中に終わらせて!」と差し込みがきたとかかも。

だけど、メンバーにまでこれに陥ってほしくないので、メンバーには自分がそれぞれ割り振って、多忙じゃないように言ったりします(もちろん、ヤバさとか伝えることもあるけどケースバイケース)。 あとは、この状態は弊社だとエンジニアがなりやすいかもしれない。 なので、そうなっている人をみたときには「これって大丈夫?」って聞いたり「ひとまず落ち着こう」って言ったりもするかなぁ。

あ、意外と会議中になることはあるかもしれない。 情報や議論がありすぎて頭の中が多忙になる。こうなったときは良い結論があんまり出てない気がする。

多忙にならないようにいろいろ対策するけど、それでも多忙になるときはあるので、そうなったら「多忙である」っていう自覚があるだけでも少し対策できるかもしれない。 どうやって自覚するかは…メンバーに言ってもらうとかかなぁ。 自分でこの状態に気付くのは難しそう。

⑥ 無知ミス

⑥ 無知ミス
知識、理解が不足しているために起こるエラー。教育、訓練、経験が不足している未熟練者だけでなく、省人化で一人の作業者に幅広い知識が要求されたり、新しいハイテク機器がつぎつぎに導入されるため、ベテランでもこのタイプのミスを起こす可能性が高くなってきました。

ミスって聞いたときに多くの人が思い浮かべそうなミスだなぁって思いました。

でもこのミス、テストにうまく応用しやすいですよね。 うちのチームではこのミスは実は結構役に立っていることが多いです。 テスト対象のシステムを説明してもらってからテストに入るのですが、システムをわかってないからこそしてしまう操作があるし、そこで不具合が見つかる的なやつ。 もちろん「無知」に頼るだけじゃなくて「無知な人が触ったらどうなるだろう?」を考えながらのテストももちろんしますが、やっぱり本当に知らないことが多い状態には敵わないなぁって思います。

この無知ミス、②の確信ミスと合わせて面白いなぁって思うのは、知らなくてもミスするし、知っていてもミスするっていうところ。 知っていたら大丈夫、でもないし、知らなかったら大丈夫ともならないのが「そうだよなぁ」としみじみ思いました。

自分がテストしているとき、自分に対しても他のメンバーに対しても「今どれくらい慣れているのか?どれぐらい不慣れなのか?」は気にしている気がします。 それを考えてテストを割り振ったりしています。

おわりに

ただただ思うことをつらつらと書きました。 「どんなミスをするか、ミスが生まれない状況にするにはどうしたらいいか」という自分の行動についての考え方だけでなく「『◯◯ミスが起きそうなとき』のことを考えてテストする」と考える参考にもなっていいですね。 この本がかなり面白かったのでなんか思ったことを書きたかったんですよね。 まだまだ書きたいことはあるけど今回はこれくらいにします。 まとまりのないブログを読んでいただきありがとうございました。

他にも「エラーをおかしやすい人」「誤りに強い人と弱い人」「錯覚は正常覚」などなど個人的にとてもおもしろいことが書かれていたのでぜひ読んでください。

*1:「この行動が生まれた背景にはどういう要因があるんだろう?」っていう意。責めているわけではないし、責任には興味がない。

バグを逃してしまったときにチームでやること #テストアドカレ

qiita.com

この記事は、ソフトウェアテストアドベントカレンダー2021の1日目です。

先日友人に「バグを逃してしまったときどうしてる?」と聞かれました。 そこで自分たちのチームがバグに気づけなくて逃してしまったときはこんなことしてるよ、という話をしたのでその内容をブログに書くことにしました。

逃したとき

バグを逃してしまったとき、自分たちは「そもそもそのバグに気づくことができたかどうか」を考えます。 気づく実力があったかどうか、という意味合いが近いかもしれないです。 ただどちらにせよ、逃している時点でその実力はなかったと言われるとその通りです。 「他のプロジェクトでテストしたときは逃さなかったバグかどうか」を考える という感じが近いと思います。

自分たちの実力ではそもそも気づけなかった場合

自分たちの実力ではそもそも気づくことができなかっただろうものについては、以下を行います。

  • バグについてエンジニアに聞く
  • バグに関係することを調べる
  • どういうテストで見つけれるか考える
  • どうやったら↑のテストをするようになるか(したくなるか)を考える

「エンジニアに聞く」「調べる」は、何が原因だったのか、どんな条件で起きるのか、どんな対応をしたのか、このバグから他にどんな事が起きるのか考えるなどをやります。 自分たちが気づきようがなかったので徹底的に調べます。

それが終わると、次は「どんなテストで見つけれるか」「どうやったらそのテストをするようになるか」を考えます。 ここでどちらかというと難しいのが「どうやったらそのテストをするようになるか」です。 「このテストをやればこのバグはみつけられるぞ!」と思っても、そのテストをやるようにならないと意味がないですよね。 しかし、このとき考えたテストは自分たちにとって完全に新しい取り組みなので、うまいことやらないとなかなか自分たちの動きに馴染んでくれません。 そこで「どうやったらこのテストを自然に気付けるようになるか?自然にやるようになるか?やりたくなるか?」を話します。 話している途中にこれが決まらない場合は、また「どんなテストで見つけれるか」を考え直します。 「このテストをやれば見つけれるよね、意識して頑張ってやろう!」と言いたくなる気持ちはわかるんですが、現実問題そのテストをやるのが難しいということもよくあります。 また、意識しようと思っても体に染み付いた考え方を変えるのはなかなか難しいです。 なので、今の自分たちのテストの流れ(テストの考え方/やり方)にできるだけ自然に埋め込める/拡張するよう考えるようにしています *1

自分たちの実力で見つけれたかもしれない場合

次に「自分たちに気づく実力があったけど気づけなかった場合」の話です。 繰り返しになりますが「そもそも気づけてないのでその実力がなかった」のはごもっともです。 「他のプロジェクトでテストしたときは逃さなかったバグだけど逃してしまったバグの場合」です。

この場合、まず以下を考えます。

  • テスト中どの瞬間に気づけたか
  • なぜその瞬間にテストをしなかったのか

「普段なら気づけたはずなのに気づけなかったと思う」ということは、普段とは違う何かがあったということですよね。 なので、普段ならどの瞬間に気づけたんだろうかを探します。

その瞬間が見つかると次に「なんでそのテストをやらなかったのか」を思い出します。 その場面を思い出すと、自覚してやらないを選択したのか、無自覚にそのテストをやらなかったのかなどがわかるので、そこからさらに「その選択をした理由」または「そのテストをやらないようにさせた要因」を辿ります *2。 ここで出てくる例としては「データの準備が大変だからケースを減らした」「直前に大きなバグが直って安心してしまった(油断)」「既存のシステムをコピーするだけだから大丈夫(油断)」「余裕がなかった」などがありました。 そしてさらにこれらから「なんでその判断をしたの?」や「なんでその状況になったの?」をある程度繰り返し考えていきます。

例えば「無自覚にそのテストをやらなかった」要因が「余裕がなかった」としたとき「なんで余裕がなかったんだろう?」を考えます *3。 すると「デグレや再確認が多くて疲弊してた」とか「仕様変更が多くて…」とかそういったものが出てくるので、また「なんで?」を考えるという感じです。

ある程度繰り返して要因を出し終わると、それぞれの要因に対して「その状況にならないようにするにはどうするか」「その状況になってしまったときどうするか」「どうやったらその状況になっていることに気付けるか」を考えます。 先程まで挙げたものだと以下を考える感じです。

  • 余裕がない状況にならないようにするにはどうするか
  • 余裕がないときどうするか
  • 今余裕がない状況になっていることにどうやったら気付けるか
  • デグレが多いときどう立ち回るか
  • 疲弊してることにどうやったら気付けるか
  • 油断していることにどうやったら気付けるか

ここで特に気にしているポイントは「どうやったらその状況になっていることに気付けるか」です。 「余裕がない」「疲弊している」ときは 本人はその瞬間は自覚がないことが多くて、プロジェクトが終わった後にふりかえってみると「あー、あのとき余裕なかったな」と気づくことが多いです。 なので「余裕がないときこういう風に立ち回ろう」と決めても「余裕がない状況になってることに気づけてない」ため、せっかく立てた対策が実行できなくなってしまいます。

もちろんここで考える内容も、今の自分たちのテストの流れ(テストの考え方/やり方)にできるだけ自然に埋め込めるように話し合います *4

おわりに

ここまで自分たちのチームで、バグを逃してしまったときどうするかを書きました。 どちらの場合も時間はだいたい30分ぐらい、長くても1時間ぐらいで終わります。 かなり頭を使って話すので時間にすると意外と早く終わります。何より1時間以上は頭が持ちません。

今回は逃してしまったバグについて書きましたが、「このバグよく見つかったね」というのも↑のように考えたりします。 ものにもよるんですがラッキーで見つかったようなバグは特に。 運も実力の内とは言うけど、そういうのは次回は実力で見つけたいですよね。

そしてここまで淡々と書いてきたのですが、バグを逃すことはもう本当に絶対1番やりたくないことだなぁと思います。 申し訳ないし、悔しいし、もうその他色んな感情が吹き出して未だに取り扱いに困ります。 でも、そのバグを逃さないように新しく取り組みを始めたせいで、これまで普通に見つけれていたバグが見つけれなくなるのも嫌です *5。 テストのデグレ、イヤですね。 なので今できていることは守りつつ、ちょっとずつ丁寧に対策していけたらと思っています。

*1:根本的に変えないといけないこともありますが最近はあまりないです。どうやっても難しいときはあきらめてやります。

*2:なんでそのテストしたのか/どういう事考えてテストしたかなどその場面を事細かく覚えているのはテスターあるあるな気がする(もちろん覚えてないときもあるけど)。

*3:「余裕がなかった」で終わるふりかえりは苦手なんですが、「なんで余裕がなかったんだろう」を考えるのは好きです。でも「時間がなかった」「考慮漏れ」というワードが出てくるのはなんか苦手です。

*4:それぞれの役割で考えます。 テスト実行する役割だったら/テストを指示する役割だったらなど。

*5:チームメンバーのsaeさんが「新しく取り組むのは良いけどそれをやると今できていることができなくなる気がする。そのほうが嫌」と言ったことがあって確かに!と思った。

第157回テストラジオのメモ-シナリオテストとデータ移行の回 #テストラジオ

第157回テストラジオで話したことのメモです。
本編はこちら

話したこと

  • シナリオテストの話
  • データ移行でみつかった不具合の話

今回はなそさんと自分がそれぞれ話したいネタを1つずつ話しました。

シナリオテストの話

なそさんが今回のラジオで話したかった話。
ここではシナリオテストとは「業務シナリオや業務フローをもとにテストしていく」といった意味合いで使いました。
「シナリオテストを作って欲しい」となそさんがメンバーに依頼したら、お互いに想像していたものが違って「あれ?」となったというのがこの話。 「シナリオテストを作る」という経験が自分にはあまりないので、なかなか新鮮な話でした*1

自分は「シナリオテスト」というワードに引っ張られて、収録直前の週にある社内システムの仕様(操作)を教えてもらったという話をしました。 この社内システムの追加開発でテストが必要になったけど、テストチームがほぼ触ったことが無いシステムなので、 せっかくなら社内で実際に使っているメインユーザーに仕様と操作を教えてもらおうと思った、というのが経緯です。 自分たちがテストする時に「ユーザーはどんな操作をするだろう?」「どう思って操作するだろう?」と想像することはもちろんあるんですが、 「ユーザーが実際に触っているのを見る」機会がなかったので、レアな経験でした。

説明してもらいながら実際に普段の操作をしてもらったので仕様や動かし方を知ることができたのですが、 個人的にはそれよりもちょっとした操作の癖や入力の順番を見れたことがとてもよかったです。 (おそらく)開発した当時は想定してない部分から検索したり、 あるデータを登録するときには「最初に一部のフォームに値を入れて登録して、後日、編集画面から残りのフォームに値を入力する」などなど。

シナリオテストを考えるときにはこういった操作まで細かく想像することも大事なんだろうなぁと思いました。

※ メモ ISTAB(JSTQB)では「ユースケーステスト/シナリオテスト/ユーザシナリオテスト」として以下のように定義されている。

ブラックボックステスト技法の一つ。ユースケースの動作を実行するようにテストケースを設計する。

https://glossary.istqb.org/jp/search/%E3%83%A6%E3%83%BC%E3%82%B6%E3%82%B7%E3%83%8A%E3%83%AA%E3%82%AA

データ移行でみつかった不具合の話

よしたけが今回のラジオで話したかった話。
ここで自分はデータ移行を「システムをリプレイスするときに既存のシステムからデータを移行する」 「現行システムがない場合は、新システム利用開始前にデータを注入する」といった意味合いで使いました。 自分のチームはデータ移行(のテスト)に関わることがあまりなかったのですが、珍しく関わって「データ移行らしい不具合」を見つけましたというのがこの話です。
※ 実際のデータ数はかけないですが、1レコード20カラムぐらいで500レコードぐらいあるといった感じざっくりな想像でOKです。

ラジオ本編では以下のバグの話をしました。

  • 必須のカラムが空になってるものがあった
    • システムを動かすと500エラーが起きたのでわかった。
  • あるカラムの数値データがおかしくなってるものがあった
    • システムを動かしていたら気づいた
    • データ注入前にエクセルでデータを弄ったらエクセルの書式によって値がおかしくなったっぽい。
  • あるカラムに改行が反映されてなかった
    • システムを動かしていたら明らかに改行されてそうなものが改行されてなかったので気づいた

自分たちがデータ移行のテストをする前に、もちろんエンジニアも注入するデータのチェックをしてくれてたので、基本は問題なかったんです。 一部のデータだけで起きていたので見つけれてよかった。

ラジオ本編やツイキャスのコメントで以下のようなこともありそう、というのをなそさんが教えてくれました。

  • 移行するとき、新システムへデータの入れ先がない(逆もありそう)
  • リレーション間違い(IDがくっつく予定がIDがないとか)
  • 売上データと思ったら明細は仕入れデータだった(データの勘違い)

また、自分が使っている「データ移行のテスト」というのは「現新比較」(現新比較テスト/現新比較検証)というそうですね。
知らなかったので勉強になりました。

ラジオ収録外で話したこと

・年が明けてから音声問題に悩まされいる
 収録ソフトのノイズキャンセルと使っている機材との相性問題なのかなんなのか、なかなか難しいですね。 この回はその調整に1時間ぐらいかかったので、なかなかもどかしい。 これが解決したときはすっごい気持ちいいんだろうなぁ。

*1:シナリオテストをしないわけではないけど、まだまだ甘いので今後やり方を極めたいなぁと思った

第156回テストラジオのメモ-雑談ベースドテストの回 #テストラジオ

第156回テストラジオで話したことのメモです。
本編はこちら

話したこと

  • オンラインで会話する時の音質問題
  • 雑談ベースドテストの話

オンラインで会話するときの音質問題

オンラインで会話するとき、自分の音声が正しく聞こえているかわかりにくいよね、というイントロでした。
特に答えはないんですが、難しいですよね。

雑談ベースドテストというなのながらテスト

前回のラジオの最後に「雑談ベースドテスト」というワードだけが出て終わったのでその説明をしました。
それっぽい感じで書いてますが「雑談しながらテストしたらバグが見つかった」ということを、冗談めかして「雑談ベースドテストだね」と笑っていたというものです。「雑談ベースドテスト」というワードは自分が作った造語です。

ただ、せっかくなので、このワードが生まれた時の状況を分解してみました。 詳細についてはラジオ本編で話したので、そちらをお聴きください。 雑談をする = 肩の力が抜けているというときだからみつかりやすいものもあるのかなぁと思いました。 ただ一応補足すると、テストは雑談しながら(ふざけながら?)できるものではないので、そのように捉えた方がいたらすみません。

また上記の状況の説明とはちょっと状況が異なりますが、テストを黙々とやっていてふっと休憩した時、何か新しいテストや不具合のありそうな場所をひらめくというのがあるよね、という話をしました。
自分がラジオ収録当日にたまたま見た「奇跡体験!アンビリーバボー」の再放送で「G-SHOCK」と「QRコード」の開発秘話を取り扱っていたので、それを例に出しました。

それぞれの開発秘話はすごい話だったので以下の記事などをぜひ読んでみてください。
www.itmedia.co.jp

toyokeizai.net

ラジオ収録外で話したこと

収録当時、時間がなかったので特になし