遅れましたが、”とちぎテストの会議03“と呼ばれる、イベントに参加してきたので、そのレポートを残しておこうと思います。
既に公開されているサイトもありましたので、リンクを張り。
とてか03は、隔年くらいで開催されている、開発とテストが融合して色々な議論を行える場所のようです。私が社会人になったのが2011年4月なので、まだ学生の頃に1度目が行われ、社会人2年目となりいろいろ基礎的な学びを得ている間に2度目が行われたわけですね。
きっかけは、とてか03の募集が開始されたときにふとみて面白そうだったこと、今の上長から開催少し前に友人らが主催しているので行ってみたら？と後押しされたこと、でした。
基調講演
「いかす!」のために大事だと思う４つのこと
湯本 剛 氏
所属: 日本ヒューレットパッカード株式会社
経歴: 最初は、製造メーカにて生産管理システムの構築メンバー、その後、ソフトハウスにてテストリーダとして数多くのアプリケーションの開発に携わる。そして、ソフトウェアテストのコンサルタントになり、10年以上。テストプロセスの改善コンサル、テストツールの導入支援、テストの教育などしている。
資料は以下に添付する通りです。まとめると、以下の4つがキーワードになります。
- 定期的なトライ
- 人の知見吸収
- 目的再考
- 無駄やめる
具体的なテストの話しよりは、全体的な話しがここでは多かったように思えます。
ちなみに、 http://www.tmap.net/en/tpi-next の翻訳も行われているとのこと。活動範囲が広い・・・
感想
何事もそうなのですが、目的再考は大事ですね。手段と目的を違えないことは理解しつつも、よくやってしまうことです。
無駄を止めるということは、リーン開発がソフトウェアサービス産業に取り入れられて、開発体制含め色々な所で速度を求められている今の時代には、実は非常に価値のある要素だったのではないでしょうか。何か改善するにも、それは開発の一連の流れに無駄無く統合されることで価値あるものになるように。
招待講演
招待講演の方は以下。sekiさんが命名した忍者式テストを実際に行ったときの体験談をお話ししていました。
「忍者式テストをやってみた」
中島 滋 氏
所属: 株式会社ラグザイア
経歴: 通信系中規模SIerにて大人数受託開発を経験。現職にて、受託開発でのアジャイルソフトウェア開発に挑戦。主にC#・ASP.NETを使った業務用Webアプリケーション開発に携わる。現在はJavaScriptを使ったブラウザアプリケーションを開発中。
発表概要: 2004年に関 将俊さんが発表された忍者式テストから10年、ようやく今年、実行できました。この講演では、世界で二番目の忍者式テストの実施例をご報告をさせていただきます。
忍者式テストは、日々増えるテスト、日々感性するストーリ、修正された不具合の確認、それでも変更を迅速に、安全にするためのテストの考え方です。
あたりが公になっている資料でしょうか。
中でも大事なのは、 日々テストすること 、 柱となるシナリオや操作を定め、適度に変異させてテストをすること、 だと感じました。
実際に行われているテストは以下のwikiにまとめられているもののようです。
https://github.com/pubannotation/textae/wiki/userAcceptanceTest
他、レガシーコードのJSをMVCやMVPのような形式に整えていくなどを合わせて話していました。
- http://ledsun.hatenablog.com/entry/2014/06/06/140730
- https://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
- http://c2.com/cgi/wiki?ModelViewPresenter
感想
ここで行われているテストって、探索的テストの色もありそうですね。日々、1時間程度でもテストを実施する時間を設ける、変更に対して正しいかをCheckingする、不具合が埋め込まれていないかをTestingする。そういう流れが現実的な形で作られていそう。
今、私はモバイルアプリのテストに関わることが多いのですが、大きなテストシナリオを用意し、変異できる箇所を変異させてテストケースに落とし込んでいく、という落とし込み方を社内のディレクターの方々に広めています。その利点は、大枠として何をしているのかを残しつつも、細かなところでは仕様に沿ってるかを確認するために落とし込んでいけること。そして、基本はCheckingを重視しつつも、要所ではTestingの要素を組み込めるところでしょうか。
たぶん、TurnipやFitNessを使って自然言語をベースにテストケースを書くことを経験した人だと、変更に強いテストケースを意識すると同じような形に落ち着きそうな形だと思います。（ここらへん、もう少し社内の資料を整理しないとな・・・）
そういえば、こういうテストケースの作り方って、思いのほか興味持っている方々多い？（共有チャンス！？）
イカついパネル
以下ついは、いかしたテストのツイートを題材に、その場で議論を行うというものです。
http://d.hatena.ne.jp/m_seki/20140930#1412073967
なるほどな、と思ったものを1つ。
“@miwa719酒匂さん「検出できるモレもありますよね」て言っててスッキリした。(略)検出できるモレは検出してるでしょ。そうじゃなくて、わたしが、あなたが検出したいモレは検出できないの。だから「モレは何をやっても検出できません」て言ったんだなーて。” #toteka_ikasu
=> 考慮漏れを減らすためにレビューやテスト技法があるわけですが、それらを駆使して出し切ったあとにモレがあることをそのときは判断しようが無いので、モレは検出できないといっている、少し頭がこんがらがるけれど、認識論的な話しで正しいな〜と思いました。
テストの話しを混ぜると、この検出されない要素を減らしていくために、テストを設計したり、そこからテストケースに落とし込んでいったりするのかなと思いますね。
ワールドカフェ
とてか03当日にタイマーが使われたのですが、そのタイマーに対して本番2日前に変更を加えて動かなくなった。あなたならどうする？というお題のもと、ワールドカフェ形式で議論を深めました。
分析からちゃんと行うところ、優先度付けをつけ、そこから着想を広げるところなど、いろいろあって面白かった。
懇親会
懇親会が終わるころ、弊社バックを配りました。
最後に
栃木、仙台といろいろイカした活動多くて面白そうでした。確かに情報は東京のほうが多い気はしますが、より現実的に試行錯誤している人と触れ合う機会って、近郊のほうが多いのかな。
またあちら方面でテストやテストよりの開発の話しが出たときは足を運びたいなと思いました。その前に、まずはいくつか積まれているタスクをこなさないと行けないなと思う今日でした。
※JaSST 15 Tokyo、気づいたら論文の申し込み終わってて残念だったのですが、 第2回 日本Seleniumユーザーコミュニティ勉強会 でモバイルアプリのテストに関してお話しさせていただくことになりました。足を運ばれる方はよろしくお願いします！
~ my tech diary ~ 