WACATE 2014 冬に参加してきた

最近常々思うのですが、テストエンジニアも役割が細分化されて、役割が再定義される時代がすぐそこそうですね。開発者が、xxx(特定の言語)エンジニア、サービス開発エンジニア、インフラエンジニアなどのように区分して呼ばれるように。例えば、最近、テスト自動化エンジニアと呼ばれる人たちが出てきましたが、それもその一つだと思います。

さて、話題は変わり、12/6、12/7の2日間で開催されたWACATE 2014 冬に参加してきたのでその話をまとめます。1ヶ月くらい経ちましたが、ようやっとブログポストになります。。。Twitterにおけるハッシュタグは #wacate だそうです。

WACATEとは

WACATEは「Workshop for Accelerating CApable Testing Engineers」の略で、「内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ」という意味です。

前々から日程が合えば参加してみたいと思っていたのですが、日程が合わず今回初参加。初参加ながらも、分科会をさせていただきました。

ここでふと疑問に思うのが、若手の定義です。こちらのCIAの資料によると、日本の平均年齢は46.1歳のようです。そこから考えると、30代までが若者といっても良さそうな範囲ですね。

なお、WACATEとはによると 35歳以下 だそうです。

内容

ポジションペーパーセッション

参加時にポジションペーパーを提出するのですが、それらをまとめた冊子が配られます。


STORY描けてますか??~計画にSTORYを描こう~: 高橋 一勢 氏

テスト計画から実施、完了までのStoryの話をしていました。
スライドが見つからなかった…

内容自体は、開発全体の流れの中で計画を立てる。その計画に、期間の間のいつ何やろうという具体的な話を混ぜる、というものでした。


ボクらのプロセスにきづこう: 川西 俊之 氏

“プロセス”自体に言及した話です。入力と出力の間を知ることで、システムとしてどのような処理が入っているかを考えることにつながる話しだったと思います。


モデル検査入門: 朱峰 錦司 氏

個人的に、モデル検査は気になるところでした。開発工程の中で得られる成果物のモデルに対して現在どのような手段で検証ができるのかを把握するのに役立ちます。

個人的に、レビュー自動化によるレビューアの負荷軽減や不具合作り込みの防止には興味あるので、面白かったです。


クラシフィケーション・ツリー法入門: 井芹 洋輝 氏

分類木や、そこまで整理されていなくてもにたような形でテストを設計することはよくやっていました。マインドマップを使ってどのようなテストするかとか。そういう設計をまとめてすごく分かりやすい形で整理されています。

今のモバイルアプリやWebアプリのスタートアップのような速さ求める職場だと、このくらいの気軽さで内容をまとめ、適宜更新できる形でないと、多くの場合はビジネススピードに対してテストの落とし込みが重たいのですよね…


バグ票をもっとうまく使うために: おうみ氏、ちかみ氏、すずき氏


はじめよう!レビューのいろは: 山口 寛子 氏


1段深い心で人と関わろう: 上條 飛鳥 氏

6つの帽子
http://newhabits.blog33.fc2.com/blog-entry-1168.html

ラポール = 信頼関係


ソフトウェア開発に必要な技術としてのコミュニケーション: 森崎 修司 氏

人月の神話やコンゥエイの法則のような有名な話を混ぜつつ、コミュニケーションにまつわるソフトウェア開発に関してお話されていました。


分科会

僭越ながら、分科会を主催させていただきました。いろいろ議論したのですが、ちゃんとまとまるところまではいきませんでした。疑問の発端が抽象的で、具体的な解に落とし込むことが難しい疑問だったので致し方なしですが。。。

参加していただけた方々、ありがとうございました。ほんとう。

一方で、スマホアプリやウェアラブルデバイスのような、サービス開発と密接に関わる領域に関係するテストエンジニアは、Business AnalysisやDesignへの知識も増やしていく必要があるのは必然なのかなと感じました。More Agile Testingで書かれているように。(その領域は世界的にも取り組まれている途中なのでよく分からないとう事実も…)

サービス開発xマルティデバイスに対するアプリ開発におけるテストエンジニアの価値は?

発端の問題意識として漠然とあったのは、サービス開発におけるテストエンジニアのスキルセットはどのようなものが必要なのだろうか?というものでした。受託開発とは異なり、サービス開発(自社)の場合は関わる人が様々なスキルセットを持って、ユーザに対して価値の高くなるサービスの開発を継続して行います。納品物の定義に沿ったものを作って終わり、という考えとは大きく異なります。少なからず、私が受託開発、サービス開発の両方を経験した上でもそこは強く存在すると感じました。

受託開発の場合、要求分析の能力やその定義の能力が入り口となり、発注者のサービスがどうこうまでは関与することはほとんどありません。その場合、テストエンジニアとしてのスキルセットもその限定された領域内の話になるので、要求定義やソフトウェアテストのスキルを磨くことになると思います。つまり、V&Vでいうverificatioの側面が強いように思えます。

サービス開発の場合、受託だと考える必要が小さかった サービス まで頭を回す必要があります。さらには、リリース後のユーザからのフィードバックの取り入れや、サービス開発者がユーザにどのような価値のある体験をしてほしいかに関しても考える必要があります。そういうと、V&VのVerificationはあくまでもきっかけで、Validationの領域を強烈に考える必要性も高いように思えます。

さらには時代はマルチデバイス(スマホやウェアラブルデバイス)に突入し、サービスを考える場合はそれらとも向き合うことは必須になりました。そんな中、テストエンジニアはどのようなスキルを持つ必要があるのか。どういう役回りを行う必要があるのか、ということに関してよく分からなかったので分科会を開かせていただきました。

(というか、直面しているのですよね…)

メモ

  • 非機能要件の、特に魅力的品質と呼ばれる領域の価値があがりそう。
    • 機能的要件や、非機能要件のパフォーマンスなどの仕様を満たすためのスキルはある程度取り組みが進んでいる
  • テストする人までに、ビジネス要件とか、上位成果物の情報が共有されない
    • 受託、委託系では特に
    • 企画/開発/テストが分離されている <=Agile開発でのバッドプラクティス
  • テストエンジニアの価値向上
  • テストエンジニアがサービスの立案、良し悪し?

最近発売された"デザイニング・マルチデバイス・エクスペリエン"を読んでみたのですが、事例も多くて結構面白かったです。同様にサービス開発に関わっている人は一読してみると良いと思います。多分、ここらへんの情報はテストエンジニアとしても頭に入れておく必要がありそうな箇所。

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s