JaSST'14 Tokyoに参加してきました!

このエントリーをはてなブックマークに追加
QAのkmtです。
年に一度のQAのお祭り、「JaSST'14 Tokyo」に参加してきました。

今年は目黒雅叙園から東洋大学に場所を移しての開催となったのですが、大学が広すぎて迷いました。
個人的にはもう少しナビゲーションがほしかったですが、真面目にきちんとが売りのQAの皆さんは時間どおりきっちり来ておられました。
結局大学を半周してたどり着いた頃には基調講演はだいぶ進んでおりましたが、、、



●基調講演:テストエンジニアのモチベーション


テストエンジニアのモチベーションはどこにあるのかといったことを各国のエンジニアに質問を行い、その解答からモチベーションをあげる方法はないかといったことを話されていました。

資料をみると、ヨーロッパ、オーストラリアのテストエンジニア、開発者が主で、アジアや北米の人数は少なかったようです。
割合でいうと 45%がオーストラリア、41%がヨーロッパ、アジア7%、北米4%、あとはその他です。
ちょっと偏ってますね。

職種に関しては、テストコンサル(8%)、テストアナリスト(24%)、テスト部長(6%)、テストマネージャー(24%)、テスター(12%)、開発(4%)、その他といった感じで、海外はテストの職種がきっち分かれているのだなあと思いました。あれもこれもやらなくていいのね、ウラヤマシイ・・・

企業の規模や業種、組織も資料にはありましたがここでは省きます。

いろいろな側面から質問をされたようですが、記憶に残った回答としては

-開発者は1つの業務に集中したいから他の煩わしいことからは解放されたい(まあ当然ですよね)
-アジアのテスターは途中で完了する前にプロジェクトから次のプロジェクトにいくのが好きではない
-金銭よりもやりがいを重視する
-開発者はフィードバックをもらうとモチベーションがさがるがテストアナリストはモチベーションがあがる

などほんまかいなといった内容もありました。
今後グローバル企業で人材を採用していくときにこのような傾向も参考にするといいのではないかといったところです。


事例紹介セッション:テスト設計のタイミングと手法の変更による品質向上と生産性向上

-テスト設計のタイミングをプログラムを組む前に設計段階からやる
-設計段階からやる場合に要因分析を行い、レビューなどでチェックパターンを最少にするための活動をする

それによって上流工程からバグを作りこまない、シンプルなコーディングを実現する
シンプルなコーディングの実現が無駄なリファクタリングを生みださない


といった内容でした。


最初からテスト設計を行い、その通りに実装するとテスト設計から漏れた部分がバグとして紛れ込まないかといった質問がでていましたが、あくまでも最初のテスト設計でテストするのはプログラム実装レベルの話で、それ以降のフェーズで別のテスト手法を使いバグが紛れ込んでいないかをテストしているんだそうです。

品質を学問的にやられている方からはいろいろ突っ込みどころもあるんでしょうが、実際開発現場にいると実践できるならばこの手法はとても有効だと思います。ただ、QAに最初からテスト設計できるスキルが必要なのとプログラムに対する知識が必要です。なので開発者にテスト設計のノウハウを伝授して実践してもらうのが現実的かと思いました。



事例紹介セッション:システムテストの自動化による大規模分散検索のプラットフォームの開発工程改善

複数のコンポーネントが相互作用しているシステムで最終段階で発見されていたバグをシステムテストを自動化することにより、バグ修正日数を減らすことができた事例です。

これを実行するために、チーム内に自動化の専門部隊を設けたそうです。
自動化の専門部隊は

-自動化の観点から設計や分析を行う
-自動化が実装できない場合はできるように依頼する
-自動化を作成する

などの活動を行っているそうです。

弊社でも自動化できない場合は、自動化できるようにプログラムを修正してもらったりしていますが、こういう文化が根付いていない組織では専門チームがなければ開発者に嫌がられてその箇所の自動化を作らない、無理やり自動化を作るために自動化を作成する工数がかかるなどがあるかもしれませんね。
まずは組織改革してから実践というのも効果的なんじゃないかと思います。

また、システムテスト段階での自動化は一般的に工数がかかるのですが、ドメイン固有テスト言語(DSTL)でテストを記述→自前のテストツールを作成することによりプログラマでなくてもテストが作成できるようになり工数削減できたそうです。

ツールを作成しない場合は、Cucumberのようなものを利用することも可能です。
弊社のある開発チームではCucumberを使用して機能テストを作成していますし、別の開発チームではApi専用のツールを作成してSeleniumと組み合わせることにより受入テストを実現しています。


専門部隊を設けたり、ツールを作成したりする活動と同時にテストと開発のサイクルにリズムを作ることも大切だとおっしゃっていました。
大規模開発でリズムを作るためには仮想化は必須ですね。
テストがどの環境でも流せるように環境情報を分離して3000件くらいのテストケースを並列実行して4~5時間流しているそうです。

弊社も現在環境情報を分離するプロジェクトを実施していてそれができればサーバ管理がとても楽になると思います。
テストケースの並列実行は同じような感じでやっているので自動化の王道はクリアできている感じです


●チュートリアル:Selenium WebDriverで学ぶ システムテスト自動化の第一歩

Selenium WebDriverでの自動化を行えるようになるためのレッスンでした。
開発者の皆さんからすると大変簡単な内容ではあるのですが、開発をしたことがない人に対して最初の一歩というのは踏み出しにくいものです。
困ったら自動化研究会の方がついてくださりアドバイスをくださるのでやりたい気持ちはあるけどどこからはじめていいのかわからない、周りに聞く人がいない方などはこのようなセッションに参加されるといいかと思います。
プログラム経験が全くないメンバーをこのようなチュートリアルに送り込むといい勉強になるのではないかと思います。


●パネルディスカッション:ソフトウエア発注側の品質戦略とテスティングに対する期待

ソフトウエア発注側の皆さんが実施しておられる品質戦略について、また、テスターに対して何が期待されているのかがディスカッションされていました。

昨年、「プロジェクト成功のために世界ではどうテストしているのか ~経営者が語るグローバルソーシングパネル~」にでたのですが大変面白かったので今年も楽しみにしていたのですが普段聞けない話がきけておもしろかったです。

あまり具体的には書けないのですが、

最近のQAエンジニアに対する期待は、

テストだけする人(ずっと昔のQA)
自動化もやってよQAエンジニアさん(2013年前後)
更に、カスタマーサポート、マニュアルもやってよQAエンジニアさん(イマココ)

てな具合にどんどんまかされる領域の幅が広がってきている感じです。

何でも屋的におしつけられているととるのか、自分の業務が広がるチャンスととるのかは考え方次第ですが、ただテストだけする単純作業に対しては今後ますます単価がさがり、トータルな品質サービスを提供する期待に応えられるQAエンジニアはますます重宝されるといった具合です。

エンジニアには開発だけさせたいといった声もありましたが、たぶんこの開発には以前とはことなってある程度のテスト工程というのが当然のように入っているんだと思います。
このように同じ、開発、テストといった言葉でも数年単位で求められる内容が異なってきているのでエンジニアとしてこのあたりも常にキャッチアップしておくといいと思います。

次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...