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

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

ども。コヤマンどぇす。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

・テスト対象分析

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

・ステークホルダ分析

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

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

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

・優先順位の定義

・テスト方針の作成

・スコープの定義

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

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

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

・全体像

◆全体像の構成

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

　・メリット：

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

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

　　テストの意図が明確

　・デメリット：

　　俯瞰しにくい

　　頑張ると重い

◆◆本記事のテーマ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

つづく。(たぶん)

-----

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

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

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

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

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

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

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

ども。コヤマンどぇす。

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

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

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

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

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

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

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

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

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

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

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

自動化頑張ります。

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

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

ではでは。

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でテスト結果管理をしていて、リアルタイムで結果が見れるのか。

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

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

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

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

とちぎテストの会議02に参加しました。

ども。コヤマンどぇす。

とちぎテストの会議02-通称とてか-(#toteka)に参加してきたので簡単にレポート。

端的に言うと、普段あまり触れ合わない方々と触れ合い、大変に刺激を受けた。

正式に取材許可をいただいてないのと、どこまで公開OKかよくわからなかったのでひとまずブログにアウトプットさせていただくことにした。

◆全体的に
・全員が楽しめるようにとても心遣いがされていたイベントだった。
・皆さんが温かかく、笑顔だった。
・プログラマの方多め。でもテストの話の方が多かった。
・実装とテストのライブ面白い。
・秋山さん(@akiyama924)と咳さん(@m_seki)の言葉の力が凄かった。
　圧倒的な思考力を感じた。
　圧倒的な視点の多さと、本質的な発言、言葉。カッコイイ。
・よねざわさん(@vestige_)はおしゃれだった。河野さんと合いそうだな、と思った。
・みわさん(@miwa719)は別嬪さんだった。

◆トゥインクル
美味しかった！←顔に似合わず野菜大好き。

◆基調講演
秋山さんの日常。
ツイート分析と会いに行けるネタで吹いた。
インプットーアウトプットサイクル。最近できていないので反省。

基本的に問題解決をしているのだな、と思った。
僕のしている仕事と本質的には変わらないな、と思った。
問題の糸口探しでの
４分割(自分/他人、永遠の問題/なんとかできる問題)
は、すごくわかりやすかった。普段は暗黙的に分割していることにも気付いた。
※とはいえ永遠の課題と他人の問題が身の回りに多いので、つい質問してしまった。

◆Testing Live
かっこいい咳さんの言葉と実装。
Rubyは実は恥ずかしながら初めて？まともにソースを見た。
よって型の扱いとかそういったことがわからなかったので
仕様の部類に入るものをあえて質問してみた。
ら、割と面白かった。

どうやって作られているのか、というのは
テストタイプで言うと「構造テスト」に入るのだけれど
それをどう考えるか、という点を強く実感できてとっても面白かった。
そして、三角形判断のエレガントさに感動した。

◆レシピ
・なかうちさん(@mame)
　相談の重要性などがやはり大切なことを思い知った。
　自己分析のレベルの高さに感動した。
　コミュニケーションというか、やはりレビューは大切だと再認識。

・Unityさん(@Unity1004)
　マリオチャートの話。
　全体の俯瞰って難しいよね。
　他のチャートと組み合わせるときはワンプレート難しそうだな、と思った。

・リック・サンダースさん(@Rick_Thunders)
　タイトルのこじつけが面白かったｗ
　結合しなおし確認テストとはいえ、「変更」点を意識する必要性の重要性の話。
　聞いた後の秋山さんやばんちゃんがすごく生き生きしてたｗ

・みわさん
　探索的テストでのもやもやの話。
　チャータのレビューなどでいくらか消せるかもと認識したけれども
　テスターとしてのセンスをすごく感じた(=自分のアウトプットの品質に対する不安)。
　プログラマとのペア探索的テストやってみたい。
　
・goyokiさん(@goyoki)
　熊とワルツの方がいいです、で吹いたｗ
　大人のマネジメントができない人って割と多いよね。自戒を込めて。
　いい話しがわかりやすい例で例えてあった。プレゼン上手いなー。
　あとでスライドどこかにアップしてもらえるかしら。。

◆ワールドカフェ
基本的に雑談。でも人の考えや感情に触れるのは、やはり面白かった。
テストの話、特にJSTQBの定義などはやはり認知度が低いのだろうな、というのを実感した。
ここでもコミュニケーションの重要性というのを感じたという声を聞き、
やはり「基本」部分はコミュニケーションだよね。と改めて認識を強くできた。

◆懇親会
ウニコの料理はとてもおいしかった。
鯛メシヤバイ。

凄い人たちが多くて緊張して話しかけられなかったな。

リジェクトされたネタも面白かった。
単なる日常ネタを持っていったのだけれど、
割と笑っていただけたので良かった。
和田さん(@t_wada)の発表、F.I.R.S.Tの話。
自動化で考える必要があるな、と再認識した。
設計というか実装の部分で考えが必要であり、TABOKにはそういった記述は少ないかも。

自己紹介とネタのLTをしながら少しJSTQBとJaSST、WACATEの話。
WACATEに少しでも興味を持っていただければ良いなー。

P.S.「カイパン」と認識されていることを改めて思い知ったｗ

統合テストの分類について #swtestadvent2011

#swtestadvent2011

http://atnd.org/events/22833

@takanorigさんのお声がけによる

"Software Test & Quality Advent Calendar"の12/16版エントリです。

12/15は@shuji_w6eさんのエントリでした。

「Developer TestからCustomer Testへ」

-----

明日からWACATE 2011 冬なのですが、ドタバタする前に上げておくことにします。

WACATEに興味のおありの方は是非、オフィシャルサイトや

MagazineやManiaXなどで雰囲気を感じていただければ幸甚です。

-----

さて。たまたま書き貯めていたネタを投下させていただくことにする。

ニセコでミッキーさんとお話をしたときに考えたというか気づかされたことなど。

わたくしコヤマンは「統合テスト屋さん」を自称している。

で、その統合テストってなんぞ？というお話。

◆◆◆統合テストとは。

組織によって名称が異なるが、

・「結合テスト」

・「連結テスト」

・「インターフェーステスト」

・「インテグレーションテスト」

・「サブシステムテスト」

・「コンポーネント統合テスト」

・「システム統合テスト」

などと呼ばれるものの総称である。

明確な方法論が存在しないと言われており、組織によってさまざまな実施形態があるため、定義も困難になっていると思われる。

個人的にもっと整理しようと思っている領域である。

◆◆◆定義

ここは鉄板、JSTQB用語集(JSTQB-glossary.V2.0.J02)を見てみよう。

引用-----

●統合テスト(integration testing)：

統合したコンポーネントやシステムのインターフェースや

相互作用の欠陥を摘出するためのテスト。

component integration testingおよび

system integration testingも参照のこと。

-----

参照先は以下。

引用-----

●コンポーネント統合テスト(component integration testing)：

統合したコンポーネント間のインターフェースや相互作用の欠陥を検出するためのテスト

●システム統合テスト(system integration testing)：

システムとパッケージを統合するテスト。また、外部システム(たとえば

電子データ交換やインターネット)とのインターフェースのテスト

-----

まぁ、塊をくっつけたときにするテストなのね、というのはご理解いただけるかと思う。

ちなみに統合テストについては、以下のURLに詳しい説明がある。

◆望月さんの連載

◆布川さんの連載

布川さんの連載には最上階は「システム」であると記載がされているが、ここ最近では「システムオブシステムズ」や「ソリューション」といった概念が出てきており、統合テストの範囲は年々広がっていると言える。

つまり、以下のような粒度があると言える。

○コンポーネント間統合

○サブシステム間統合

○システム間統合

ちなみに、筆者は全ての粒度が担当であったりする。

※現在はシステム間統合が多めだが、基板上の通信内容を冶具を使って採取してProtocol Analyzerにかけたり、モジュール間の通信Logの内容の解析をしたりもするし、単にシステムの動作について確認したりなどもしている。

では、その中でどのようなテストをやっているのか、の話に移ろう。

◆◆◆統合テストの分類

今のところ、ざっくり統合テストというと以下の分類が存在する。

◆◆範囲の分類

○インターフェースに特化したテスト

・「連結」テストと呼ばれることもある。

・インターフェースのプロトコルやメッセージのやりとりに特化したテスト。

シーケンス図等を使ってやりとりが正しいことや有り得ないパターンの通信を受けたときの動作が妥当なものかどうかを評価するテスト

※とあるモジュールが出した命令を受けて、期待どおりに次のモジュールが動くこと、正しい通信を返すこと、といった点が主な焦点になる。

★結合することをテストする。

○サブシステムやシステムを結合した状態でのブラックボックステスト

・いわゆる「結合」テスト。

・既に「現在の対象が外部にリリースする単位」(=これを単体と定義する)では内部のテストが終了しており

　他のモジュールとの連動や

　組み合わせによって表現される機能に対してのテストを行う。

※要求から一つ一つブレイクダウンした「実現方法」が主な焦点になる。

★結合した状態の動作をテストする。

この結合テストでいう単位というのがテストレベルになったりする。

組織によっては細分化されたり、丸められたりする。

品質を厳しく見る組織では、細分化されたり、まったく違う軸のテストが定義されたりもする。

◆◆実施方法の分類

○トップダウンテスト

いわゆるスタブを使ったテスト。

モジュール構造において下位にあたるモジュールを仮に生成して上位モジュールから呼び出してテストをする。

・メインモジュールやモジュール間インターフェースに対して早めの段階でテストが可能になる。

・下位モジュールのテスト時にも上位モジュールのテストになるため潜在バグを発見しやすい

といった長所があるが、

・開発の初期の頃には、テストしながらの開発が難しい

・スタブの作成が割と難しい

といった短所がある。

○ボトムアップテスト

いわゆるドライバを使ったテスト。

モジュール構造において、上位にあたるモジュールを仮生成して下位モジュールから呼び出してテストをする。

・テストケースの作成や結果のチェックが容易。

・開発の初期からテストしながらの開発がしやすい

といった長所があるが

・最終的に接続した際に、インターフェースのバグがあったりすると修正量が多くなってしまう

といった短所がある。

◆◆◆特徴

統合テストとして特徴的なのは、スケジュールや対象物、環境によって

これらのパターンがコロコロと変わることである。

例えばスタブとなるシミュレータがあらかじめ用意されている環境では

トップダウンの方式を取ることがあり、納期が非常に厳しい対象であったりすると

ボトムアップの方式を取ることがある。

なので、最近はボトムアップが多い気がする。なので最終的に(ry

また、基本的にはがっつり開発中だったりするので、

・テスト期間中だが仕様が定まらずドキュメントが無い

・仕様がコロコロ変わる

・連結先の都合で止まる

・シミュレータのバグに翻弄される

・要求が変わる

・スケジュールが無い

といったことが当然のように発生する。

まぁ、上記は統合テストに限ったことではないが、より発生しやすい、と認識いただければ幸いである。

◆◆◆まとめ

統合テストの厄介なところはコンテキストが合わないことが多いところだと思う。

粒度も範囲も実施方法も色々な方法があるというところではないかと感じている。

またこれが組織によって(会社の中ですら)まちまちであったり、妥協の産物がごろごろしていたりなどする。

結合テストや統合テストといっても、どのイメージで話をしているかについては事前に話し、コンテキストを合わせた方がよいだろう。

その中でいくつかの分類を紹介したので、皆さん自身でマッピングしていただければ幸いである。

統合テストをしている人は

もしかしたらプロトコルのインターフェースを見ているかも知れないし、

システム間のデータのやりとりを見ているかも知れないし

ある値を与えられたときの関数の振る舞いと見ているかも知れないし、

ある操作をしたときの機械の動作を見ているかも知れない。

これらを整理したうえで、統合テストの方法論をみんなで構築できたら素晴らしいと考えている。

僕はこんなことを考えている。(テストの視点の話)

-ちょっと修正：2011/10/18

風使いになりたい。
暑いときには扇風機がわりにできるし
寒いときは温かい空気を送ったりできるし、
刃物もカマイタチがあればいいし、走るときはいつも追い風だ。
そして何より「神風の術」が使える。スンバラシイ。


ども。コヤマンです。

なんだかドタバタしていたけれど、少し落ち着いてきたので考えていることなどを簡単に書き出してみる。

テストの視点の話。

大雑把な書き方なので何を言いたいのかよくわからないと思いますが、
僕がテストを考えるときに何を考えているのか、という"視点"を大雑把に出してみた。

• モノ
• コト
• ドメイン(背景など、対象を取り巻く世界)

こんだけ。んで、これって何かモノを作るときと全く同じだよなーと思った。
モノを作るとき、同じことを考える。
※もちろんこれは僕の個人的意見に過ぎないので、異論はあるかと思う。
　なるほど、テストを開発する、と考えると
　｢何かを作る｣ときに共通に使える概念かもしれない。

では話を戻して、
｢開発成果物の作成｣と｢テスト開発成果物の作成｣では、
決定的に何が違うのか？ 

と考えた場合に以下の視点が増えた。

• モノ：
• 開発成果物そのもの
• 開発成果物の持つ癖
• コト：
• 開発成果物が実現したこと、実現出来なかったこと
• 現在の開発成果物をユーザが思うこと
• ドメイン：
• 開発成果物を作るうえで関係した背景(基盤技術やドメインの特性、使用した技術の特徴など)
• 開発チームを取り巻く環境(コミュニケーション状況や組織状況)

つまり、モノを作りましょうといった時に考えることよりも少し考えることが増えた。
基本的には変わらないのだけれど、
複雑に作れば作るほど、考える幅が増えるんだろうというのがよく分かった。

図であらわすとこうなる。

考えているものを３つの視点で見る

テストはそれもひっくるめてさらに３つの視点で見る

複雑に作ると

視点は変わらないが、幅が広がる

これをまぁよく理解せずに
「ボクちゃん後工程だからそもそもの背景とか考えなくていいんだもんね！」
とか言っちゃう人もまれに？いるが、
それだと論拠・根拠が無くなるため、何をやっているんだかわからなくなるうえ、主体性がなくなる。

僕が
「ウチは後工程だから考えなくていいんだよ」
「言われたことだけやってりゃいいんだよ」
「開発者がいいと言えばいいの！」
と言われた時に感じる"気持ち悪さ"というか違和感はどうやらここにあるようだ。
※ただし、スコープの定義の話は勿論別だある。
根拠のあるスコープの中での定義であれば違和感はない。

なのでまぁ、簡単に言うと3種類の視点で考えていて、
その中の｢要素｣が沢山あって、それをテストする立場で見るんだな、と。

でまぁ、この｢要素｣というのがたぶん肝なんだな、と。
といっても大雑把な話だとよくわからないと思うので具体例を列挙してみる。

• モノ
• 部品などの構成要素
• 部品の特性
• 流用したベースとなる存在

• コト
• 要求(満たしたいこと)
• ちょっとした制限事項
• 自分がなんか怪しいと思うこと

• ドメイン
• なぜ、そのものが産まれたのか
• 業界の標準や常識
• どんな人が使うのか

と、こんな感じ。
定量的に説明出来ないが、僕はこんなことを考えている。

でまぁ、最近色々考えさせて頂く機会があって、実践もさせていただける場所もある。
そこでちょこちょこ実践しているのだがー

…これがまぁ、なかなか上手く出来ないw

いや、そこそこは出来るんだけど、考えることが多すぎてイッパツでバシッと決まらない。
何回も何回も修正する羽目になる。

朝起きると｢あぁっこんな事も考えられるじゃないか！｣と閃いちゃったりして
モンモンとしながら会社に行ったりする。モンモン通勤。

でもまぁ、それはそーゆーもんだ、と割り切ることにした。
イッパツでバシッとキマると格好いいんだろうけど、僕はそんなに格好いいタイプではないし、頭もポンコツなのでそのくらいが丁度いい。
何回も何回も修正するけど、それなりにいいテストが出来るなら、それがいい、と考えた。

予め予測出来ることを全て列挙するよりは、いくつかガイドワードから導きだすフレームワークの方がテストに向いてる気がする。
→理由としては、考えることを全て出すと恐らくコストに見合わない。
ガイドワードから、というのはミッキーさんの意地悪漢字なども参考にできるだろう。

まだ予想に過ぎないが、ドメインを固定したときには、そのガイドワード、
あるいはいくつかの｢要素｣がスケルトンやパターンのように生成されればいい気がする。

とか考えてたら、僕の考えている範囲はアーキ生成モデルなのか？とか思ったりしたり。

…脱線した。

まぁ、そんな感じでどうやら僕は割りと単純な視点でものを見ていて、
ときどき考え方を流用して｢要素｣の抜き出しをするらしい、ということが分かった。

この考え方や説明がわかりにくかったり、そうではなくてこうなのでは？
と思われた方は是非、教えていただけるととても嬉しい。
-----
★にしさん(@YasuharuNishi)
★あきやまさん(@akiyama924)
★きょんさん(@kyon_mm)
コメント有り難うございます！

テスト実施者のキャリアパスをどう作るか。

気温が下がって快適になってくると女子の露出が減って心が寒くなりますね。

ども。コヤマンどぇす。

まぁ、こんなしょーもないことばかりしてる僕でも色々考えることもあるんですよ。えぇ。

色々世の流れにアンテナ張ってると、某G社さんのSETみたいなスキル(http://googletesting.blogspot.com/2011/02/how-google-tests-software-part-two.html)が求められていて、作るときに品質上げていかないと！とゆー流れなのはとっても良くわかる。予防であるべきというのは全く正しいと思う。

でもまぁ、そーゆー人はそんなにぽこぽこいるもんでもなく、

会社を見てるとスキルもバラつきがあるし、プログラムを読むことも作ることもしないひとなんて沢山いるわけだ。

いわゆる、テスト実施のみのキャリアである。

勿論、時代に取り残されてしまったと言って切り捨てるのは簡単だ。

しかし明らかに怠惰をしていたわけでない人も少なからず存在するわけだ。

現場から｢頼むからやめないでくれ｣と言われ続け、ずっと同じ仕事を強要され続けた人も。

僕より年上のそういう人は沢山いる。そして、単価の高い日本人である宿命により、ある日突然コストカットという名目で切られる可能性に怯えている。

そういう人は日本の中でどこを目指すべきなのだろうか。

そう考えた。

〇そのいち。

テスト設計者。

一般的に考えられている最も多いキャリアパスなのではなかろうか。 

いつもやってるテストを作る側になってみる。

いつもあの人が出してくるプアなヤツを改造しているから

なんとかなるだろうと甘く見てると痛い目を見るキャリアパスであるw

どの世界にも言えることだが、他人が作ったものを批判するのは簡単であるが、ゼロから作るのは大変なのである。

よく見る光景として、

「テスト実施者だったときは凄かったのにテスト作らせたらあまりにショボい」

「テスト実施者としてはとても有能であったが、テストを作らせるといつまでも細かいところにこだわりすぎて作業が終わらない」

「本人がやりやすいと思って作ってはみたものの、実は皆がわかりにくいものが出来てしまった」

といったことはありがちである。

その結果、やっぱり「テスト実施者」でいてください、ということが

しばしば起こる。

〇そのに。

テストマネージャ。

実施が上手いひとがマネジメントも上手いひとがかというとまたこれが別の話だったりする。

そもそもテストリーダーとテストマネージャって会社の切れ目なんじゃ、とゆー

大人の事情はさておき、求められるスキルセットがあまりに違うので

突然テストマネージャ、という話にはなりにくい。

顔の広さやらヒューマンスキルが高い人は割りとすんなりハマッたりもする。

ただし対外交渉でしっかり主張が出来るだけの胆力は必要になるだろう。

最悪なのは何を勘違いしてるのか、一日中雑談だけして過ごす輩。

社内政治のみに走ると使えないのにずっと残って現場に害を与え続けるが、上司には届かないという

やっかいなゴミになる。が、割りと良く見かけるタイプ。

ちなみにテストリーダーやマネージャになってからは要求の方のキャリアに行ったり、

プロジェクトマネージャになったりなどといったキャリアパスも増えると思う。

〇そのさん。

実施の自動化推進及び切り分けとその利用者。

いきなりハードルが上がったように見えますが気のせいですw

端的に言うとノウハウの形式知化にくわえ、形式知の利用と発展である。

つまり、生産性を上げながらもテスト実施にフォーカスを当て続ける道。

その中でどこから自動化すべきか？ということを考える。そしてそれを使いながら自分の強みが活きるところを探す。

TABOKで言うと、スキルカテゴリ6、TestAutomateArchitect的な仕事かも。

下記参照。

・http://www.automatedtestinginstitute.com/home/index.php?option=com_content&view=article&id=1114:skill-category-6-automated-test-script-concepts&catid=69:automation-body-of-knowledge-abok&Itemid=196

・http://d.hatena.ne.jp/shinsuku/20110805/p1

なかなか最強だが汎用性を犠牲にしすぎると属人化して視野が狭くなったりするので注意が必要。

特定ドメインから出れなくなるリスクは考えておく必要があるだろう。

ドメインの没落とともに技術者人生も…とならないような施策が必要になったりする。

上手く自動化の勉強が進んでプログラミングやツール作成が進めばしめたもの。

活躍の場に広がりが出ます。

湯本さんや松木さんはマネージャを経てこのプロセスを踏んだひと、と理解しています。

〇そのよん。

探索的テストの専門家。

※このへん、少し空想入ってます。

最近、脚光を浴びはじめた探索的テスト。

極端なことを言うと正にウデ一本で生きていく生き方だ。

絶え間ない実績と自らのプロモーションが必要になるだろう。 

「オレに任せてくれれば、バグ出してやるぜ」的なイメージ。

但し探索的テストに必要とされるエビデンスはしっかり取っておくしたたかさと、自分のなかにある経験やパターンとのマッチングの能力が必要であり、探索的テストの利点などを深く理解していないと難しい。

また、対象ドメインの知識やプログラミング知識も探索するには

勉強が必要であろう。

しかも普段から探索する癖をつけていたりなどができないと、パターンとのマッチング能力を継続的に発揮するのは困難であろう。

また、多岐にわたる製品カテゴリの経験が要求されるため、仕事に巡り会う運のよさも必要だ。

フリーランステスターとでも呼ばれるのだろう。

僕はこういったタイプの人にはあまり巡り会った事はない。

長く同じ仕事をするひとの中に稀に見かける。

が、そのコンテキストから外れるとどうなるかはよくわからない。※ドメイン依存の人が多い気がする。

正確には、日本の産業状態では難しいから存在しないだけかも知れない。

とはいえ、海外のイベントに出ていない身としてはどれほどの探索的テストの事例やプロがいるのかはわかっていない。

※Cem KanerやJames Bachのセミナーを受けた方がどれほど専門性を持って活動しているのかは

よくわかっていない。

〇そのご。

実施におけるメソドロジの構築などの今までに存在しないジャンルの仕事を開拓する。

正直言うと空想の存在。

だがその世界は今まで存在しないだけであって、作る価値はあると思っている。

探索的テストやテスト実施についての知識体系の構築などをするひと。

スーパーテスターみたいな人が何を考えてどのように操作などを行い、

その考え方はどこまで通用するのか、などを形式知化する。

探索的テストのパターンとのマッチングの形式知化などが求められるだろう。

化学、物理、論理、人間についての勉強など、多岐にわたる学習が必要になるだろう。

とまら僕がおぼろげに考えられるのはこのくらいだ。

ま、どれにでも言える事は

「めちゃめちゃ勉強が必要」ということぐらいであろうか。

「今の仕事が楽しいからこのままの仕事だけしてたーい♪」というひとには先はない。野垂れ死にが待つだけだ。

それだけは確かかな。

ま、それはどの業種にも言える事だったりもするのだが。

人生そんなに甘いもんじゃないんだなー。うん。

探索的テストをいつやるべきか。

ども。コヤマンどぇす。

先日は水面下で打ち合わせをしている、あるイベントの打ち合わせだった。
(名前はまだ言えない)

ともあれ、その打ち合わせ後の飲み会中に
｢探索的テストをいつやるべきか｣
という話題になった。
それを通勤中の時間を使っていくつか考えている事を書いていく。

コヤマンの結論は｢場合による｣だ。
当たり前なんだけど、必殺技主義でないので、この回答にならざるを得ない。

―理由を述べる。

まず、探索的テストの前提として
ソフトウェアが｢探索できる状態｣である必要がある。
つまり、ある程度形になっていて、ある程度安定動作をしている必要がある。

なぜならば、例えば原因解明中のクラッシュ/ハングする問題があったとする。
どこで落ちるかわからない状態で探索を行って、途中でクラッシュ/ハングしたとする。
こうなると自分の操作が原因なのか、既知の問題なのかはパッと見ただけではわからない。

動作ログがあるなら切り分けは出来るが、動作ログを解析するツールなどが整備されている必要がある。
解析を開発担当者にやらせれば良いとお考えの方もいるかも知れないが、作る側からすると｢どうせ既知の問題だろ｣と考えるのでモチベーションも上がらないうえ、
徒労に終わってしまった場合には所謂時間の無駄遣いを強要することになるため、信頼関係の問題となる。
なので個人的にはオススメしない。

また、組織やチームの役割も関係する。

僕は統合テスト屋であり、主にシステム全体として見た場合の単機能の実現などがメインミッションとなるのだが
規模によっては製品単体の単機能であったり複数の組み合わせなとも
クライテリアとして存在する場合もある。

組み合わせの場合には単機能の品質次第であるが、早めに実施することをオススメする。
組み合わせの仕方による違いや、弱みみたいなものが早めに触ることにより浮き彫りになる。

逆に単機能の実現が目的なのであれば、ある程度機能が安定したあとに更なる品質向上を目的としてユーザの観点などを加えながら実施するのが良いだろう。

作りや重要度によっても影響を受けるのだが、これは多岐にわたるので割愛する。

重要度が高いものや、作りが特殊なものは早めに触る方が良い。
とはいえ、技術確立がなされていないなど、全く動作しないような状況ではあまり意味がない。

上記のようにさまざまな要因があると考える。よって｢場合による｣のだ。

と、考えたことをぼんやりと。

Software Testing ManiaX vol.5に寄稿

ども。コヤマンどぇす。


創刊から記事を書こう書こうと思っていたにもかかわらず
周りの方々の豪華っぷりに尻込みしたり、
記事を書いてる余裕も無かったので
作成側にいながらも書いていない状態でしたが、今回やっと書けました。


伝説のソフトウェアテストの同人誌
Software Testing ManiaX vol.5に
｢テストの必要性を考えたときに考えたこと｣という内容で寄稿しました。

決して技術肌でない僕が書くのはためらいを禁じ得ませんでしたが 想いを強くするために恥を覚悟で書きました。


熱さだけ、勢いだけですが、目を通していただけると嬉しいです。
-----
2011/08/14[sun]
C80 東2ホール　P-28b
-----
http://circle-official.wacate.jp/

初テスコラと統合テストと僕。

ども。コヤマンどぇす。

今日は@Yuko_skiさん主催の通称"テスコラ"に初めて参加してみますた。
理由は"統合テスト"についての取り組みをしているから。

"統合テスト"は僕がテスト人生をかけて取り組もうと思っていたテーマだったので
ものすんごく興味があった。


◆統合テストって難しいんですよね
"統合テスト"ってなんぞ、とゆー説明自体もかなり難しくって、
単体テストとシステムテストの間にやるテスト、というのが
いちばんしっくりくるかなぁと思っている。

最近はシステムオブシステムズとか色々あるじゃないですか。
あれもシステムテストってどこやねん、的な定義が難しかったり
ソリューションとか言われたりしてたり。

一体どこまでが単体/ユニット/コンポーネントだったりすんねん、とか。
んで、単体じゃないから統合だよね、とかなるんですけど
その粒度はホントに様々なんですね。

かの「バリ本」にも難しいって書いてあった気がします。←記憶が定かでないですが。

◆言葉の定義はわかるけど、なんで難しいの？
で、なんで難しいかというと、
@mkoszkさんのエントリがわかりやすく表現してあります。
http://d.hatena.ne.jp/mkoszk/20110103/p2

縦も横も考えるんだけど、作りだけでなく使われ方まで考えないと
うまくテストできないんですよね。

で、もちろんインターフェースだけに注目しても「いいテスト」にはならない。
※このあたりは用語の定義に反するのですが、そう主張する。

僕は業務で「統合テスト」のあたりを扱って8年ほど経ちます。
思えば「なんとなくプログラムも書いてるし、テストもわかるし」みたいな感じで
入ってみたのが運のつき。

大き目のシステムから小さめのシステムの統合テストみたいなものまで。
時には機能間の結合を見たり、時にはプロトコルのログとにらめっこしたり。
そんな感じで幅広い経験をさせていただいていて
めちゃくちゃ面白いところだと思っている。

早めに欠陥を見つければ修正コストも早いよね、と思って頑張ったりする。

さらに会社の基準とかでも、かなりのバグ抽出カバレッジを求められたりする。


◆でも統合テストってヤツは。
そんなニクいヤツ"統合テスト"ですが、
実際に事例とか"統合テスト"といえばこう！みたいなものって実は確立されていません。
※僕が知らないだけかもですが。

まぁ僕が思っているだいたいの理由は単純で。

「人間の感覚」の度合いが強いんですね。
だから方法論として確立するのが非常に難しい。

これはテスト全般に言えることだったりするんですけど
特に"統合テスト"というフェーズはそれの度合いが強い。

人と人との意志疎通であったり、認識のズレであったり
人が何かを作るときに思いついた「思いつき」であったり
そういった事とガチで向き合うテストなんですね。

しかもテスターらしく外からそれを見ないといけない。
※この感覚わかるかなぁ＾＾；

いわゆる"アジャイルテスター"みたいなことをする必要がある。

特に最近のご時世はひどくって、
高品質短納期が求められるくせに
システムオブシステムズで「機能ってなんだっけ？」とかいう状態なので
直接PMやら開発リーダーに話を聞いたりしてコミュニケーションをよくしないと何も解決しない。

仕様書がないことすらある"統合テスト"では、コミュニケーションやら
見える化などが絶対条件で必要になるんですね。

で。これを楽にしたいんですね。
そしたら皆ハッピーじゃん、と。


◆話は戻ってテスコラ。

でまぁ、テスコラに参加してみました。(前置き長ッ)

今日は今までのおさらいとどんな感じで進めようかねー、という話をしたのですが

その最中でも色々な議論ができて楽しかった。

「機能」って難しいよね。@mkoszkさんがManiaXに書くわけですよね。

で、今日感じたのは、

・「要求」には「現在のリアルから求められるもの」と「外部から求められるもの」があるということ。

・テストを引き受けるときに「この製品のコンセプトはなに？企画書プリーズ」という僕は

　割と異端なのかもしれないということ。

　※誰からも反応がなかったので、反論が無いのか、ポカーンとされたのか

　　どっちかよくわからないのだけれども。

そんな感じス。