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

ども。コヤマンどぇす。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

◆テストも同じく、テストをした結果をすぐ見たいですよね。
　テストのやり方や前提が間違っていなかったか、とか
　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)
コメント有り難うございます！

今日のいろいろ

実はよさこいのチームに所属していたりするのですが
今日は地元のよさこい祭りの中で最大のお祭りだったので一日中踊ってきました。
踊る阿呆です。

総踊り(参加者全員で踊る踊り)にて担ぎ太鼓で２曲→１曲を獅子舞
→１曲を踊り子→１曲を獅子舞→最後の総踊りにて担ぎ太鼓で２曲
というスケジュールでやったのですが、既に太ももとお尻、右腕がヤバい。
明日の朝、起きれるかどうかが問題。


ども。コヤマンどぇす。

今日はずっと放置していた
MBAirにEclipseとPleiades(Eclipse日本語化プラグイン)、AndroidSDKを入れる作業をしてみた。
Windowsだと入れるだけーみたいなカンジだったけど
Macだとそうでは無く、いろいろ勝手が違って面倒だった。

下記のサイトにとてもお世話になった。
◆日本語化
http://labs.uechoco.com/blog/2009/04/mac-eclipse-install-pleiades-japanese.html
◆AndroidSDKインスコ
http://www.textdrop.net/soft/mac-android-sdk-install2/

目指せ日曜プログラマ。
で、実はWindowsではサクラエディタがお気に入りだったりするのだが
mac版に無いとのことで、んじゃこれもチャレンジだーとemacsを入れてみた。
ー全然使いこなせないw

まぁ、元はPGしてましたがセンスが無いのは知っていて、
そのときはVisualStudio6でVisualC++上で書いてたし
現役でなくなったあともVisualBasicやExcelVBAくらいでしか
プログラミングしてなかったので
※javascriptはサクラエディタで書いてましたし。。
なんかもたもたしながらも地味に使っていこうかな、と思ってみたり。

生産性が非常に悪いけれども
新しいチャレンジを楽しんでいたりします。
生暖かく見守っていただければ幸いです。

他にもいろいろ知らなければならない技術がたくさんある。
ひとつひとつ、知っていこうっと。

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

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

ども。コヤマンどぇす。

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

色々世の流れにアンテナ張ってると、某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のセミナーを受けた方がどれほど専門性を持って活動しているのかは

よくわかっていない。

〇そのご。

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

正直言うと空想の存在。

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

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

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

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

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

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

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

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

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

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

それだけは確かかな。

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

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