CAT GETTING OUT OF A BAG

What the tester is thinking.

若手開発者(プログラマー)と読書会をはじめました

5月に社内の若手開発者(プログラマー)から「テスト設計技法を学びたい。できれば体系的に」と相談されたのをきっかけに、書籍『ソフトウェアテスト技法ドリル』の読書会をはじめました。この記事では読書会をはじめるときに決めたこと(伝えたこと)と、2か月やってみて思ったことをメモしておきます。あと『ソフトウェアテストの練習帳』を使ってみたのでそれの感想も!

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

 

読書会をはじめるときに決めたこと(伝えたこと)

本を読むことを主目的としない

単に本に書いてあることを音読し、わたしがたまに補足して、巻末の演習問題を解くのではなく、テスト設計技法を学びながら実際の開発(テストを含む)について考えたり、話し合う場にしたいと思いました。このやり方だと1冊読み終えるのに半年はかかるのと、読書会がうまくいったらどうなるか?のイメージ(=普段の開発の中で読書会で話したことを思い出し何かのヒントになる)を伝えました。

担当制にしない

章ごとに担当を決めて担当になった人が当日講師役になって進めていくスタイルは、講師になった人が事前に予習しなければならず大変なのでやめました。…というのは建前で、今回の状況だとどうみてもお前が講師だろ!て感じだったのでそれを回避しました。

宿題にはしない

宿題があると時間的にも気持ち的にも負担になりますよね。例えば、章の最後に演習問題が2問あるんですけど1問だけみんなでやって、もう1問は次回までに各自やっておきましょう、ということはしない。

無意識だったけど「しないこと」を決めていたのだなあ。

読書会を2か月やってみて

週1回開催(1時間/回)で8回実施しました。この本は第6章まであるのですが、現在第2章まで読み終えたところです。

  • そうだろうなと思っていたけど、若手開発者(以降、Aさん)も普段の開発の中でテスト技法(同値分割や境界値分析)を使っている
  • Aさんも「自分が普段やっていることに名前がついている」ことが分かってきたみたい
  • 本を読むことで「いつこの技法を使うのか」「どのように考えていくのか、またそれでよいとする理由」を自分の頭の中に取り込むことができる。これまでなんとなくやっていたことが(これでいいんだな)と思えるようになるのは、精神衛生上とても良いことだと思う
  • 区切りのいいところまで音読し、自由にディスカッションしている*1
  • 気になった文章を取り出し「これはどういうことを言っているのか」「この技法の考え方は実際の開発の中だとどこで使われているのか」そこからさらに設計、実装方法にブレークダウンしたり、過去に見た(聞いた)不具合などを話している
  • 結論を出したり章ごとにまとめるようなことはしていない(その場で話したことが全て)
  • この本は技法だけでなく「ソフトウェアテストの7原則」「248日問題」など、知っておいてもよいことがさらっと書かれている。Aさんに聞いたら「知らない」というのでその場で簡単に紹介している*2
  • Aさんとは開発してる製品が全く違うので、同じドメイン(医療機器)であっても原理的、構造的な違いから、似たような機能であっても気にするところが変わってくるのが面白い(自分の思考を広げるネタとして使えるので、こういう話を聞くのが好きです)
  • 1時間やるとかなり疲れるけど、週1回なので続けられそう

ソフトウェアテストの練習帳』の感想

ソフトウェアテストの練習帳』はソフトウェアシンポジウム 2019 東北に参加した際にお土産として頂いたものです。一般の書籍ではないので、以降の感想は練習帳を持っている方とこの練習帳の製作に尽力された方々向けになります。

ソフトウェアテスト技法ドリル』の第2章まで読み終えると、この練習帳の同値分割と境界値分析(11問)が解けるようになります。さっそくやってみました!

  • 1時間で2問解きました(1問目:40分、2問目:20分)
  • 問題を解く上で考えなくてよいこと(制約)が書かれているので、考える範囲が適度にしぼられ、その結果、対象にしている技法(今回は同値分割と境界値分析)に注目して解くことができました
  • 問題が文章だけ(構成図や画面例がない)というもの同じで、書いてないことで有効な制約になっていると思いました*3
  • あえて制約をつけないで問題を解いてみるという使い方もできそう
  • 問題を解いてるときに解答例、解説が見えない(次のページになっている)のが良いです(自分で見えないようにするのは案外ストレスがかかるものです)
  • 問題の横に書き込めるように?たっぷり余白があるのですが、何度も使いたいので練習帳には書き込まずホワイトボードを使いました
  • この問題に対する答えはこうだろうというよりは、自分ならどんなテストをしてみたいか、なぜそれをしたいのかを自分の言葉で話すようにしています
  • 自分で出した答えと解答例を比べて同じだと、やはり嬉しい気持ちになりますね
  • 1問目を解いたときに「代表値」について読書会ではそれほど触れなかったのに気づくことができました。そこで「都道府県を選ぶときの代表値」を例題にしてディスカッションしました
  • 解答例だけでなく丁寧な解説もついているので、その答えにたどり着くまでの過程を自分の思考と照らし合わせて確認することができるのがよいですね
  • 1問目と2問目は同じような解説が載っています。対象が同値分割と境界値分析なのでそうなるんですけど、やりようによってはわざと見せ方(解き方)を変えることも可能だと思ったのですが*4、おそらく同じような解説の方が読み手が混乱せず、安心して問題を解くことができるので、正しいことを同じように繰り返すのは大事なことなんだと思い直しました*5
  • 問題を解いていくことで「同値分割と境界値分析とはこういうもの」をより実感することができますね
  • Aさんは本で学んだ通りのお手本になるような解答をしたあと、さらに実装方法をホワイトボードに書きながら、自分ならこの対象としている値の元になるデータはfloat型を使うかもしれない、そうなると値を求める時に差分をとって比較するようなことをすると思う。なぜ差分をとるのかは前に値をそのまま比較して失敗した(丸め誤差と桁落ち)ことがあるので…のような話をしてくれました*6
  • このような話が出てくるきっかけになる練習帳の問題、素晴らしい!
  • 老眼の人にも優しい組版だと思いました(フォントや文字の大きさや行間など)

 

同値分割と境界値分析の問題はあと9問あるので、次回の読書会からしばらく練習帳を使うことになると思います。この練習帳を作ってくださった方々のお顔を思い浮かべ感謝するとともに、これからも楽しみながら解いていきたいと思います。ありがとうございました。*7

note.mu

*1:読書会ではなんでも話してほしいので、率先してわたしがなんでも話すようにしている。Aさんもなんでも話してくれるようになってきた。自分の仕事で解決できなくて困っていることとか。

*2:その後、Aさんは自分でボーイング787の248日問題、497日問題、36時間問題などを調べていた。

*3:うっかり画面例を書いたらいろいろ気になってしまい大変なことになった。

*4:思ったというか期待しちゃった…!JaSST Tohoku 実行委員のみなさんに対する期待値がものすごく高いんだわ。

*5:3問目以降の問題は見ないでこれを書いてます。

*6:こういう話が好きです。

*7:練習帳の表紙にもなっている仙台『蔵の庄』のごぼう天、美味しかったのでまた食べたいなあ。

「無効にする」という言葉は案外むずかしいのかもしれない

「無効にする」という仕様でプログラマーとテスターが違うものを想像した話です。開発中の些細な出来事ですがツイートするには長すぎるのでこっちにメモしました。

 

ある日のこと 

ある画面に表示しているスライダーコントロールを触っていたら、おかしな現象に気づきました。Trackの部分をマウスの中ボタン(ホイールボタン)でコロコロしたら、値の増減が正しく行われる時と行われない時があるんですね。

 

https://docs.microsoft.com/ja-jp/dotnet/media/genericslider.png?view=netframework-4.8

説明上、スライダーコントロールの部品の名称を載せたかったので docs.microsoft.com .NET.Framework の Slider Class の図を直接リンクしました(わたしたちが開発してる製品とは無関係です)

 

担当のプログラマーTさんとFさんにその現象を見せて、そのあとチームでどうするか話し「中ボタンは無効にする」ことになったのですが、翌日修正したものを触ったらなんかおかしい。

  • Trackの部分を中ボタンでコロコロしても値は増減しない。無効になっているのでOK
  • Trackの部分を左ボタンで長押しすると連動して値が増減する。元からあった仕様でこれもOK
  • 左ボタンを長押ししたまま(マウスダウンしたまま)中ボタンをコロコロすると値が戻ってしまう。あれ?

例えば、値が10の時プラス方向に長押しすると11、12、13、14と増えていきマウスボタンを離したときに増加が止まります。これは良いのですが、長押ししながら中ボタンをコロッとすると10(長押しする前の値)に戻ってしまう。

中ボタンは無効にすることになったので、長押ししながら中ボタンをコロッとしても何もせずに無視するが、わたし(テスター)が期待した動作でした。直しきれてないコードがあって中ボタンのイベントが発火したのかなと思いました。…にしてもどう作るとこうなるんだろう。

さっそくプログラマーTさんとFさんにその現象を見せたら「そうなるように作ってます」と衝撃の言葉が!えっえっどういうこと?と聞いてみたら「中ボタンは無効にすることになったので、中ボタンが押されたら前の状態に戻してます」とのこと。無効=取り消し=それまでの操作を取り消す意味で捉えたのか!なるほどー。*1 

結局、中ボタンを押しても無視する(何もしない)ことになったのだけど「無効にする」という言葉は案外むずかしいのかもしれない。今後「無効にする」が出てきたら無効とはどういうことか、どう動くのか(どう動かないのか)を具体的に話そうと思います。

*1:前の状態に戻すにはある時点での状態をどこかに記録しておく必要があるので作るの大変だったのではなかろうか…

バグが報告されたときにわたし(テスター)がやってること

こちらのツイートですが、思いがけずたくさんの方に見ていただきソフトウェア開発(特にテスト駆動開発)への思いやご意見を伺うことができました。ありがとうございます。


この記事では「バグが報告されたときにベテランプログラマーSさんではなくわたし(テスター)がやってること」をメモしておこうと思います。

自分以外の誰か(以降、同僚)がバグを見つけたときにあなたは何をしていますか。個人的に大変興味深いテーマですが、バグを見つけるための手法やプロセス、バグを見つけたあとの報告の仕方(バグ票の書き方など)と比べて取り上げられることが少ないように思います。もしかしたら当たり前すぎて話題にならないのかもしれませんが『当たり前にやってることに価値がある』と聞いたことがあります(これを書くモチベーションにしよう!)。

バグが報告されたときにやってること

以下にざっと列挙しましたが(★)は自分でバグを見つけたときにもやってることでした。消すのもなんなので載せておきます。(だいぶ書いてから気がついた)

  • どのようなバグなのかを知る(★)
  • どうやってそのバグを見つけたのかを教えてもらう
  • バグを再現させてみる
  • 自分ならそのバグを見つけられたかどうかを考える
  • どんな風に作るとそのバグが起きそうかを考える(★)
  • そのバグが起きるなら…(他のバグを探しに行く)(★)
  • バグを見つけた同僚を褒める

どのようなバグなのかを知る(★)

うちのチームは面白いバグや重大なバグが見つかるとザワつくことが多く(何かが起きたらしいぞ)を感知したプログラマーやテスターが発生源に集まってきます。そこで見つけたてのバグを再現方法も含めて披露してもらうのですが、バグそのものの現象を知るには一番早くて確実な方法ですね。

朝会の中で(昨日そんなバグが見つかったのかー)とはじめて知るものもあります。現象自体はなんとなく想像できるものが多いのですが、分からなかったらその場で聞いて教えてもらいます。嫌な現象は起きてないけど今の実装だとまずい(いつかアプリケーションがクラッシュする)というものも報告されます。

これらのバグを修正していく過程でどんどん明らかになっていく「バグの原因(どこをどう間違ったのか)」「何を実装したときにこのバグが入ってしまったのか」「どこをどのように直すのか」に耳を傾け、またそれに伴うディスカッション(その修正方法だとこういうケースでダメなのではないか etc )も合わせ聞いたうえで、徐々に「こういうバグなんだな」が分かるようになります。*1

どうやってそのバグを見つけたのかを教えてもらう

これは操作手順のことではなく、なぜそんなことを試してみようと思ったのか、何を見ておかしいと思ったのかです。思考側(きっかけ、動機)ですね。

  • 前に開発していた製品でこんなバグを見たことがあったので
  • 画面の更新が一瞬遅くなったからあれ?と思った
  • 処理が遅すぎて(退屈で)やることがないので押せるものを押してた
  • チケットを ”クラッシュ” で全文検索して気になるものをやってみた
  • いつも同じデータで試していて問題を見つけられなかったことがあったので
  • 見た目はこんな画面構成だけど、内部的にはデータを二重管理しているから…

これを教えてもらうと、同僚が知っていることや経験してきたことや考えていることを(断片的ではありますが)自分のものにすることができます。例えば、これまで見てきたバグや自分自身の失敗談、いま何に注目し、何を心配しているのか、テストのやり方や得意なこと、こだわりや癖など。それを自身の開発(テスト)に活かすのです。これはオススメです。*2

ただ、実際に自分で経験したことではないので揮発性というか時間の経過と共に忘れてしまうことが多いです。そのことに気づいてからは専用のメモ帳に書いておき、ときどき読み返しては自分の脳にせっせと書き込んでいます。

バグを再現させてみる

先ほど ”朝会ではじめて知るバグも現象自体はなんとなく想像できるものが多い” と書きましたが、バグが直ったことを確認するときのために(このバグは自分の手で再現させて自分の目で見ておかなきゃ!)と思うものがあります。

  • タイミングを狙うような操作が必要なもの
  • 操作手順が複雑なもの
  • 現象自体が分かりづらいもの

これらのバグは練習して確実に再現できるようにしておきます。例えば「この処理の一瞬の隙間を狙ってボタンを素早く二回押す」といった操作です。”現象自体が分かりづらいもの” というのは「動作がもっさりする」「画面がパシャパシャする」「ボタンが一瞬チカッとする」のようにオノマトペで表現されるものが多いです(うちのチームだけの特性かもしれませんが)。自分で再現させる前にバグを見つけた同僚に目の前で再現させてもらったり、どこがどうおかしいのか説明してもらうこともあります。パシャパシャとはこの現象を言ってるのだな、とかね。プログラマーが優秀で翌日にはバグが直ってしまうこともあるので(見ておかなきゃ!)と思ったらすぐやるようにしています。

自分ならそのバグを見つけられたかどうかを考える

同僚が見つけたバグを「自分なら見つけられたかどうか」を考えます。

  • 自分ならその操作を試そうとしただろうか
  • 自分ならその状況を思いついただろうか
  • 目の前にそれ(バグ)が現れたときにおかしいと思えただろうか
  • 設計や実装を想像できただろうか

遅かれ早かれ「自分でも見つけられたかな」と思うものはそれでよしとします*3。そうでないものは、そのバグを見つけられないのはなぜか、自分でも見つけられるようになるにはどうすればよいかを考えます。

  • これから開発(テスト)するときに注目すべき点(観点)としてXXXを自分の中に取り入れよう
  • バージョンごとにそんな複雑な仕様になってることを知らなかった → その仕様に詳しいNさんに教えてもらう
  • この特殊な画像データを使うとおかしさに気がつきやすいのか! → 使う
  • 設計や実装を知らないとそこが怪しいなんて絶対想像できない → プログラマーSさんに説明してもらう*4

どんな風に作るとそのバグが起きそうかを考える(★)

これは自分でバグを見つけたときにもやってることなので省略します。

そのバグが起きるなら…(他のバグを探しに行く)(★)

これも自分でバグを見つけたときにもやってることなので省略します。

バグを見つけた同僚を褒める 

「これはいいバグ!」「よく見つけたなー」と思ったら褒めます。わたしも誰かに褒められたら嬉しいですもん。最近だと入社2年目のエンジニアKさんが「丁寧にテストしないと見つからないバグ」を報告していたので褒めました。Kさん「だんだん慣れてきたらこんなに(丁寧に)テストしなくなるかもしれません」と馬鹿正直に言うので「10年後もその丁寧さを忘れないでーーーー」とお願いしました。

同僚じゃなくても褒めてますね。

おわりに

バグが報告されたときにわたし(テスター)がやってることをメモしました。同僚がバグを見つけたときって今の自分には無いものに気づいたり、足りないものを学習したり、他人の経験(暗黙知を含む)を自分のものとして取り入れることができる良い機会だと思っています。

 

テスト駆動開発

テスト駆動開発

 
ソフトウェア・テストの技法 第2版

ソフトウェア・テストの技法 第2版

  • 作者: J.マイヤーズ,M.トーマス,T.バジェット,C.サンドラー,Glenford J. Myers,Todd M. Thomas,Tom Badgett,Corey Sandler,長尾真,松尾正信
  • 出版社/メーカー: 近代科学社
  • 発売日: 2006/08/01
  • メディア: 単行本
  • 購入: 7人 クリック: 267回
  • この商品を含むブログ (47件) を見る
 
ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

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

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

 
新装版 達人プログラマー 職人から名匠への道

新装版 達人プログラマー 職人から名匠への道

 

*1:分かったことが「本当に正しいかどうか」は気にしすぎないようにしてます。もちろん正しいのが理想なんですけど、自分で(こうなんだな)と思えればまずはよし。あとから分からないことが出てきたり疑問に思ったときにまた調べたり誰かに聞いたり、間違いに気がついたときにエラー訂正します。

*2:自分でバグを見つけたときも、なぜそんなことを試してみようと思ったのか、何を見ておかしいと思ったのかを話すようにしています。

*3:見つけられたとは思うけどそのバグはもうすこし早い段階で見つけたかったな…と思うものがあります。何かの順番が間違っているのでしょうね。

*4:Sさんにもどのようなバグを見つけられるようになりたいのかを伝えます。Sさんはそれを踏まえてどう作られているのかの種明かしや秘密を暴露してくれるはずです。

とちぎRuby会議08 食に関するメモ #toruby

6月29日に開催した『とちぎRuby会議08』でわたしが担当した『』に関するメモです。

ランチセッションのお弁当

今回のお弁当は『石窯イタリアン アンジェロ』さんに作ってもらった。

5月にアンジェロさんと打ち合わせをした。お弁当のボリューム感について悩んでいそうだったので「参加者の8割くらいは男性で2、30代くらいの方もわりと多いかな……」と言ったところ「唐揚げのようなガッツリしたものがいいでしょうか?」と聞かれたので、前回(一昨年)のとちぎRuby会議07の『からあげ弁当』の話をした。(ランチセッションで用意した『からあげ弁当』の影響でパーティーのお料理が大量に余ってしまう事案発生。詳しくはこちら


…かと言って少なすぎるのも困るんですけど……いい感じにお願いします…!とおまかせ(丸投げ)した結果が、こちらのお弁当。

f:id:miwa719:20190629112737j:plain

1品1品、丁寧に作ってあるのわかる。彩りも豊か。夕方からはじまるパーティーのお料理とかぶらないように作ってくれた。気にしていた量も(全体的に見て)少なすぎず多すぎずだったと思う。というのは、パーティーのお料理が不足することもなかったし、大量に余ることもなかったから。

コーヒーマシン

f:id:miwa719:20190629112254j:plain

  • アンジェロさんにお借りした。とても良かった!
  • ダークチェリーという豆だった。飲みやすかった。
  • 何人かの方からレンタル料金を聞かれた。お料理なども全部こみでお願いしたので単品の金額はわからない。
  • 開場前に設置&使い方を教えてもらった。前回と同じ機種だったのに使い方をすっかり忘れていた。
  • 適宜、水とコーヒー豆を補充して、コーヒーかすを捨てれば良い。簡単だけど1年後はまた忘れてると思う。
  • 挽きたてのコーヒーは香りもいいし美味しい。売れ行きもよかった。
  • 講演の最中にガーーッと豆を挽く音が響くの非同期処理ぽくて、好き。

用意した飲み物

  • ペットボトル(2リットル)28本
  • 前回(8月開催、参加者数は今回とだいたい同じ)「18本用意してほとんど残らなくて、あと5、6本あってもよかった」→ 今回増やしてみたけど10本くらい残った。足りないよりは良い!
  • お持ち帰りしてくれたみなさん、ありがとうございます。
  • ウィスキンソン ジンジャーエール(辛口) 24本
  • パーティー用に冷やしたものを持ってきてもらった。
  • 開封の3本は @arton さんに持っていってもらった。ありがとうございます。
  • そうそう、アンジェロさんがクーラーボックスで大量の氷を持ってきてくれた。冷たいほうがいいでしょうからって。
  • 氷を用意するのは思いつかなかった。アンジェロさんさすがアンジェロさん。

f:id:miwa719:20190629112200j:plain

軽食つきのパーティー

  • ケータリングも『石窯イタリアン アンジェロ』さんにお願いした。
  • お料理の搬入などはスムーズで特に問題なし。30分くらいでセッティング完了。
  • 今回のお料理もとても美味しかった。見た目も美しいし、食べやすいように工夫してある。
  • いつも写真を撮り忘れるんだけど今回は忘れなかった。

f:id:miwa719:20190630163316j:plain

f:id:miwa719:20190630163338j:plain

f:id:miwa719:20190630163401j:plain

  • 毎回お料理の名前が分からなくて(あの美味しかったあれ)みたいな感じになっていたので、今回はお願いしてメニューをつけてもらった。
  • 名前が分かるとこんなツイートができるのだ。名前重要

  • ワインのコルクがこんな風に使えるなんて!(きれいなコルクは捨てないで取っておくか)
  • ワインは赤と白1本ずつ持ってきてもらった。
  • 白ワインは氷で冷やしておけばよかった。クーラーボックスに残っていたんだよね。氷。いま気がついた。
  • 前回のメモによると「赤ワインはわりと早いうちになくなった。白ワインがグラス1杯分残った」→ 今回はほとんど残ってた。@ardbeg1958 さんがいなかったからかな。面白いな。
  • ワインは @emorima さん @youchan さんに持っていってもらった。ありがとうございます。
  • アルコール類の準備はよく分からないので(飲まない人もいるし)今までどおり、飲みたい人が休み時間に買いに行くスタイルでよいと思う。
  • @you_ssk さんが日本酒2本を差し入れしてくれた。ありがとうございます。
  • アンジェロさんから『電気式石窯ピザ』使用のご提案があった(素晴らしい)
  • 電源事情がクリアできれば挑戦したい…!焼きたてのピザはどう考えても美味しいに決まってる。
  • 軽い気持ちで『電気式石窯ピザ』を調べてみたら100万円くらいする。びっくりした。
    f:id:miwa719:20190630170353j:plain

  • Lightning Talks は途中で短めの休憩時間を入れると良かったかもしれないね。お料理を取りに行ったり、コーヒーを淹れたりできるから。

その他

  • テーブルにお土産のお菓子がたくさん並んでいた。ありがとうございます!
  • お菓子の包装紙を使っていい感じに飾る方法を覚えた。@suginoy さんありがとうございます。セロハンテープの端っこを折り曲げておくとはがすとき楽になる小技も教えてもらった。

f:id:miwa719:20190630212815j:plain

  • @takkanm さんのお子ちゃまがかわいくて癒された。会場のうしろに並べた椅子でお昼寝してた。@m_seki のブランケットが大活躍!

  • 閉会後の片付けをたくさんの方に手伝ってもらった。ありがとうございます。 

 

追記(2019-08-18)

当日の本会の様子が『るびま』に掲載されました。思い出し用に貼っておきます。

magazine.rubyist.net

 

うちのチームのプログラマーはなぜテストがうまいのか

 

医用機器(自社製品)のソフトウェア開発に従事して、あと数年で30年になります。いろんなチームに所属し、多くの開発者と一緒に仕事してきましたが、現在所属しているチーム(うちのチーム)のプログラマーはテストがうまいです。プログラマー時代の自分と比較してもそう思いますし、『ソフトウェアテスト』という側面から製品開発を考えられるようになった今の自分から見てもそう思います。いいバグを見つけたなぁ…(素晴らしい)と思うことが多々あります。

うちのチームのプログラマーはなぜテストがうまいのか。いくつかの要因が思い浮かびましたが、その中でも「毎日1時間、システムレベルのテストをしている」のが大きいのではないかと考えました。この記事では、タイトルから期待される結論(なぜうまいのか)を書くつもりはないのですが(ごめんなさい)システムレベルのテストをすることで得られそうなことをメモしておこうと思います。プログラマーがこんなにテストしてるチームはこれまで見たことがありません。これを15年以上もやってるってすごくないですか?*1

プログラマーが毎日システムレベルのテストをしている 

うちのチームのプログラマーは全員、毎日1時間「テストの時間」が割り当てられています。テストの時間は朝会終了後の10:00〜17:00まで。好きな時間に勝手にやるスタイルではなく予め決まっていて、時間割表(テストPC * 6時間)はびっしり埋まっています。プログラマーAさんは10:00〜11:00(テストPC-001)、プログラマーBさんは14:00〜15:00(テストPC-002)のように。プログラマーCさんがテストPC-003の前に座ったら、わざわざ時計を見なくても(ああ、もう16時か)と分かるくらいに常態化しています。

この記事での「システムレベルのテスト」は「テストPC(ほぼほぼ実機環境)の前に座り、お客さまが使うのと同じようにソフトウェアを触るテスト」のことです。JSTQB*2で定義されている「システムテスト」とはすこし違うかもしれません。

テストは『本日のおすすめテスト』*3に従って実施します。テストケースに書いてある通りに操作して期待する結果になるかどうかを確認し、テスト結果を登録します。時間がきたら(テストが途中でも)おしまいです。そんなにビックリするようなことはしていないと思います。

システムレベルのテストをすることで得られそうなこと

  • 自分が開発していない製品、機能そのものを知ることができる
    わたしたちの製品はそこそこ大きいこともありソフトウェアに関する部分だけでも複数のチームで開発しています。ひとつのチームが複数の製品を同時に開発しているので、プログラマーがシステムレベルのテストをするということは、自分以外のプログラマーが作った製品、機能も当然触ることになります。
  • お客さまがどのように使うのか(ワークフローなど)を知ることができる 
  • 実機での処理速度感
  • システムレベルで見たときのバックグラウンド処理(特に他のチームが開発しているもの)を知ることができる
  • 実際の現場に近いユーザーデータ環境がどういうものかを知ることができる
    開発PCだと少なめのデータやお決まりのテストデータで試すことが多いのではないでしょうか。
  • 意地悪テストの残骸を見ることができる
    テストPCはテスターも使っています。テストPCを触るということはテストの残骸(データや操作履歴など)を目にすることになるので、どのようないじめ方をしているのかを知ることができます。
  • 開発履歴を知ることができる
    テストケースからその機能の開発履歴(開発日記)が簡単に辿れるようになっています。どのような経緯で開発(設計、実装)してきたのか、関わったプログラマーは誰で、いつどんな変更が入ったのか、過去にどのようなバグが検出されたのか、どのように修正したのか…などがわかります。実際、開発日記を読みながらテストしているプログラマーの姿をよく見かけます。 

テストケースに書いてないことも試している

先ほど「テストケースに書いてある通りに操作して期待する結果になるかどうかを確認し、テスト結果を登録します。」と書きました。でも「テストの時間」にプログラマーが検出したバグを見るとテストケースに書いてないことも試しています。テストケースを誤読して偶然見つけたものもありますが「これ、絶対バグを見つけにいってるでしょ」と思うものも多いです。どういう心境でテストしているのでしょうね。「テストの時間」はプログラマーの帽子を脱ぎ、テスターの帽子をかぶっているのでしょうか。

おわりに 

うちのチームのプログラマーはテストがうまい自慢と「システムレベルのテストをすることで得られそうなこと」をメモしました。毎日テストをしているからテストがうまくなる(訓練みたいなもの)とも思いましたが、それだけではないのも実は分かっていて、いつか言語化できたらいいなと思っています。

 

*1:中の人たちはこれがすごいことだと分かってないのもすごい。自分たちの開発にはこれが必要だと認識してやってる感じ。

*2:Japan Software Testing Qualifications Board

*3:膨大なテストケースの中から現在の開発の状況に応じていい感じにテストケースを選んでくれるレコメンドシステムがあります。@m_seki が作りました。

ピクシー絵本の思い出

 

この中でも特にお気に入りだったのが、こちらの5冊。

f:id:miwa719:20190503091719j:plain

f:id:miwa719:20190503091720j:plain

f:id:miwa719:20190503091440j:plain

f:id:miwa719:20190503091721j:plain

f:id:miwa719:20190503091531j:plain


当時、お出かけする時にはポシェットの中にピクシー絵本を2、3冊しのばせていくのが習慣になっていて(京浜東北線の電車の中でよく読んでいた)この5冊が選ばれることが多かったように思います。

この5冊のどこが気に入っていたのだろう?と思いながら読んでみたのですが、面白いことに気がつきました。『ひもぐつ』以外の4冊は「何かを作るお話」なんですよ。

ピクシー絵本の内容は「動物のお話」「家族のお話」「仕事のお話」「数のお話」「冒険のお話」「友達のお話」など多種多様です。その中で「何かを作るお話」が何冊も上位を占めるのですから「何かを作る」ことに対して、特に興味を持つ子供だったのかもしれないですね。

そんな子供も大人になり、医用機器を作る仕事に就き、毎日毎日「作っては壊し、また作る」ことを30年近くやってますが、一向に飽きることがありません。

ちなみに『ひもぐつ』は、こんなお話です。

あたらしい赤いひもぐつを買ってもらった主人公(トーマス)が、お母さんにひもを結んでもらって出かけたら、かけよってきた子犬にひもぐつのひもをほどかれてしまいます。家にもどってお母さんにひもを結んでもらおうとしましたが、お母さんはパンを作っていて手が離せません。そのあともいろんな人に頼むのですがみんな忙しくて結んでもらえない。「だれも手伝ってくれないなんてひどいよ」とがっかりしていると、女の子が通りかかります。「わたしが教えてあげるわ。結び方をおぼえて自分で結べばいいじゃない」

トーマスは練習し自分で結べるようになりました。89回目で!

これを読んで(わたしもひもぐつのひもを結べるようになりたいなー)と思いました。最後のページには「くつひもの結び方」が載っていて、まだ履いたことのない『ひもぐつ』に憧れ、眺めていた記憶があります。*1

*1:『ひもぐつ』は「できないことができるようになったお話」であり、そこにも惹かれる要素はあったと思いますが、当時は「ひもぐつへの憧れ」が強すぎて、著者が伝えたかったことは受け取れてなかったなぁ。

誰も使ってない機能にバグが見つかった時にどうするか

 

Twitterのタイムラインにこんなツイートが流れてきました。面白い問いですね。数年後にこれを見てどう思うのか(今の自分と比べてどう変わったのか、または変わらないのか)に興味があるので考えたことをメモしました。(自分宛てなので好き勝手に書いてます)

なお、考えている最中「いつか誰かがその機能をうっかり使うかもしれない」呪縛に取り憑かれて何度も脱線したので「その機能は未来永劫、絶対に使われることはない」を前提とします。あと「誰も使わない機能をなぜ作った?」「他の機能は大丈夫なのか?」についても考えないことにします(書いておかないと妄想が思考を邪魔するので書いた)。

「3. 機能を削除する」について

この中だと「機能を削除する」が好きです。めっちゃ好き。こんな風に書くと「好きとか嫌いで仕事してはいけません」と叱られてしまいそうだけど「機能を削除する」が好き。今の自分ならこれを選びます。

誰も使ってない機能だとしても製品の一部として提供している間は何かと手間がかかります。新しい機能を追加したり、既存の機能を変更するたびに誰も使ってない機能との関連や影響を考えるだろうし、リリースのたびに誰も使ってない機能が正しく動くことをテストしなればならないし。ちょっとした手間であっても塵も積もれば山となるわけで大変なんだよぅ。誰も使ってない機能にコストをかけるのはバカらしいのでやりたくない気持ちもある。そこに労力をかけるくらいなら、違うこと(やるべきこと)に使いたい。仕事とは言え(誰も使ってない機能なのに…)と思いながら作業するのは精神的に苦痛です。

「機能を削除する」ためのコストはかかるけど、以降「誰も使ってない機能」に関してコストはかかりません。良い。

お客さまにとっての価値

元々使ってないので機能を削除しても何も変わらないのかな。個人的にはシンプルになって良いと思うけど。その機能分プライスダウンするなら価値は上がりますか?何に価値があると思うのかは人それぞれでむずかしいと感じるけど、価格は分かりやすいと思う(この文脈では「安かろう悪かろう」は無いものとします)。それ以外だと何だろう。今後は「誰も使ってない機能」のために消費していた(消費するであろう)リソースを他の何かに割り当てられると思えば「新しい価値」を提供することは(計算上)可能のはずなのだけど…

「1. バグを直す」について

製品として提供してしまった機能はそう簡単には削除できません(少なくともうちの製品はそうです)。となると「バグを直す」か「放置する」のどちらかを選ぶことになります。ここで「バグを直す」を選びたくなるのは…自己満足なのだろうな。バグがあるのが分かっているのに直さないでいるのは気持ちが悪い。直せばスッキリする。ただそれだけなのだな。バグを直すには多少なりともコストがかかるので「未来永劫、使われない機能」なら放置した方が安い。

お客さまにとっての価値

元々使ってないのでバグを直しても何も変わらない。うっかりリリースノートに「バグを修正しましたっ」と書いたら(そんな機能は使ってないし、むしろ要らなくね?)(それよりもこっちの機能をどうにかしてほしい)とか思われたりしてね。価値が下がってしまう可能性がある。

「2. 放置する」について

お客さまにそのような問題があるということをお知らせした上で「放置する」なら受け入れられそう(自分が)。何もしないでそのまま放置するのと、バグを直すことにしたのに(優先順位が最下位のため)いつまでも直さないでいるのは似ている。これについてはまだ自分の中にうまく取り込めていない感じ。全てのバグを直すことはできないのは分かっているんだけどな。完璧主義者でもないのに変なの。

お客さまにとっての価値

元々使ってないので放置しても何も変わらない。問題を公表したことが良いイメージ(誠実性や透明性など)につながるのなら、なんらかの価値を与えられるかもしれない。うーん。ちょっと無理があるね。何も変わらないですね。

ここまでのまとめ

本題とは外れますが「自己満足のために仕事してる部分がある」が観測できたのはよかったです。これからは暴れる前に何かを主張する前に(これは自己満足かな?)と問いかけるようにしたい。あと熱中してる時とか…(身に覚えがある)。スッキリした時もかなり怪しい。スッとしたとかツイートしてる場合じゃないわよ(笑)。すこし消化不良するくらいが私にはちょうどいいのかもしれないな。いずれにせよ、仕事に自己満足はいらない。