ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

【翻訳】「アジャイルテスト」、わたしたちの定義

 『実践アジャイルテスト』の著者である、Janet Gregory、Lisa Crispinの両氏による『Our Definition of “Agile Testing”』という記事を、許可をいただいて翻訳してみました。

agiletester.ca

 この本、勢いで買って店晒しにしておったのですが、最近やっと読み始めまして、とても気に入っています。あらゆる経験、知識、エピソードをとにかくぶっこんでみた!という勢いと厚さが好きです。つまみ食いでも得られるものがあると思いますので、未読の方はぜひ。

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

 では、以下が翻訳です。

アジャイルテスト」、わたしたちの定義

 Janetの講義で、学生の一人がアジャイルテストの定義を尋ねてきた。彼が求めていたようなわかりやすくきれいな定義は、3日間の講義の中では得られなかったのだ。
 Janetは自著である『Agile Testing』と『More Agile Testing』を調べてみたが、簡潔な定義はどちらにも載っていなかった。ブログポストにあるものが、最も答えに近いものだった。

 そこで、LinkedInのアジャイルテストのグループと、長く続いているアジャイルテストのYahooグループで質問してみることにした。
 「アジャイルテストの定義はどんなものだと思いますか?」

 多くの人が、アジャイルを定義しようとしたり、定義の中で「アジャイル」という言葉を使ったりしていた。この言葉を使うことにまったく同意しない人もいるが、「アジャイル」という言葉自体は形容詞であり、「アジャイルテスト」という言葉は間違ってはいないだろう。また、テスターのロールではなく、テストという活動自体にフォーカスしたかった。

 すべてのやり取りと、わたしたち自身の考えを踏まえた結果、考えついたのが以下の定義だ。

アジャイルテストの定義(Lisa Crispin、Janet Gregory)
 開発の始めからデリバリーまでに行われる協働的なテストのプラクティスで、顧客にビジネス価値をもたらす高品質なプロダクトの、高頻度なデリバリーを支える。テストの活動は、欠陥を見つけることではなく抑えることにフォーカスするものであり、「品質に対するチーム全体の責任」という考え方を強め、支えるためにある。

 アジャイルテストは、以下のようなテストの活動を含む(が、これに限られない)。
 具体的な例を挙げて開発を導く。アイデアや仮定をテストするために質問を投げかける。テストを自動化する。探索的テストを行う。性能、信頼性、セキュリティといった品質特性のためにテストする。

 この定義があなたにも響いてくれればいいが、そうでなければコメントを残すか、メールしてほしい。この定義はまだ初めのもの、ドラフトであり、変更したり適応させたりすることに、わたしたちはやぶさかでない。

 すでに寄与してくれた人に感謝したい。有用なアイデアもあればそうでないものもあったが、すべてがわたしたちの検討の役に立った。
 以下は、グループメンバーからもらったコメントや定義の一部である。上述のグループを訪れて、やり取り全体を読むこともできる。

  • 重要なプロダクトを欠陥なしかつ迅速にリリースできるようにする、協働的かつ継続的な活動
  • アジャイルのコンテキストでは、高速なイテレーションと継続的な改善という環境におけるテストであり、変化とプレッシャーに対応するものである。
  • Elisabeth Hendricksonの『Agile Testing Overview』(pdf)を教えてくれた人もいた。これはみなさんにぜひ読んでもらいたいものではあるが・・・、21ページもあり、簡潔な定義とは言えない。
  • イテレーションベースの成果物を支える迅速なフィードバックをもたらすために、短い時間で結果が得られる効果的なテスティング
  • アジャイルテスティングとは、最初の1日目から、プロダクションに提供されるまでの間ずっと取り組むものである。
  • アジャイルテスティングは、ビジネス価値と、顧客が求める品質に直接フォーカスする。アジャイルテスティングにおいてテスターは、品質に対して一丸となって責任を持つ、アジャイル開発チームの一員である。
  • 顧客の視点からテストし、ビジネス価値を高めること。それはプロダクトのゴールなのだから、とても重要だ。Gojko Adzicの「ソフトウェア品質のピラミッド」の言葉を借りると、「使うことができる」(usable)、「役に立つ」(useful)、「成功である」(successful)というのは時に、テストの話だとは考えられていないが、わたしにとって「アジャイルテスター」は、これらすべてのレベルを意識しているべきであり、少なくともどのようにテストすればいいのかをチームに知らせるべきだ。
  • 品質に対するチームの責任感を強める。
  • Karen Greaves and Samantha Laingのテストマニフェストに言及する人もいた。

わたしたちは、以下のことに価値をおく。
「最後に行うテスト」よりも「ずっと行うテスト」に、
バグを見つけるよりもバグを防ぐことに、
機能をチェックすることよりも自分の理解をテストすることに、
システムを壊すことよりも最高のシステムを作ることに、
テスターの責任よりも品質に対するチームの責任に。

  • アジャイルテストは、アジャイルソフトウェア開発において切り離された活動ではなく、切り離せない部分である。
  • アジャイルテストは、バグが起こるのを待っているのではなく、未然に防ぐものである。
  • 協働/アジャイルは、プロジェクトの最後だけ(あるいは最初の少しと最後だけ)でなく、プロジェクト全体を通じてテスターは一緒にいるのだという事実を教えてくれる。
  • ユーザストーリーに対して質問を投げかけたり、受け入れ基準を作り上げるのを手伝ったりすることで、プロジェクトは良くなっていく。バグを見つけるのが遅くなるほど、プロジェクトにとって高くついてしまう。
  • アジャイルテスティングは、サイクルの短い開発でペースを保つためのテストである。
  • 価値とアジャイルマニフェストのプラクティスを支える、テストのプラクティス

 わたしたちが提起した問題に取り組み、探究を助けようとしてくれた、以下の方々に感謝する。誰かを漏らしていたら申し訳ありません。
 Augusto Evangelisti, Tim Western, Gaurangi (Surve) Rawat, Richard Cowling, Vivek Sharma, Wim Heemskerk, Eddy Bruin, Steven Gordon, Lionel Champalaune, George Dinwiddie, Adrian Howard。

JSTQB Advanced Level - Test Analystシラバスのわからないところ - その1 -

 来たる2017年2月11日(土)、JSTQBの試験が催されます。わたしは、テストアナリストの第1回試験を受験するつもりです。前回のトライアルは受け忘れていました。
 受験料が高いので一発合格したいのですが、もう3週間前となってしまったため、慌ててシラバスを読み始めましたよ。61ページ中、すでに14ページまで読み終わりました。すごくないですか? ちなみに、7ページ目は「シラバスの紹介」で、本文は8ページ目からです。すごくないですか?

 さて、テストマネージャーの方は全章について2周分も学習ブログ記事を書いたのですが、もうそんな余裕はありません。シラバスを読んで、理解できなかった部分を解読するだけの記事を投下していきます。

1.3.1 テスト計画作業

 以下のような記述があります。

The documentation must be accurate to be effective. The Test Analyst must allocate time to verify the documentation ...
正確で有効なドキュメントを作成する必要がある。テストアナリストは、時間をかけてドキュメントを検証する必要がある。

 これだと、テストアナリストがドキュメントを検証するかのように読めます。
 テスト計画の話なので、「ドキュメントの検証に時間を割り当てる必要がある」というのが適切ではないでしょうか。

1.3.2 テストのモニタリングとコントロール

 以下のような記述があります。

While the Test Manager will be concerned with compiling and reporting the summarized metric information, the Test Analyst gathers the information for each metric. Each test case that is completed, each defect report that is written, each milestone that is achieved will roll up into the overall project metrics. It is important that the information entered into the various tracking tools be as accurate as possible so the metrics reflect reality.
テストマネージャがメトリック情報の要約を編集およびレポートする場合、テストアナリストは各メトリックの情報を収集する。完了した各テストケース、記述した各欠陥レポート、達成した各マイルストンを全体的なプロジェクトメトリクスにまとめる。さまざまな追跡ツールに入力する情報を可能な限り正確にして、メトリクスに現実を反映させることが重要である。

 この訳では、whileの意味が失われているのではないでしょうか。
 この文章は、テストマネージャーとテストアナリストを対比したものだと僕は理解しています。つまり、以下のような感じ。

  • テストマネージャー: 要約されたメトリクス情報を集めて報告することに関心がある。overall的。
  • テストアナリスト: 要約される前の個別の情報を成果に保つことに関心がある。each的。

 「全体的なプロジェクトメトリクスにまとめる」には主語がないのですが、この仕事をするのはアナリストではなくマネージャーなのではないでしょうか。

1.5 テスト設計

 以下のような記述があります。

Still adhering to the scope determined during test planning, the test process continues as the Test Analyst designs the tests which will be implemented and executed.
テスト計画作業時に決定されるスコープに従い、テストアナリストが設計するテストを実装および実行して、テストプロセスを継続する。

 これは明らかな誤訳ではないかと。「テスト設計」の節なのに、「実装および実行して」いるのはおかしいですね。
 「テストアナリストは、(今後)実装・実行する(ことになる)テストの設計を行う」というような意味になるかと思います。

If the author is not the person who executes the test, other testers will need to read and understand previously specified tests in order to understand the test objectives and the relative importance of the test.
テスト作成者がテストを実行しない場合、他のテスト担当者はテスト目的およびテストの相対的な重要性を理解するために、以前に指定されたテストを参照し、理解することが必要になる。

 「以前に指定されたテストを参照し、理解する」というのが意味不明です。が、原文を見る限り「事前に具体化されたテストを読んで、理解する」ということではないでしょうか。Aさんが事前に定義したテストケースを、Bさんが読んで理解するって話ですね。
 specifiedとかspecificという単語は訳が難しいですねえ。

1.5.1 具体的テストケースと論理的テストケース

Logical test cases provide guidelines for what should be tested, but allow the Test Analyst to vary the actual data or even the procedure that is followed when executing the test.
論理的テストケースは、テスト対象とすべきものに関するガイドラインを提供し、テストアナリストが、テスト実行時に実データや手続きさえも変更することを可能にする。

 まず原則として、テストアナリストはテスト担当者とは違うロールであって、「テストを実行する人」ではないと思います。なので、「テストアナリストがテスト実行時に変更する」というのはおかしいです。
 原文を読む限り、おそらく修飾関係が違っていて、「論理的テストケースはテストすべき対象についてのガイドラインとなるが、テストアナリストは実際のデータや、テスト実行時に従う手順さえも変えることができる」ということではないでしょうか。

1.5.2 テストケースの作成

Depending on the scope of the testing, test analysis and design address the quality characteristics for the test object(s).
テストのスコープに応じて、テスト分析およびテスト設計は、テスト対象の品質特性に対応させる。

 この文章の主語がわからないのですが、「対応させる」だと意味がとれません。
 「テストのスコープによっては、テスト分析とテスト設計において、テスト対象の品質特性を扱う」ということだと思います。

 今日はここまで。
 「訳文に文句つけるならおまえが訳せよ!」って話もありますが、読んでケチつけるのは楽な仕事だって自覚してますので。。。

「IoTセキュリティのための動的テスト(ファジング)」 #IoTテストアドカレ(21)

はじめに

 この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の21日目です。いったいいつから・・・アドベントカレンダーはその年のうちに終わると錯覚していた? 20日目はコチラ。

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『Security Testing the Internet of Things IoT: Dynamic testing (Fuzzing) for IoT security』
  • 著者: Beyond Security
  • 参照サイト: Beyond Security

ポイント

 IoTのマーケットに各製造業者が押し寄せているが、ネットワークデバイスについての経験がないことが多く、ハードウェア・ソフトウェアのセキュリティ設計・構築の複雑さは見逃されがち。プロダクトが普及した後に脆弱性が発見されると、個人・家庭内・移動体・ビジネスといった各エリアにおいて、攻撃を受けるポテンシャルを抱えてしまうことになる。

静的テストと動的テスト

  • 静的テスト脆弱性の検出の手段としてよく使われるが、プロセッサーやメモリといった、アプリケーションのインストール先に潜む脆弱性を見つけるようには設計されていない。
  • 動的テストでは、静的テストでは見つけられない隠れた欠陥・脆弱性を見つけることができる。たとえば、古いプロセッサー上で新しいコードが動く際の脆弱性を見つけるのに重要な役割を果たす。

ファザー

  • バイスやアプリケーションを攻撃する攻撃者は「ファザー」(fuzzer)を利用している。予期しないような壊れたデータを生成・入力したり、プロトコルの境界を狙ったりして、アプリケーションを破壊する組み合わせを探す。
  • 開発側もファザーを用いることで、脆弱性をできる限り低減しておく必要がある。ただし、多くのファザーはある特定のタイプの脆弱性プロトコルに特化していることが多い。
  • ファザーは、バッファオーバーフローエラーのテスト、プロトコル違反のテスト、ブラックボックステストなどの助けになる。
バッファオーバーフローのテスト
  • バッファオーバーフローの問題がある場合、バッファの外にあるメモリの内容を上書きされ、悪意あるコードを埋め込まれたりするので、脆弱性の元である。
  • beSTORM™では、ヘッダを改竄したパケットを送り込んだりすることで、欠陥を検出する。
プロトコル違反のテスト
  • バイス間の通信のために用いられるAPIに対して、攻撃が行われる。たとえば、入力値に対する誤ったバリデーション・境界値チェックや、設計の瑕疵、プロトコル自体の実装の問題を突く。攻撃の組み合わせの量が膨大になるので、もっともエラーの原因になりそうな箇所から試行したうえで、組み合わせ空間をカバーしていく。
  • 値の操作だけでなく、プロトコルの操作、ロジックの操作といった先進的なアルゴリズムが、ファザーの能力を決める要因である。
  • beSTORM™は、おそらく唯一のマルチプロトコル対応のファザー。50のプロトコルをサポートしているうえ、固有のプロトコルであっても自動的に学習することができる。
ブラックボックステスト
  • アプリケーションの内部について知識がない場合、テスターはまずトラフィックを調べて、それをベースにして、正当な入力、ランダムな入力、おかしな入力を試す。
  • ツールでは、内部エラーを引き起こすために組み立てられた入力を、繰り返しプログラムに食わせる。「フォールトインジェクション」とも言う。
  • beSTORM™は攻撃の組み合わせを徹底的かつ賢く行い、アプリケーションの異常な動作を検出する、強力なブラックボックステストツールである。

所感

この文章って・・・

 ファジングについての話なのですが、beSTORM™という特定プロダクトをやたら推してくる。

bestorm.jp

のはまあいいとして、とにかく読みづらい・・・! 文章と文章のつながりがわかりづらい部分が多く、読み進めるのに苦労しました。で、内容も理解できない点が多かったので、いろいろ調べていると・・・。

Open Source Fuzzing Tools

Open Source Fuzzing Tools

 なんか、この本*1文章がものすごく似ているんですよね。読みづらいのも当然で、書籍の文章が、この記事の複数箇所に切り貼りされているんです。これは何なんだ、記事と書籍の著者が同じならいいのかもしれないけれど・・・。
 まああまり闇に突っ込みたくないので、記事では不明だった点を、書籍の方の記述に基づいて少し補足しておきます。

ファジングの技術

 ファジングの技術として、「値の操作」「プロトコルの操作」「ロジックの操作」というのがありました。具体的には、以下のようなことみたいです。

  • 値の操作: たとえばTCPセグメントにおけるポート番号のフィールドに、記号を入れたり、RFC規定の外の数字を入れたりして、アプリケーションに送り込むこと。各フィールドの意味自体は気にせず、エラーを引き起こしそうな入力パターンを試します。
  • プロトコルの操作: たとえばHTTPにおいて、「GET GET GET」などと送り込んでみる。プロトコルのフィールドやコマンドの意味を把握したうえで、それを壊そうとする試みのようです。
  • ロジックの操作: たとえばSMTPにおいて、EHLOの前にRCPT TOを送り込む。プロトコルの正規手順を理解したうえで、例外的な手順だったり違反した手順を試して脆弱性を探すイメージでしょうか。

ファジングって動的テストなの?

 正直申しまして、動的テストとファジングによるテストの違いがわかっていません。ファジングは動的テストの一種?
 過去にIBM AppScanを見たことがありますが、これはファザーなのか?

www-03.ibm.com

 ネットワークセキュリティの調査では、BreakingPointに関わったこともありました。ちょっとだけ。

jp.ixiacom.com

 なおJaSST'17 Tokyoでは、ベリサーブの松木さんが「IoT時代に立ち向かうテスト・ファジング技術入門」というチュートリアルを行う予定になっていますね。   

 ソフトウェア化していく世界のなか、まずコンピュータがクラウドという形で結実し、昨今はモノのソフトウェア化=IoTが進んでいます。実在の世界における"環境変数"を事前に想定することがどんどん難しくなっていくこれからの時代に立ち向かうために、いわゆる"異常系"の膨大なテストを実現する「ファジング」技術についてその概要、およびウェブサーバを例にとったファザー設計の実例をお話します。

 興味のある方は、受講してみてはいかがでしょうか。

 22日目はコチラです。(いつの日か公開されます)

http://kzsuzuki.hatenablog.com/entry/ac_20161222kzsuzuki.hatenablog.com

*1:っていうかこんな本が売られていて、かつ7,992円というのに驚いた。円安かよ。

「IoTのテスト:5つの大きな課題をどう乗り越えるか」 #IoTテストアドカレ(20)

はじめに

 この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の20日目です。19日目はコチラ。一体いつから・・・、アドベントカレンダーは12月25日に完結すると錯覚していた?

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『IoT testing: How to overcome 5 big challenges』
  • 著者: TechBeacon
  • 参照サイト: TechBeacon

ポイント

 IoTの時代には、効果的なテストが重要である。Iotデバイスのテストにおける考慮事項を述べる。

IoTプラットフォームが多い

 デバイスのハードウェアとソフトウェアが多彩すぎて、すべての組み合わせをテストすることはほとんど不可能。エンドユーザの情報を集め、どのデバイスとソフトウェアが使われているかを理解したうえで、最もよく使われる組み合わせを中心にテストする。

テストする通信プロトコルが多い

 現在のIoTデバイスでは、コントローラとやり取りするための様々な通信プロトコルを使っている。MQTT、XMPP、CoAPなどがよく使われており、それぞれ長所と短所がある。
 テスト設計は、IoTデバイスがどのようなプロトコルAPIを使っているかに依存する。テストツールはそれらを利用できるものでなければならない。

攻撃されるポイントとセキュリティ上の脅威が増える

 IoTデバイスの70%以上が、セキュリティ上の脆弱性を抱えているとされる。開発者やテスターは、パスワードポリシーをはじめとするセキュリティの問題にも注意を払う必要がある。

IoTアプリケーション、デバイスが多様になる

 テスターは、しっかりしたテスト戦略を持ち、アーキテクチャを理解し、デバイスとソフトウェアが適切なバージョンに設定されていることを確実にしておく必要がある。

 システムがサードパーティーのサービスを使っていれば、そのサービスの変更によりテストが失敗する可能性がある。サードパーティーのサービスが利用できない場合、サービスの仮想化を使うことで実際のサービスへの依存性を排除することができる。仮想化を行うツールがカスタマイズ可能なものであれば、様々な状況のレスポンスをテストできる。

データの高速化と負荷の増加が巨大になる

 WiFiチャネルの高負荷、信頼性の低いネットワークハードウェア、低速で一貫性のないインターネット接続など、ネットワーク状態は、デバイスの性能に重大な影響を持つ。様々なネットワーク条件でテストし、データを失うことなく適切なレスポンスができることを確認しなければならない。そのために、ソフトウェア的に様々なネットワーク状態をエミュレートするためのネットワーク仮想化を利用する。

 またテスト中は、CPU使用率やメモリ使用率のようなシステムのメトリクスをモニタする必要がある。ただIoTデバイスは、デスクトップアプリケーションのようにユーザの操作によって起動・テストされるとは限らないので、どのデバイスが利用されているのか、どのように振る舞うのかを把握する必要がある。

所感

 プラットフォームの組み合わせ、プロトコル、セキュリティ、性能など、これまでの資料でも言及されたポイントが整理されていてわかりやすいですね。

 21日目はコチラです。(いつの日か公開されます)

kzsuzuki.hatenablog.com

「モノのインターネットをテストする: ヒトの体験」 #IoTテストアドカレ(19)

はじめに

 この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテスト アドベントカレンダー」の19日目です。18日目はコチラ。

kzsuzuki.hatenablog.com

プロファイル

  • タイトル: 『Testing the Internet of Things: The Human Experience 』
  • 著者: Gerie Owen
  • 参照サイト: InfoQ

ポイント

ユーザの理解

  • IoTデバイスをテストするということは、人間のユーザを深く理解すること。人間との相互作用とテストしないと、品質の判断において重要な情報が欠くことになる。
  • 「ヒトの体験」(human experience)というとユーザビリティが頭に浮かぶが、もっと深い。単なる見た目や使いやすさだけでなく、ユーザの感情的、物理的、知覚的な反応や、マインドセット、バイアスといった観点で、徹底的にテストする必要がある。
  • バイスを使用するうえでは多くの失敗が考えられるので、ネガティブなテストシナリオが、ポジティブなものより重要になる。非機能要件(-ability)のテストも重要。
  • ヒトがデバイスに何を求めるのか、知見を集める必要がある。新しい種類のデバイスであれば、プロトタイプでユーザの反応を観察したり、デバイスに対する印象をインタビューしたりする。
  • 現実世界におけるユーザのテストシナリオをどのように設計するか。「ヒトの体験」をテストする最も効果的な方法は、人間-コンピューター相互作用の設計原理を用いることである。

ペルソナ

  • 「ペルソナ」は、潜在的なユーザのモデル。年齢、性別、家庭的な背景、教育レベル、職業、社会・経済的な状況、価値観、欲求といった特徴をすべてリストアップしたもの。場合によってはペルソナが動物の場合もある。
  • ペルソナから、ユーザがデバイスに期待することを引き出し、それを元にテストシナリオを作る。

ユーザ価値ストーリー

  • バイスがどのようにユーザに価値をもたらすかを、「ユーザ価値ストーリー」に基づいてテストする。
    • たとえばマラソンの終盤という状況を考えて、「汗をかいている」「ゆるい上りが急坂に感じる」「群衆の声が聞こえてくる」といった状況で、ゴールの瞬間にスマートウォッチをクリックする・・・といったストーリーを記述していく。
  • ペルソナとユーザ価値ストーリーに基づくテストシナリオは、物理的な期待、知覚的な期待、方向や地理に関する期待、状況に基づく期待や、バイアス、マインドセットもなどを含む。
  • どんなデバイスにも複数のペルソナがあり、各ペルソナに複数のユーザ価値ストーリーがある。ペルソナとユーザ価値ストーリーを組み合わせるだけでも、多くの「ヒトの体験」シナリオが生み出される。シナリオの絞り込みのために、リスクベースドテストを使ってもよい。

所感

 IoTの中でも、人間と密接にやり取りするパーソナルデバイスを念頭においた記事。マラソンランナーとしての筆者が、自分の走りをスマートデバイスでモニター・記録していたにも関わらず、そのデータが大会側に反映されていなかったというエピソードをベースに、「ヒトの体験のテスト」についての説明をしてます。具体的で読みやすい内容でした。

 このカレンダーの前日の記事もシナリオテストに関するものでしたが、今日の資料は、ペルソナやユーザ価値ストーリーの導出の流れをわかりやすく説明してくれています。だいぶはしょっているので、ぜひ原文をお読みください。
 この中で言及されている「人間-コンピューター相互作用」については僕は知識が全然ないのですが、これから特に重要になってきそうな分野だと感じます。

 20日目はコチラです。(12月20日の0時に公開されます)

kzsuzuki.hatenablog.com