CAT GETTING OUT OF A BAG

What the tester is thinking.

明日から試せるテストに関するアドバイス🎄

この記事は、テストに関するツイート(わたしの)の抜粋です。
那須の「あのチーム」の話を聞いたからと言って、すぐに真似することはできないかもしれないけど、これなら明日から試せそうじゃない?と思うものを、集めてみました。

1. 実装する前にやってみたい(やる)テストを宣言する

2. 同僚が見つけた良いバグを褒める

3. なぜそのテストをやってみたのかを話す/聞く

4. 昨日見つけたバグや気になることを交換する

5. 暴れる前にツイートする

6. プログラマーに自信のあるところ/ないところを聞く*1

7. 話しづらいことは話しづらいので話せるように練習する 

 

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

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

 

 

*1:ツイートで引用したのは、書籍『達人プログラマー』の一節。テスターにもおすすめの本です。7. の『割れ窓理論』も載っています。

ブログのサイドバーに本棚を置きました

自宅の本棚を新調したいな…と思っているのですが、どういう本棚にしようか探したり、悩んだり、採寸とかいろいろ面倒くさいので、とりあえずブログのサイドバーに本棚を置いてみました。だからと言って何も解決してないんですけど、ちょっと満足しました。 これをやるためにブクログでIDとって、とかは面倒くさくない。

ブクログのIDを miwa719 にしたかったのに既に使われていて(もしかして自分で取ったのかな?)と思ったけど調べられなかったので beautyandharmony にしました。名前が美和だから。  

beauty and harmony

beauty and harmony

Twitter などで言及したことのある書籍を中心に並べていこうと思います。 booklog.jp

コーヒーの香りを楽しむための Apple Watch アプリを作りました

普段、紅茶やルイボスティーを飲むことが多いのですが、猫廼舎さんコーヒー豆が通販で買えるようになったので、毎日1杯だけハンドドリップする時間を作りました。コーヒーを淹れるときの香りには、人間の脳に働きかける二つの効果(癒しと集中力)があるそうです。

20秒間、時計の秒針を見てるのが辛い

コーヒーを淹れるのは、頭の回転が鈍くなる午後2時から3時くらい。リフレッシュして(午後5時まで)あと1、2個のテーマでテストするぞーと思う時間帯です。

コーヒーを淹れるときの手順はこんな感じ。

  1. ペーパーフィルターをドリッパーにセットする
  2. ドリッパーにコーヒーの粉を入れる
  3. 粉の表面に20cc程度のお湯を注ぎ、20秒ほど蒸らす
  4. 中心部に「の」の字を描くように、お湯を数回に分けて注ぐ
  5. できあがり

この手順 3 のとき、ハンドドリップならではのふわっとした良い香りがするのですが、時計(Apple Watch)の秒針を20秒間見てなきゃならない。これが地味に辛い。

20秒たったらお知らせしてくれる Apple Watch アプリを作りました

コーヒーを淹れるときの手順はこんな感じになります。

  1. ペーパーフィルターをドリッパーにセットする
  2. ドリッパーにコーヒーの粉を入れる
  3. 粉の表面に20cc程度のお湯を注ぐ
  4. Apple Watdh アプリを起動する
  5. ボタンを押す
  6. 香りを楽しむ ← ここが重要
  7. お知らせ(チャイム音と手首トントン)がくる
  8. 中心部に「の」の字を描くように、お湯を数回に分けて注ぐ
  9. できあがり

手順が増えたけど(笑)蒸らし時間を気にしないでコーヒーの香りだけを楽しむことができます。

このアプリの特徴やこだわり

  • 20秒たったらお知らせすることに特化する
  • 視覚以外(聴覚と触覚)でお知らせする
  • 時間を設定することはできない(20秒固定)
  • アイコンでも20秒以外は対応しないという強い意志を示す
  • アイコンの背景色は「モカ」という色を使用(コーヒー豆を意識)

f:id:miwa719:20181111144340j:plain f:id:miwa719:20181111145742j:plain

  • 画面は見ないので凝ったデザインにしない 
  • 画面に Button とか Label という文字が表示されていても気にしない *1

f:id:miwa719:20181111145752j:plain f:id:miwa719:20181111150257j:plain f:id:miwa719:20181111145812j:plain

問題点:Apple Watch がスリープしてるとお知らせしてくれない

シミュレータでまあまあいい感じに動くようになったので、実機(Apple Watch)にインストールして動作確認をしていたら、20秒たってもお知らせ(チャイム音と手首トントン)してくれないときがあるんですよ。どうやら Apple Watch がスリープしてしまうと通知しないみたい(そうなるように実装しているんだろうけど…)。大問題ですね。アプリを動かしたら Apple Watch がスリープしないように目で監視しなきゃならないわ*2。これでは困ります。

解決方法

そもそもなんでスリープするのか調べていたら、Apple Watch の設定で「タップ時」というものがあるのですね。知らなかった。

f:id:miwa719:20181111162127j:plain

「15秒間スリープ解除」というのは「画面が表示されたままになる時間が15秒間」という意味で(分かりづらい)鋭い人はもう分かったと思うけど、この設定を変更しました。

f:id:miwa719:20181111162136j:plain

こうすればアプリ起動後、70秒間はスリープ状態に移行しないので問題解決です。(自分のためだけのアプリだから、これで良いことにする)

タップ時の設定をこれまでの15秒から70秒に変えたことで、バッテリーの持ち時間にすこし影響が出るかもしれませんね。Apple Watch がスリープ中でもアプリからお知らせする方法を調べるのは、必要に迫られたらやろう。

新しく覚えたこと

開発環境

その他

来月のとちぎRubyの勉強会 #toruby で Rubyist にコードレビューしてもらおうかな。Swift だけど。前にキッチンタイマー(言語はC#)を作ったとき、みんなにコードを見せたらでダメ出しされたので耐性はついてる。

f:id:miwa719:20181111153242p:plain

 

ドリッパーとペーパーフィルターは、こちらで購入したものを使っています。

item.rakuten.co.jp

item.rakuten.co.jp

猫廼舎さんはスイーツも美味しいです。お店に猫はいないけど、猫好きな店主がいます。コーヒー豆はこちらから購入できます。(スイーツと店主の @ogijun さんは通販してません)

cafenekonoya.shop

*1:これは自分に言い聞かせています。開発環境など諸々のアップデートをしながら、週末の二日間で動くものを作りたかったので。プロジェクト名も sec20 にしてあれこれ手を出さないように自分で自分をコントロールしたよ。名前重要!

*2:こんな運用回避は嫌だ

プログラミングの「アンチパターン」からテストを考える

はじめに

この記事は、技術系ブログや書籍などに書かれているプログラミングの「アンチパターン」を読んだとき、わたし(テスター)が、どのようなことを考えているのか紹介したものです。

もし「アンチパターン」で実装されていたら

わたしはよく「過去の不具合を使って(同じような)不具合が起きないかを確認する」ということをするのですが、この「過去の不具合」を「アンチパターン」に置き換えて、テスト対象のソフトウェアが、もし「アンチパターン」で実装されていたら

  • どのようなこと(ミス、不具合)が起きそうか
  • どのようなテストをやってみたいか

を考えます。この2つが対になるように考えてもいいし、テストが思いつかないときは「こんなことが起きそう」だけでもOKです。要はより多くの「起こりそうな嫌なこと」を描くトレーニングです。

題材さえあればいつでもどこでもできます。一人でもできますが、何人かで集まってやると自分では思いつかなかったこと(他人の思考)を、自分のものとして頭の中に取り込めるのでお得です。時間を制限してやると瞬発力がつきます。なお、わたしたちのチームは(特別に集まることはなく)普段からこのようなことを話しています。

 

今回は、伊藤 淳一さんの こちらの記事 を題材にしてやってみたいと思います。サンプルコードや解説がとても分かりやすい!テスターのみなさんにも、ぜひ読んでもらいたい記事です。

blog.jnito.com


なお、実際に開発してる製品を絡めた形では書けないので、架空のシステムを想定した、やんわりとした内容になっています。  

主要な変数が全部連番、かつあらゆる変数がグローバルなシステム

どのようなこと(ミス、不具合)が起きそうか

  • プログラマーが打ち間違いをしそう*1
  • コードを見ても間違っていることに気がつかない
  • 実装に時間がかかるので、十分なテストができないかもしれない
  • 指定するテーブルやカラムを間違うことで、お客さまがやりたいことと無関係なデータを表示、変更、削除してしまう
  • 仮にテスト対象が電子カルテシステムだった場合
    • 別の患者のカルテで治療計画を立ててしまう
    • 患者の体位と向きの表示を間違えたまま開腹手術してしまう
  • ループ用の変数もグローバル変数で宣言されているのか……
    • データは取得できても、中途半端に表示することがあるかもしれない
    • 件数は合っていても、前回のデータを残したまま表示することがあるかもしれない(初期化が中途半端)
  • 主要なテーブルやカラムについては目に触れることも多いし、みんなが気にして確認するけど、そうではないものは確認が手薄になりそう

どのようなテストをやってみたいか

  • この実装だと間違える要素がありすぎるので「間違っているものを探す」というよりは「正しいものを探す」という気持ちでテストしたい
  • 単にデータが取得できた、変更できた、削除できただけでなく、データの中身まで確認したい
  • 全テーブル、全カラム、全てだ!
  • テストデータは適当な文字列の羅列ではなく、テーブルごとに意味のある内容にしたい
  • テストデータを見ただけで「どのテーブルのどのカラムのデータ」が分かるものを用意したい(テスト結果を見たときに、指定先の間違いに気づきやすい)
  • 指定するインデックスも間違うかもしれない。応答速度(検索、ソートなど)も気にしたい
  • とすると、テストデータの量も調整しながらテストしたい
  • ループ用の変数もグローバル変数で宣言されているので「件数」を気にしたい

カンマ区切りで複数のコード値を格納しているテーブル

さっきのもすごいけど、これもすごいな(こういう実装を思いつくのがすごい)*2

どのようなこと(ミス、不具合)が起きそうか

  • マシンスペックが良すぎると、案外サクッと動いてしまうかもしれない
  • 性能問題に気づけないのが問題
  • 売上げテーブルの商品コードカラムに、商品マスタに存在しない商品コードが登録できてしまうかもしれない(外部キー制約をつけられそうにないから)
  • カンマ区切りで複数のコード値を格納しているテーブルは、この売上げテーブルだけではないかもしれない
  • データの整合性に関して何もかもが怪しく思えてくる

どのようなテストをやってみたいか

  • プログラマーの開発PCより遅いマシンスペックでテストする
  • システムで推奨してるマシンスペックより劣るもので動かすと、早いうちに問題に気づきやすい
  • たくさんの商品を1回で購入するような操作をしてみたい(売上げテーブルの商品コードカラムを溢れさせたい)
  • 商品を購入した後に、商品マスタのマスタデータを削除してみたい
  • 商品マスタの商品コード自体にカンマを入れてみたい
  • 商品名にもカンマを入れておきたい(ITEM_NAMEからコードを逆生成することがあるかもしれないので、念のため) 

おわりに

テストの定義はいろいろありますが、わたしが一番好きなのは、マイヤーズの「テストとは、エラーを見つけるつもりでプログラムを実行する過程である」というものです。この「エラーを見つけるつもりで」という行為は、より具体的な「エラー」を頭の中で描けないと難しいと思っています。絵本『ウォーリーをさがせ!』を想像してみてください。ウォーリーを知らないと探すことはできませんよね。ウォーリーを見つけるための手がかり(どんな顔をしていて、黒縁メガネをかけていて、ひょろっと痩せていて、赤と白のしましまの長袖Tシャツを着ていて、赤いボンボンのついた帽子をかぶっていて…)を知っているから探せるのです。

今回この記事で紹介したのは、より多くの「起こりそうな嫌なこと」を描くためのトレーニングの一例になります。「起こりそうな嫌なこと」は「エラーを見つけるための手がかり」の1つです。いつでもどこでも「起こりそうな嫌なこと」を描いてしまう癖がつくと、思考のバリエーションがどんどん増えていき、ソフトウェア開発の各場面で活かせるのではないかと思っています。実際、わたしが普段やっている Testing はこういった癖(トレーニング)で習得した要素が含まれています。きっと明日のテストでは、入力項目に思わず「カンマ」を入れてしまうと思います。

 

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

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

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

NEWウォーリーをさがせ!

 

 伊藤 淳一さんのチェリー本も載せておきます

 

*1:そんなの当たり前!と思うことでも出します。それが本当に当たり前かどうかは分からないし(でも、だいたいは当たり前なんですけど)当たり前にやるだろう、と思っていたことがすっぽり抜けてしまった苦い経験があります。

*2:すごすぎて他の言葉が見つからないわ。テーブルやカラムを増やしてはいけないシステムだったのかな。

「バグの伝わり方」を知るということ

見た目は単純そうなバグでも、その生い立ちを知ると「バグの伝わり方」が見えてきて(面白いなー)と思うときがあります。

たとえば、アプリケーションの画面には、やりたいこと(処理)を実行するための「ボタン」があります。状況に応じて、ボタンを有効(enable)にしたり、無効(disable)にしたりするんですけど(Twitterクライアントアプリなどもそうですね。何か文字を入力すると「ツイートボタン」が押せるようになります)あるソフトウェアをテストしてたとき、そのボタンは使えない状況だったのに「有効」になっていたのです。ああ、無効にするのを忘れたのかな(単なるコーディングミス)と思ったのですが、実際はもうすこし複雑でした。

ボタンの有効/無効は「状態」によって決まり、4つの状態(A,B,C,D)を持っているモデルがありました。でも、使う側はBかCかそれ以外(D)で判断していました。だからAのときはDに倒れてしまう。Aのときはボタンを「無効」にしなければならないんですけど、Dに倒れたことで「有効」になってしまった。さらに、

  • 状態Aは開発の途中で後から追加した
  • これらの状態は複数の機能で使われている
  • 複数の機能は複数のプログラマーによって開発されている

というものでした。


開発の過程で様々な機能が作られていき、それによって新しい状態が生まれる。元からあった機能は新しい状態を知らない。これまでうまく動いていたものが、あるとき急に動かなくなる。「バグの伝わり方」が目に見えるようでした。

また、このときに思ったのは「外側から見えている状態」と「プログラムで扱っている状態」は必ずしも同じではないということでした。プログラムで扱っている状態は4つ(A,B,C,D)ですが、わたし(テスター)から見えていた状態は3つ(A,B,D)だった。わたしが想像するよりも、プログラムの世界はもっともっと複雑で繊細なのです。

今回の話は「バグの伝わり方」の一例ですが、それ以来、状態に関する変更が入りそうな時には「プログラム内部で持ってる状態が増えたりしますか?」とプログラマーに聞くようになりました。昨日より良いテストをするために(わたし自身が)知りたい!という気持ちが強いのですが、朝会などでわざとらしく聞くのは「このチケットがコミットされたら、状態も気にしてテストしますよ(だからみんなも気にしてね)」というメッセージでもあるのです。

ベテランプログラマーKさんの弱点

隣のチームのベテランプログラマーKさんが担当したものを(自主的に)テストすることがあるんだけど、バグが出ない。これまでにわたしが見つけたのは1つだけ。「◯◯の隙間を突かれましたねー」と、笑いながら言われたので、そのときの風景も含めて覚えているのだけど、その1つだけ。

隣のチームで開発してる部分の理解が圧倒的に足りない(=効果的なテストができない)のもあるけど、ある程度わかったとしても、簡単には出せない感じがする。

…とは言っても、Kさんも人間なのでミスはする。わたしが観測した範囲だと、Kさん自身がミスに気づいて直すパターンが多い。それも、外側から動かして見つけたというよりは、内側から(理詰めで)見つけてきたような、うまく表現できないけど、そう簡単に見つかるようなバグではない感じ。こういう凄腕プログラマーもいるのだなあ、と常々思っている。

そんなことをプロの無職 @m_seki に話したら(頼んでないのに)Kさんに話したらしく、Kさんの弱点を聞いてきてくれた。ありがとうございます。

「作ったところに関してはあまりバグは出ないんだけど、たまに要件ごとごっそり抜けることがあります」


それ以来、チケットに書いてないこと(隠れた要件や機能など)も気にして触ってるのだけど、バグを見つけたことはまだありません。

テストのさじ加減


はじめに

テスターが「仕様書」や「見た目の出来栄え」だけでなく「設計の良し悪し」を感じ、それをテストに活かすことができたら良いんじゃないかな、という話です。テスター向けに書いたのだけど、プログラマーのみなさんは、どんなときに「設計の良し悪し」を感じるのか、教えてもらいたい気持ちがあります。

「設計の良し悪し」とは

書籍『達人プログラマー』第2章(達人のアプローチ)「8 直交性」より

直交性とは、簡単に設計、製造、テスト、拡張できるシステムを構築する場合に必要となる重要な概念です。

(中略)

この用語はコンピューティングの分野では、ある種の独立性、あるいは分離性を表しています。2つ以上のものごとで、片方を変更しても他方に影響を与えない場合、それらを直交していると呼ぶわけです。

本項では「直交していないシステムの変更や制御の難しさ」「良いとされる設計」「直交することの利点」などについて書かれています。はじめに貼り付けたツイートのような「再現手順が思いつかないような現象を見たときでも、プログラマーが問題箇所に当たりがつけられる状況」というのは、ここで良いとされている設計 *1 になっている(またはそれに近い)のではないでしょうか。

多くのテスターがそうであるように、わたしも普段はソースコードを読まないので、本当のところは分からないのですが、開発中に起きる様々なことから「設計の良し悪し」 を感じ、テストのさじ加減(テストを行う際の配慮や手加減のこと。一通り触ってみたけど、もうすこしテストしたほうがいいな、というようなテストの微調整)を決めるための「材料」にしているように思います。

「設計の良し悪し」を感じるとき

わたしが「設計の良し悪し」を感じるときをメモしておきます。悪いシグナルを書いたので、反対にすると良いシグナルとして読めるものもあります。

なお、うちのチームは世界的に『外れ値』として扱われてしまうことが多いので、これまで所属してきた複数のチームを思い浮かべて、観測できそうなものを書いてみました。*2

1. チケットの滞空時間が長い

手をつけてからコミットするまでに日数がかかっているチケット。進んでいるように見えるが、なかなかコミットできない。設計が複雑で難しいのかもしれない。*3

ただ、これは他にも問題(もっと深刻な開発全体に関わるようなもの)が起きていることもあるので、単に経過日数だけに注目すると間違えます。(例:開発が順調に進んでいるように見せる必要があり、ひとりのプログラマーが複数のチケットを同時にオープンしている)

また、チームによっては、滞空時間が長いのは良い傾向(サクッと進んでしまうときほど危うい)の場合もあるようです。

2. なかなか手をつけないチケット

設計が複雑で難しく(やりたくないので)なんとなく後回しにしてしまうのかもしれない。

これもさっきと同じで、経過日数だけ見てると間違えます。(例:バグが出すぎていて取りかかれない、手をつけているチケットで難しい問題が発生している、緊急度/重要度が他のチケットより低い)

3.「再現手順が分からないと分からない」と言われる

現象から当たりをつけられないくらい、これに取りかかったら、しばらく他のことができなくなるくらい、設計が複雑で難しいのかもしれない。

各種ログからも追いづらい、調査しづらい厄介な問題であることが多く、簡単には再現しない。再現手順が分からないと、直ったかどうかも確認できないので、わたしも再現手順を見つけたい。*4

4. 変更内容をコードの断片だけで説明する

変更前にそう書かれていた意図、それをどのように変更したのか、それで良いと思ったのはなぜか(根拠)を言葉で説明できないくらい、設計が複雑で難しいのかもしれない。

5. 変更したら別の機能が壊れた

変更したことによる影響が分からないくらい、設計が複雑で難しいのかもしれない。*5 

6. 変更したファイルがやけに多い

一昨日、うちのチームのプログラマー @vistige_ から「コミットログを見ると、いろいろ分かって面白いですよ〜」と教えてもらったので、しばらく毎日観察してみようと思っています。ファイル名からどの辺を変更したか、だいたい分かると言っていたので、これは予想ですが、自分ではちょっとした修正だと思っていたのに、変更したファイルがやけに多いなとか、いつもとは違うあまり見たことのないファイルが変更されてる…を感じることができるなら、テストのさじ加減も変わりそうです。*6

 

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

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

 

 

*1:YourdonとConstantine が「凝集度」と呼んでいるもの

*2:プログラマーが常に良いコードを書きたいと願い、実際そういうコードを書こうとしてるのは、見て知っています。わたしが対象にしてるのは製品(ソフトウェア)なので、プログラマーを責める気持ちはありません。どうか怖がりませんように…!!

*3:うちのチームでは「仕切り直し」というキーワードが使われるので分かりやすい。最近、特に注目しているのは「鋭意作成中」とチケットに書いてくるプログラマーがいるので、注意深く観察しているところです。「作成中」なのは知っているので「作成中」と書いてくる時点で気になるけど、さらに「鋭意」を入れてきた理由があるはずだと思うから。

*4:この手の問題は1つ直っても、他に問題が潜んでいることも少なくないので、修正後の確認はかなり時間をかけて行います。問題の周辺をよく見る。

*5:どこを直したらどこが壊れた、という事実は、テスターが内部設計を予測するのを助けます。

*6:ある部分は機械化できそうな気もする。