[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

(AD)

テストは増え続ける、でもボトルネックにはできない──テスト効率化の2つのカギを朱峰 錦司氏が解説!

【Session2】ツール活用によるシステムテスト活動の高度化とアジリティ向上

テスト効率化のカギとなる「テスト資産」とは?

 大規模アジャイルにおける課題について朱峰氏は対応方法を紹介する。1つめのアプローチはテスト資産管理の効率化だ。テストプロセス全体の流れを見渡すと、最初はテスト計画から始まる。リソースは有限なので、いかにコスパ良く実行できるか作戦を立てて(分析・設計)、テストケースに落とし込む(実装)。ここで自動化する場合もある。データや環境などの準備をしたうえで、ようやくテスト実行へと進む。実際は全てが計画通りに、1回でテストが通るとは限らない。どこかでバグが見つかり2周目、3周目の繰り返しを経て、最終的に全体を振り返ってようやくテストは完了する。

標準的なテストプロセス
標準的なテストプロセス

 この一連のプロセスの中で、テストで使うテスト観点、テストケース、テストデータといった成果物がテスト資産だ。

 そしてもう1つ、朱峰氏は「テスト結果もうまく扱っていくべき」と提言する。プロジェクトは繰り返し発生するため、過去のテスト結果をうまく活かすことで、以降のテストのアジリティを上げることができると期待できるためだ。

 朱峰氏によるとテスト資産管理に着目する理由は主に2点あるという。1点目は、仕様変更時の分析の効率化だ。日常的にテストを繰り返すなか、「今回は仕様のどこが変更されていて、どこか変更されていないのか」と、仕様変更が既存テストに与える影響を分析することは結構な手間になる。

 この作業を効率化するには「愚直に仕様とのトレーサビリティが取れるテストケースのバージョン管理が求められる。ここは何かしらの支援がないとテストエンジニアが大変になる」と朱峰氏は言う。何せテストは増え続ける。どこかバグがあると、テスト範囲を広げることにもなる。

 「そもそもテストは終わりのない活動なのでいくらでも増えてしまうが、ヒューマンリソースは有限」と朱峰氏は言う。どこかで増えたら、その分、どこかで減らすことも考えなくてはならない。

 それではどこのテストを減らせるか。これはテスト担当者としては苦渋の決断になる。削ったことでバグを見逃してしまったら……と想像するだけでも恐ろしい。

 そこで、テストを減らす判断の助けになるのが過去の実績だ。例えば過去10〜20回のテストで「この機能でバグは出ていない。安定している」ことが分かれば、テストを減らす判断の根拠にできる。朱峰氏は「過去のテスト結果はテストの数や分量を最適化するのに役立つのではないでしょうか」と提案する。

テスト資産管理のポイント
テスト資産管理のポイント

 絶え間なくプロダクトは進化する。それに伴い仕様も変化していく。仕様変更の影響分析をいかに迅速に行うか。そして増加の一途をたどるテストから、いかに不要なところを自信を持って削減させていくか。これらの課題を解決するにはテスト仕様とトレーサビリティも含めたテスト資産を人間の頭の中や表計算アプリケーションで管理するのではなく、何らかのツールを使うのが現実的だろう。

 ツールについて、朱峰氏は「自社ツールも含め、誤解を恐れずに言えば、まだまだで進化している途上にあります」と前置きしつつも、テスト管理ツールというジャンルを紹介した。

市場に多数あるテスト管理ツール
市場に多数あるテスト管理ツール

 テスト管理ツール導入時には、カタログスペックやプリセールスレベルでの机上判断、無料プランやトライアルにて小規模パイロット案件適用で比較していくことになるだろう。朱峰氏によると、パイロット案件に含めるべきは「100件以上、できれば1000件以上のテストケース」だという。また1プロジェクト内での繰り返し(パスしなかったテストの2周目以降のテストや、パスしたテストの回帰テスト)、2プロジェクト目以降の繰り返し(仕様変更を想定したテストケースなど)を考慮するのがポイントだという。

 朱峰氏は「テストケースや過去のテスト結果をしっかり資産として、手の内化して、自分たちのテスト活動を効率化していくこと」とアドバイスする。

次のページ
仕様書が不完全でも「とりあえず触る」、アジリティの高いテスト

この記事は参考になりましたか?

この記事の著者

CodeZine編集部(コードジンヘンシュウブ)

CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

加山 恵美(カヤマ エミ)

フリーランスライター。茨城大学理学部卒。金融機関のシステム子会社でシステムエンジニアを経験した後にIT系のライターとして独立。エンジニア視点で記事を提供していきたい。EnterpriseZine/DB Onlineの取材・記事や、EnterpriseZine/Security Onlineキュレーターも担当しています。Webサイト:http://emiekayama.net

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

山出 高士(ヤマデ タカシ)

雑誌や広告写真で活動。東京書籍刊「くらべるシリーズ」でも写真を担当。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

提供:株式会社ベリサーブ

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/20498 2024/12/24 12:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング