MassKaneko.Outスマートフォン用の表示で見るMassKaneko.Out2015-06-24最後のWACATEあらすじWACATEという一泊二日で行うソフトウェアテストの勉強会があります。夏と冬の年2回行われており、もう何年も続いています。「1回くらい行ってみるか」という気持ちで参加したのが2014夏、「冬は夏と違う」という情報を聞いて参加したのが2014冬、そしてそこで賞を頂いて講演を条件に無料で参加したのが今回2015夏です。賞というもので、参加申し込み時に提出したポジションペーパーの中から参加者投票によって選ばれた一位に贈られる賞です。いうわけでお話をする機会を得られました。決まったので、「自分のセッションだけ浮いたことをやってもなぁ」と思い直し、最終的に「ポジションペーパーで選ばれた人のセッションなんだからポジションのお話をしよう」というシンプルな?考えに至り、上記スライドのような内容にしました。Talk)がBPPにかけてあることや、「そもそもポジショントークなのにBiasedって何だよ」というツッコミを待っていたのですが全くなく、無力感でいっぱいです。業種や職種などのポジションと聞いて語りやすいところから始め、テストに関して意見がこう分かれるだろうなぁと私が想定している点を、聴講者にほぼ二択で突いてゆくというスタイルでお話しました。予想通りなことも、そうでないこともあって面白かったですね。賢くサボりたい"では、「半々くらいかなぁ」と予想していましたが、賢くサボりたい派の方が優勢でした。そんなこんなで気分良く話していたら時間が足りず、スライド2枚分をカットすることに(テクノロジー/メソドロジーの話と、名君/名人/名作の話)。いっても試しにシャドーで練習したときからそれはわかっていて、何しろ30分の枠なのに練習では60分以上も喋っていて、こりゃダメだわと。この場でちょっと補足します。ソフトウェアエンジニアリングにおいて、テクノロジーとメソドロジーはどちらも日本語では「技術」と言われます。区別して訳すならテクノロジーは科学技術、メソドロジーは方法論です。静的コード解析ツールやテスト実装・実行ツールはテクノロジー、ゆもつよメソッドやアジャイル開発はメソドロジーです。ソフトウェアエンジニアリングは両方によって成り立っています。ソフトウェアエンジニアはどちらを好むかという嗜好があると考えています。コンピューターに計算させたりハックしたりすることに興味を持つのか、概念のモデリングや人々が織りなす社会活動・プロセスとしてのソフトウェア開発に興味を持つのかという嗜好の違いがあると予想しています。WACATE等で出会ったテスター達は、どちらかと言えばメソドロジー寄りなのかな?という感触です。?以前の私はメソドロジーにはあまり興味はありませんでしたが、今ではあまり偏りが無いかな...というのが自分の感覚です。話し逃したことをもう一つ。名君/名人/名作の話。Uesugiさんオリジナルの文章*1を是非読んで頂きたいのですが、これも違いがあるということです。WACATE等で出会ったテスター達は、かなり名人志向だと感じています。私はこの中で選ぶなら名作志向で、あまり「この分野で一番になりたい」とか「負けたくない」とは思うことはそんなにありません。そもそも意識高くないから3つのどれでもない説もありますけどね。スライドにある項目それぞれについて私のポジションを以下に示します。(以前はテクノロジー寄り)名君/名人/名作:名作...と述べたように、ソフトウェアエンジニアが置かれている状況から考えられる有効なエンジニアリングと、その人が行いたいエンジニアリングは同じとは限らないと思うんですよね。そのポジションを表明しておくことはWACATEのように色々な背景を持った人々が集まる場では交流のために有効に働くと思うのですよ。あ、勿論「プロならやるべきエンジニアリングをやるべきだろう」という意見はあると思いますが、それはそれで別の議論です。セッション終了後、「考えさせられました」「あれは同意です」などのポジティブな反応を頂き、何かしら価値を提供できたことに安堵しています。BPPの選定条件とはいやーそれにしてもポジションペーパー...立場表明書が選ばれるというのは他に経験が無いので面白いですね。背景・動機・これまでの活動・これからの活動に一貫性のある記載をしている人という条件で選んでいました。背景と動機だけで活動を書いていない人、手書きなどでインパクトがあるだけの人は選んでいません。...という選び方をしていましたが、私の選んだ方は3回とも一位にはなりませんでした。私もなぜ前回選ばれたのかはわかりません。狙って書いたわけでもないんですけどね。機会があれば教えてほしいものです。夜の分科会:コードの美的感覚を語る会WACATE本編では結構みっちりとしたグループワークと講義があるのですが、その後、お酒が入った宴会の更に後にも一部の参加者が打ち立てたテーマについて議論する"夜の分科会"と呼ばれる場があります。このような分科会は幾つか開かれて、分科会オーナーでない人達は各自興味のある分科会へ参加します。コードの美的感覚を語る会にはあまり人が来ない!アピールの仕方が悪かったのか、コードと聞いて身構えてしまったのか。少人数で議論したところ、その分非常に濃い話ができました。ここも詳細に書きたいところですが、さすがに1エントリに書くには長くなりすぎますので今回はやめておきます。一つだけ興味深い意見を出しておくと、「実務において美しいという言葉を使うのは説明すべきことから逃げている」があります。実務に関係の無い感覚的なゆるい話をしようというつもりだったのですが、がっつり実務に関係する議論になりました。ゆもつよメソッドさて、自分が出番の話はこれくらいにしてメインコンテンツについて書きます。ゆもつよメソッドはテスト開発方法論であり、漫然と手をつけると漏れや重複を起こしてしまいがちなテストすべきことを他人に説明できるように整理することを目的としており、ISTQBで言うところのシステムテストレベルにおけるテスト分析/設計・機能テストを主な対象としています。わからなかったことが色々とスッキリしました。テストカテゴリの必要性は実感としての理解には至りませんでしたが、これは場数を踏まないと理解できないことなのだと思います。あと、講義よりも演習の回答を見た瞬間が一番勉強になりました。「あぁ~こういうことを書くのね」と。*5それにしても疑問に思うのは、ISTQBで言うテスト分析の必要性を肌感覚として理解している人ってどれだけいるのでしょうか。私は経験不足なので実感までは至っていません。その理解に至るためには機能テスト向けのクラシックなテスト設計技法を常用し、それだけではダメだという痛い思いをしている。色々なタイプの非機能テストシステム統合テスト以上のテスト計画という経験が必要なのだと思います。それともそこまでの経験は必要無くて、普通のテスターなら皆わかっていることなのでしょうか?今度テスターに会うことがあれば聞いてみたいですね。ありがとうWACATEWACATEに参加するのはこれで最後にします。WACATEに頼らなくてもテストのことを学んだり、詳しい人にコンタクトできるようになった。自分で企画したプロダクトを自分で開発することを目指しており、テスターを目指しているわけではない。現在は職務上ソフトウェアエンジニアリング方面に舵をきっており、半年程度はそれを続ける予定ですが、その後はBPPセッションのスライドで少しだけ登場した工作の方面にシフトしていこうと考えています。以前はソフトウェアテストという技術分野があることを知らず、テスターが集まるコミュニティがあることも知りませんでした。知っていてもISTQBは知りませんでした。テスターに対する誤解も大分ありましたが、スキルや志の高い方々との出会いにより、それも無くなりました。テストを学んだのは職務上必要になったからという理由がきっかけとして第一にあるのですが、それ以上にWACATEで出会った方々からの影響を受けたことが実に大きいと感じています。私はこれで最後にしますが、周りにテストに興味がある人・開発経験はあるがテストの経験が無く悩んでいる人・技術者コミュニティにデビューしたい人がいればWACATEを薦めようと思います。Know...*3:http://jasst.jp/symposium/jasst12tokyo/pdf/A2-6.pdf*4:ソフトウェア・テストPRESS総集編:書籍案内|技術評論社*5:ちなみに私なら、仕様書に直接書いてある仕様項目と、仕様書以外のテストベースや経験から導き出したテストすべきことは分けて書く。その方がCPMから移行しやすい。月別アーカイブリンクヘルプはてなブログお知らせはてなブログをはじめよう!masskanekoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。