1/16(水)は「あさこ姐さんにゆもつよメソッドを語る夕べ」に参加してきました。
会場は メソニック39MTビル 11F のイベントスペース。
目次
語る夕べ とは
ちょっと探してみたのですが、これだという記述を見つけられなかったので、リンクを貼っておきます。
今回のテーマもそうですが、過去のテーマなども見てみると、テスト管理や設計、分析などテストを中心とした範囲を学ぶことを目的とした勉強会のようです。 こういった勉強会は探してもあまり見つからないので、結構貴重な場なのではないかと思います。 結構頻度も高く月に何回か開かれている、というのも凄いと思います。 ここ最近の開催を見てみると月に3回から4回開かれていて、とても活発なコミュニティですね。
何故参加したか
あまりテスト管理について、現場での経験(まぁ、やらされたということですが)はあってもきちんと学んではいないので、そういう話が聞ければ良いなと思って参加しました。 テストについて語る会、面白そうじゃないですか。 ついでに言うと、僕はRedmine.Tokyoという勉強会によく参加するのですが、そこのRedmineエバンジェリストの会にも所属するあさこ(@acha_821)さんに語る、ということで参加したという理由もあります。 「が」ではなく「に」語るというのは一体。。。。（笑）
内容
テーマにある「ゆもつよメソッド」というのはこちらの資料に書かれているものです。
www.slideshare.net
作者の湯元さんの解説はこちら。
この「ゆもつよメソッド」について「本人とは関係なく勝手に」語り尽くすイベントとは凄いですよね。しかも2時間（笑）
これはつまり、予習が必要になるやつですね！
当日の様子
トゥギャられているので、そちらのリンクを貼っておきます。
「ゆもつよメソッド」について
語る夕べ、というコミュニティ名が表すとおり、基本的には話したい人が話したいことをしゃべる感じで、分からないことがあれば随時聞くようなスタイル。
テスト方法論などについてある程度の知識があれば凄く楽しいと思いますが、最初に参加者のレベル感を確認してから説明をしてもらえるのでテストについて詳しくない人でも楽しく聞けるのではないかと思います。僕もあまり詳しく知らないで参加したのですが、これまでなんとなくでやっていたことが整理されていくように感じて、とても勉強になったし、面白いなぁと思いました。
肝心の内容は資料に書かれているので公開されたらリンクを貼ります。
以下は聞いた内容のメモ。
テスト戦略を二人で盛り上がっても良いんだけど、それを他の人にオープンにしてもいいかな？と思って始めた。 話す人が話したいことをしゃべる。 聞く人を満足させようという意志はない。 テストカテゴリ テスト分析マトリックス(ピボットテーブル) テストマトリックス テストカテゴリ 飛び道具、必殺技 マインドマップを納品物としていた。 →納品物にならない 納品物にならないものを書くのか？ 多くの人が普通だと思わないものを取り入れるのは難しい 湯も強メソッドは組織に対する違和感が少ない ドキュメントフォーマット 論理的構造 テストカテゴリ 仕様項目特定パターン テスト分析マトリックス ドキュメントフォーマット テスト分析とテスト設計を1つのシートにまとめて書ける 複数の文書を作りがちだけど後で継続できない ドキュメント一つというのは評価が高い 組織標準を作る人達がコンサルのフィーを払う 現場は払わない。 テスト分析とテスト設計を一つにまとめられると言われるとみんな飛びつく その会社の標準にするかどうか キーファクターにするかどうか ドキュメントなど好きに書けばいいじゃん →実際にはそうでもない HAYST法の目的 市場に透過したときの不具合を減らしたい 際を狙うための道具立て 普通のバグを出したいという目的ではない 普通のバグ検出はきちんと開発プロセスを回して検出する それなりに動くものに対して適用するのがHAYST法 VSTeP法 複数のやり方を比較検討するためのプラットフォーム 合意形成の道具立て やりきった感を味わうための道具立て どこかのバグを見つけたいというよりは現場の知見を最大限に発揮してバグ検出をする。 バグを叩き出すのが目的 ゆもつよメソッドの作られた目的 テストチームのレベルを合わせること バグを叩き出すのが目的ではない 難しい用語を使ったりはできない。 レベルを上げたいのではなく揃えたい 成果物のレベル 粒度、ばらつきを抑えたい チームのレベルを合わせるためのテクニック ドキュメント 指定のドキュメントがある。ただしばらつきがある。 ゆもつよメソッドのプロセス プロセスとアクティビティ 計画 分析 設計 詳細設計 分析 テストタイプ テストカテゴリ 各アクティビティは２～４のタスクで構成されている 仕事をするときの要件定義が必要 ゆもつよマトリックスが有名 縦軸にフィーチャー、横軸にテストタイプを並べる ただしアクティビティの中にこのタスクはない。 何故か？ 検算だから テスト分析とテスト設計の違い 方法論によって微妙に区分けが違う ゆもつよメソッドでは テスト分析 テスト対象のフィーチャー →テスト条件を作成 テスト設計 テストケース ゆもつよメソッドでいうテストケース いわゆる大中小項目で分類したものではない パラメータと値でテストケースは生成される テストパラメータ 値 アクション 期待結果 ここで言うテストケースは値まで入っているレベル テスト条件はパラメータを出しておく？ そこは相手の会社によってゆらいでいる テストの世界では因子と水準が挙がっていることがテスト設計 どうテストするかはテスト詳細設計で書く テスト分析のアウトプット 仕様項目の特定と列挙 期待結果の特定と列挙 テストパラメータの列挙 ゆもつよメソッドではテスト条件とは言わない 仕様項目と期待結果 テスト設計のアウトプット VSTeP法でもパラメータと値がテスト項目のスタイル テスト標準が自社にある会社は少なそう テストにモデリングを導入するのはハードル高い モデリングなんていうと新人ぶち込めないじゃんとか言われる 普通。稟議書を書きやすい シンプル PFDで書かれているけど見にくいので直列に直した アクティビティを説明するのが普通だけどゆもつよメソッドでは概念と手法を先に説明する テスト条件にこだわりがある？ ゆもつよメソッドのテスト分析 テストタイプ 機能テスト、使用性テスト、回帰テストのように特定のテスト目的に焦点を当てている 確認したい品質とテスト対応を組み合わせている 品質特性とテストタイプは異なるもの 信頼性テストとテストタイプ 品質特性とテストタイプは多対多。よもつよメソッドでは一対多 テストタイプはプロジェクトのたびに１から作るものではない 標準があるから特定という言い方をする。 組織標準にあるものから選ぶ。 各組織にあるものを選択する。 ゆもつよメソッドの中にテストタイプを作るというタスクはない VSTePは毎回１から作る テスト目的に合わせてテストタイプを選ぶ 計画 テスト目的の設定 分析 テストタイプの特定 TISが公開したテスト種別＆テスト観点カタログを参照しても良い 親切じゃないけど説明はあるので使えないことはない ただし目的には合わない、物足りない事はあるかも 性能テストと負荷テストを区別していない組織も多い 組織によっては区別していないところもある 同時アクセスが少ない状態：性能テスト 同時アクセスがピーク時の性能要件：負荷テスト ピークを超えて同時アクセスをするとき：限界テスト テストタイプは組織によって違う可能性がある 固定で持ってしまうとうまくいかないこともある 様々な業種業態の組織を相手にする場合はテストタイプを固定にするとうまくいかない可能性があるけど、通常は固定でもそれほど問題にはならない。 どちらかといえば予め決めておいてそれを選択するという方法は効率的（リーズナブル） 場面によって使い分けが必要。 テストカテゴリ テストタイプと事象の間の距離がありすぎ 同義語なのでは？と混乱する テストしたいなにかを導くなにか テストケースを束ねたもの ゆもつよメソッドの中では区別する テストタイプは組織標準なので汎用的なもの テストカテゴリはプロジェクトに合わせたもの テストタイプとテスト条件の中間に位置づけられるもの フィーチャー フィーチャー一覧：テスト対象の網羅性を確保するために使用する一覧表 機能要件だけではなく非機能要件も含んだもの 一覧表を作るが、結局マトリックスのフィーチャーとして並ぶもの コンポーネント モジュール システム 第三者検証機関ではスコープを顧客と合意するための道具立てとして機能一覧を使う 機能仕様書の目次一覧と同じ事が多い これとフィーチャー一覧は違う 該当するテストレベルの粒度で機能を整理する 機能一覧をばらして再構成する必要がある →これはかなり難しい 機能一覧を再整理する 機能カテゴリ 機能一覧から生成する このやり方（変換ルール）はゆもつよメソッドでは語られない。難しい。 エンプラでは機能仕様書は書かない。 システムの機能が複数文書に点在して書かれていることがある テーブル仕様書の備考欄に書いてあったりする 点在している機能をひとまとめにすることがゆもつよメソッドのフィーチャー一覧 機能一覧をリファクタリング 論理的機能構造 処理がブラックボックスなので参照モデルを使っている 入力調整 変換 貯蔵 出力 サポート 相互作用 論理的機能構造はフィーチャー一つ一つに含まれる http://jasst.jp/symposium/jasst15tokyo/pdf/B2-3.pdf ソフトウェアの参照モデル VSMもよく使われる テストカテゴリ テスすべきフィーチャーを抜け漏れなく多面的に見るための概念 テストカテゴリを抽出するための取っ掛かり テストカテゴリはチームのみんなで合意を取る 成果物のレベルを合わせる テストカテゴリにいい塩梅に分類する 合意したけど難得してない、というケースもある 欠陥を出したいというところに重点をおいてない バグを出すのではなく仕様をうまく分類する何か。 知識からテストカテゴリを導出する テストカテゴリが抽出された後にどんな不具合が見つけられるか話し合う テストカテゴリ バックボーンが違うと話し合いで決めると言っても合わない 内部構造がイメージできないとうまくいかない ドメイン知識が必要になる どうやったら一般の人がテストカテゴリが出せるか？ テストケースをリバースエンジニアリングしないとわからないのでは？ テストケースから意図を想像で考えて、テスト観点っぽいものに割り当てる。 そうやって見るとテストカテゴリっぽいものを抽出できる そうやることで落とし所が見つかるかも。 １０００本ノックだと、研修には来なくなっちゃうかも。 意図がわからないと大変。 でもやるしかないかも。 １件１件全部リバースする必要はない テスト条件 テストの視点からみたテスト対象の仕様項目 開発者の仕様ではなくテストウェアの仕様 テスト条件とは「テスト対象が、〇〇の場合、〇〇すると、〇〇となる」 ゆもつよメソッドのテスト条件 フィーチャー テスト対象が 仕様項目 〇〇の場合 期待結果 〇〇となる データ入出力パターン ゆもつよメソッドでどういうバグが取れるのか分からない → データフロー テスト対象をどうみるか？ バグを見つけたいけど方法論を作れなかった。 相手に合わせて変えてしまうから 方法論にはできない 相手がどういうやり方で来るか固定できないから システムをどう見るかに依存する ・目的ー手段の階層構造または目的ー機能ー手段の階層構造で認識する ・機能の集合として認識する ←ゆもつよメソッドはこれ ・データの流れ、データの変換過程として認識する ・刺激ー反応モデルとして認識する ・状態の変化として認識する ・写像、関数として認識する ・論理の集合として認識する ・手順、手続き、イベントの連鎖として認識する ・静的な構造として認識する テスト対象を作った人がどういう立場かを見る やったほうが良いけど現場は端折る。 これが抜けにつながってバグが検出できる ゆもつよメソッドではバグを出すことができない。 → 目的はバグを出すことではなくレベルを合わせること バグを取るのはその後 テスト分析マトリックス 検算 ピボットテーブル そのあたりがテストされているかを俯瞰 巨大なフィーチャーのマトリックスに貼る → 全部埋めたくなる 全部埋めたらテストしなきゃいけなくなるけど、工数的に無理 数字を見て少ないところを補足するための方法 テスト分析対象を俯瞰 対象の俯瞰 工数見積 どうやって導入するか 大人数でやるのには向かない パートナーが居ると合わせるのは難しい
まとめ
内容を僕のような初心者にも分かりやすく説明したことで予定よりだいぶ時間がオーバーして21時半くらいまで延長になってしまいましたが、個人的にはとても勉強になりました。現場に居るとこういう勉強をする機会がないまま実務としてやらなければならないという場面が多かったので、もっと早く勉強をしておけばよかったと思うことしきり。また機会があれば参加したいと思います。
参加した皆さんがとても熱心に聞き入っていて、質問とそれに対する答えのやり取りもなるほどと思いながら聞くことが出来ました。
ありがとうございました！
