BT

InfoQ ホームページ ニュース State of Testing 2015報告書が公開

State of Testing 2015報告書が公開

ブックマーク

原文(投稿日:2015/07/02)へのリンク

state of testing 2015 report”は,テストに関する今年の調査結果を公開した。PractiTestのJoel Montvelisky氏とTea-Time with Testersを主催するLalit Bhamare氏が取りまとめたものだ。テストの技術やプラクティス,自動化の採用状況に加えて,テスト担当者が直面している課題に関する見識を与えてくれる。

調査は“state of testing 2013 report”に続いて,今回で2回目の実施となった。InfoQは主催者である両氏にインタビューした。

InfoQ: 2015年の調査結果を2013年の調査結果と比較した場合,主な変化点はどのようなものでしょう?

Joel Montvelisky: テスト担当者の一般的な感覚として,作業はよりセキュアであるべきという方向性を示すような回答の変化がありました。アジャイル原則の適用範囲がさらに拡大したこと(ほとんどの組織で標準となってきています)や,アジャイル開発環境でテスト担当者として成功する上で必要なテスト技術や方法論(自動化の促進,よりリーンなテスト,開発者との直接的なコミュニケーションなど)を示す,業界レベルの変化も確認できると思います。

Lalit Bhamare: 前回の結果と比較して,複数の分野で,多くのテスタが“自己認識の向上”や“テスト担当者の考え方”を習得している,という変化が見られます。それはつまり,各分野でのテスト担当者の業務や役割,重要性に対する認識が向上していること,そして何よりも重要なのが,問題解決においてより能力を発揮するために必要な,問題領域に対する認識が向上していることを示すものだと思います。今挙げたような大きな変化が,調査結果全体を検討することで確認できます。14ページと15ページをご覧ください。そこでのコメントは,テスト担当者がさまざまな面で進歩していることを反映しています。雇用に対する態度の変化に注目してください!そう,それが先程の“大きな変化”のひとつです。さらに,テスト担当者がテスト業務に対してどのような変化を望んでいるのか,という部分も見て取れると思います。彼らの意識や考え方にも,それが反映されています。このような変化が明らかになったのは,よいことだと思います。

InfoQ: 調査では,テスト担当者の37%が要件収集に関与している点に言及していますが,彼らが関与することのメリットについて,詳しく説明して頂けますか?

Lalit Bhamare: 個人的な経験から言えるのは,テスト担当者が要件収集に関わらない場合,テスト対象のソリューションの実装が間違っていたり不完全であったりするだけでなく,要件のソリューション自体が間違っていたり不完全であったりすることが普通なのです。時間の無駄ですし,もちろんお金も無駄になります。テスト担当者が要件収集に関わることで,手遅れになったり,コストを要する問題になったりする前に,要件を注意深く解析できるようになります。リスクについて,どうやって知らせてほしいですか?“この先に落とし穴があります。注意してください”,という方法でしょうか,それとも,“みなさん,落とし穴に落ちました” ... ですか?テスト担当者が要件収集に関与するのかどうかで,このような大きな違いが生まれるのです。

私の意見としては,37%はまだ少なすぎる数値です。ですが,要求収集への関与が求められるようになったのは嬉しいですね(15ページ)。この方向での本当の変化は,テスト担当者が要件収集に関与することが疑問に思われなくなった時に起きるでしょう。

Joel Montvelisky: Lalitが強調していた“テスト担当者の要件収集への関与が37%”というのは,私も低過ぎる数字だと思います。まずはそれを言いたいですね!

私の気持ちとして,私たちが開発環境内においてユーザ側の立場であるという事実を考えれば,テスト担当者が要件収集プロセスで果たすべき役割はもっと大きなものだと思います。私たちはもっとエンドユーザや,要件プロセスとの結び付きを強くしなくてはなりません。

質問に対しては,テスト担当者が要件収集プロセスに直接的に関与することで,文章になった“無味乾燥な要件”だけでなく,その要件が求められた状況についても把握できるから,とお答えしたいと思います。この“味付け”は,要件をさらに詳しく解釈する必要のある時,特に要件やユーザストーリを同じ機能の異なる実装に展開しようとする時には,非常に重要な意味を持ちます。

InfoQ: 今回の調査から,テスト担当者の作成するドキュメント量が少なくなっていることが分かります。これについて説明して頂けますか?

Joel Montvelisky: 2013年の最初の調査や今年初めの調査に比較して,回答数が大幅に増えている点も認識しておかなくてはなりません。現実に起きていることが,以前より明確に読み取れるようになっただけかも知れないからです。

あるいは,もしもこの結果が回答数の影響によるものではなく,実際にドキュメントが少なくなっている(但し,ドキュメント内容の内部比率は維持されている)のだとすれば,開発者コミュニティ全体がアジャイルやリーン環境を目指して移行しているために,直接的な対話が優先されて,ドキュメント作成が抑制される方向にあるのかも知れません。

この件については,今後の調査でも引き続き確認して,これが継続的なトレンドであるかどうかを見極めた上で,背後にある根本的理由を探す必要があると思います。

Lalit Bhamare: よい傾向だと思いますね。従来から,テストのために割り当てられた100%の時間中,実際のテスト実施に使用されるのはわずか30%(程度)でした。残りの70%は,コンプライアンスやトレーニング,監査などを目的とした大量のドキュメンテーションなど,不要な作業で浪費されているのです(13ページの“Test Team Challenges”をご覧ください)。コンテキスト駆動テストのプラクティスとアジャイル/リーン方法論の台頭によって,テストを担当するグループが,その状況において適当な(基本的に従来より少ない)ドキュメント作業を行って,意味のあるテストにより多くの時間を充てることの価値を認識したのだと思います。これはまた,テストの担当者が,時間を使わずにテスト作業を文書化するスマートな方法を理解していることも示しています。

さらに詳しく話せるなら,このような組織やテストグループは,“少ない労力で多くの成果を上げる(doing more with less)”方法を体得していると思われます。よい兆しですね。

InfoQ: テストチームが直面している主な課題は何でしょう?それらを一般的に扱う方法はあるのでしょうか?

Joel Montvelisky: チームとマネージャにとって最上位の課題が組織拡大と時間に関するものあることは,レポートから非常に明確に理解できると思います。

組織の拡大は,優れたテスト技術者の雇用に関して報告されている課題に反映されています。原則的には,これはよいニュースだと思います。雇用に関して課題があるということは,優れたテスト技術者に対する高いニーズがある,という意味だからです(これはテスト,特に手動テストを衰退技術と考えていた人たちに言いたいですね)。

第2の課題は時間枠に関するものです。繰り返しになりますが,私はこれも,世界がリーンやアジャイルプラクティスに向かっているという事実に関連したものだと思っています。このアプローチは,テストサイクルは長く包括的なものであるというこれまでの仮定に疑問を呈して,これまでよりもリスク分析や自動化,開発テストを基本とした作業,それによるテスト時間全体の削減という,現実問題の場に私たちを置きます。

Lalit Bhamare: 1行でまとめるならば,主な課題は“少ない労力で大きな成果を上げる”ことだと言っていいでしょう。つまり,より多くの(意味のある)テストをより短時間で実施する,より短時間でより多くの障害を検出する,より少ない予算でより効果的なテストを実施する,効果的なテストをより少ない人数で実施する,より効果的なテストをより不確定な情報で実施する,といったことです。

テスト担当者の大多数がそれを扱う方法を見つけているかどうか分かりませんが,私の知る中では,彼らは,Rapid Software TestingContext Driven Testingの原則に従うことで,このような問題を解決しようとしています。

InfoQ: テストはさらにアジャイルになるのでしょうか?

Lalit Bhamare: 残念ですが,自信を持ってそうだとは言えません。大きな理由は,私やあなたにとってのアジャイルと,回答者が自分なりに考えたアジャイルが違うかも知れないからです。スタンドアップミーティングをしているからアジャイルだという人もいれば,スプリントでソフトウェア開発をするから,専用ツールを使っているから,という理由の人もいます。たまたまスクラムあるいはアジャイルチームの一部として仕事をしていることから,自らをアジャイルテスタと呼ぶ人もいます。ですが,それらのことを行うから,アジャイルでテストしているのでしょうか?私はそうは思いません。 おそらくは”テストは真のアジャイルになっていますか?”という質問の方がよいのでしょう。テストを真のアジャイルにする要因は何なのでしょう?

少なくともテストのコンテキストでアジャイルを語るのならば,アジャイルの意味について,私たちの産業が共通の結論に達しておく必要があったと感じています。今後の調査ではこの部分をカバーして,もっとクリアな結果を得られるようにしたいと思います。簡単ではないことは確かですが。

Joel Montvelisky: 私としては,回答者の88%がアジャイル方法論をベースとした作業をしている(2013年の78%から増えています)ことを示しているレポートの11ページから,企業がよりアジャイルへと転向していることは間違いなく事実であると思っています。とは言っても,アジャイルの解釈が人それぞれだというLalitの意見には同意しますが,私はそれ自体が悪いことだとは,100%思ってはいません ...

世の中は,私たちがこうあって欲しいと願うよりも,いつも複雑だと思います。この質問に対する回答の選択肢が複数あるのも,その理由からです。ですから,88%が手に手をとってアジャイルで作業する一方で,42%はウォーターフォールあるいはそれに類するもの,15%は自分たちの“独自モデル”,さらに6%はモデルあるいは原則に基づいていない,という結果なのです。

この結果はさまざまに解釈できますが,私がより正確だと思うのは,大部分の人々や組織が新しいことを導入しようと試みている一方で,実際の作業の変革は緩やかだ,ということです。

同じように興味深いのは,今日すでに14%の回答者が,DevOpsに基づいた作業を始めているということです。これはアジャイルへと続く変化だと解釈していますので,これが来年も続くトレンドなのかどうか,注目してみるのも面白いと思います。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT

あなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。

Eメールを変更すると確認のメールが配信されます。

会社名:
役職:
組織規模:
国:
都道府県:
新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。