ソフトウェアテストのこと。テスト設計コンテストのアレ#1

ニーハイの　増える季節だ　ひゃっほほほ(五・七・五)。

ども。コヤマンどぇす。

自動化カンファレンスをやってきた記事を書いたばかりですが

その前の日にアテクシ「テスト設計コンテスト」というのに参加をしてきました。

…んでまぁ恥ずかしながら豪快に惨敗してきたワケですｗ

そこで負けた理由を審査員の皆様に聞いたところ

「見通しが悪い」ということだったので、まぁ納得[*1]をしまして。

そもそもの成果物の作りの悪さみたいなところもあり

意図がわかりにくいところもあり。

そういえば、自分で作った「テストの全体像」について

なんで「テストの全体像の構成がそういう構成なのか？」という前提部分を

すっかり書いてないことに気付いたわけです。

その前提と成果物を15分で説明するのは困難だったために削ったわけですが、

そこはシンプルに言葉にできてない自分の技量の低さ(か、頭の悪さｗ)で仕方ないとして、

まぁ負けたことだし丁度いいや、と思い前提の考え方の部分を含めて、

少しずつブログで出して行こうかと考えました。

で、その前にどんな内容の作業をしたか、を書いておく。

※どこまで資料公開して良いのかよくわからないので、ひとまずスライド公開は保留。

◆テスト設計コンテストで実施したこと

・テスト対象分析

・マーケット分析＋セリングポイントの仮説立て

・ステークホルダ分析

・ユーザ行動モデルの作成

・テスト対象動作モデルの作成

・確認・要望リストの作成

・優先順位の定義

・テスト方針の作成

・スコープの定義

・全体像の作成＋SAL法[*2]によるテスト要件などの増加

・高位レベルテストケースの作成

◆テストアーキテクチャ（テスト全体の構造）

・全体像

◆全体像の構成

ビジネス実証要求＞システム実証要求＞テスト条件＞実証要求という構成。

　・メリット：

　　ビジネス実証要求に立脚してテストを考えるため、顧客価値に紐づいている。

　　ビジネス実証要求を意識するため、発散しにくい。

　　テストの意図が明確

　・デメリット：

　　俯瞰しにくい

　　頑張ると重い

◆◆本記事のテーマ

ステークホルダ分析とセリングポイントの仮説と、全体像の関係について

そもそも企画文書がないなど、色々と本来あるはずのものが無かったので

ある情報の中からフェルミ推定などをして色々と分析をしました。

その中でステークホルダ分析として作ったのがこちら。

この"輪"の構成は以下の領域からなっています。

「環境領域」、「ビジネス領域」、「システム領域」、「ソフトウェア領域」

ここからセリングポイントの仮説立てをして、全体像を作っているのですが

この領域を「テスト空間」と呼んでいます。

簡単に言うと「考えなければならない空間」というところでしょうか。

まぁ色々理由はあるのですがテスト空間とテストとテスト対象の関係について

まとめて全然公開してなかった資料をアップしたので以下を参考に。

外部論理と内部論理とテスト空間 from koyaman 2

かくして、この考え方をモトに全体像の構成が

ビジネス実証要求＞システム実証要求＞テスト条件＞実証要求という構成に。

つづく。(たぶん)

-----

*1.とはいえ一部納得いってないところもある。

　設計はシンプルにして少ない情報で意図が分かるのが良いと思っているので

　最終的な成果物としての高位レベルテストケースを3pにまとめた点は

　もう少し評価してもらっても良い気がするなぁ。とか。

*2.Struck A Lighting法。火打石法と名付けたコヤマンのテスト視点を増やす手法。
　テスト対象・テスト条件を[物]、テストの視点などを[心]、テスト要件(実証要件)を[事]と位置づけて

　物やら心やらを元にごにょごにょ考えるやり方。

テスト自動化カンファレンス開催してきた。

ども。コヤマンどぇす。

あんまり自分のキャラとリンクしないのですが

しんすくさんが主催しているテスト自動化研究会に

コミッターとして参加しています。

そこで、おーたさんを実行委員長とした催し

「テスト自動化カンファレンス2013」を開催してきました。

森さんの素晴らしい文章でまとめられた記事はこちら。

とはいえ自分の足元の自動化は全然進んでいない

（とゆーか社内ツールやらテスト管理だったりやらするので情報出しにくい）ので

研究会自体にはTABOKのまとめ以外、全然貢献できてないと思っていますが

そこそこのものが出来たら負けじと発信したいなぁ。

とはいえ自分のスキル不足が否めないので

自動化頑張ります。

※あるいはどうやって業務の自動化構成を考えて作っていくかあたりが

　持ちネタになるのかなぁ。

ではでは。

勝手にSaPID勉強会in町田の開催をお手伝いしました

ども。コヤマンどぇす。

ミッキーさん(@mkoszk)による「勝手にSaPID勉強会」について

町田での開催をお手伝いしました。

6/29(土)13:00〜　@町田市文化交流センター5F コスモス会議室

◆SaPIDとは

SaPIDの概要

HBA　安達賢二さんによる自律型プロセス改善の仕組みです。

システムアプローチをベースとした、当たり前のことを当たり前にやるためのスキームなのですが、とてもうまく出来ているので勉強したかったのです。

※安達さんとはソフトウェアテストワークショップWACATEなどで一緒にワークをお手伝いしたりなどのつながりがあったので、興味はひとしお。

※安達さんはADAMOSの管理者としてソフトウェア品質関連の技術者の中ではとっても有名な、とても穏やかな悪ノリ好きなおっちゃんですｗ

会社の仕事もプロセス改善のようなことをする機会が多いので、

これはやるべし！と主催側に手を挙げました。

◆やったこと

○会議室の確保

そーいや、町田で勉強会主催したことねーやってことで、町田で会議室を探しました。

民間ぽいとこでもたかだか３０分程度の口頭打ち合わせのために

わざわざ一旦直接行かなくてはならないあたり、さすが日本ｗって感じでしたが

特に問題もなく、会議室を確保しました。

※なお、町田文化交流センターさんは会議室としていいな、と素直に思いました。

○食事会の場所確保

お気に入りのお店を確保しました。

地中海料理コシード

ブイヤベースコース。

あの時間に終わるなら直接行っても大丈夫かなぁと思った。直接行けばコースでなくても…ニヤリ。

ちなみにマッシュルームセゴビア風とブイヤベースが美味しくて皆の会話が止まりましたｗ

○予習と宿題

予習としてはスライドや公開情報を読みました。

印象としては、オーソドックスな改善活動、という印象。

これがまぁ、当たり前にやるのが結構難しいんですよね。

また、宿題として「自分のプロジェクトにおける問題点の列挙」がありました。

これはさらさらと１１個くらい持っていきました。

○ミッキーさんによるワークショップ

ミッキーさん(@mkoszk)による秀逸な解説と

理解させるためのワークショップが行われました。

小道具としては模造紙(A2くらいのサイズ)とペン、付箋紙を持って行きました。

最初はほとんど解説でした。

◆わかったこと

ざざっと列挙。

・SaPIDはメンバー自身を進ませるスキーム

・その仕組みが秀逸！

・愚痴から事象への変換がキモ

・ひとまずスモールサクセスを経験させるフレーム

・フォームの変更など、すぐできるものを考えて実施して、改善を実感するのが重要

・自分がやっていた「問題を可視化して構造化し、改善をする」というのは悪くないスキームだったことがわかった。

・ただし、自分がやっていたものは「自らが進んで実践する」というスキームが無い

・ある程度サクセスを経験しているところには今現場に適用しているKWSの方がマッチングするかも知れないと思った。

◆次にやること

・自分のやっていることに自律型の考えを摘要してみる

・現在のKWSに自律の考え方を組み込めないか検証する

・参加できなかった秋山さんのために再度勝手にSaPID勉強会を開催する

◆その他

私もJSTQB講師などでお世話になっている日本科学技術連盟さまの方で安達さんが登壇されるようなので、興味のある方は是非。

【SQiP特別講演会ＩＩ】～日本発～自律型プロセス改善の新しい風を捉えよう！

ではでは。

Nagoya.Testing in Tokyo#3にTAで参加

ニーハイの　JK見たいが　目がかゆい。(五・七・五)

ども。コヤマンどぇす。

きょんくん(@kyon_mm)がJaSST'12 Tokaiで発表した
「アジャイルなテストの見積もりと計画作り」の発表内容をもとにNagoya.Testing in Tokyo#3を開催するとのことで
お手伝い依頼がきたので、喜んでスタッフ参加させていただきました。

イベント概要はこちら
togetterはこちら

僕の役割はにぎやかしと演習のフォロー。
演習のススメ方のヒントを話したり、テスト観点の出し方やテストの考え方についてのフォロー、あとはテスト仕様のレビュアをさせていただきました。
あんまり貢献できていなかったかも知れませんが。

◆所感。
○プログラマとテスターの思考の違いと共通点が見えた
○この内容でこの金額と満足度はとてもお得な感じ
・WACATEのような内容で、テストエンジニアにもオススメしたい
・演習は見る方もやる方もやっぱり楽しいな
・きょんくんすげー
・かおりちゃんかわいい
・オラクルすげー
・無限ドリンクバーは有限だった
・煙霧すげー
・お弁当とスイーツおいしかった
・あすかくんすげー
・KENさんすげー

◆反省点
・演習の設計内容についてもう少し調整できればよかったかな
・演習フォローは若干フォロー不足だったかも
・ゴールイメージがうまく共有できてなかったかしら
・事前に確認しておくべきことを確認しきれてなかったかな

演習については演習設計経験者としてはもう少しフォローできたかも、なのは
結構反省している。
でも楽しそうだったし、ものすごく考えたと思うのでこれはこれで良かったと思う。

◆自分用の細かい点
テスト仕様というものがどういったものか、というのがざっくりしすぎていて
上手く参加者と共有できていなかったなーと思った。
それをバシッとあの場で説明できないのは僕の力量のなさかな。

簡単に言うと「どのようにテストをします。その理由はこうです。」というのを
納得感を持って説明できるものが必要だったというのが答えなのですが、
そもそも仕様や背景がふわっとしていると妥当性を説明するにあたり仮説が必要になるため、このあたりの裁量が難しかったかも知れない。

そのとっかかりとして色々ヒントを出してはいたのですが、
何を言えばわかりやすいかなーというあたりでプログラマに伝わる言葉が足りず、
しっかりフォローできなかったかも知れない。

もう少し対象を分析・分解してから目的と対象を対比させないと
このあたりの妥当性や納得感を出すためには必要だったかも知れないのだが
それをスパッと見抜いてフォローできなかったのは今回の僕の大きな反省点です。


◆おまけ
ビアバッシュで乾杯した後に
「おっさん普段なにやってんの？」(ホントはもっと丁寧に質問されましたがｗ)
と言われたので10分くらいで作った「おっさんの日常」
「良かった」と言ってくださった方がいたのでやってよかった。いぇい。

テストエンジニアのおっさんの日常です from koyaman 2

ネタスライドを持っておいてよかったぜ。

テストする≒カメラで撮影する

ども。コヤマンどぇす。

例によってしばらくアウトプットしていないので投下。

ここ最近、仕事で色々と「テストとはなんぞや」とゆーことを色んな人に話す機会がありました。
就活学生説明イベントでの発表や学生向けの質問窓口的なものや、
グループだけでなく部の中での情報展開とかするときとか。

で、色々話しているうちに自分の中で「テストとはなんぞや」というのを端的に表現するのにこれっていいんじゃね？とゆーのができたので、それを公開してみる。
簡単にいうとフィードバックが欲しいだけです。ハイｗ

テストすることとカメラで撮影することは似てる。という話。

カメラって使いますよね。ケータイにもくっついてくるぐらいメジャーかな。と。
で、どういう時にカメラって使いますかね？
まぁ、記録に残したい（景色やイベントごとなど）がメインかと思います。
ただ「対象を"知る"ために撮影する」という使いかたもあります。
"何かの資料に使う"とか"診断する"といった使い方の方ですね。

で、この記事でいう「カメラで撮影する」というメタファは
「写真を何かの資料に使うために撮影する」というものと思ってください。

似てる点を５つにまとめました。

◆◆視点
◆カメラで撮るときって、視点を考えますよね。
　今見ている視点、少し上からの視点、煽り、俯瞰…
　「もしこっちから見たらどうなるだろう」
　「少し上からの方がより良さがわかるかもしれない」
　などなど。視点を考えます。

◆テストも同じく、視点を考えます。
　機能が動作するという視点、使いやすさ、デザイン、性能…
　色んな角度で見ておきたいですよね。

◆◆構図
◆カメラで撮るときって、構図を考えますよね。
　何かと一緒に入れて撮る、世界観を出すためにあえて手前に何かを置く、
　こういう角度の方が魅力的に見える…などなど。
　「どのようにその世界を切り取るか」を考えます。

◆テストも同じく、どのように世界を切り取るかを考えます。
　ソフトウェアの振る舞いはおおよそ無限の振る舞いを持ちます。
　そこから有限を切り出すために「どうしたら効果があるのか」を考えて
　無駄なテストをしないように考えます。

◆◆鮮明度・ピント
◆カメラで撮るときに、撮る方法や見せる方法を考えます。
　星の動きを撮影するために、シャッターを開放したり、
　ピントを人に合わせて背景をぼかしたり、そういった工夫をします。
　また、撮った画像がピンぼけだったり暗すぎたりすると意味がありませんよね。
　どういった撮り方をするのか、結果としてどう見せたいのか。そう考えます。

◆テストも同じく、取り方や見せ方を考えます。
　実施した結果がちゃんと見れないと意味がありません。
　どういうデータの取り方をしたのか、その結果、何を見たいのか。
　狙った結果を取りたいためにテストの仕方からテスト結果の見せ方まで考えます。

◆◆撮影後、すぐ見たい
◆カメラで撮った後、結果をすぐ見たいですよね。
　カメラワークや設定が間違っていないのか
　「ちゃんといい写真が撮れたのか」確認したいですよね。
　昔のように撮ったあと画像になるまで時間がかかるのか
　銀塩フィルムのように撮ってから現像するまでに時間がかかるのか。
　まぁデジカメだと、すぐ結果は見れますよね。

◆テストも同じく、テストをした結果をすぐ見たいですよね。
　テストのやり方や前提が間違っていなかったか、とか
　Excelでテストケースの管理をしていると
　結果はExcelで集計マクロを動作させないと結果が見れないとか。
　DBでテスト結果管理をしていて、リアルタイムで結果が見れるのか。

◆◆撮影後、自分で考える
◆カメラで撮った後、何かの資料を作成するために自分で考えます。
　視点、構図、鮮明度・ピントなどを持って撮ったたくさんの写真から
　この対象はこういった特徴があって、こういうことがわかる。
　そういったことを自分で考えます。そして資料を作ったりします。

◆テストも同じように、得たテスト結果から自分で考えます。
　○○テストの結果からこういうことが言える
　△△テストの結果からこういうことが言える
　この対象はこういった特徴があって、こういうことがわかる。
　そういったことを自分で考えます。そしてレポート書いたりします。

とまぁ、いかがでしょうか。
「テストする≒カメラで撮影する」

当たり前と思っている方もいらっしゃるかも知れません。
そんな「思ったこと」を綴ってみますた。コメントお待ちしてます。