Nagoya.Testing #2 in Tokyo に参加してきた #NagoyaTesting

• 4月6日 Nagoya.Testing #2 in Tokyo(東京都)

(写真：当日会場に持ち込まれていた『テスト』関連書籍たち。)

先々月の2/26に、名古屋にて『テスト』に関する勉強会が行われておりました。この日その再演的なイベントが東京で開催されるという事で、(平日日中開催でしたが有休を取って)参加してきました。

そのイベントの名前は『Nagoya.Testing』。前回開催分の内容は以下の各種エントリをご覧下さい。

前回のおさらい

• 2月26日 Nagoya.Testing(愛知県)

• Nagoya.Testing #1 #NagoyaTesting - Togetter
• USTREAM: Nagoya.Testing: .

• Grailsとか勉強会、StartupGroovy、Nagoya.Testingを開催します。 #GrailsEtcStudy #StartupGroovy #NagoyaTesting - うさぎ組
• Nagoya.Testing に行ってきた #NagoyaTesting - 日々常々
• Nagoya.Testingに参加しました。 - プログラムはじめました。
• Nagoya.Testingに参加 #NagoyaTesting - pocketberserkerの爆走
• Nagoya.Tesing 参加してきた - ITとともに生きよう

そしてここからは今回の参戦メモ。

開催会場は株式会社VOYAGE GROUP AJITO＠神泉。VOYAGE GROUP様開催のイベントには過去何回か参加してましたが、この部屋開催での勉強課員参加は初めてでした。受付開始時刻の10:30頃には到着してましたが、その時点で半分位の参加者は既に来ていたように思います。

テストプロセス入門 (11:00 - 12:00)

• きょん＠うさみみモード(kyon_mm) 氏

当セッション直前には、『アイスブレイクタイム』として同じテーブルに座ったメンバー同士で自己紹介等を。

ちなみに当日の座席表はこんな感じです。勉強会界隈では主に＆前回のNagoya.Testingでもおれんじクローバー(TwitterID:@orange_clover)さんが座席表マスターとしてその名を轟かせておりますが、今回は出席されていないようなので試しに自分も作ってみました。Google Docsの"Drawing"を用いてますが、割と簡単に作る事が出来てました。

• Nagoya.Testing #2 in Tokyo 座席表 - Google Docs

話したテーマは以下の2点。

• 1.あなたは何で(どんな理由で)NagoyaTestingに参加したのか？
• 2.自分が何をしてるときが一番楽しい？

2つ目のテーマについては、前回名古屋編では『型を考えているときが一番楽しい』という人も居たそうです。さすが名古屋。

• 自己紹介
  • 24歳うさみみ系男子『うさみみかわいいよね』
  • SCMBC、近いうちに札幌でもやるらしい。

• 発表スライド：
  • The outlineoftestprocess
    • View more presentations from Kyon Mm

イベント当日、セッション終了後にスライドは挙げられていた＆自分の中で資料における単語レベルの理解なども不十分であるため、見出しレベルの記載のみに留めておきます。

イベント実施前にきょん君がブログでお勧めしていた書籍のうちの1冊『マインドマップから始めるソフトウェアテスト』を早速購入してみたので、当イベント参加における『次の一歩』はこの書籍を読み進め、理解を深める(自分の中で曖昧だった情報の整理整頓を行う)作業を行っていきたいと思います。

マインドマップから始めるソフトウェアテスト

• テストとは？
  • JSQTBの定義するテスト(Testing)
  • kyon_mm氏の定義するテスト
  • #なごやこわい の定義するテスト

• テストプロセスについて
  • テスト戦略策定(テスト計画)
    • テスト戦略手順
    • テスト戦略
      • テスト要求
      • テスト対象
      • テスト目的
    • テスト戦略：キーワード
      • ソフトウェアの品質特性
      • テストタイプ、テストカテゴリ
      • テストフレーム、テストアーキテクチャ
      • テスト技法、レビュー

• • テスト分析
    • テスト分析手順

• • テスト設計
    • テスト設計手順
    • テスト技法(テスト設計技法)
    • テスト設計：キーワード
      • テスト技法：同値分割、境界値分析、制御パスフロー、All-Pair法、状態遷移テスト、デシジョンテーブル、原因結果グラフ、リスクベースドテスト
      • 静的解析
      • 網羅基準

• • テスト実装
    • テスト実装手順

• • テスト実施/報告
    • テスト実施/報告手順

• まとめ
  • テストプロセスは長いと思われがちだけど、実際は良くやっている事を明確に定義付けたもの。
  • テスト自体がまだまだ未成熟な領域が広いので、違和感があるかも。
  • 一元的に正しいものは存在しない。

• 質疑応答
• Q.テスト戦略、どの辺で実施することを考えているか？
  • A：2つの面がある。
    • 戦略で、システムで必要なモノを全て考える（システムテスト〜単体）
    • また、システムテストでのみ…というばあいもある。(きょん君の考えるのは後者)
    • 完成させようとしているタイミングによる。大枠としては開発と並行してやるのがベスト
    • →基本・概要設計が終わる辺りのタイミング。
    • 一番大事。ベストなのは出来るだけ前(の段階)でやる。

• Q.仕様を明確にするためのテスト、何処に当てはまる？
  • 各フェーズのインプットがそれに当たる。

• Q.テストプロセスのフロー、気になる点2つ。(1).上から下へ手戻りが無い前提で話してるけど？ (2).設計がおかしいかどうかのチェックはどこで？
  • 変更可能性
  • テストプロセスをはっきりと打開する方法は今の所無い。でも頑張っている。
  • テストのマイルストーン
  • テスト実装まで進んでって、仕様が間違ってる事が発覚したら？
    • →いまのところ、無い。
    • →テストの中でバリデーションを取る。
    • トレーサビリティを取る。テストケースにIDを振る。どの仕様書のIDを元にやっているか。

• Q.トレーサビリティ、現実に管理することは難しいと思うけど…
  • 管理コストが非常に高いので厳密に出来てるところはあんまないんじゃないか

• Q.スプリントを止めるかどうかの判断
  • 仕様変更でスプリントを中断すべきかの判断
  • 実際やりきったときに、トレーサビリティが残っていれば次スプリントで判断を下す。

• Q.となるとある程度詳細な設計書がそれなりに出来てなければいけない前提？
  • JSQTBは全てをカバーしようとしている前提で。
  • ある時点で足りてないのであれば、掛け合っていき、自分達で作って行く。
  • 無いものはないよ、って言われたらそこはビジネスの話。
  • 非機能要件等も含めて言っている。

ハンズオン (トータル1時間×3回)

昼食後のハンズオンは、出されたお題について、戦略を立ててテストケースを作るまでのテストプロセスを4人1チームで行いました。

お題はこちら：【issue管理ツールの作成】。

• nagoya-testing-2/project_background.md at master · toshi-kawanishi/nagoya-testing-2

github上に記載された情報を参考に、諸々の作業を進めていきます。

画面仕様はこちら。(Google Docs)

• Nagoya.TestingDocument - Google Docs

機能リストはこちら。(Slideshare)

• function list
  • View more presentations from Kyon Mm

一緒にハンズオンワークショップを行った方々は私を含めてこちらの御三方。

• Shuji Watanabe (TwitterID:@shuji_w6e)さん
• ken okamoto (TwitterID:@k_0kamoto)さん
• skowata (TwitterID:@skowata)さん

計3つのスプリントで目標とされた各タスクは以下の通り。その時々で取ったメモやつぶやきなどを交えてメモ。

• 【Sprint0: プロジェクト開始テストチームのタスク: 全体戦略をたてる】
  • テスト戦略を考える　テスト要求分析
    • ビジネスの話
      • テスト対象プロダクトに焦点をアクセス
      • テスト目的に合致した戦略を。
    • まず、ビジネス側の話で【やりたい事】の話をしている
    • 制約の話はしてない。これから必要だけど。
    • スプリント内で検討したテストを入れるか、入れないか、というのが重要。
    • 考えておく事は勿論重要だし必要。
    • テストは出来るだけ広く、深く考える
    • その後に優先度、枝を落とすかどうか考える

• • レビューの後、模範解答の提示。

• ソフトウェア技法ドリルを参考に。

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

• 各種ツールの紹介
• 状態遷移表
  • astah*を使えば簡単に状態遷移表が作成される。
• 画像のメモ
  • 2スイッチ：QAはここまで網羅
  • 1スイッチ網羅
  • 0スイッチ：開発者はここまで網羅

• 【Sprint1: 実装完了テストチームのタスク: 全体戦略を見直す】

(以下はチームでの雑感。)

• • ユースケースとモックを渡して了承を得る、というのは最強
    • 模範解答：(チーム的には)目的はほぼ一致していた。
    • 100%幅広く全網羅するなら模範解答の方がベター？
    • 限られたリソースでタスクを消化するなら、ユースケースの方が好ましい。

(そして代表1チームによる発表。)

• (きょん君指摘)：+-付けたのが良い。自分は数字でやる（1,2,3...）
  • テスト分析レベルまではホワイトボードで可。必要に応じて文書化

• 【Sprint2: テスト開始テストチームのタスク: テスト実施】

自チームは戦略に基づいて作成したユースケースを元に、手分けしてテストケースなどを作成してました。

最後には全てのチームが簡単な成果報告発表を実施。

ちなみにうちのチーム、@shuji_w6e さんが当初からリードして頂いたお陰で、軸をぶれさす事も無く、作業もスムーズに行う事が出来ました。またチームとしても適宜疑問点や不安点を議論の場に挙げて、対応可能なものについては速やかに反映(※うちのチームは付箋や紙を使わず、Google Docsベースで作業を進めていた)し、単体テストケースまでそれなりのクオリティで作成出来ていたと思います。@shuji_w6e さん、@k_0kamotoさん、@skowataさん、ありがとうございました！

また、今回主催及び運営サイドでイベントを円滑に進められた(うさみみ装着者の)@kyon_mm君、@oota_kenさん、-@tosikawaさん、会場提供頂いたVOYAGE GROUP及び-@katzchangさん、当日イベントに参加された皆さん、ありがとうございました！

個人的にはこの『テスティング』という分野、社会人になりIT関係のお仕事を進めてきた上で『何となく』であったりこれまでの経験から来る『感覚的』な部分で進めてきていたり、力技の部分で乗り切ってきた部分が多かれ少なかれ(多分多い)あった部分でした。

その辺りを『戦略的に』見つめ直し、一定の基準で判断を下してテスト計画を進めていく…という作業は、あんま使わない筋肉を使った感が半端無かったです。新鮮ではありましたが、如何にこの分野についてそういう風に見つめてきてなかったか(個人の経験・資質のみでやってきたか)、って事でもありますけど。恥ずかしい限りです。^^;

主催者自らブログエントリで、今回の『テスティング』に関するオススメ書籍を挙げております。自分もこの辺りのポイントを抑えて今後の仕事に役立てるべく、まずは1冊目の『マインドマップ』の本から手を付けて(読み進めて)行こうと思います。

• ソフトウェアテストを勉強しはじめて10ヵ月でやったこと - うさぎ組

マインドマップから始めるソフトウェアテスト

はじめて学ぶソフトウェアのテスト技法

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

ソフトウェアテスト教科書 JSTQB Foundation 第3版

その他関連：

• 2012/04/06 Nagoya.Testing #2 in Tokyo #NagoyaTesting - Togetter

(P.S.)イベント終了後には参加者数人と新宿にてとんかつを食し、付近のルノアールで茶をしばく(a.k.a. 休憩し語らい合う)等しておりました。とんかつは超美味し！

• 豚珍館 とんちんかん - 新宿/とんかつ (食べログ)