JaSST'14 Tokyoに行って来ました!

このエントリーをはてなブックマークに追加
こんにちは。
inomata@QAです。

今年もソフトウェアテスト最大のイベント、JaSSTに行って来ました。今年は会場を東洋大学へと変えての実施ですが、相変わらず大盛況のようでした。
私は3/7(金)の方に参加したので、早速レポートと行きましょう。(既に上がっている他のメンバーと内容が少しかぶってます。。)



基調講演:テストエンジニアのモチベーション
テストエンジニアのモチベーションを上げるには?というのものをいくつかのモチベーション理論を用いて考察するセッションでした。
現場のエンジニア、マネージャといった役割別、世界、アジアといった地域別に対して、仕事のやりがい、自主性のある仕事、仕事に対するフィードバックといったいくつかの要素にモチベーションが上がるのか、または下がるのかといった具体的な結果が示され、大変興味深いセッションでした。

いくつか面白い結果を。
・開発エンジニアは同僚からのフィードバックから受けるとモチベーションが下がる
これは、コードレビューなどのフィードバックととらえられ、コードを指摘される事でモチベーションが下がったのでは?と推測されていました。

・開発エンジニアはタスクに多様性があるとモチベーションが下がる
開発エンジニアはコードだけ書いていたいという事でしょうか。分かります。ただ、複数のプロジェクトに関わるとモチベーションが上がるようです。これは多くの役割でそう感じているみたいです。

・仕事の完了に対して、アジアの人は大きくモチベーションが上がる
アジアと世界で地域を分けた場合、アジアの方が大きく伸びていました。アジア以外は担当する仕事に関して割とドライなんでしょうか。

モチベーションをうまくコントロールするには、その人の仕事、役割、地域性を考慮するべきという結果がよくわかります。
モチベーションを挙げて、仕事の生産性をあげようというのが最終目的ですが、お金や恐怖支配では効果が無いとも言ってました。


テストアーキテクチャ設計の質について議論しよう

すでにJaSSTおなじみ智美塾のセッションです。
今回はテストケースリファクタリングというお題で、作成済みのテストケースを上手く使い回すには?という観点からテストケースの良い設計とは何か、というお話でした。

テストは「何を保証するのか」ということが重要です。つまり、そのテストは何を目的に作られたのかという事が、客観的に示されてなければならないのです。しかし、作成されたテストケースはその部分が書かれてない事が多く、作成者以外は何をテストされているか分からないという状態が起こります。
具体的な話では、現場ではテストケースを新規作成するよりは、前回のテストケースを参考に新機能のテストケースを追加したり、または関係ないテストケースを省いたりするわけですが、テストケースの目的がないと、何を追加したり削除すればいいのか話からいという事になってしまいます。

セッションでは、そんな不完全な(現場ではよくある!)テストケースを題材に、上手くテストタイプを分けたり、パラメータのバリエーションを増やしたりで、よりよいテストケースを作成していました。
手順としては
1.テストの目的を考えて分類する
2.目的の観点から、パラメータや条件のバリエーションを増やしていく
3.さらに観点が抜け落ちてないかを考える
といった感じです。
とにかく重要なのは、「なんの目的でテストしているのか」を誰が見てもわかるようにすることです。興味深く感じると同時に、身につまされる思いです。。


上流工程からの信頼性向上を目指す「形式手法」のご紹介」

形式手法という方法を用いて仕様書を作成し、上流工程から品質をあげようという話でした。
形式手法とは論理学や数学を用いて、あいまいさのない仕様を作ろうという事みたいです。(詳しくはgoogle先生へ。。。)昔からある手法ですが、実用は少ない様です。

事例としては以下を紹介していました。
・謀稼働中のシステムの仕様書を形式手法に変換してみたら、55件ほどバグらしき部分が見つかった。
・モバイルFeliCa IC チップのファームウェア開発は大々的に形式手法を取り入れた。

形式手法の適用は、あいまいさ排除や、仕様の不足分の気付きの助けになるということでしたが、このあたりはテスト技法のデシジョンテーブルでも同じ事が言えると思います。
このあたり上手く使って、上流から品質を上げていきたいところです。


よいテストプロセスの作り方
ISO/IEC/IEEE 29119 Software Testing Standardについての解説でした。
これはソフトウェアテストプロセスの国際的な規格です。今回来日されたStuart Reid氏が大きく関与して作成されています。(ISO/IEC/IEEE29119シリーズを作成しているISO/IEC JTC1/SC7/WG26のコンビーナ(議長)を務めている)
今回はパート2のテストプロセスに焦点を当てて解説していました。大きなポイントとしていくつか。

・テストのポリシーやテスト戦略は、共通化し組織で定義する。
プロジェクトごとに定義してるポリシーや戦略といった、より上位のレイヤーは先に定義しておこうという事と、上役への理解を得る事を明確にしています。

・リスクベースドテストの導入を明示している。
やったりやらなかったり?であろうリスクベースドテストの導入を明確にしています。この場合のリスクベースドテストは「リスクを識別し、優先度をつけて全て実施する」というものです。決して「リスクを識別し、リスクの低いものはやらない」という事ではありません。

自組織のプロセスを改善しようと思ったら、これは大きく参考になりそうです。特にドキュメントに付属してる導入事例が豊富で、ウォーターフォール、アジャイルといった開発手法の事例もあるみたいです。
また、導入のポイントとしては、あくまでも改善しようと思った時に適用すればよく、出来るものからやっていけばよいとのことです。というのも、現在の業務と29119はかけ離れている部分が多いと予想されるので、そのあたりの調整も上手くやる必要があります。

29119に関しては、有志で勉強会も開催されているようなので興味のある方は参加されてみてはいかがでしょうか。

各セッションの資料はJaSSTのwebページで参照できるようになると思いますので、ぜひ見てください。このほかにも興味深い話がいくつもあると思います。
JaSST'14


以上、簡単ですが参加したセッションのレポートでした。



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