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

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

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

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

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

小ネタ。

ラーメンで　おくちの中が　ガーリック。

五七五。

ども。コヤマンどぇす。

正直、SlideShareのフォロワさんがなんだか増えてきたので

こりゃいい加減どげんかせんといかんと一人で勝手に焦っていた。

で。この一年ろくに社外にアウトプットしていなかったので

小ネタを集めてみますた。

…といってもやりそこねたLTとネタLT２つですが。

・JaSST'12 Niigata用に作ったけど人がたくさんいたので飛び入りできなかったお蔵入りLT。

JaSST'12 Niigata LT-koyaman from koyaman 2

・仕事術コンテストで一応作ったものの、カラオケボックスの中でのお披露目になったネタLT。

LetsSuperyoutime from koyaman 2

・とてか02で作った隣の人いじりネタLT。

Myweekdays and testing from koyaman 2

…こう見るとロクなアウトプットをしていないですね。うん。ﾜﾘｯ

とちぎテストの会議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)
コメント有り難うございます！