2011年9月18日日曜日

今日のいろいろ

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

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


ども。コヤマンどぇす。


今日はずっと放置していた
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はサクラエディタで書いてましたし。。
なんかもたもたしながらも地味に使っていこうかな、と思ってみたり。

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

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

2011年9月3日土曜日

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


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

ども。コヤマンどぇす。

まぁ、こんなしょーもないことばかりしてる僕でも色々考えることもあるんですよ。えぇ。
色々世の流れにアンテナ張ってると、某G社さんのSETみたいなスキル(http://googletesting.blogspot.com/2011/02/how-google-tests-software-part-two.html)が求められていて、作るときに品質上げていかないと!とゆー流れなのはとっても良くわかる。予防であるべきというのは全く正しいと思う。
でもまぁ、そーゆー人はそんなにぽこぽこいるもんでもなく、
会社を見てるとスキルもバラつきがあるし、プログラムを読むことも作ることもしないひとなんて沢山いるわけだ。
いわゆる、テスト実施のみのキャリアである。

勿論、時代に取り残されてしまったと言って切り捨てるのは簡単だ。
しかし明らかに怠惰をしていたわけでない人も少なからず存在するわけだ。
現場から「頼むからやめないでくれ」と言われ続け、ずっと同じ仕事を強要され続けた人も。

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

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


〇そのいち。
テスト設計者。

一般的に考えられている最も多いキャリアパスなのではなかろうか。 
いつもやってるテストを作る側になってみる。
いつもあの人が出してくるプアなヤツを改造しているから
なんとかなるだろうと甘く見てると痛い目を見るキャリアパスであるw

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

よく見る光景として、
「テスト実施者だったときは凄かったのにテスト作らせたらあまりにショボい」
「テスト実施者としてはとても有能であったが、テストを作らせるといつまでも細かいところにこだわりすぎて作業が終わらない」
「本人がやりやすいと思って作ってはみたものの、実は皆がわかりにくいものが出来てしまった」
といったことはありがちである。

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


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

そもそもテストリーダーとテストマネージャって会社の切れ目なんじゃ、とゆー
大人の事情はさておき、求められるスキルセットがあまりに違うので
突然テストマネージャ、という話にはなりにくい。
顔の広さやらヒューマンスキルが高い人は割りとすんなりハマッたりもする。
ただし対外交渉でしっかり主張が出来るだけの胆力は必要になるだろう。

最悪なのは何を勘違いしてるのか、一日中雑談だけして過ごす輩。
社内政治のみに走ると使えないのにずっと残って現場に害を与え続けるが、上司には届かないという
やっかいなゴミになる。が、割りと良く見かけるタイプ。

ちなみにテストリーダーやマネージャになってからは要求の方のキャリアに行ったり、
プロジェクトマネージャになったりなどといったキャリアパスも増えると思う。


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

いきなりハードルが上がったように見えますが気のせいですw
端的に言うとノウハウの形式知化にくわえ、形式知の利用と発展である。

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

その中でどこから自動化すべきか?ということを考える。そしてそれを使いながら自分の強みが活きるところを探す。
TABOKで言うと、スキルカテゴリ6、TestAutomateArchitect的な仕事かも。
下記参照。


なかなか最強だが汎用性を犠牲にしすぎると属人化して視野が狭くなったりするので注意が必要。
特定ドメインから出れなくなるリスクは考えておく必要があるだろう。
ドメインの没落とともに技術者人生も…とならないような施策が必要になったりする。

上手く自動化の勉強が進んでプログラミングやツール作成が進めばしめたもの。
活躍の場に広がりが出ます。
湯本さんや松木さんはマネージャを経てこのプロセスを踏んだひと、と理解しています。


〇そのよん。
探索的テストの専門家。
※このへん、少し空想入ってます。

最近、脚光を浴びはじめた探索的テスト。
極端なことを言うと正にウデ一本で生きていく生き方だ。

絶え間ない実績と自らのプロモーションが必要になるだろう。 
「オレに任せてくれれば、バグ出してやるぜ」的なイメージ。

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

また、対象ドメインの知識やプログラミング知識も探索するには
勉強が必要であろう。
しかも普段から探索する癖をつけていたりなどができないと、パターンとのマッチング能力を継続的に発揮するのは困難であろう。
また、多岐にわたる製品カテゴリの経験が要求されるため、仕事に巡り会う運のよさも必要だ。
フリーランステスターとでも呼ばれるのだろう。
僕はこういったタイプの人にはあまり巡り会った事はない。
長く同じ仕事をするひとの中に稀に見かける。
が、そのコンテキストから外れるとどうなるかはよくわからない。※ドメイン依存の人が多い気がする。
正確には、日本の産業状態では難しいから存在しないだけかも知れない。
とはいえ、海外のイベントに出ていない身としてはどれほどの探索的テストの事例やプロがいるのかはわかっていない。
※Cem KanerやJames Bachのセミナーを受けた方がどれほど専門性を持って活動しているのかは
よくわかっていない。


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

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

探索的テストやテスト実施についての知識体系の構築などをするひと。
スーパーテスターみたいな人が何を考えてどのように操作などを行い、
その考え方はどこまで通用するのか、などを形式知化する。
探索的テストのパターンとのマッチングの形式知化などが求められるだろう。

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



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

ま、どれにでも言える事は
「めちゃめちゃ勉強が必要」ということぐらいであろうか。

「今の仕事が楽しいからこのままの仕事だけしてたーい♪」というひとには先はない。野垂れ死にが待つだけだ。
それだけは確かかな。
ま、それはどの業種にも言える事だったりもするのだが。

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

2011年8月25日木曜日

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

ども。コヤマンどぇす。

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

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

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


―理由を述べる。

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

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

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


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

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

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

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


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

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


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

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

2011年8月9日火曜日

Software Testing ManiaX vol.5に寄稿

ども。コヤマンどぇす。


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



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

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


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


2011年7月30日土曜日

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

ども。コヤマンどぇす。

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


◆話は戻ってテスコラ。

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

今日は今までのおさらいとどんな感じで進めようかねー、という話をしたのですが
その最中でも色々な議論ができて楽しかった。
「機能」って難しいよね。@mkoszkさんがManiaXに書くわけですよね。

で、今日感じたのは、
・「要求」には「現在のリアルから求められるもの」と「外部から求められるもの」があるということ。
・テストを引き受けるときに「この製品のコンセプトはなに?企画書プリーズ」という僕は
 割と異端なのかもしれないということ。
 ※誰からも反応がなかったので、反論が無いのか、ポカーンとされたのか
  どっちかよくわからないのだけれども。


そんな感じス。

2011年7月29日金曜日

新調。

ども。コヤマンどぇす。

38歳じゃない!とクレームを言われました。
サーセンw

色々googleのサービスを使っているので、
やってみるかとブログを新調してみた。

ソフトウェアテスト
ソフトウェア品質
欠陥
人間
などに興味があります。

僕が考えたことなどを好き放題に書いてみて
叩かれたりなじられたりすることを想定している。
ま、負けないぞっwwww

三日坊主ですけど、どっかで何かやったとか記録できるといいな。
スライドとか載せられたらもっといい。
載せられるかどうかよくわからんので調べてみようと思っている(そこからかよ)。

とりあえず。よろしくお願いいたします。