最後のWACATE

あらすじ

WACATEという一泊二日で行うソフトウェアテストの勉強会があります。夏と冬の年2回行われており、もう何年も続いています。「1回くらい行ってみるか」という気持ちで参加したのが2014夏、「冬は夏と違う」という情報を聞いて参加したのが2014冬、そしてそこで賞を頂いて講演を条件に無料で参加したのが今回2015夏です。

WACATE2015 夏 ～ワタシハソフトウェアテストチョットデキル～ 開催概要 - WACATE （ソフトウェアテストワークショップ）

ソフトウェアテストに関わる人のための Biased Position Talk - BPPセッション

ソフトウェアテストに関わる人のための Biased position talk from Masanori Kaneko

www.slideshare.net

その賞というのはBest Position Paper 賞というもので、参加申し込み時に提出したポジションペーパーの中から参加者投票によって選ばれた一位に贈られる賞です。

というわけでお話をする機会を得られました。最初は何か単発の技術セッションを開こうかと思ったのですが、2015夏のメインコンテンツが上位テストレベルの機能テストを主に対象にしたテスト開発方法論である "ゆもつよメソッド" に決まったので、「自分のセッションだけ浮いたことをやってもなぁ」と思い直し、最終的に「ポジションペーパーで選ばれた人のセッションなんだからポジションのお話をしよう」というシンプルな？考えに至り、上記スライドのような内容にしました。BPT(Biased Position Talk)がBPPにかけてあることや、「そもそもポジショントークなのにBiasedって何だよ」というツッコミを待っていたのですが全くなく、無力感でいっぱいです。

業種や職種などのポジションと聞いて語りやすいところから始め、テストに関して意見がこう分かれるだろうなぁと私が想定している点を、聴講者にほぼ二択で突いてゆくというスタイルでお話しました。予想通りなことも、そうでないこともあって面白かったですね。例えば "網羅したい vs 賢くサボりたい"では、「半々くらいかなぁ」と予想していましたが、賢くサボりたい派の方が優勢でした。

そんなこんなで気分良く話していたら時間が足りず、スライド2枚分をカットすることに(テクノロジー/メソドロジーの話と、名君/名人/名作の話)。といっても試しにシャドーで練習したときからそれはわかっていて、何しろ30分の枠なのに練習では60分以上も喋っていて、こりゃダメだわと。なのでこの場でちょっと補足します。

ソフトウェアエンジニアリングにおいて、テクノロジーとメソドロジーはどちらも日本語では「技術」と言われます。区別して訳すならテクノロジーは科学技術、メソドロジーは方法論です。例えば静的コード解析ツールやテスト実装・実行ツールはテクノロジー、ゆもつよメソッドやアジャイル開発はメソドロジーです。ソフトウェアエンジニアリングは両方によって成り立っています。そして更に、ソフトウェアエンジニアはどちらを好むかという嗜好があると考えています。コンピューターに計算させたりハックしたりすることに興味を持つのか、概念のモデリングや人々が織りなす社会活動・プロセスとしてのソフトウェア開発に興味を持つのかという嗜好の違いがあると予想しています。WACATE等で出会ったテスター達は、どちらかと言えばメソドロジー寄りなのかな？という感触です。どうでしょうか？以前の私はメソドロジーにはあまり興味はありませんでしたが、今ではあまり偏りが無いかな…というのが自分の感覚です。

話し逃したことをもう一つ。名君/名人/名作の話。これはShu Uesugiさんオリジナルの文章*1を是非読んで頂きたいのですが、これも違いがあるということです。WACATE等で出会ったテスター達は、かなり名人志向だと感じています。私はこの中で選ぶなら名作志向で、あまり「この分野で一番になりたい」とか「負けたくない」とは思うことはそんなにありません。まぁそもそも意識高くないから3つのどれでもない説もありますけどね。

スライドにある項目それぞれについて私のポジションを以下に示します。

• 業種：情報家電, 自動車, OA機器あたりのエリア
• 職種：品質を作る立場、品質を明らかにする立場の両方
• テストレベル：上下両方
• テスト・品質系：おかしいと思う
• テストの楽しさ・達成感：品質が向上されたとき
• きっちり網羅 vs サボりたい：サボりたい
• 無則とか探索とか：必要だとは思うけど好きではない
• テクノロジー/メソドロジー：あまり偏りは無い (以前はテクノロジー寄り)
• 名君/名人/名作：名作

…と述べたように、ソフトウェアエンジニアが置かれている状況から考えられる有効なエンジニアリングと、その人が行いたいエンジニアリングは同じとは限らないと思うんですよね。そして、そのポジションを表明しておくことはWACATEのように色々な背景を持った人々が集まる場では交流のために有効に働くと思うのですよ。あ、勿論「プロならやるべきエンジニアリングをやるべきだろう」という意見はあると思いますが、それはそれで別の議論です。

セッション終了後、「考えさせられました」「あれは同意です」などのポジティブな反応を頂き、何かしら価値を提供できたことに安堵しています。

BPPの選定条件とは

いやーそれにしてもポジションペーパー…立場表明書が選ばれるというのは他に経験が無いので面白いですね。一体皆さんどうやって選んでいるんでしょう？私は3回参加(3回投票)していますが、振り返ると、

• できるだけ初参加に近い人
• 背景・動機・これまでの活動・これからの活動に一貫性のある記載をしている人

という条件で選んでいました。背景と動機だけで活動を書いていない人、手書きなどでインパクトがあるだけの人は選んでいません。…という選び方をしていましたが、私の選んだ方は3回とも一位にはなりませんでした。まぁそんなもんでしょう。私もなぜ前回選ばれたのかはわかりません。特に狙って書いたわけでもないんですけどね。機会があれば教えてほしいものです。

夜の分科会：コードの美的感覚を語る会

WACATE本編では結構みっちりとしたグループワークと講義があるのですが、その後、お酒が入った宴会の更に後にも一部の参加者が打ち立てたテーマについて議論する"夜の分科会"と呼ばれる場があります。私も「最後だし何かやっておくか」という動機で "コードの美的感覚を語る会" を開きました。 このような分科会は幾つか開かれて、分科会オーナーでない人達は各自興味のある分科会へ参加します。が、コードの美的感覚を語る会にはあまり人が来ない！アピールの仕方が悪かったのか、コードと聞いて身構えてしまったのか。

ともかく少人数で議論したところ、その分非常に濃い話ができました。ここも詳細に書きたいところですが、さすがに1エントリに書くには長くなりすぎますので今回はやめておきます。一つだけ興味深い意見を出しておくと、「実務において美しいという言葉を使うのは説明すべきことから逃げている」があります。実務に関係の無い感覚的なゆるい話をしようというつもりだったのですが、がっつり実務に関係する議論になりました。疲れた…。

ゆもつよメソッド

さて、自分が出番の話はこれくらいにしてメインコンテンツについて書きます。ゆもつよメソッドはテスト開発方法論であり、漫然と手をつけると漏れや重複を起こしてしまいがちなテストすべきことを他人に説明できるように整理することを目的としており、ISTQBで言うところのシステムテストレベルにおけるテスト分析/設計・機能テストを主な対象としています。

2日間に渡る演習により、既存の資料 *2 *3 *4 だけではわからなかったことが色々とスッキリしました。ただ、テストカテゴリの必要性は実感としての理解には至りませんでしたが、これは場数を踏まないと理解できないことなのだと思います。あと、講義よりも演習の回答を見た瞬間が一番勉強になりました。「あぁ～こういうことを書くのね」と。*5

それにしても疑問に思うのは、ISTQBで言うテスト分析の必要性を肌感覚として理解している人ってどれだけいるのでしょうか。私は経験不足なので実感までは至っていません。恐らくその理解に至るためには

• 機能テスト向けのクラシックなテスト設計技法を常用し、それだけではダメだという痛い思いをしている。
• 色々なタイプの非機能テスト
• システム統合テスト以上のテスト計画

という経験が必要なのだと思います。それともそこまでの経験は必要無くて、普通のテスターなら皆わかっていることなのでしょうか？今度テスターに会うことがあれば聞いてみたいですね。

ありがとうWACATE

WACATEに参加するのはこれで最後にします。

• WACATEに頼らなくてもテストのことを学んだり、詳しい人にコンタクトできるようになった。
• 自分で企画したプロダクトを自分で開発することを目指しており、テスターを目指しているわけではない。

というのが理由です。現在は職務上ソフトウェアエンジニアリング方面に舵をきっており、半年程度はそれを続ける予定ですが、その後はBPPセッションのスライドで少しだけ登場した工作の方面にシフトしていこうと考えています。

以前はソフトウェアテストという技術分野があることを知らず、テスターが集まるコミュニティがあることも知りませんでした。デブサミは知っていてもJaSSTは知りませんでしたし、情報処理技術者試験は知っていてもISTQBは知りませんでした。テスターに対する誤解も大分ありましたが、スキルや志の高い方々との出会いにより、それも無くなりました。テストを学んだのは職務上必要になったからという理由がきっかけとして第一にあるのですが、それ以上にWACATEで出会った方々からの影響を受けたことが実に大きいと感じています。

私はこれで最後にしますが、周りにテストに興味がある人・開発経験はあるがテストの経験が無く悩んでいる人・技術者コミュニティにデビューしたい人がいればWACATEを薦めようと思います。

ありがとう！さようならWACATE！

*1:名君になりたいのか、名人になりたいのか、それとも名作を作りたいのか | Value Different

*2:A Test Analysis Method for Black Box Testing Using AUT and Fault Know…

*3:http://jasst.jp/symposium/jasst12tokyo/pdf/A2-6.pdf

*4:ソフトウェア・テストPRESS総集編：書籍案内｜技術評論社

*5:ちなみに私なら、仕様書に直接書いてある仕様項目と、仕様書以外のテストベースや経験から導き出したテストすべきことは分けて書く。その方がCPMから移行しやすい。

JaSST'15 Tokyo 感想 - 昨年よりは理解が進んだと思いたい

JaSSTソフトウェアテストシンポジウム-JaSST'15 Tokyo

へ行ってきました。2日目だけです。開催されてから幾分日があいてしまいましたが、得たことや思考のために残しておきます。

昨年も2日目だけ行きました。テスト設計コンテスト(テスコン)について肩すかしを受けたという旨の文章を書いたところ、関係者と思われる数名からTwitterでリプライを頂きまして、テスト実施とバグ検出に重きを置くテスティングライブからテスト設計に重きを置くコンテストに移ったという歴史がわかりました。

JaSST '14 Tokyo 感想 - テスコンとテストの人達とは。必要なのはロマンスとエンジニアリングだ。 - MassKaneko.Out

前回から1年経ったわけですが、その間に私はJSTQB FLの勉強をしてみたり*1、SQiPやJaSSTの論文を読んでみたり、昔の雑誌 を読んだりなどしてみたので、今回はもうちょっと理解が進むだろうと踏んだわけです。理解が進むだろうというのは、テスコンもそうですが、もっと言うと「テストをテーマにして大きなシンポジウムを開催できるほど人が集まるものなのか？」について理解が進むだろうということです。

タイムテーブルを見るとわかりますが、今回はセッションのサブタイトルがずいぶんくだけた感じになっていましたね。同じ時期に開催されるデブサミはちょっとずつ固くなっていると感じるのに対してJaSSTはやわらかくしていく方針なのでしょうか。1日目の基調講演、「ウェブよウェブウェブ」、「今夜ビジネスで比べてみました」の3つは聞きたかったのですが、普通に仕事してました。無念。

テスト設計コンテスト(テスコン)

2日目お目当てのテスコンです。テストベースは今回も自動販売機のようです。テスコンのセッションは9:00から始まるのですが寝坊してしまったので9:30ごろに到着。見ることができたのはT研, しなてす, TEVASAKIplus, 1年4組の4チームでした。

一応真剣に聞いてメモをとったつもりですが、時間の割にスライドの内容が濃くて理解し切れませんでした。プレゼンの後に展示されている成果物も読みましたが、どのように工夫したり苦労したりしたのかが読み取れないところもありました。

つたない理解の中での印象ですと、しなてすが手堅く、TEVASAKIplusがオリジナリティと説得力を兼ね備えていると思いました。テスコン参加の説明会ではTest.SSFのプロセスが紹介されるそうですが、TEVASAKIplusの説明にはそれらしい言葉が無く、テスト対象の設計・構造の理解を重視し、機能タイプの分類・脆弱性の発見・悪条件の導出をするという方法は理解しやすく、効果もありそうだと感じました。ただ、全ての思考の起点が機能なのは問題があるのではないかとも思いました。テストタイプによって思考の起点が機能かどうかって異なりません？まぁ、自動販売機の場合はそれで良いのかもしれませんが。

あと、しなてすのプレゼンに対して「テストアーキテクチャが低凝集・高結合になっているのではないか？」という質問があったのが印象的でした。仮にテスト設計にアーキテクチャがあってクラス図のような箱と線で表せたとして、ソフトウェアの設計のように高凝集・低結合が良いのだろうか？と考えさせられました。もしそのような原則があるのであれば、テスト設計についても七つの設計原理(富士通)みたいなものがあるのかもしれませんね。*2

テストに何が求められるのかをテストベースを分析して求めるプロセスと、テスト設計技法を使ってテストケースを求めるプロセスの間に、何か工夫をするプロセスがあった方が良く、それはテスターにとってのmaintainabilityとも言うべきテストの品質を確保するために行うプロセスだというのは直観的にはわかるのですが、それをテストアーキテクチャ設計と呼ぶのが良いのかはよくわからないんですよね。テスコンに出場してる方々は理解しているのでしょうか。*3

おっと、話がそれてしまいました。結果、優勝はしなてす、次点はTEVASAKIplusでした。おお、私の目に狂いは無かった！*4

 テクノロジーセッション：ソフトウェアテストの新潮流

「自然言語解析・人工知能・機械学習といった技術を用いたシステムの補助により、従来はベテランの経験が無いと勘付けなかったようなテストを、初級・中級者でも行えるようになる*5」とか、「昨今の計算機性能の発達により、"全数テストは不可能" の原則を覆えすことに挑む*6」とか、「レガシーコードを解析して期待値を自動的に生成する*7」といった一歩先を行っていると感じる内容でした。計算機にできることを増やして、人間しかできないことにフォーカスしようという思想が見えるようで好感度大です。

プレゼンの中で「テストにおいて人間にしかできないことが減っていくと、テスト技法よりもテスト対象や欠陥の知識が要求されるようになる。」と言われていましたが、先進的な技術をさんざん述べた後でなぜわざわざ当たり前のことを言うのだろう？と疑問に思いました。もしかして世のテスターの多くはテスト対象の理解や欠陥の知識が不十分でありながらテスト技法の知識だけはあってテスト活動を行っているのでしょうか。そうだとしたら憂慮すべきことかと思います。

クロージングパネル：Michael Bolton の言葉は非常にしっくりくる

クロージングパネルではデベロッパーとテスターの関係についてパネルディスカッションが行われました。エモい話とか組織論とかテスターを持ち上げる話なのかとボーっと聞いていましたが、Michael Bolton が出した図を見て目が覚めました。直観的にしっくりくるものだったからです。開発をするときのマインドセットとテストをするときのマインドセットの変化らしく、Critical Distance と題されていました。上の図は私のメモから起こした図なので間違っている可能性があるのですが、こんなような図でした。上下左右4つの文は、何かしら開発やテストをしたことがある人であれば、右の build some of it から時計回りに読めばわかるでしょう。そして、弧を描く複数の矢印の半径の違いは、恐らくテストレベルが高いほどマインドセットを切り替えたりテストで得られたことを開発に活かすのが難しいことを表しているのでしょう。例えば、自分が書いたコードの間違いにユニットテストで気づいて直すことよりも、受け入れテストレベルにおけるユーザビリティテストで「これはイケてないな」ということがわかって、それを開発にどう活かすのかを見出すことの方が難しい、ということを表しているのだと思います。

テスターとは何をする役目なのか、という話もありました。Michael Bolton 曰く、「テスターにはコードを書く権限も、予算を決める権限も、採用や解雇をする権限も、リリースの判断をする権限もない。ではテスターは何ができるのか。プロダクトのクオリティを明らかにすること、認識できるようにすることだ。」とのことです*8。これも納得です。うなずきながら聞いていました。決して期待値と出力を人力でベリファイするロールではないんですね。また、クオリティはどのロールが責任を持つのかという話もあり、デベロッパーだけでもテスターだけでもないという意見がありました。これも同意です。日本では「テスト・品質系」というくくりで職種や技術が語られることがありますが、あれには非常に違和感があります。だからSQiP2014のデベロッパー参加比率が低いのではないかと考えてしまいます。*9

あと、ささいなことかもしれませんが、ゲーム業界のパネリストの方がテストのことを「デバッグ」と呼んでいたのは非常に気になりました。JaSSTとは全く別の機会で他のゲーム業界の方も同じように「デバッグ」「デバッガー」という言葉を使っているのを聞いたことがあるので、ゲーム業界の習慣なのかもしれませんね。

Tester と テスター

先の話でテスターという言葉を使いました。もちろん Michael Bolton はカタカナではなく Tester という言葉を使っています。両方同じ意味と捉える方もいれば、違うでしょ？と思う方もいると思います。私は、日本と海外(どこの国々なのかはわからないが)の違いとして

• Tester：プロフェッショナル、エキスパートのニュアンス。
• テスター：システムテスト実行の人海戦術要員のニュアンス。

というニュアンスの違いを感じています。昨年のデブサミでDeNAの方が「テスターじゃない、テストエンジニアだ。」と語っていましたのを思い出します。*10

日本のソフトウェア開発現場で全体的にこのような認識がなされているのかはわかりませんが、もしそうだとすればテスト技術やテスターは(Tester であったとしても！)軽視されてしまうでしょう。

テストをテーマにして大きなシンポジウムを開催できるほど人が集まるものなのか？

実際に東洋大学の講堂を埋め尽くす人が集まっているのに何を言っているのかと思われるかもしれませんが、1年前の自分はそう思っていました。また、テスト専門の会社があることを初めて知ったときは非常に驚いた覚えがあります。テスト技術を多少勉強したり、WACATEに2回参加した後の今でも「なんだか不思議だなぁ」と思うところがあります。これについて少し考えてみます。考えるというか、深層心理を吐き出しているだけで整理ができておらず、専門家やテストが好きな方から見ると気分を害すかもしれません。

1. QAとかテスターとかその辺の人々による内輪感がある。品質を確認する側、管理する側の立場の人、SEPG、コンサルタント、研究者に偏っている気がする。
2. QAとかテスターとかその辺の人々が単にテストと言うとき、暗黙的にシステムテスト以上のテストレベルを指していると感じる。
3. 「どのようなプロダクトを作りたいのか？」という前提を全く共有しないままテストの話で盛り上がっているのを見ると空論に聞こえることがある。モデリングが好きなだけで何を作るかあんま興味無いんじゃないか、だとか。
4. バグを見つけるのが楽しいという感覚が全く理解できない。
5. 社会科学や心理学的な側面の話が多く、計算機やプログラミングっぽい匂いがしないと感じることがある。

これらは私の勉強不足による誤解かもしれませんし、単に趣向の違いかもしれませんし、もしかするとJaSSTなどの世界にとってまずいことかもしれません。1番目は結構まずいんじゃないかなと勝手に思っています。

とりあえず最近の自分にできそうなこととしては、次回のWACATEにデベロッパーを呼ぶことや、「テスターは刺身タンポポ業じゃないんだよプロなんだよ」と説くことですかね。

以上、JaSST'15 Tokyo の感想でした。昨年よりは理解が進んだと思いたいものです。

*1:合格しました

*2:しなてすには「テスト設計に凝集度や結合度なんてありませんよ」と真正面から跳ね返すロックな返答をして欲しかったのだが、そうはならなかった。

*3:もちろん決勝出場メンバーは理解して論を打ち立てているのだと思いますが、各チームがそれぞれテストアーキテクチャとは何なのか、どう表現できるのかを説明したときに、果たしてそれは同じ概念を指しているのだろうかと疑問に思ったりするわけです。

*4:前回もこんなことを書いたような…

*5:単に仕様書を食わせてあいまいな箇所を見つけるだけのツールなら以前からあった気がするので、これはもっと進んだことをやっているのだと思う。

*6:英語で Exaustive Testing と言うらしい

*7:本来ブラックボックステストで扱われるような期待値の推定のように聞こえたが自信なし

*8:通訳された発言を解釈して書いているので正確ではないかもしれません。

*9:ソフトウェア品質シンポジウム2014（SQiP2014）オープニング：SQiPの紹介

*10:Software Engineer in Test at DeNA

ソフトウェア開発などの技術書の整理

知り合いのソフトウェア開発の技術書を沢山持っている方がブクログを使ってそれらの技術書を整理していました。その方は私と同じ職種なのですが、所持している技術書の傾向が随分異なり面白いと思いましたので、私もブクログを使ってリストアップしてみました。といっても私の所持している冊数はその方の1/10程度ですが。結果は次の通り。

masskanekoの本棚 (masskaneko) - ブクログ

どのようなカテゴリを作るかというのは悩むところがあります。そして、どのようなカテゴリを作るかでその方の趣向もわかるのかなと思います。例えば私は「モデリング」「テスト」「品質」「プロセス」といった分け方をしていますが、これは「ソフトウェア工学」というだけでは分類が大ざっぱ過ぎると思うからです。人によってはこれは些細な問題であり、むしろ私が「プログラミング」に分類している書籍をプログラミング言語や実行環境別に分類したいという方もいると思います。

あと、せっかくなので簡単でもよいので振り返りのためにレビューを書いてみようと思うのですが、読み返さずにレビューを書けるほど覚えているものってそこまで多くないことに気付きました。あまり血肉になっていない証拠でしょうか…。まぁもう一度読みなさいということですね。

WACATE2014冬に参加しました

ソフトウェアテストの合宿型勉強会WACATEに参加しました。

詳しくは技術評論社ウェブサイトに記事を書きましたので、ぜひお読み下さい。

テストを学んでいない開発者に贈る「WACATE2014冬」参加レポート：レポート｜gihyo.jp … 技術評論社

技術系のウェブサイトに文章を載せるのはこれが初めてなのですが、また機会あれば書いてみたいと思います。

クソレビューアだらけのレビュー会をもう少し考える

クソレビューアだらけのレビュー会 という、はてな匿名ダイアリーのエントリがホットのようです。共感する方が多いのか、1日でブックマーク数が700を超え、結構な勢いでコメントがついています。

何を対象にしたどのような条件下でのレビューなのかを示す文脈は直接書いていませんが、

• ソフトウェア開発、システム開発における
• 欠陥の摘出を目的としたレビューであり
• レビュー対象はWord等のページ番号のある文書(仕様書や設計書)であり
• 少なくとも5名以上の同僚が集まる
• 対面の会議であり
• 文書の作成者が進行をリードするウォークスルースタイルで
• レビュアーはこの会議で初めて文書を読んでいる

ということが推測できます。

レビューのスタイル

であれば、もううまくいかないことは目に見えています。会議の場で初めて見る文書をウォークスルースタイルで作成者が頭から説明してゆくやり方は、設計の欠陥や仕様同士の矛盾などを見つけるのには向いていないでしょう。欠陥を見つけるには、レビュアーは自分のペースでページを行き来したり、ほかの文書と見比べたり、場合によっては紙に図を描いたりコードを書いたりした方が効果的でしょう。ウォークスルースタイルで事前に文書を配布していないと、そのような読み方ができず、欠陥が見つかりにくくなることが考えられます。

仕様書や設計書の欠陥摘出であれば必ずしも対面で会議する必要は無く、むしろ各レビュアーが自分のペースで集中してレビュー対象に向き合う時間をとり、その後で各レビュアーの指摘をまとめ、議論が必要となりそうな指摘内容があれば会議を開く方が効率的でしょう。また、誤字やフォントなどの体裁については、欠陥とは分けて記録しておいた方が欠陥の摘出に集中できるでしょう。体裁は簡単に指摘できますから、レビューした気になってしまいますので。

レビューには複数のスタイルがあり、ウォークスルーが悪なのではなく、目的よって向き不向きがあるので目的に合わせてスタイルを選びたいところです。

• カジュアルな欠陥摘出ならチームレビュー
• 厳格な欠陥摘出ならフェイガンインスペクション
• 教育や引き継ぎならウォークスルー
• コーディングならペアプログラミングかピアデスクチェック

といったところでしょうか。集まって読み進めるやり方しか知らないのであれば、ピアレビューでググるといいと思います。

各"クソレビュアー"の主観的ランク

これをわざわざ書くかどうか迷ったのですが、当の匿名エントリを読んだ感想の整理のために書いてみることにします。

○寒がり 

クソどころか超重要。寒暖を我慢したまま会議をするなんてバカげてます。

○レアケース厨 

悪魔の証明に類することを指摘しても意味はありませんが、レアケースであっても信頼性の向上に繋がりそうな指摘をして議論することは、そのレアケースを考慮する必要が無かったとしても有意義であると思います。

△ついていってない 

これはおそらく、スタイルがウォークスルーにも関わらずレビュアーが自分のペースで集中して読み進めているために起こるので、チームレビューであれば良いレビュアーになるかもしれません。

△体裁厨、用語統一厨、箇条書き過剰、寂しがり、目悪い、指摘曖昧系

文体をわかりやすくしたり、見栄えを良くすることも必要かと思います。こればっかりでは困りますが、別に良いのではないでしょうか。9ptだと辛いから11ptにしてくれとか。

△遅れてくる系 

これもウォークスルーをやめれば活躍する人かもしれません。

△寝てる

連日の疲れがたまっているのかもしれません。必須のレビュアーでなければそっとしておきましょう。

×成果物興味なし系

役立たずその1。居る意味が無い。ただし、レビュアーとしてマッチしていないだけで、この人がクソとは限らないことに注意。

×物忘れ激しい系

役立たずその2。居る意味が無いどころではなく害悪。レビュー以外でも迷惑をかけていそうです。

×PMO 「指摘密度が基準値に満たないので…

役立たずその3。非生産的な仕事をさせようとするクソパーソン。レビュー以外でも似たようなこと言いそうですね。

WACATE2014夏

日高屋でラーメン食ってるときに参加を決めた

3月、テストの人達の人物像を確かめるためにJaSST'14Tokyoへ行きました。収穫は多くありましたが一日見物したくらいでテストの人達とは何だかわかるわけもなく、消化不良感もありました。

JaSST '14 Tokyo 感想 - テスコンとテストの人達とは。必要なのはロマンスとエンジニアリングだ。 - MassKaneko.Out

そしてある日の夜22時、くたびれた体で汁なしラーメンを食べながらTwitterを見ていると「WACATE2014夏申し込み今日まで」との情報があり、迷いました。

WACATE受付締切あと2時間じゃん。冬だけだと思ってたけど、どうしよう。

— Mass Kaneko (@masskaneko) 2014, 6月 1

とりあえずTwitterでそれっぽい人達を探してみるとなんかマニアックでやる気あるっぽい方々が多くいそうだし面白いんじゃないかと。あと、私はテスト専門ではないのですが今のポジション的にはもうちょっとわかってないといかんという事情もあって参加することにしました。

といったところで汁なしラーメンを食べ終わりました。

改めて、ソフトウェアテストと自分

WACATEでは参加者がポジションペーパーをあらかじめ書くのが恒例のようです。40人以上が参加して1泊2日を過ごすワークショップですから、参加者同士のコミュニケーションが生まれやすいように配慮しているのでしょうね。

人によってはずいぶん気合の入ったポジションペーパーもありましたが私はいかんせん締切2時間前にラーメン屋で気付いた経緯もあり、そこまで凝ったものは作れませんでした。というか変に短時間で気の利いたことを書こうとしてちゃんと自己紹介を書けていませんでした。そこで改めてソフトウェアテストと職務上の自分との関係を簡潔に示してみることにします。

• 元々は開発者。テストでバグを出される側。出されるとげんなりする。
• システムテストを手伝ったこともあったけど自分はほとんどバグを見つけられなかったので、向いてないんだろうなと思った。逆にレビューではズバッと欠陥を見抜いたり、静的コード解析には強い興味があったりした。なので、Static Testingだけ尖ってる感じがある。
• なんやかんやで開発からコンサルティングをする立場になった。ソフトウェア工学のことなら何でも一通り押さえておかないといけなくなったけど、テスト…特にブラックボックス視点でのシステムテストはぽっかり穴が開いていた。
  ※他にも穴はあるけど特に苦手意識があった
• ふとした縁で何人かの識者と会ったことをきっかけに基礎を固めることにした。テストエンジニアと技術的な会話をできるようになっておこうと思ったからだ。とりあえずJSTQB FLのシラバスくらいは読んだ。他、色々調べたり手を動かした結果、テスティングはクリエイティブで発展している技術分野っぽいことがわかった。
• 生粋のSoftware Testerみたいな人を見ておこうと思ってJaSSTへ行き、WACATEにも参加することにした。

WACATEのワーク

Workshopなのでワークがあります。あるお題のアプリケーションのツッコミどころ満載な不完全な仕様書とテストケースからテストの意図をリバースするというのが今回のテーマでした。これを数名のグループで一泊二日どっぷり取り掛かるわけです。リバースの手法としては「ゆもつよメソッド」(の一部)を使って機能：テストカテゴリの表を作り、意図が書いていない既存のテストケースをはめこんでいくというものでした。

私としてはトップダウンでテスト分析するより、具体的なテストケースから抽象的なテスト条件に汎化させて更にそれらをカテゴライズしてテストカテゴリを導き出す方がやりやすいかなと思いました。テストカテゴリは全然思いつきませんが「確認しておいたほうがよいこと」「懸念・心配すること」の方が先にどんどん思いつきますから。テスト対象のプロダクトに馴染みがあり、論理的機能構造(入出力・変換・貯蔵…)や品質モデルを理解していたとしても、テストカテゴリっていきなりは出てこないと思います。リバースの方がしっくりきました。

グループワークとしては機能の抽出ですらなかなかモメたりして「うまくいかんもんだなー」と思ったりしましたが、お題のドメインに親しみがあったのがグループで私しかいなかったようなので致し方なしかな。でも凄く良いワークだと思いました。

※参加者向け：惜しむらくはリバースではなくトップダウンで仕様から入ろうと思えば入れたところでしょうか。あのお題の仕様書がもっと欠落していれば、よりリバースっぽい作業ができたのでは。お題を作る側としては相当バランスに悩んだと思いますが。どうでしょうか。

WACATEの人達と雰囲気

参加者は実行委員を除いて50名近く。初参加は約半数。でしたっけ。とにかく皆さん自発的に来ているだけあってかとても熱い感じです。かなり遠くから前泊して参加した方も結構いらっしゃったようです。あと、フレンドリーな方ばかりでしたから初参加でも全然問題ないと思いました。

ポジションペーパーを見る限りでは、職種の分布は「テストエンジニア・QA(9)」「開発(3)」「コンサル・研究(1)」ってところでしょうか。業界はバラバラのようです。とりあえずワークのグループメンバーはステートマシン図にはあまり馴染みがないようでした。

ワークのテーマが派生開発を背景にしているからでしょうか、XDDPの生みの親である清水吉男さんがいらっしゃいまして、参加者の多くが知っていそうな感じなのが結構意外でした。組込み分野以外ではあまり認知されていないと思っていたのですがそうでもないようです。そういえばこの間のAFFORDDに行けなかったんですよね。あいにく旅行がかぶってしまいまして。おっとこれは関係ない。

1日目のワークが終わり、夕食からは酒が入って皆さん饒舌になっていきます。ワークが終わっても「夜の分科会」なるものがあり、個々人の嗜好別に何かしらのテーマについて議論します。探索的テスト好き集まれーみたいな感じ。更に夜が更けると寝る人と寝ない悪い人に分かれます。私は分科会が終わって目がさえてしまったので寝ない悪い人を選びました。ここから先はもうただの酔っ払い同士なのですが、それでもまだ技術の話が続くわけですね。「テスターはコードの品質には興味ないんですよ」なんて話も聞いて、それはもう大ショックを受けてMPが0になりましたが私は元気です。

そうそう、あとJaSST'14Tokyoで見た参加者の声を自由に書けるようなボードに「バグ出しは楽しい！」って書いてあるのを見て「正気か？」って思っちゃったんですよ。だってバグなんですよ？ダメなことがわかるんですよ？仕事増えるんですよ？凹むじゃないですか。で、WACATEにはバグ出しが楽しい人が沢山いると思って何人か…7人くらいかな…に聞いてみましたところ、目を輝かせて「楽しいよ！」と語る方と「うーん？」という方に分かれました。ちなみに自分がもしテストエンジニアだったら、エンドユーザーの利便性に大きく関わるバグを技術を使って見つけて、更に直ったところまで見届けて、できれば自分で直せれば楽しいですね。見つけること・出すこと自体は特に惹かれません。ここは分かれると思います。人それぞれの嗜好の背景を聞くのは好きなのでまたWACATEみたいな層と会うことがあったら聞いてみたいと思います。

行ってよかったですか？2014冬は参加しますか？

参加費22000円はものすごく割安だと思います。迷ってたら行くべし！ 参加者の方々、実行委員の方々、講師・ゲストの方々、貴重な機会を頂きありがとうございました。

といいつつ何回も参加するのが吉なのかは測りかねているところもあるのですが、冬のWACATEは夏とはプログラムの組み方が違うらしいので今のところは参加しようと思っています。

願わくばこのエントリが未来のテストエンジニアの背中を押せるかどうかはわからんけど何かの役には立ちますように。

個人的ソフトウェア世界マップ

※無知な人が勝手にソフトウェア開発の世界を1枚に描いてみたってだけのエントリです。

「多様さをスパッと描きたい」などと供述しており

ソフトウェア開発業界って言っても色々あると聞きますし実際そう思います。遠い世界の人と話すときに文脈や単語が通じてているのか怪しい場面を経験したことはないでしょうか。それは、エンドユーザー・開発環境・アーキテクチャ・ありがちなバグ・チーム内のロール・文化的習慣…などがきっと様々だからなのでしょう。

ゲーム業界の方はプロマネではなくディレクターと言うでしょう。ウェブシステムに馴染みの無い方にはデプロイという単語は通じにくいでしょう。「毎回DBを読みにいくウンコードが…」という愚痴に耳を傾ける組込マーは頭の中でフラッシュメモリへの無駄なアクセスに置き換えているかもしれません。

オープンな勉強会やカンファレンスに参加したりするとその多様さが良い刺激になります。時々その多様さを一枚に表せないか？と思うことがあるんですね。世の中には一体どんなソフトウェア開発の世界があるのかという分類は時々目にしますが、絵に描かれたものが無かったので試しに自分で描いてみることにしました。

*1 *2 *3 *4 *5 *6  

描いちゃった

はい、いきなりですがドーン。

え、ほんとにこうか…？これでいいのか…？「私からはこう見えてる」ってことを図示できればそれで良いという勝手な趣旨だからいいんですけど、一応パブリックな場に出すとなると躊躇しなくもない。ま、恥はかきすて。ブログも書き捨て。あまり気にしないことにします。

comsumer, enterprise は一般人向けか法人向けかという軸です。鉄板な軸の一つだと思います。そしてちょっと説明が必要そうなのは縦軸です。この縦軸は計算機の抽象度・汎用/特定用途・マシンパワーを表しています。上がクラウド・スパコン、真ん中がPC、下が組込みというイメージです。

ウェブ系とかエンプラ系っていう言い方はこの図だと…

で、一般的にはもっとざっくりした分け方されてますけど、私的にはこんな図を思い浮かべてます。エンタープライズ向けのウェブシステムが両者の重なる部分になります。クラウドの登場でSIerがヤバいなんて話もこの重なる領域かと思います。ゲームはコンソール・アーケード・PC・ウェブといった幅広いスペックの計算機で動くものがリリースされていますので、ウェブと組込みに重なる部分を設けています。組込みはコンシューマー・エンタープライズの両方をカバーしています。

オチはあるの？ 

 今日のところはこれで勘弁してください

*1:エンタープライズ系とウェブ系 (2014)もうちょっとなんとかなるのでは？と思ったのも図示することの動機です

*2:クラウドがもたらす破壊と創造 = Developer Summit 2014 = (2014)スライド22枚目。クラウドの利用領域の話なのでこの分け方なのかもしれない。

*3:組み込みソフトウェア業界というナゾの裏世界の話 - きしだのはてな (2014)裏世界じゃないよ

*4:「IT業界」なんて、ないんだよ。 - 思っているよりもずっとずっと人生は短い。)(2011)記憶に残るエントリの1つです

*5:組込み、エンプラ/IT系という分類で大丈夫？：森崎修司の「どうやってはかるの？」：ITmedia オルタナティブ・ブログ (2008)組込みだけ分類するなら良い軸だと思う

*6:5つの世界 - The Joel on Software Translation Project (2002)今読むと時代が変わったなと思う箇所がところどころ。