CAT GETTING OUT OF A BAG

What the tester is thinking.

2020年7月〜12月に買ったもの(自宅のパソコンまわり)

自宅のパソコンまわりがこの半年間でかなり変化しました。買ったものを記録しておきます。(貰ったものもあります)

Apple Magic Keyboard

今年はCOVID-19の影響で在宅勤務にシフトされた方も多かったと思いますが、わたしの場合はそれがきっかけではなく、誕生月にApple Magic Keyboard - 日本語(JIS)をプレゼントしてもらったのがはじまりました。

Apple Magic Keyboard - 日本語(JIS)

Apple Magic Keyboard - 日本語(JIS)

  • 発売日: 2015/10/14
  • メディア: Personal Computers
 

 

MacBook Proと自分の間にMagic Keyboardを置いて使うことで、ディスプレイの位置が10cmほど遠くなりました。たったそれだけのことだけど老眼に優しい。 

togetter.com

よろこんでいたのも束の間、この配置で使い続けていると手元に窮屈さを感じるようになります。机の奥行きが物理的に足りないんですね。長年愛用している白いスチール机を買い替える気はさらさらなかったのでMacBook Pro用のスタンドが欲しくなりました。

またちょうどこの頃、某オンラインイベントに登壇しDiscordとZoomとKeynoteを一度に使う体験をしました。Macbook Proの13インチのディスプレイでは土地が狭すぎる…。「Sidecar」を使えば手持ちのiPadMacBook Proのサブディスプレイになると教えてもらったのですが、わたしのこころは4Kモニタにありました。

support.apple.com

AmazonMacBook Pro用のスタンドと4Kモニタを調べたのですが、商品が多すぎて選べない。こういうときは知ってる人のPC環境を参考にしよう!ということで、櫻井さんちの作業環境を見たけどプロ仕様すぎて参考にならなかったです。一品一品がちゃんとしてて憧れる。

fjord.jp

MacBook Pro用のスタンド

Amazonのレビューを読んで良さそうなスタンドを「ほしい物リスト」に入れておいたら、池澤さんが贈ってくださいました。

とにかく頑丈でしっかりしたものが欲しかったので満足しています。デザインもシンプルで気に入ってます。高さや角度は変えられませんが問題なかったです。机の奥行き問題も解消し、ディスプレイの位置が高くなり身体的にずいぶん楽になりました。これまでと比べて眼球の移動量が減り、それに伴い頭部や頸部への負担も軽減されたのではないでしょうか。

27インチの4Kモニタ 

EIZOのモニタは高級すぎるのでそれよりは低価格でまあまあ良いやつはどれか?と @m_seki(以降、プロの無職)に相談したらLGの新型と旧型をおすすめされました。旧型にしました。プロの無職と同じものを買っておけば、何か困ったことがあってもサポートしてもらえるからです。

モニタとしての基本的な性能については何も問題ありません。素晴らしいです。特筆すべきはこのモニタ、給電サポート付きなんですよ。付属のUSB Type-CケーブルでモニタとつないでおくだけでMacBook Proがいつも充電100%になってるの。メニューバーのバッテリーアイコンを見て残量何%だとか、もうすぐ赤くなるかなとか、そろそろ充電しなきゃとか考えなくていいのが本当に楽です。変化を監視して行動を変えていくの、自分が思ってる以上にストレスかかっているんだな。

在宅勤務のときはDynabookを付属のDisplayPortケーブルでつないで使っています。快適です。

USBコンデンサーマイク

これまではiPhoneについてきたおまけのイヤホンを使っていたのですが、オンラインでのコミュニケーションは音声品質がとても大事!と実感し、某シンポジウムの参加に合わせて購入しました。自分で自分の声を聴くことはできないのだけど、何名かの方から「とてもクリアに聴こえましたよ」と教えてもらって満足しています。というか、この商品がどうやって選ばれたのかを遡ると酒匂さんのYetiに行き着くので間違えようがないのだけど。

本題とは関係ないけど、酒匂さんが翻訳した本で所有しているものを貼っておこう。 

Apple AirPods Pro

Yetiのマイクと同時にイヤホンも買いました。プロの無職にAirPodsをおすすめされて他のイヤホンを調べるのが面倒だったので「じゃあそれでいいわ」と秒でProを買ったら泣いてました。

Apple AirPods Pro

Apple AirPods Pro

  • 発売日: 2019/10/30
  • メディア: エレクトロニクス
 

Apple Magic Trackpad 2

MacBook Proをスタンドに乗せたので、地上(机上)ではMagic KeyboardとMagic Mouseを使っていました。 

ツイートによると2011年7月にMagic Mouseを購入したようです。当時マインドマップ(XMindだったかな)を描くのにトラックパッドだと操作しづらくて買い求めたと記憶してますが、結局あまり使いませんでした。ようやく日の目を見ることになったMagic Mouseですが、あれから10年くらいの月日が流れ、今度はわたしがトラックパッドの操作に慣れすぎてしまってMagic Mouseが使いづらい事態に…。今回Magic Trackpadを購入したことで、Magic Mouseは再びお蔵入りとなってしまいました。

Magic Trackpad、めっちゃいいです。MacBook Proについてるトラックパッドよりひとまわり大きく、角度(傾き具合)が絶妙で使いやすい。押し込だときの感触も好き。最高。

Apple Magic Trackpad 2 - シルバー

Apple Magic Trackpad 2 - シルバー

  • 発売日: 2015/10/14
  • メディア: Personal Computers
 

クリップライト

2台購入しました。机の両端に1台ずつ置いてあります。使う機会はほとんどありませんが、オンラインで顔出しするときは「3段階調色/10段階調光」で最高に明るくして、気になるところを全部飛ばしてやろうと思っています。

アルミ製のiPad用スタンド

iPad用スタンドは必要に迫られてというよりは、配置してみたくて購入しました。左側にMacBook Proのスタンド、真ん中に4Kモニタ、右側にiPadのスタンドがあると見た目のバランスがよく収まりがいい感じしませんか?

iPad用スタンドはある程度自由に角度を調節できるものが欲しかったのでこれにしました。ぐらつきもなく安定しています。折りたためないタイプです。

iPadの主な用途は読書です。後述するBluetoothスピーカーとつないで音楽プレーヤーとしても使い始めました。Apple Pancilでアイデアをメモしたり、気軽に持ち運べてインターネットできるのが良いです。それだとスマートフォンと変わらないのでは?と思うかもしれないけど、大きな画面で見れるのはぜんぜんちがうんですよ…。

iPadApple Pencilは昨年のクリスマスシーズンに自分へのプレゼントとして買いました。

ケーブル収納ボックス

それまであまり気にならなかった机の上のケーブル類が目につくようになりました。ずっと前からぐちゃぐちゃだったのに面白いよね。このケーブルたちをどうしたらいいものか?とインターネットで調べて見つけた記事がこれです。

note.com

このデスクをすっきりさせるマガジンに載ってるデスク環境は全部読みました。テーマや求めるものはみなさん違いますが、理想のデスク環境に近づけるための思いと工夫と努力と1mmたりとも妥協しないその姿勢が素晴らしい。だが、知っているぞ。そこは沼だ。

note.com

最高峰のケーブル隠しテクニックを目の当たりにして早いうちに諦めがつきました。諦めたというか見極めた。わたしにはケーブル収納ボックスくらいがちょうどいいな、と。

小さいサイズ(4個口電源タップ用)と大きいサイズ(6個口電源タップ用)があります。工夫すれば4個口用でもいけるかなと思ったのですが6個口用にしました。机の上に置いて使ってます。意外とかさばる4KモニタのAC-DCアダプタや太くて長い電源コードなども箱の中に入れてます。大きいサイズを購入してよかったです。サイドのスリットからLightningケーブル(0.9m)を出しておき、iPhoneAirPodsなど適宜充電しています。

電源タップ

いつ買ったのか覚えていないくらい前(おそらく15年以上前)の電源タップを使っていたのですが、よく見たらスイッチランプの光が点滅とまではいかないけど弱々しく揺れていることに気づきました。特に問題なく使えているのですが、古いタップだし漏電して火事にでもなったら大変だと思い、収納ボックスを買うついでに新調しました。収納ボックスと同じエレコム製です。

購入してからわかったことですが、スイッチランプの点滅はランプ自体の寿命が原因で起きているとのこと。コンセントの機能とは独立して動いているのでランプが点滅していてもコンセント側には影響はないみたい。(新調しなくてもよかったってこと)

絵 

那須の山奥にあるBar+Gallery 殻々工房で開催された佐藤陽香さんによる作品展で二点購入しました。朝、目覚めたときにこの絵が視界に入ってきたら気持ちいいだろうなと思って。

f:id:miwa719:20200724162213j:plain

「 窓を開けたら鳥の声が聞こえた。7 」

f:id:miwa719:20200724162148j:plain

「 薫風の庭で 1 」

Olasonic ハイレゾ対応高音質 Bluetoothスピーカー

数年前からBar+Gallery 殻々工房で展示、販売をしていてずっと気になっていた製品ですが(スピーカー持ってるしな…)と我慢していたのに、先日プロの無職が買ってしまい「すごくいいよ!」と自慢してきたのだ。

f:id:miwa719:20201228024534p:plain

ついカッとなって

www.olasonic.jp

現在、iPad + OlasonicでAmazon Music(無料お試し)を流してます。ジャズやピアノは生演奏を聴いてるみたい。臨場感ってこういうのを言うんだと思いました。音に奥行きを感じます。これまで聴こえなかった繊細な音色や響き、音にならない空気感や息遣いまでちゃんと聴こえる。すごくいいってわかるんだけどうまく説明できません。

さっき、スピーカー持ってるって書いたけど、これは15年前くらいにプロの無職が譲ってくれたONKYO WAVIO ル・シータ アンプ内蔵スピーカー 6W+6W GX-R3X(W) /プラチナホワイトなの。スピーカーもらっておいて新しいのなんて買えないよね。(買ったけど)

こちらは今も現役で4Kモニタにつないで使っています。普通によいです。スピーカーの側面についてるつまみでボリュームと低音が調節できるのが便利。

ホット脚入れヒータ

もうこれがないと冬場のデスクワークは無理だと思います。買ってよかった。 

小さな加湿器

適応畳数がプレハブ洋室で約3畳の小さな加湿器です。机のそばに置いて蒸気を感じながら作業したくて購入しました。小さくても約11時間連続加湿できます。夜、寝る前に給水タンクを満タンにしておけば朝まで使えます。タイマー機能はついてません。電源プラグをコンセントに差し込み、電源スイッチをONにすることで動き出します。運転時はリセットボタンのランプが点灯します。電源スイッチをOFFにすると停止します。

運転中にタンクの水がなくなったときどうなるか気になりますよね。実験しました。水がなくなるとリセットボタンのランプが消灯し、運転を停止しました。そう!電源スイッチがONの状態を保ったままちゃんと停止しました。期待どおりです。引き続き、給水したタンクを本体にセットしリセットボタンを押し込むと、ランプが点灯し運転を再開しました。よし!

基本動作の確認ができたので、次回はリセットボタンを押し込む前に電源スイッチをOFFにしておこうと思います。この操作手順は取扱説明書に載ってません。

アイリスオーヤマ 加湿器 加熱式加湿器 ピンク SHM-120R1-P

アイリスオーヤマ 加湿器 加熱式加湿器 ピンク SHM-120R1-P

  • 発売日: 2019/09/17
  • メディア: ホーム&キッチン
 

番外編

社内で『熊とワルツを リスクを愉しむプロジェクト管理』の読書会をすることになりました。参加者は全員紙の本を持っているのですが、プロジェクターに映すためのKindle版、iPadとプロジェクターをつなぐためのLightningケーブル、iPad用スタンドを買いました。 

Apple Lightning - Digital AVアダプタ 

Apple Lightning - Digital AVアダプタ

Apple Lightning - Digital AVアダプタ

  • 発売日: 2015/04/16
  • メディア: Personal Computers
 

プラスチック製のiPad用スタンド

読書会は週1回なのでスタンドを持ち運ぶことを考えて軽いもの(200g)を選びました。問題なく使えてます。自宅ではスマートフォン置きとしても使ってます。高さの調整は二段階、角度の調整はできません。厳選した機能で勝負してきたそんな製品です。こういうの好き。

 

無意識なテスト

ソフトウェアテストの小ネタ Advent Calendar 2020 - Qiita 11日目の記事です。

qiita.com

はじめに

私は医療機器(自社製品)の開発者です。開発の現場で感じるちょっとした違和感を大切にし次の行動に移るためのシグナルとして使う、そんなお話を2年前のソフトウェアテスト #2 Advent Calendar 2018 - Qiitaに投稿しました。『違和感のつかまえかた』は多くの方に読んでいただき、これがきっかけで登壇したりと印象深い記事のひとつになりました。今でも覚えているコメントがあります。


この人、無意識を使おうとしてる。

開発やテストで無意識を使おうとする意識は無かったのですが、そう言われてみればそうかもしれません。無意識が教えてくれることは意外に多くバグも出せます。何を言ってるのかわからないかもしれませんが、毎日のことなので偶然ではなさそうです。この記事では ”意識して触っているわけではないのにバグを出せてしまうテスト” を「無意識なテスト」と呼ぶことにして、この伝わりそうにない無意識なテストについて書いてみようと思います。

無意識:国語辞典的な意味

土曜日の午前中、愛車で近所のスーパーへ買い物に行くときに左折しなければならない道を直進してしまい、あわててUターンしました。なぜ直進したのかはすぐにわかりました。そう。平日の通勤経路が直進だったのです。会社に行こうなんてこれっぽっちも思ってなかったのに無意識に直進してしまいました。

む-いしき【無意識】

1. 意識がないこと。正気を失うこと。「無意識の状態が続く」

2. 自分のしていることに気づいてないこと、また、そのさま。「無意識に足が向く」

3. 精神分析学で、意識下の領域、種々の人間現象の背後にあって影響を与える混沌としたもの。催眠・自由連想・投影検査、麻酔などの薬物作用によってのみ表出が可能となる。潜在意識。

さすがに正気は失ってなかったので 1. ではありませんね。直進したその一瞬だけを切り取ると 2. の「自分のしていることに気づいてないこと」ですし、直進した=表出したのは 3. の「潜在意識のなせるわざ」とも言えそうです。無意識なテストも 2. または 3. に当てはまります。

無意識なテストの特徴

  • こんなことをしたらこういう問題が起きるかもしれないと狙いを定めてやるテストとはちがう(そういうテストは毎日やってるけどそれとはちがう)
  • 気がついたらやっていた
  • 頭で考えるというより身体が勝手に動いている
  • なぜそんなことをしたのか聞かれたら意図や理由を答えることができる
  • 当てずっぽうにやっているわけではなさそう
  • 思考のスピードに自分のテストが間に合ってないと感じる
  • 脳内に広がる情報量が多すぎて取りこぼしていると思う
  • 取りこぼさないように脳内に浮かんだことを言葉にしようとした瞬間に無意識なテストではなくなる
  • 脳内にあるのはこんなこと

企みや企てや期待する結果や期待しない結果や起きたら嫌なことや前にこんな問題があったとか昨日のプロダクトの様子とか同僚がこんなことを気にしていたとか処理は一瞬で終わるけど内部的にはこんな風に動いているはずだとか自分が作るとしたらどう作るかとかその作り方だとこんな風に間違えるかもしれないとか実装中に話題になったことやプログラマーの表情やチケットに書いてあった断片の文字やいま目の前で起きていることや指先から伝わってくる感触や視神経に残るコンマ何秒か前の残像(はあはあ)

  • QuestionとAnswerのセットが一瞬のうちに大量に処理されるイメージ
  • ものすごく繊細なときもあれば大胆なときもある
  • わずかな綻び(設計や実装が破綻する前触れのようなもの)を肌感覚や手触りで感知する
  • 出したバグをあとから思い返すとロジカルに見つけているのがわかる
  • 息を吸って吐くように自然にできる
  • 属人性が高い
  • プログラマーSさんの感想:"こわくて見てられない"
  • プログラマーFさんの感想:"落ち着きがない"

f:id:miwa719:20201210194446p:plain

バグの原因調査で動作ログからShiftキーを押していたことをプログラマーから告げられたときの私

なぜこんなことができるのか

私たちのチーム(以下、咳チーム*1)の製品開発のやりかた(チーム全体がひとつの生き物のように見えます。その生命体がやっていることすべて)に秘密があると思います。なぜなら咳チームにJoinする前は無意識なテストなんてできなかったし、第一そんなテストが有るなんて知らなかったから。ちょうどよい媒体がたまたま私だっただけで、無意識なテストは宿るべくして宿ったチームの成果物のようにも思えます。再現性のないおとぎ話のようですが、無意識(意識下)に強い影響を与えてそうな2つの習慣を紹介します。

1. どういう仕組みで動いているのか想像しながら触っている

ボタンを押すと画面が切り替わり○○が表示される、のような人間の目に見える変化だけでなく、たったそれだけのことを実現するためにソフトウェアがどういう仕組みで動いているのか想像しながら触っています。たとえばこんな感じです。

ボタンを押すということはどういうことか。どのイベント(MouseDown、MouseUpのような)に反応するのか。イベントを感知するプロセスと○○を取ってくるプロセスは同じなのか。○○はどこからどうやって選ばれ、どのようにしてデータを受け渡しているのか。その中間データはそのあとどうなるのか。受け取ったデータはそのまま使うのか、加工するのか。その時点ではたしかに存在してる○○を選ぼうとした直前に○○が消えていたらどうなるのか。画面の初期化はどのタイミングで行うのか。毎回やるのか。初期値はどこから持ってくるのか。画面のその位置に○○を表示すればいいことをプログラムはどうやって知るのか。

このように想像しながら触っていると「たったそれだけのこと」なんて思わなくなります。1秒で終わる処理がとてもとても長いものに感じます。ソフトウェアの隙間に気づき、試したいことがどんどん出てきます。画面を眺めているだけでは目に映らなかった問題や課題が見えてきます。新しい疑問がわいてきます。

どういう仕組みで動いているのかイメージできるようになると、自分の頭の中にピタゴラ装置NHKの番組『ピタゴラスイッチ』に登場するからくり装置)のようなものが組み上がってきます。実際のソフトウェアと同じかどうかはわかりませんが(たぶん違うがそのズレは悪いものではない)脳内でそのピタゴラ装置を動かしながらプロダクトを触ります。ときにはピタゴラ装置のある部分に障害物を置いてどう反応するのか観察します。プロダクトを動かしながら自分の理解をテストし続けるのです。

仕組みを知るにはどうしたらよいか

ソフトウェアがどういう仕組みで動いているかは、それを実装したプログラマーから教えてもらうのが一番良いです。またはその仕組みを知っている人。教えてもらうタイミングは何か不具合が見つかったときがおすすめです。"この状況でこんなことをするとこういう風におかしくなる" という物語を使って仕組みをトレースすると頭に入ってきやすいです。またこのときに仕組みの中のどこをどう直そうとしてるのかも併せて教えてもらうとよいでしょう。私は自分の頭の中にポンチ絵が描ければヨシ!(ひとまず理解できた)としています。不具合が直ってきたらどこをどうテストしようかな?と考えたり作戦を立てるときに、解像度が上がっているのを実感すると思います。

f:id:miwa719:20201210031531j:plain

100msecの間にソフトウェアの内部では何が起きているのか*2

2. 圧倒的な練習量

無意識なテストは身体的な反応(脊髄反射)に似ています。脳みそと感覚器を使って毎日プロダクトを触り続けていたら自然とそうなっていました。

私の1日(8時間勤務)の時間割りは、朝会と夕会で1時間半(内容は設計レビューのようなものです)、残りの時間はプロダクトを触ったり同僚のプログラマーやテスターと製品について具体的な話をしています。製品と向き合う時間の長さというよりはその時間をどう過ごしているかがポイントだと思いますが、仮にプロダクトを触る時間は1日1時間、残りの時間はずっと製品に関する会議をしていたとしたら無意識なテストは今も身についてないんじゃないかな。プロダクトの出来栄えや手触りや速度感を身体のすみずみまで染みわたらせるにはちょっと短いような気がします(個人の感想です)。

おわりに

意識して触っているわけではないのにバグを出せてしまう「無意識なテスト」について書きました。普段の開発では作戦としての無意識はありません。あてにしてないのでバグが出せたらラッキーくらいに思っています。無意識=気づかない、という側面もあるのでこわいですよね。

お客さまが想い描いている理想の世界や解決したい課題を自分たちの製品でどう表現するのか。ソフトウェアの仕組みを想像しながら動かし、お客さまが本当に望んでいるものは何かを問い続けています。このような毎日の営みが私たちのこころや身体となり、無意識の領域に働きかけるのでしょう。

鋭い読者は気づいたと思いますが、この記事を読んで無意識を意識してしまったら「無意識なテスト」になりません。私自身も今回これを書いたことで無意識に無意識を意識してしまいそうでちょっと後悔しています。

*1:世界一長生きのXPのチーム。@m_seki がプロの無職をロールプレイしている。

*2:話を聞いても複雑すぎて理解できないときもある。これはプロの無職に解説を求めて描いてもらったポンチ絵

N's YARD に行ってきた

那須の森の中にある奈良美智さんの私設アートスペース N's YARD に行ってきた。*1

f:id:miwa719:20201024144953j:plain

Thinking Time 2020 Yoshitomo Nara

展示室は room 0 から room 5 の6つ。room 0 には奈良さんの好きなレコードジャケットやミュージシャンの写真やオブジェが展示してあった。こういう音楽やモノたちに囲まれながら奈良さんは生活(創作)しているのね…。受付で展示マップを頂いたときに「room番号はゼロオリジンなのか。なんだかプログラマっぽいな」と思ったんだけど、room 1〜5 とは流れる空気がまったく違う(好きが溢れ出ている)から1ではなく0にしたのはそういうことなんだろう、と思うことにした。

f:id:miwa719:20201024144845j:plain

room 0

奈良さんの絵はなにかに不安や不満を抱いていて(でもそれらの想いを自分の言葉でうまいこと変換できない)どこか挑戦的でもある子供の表情が印象的で可愛い。君が何を想い何を考えているのか知りたいけど、何も聞かずにそっと見守ってあげたいとも思う。

f:id:miwa719:20201024150239j:plain

Tear 2019 Yoshitomo Nara

今回の展示作品の中で特に面白いなと思ったのは『旅する山子』。文字どおり『山子』が全国各地を旅する。room 2 には旅先でのスナップ写真がたくさん展示されていた。

f:id:miwa719:20201024145606j:plain

Traveling Yamako 2019 Yoshitomo Nara
f:id:miwa719:20201024145712j:plain
f:id:miwa719:20201024145727j:plain
f:id:miwa719:20201024145736j:plain
f:id:miwa719:20201024145815j:plain

 

単純だけど「背景を差し替えることができる」のが面白いのと、そこに吹いている風や湿度や匂いや音が『山子』がいることで、さらに色濃く感じられてすごい。あとぜんぶ同じはずの『山子』の表情が行く先々で違って見えるのが不思議。なんでそう見えるのか考えたんだけど、その背景から物語を(自分勝手に)作り『山子』に投影しているのかもって思った。キャンバスが段ボール(!)なのでいつでもどこにでも行ける自由な『山子』だけど、この作品から軽快さはそれほど感じられない。これを見た人のいろんな想いが『山子』に宿っているような気さえしてくる。

f:id:miwa719:20201024145552j:plain


他にも段ボールを使った作品があった。こちらのギターを弾く女の子なんかは目を細めながら見て「奈良さん amazon で何を買ったんだろう…」と下世話なことまで考えてしまった。

f:id:miwa719:20201024160605j:plain

Guitar girl 2020 Yoshitomo Nara

併設のショップでポストカード*2を1枚購入し、こならカフェで豆乳のカフェオレを飲みながら一休みしたあと、 room 0 からもう一巡した。今年制作した作品も置いてあったので定期的に入れ替わるのかな。次回は room 0 に展示してあった奈良さんの好きなレコードからプレイリストを作って、ロックやパンクを聴きながら鑑賞するのも良いかもしれない。*3

f:id:miwa719:20201024145906j:plain

Miss Forest/Thinker 2016 Yoshitomo Nara

www.nsyard.com

*1:撮影可能な展示品が多くてびっくりしました(フラッシュ使用と動画撮影は不可)。あとから写真を見て楽しむことができるから嬉しい。最近は日本でもそういう流れなの?

*2:娘ちゃんによく似ている女の子のポストカードを買いました。奈良さんの描く子供はどこか娘ちゃんに似ているんだよな。本人もそれは自覚していて彼女は数年前に青森県立美術館(奈良さんの常設展示がある)を訪ねている。

*3:奈良さんセレクトおすすめの3枚!みたいなの、どこかで紹介されてないかな

JaSST Online Bergamot に参加しました #JaSSTOnline

JaSST Online Bergamot に参加したので感想などをつらつらと

www.jasst.jp

セッション1「探索的テスト」

ゲストにnemorine氏をお招きし、事前に実施の様子を撮影して頂いた探索的テストの動画を視聴します。
視聴をしながら質問者が随時気になったところで動画を一時停止し、ゲストに対して質問を行い探索的テスト実施時の内容や当時の思考を深堀りします。
質問者は実行委員及び、参加申し込み時に質問者オプションを購入いただいた参加者になります。

これオンラインでどうやるんだろう?と想像できなかったのですが、面白そうなので「質問者オプション」を購入しました。セッションの雰囲気は『相席食堂』、質問者は千鳥のイメージです!とお聞きしたので、民間公式テレビポータル『ティーバー』をインストールしてさっそく視聴。なるほど。芸能人が全国各地でロケを行い、そのVTRを千鳥が鑑賞し、気になる点があれば手元の「ちょっと待てぃ!」ボタンを押してVTRを止め、ツッコミを入れながら見守る番組なんですね。*1

様式はなんとなくわかったものの「あの物理ボタンはどうするんだろう?」と疑問は残りました。当日は早押しボタンオンラインを使いました。世の中にはいろんなツールがあるんだなぁ。素晴らしい。

@nemorin さんが探索的テストしたテスト対象については、開催日の二日前に資料が公開されました。TwitterぽいWebアプリケーションです。株式会社LIFULLさん がテスト研修の際に利用しているサンプルアプリケーション(わざとバグが埋め込まれている)だとか。これまた素晴らしい。自分たちが開発してる製品(本物)でテストするのが一番いいと思うんだけど、本物だとちょうどいい感じのバグって出ないもんね。教えたいことを逆引きしてバグとして事前に仕込んでおいてそれをネタに幅広く解説したり、なんならソースコードを修正してうまく動くところまで確認できる。とても良い取り組みだと思いました。

参加するにあたってのモチベーション

  • テスターのあたまの中にあることを質問をとおしてあぶりだしてみたい(書籍や教科書には載っていないような何か)
  • 自分の開発(テスト)脳への刺激、エッセンス

@nemorin さんを同僚だと思って一緒に開発(テスト)する気持ちで参加しようと思いました。自分だけが気持ち良くなったらたぶん失敗で、これは普段の開発でも同じです。

今回のシンポジウムは開発(特にテスト)が好きな人や得意な人が参加するはずなので、探索的テストの様子を見ながら様々な視点や観点でバグを探すんだろうなと想像しました。実際そうでしたね。そこは参加者のみなさんにお任せすることにしました。すごく楽しそうだったけど我慢した!(はじめにそう決めておかないと絶対バグを見つけようとして本来やりたいことができないのがわかっていたから)

早押しボタンが反応しない

当日のお昼過ぎに早押しボタンのURLが公開され動作確認も済ませていたのですが、セッション中に早押しボタンを押しても「ピンポン♪」と鳴りません。連打とか長押しとかいろいろやってみたのですがいっこうに反応しない。そんなことはお構いなしに探索的テストの動画は進んでゆく…。

どうしたらいいのかわからなくて流れの遅かったzoomのチャットに助けを求めました。SafariじゃなくてChromeがいいかもとかiPhoneでやってみたらどうかとか「みわさんは口ピンポンでいいです」などなどアドバイスをいただきました。ライブ中に本当にすみません。結局iPhoneでやりましたがまた動かなくなってしまい口ピンポンも投入しました。他の質問者の方は問題なく動いていたようなのでわたしのブラウザ(Safari)の設定が気に入らなかったのかも。

自分たちの開発(テスト)とのちがい

開発の仕方が違えばテストのやり方も変わるので単純に比較はできないのですが、普段自分たちが当たり前にやっていることを差分として感じることができたのでメモしておきます。良い悪いの話ではありません。

一度にテストする範囲が広すぎる

今回1時間でTwitterぽいアプリケーション全体を触りましたが、自分たちの開発ではこういうのはないです。もし1時間しかないのだったらテスト範囲をもっと絞ります。製品を触りながらテストしていき、小さな綻び(違和感)を見つけたら、さらに深さ方向に探索していきます。バグを仕留めたら(こんなバグが見つかるならあっちも心配だ)といったん地上に出て水平方向や斜め方向に移動し関連性がありそうだと思う場所をさらに探索、といった感じです。いま目の前で起きていることを観察し、自分の脳内に蓄積されている情報を使い、都度判断しながら探索していく。こういった一連の流れは「探索的テスト」の醍醐味の一つなのではないかと思っています。*2

動画を見た参加者が「ああ、探索的テストって1時間であんな風にアプリケーション全体を草原を走るようにさらっとテストすればいいんだな」と誤解されないかヒヤヒヤしました。さらっと見えるかもしれないけど @nemorin さんがやってたのはそんなに簡単なことじゃないんだからな!

わりと仕様書を読み込んでテストしている

わたしたちのチームは朝会でチケットを音読します。チケットは仕様書(よりももっと詳細)でプログラマーやテスターと議論した内容とともに毎朝強制的に頭に入ってきます。

実際にテストをする前にもチケットを読み返して一度おさらいしてからはじめることが多いです。どのように動くのを期待している/期待していないがだいたい頭の中に入っていないとテストできないんですよ。うまく言えないけど自分が期待しているパフォーマンスでテストすることができません。たぶんテストしながら目の前で起きる一瞬一瞬の動きやふるまいを脳内にある期待値とコンペアしてるのだと思います。もちろん仕様書自体が間違っていることもありますし、これまでは正しい仕様だったけど今も正しいかは分からないし、自分の脳だってバグっているかもしれないので、疑うことは忘れてはいけませんが。

そういうわけで前述した内容とも関連しますが、アプリケーション全体の詳細な仕様を頭の中に全部入れるのは無理なので、テスト範囲をもっと絞るということになります。わからない部分はその都度仕様書を読めばいいのでは?と思うかもしれませんが、それだとやりたいテストとスピードがぜんぜん合いません。*3

「探索的テストする」って言ってない

今回のテーマは「探索的テスト」ですが、普段「探索的テストする」って言ってないなと思いました。それだけです。

OST: 探索的テストをやるタイミングについて

Open Space Technology で shiromoto さんのテーマ「探索的テストをやるタイミングはいつにしてますか?」に参加しました。この問いについてのわたしの答えは「いつもです」としか言いようがない。テスターもたぶんプログラマーも毎日やっているので感覚がおかしくなっているのかもしれないけど、探索的テストってそんなに特別なものではないと思っています。わたしたちのチームがレアケースすぎるのかな。もしかしたらテーマの捉え方が違うのかもしれないし(前半は離席していた)、探索的テストという用語の解釈がずれてる可能性もあるな。わたしがいつも毎日やっているのはTestingだしな。そんなことを考えていました。

OST: 探索的テストをどうやって勉強、指導するかについて

Open Space Technology で とろ さんのテーマ「探索的テスト、どうやって勉強しますか?どうやって指導しますか?」に参加しました。テスト対象(製品やサービス)ではなくテストそのもの(テクニック)を対象に話してみたいとのこと。わたしはこんなことから日々学んだり、テストの幅を広げています。

  • 同僚(テスターやプログラマー)との会話
  • テストしている同僚の横に座って見てる(気になったところは教えてもらう)
  • ペアテスト(プログラマーともやります)
  • テーマを決めてチケットシステムを全文検索し過去の開発や起きた問題を斜め読みしながら、これから起こりそうな嫌なことを妄想する(バグをとらえるための瞬発力を鍛える訓練だと思ってやってる)
  • 他チームの開発者との会話(開発の仕方や最近見つけた面白い不具合とその原因について教えっこする)
  • 同僚(凄腕テスターSさん)になりきってテストする
  • 若手開発者とテストに関する本を読む

miwa719.hatenablog.com

この読書会、週1回のペースでやっているのですが1年半も経つのにまだ読み終わってません。途中でHAYST本に寄り道したのもあるけど毎回脱線しながらじっくりやっています。本に書いてあることが呼び水となり、お互いの開発(若手開発者とは開発してる製品が違う)について話していることが多いです。*4

勤続年数的には指導する立場なのでしょうけど、まだまだ知らないこと、分からないことも多くいつも一緒に学んでいます。

この練習帳がなかったら、社内教育に対して暴言を吐いておしまいになっていたかもしれないので助かりました。

  • 『ソフトウェア技術者のためのバグ検出ドリル』を解く

miwa719.hatenablog.com

  • iOSアプリやAppleWatchアプリを作って遊ぶ(無限にテストできます)

このテーマだけで1本記事が書けそうだけど、これくらいでやめておこう。*5 

当日使用したマイク

これまではiPhoneについてきたおまけのイヤホンを使っていたのですが、オンラインでのコミュニケーションは音声品質がすごく大事!と実感することがありまして、今回のシンポジウムに合わせて購入しました。でも自分では自分の声を聴くことはできないのである。どうだったんだろうか。

もっといろいろあったような気がする。思い出したらまたあとで書きます(更新したらツイートします) 


 

*1:このとき視聴したのがショーガールのブリアナ・ギガンテさんが大阪府枚方市にあるテーマパーク(ひらかたパーク)で遊ぶ回でした。

*2:ケースバイケースですが、検出したバグの修正に影響しそうなところはもう触らないことが多いです(直した後にそこも含めてテストしようという思考に変わる)。どこら辺まで修正の影響が及ぶのか分からないときは「ここをテストしようと思っているけど、あのバグが直ってからのがよいか」をプログラマーに相談するときもあります。

*3:車の運転中にあることがしたくて取扱説明書を見てしまうと、それをしたかった時と場所と状況にはもういないイメージです。

*4:先週、最終章の第6章「多次元の品質」に入り、ようやく終わりが見えてきました。

*5:ここにあげたものの多くは手段であって、ここから具体的に何を学び、どうテストに活かすのかは書いてないのだった。

判断に迷うときは「NG」にする

普段、わたしが心がけていることの1つに『判断に迷うときは「NG」にする』があります。目の前のふるまいが正しいのか間違っているのか判断に迷うとき、いったん「NG」にしてチームのみんなに問うのです。*1

例えば「これまで何年間もそのテストはPassし続けてるけど、いま触ってみたらなんとなくおかしい感じがする(でもずっとPassしてるんだよな…)」とか「すこし気になるけど、こう動くのはおそらく正しいのだろうなぁ」とか「こんな操作、お客さまは絶対にしないのは自分でもわかってる。わかってるけどわかったうえでこんなにひどいことをしました、とプログラマーに告白するのはいささか気が引けるな(どうしよう)」のようなもの。頭の中に「おそらく」「きっと」「多分」「〜だろう」のような確実さの度合いをあらわす副詞が浮かんだら、正しいほうではなく間違っているほうに倒します。

また、判断に迷う以前の行動として「いま自分は間違っている理由ではなく正しい理由を探そうとしている」ことに気づいたら(ちょっと気をつけなさいよ)と自分に言い聞かせます。あとこれはわたしだけかもしれませんが、脳が疲れてくると「正しいことにしたい気持ち」が若干強くなるような気がするので、疲れを感じたら休むか、そのときはあえて判断しないようにしています。

今ではこうすることに慣れてしまったのですが、NGにしたものがNGでなかったとき(正しいふるまいだったとき*2)は、自分のせいでチームの人たちに迷惑をかけてしまった、みんなの貴重な時間を奪ってしまったと申し訳なく思う気持ちと、自分が無知であることをひけらかしてしまって恥ずかしい気持ちが入り混じりなんとも辛いんですよね。

でもこのときこそ自身の学習の絶好の機会でもあるし*3、あとから問題が発覚して「ああ、あのときのあれはやっぱり間違っていたんだ…」と思うよりずっといいです。

こうすることにしたきっかけはあれかな。数年前、隣のチームのテスターと一緒に(7、8名いた)より良いテストのやりかたについて座談会をしたときに、困っていることや悩みごとを話す中でみんなで決めたんです。判断に迷ったときは「NG」にしようって。

正しいかもしれないことをNGにするのは今でも躊躇するけど、こんな風に「きまり」になっているとぐじぐじしないで「きまりだから言うかー」と思えるのがよいです。気分的にとても楽。みんなで決めたいくつかの「きまり」は小さなカードに印刷して*4事務机の上に置きいつも視界に入るようにしています。

*1:同僚のテスターやプログラマーに話したり、Bugチケットをあげて全員に見てもらうこともあります。

*2:偽陽性とも言いますね

*3:同僚が提起したNGから学習することも多いです。そんなときは「わたしも知らなかったから勉強になったよー、ありがとう」と言います。自分も同僚にそう言われて救われたし、お礼を言ってもらえて嬉しかったから。

*4:パウチしてある。パウチ知らないか…

ふりだしに戻る

うちのチームのチケットには開発日記が書かれています。その日に起きたことやこれから試そうと思っていること、気になっている部分のコードの断片や「誰それがこう言ったから(仕方なく)こうした」など、内容はさまざまです。毎朝同じ時間に同じ場所でこれらをみんなで読み合わせ、質疑応答を繰り返していきます。わたしはそこで思いついたテストのアイデアを話しながら、ここに書いてない+αの情報を脳内に配線していきます。

プログラマーがコミットしたあと、わたしは新たな気持ちでこの開発日記を読み直し、そこでまたなんらかの着想を得ながらテストしています。さっきも書きましたが、開発日記には設計/実装中に起きたこと、やったことの全てが書いてあるわけではないので、朝会や普段の会話から知り得たことやそれまでの経験から行間を補完します。その結果、出力されたわたしの思考や行動やテストが明後日の方向に行ってしまうことがあるのです。

たとえば、人間がやる(手動)テストとしては相応しくない(うまく狙えたのかどうかはわからない)。そこを保証したいのならコードを見て理詰めでやるべきだ。あなたの心配しているそれはもっと上位の仕組みでカバーされている(しかも長い間問題なく動いていて「枯れて」いる)…とかね。「まあどうしてもやりたいならやってもいいけどバグは出ないと思うよ」と言われたりします。

疑ってもあまり意味がないことに時間とエネルギーはかけたくないので、どうにかしたいなと思うのですが、明後日の方向に行っているかどうかはその出力が表沙汰にならないとわからない。となれば出来るだけ早いうちに表面化すればよさそう。なんですが、明後日の方向に行ってしまったおかげで見つけることができた価値のある課題や問題もあるのですよね。これがわりと少なくなくて捨てがたい。よって「しばらくこのままでいいか!」となり、ふりだしに戻るのを何回も繰り返しています。*1

*1:うちのチームはソフトウェアのバグだけではなく人間の行動バグもかなり早いうちに検出していると思うのですが、自分の中で(ああこの30分はもったいなかったな、どうにかしたいな)という気持ちがこの記事の元になっています。

チームが「サイロ化」しないための仕掛け

テスターのくせに Janet Gregory さんと Lisa Crispin さんの書籍『Agile Testing』『More Agile Testing』を読まずに今日まできてしまったのですが、この二冊を凝縮(Condensed)した『Agile Testing Condensed』(日本語訳)くらいは目を通しておかないとね!ということで読みはじめました。

leanpub.com

この記事は本書に書かれていたある問題を取り出し、それに対してわたしたちのチームが普段やっていることをわたしの目線で紹介したものです。ツイートするには長いのでこちらに書きました。

チームが「サイロ化」する問題

複数のチームがすべて同じプロダクトで作業している大規模な組織でよく見られる問題の1つは、チームが「サイロ化」する傾向があることです。依存関係を解決するために他のチームと話すことを忘れています。(第3章:アジャイルにおけるテスト計画)

サイロ化とは:企業のある部門が、他の部門と情報共有や連携などをせずに独自(単独)に業務を遂行し、孤立してしまう状態のこと。

 

たしかにそうなりがちかもしれませんね。わたしたちが開発してるプロダクトもまあまあ大きいのですが、なるべくそうならないようにするためにいくつかの仕掛けがあります。仕掛けと言っても、普段なんとなくやり続けていることがサイロ化しないための行動やふるまいだったんだなと思うわけで、はじめに「仕掛け」があったわけではないのですけど。*1

以下に隣のチームとの仕掛けのいくつかを紹介します。隣のチームはプロダクトを構成するシステム(ソフトウェア)の構造的にもわりと近い存在です。それぞれのチームの規模は小学校の1、2クラスを想像してください。*2

毎朝10分、隣のチームと会話する

  • 毎朝10分(8:45〜8:55)同じ場所に集まり、話をしています。
  • 参加者:隣のチームリーダー(2名)、うちのチームリーダー、テスター(2名)、@m_seki(プロの無職)*3
  • 開発状況に合わせて期間限定で特定のプログラマーが参加することもあります。
  • 話す内容はいろいろ(一例)
    • 昨日見つけた問題についての補足(チームを超えてチケットをあげている)
    • チケットにあげてないが気になっていること、心配していることは何か
    • 昨日の話した問題や課題がどうなっているか(現在の状況を同期)
    • お互いのチームでホットな話題についての情報交換
    • 一緒にやってほしい、教えてほしい、助けてほしいことの軽い予約
    • いまはどこの何にどれくらいの割合で注力すべきか(複数バージョンを並行開発してるため日々の調整を大事にしている。スケジュールや各プロジェクトの状況や問題の種類や大きさやそれに対するインパクトは常に変わっていくので。)

10分しかないのでお互いのチームが関係しそうでより重要と思うことから話します。自ずとみんながそうなります。いつもだいたい時間切れで終わるのですが、たった10分でも得られる情報は多いです。多いというより中身が凝縮されている感じ。自分のチームしか見ていないと外側の小さな変化(のちに自分のチームやシステム全体に影響を及ぼす何か)に気づくのが遅れがちですが、そういうことにも気づきやすくなります。

ここで得たことを元に隣のチーム(システム、ソフトウェア)とのつなぎ目とその周辺に気を配りながら、同僚のテスターとその日のテストを柔軟に変えていきます。

隣のチームのチケットを覗く

お互いのチケットは別管理ですが誰でも自由に見ることや書くことができます。チケットはわたし(テスター)にとってはお宝みたいなもので、毎日読むのが日課になっています。

  • 毎朝10分の会話のあと、話題になったアイテムを索引にしてチケットを覗きにいきます。そこにはもうすこし詳しい内容(開発日記)が書かれています。読んで理解を深めたり、分からないことがあれば隣のチームの誰かに聞きに行きます。
  • 午前中のうちに現在のイテレーションのチケットを一通り目を通します。特に自分で見つけたバグについては注意深く読みます。バグの原因はなんだったのか、どのように直そうとしているのか、プログラマーはどのようなテストをするつもりなのか、スムーズに修正作業が進んでいるのかに興味があります。これらは修正後の確認で何を試したらよいかを考えたり、プログラマーに質問、相談するための材料になります。

チームの外側も気にしてテストする

自分のチームがいくらうまくできても製品としてダメなら全然ダメという意識が多分ものすごく強いです。境界値にバグが存在するのと同じようにチームとチームの境界にも問題が潜みがちで、より気づきにくい特徴があるように思います。そのことは経験的にわかっているので要件定義の段階からプロダクト全体として何がどう変わるのか、変わったら何が嬉しいのかをみんなが気にしていて、たびたび話題にもなります。

同様にテストも薄くなりがちなので自分のチームを超え隣のチームの範疇にガツガツ入りこんで積極的に触っています。このときに『毎朝10分、隣のチームと会話する』や『隣のチームのチケットを覗く』で得た知識やノウハウや人脈を使います。あまり変なふうに触らないで…と思っているプログラマーもいるようですが(実際にそう言われたことがあります)お客さまが変なふうに触るかもしれないので、気にしないようにしています。なお、チームの外側をテストするのはテスターだけではありません。プログラマーもテストしています。

問題を見つけたら隣のチームへ話しに行く

この見出しだけ読むとはじめに引用した部分「他のチームと話すことを忘れている」に対する仕掛けがこれか、、、となるのですが、何がなんでも伝えたい!と思うことがないから話すことを忘れてしまうのではないか(仮説)を提起しておきます。問題を見つけたらと書きましたが『チームの外側も気にしてテストする』ので問題が見つかるとも言えますね。結局のところすべての行動やふるまいは全部どこかでつながっていて、これらの仕掛けの何もかもが単に「サイロ化」を防ぐためだけでなく、製品開発におけるさまざまな課題や問題に対してじわじわと効いてくるのだと実感しています。

おまけ

わたしたちのチームのNGワードに「合意する」「共有する」があります。あとメールを出しておしまい(あとはずっと返事待ち)は喜ばれないふるまいです。*4

おわりに

チームが「サイロ化」する問題について、隣のチームとの具体的な仕掛けや行動やふるまいをわたしの目線で紹介しました。途中で、隣のチームのことを書いているのか、自分のチームのことを書いているのか分からなくなるときがあったので、混乱された方がいたかもしれません。それくらいチームとチームの境界が曖昧になっているのですが、今から5年前のことを思い起こすとチーム間の結びつきはずっと薄かったように思います。

書きそびれましたが『隣のチームとの夕会』もあります(週4回、30分/回)。とりあえずやればうまくいくというものでもないので、何か秘密があるのだろうなあ。同じチームの @m_seki@vestige_ に聞いたらまた違った視点での仕掛けが出てきそうです。もしかしたら『Agile Testing』や『More Agile Testing』にもサイロ化しないためのヒントやプラクティスが書いてあるのかもしれませんね。

nihonbuson.hatenadiary.jp

kawaguti.hateblo.jp

追記:チームとは何か

*1:そういう風に動くように仕掛けられていたのかもしれないとは思う。

*2:4、5人ではないし、2、300人でもない。

*3:個人名を書くわけにもいかないのでチームリーダーと書いておきますが、明示的なリーダーは多分いません。みんながそれぞれリーダー。テスターもリーダーだよ。

*4:@m_seki は一時期メールボックスを満杯にしてメールを受信できないようにしていた。