今日は、「アジャイルなテストの見積りと計画づくり」のワークショップへの参加。イベント案内はZusaarでのイベント案内を参考にして欲しい。また、ハッシュタグは、#NagoyaTesting。ハッシュタグを利用して当日も情報のやり取りをしているので、当日の資料や題材のWebプログラム、我々グループのテスト項目や発見したバグ一覧も辿って見ることができる。
案内を目にして、しばらく経ってから申し込んだせいか、補欠になってしまった。懇親会のビアアッシュに先に申込みする格好になった。結構その時は参加希望が多かった。ところが直前になってキャンセルがあり、繰り上がりで参加できることになった。
ただし、パソコン持参とのことで急遽使用できるように準備。最近ノートPCを使ってないせいか、セキュリティパッチやディスク容量が少なくなっていたので、それらの対応を行った。7日の夜から少しづつ準備しようとしたけど、ディスク容量が少ないことで、不要なアプリを消して少しセキュリティパッチを繰り返すやり方になった。
今朝の出発前でもセキュリティパッチが動いたせいか、シャットダウンに時間がかかってる。強制電源Offしてワークショップで起動しないのは避けたかったので、そのままバッグへ。当初が補欠だったこともあり、ちょっと慌ただしい朝での準備となった。
多少はヒントになるだろうと、「アジャイルな見積りと計画づくり」もカバンに入れた。結論から言えば、この本は今回は電車の中での予習としては役に立たなかったかな。やはりというと変だけど、アジャイルのしかもテストに関する実践主体のワークショップを前にパラパラ見るような本ではない。今回のワークショップがシステムテストなりブラックボックス系のテスト主体の話だろうとのことは分かっていたので、その視点での予習にはあまり役立たなかったという意味。「実践アジャイルテスト」はホワイトボックス系のテストの話だし、自分的に実践とも少しかけ離れている感じがしてるし、、、。皆も手探りのように思える。
ちなみに、電車の中で、お受験風の親子連れが乗り込んできて、なんか問答してる。それなりに大きな声だったので、そっちに気が行ってしまった。社会の工業地帯のお勉強だった。結構暗記してる子だったけど、佐世保で有名なのが“笹かまぼこ”との返答には苦笑。そんなこともあって、予習は実質ゼロ。
少し早めに会場の最寄り駅に着いたし小腹が空いていたので、丼屋へ行ってから会場に向かった。会場はオラクルさん。（オラクルさん、会場提供を含め色々ありがとうございました。）
本来は、Zusaarでのイベントでの自分の番号をメモしておくべきだったんだけど、繰り上がりだったこともあってよく読んでおらず番号の件で少しアタフタ。係の方で調べてくれたけど。ちなみに、プレートにはTwitterアカウント名などを記載。入門証というかQRコード書かれた紙をもらって、そちらでゲートイン。
テーブルについた後は、知った人にちょっと挨拶。それにしても、周りはほとんどMac。自分のPCは、Windowsで表カバーにアップルのカラーシールを貼っているもの。無線LAN使えるとのことだったけど、昨日のうちにｲｰモバイルを使えるようにしたのでそちらを利用した。（自宅での悪戦苦闘の末にｲｰモバイルはUSB接続にしたけど。）
11時からのスタート。セッションスタートの最初に、テーブル（グループ）内で自己紹介。自分を含めて、6名。Web系の人が多かったけど、組込みとか企画系が半分という感じ。自分は、この分類ではシステム絡みの組込みかな。全体的にも、テスト系（テストが主）の人は皆無との印象。運営サイドにテスト系の人がチラホラいたけど。
グループ内のアジャイル実践程度は、微妙にまちまちだったかな。どっちかというと暗中模索しながらやってる人が多いみたいなイメージだった。なお、この類で、趣味の話が出ると和みやすいというか、その後の作業がしやすいと実感した。趣味とその後の作業は直接関係しないけど、思考方法がある程度類推できるというか、、、｡
以下、自分の感想を踏まえて様子を記載する。（ワークショップでの講演なども良かったけど、ここでは多少批判めいた記述が多くなって済みません。まっ、自分を含めての今後の参考ということで。）
その後は主催者の説明が2時間ぐらい。13時になって昼食＆昼休みだった。タイムテーブルをちゃんと見てなかったし、弁当出るとは出ていたか？ 一瞬、それなら丼を食べなくても良かったかなと思ったけど、13時まで続いたから丼食べてて丁度良かった。
スライドは以前30分で講演したのを利用（？）したみたいだけど、2時間でも時間が足りない雰囲気だった。足りないというか、ネタ的に色んな事が含まれてて人によっては消化不良の部分もあったかも。というのも、ソフトウェアテストでのテストレベルやテストタイプ、ISO 9126とかリスクの事にも触れており、非常に幅広い内容。
主催者によるテスト実践の話が出て、具体的で良かったと思う。ソフト開発とは別にソフトウェアテストのタスクボードを用意して進捗管理を行う方法。組み合わせテストを事例としたテスト（タスク）見積りの話も出た。ちなみにテストの複雑度を1～80としてるとかで、個人的には細かすぎるとの印象。また、話にも出たが、プロダクトオーナーの役目や開発とテスト側のやり取りでの見直しなども発生するので、ターゲットとなるソフト種や組織体の雰囲気などによって採用しやすいかが決まるように思う。
（つまり、一般化しやすい／他で利用しやすいとは言えないと感じた。なお、どんなことでも当て嵌まる話として、一般化することよりも、良さそうとの意識があるなら各自が持ち帰ってどう自分の組織体に填め込むか考えれば良い。ただし今回の件は、プロダクトオーナーや開発とテストとがあまりに密でお互いにカバーし合う状況でないと、適応が難しそうだ。そんな組織体が少ないだろうという意味。）
昼食後＆昼休み後は、少しおさらいして実習へ。与えられたWebプログラムの仕様書というか概要を元に、グループでテスト計画書／テスト仕様書を作成するというもの。テスト計画書との話だったと思うけど、IEEE 829のような本来の計画書ではなくて、むしろテスト仕様書の作成だったようだ。（テスト仕様書というよりも、テストケースの集団の検討を意識しているようなので、テスト屋さんにはテストスイーツのような言葉の方が通じやすかったかも。もちろん、テスト屋さんは少なかったけど。）
Webプログラムは、作業（タスク）の追加とか変更、項目による並び替えなどが出来るもの。ただし、当初はドキュメントのみを見てテストケースを考え、テストケースを主催者・事務局に見せてOKをもらえたら、WebサービスのURLを教えてもらえるという方法。
我がグループは、最初リーダー的な人と進捗把握の人を決めた。まっ、アジャイル系とかファシリテーションの絡む実習とかでは良く行われるパターン。ただ、一応決めた（と思った）けど、明確なやり取りは無く、誰か（実質2人だったか）が残り時間を時々教えたり、リーダーはダイナミックに変わるようなイメージ。
で、ついグループ作業の最初の方で「テスト観点の説明もあったけど、テスト観点って分かりにくいんだよね～」と口火を切った。まっさらの状態でテスト項目を考えるということでは、かえってテスト観点は邪魔との考えによる。ただし形勢は不利で^.^;、2対4。4人でジャンケンをして、うち1人にこっちのサブグループに入ってもらった。
実習の前に、変更に強い／変更しやすいテスト仕様書とか、（途中からだったか）そのテストでどんなリスクが回避できるかはっきりさせた方が良いとのコメントがあった。帰宅時の電車で思ったことは後述するとして、リスクの検討は当面無視というか、シンプルなWebアプリなのでリスク検討はさほど重要でないと考えて作業した。
変更の事を言われたので、さらっと仕様を復唱して、どんな要望が出そうかを軽く検討。それで変化に強いテスト仕様にとも思ったけど、そもそも変更が具体的でなく検討も含めて我がサブグループは消化不良だったかな。（本件も思うところを後述。）
で、別のサブグループは、テスト項目をGoogleスプレッドに入れてた。こちらはポストイット。決めた時間後に「せぇの～」と見せ合いっこしたら、結構似てた。つい「あれっ、テスト観点を主体に考えると言ってたのに～」と言ってしまった。^.^; 逆に、その後は、こちらのテスト項目を追加したり、考えの相違を検討すれば良かったので作業は楽になった。GoogleスプレッドのURLをTwitterでつぶやいて、ハッシュタグ付けることで、他の人もそのスプレッドへアクセスするという方法。
実は、自分のPCではGoogleスプレッドがうまく見えなかった。ぎりぎり容量でIEは6のままにしてたせい。多少焦ったり、こんな事ならiPadを持ってきても良かったかなと思った。今回はネットサービスの利用だったので、iPadでも作業できたかなと感じた。（ただし、やはり文書作成というか文字入力や編集の手間の件があるから、iPadで実作業できたか不安だけど。）
グループ内で、変更に強くするにはとか、リスク軽減やテスト目的などを少しまとめて判定依頼へ。で判定結果は「検討不十分」。その時にリスク軽減などを言われたのかもしれないが、再検討。他に見積りなどもその時に言われたのだったか？
見積りに関しては、意見色々。そもそも積み上げ式で行くにしても、どんな技法使うかとか、それらの意見を集約させるかなども課題。プランニングポーカーみたいにしたらと（一応）言ってみたけど、反対も無かったし賛同も無し。優先順位の件とか色々用語は飛び交ったけど、うまく収束していかなかった。結局、今回の実習でテストに○○分が与えられるので、それでテストできそうかとか、それに間に合わそうとの話になった（ような、全員賛成でなかったけどその方向だった）ように感じた。
個人的には、アジャイルでのテストの見積りの話をするなら／それが重要とテスト派が言うのなら、そもそも従来のテストの人達の見積り手法を明示すべきと思う。アジャイル系というか開発系からすると、今回の簡易なWebサービス等で、テストに焦点を当てた見積りが必要か？？ 開発とテストを一緒に考えて、ストーリー／ストーリーポイントを考えるのが普通だと言える。メンバー全員がそうかは不明だけど、見積りに対して消極的だったのは、テストの（厳密な）見積りの必要性そのものが理解に苦しんだからかもしれない。
それでも、リスクの検討とかテスト目的とか、それっぽい見積り結果の言い方を用意して、2回目の判定へチャレンジ。（これも、グループ内には、まだ不十分との意見もあったり、駄目なら3度目にチャレンジで良いじゃないの意見もあり。）
結果的には、実習の時間のことや、主催者のチェック担当の人の関係も（他に温情も？）あって、Webサービスの実体のURLを教えてもらった。具体的には、ハッシュタグ付きの私宛のつぶやき。（ハッシュタグで他のメンバーもそのURLを知る方法。）
2回目の判定では、ユーザーシナリオが甘いとの指摘もあった。一応テスト一覧に書いてるつもりはあったけど、グループ内で再検討。実URLを教えてもらう前後だったと思うけど、そのあたりを追加／追記や明記する格好になったと思う。
で、実URLを利用してのテスト実施。効率よくするために、グループ内でどう作業するか議論。結局、元我々サブグループの方が機能（いくつかの画面）のテスト、別のサブグループがユーザーシナリオ系をテストすることにした。我々のグループも、画面で分けたり、同一画面のテストならテスト項目の上からの人と下からの人にした。で、バグをポストイットに書いてたけど、ある人がGoogleスプレッドに入力してくれて、そちらに清書をお願いする格好になった。（それも、ハッシュタグ付きでつぶやいて、皆で情報共有。）
なお、テストしようとしたら自分のPCのIEが古いせいか、画面乱れ。ある意味バグレポート1号。^.^; 結局自分自身はテストはできず、別の人と一緒に作業することになった。
先にバグレポートって書いたけど、使用環境が明示されてないので、バグと言えるか疑問ではあった。また色々操作してたら、そもそも仕様がおかしいよなというのもいくつか出てきた。画面遷移が不自然。それらも項目によっては要望と明記したりして、リストアップした。
一応、異常値とか複数人での同時操作などもテストした。変な文字列というか特殊コード、あるいはクロスサイトスクリプティングテスト入門編みたいなテストも行った。具体的には、（手っ取り早くできた）Tabコード入力。案の定というか、おかしな挙動を発見。
最後にGoogleスプレッドでのバグ一覧を元に、皆で議論。KPT（keep, problem, try）の整理も一緒にやったように思う。もしかしたらKPTの議論は、発表後だったかもしれないけど、、、。
なんかグループの2人間で多少意見の隔たりがあって突っ込んだ意見を言い合って、どうしたんだろうと思った時もあったけど余り気にしないことにした。個人的には悪くないグループ作業。個人的な結論（システムテストとしての合否）としては、社内向けならOKと思う旨は言った。もちろん負荷試験とか、ここでできないテストは別扱い。
で、テスト結果の発表は、我々のグループになってしまった。リーダ役の人が説明して、発表の指名時に自分の名前が呼ばれてしまったし、そのせいで前へ出たらコメントを求められたので、グループ内で意見統一できてはいないけど社内利用はOKに近いと述べた。
その後に総括的な話が出て、希望者はビアアッシュへ突入。
個人的には、アジャイルとの目線では、内容が細かすぎる点が多い気もしたが、実プログラムの仕様や挙動でテストする点は非常に良かった。机上で議論してても、得られることは少ない。特に実践で役立つことが少ない。頭でっかちになるだけのことが多い。その点、今回のワークショップは、メンバーとの議論を含めて、教科書に書いてないような次元での気づきがあった。また、今回の題材になかった事項で自分なりに考えがすっきりした事項もあって、ある意味感謝。
ビアアッシュでは、乾杯や歓談の後にLT（ライトニングトークス）とか個別に質問したり質問受けたり、、、。LTでは、プログラミング言語の堅めの話やメイド衣装の超軽めの話題まで多種。まっ、アジャイルなり若い人達のコミュニティ雰囲気ムンムン。面白かった。（コミュニティには、それそれで重宝する居酒屋とか度々登場する話題などがあり、知らないコミュニティのそれらを知ったりやり取りできるとの貴重。つうか、オラクルの人と少し話したけど、コミュニティの居酒屋＝実体験があると、対応なり目線が違うというのが今回の実感。まっ、人によってはたいしたこととは思わないだろうけど。）
で、歓談という状況だったので、お礼を軽く述べて、ストレートに以下を述べたりした｡
１）やっぱテスト観点は分かりにくかった。
今回のメンバーや開発系の人が多いと、テスト業界的に代表的なテスト観点をいくつか述べて、このどれかで良いので考えてみてください位が良かったかと思う。ISO 9126も一つのテスト観点だろうけど、今回のような実習でほんとに役立つかは別。
さらに言えば、そもそもテスト観点って何？みたいな基本的なことを述べないと理解は難しいかもと。（と言いつつ、自分自身もうまく理解できてないというか、どうも役立つなりツールや手法に思えなかった。あくまで、すんなり自分なりの手法として役立てようという気になってないという意味。そうでないと、他の手法などもそうだけど、応用が効かないというのが持論。ただし、帰りの電車で、テスト観点に関して「そうか～」とのアイデアも出たので、掘り下げて考えるきっかけになったのは良かった。）
２）テストケースを、ばっさり削る話しもしないと、、、。
色んなテスト関連用語が出て”漏れなく”などの用語も飛び出したけど、今回のテーマのアジャイルにテストする／アジャイルなテストをするという感覚と矛盾すると言える。テストケースを削る話しもないと、なんか従来のテストの話と同じになって、聞いててメリットがなんだったか分からなくなると言える。
もちろん反論はあるだろうけど、アジャイラーの人達が本当に”漏れなく”と言われて納得するか疑問。 逆に、”漏れなく”派とそう考えないメンバーとで、（バグ発見率などを）比較するなども面白いと考える。
もちろんテストケース以外に、テストフェーズのどこかなりテストフェーズの作業／負荷分布を見直す意見を言うなどもこれに関する事項である。
他に、他グループがどれくらいバグ発見したか聞いてみたけど、一応我々の発見件数は悪くない感じだった。グループ内の話の際に、ビアアッシュで他のチームのバグ発見件数も聞いてみますねと言って、一部からは否定的な発言もあったけど。ただし、主催者側では、わざとバグを入れてたとのこと。いわゆるエラーシーディング。それは発見できなかったとのことだった。ちょっと残念。やっぱそれなりの準備をしてたんだと内心感心もした。なお、残念って書いたけど、見つからなかったことと”漏れなく”への否定的な意見とは別。どんなバグが仕組まれていたかにも依存すると言える。
（ビアアッシュなので、意見交換すると実は、、、との話もあって、自分も含めて皆さん悩んでること少なくないんだな～とは実感した。これも有意義だった理由。）
なお、LTの最後というか占めに近いところでは、テストクラスの話が出た。テストクラスと表現すべきかは？？だけど。 少し酔ってきたこともあって、途中から席に座ってボーッと聞いていたけど、テストクラスの継承みたいなのをどう実装するかの話のように受け取った。そうであればニーズは分からなくはないけど、ツールに実装できても、（特にテスト系メンバーの）誰が使いこなすかも気になるところだった。まっ、本件はこっちの勘違いかもしれないので、深掘りなども当面先／実質やらないかな。
楽しい時間があっと過ぎて、お礼とか述べて解散。いやー良かった。
帰りの電車の中で、ボーッとしながら考えたのが2つ。
１）仕様追加に強いテスト計画／テスト仕様
実習の時は言ってることが理解できなかったけど、イテレーション（スプリント）への対応のことを言ってるとしたら非常に納得がいった。そうであれば、（時間の制約を除けば）演習の際に、例えば全部が3イテレーションで、第2イテレーションと第3イテレーションのテストをするようにすれば良かったかと思う。
で、仕様追加とかの表現ではなく、イテレーション（スプリント）への対応と言ってもらった方がすっきりしたと思う。演習時に仕様追加ではなく機能追加などの表現だったかも？だけど、少なくともイテレーションを意識して欲しいとの話で良かったと思う。例えば、第3イテレーションで実装されるのは、タスク情報の変更（画面追加）とかにすればいい。あくまで、イテレーション対応のことを言おうとしてたのなら。
さらに言えば、自分の中でテスト観点中心でのテスト設計が嫌なのは、これに脆いと思ってるからだろう。誰が考えても、イテレーションで追加されてくのは（ほぼ）機能。であれば、テスト区分のような事項は機能であるべきだ｡少なくとも、その方がイテレーションへの対応が楽だ。
２）リスクと説明責任
演習の際に、テストでどんなリスクが低減できるか示した方が良いとの話が出たと思った。また、テストには説明責任が伴うとの話しも。ここも自分的にはすっきりしない。各テストケースでリスクを考えるのはおかしい。むしろIEEE 829の言うテスト計画書で、よりテスト全般とかその関連として明確にすべき事項である。
今回の実習のようなケースだと、「全体的なテスト計画ではリスクの検討とか説明責任に言及しますが、今回はテストケース検討なので、考えなくても良いです。（興味あれば検討してみてください。）」 みたいな表現が良かったように思う。
テスト全体とか計画レベルでリスクや説明責任を考えるのは必要だろうけど、今回の勉強はそっちではないと言える。
テスト計画なども実習での検討範疇との考えもあるだろうけど、今回のようなワークショップだとむしろ上で書いたような複数イテレーションへの対応などに時間を割いた方がメリットあると考える。
なお、上で書いた2つは、自分なりにもっと掘り下げた方が良いし、ちょっとした思いつきも出た。その意味では、実習やそれに対する（上の意見だと少し過剰とも映る）コメントも、考えるヒントになってむしろありがたかった。
色々書いたけど、実習を伴った有意義な1日だった。もし次回に同類のイベントがあるのなら是非参加したいと思う。
追記：後になって、今回のイベントの運営として、ドタキャンが多かった事が書かれたブログを見つけた。こちらは補欠から繰り上がってラッキーだったけど、運営する側からは弁当などのこともあり収支に直結する問題。勉強会のことが雑誌などで取り上げられてるけど、そんな苦労もあるとか、どう改善すべき／してるかの情報共有も必要になってるんだと実感した。
