>& STDOUT

主にソフトウェアに関する日々の標準出力＋標準エラー出力

OpenSSL メモ

こんぴた的な話

OpenSSLとは

OpenSSL は Eric A. Young と Tim J. Hudson によって開発された暗号ライブラリ SSLeay を元に現在最もWeb上で普及しているセキュアなProtocolであるSSLv2/3,TLS1を実装したアプリケーションです。これひとつで、SSLサーバ/クライアントはもとより証明書の発行、管理(ちょっと面倒)、認証まで行えてしまいます。同様の機能(≠SSLeay)をもつ国産のソフトとしてはAiCAがあります。

OpenSSLの入手先

最新のOpenSSLバイナリは http://www.openssl.org/ より入手できます。Windows上で運用する場合は、精力的にWin32バイナリを配布しておられる(ありがたや) Shining Light Productions より入手してください。Win32バイナリの場合はインストーラがついてきます。インストールが完了したら、コマンドプロンプトより、

C:\>openssl version

と打って、正しくインストールされているかどうか確かめてみてください。

とりあえずSSLサーバしてみる

無事インストールとPATHの疎通確認が終わったら、とりあえずSSLサーバを起動してみましょう。コマンドプロンプトより、

C:\>openssl


と打って、プロンプトが OpenSSL> に変わればOKです。OpenSSL> に続けて

s_server -www -accept 5443 -cert C:\openssl\bin\PEM\demoCA\cacert.pem -key C:\openssl\bin\PEM\demoCA\privatecakey.pem


と入力してエンターキーを押下してください。ここでは便宜上C:\直下にopensslがインストールされている設定ですが、Windows7以降ではユーザフォルダ直下、MacOSでは which openssl などとしてインストール先のディレクトリに適宜読み替えて下さい。

(略)
Using default temp DH parameters
ACCEPT


と表示されればOKです。お手持ちのブラウザから、https://localhost:5443 にアクセスしてみてください。 今回はOpenSSLに付属してるデモ用の証明書と秘密鍵を利用しましたので、各種認証エラーでまくりだと思われますが、とりあえずのSSLサーバとして動作する事はご確認いただけたと思います。

s_server

先ほどの動作確認の際に打ち込んだコマンドです。指定されたポートで稼動するSSL/TLSサーバ(それとSimpleなHTTP応答機能)を実現します。OpenSSLはそれ自身を起動したのち、OpenSSL> プロンプトで、さまざななコマンドに無数のオプションとそれに伴う引数を指定のうえ、タスクを実現します。各種コマンド,オプション,引数に関しての正確な情報は OpenSSLのドキュメント を参照してださい。


以下にs_serverコマンドでよく利用する、いくつかのオプションを挙げておきます。

-accept port

待ち受けるTCPポート番号を指定します。このオプションが省略された場合は4433が利用されます。

-cert certname

設定するサーバでチェインの末端に位置する証明書(一般的にはそのサーバ自身を証明するもの)を指定します。Apache-SSLでいう、SSLCertificateFile ディテクティブに相当します。このオプションを省略した場合は"server.pem"が指定された、とみなされます。

-key keyfile

先ほどの -cert で指定したサーバ証明書の秘密鍵を指定します。Apache-SSLでいう、SSLCertificateKeyFile ディテクティブに相当します。

-verify depth, -Verify depth

Client認証時に辿るチェインの深さを指定します。Apache-SSLでいう、SSLVerifyDepth ディテクティブに相当しますが、OpenSSL単体の場合は SSLVerifyClient も同時に指定します。-verify とすると任意。-Verify とするとクライアント証明書の送付が必須となります。

-CAfile file

"-cert" で指定したサーバ証明書までの認証パスを持つ証明書チェインを、pemエンコードされた単一のファイルで指定します。Apache-SSLでいう、SSLCACertificateFile ディテクティブに相当。ちなみに先頭2文字は大文字でないとinvalid commandとなります。OpenSSLコマンドは大文字と小文字を区別するようです

-state

クライアントから接続があった際に、進行中のハンドシェイクの流れをおおまかに表示します。

-debug

レコードレイヤまで含めた広範なトラフィック情報を16進ダンプを含めて表示します。

-msg

プロトコルレイヤの情報を16進ダンプと一緒に表示します。
※古い版のOpenSSLには搭載されていません。

-ssl2, -ssl3, -tls1, -no_ssl2, -no_ssl3, -no_tls1

前者3つはServerHello送信時のサーバ側SSLバージョンを指定し、後者3つはそのサーバで無効とするSSLバージョンを指定します。

-cipher cipherlist

ServerHello送信時にサーバが指定するCipherのリストを指定します。
参照:http://www.openssl.org/docs/apps/ciphers.html#
ページ下部にあるCipherSuiteを単体で指定する事も可能で、clientがそれをサポートしてない場合はハンドシェイク失敗となります。

しんすく流 テスト戦略策定手法 v1.0.2

ソフトウェアテスト 軽量品質保証の部品

思いがけずソフトウェアテストという技術に触れてからはや10年が経ちました。あーでもない、こーでもない、と試行錯誤を繰り返しながらようやく自分なりのテスト戦略、ある製品のテストすべてを「任せた！」と言われた時に僕ならこうする、という型が出来てきましたので、まとめたいと思います。

いちばん大事にしているのは、品質定義とその水準の共有とテスト設計までのトレーサビリティです。

長いわりにオムニバスでは読めない形式となっておりますので、またどこか別の形にまとめ直したいと考えています。文章にできるところを全部書くとこんな感じ、というもはや自分用メモです。万が一読破した方が居られましたら是非 @snsk まで「読んだよこのやろう」と飛ばして下さい。謝ります。

お品書き

  1. 任意の品質モデルを選択して、対象製品にとっての特性に「言い換え」る
    • 「PQM:プラクティカルクオリティモデル」の作成
  2. 「言い換え」た特性の優先度、及びどんなメタ水準を達成すればよいか考える
  3. そのメタ水準を満たすことを確認するためにどんなテストが必要かを考える
  4. 優先度に沿って網羅基準と設計方式と自動化方針を考える
  5. 設計、実装、自動化、自動実行 or 手動実行の計画を考える
  6. やる

1.任意の品質モデルを選択して、対象製品にとっての特性に「言い換え」る - 「PQM:プラクティカルクオリティモデル」の作成

「品質」が一意に定義できないのはご存知の通りなので、とっかかりとしていくつか既に存在する「品質モデル」や「テスト観点」の中から一番対象の製品にフィットしそうなものを選択します。迷ったら ISO9126 でOKです。また、別の選択肢として、GQM等を用いて組織、現場自ら定義する方法もあります。

選択肢の例

などなど。

言い換える

「品質モデル」を選んだ場合は直接言い換えることが可能ですが、「テスト観点」を選んだ場合はその観点がどんな品質特性に向けたものなのかを一度咀嚼してから言い換える必要があります。また、9126は非機能要件に対するモデルなので、機能要件に対するテストは別途定義する必要があります。その点FURPSはFEATURE SETとして個別に定義されているのでわかりやすいですね。また、この時ひとつの特性に対して複数の言い換えがありうる事に注意しましょう。例えば「資源効率性」を言い換えるとき、メモリ使用量なのかCPU効率なのか、はたまた非揮発性メモリの使用量なのか、さらにはこれら全てを包括する概念として利用するのか、は選択次第です。

この時のポイントは「全部やらない」ことです。もちろんリソースが潤沢にあるプロジェクトなら当該モデルで定義されている特性全てについて次以降のプロセスを充てることもできるかも知れませんが、水準の設定やテスト設計や実装が想定できない場合もあります。

たとえば、ISO-9126ではすべての主特性の子に「標準適合性」がありますが、いま相手にしている製品に、「効率性」の標準適合性(業界標準、規約、法律等)があるでしょうか？モデルはモデルなので、合わないと感じたら切り捨ててOKです。最初は勇気がいると思いますが、この先が出来ない、と感じたらそれを正直に書いて「やらない」事を選択しましょう。この選択を共有できていれば、どこかのだれかが発明した水準やテスト設計技術によりカバーされることがあります。進めなくなってしまうことが最悪なので、思い切って削りましょう。なれないうちは3個〜5個だけでも考えただけ充分です。

これを「PQM:プラクティカルクオリティモデル」の作成と呼称することにします。既存のクオリティモデルをベースに特性の取捨選択を行いながら、実製品におけるモデルに「言い換え」ながら変換していく作業です。

2.「言い換え」た特性の優先度、及びどんなメタ水準を達成すればよいか考える

一般的な開発モデルではコストと期限は一定ですので、選んだ特性の中でも優先度を設定する必要があります。対象の製品についてモデル化された各種品質特性の中でいちばん大事だと思うものは何か？ビジネスモデル、競合製品、自社の強み等々を鑑みながら、ステークホルダー一同と合意することが重要です。ここは本当に調整力が必要なのでプロジェクトマネージャと一緒に行うことを奨めます。彼らにとっても自分たちの成果物が果たして成功したのか失敗したのか、明確にわかる基準作りになるので喜んで協力してくれるはずです。また、ここで設定するのは「メタ水準」までです。前節で作成したプロダクトクオリティモデルの要素ひとつひとつが、具体的にどんなことを満たせば”可”となるのか？を抽象的に表現します。

ただ、「言い換え」や「メタ水準の設定」自体を任せるのは酷ですので、たたき台ぐらいは作っていってあげて、そこから議論すると経験上スムーズに進みます。自社開発の継続プロジェクトに対して13個ぐらいの特性と水準の設定、及びその合意でだいたい3日間ぐらいかかります。根詰めれば2日ぐらいでしょうか。もちろんステークホルダーが拡がるほど時間が掛かります。しかし、これ以上重要な箇所はないと断言できるぐらい大事なプロセスですので充分に時間を掛けましょう。

3.そのメタ水準を満たすことを確認するためにどんなテストが必要かを考える

テストエンジニアのみなさん、おまたせしました。ここから大活躍です。何が、どれぐらい満たされていれば「良い」かが前節までで既に判明していますので、それをエレガントに検証する仕組みを考えます。

「何が」を「網羅」する

この節に丸投げされた課題がこれです。狭義のソフトウェアテストは出来るだけ手数を少なく「網羅」することが技術です。そのためには対象の「何が」の領域から説明可能な括りを以ってテストを仕掛ける範囲を限定する必要があります。

「テスト」と聞いてまっさきにその対象として浮かぶのは「機能」かと思われます。機能が想定通りに動作すること、を「良い」とした場合、どこまでが「機能」で誰の「想定」なのかを慎重に詰めていくフェーズになります。例えばスマートフォンのメールアプリケーションであれば、「日本語入力」自体はOS自体の「機能」として用意されているものですから、ここを敢えてテストする必要はありません。しかし、入力の対象となるコンポーネントがそれを受け付けていなければメールアプリケーションとしての価値の根幹を揺るがす事態となってしまいます。さらに、インストール直後に起動する場合もあれば、他のアプリケーションとの連携で起動する場合、想定している文字数に達したままサスペンドから復帰した場合、等々つらつら考えていくとあるひとつの「機能」に対して「環境」という網羅基準が出来上がりました。

もうひとつぐらい考えてみましょう。選んだ特性に「時間効率性」があり、それぞれ「通信速度」「UI遷移速度」などを挙げたとします。「通信速度」を「何が」とおくと「網羅」はまず「送信」「受信」に分かれ「送信」の環境として、プレーンテキスト、マルチパート種別、弱電界時、SMTP/IMAPトランザクションエラー時の復帰速度、等々が挙げられます。「UI遷移速度」はそもそもUI遷移を全て洗い出す事自体が難しい場合がありますが、その場合はここでは「UI遷移」という「何が」のみを定義して、「網羅」をテスト技法が担保してくれる基準に任せてしまうのもアリです。

これを前節で言い換えた特性ひとつひとつに繰り返していきます。しかし、まだここでテストを「実装」してはいけません。寸止めです。こういう観点で、ここを網羅しよう！と決められれば(もっと良いのはそれをステークホルダーにレビューしてもらえれば)この節はゴールです。

4.優先度に沿って網羅基準と設計方式と自動化方針を考える

なんと、この節でもテストの「実装」は行いません。ウズウズしてると思いますがもう少しの辛抱です。ここでは、前節までで設定できた網羅基準に従ってテスト設計の方式を考えます。よく聞くテスト技法が登場するのはここからです。

前節で先送りにしたメールアプリケーションの「UI遷移」を考えてみましょう。メールアプリケーションは「UI遷移」の網羅が難しい代表的なアプリケーションです。ちょっと想像してみましょう。起動して最初の画面からいったいいくつ選択肢があるでしょう。そこからメール受信の画面に遷移し、メールをひらく、返信する、転送する、添付ファイルをみる、お気に入りに保存する、振り分けする、振り分けされたメールのみを表示する… これが交互に遷移可能と考えると普通の人間の頭には入りきれませんので、前述の「テスト技法が担保してくれる基準」に頼ることにします。「よし！ある画面とある画面の2画面をちゃんと行き来出来れば良いことにしよう」と決められればペアワイズが使えます。「"画面"、ではなく"行いたいこと"に基準を置いてそれが出来れば良いことにしよう」と決断できればユースケーステストが使えます。

こうして設計方式が固まったら次に、遠い昔に策定したはずの「優先度」を引っ張りだしてこれらの設計方式に与えるパラメータとします。大抵のテスト技法には「それどこまでやりますか？」的な"厚み"のパラメータを与えることができます。例えば同値分割におけるクラシフィケーションの粒度もこの"厚み"の決定に他なりません。どの特性を"どこまで"やるか、その厚みの決定に優先度を利用します。

それ、自動化できませんか？

「なるほど。優先度の高いものを"厚く"するのだな」と考えた方、正しいです。正しいのですが、"厚み"="コスト"と考えるのは早計です。設計方式を考えたら次にそれが自動でテストできないかを考えましょう。「なるほど。自動化できればコストはゼロと考えられるわけだ」と考えた方、間違いです。自動化で軽減できるコストは「2回目以降の"実行"」のみです。もっと正確にいうと"チェック"のみです。あらゆる抽象表現や空気を理解できる人間様による"実行"とキカイによる"チェック"ではその質に天と地ほどの差があります。…あるのですが、あるのですが、ここまでしっかり考えられたテストであればあとは期待結果との差を"チェック"するだけ、という実装になるテストケースも相当数あることでしょう。人間様によって充分に考えられた"テスト"を"チェック"にまで落とし込めれば、かつ長期間に渡ってお客様に価値を提供し続ける予定である製品であればあるほど"チェック"を自動化した際の費用対効果は跳ね上がります。

自動化？自動実行？
「自動化」と「自動実行」は「テスティング」と「テスト」ぐらい違います。つまり、「自動化」はテストを自動化するために考えるべき全ての検討、開発及びその実行を含み、「自動実行」は「自動化」された上での実行の様子のみを指します。


充分考えて"チェック"にまで落とし込めたか？答えがYESなら自動化しない手はないです。この節で一緒に考えておきましょう。

5.設計、実装、自動化、自動実行 or 手動実行の計画を考える

ここまでで、「何を」「どれぐらい」「どうやって」「あわよくば自動化」が揃いました。もうほとんど勝ったも同然です。あとひと頑張り、プロジェクトの状況にあわせて具体的な計画に落として行きましょう。ここでの注意点は設計と自動化のコストを見誤ることです。何も考えていないテストの計画は

「んー。この機能のテストがだいたい1000個ぐらいになりそうだから(根拠なし)、作るのに10日(根拠なし)、1人1日100個実行できるとして(根拠なし)、20日！(ぐだぐだ)」

となりがちですが、テストの設計に掛かるコストはコードのそれと同じく、実際に設計するテストエンジニアにしかわかりません。逆に設計まで終えればそれによってテストケースがどれぐらいになりそうという数字はかなり正確に出ますので、実装が手作業であれば見積りも割と正しく出せることでしょう。

自動化に掛かるコストは”要求がかなり具体的に判明しているシステムアーキテクチャ設計とその実装”とほぼ同じぐらいと考えて頂ければ外れません。設計と同じく、アーキテクトに聞かないとわかりません。なお、前節で少し触れた自動化に掛かる主なコストは以下のとおりです。

  • 自動化の前に掛かるコスト
  • 自動化の後に掛かるコスト
    • システムの保守(特に適応保守)
    • 投入データのメンテナンス

6.やる

おめでとうございます。ここまで来てようやく「わかりやすい」生産活動が行えます。計画やプロセスフローに沿ってテストを仕上げて行きましょう。しっかり考えられたテストとその実行結果は、テスト対象の成果物を「知って」もらうために、どんなステークホルダーに対しても充分な説得力を持っていますので、プロセスを進める過程で生まれた中間成果物はちゃんと管理しておくことをおすすめします。

テスト計画を実際に落としていくなかで遭遇するトラブルとしては以下のような変化があります。

仕様変更

一気通貫型の開発プロセスにおいては大打撃となりますが、近年はこれを最初から想定するプロセスが主流です。では、テストプロセスにおいてはどのように対応すればよいのでしょうか。ここまでみなさんは順を追って「何を」「どれぐらい」「どうやって」「あわよくば自動化」を考えてきたはずです。仕様変更であれば大抵「何を」の変更になるはずですが、残りの3つは他の特性から流用することができるかもです。正直なところ、アジャイル開発プロセスにどのように上層のテストをフィッティングさせていくかはまだ議論の途中ではありますが、どのようなプロセスであれ先に挙げた4つのポイントが変わることはありませんので、これを如何に軽量化するかを考えてみて頂けると、よろしければ一緒に考えて頂ければ幸いです。

開発遅延

自動化領域を広げるチャンスです。手動でやろうと決めたテストをなんとか"チェック"に落とし込めないか、再検討してみましょう。開発が遅れることでテストの実行時間を縮められるのはチームにとって計り知れない貢献となるはずです。楽しいですね。

おわりに

お疲れ様でした。まさか全部読まれました？まじですか。僕の代わりに仕事してくれませんか。とにかくいちど書き上げないことには、ブログ開くたびに「書きかけかよ」と自分に責められてたのをようやく脱しました。少し日をおいてちょこちょこ過不足を補いたいと思いますので、たまに覗いてみて頂ければ幸いです。…会って聞いたほうがはやいっす。

あとはこれらの過程を具体的に実行するための補助となる表現やツールの整備ですねー。品質特性を分解する表はあるので、いずれ公開したいと思います。

ご指摘と改版履歴

BTS開発プロセス俺流

ソフトウェアテスト

バグトラッキングシステムを導入するにあたり、どんなことを考えてどのように導入したらよいか？をまとめた記事を去年の冬コミに寄稿したのを、許諾を頂いたのでこちらにも転載します。既に運用されている方も、これから運用を考える方も、何かのご参考になれば幸いです。本エントリはバグ票ワーストプラクティスプロジェクトの提供でお送りします。それでは本編どうぞー。


こんにちは！しんすけさんと呼ばれることの多いしんすく(@snsk)です。なんでも「BTSについて好きなこと書いていい」という素敵なお話を頂きましたので、この機会に「俺が愛したBTS達」を赤裸々に……　は先日某コミュニティの予習会でやったので、今回は真面目な方の話をしたいと思います。題して「BTS開発プロセス俺流」。俺流とは言うものの、この方式で作ればそうそう外すことは無いはずという汎用的なものを目指しています。

1.BTS要件分析

どんな開発プロセスであってもはじめに要件分析ありき、ということでBTSもその類に漏れません。素人目にはウェブ上でちょいちょいっと設定するだけに見えても、そこは開発プロセスやバグのライフサイクルに密接に関係するツールですので、最初に考えておくべきことは意外にあります。

1-1.プロジェクト構成/利用言語の把握と定義

まず、既に使っている、またはこれから使う予定のBTSについてそのプロジェクト構成を確認します。大抵のBTSはデータベースをプロジェクト単位に分割可能でかつ、入れ子にすることが可能です。そのシステムを利用している最も大きな組織単位でどのような構成を採用しているのか、あなたが最初の導入者であれば、今後どのような構成を取るのかを確認/検討する必要があります。例えば、標準版を親プロジェクトとして、そこからのカスタマイズや派生開発はそのプロジェクトの子としておいて、子プロジェクトで出た標準版の問題は、上位のプロジェクトのトラッカーに登録する、等。また、このBTSが横断する国の言語は原則抑えておく必要がありますが、想定できない場合でも日本語と英語ぐらいは設定しておいたほうが無難でしょう。

1-2.プロセス改善強度の把握

「プロセス改善強度」ってなんですか？という声も聞こえてきそうですが、開発プロセスの改善にあたり基礎となるデータの取集をどれぐらいBTSに頼る予定なのか？をプロジェクトマネージャやQAマネージャと予め詰めておく必要があります。もし、あなたがQAマネージャの場合は自分でこの水準を設定することになります。どのタイミングでどんなデータを取ればどんな状況の把握に役立つはずである、というアレですね。例えば「混入工程」や「混入原因」、「テスト漏れ原因」などです。一見とても魅力的なフィールドで即採用してしまいそうですが、きちんとその理由と背景を把握しておかないと、のちのフィールドデザインの際の取捨選択時に正しい判断ができなくなってしまいます。また、運用開始時にメンバーに説明するためにも重要な資料となりますので、必ず行なっておきましょう。

1-3.連携が想定されているシステムの把握

今日日のBTSはSCMやテストマネジメントツールなど、さまざまな外部システムと連携することができます。どういうI/Oをさばく必要があるかによって、構築時のプラグイン選択などに制限がでることがあります。

2.バグライフサイクルデザイン

さて、ここからいよいよ「それっぽい」BTSの設計に入って行きます。まず最初に検討しなければならないのがこのバグのライフサイクルです。バグがいつ生まれて(認識されて)、開発チームのロールによるどのような過程を経て消滅(完了)するのか、主に「ステータス」を軸に検討します。

2-1.ステータス、ワークフロー設計

百聞は一見に如かずということで、まず例としてBugzillaという著名なBTSが定義しているライフサイクルを示します。

f:id:shinsuku:20151203130409p:plain

最も重要なのは、

  • 解析/修正などの”担当者”がアサインされたか否か - 図中ではASSIGNED
  • バグが解決されたかどうか - 図中ではRESOLVED
  • 修正されたバグは正しく確認されたか - VERIFIED or CLOSED

の3点です。もちろん状況を把握する為にはステータスは細ければ細かいほどよいでしょうが、今度はルールが守られにくくなるというリスクも抱えてしまいます。この辺の縛りと規律のバランスはこの先も常に悩まされることになります。迷ったら「削る」方向に倒しましょう。ステータスを増やすのは本当に本当に困ってからで充分、かつそうでないと、誰も本気でそのステータスを運用しようとは思わないでしょう。先に例示した3点であれば運用は明らかと思われますが、もしこれ以上増やす場合は、あるステータスからあるステータスに遷移する際の”条件”や”権限”も一緒に検討する必要があるでしょう。例えば、「修正インパクトが大きいので本バージョンでは凍結」を意味する FREEZE というステータスを新設する際には、いったいだれがインパクトが大きいと判断したのか？そのフィーチャーが次版に入らない事は同意を得ているのか？辺りをルールとして策定する必要があります。

2-2.ユーザとロール

次に検討するのはそのBTSを誰が、どんな役割で利用するのか？です。ロールの設定は先にあげたステータスを遷移させる権限と紐付くことがあります。代表的なのは「CLOSED」に出来るのは”テスター”や”テストリーダー”といったようなロールの人のみ、などです。ここをどれぐらい細かく設定できるか？はBTSによってさまざまですが、導入初期はプロジェクトリーダー、テスター、デベロッパーの3種ぐらいが設定できれば充分でしょう。一般的には登録とアサインは全員が可能。RESOLVEDにできるのはデベロッパー、またはプロジェクトリーダーで、CLOSEDは先述の通りテスターのみといった様子です。

3.フィールドデザイン

先にあげたステータスもこのフィールドの一種ですが、BTSには他にもさまざまな入力項目が設定できます。BTSとして機能させるために最低限必要なフィールドは「ステータス」「担当者」「現象の説明」「再現手順」の4つです。どれひとつ抜けても機能しませんが、「プロセス改善強度」が最低にセットされており、最小、最速の運用を臨む場合はこれだけでも良いかも知れません。Excel等のスプレッドシートでも何とかなるのではないかと考えるのも無理はないですが、ファイルで管理してしまうと 1.複数人編集が困難、2.バグ件数が増えると一覧性が極端に落ちる、3.必須の入力項目を設定することが容易にはできないなどの不都合が生じます。スプレッドシートは「祭りのあと」の分析に留めておきましょう。

3-1.プレフィールドとポストフィールド

実はいままで挙げたフィールドはすべてバグ登録時に記入、または自動的に設定される"プレフィールド"です。これに対し、そのレポートがCLOSEに相当するステータスに移行する際に記入されているべきフィールドが”ポストフィールド”です。プレフィールドが主にバグ自体の状況を記述するのに対し、ポストフィールドはそのバグがなぜ発生したのか？という背景を記述します。フィールドを新たに置くときはそのフィールドが”いつ”記入されるべきなのかを念頭においておく必要があります。

3-2.優先度？重要度？カテゴリ？必須？

必須ではないが推奨されるフィールドとしては他に「要約」「カテゴリ」「重要度」「優先度」「発生したバージョン」「コメント」「期日」などがあります。「重要度」と「優先度」の設定はよく混乱を招きますが、ひとつの指針として「重要度」は”その製品にとってどれぐらい問題の大きいバグか？”を表し、「優先度」は”そのプロジェクトにとってどのぐらい優先して解決すべきバグか？”を表す、と定めるとよいでしょう。つまり、「重要度」はテスターやデベロッパーが設定し、「優先度」はプロジェクトリーダーが設定するイメージです。「カテゴリ」はそのバグが製品にとってどのような不都合を生じさせるのかを端的に表す言葉を選びます。筆者はこれと「重要度」を一緒に運用できるよう、「P1.クラッシュ/フリーズ」「P1.セキュリティ問題」「P2.既定の仕様と異なる」「P3.他製品の一般的な動作と異なる」といった文言で運用していました。もちろんどんな現象が問題なのか？は製品ごとに異なるので、それぞれに問題を考えて設定し直す必要があります。これは設定前にプロジェクトリーダーやメンバーと同意をとっておくべきで、なおかつこの問題の裏返しでうすーく品質指標を意識してもらうことにも繋がります。地味ながら(コストが低そうに見えるが)とても効果的なのでオススメです。
　
また、フィールドをデザインするときに悩ましいのが「必須」フィールドの扱いです。これを入力しないと編集が完了できないというオプションですが、そのままバグ登録1件あたりのコストに跳ね返ります。かといって「任意」が多すぎるとこれまたBTSとしての精度を保てなくなってしまいます。これは組織やチームの文化の成熟度や先に述べた「プロセス改善強度」によって適宜調整することになりますが、BTS自体を上手に運用できなければその先も無いので、基本は極限まで少なく、です。

4.実装とインテグレーション

ここまで設計できたらいよいよ実装に入りましょう。いまどきの大抵のBTSはブラウザのみで設定が可能ですが、国際化やワークフローの設定などはそれなりに時間を取られるので、1日はしっかり確保しておいたほうが無難です。実装が完了したら、ひと通りのロールでステータスを遷移させてみて、想定通りの運用が可能かどうかチェックすることもお忘れなく。

5.運用

さて、とうとうあなたのBTSのがオープンします。まず最初に行うことはワークフローの説明会と資料の公示です。この時、先に設定したロールが具体的にチームメンバーの誰にあたるのかを確実に周知しましょう。ワークフローの説明は実際に動かしながら行うと更に効果的です。この時、のちのプロセス改善のためのフィールドについても、それがなぜ必要で、いつどんな役に立てるつもりなのかを一緒に説明しておきましょう。また、定期的に利用状況や不審なステータスの集計を行いBTSが健全に運用されているかどうかをチェックすることも重要です。また、あるステータスからあるステータスに遷移するまでの時間、いわゆるターンアラウンドタイムはプロジェクトマネージャにとっても非常に有用な情報になるはずです。例えば、新規登録からASSIGNEDになるまでの時間が不審に長い場合はリーダーの稼働状況や、テスターの登録精度に問題がある可能性があります。


以上、BTSを導入する際に検討すべきポイントについて、僕なりの経験に基づいてお話をさせて頂きました。BTSはプロジェクトの渦中中の渦中に運用されるシステムですので、そのプロジェクトがいまどういう状態にあるか、定性的な情報を導き出すのにとても有用なツールです。ぜひテストリーダに任せきりにせず、マネージャにも有効活用していただければと思います。

逆引きソフトウェアテスト関連技術まとめ

ソフトウェアテスト

「Software Test ＆ Quality Advent Calendar 2011」の8日目。アドベントカレンダーということで、普段と少しトーンを変えてソフトウェアテストにあまり造詣のない方へ向けて何か役に立つ記事を考えてみました。先の記事でも述べたとおり、ソフトウェアテストの関連技術を表す用語はそれが何に使えて、何に役立つのか、門外漢にはとってもわかり難いので、そちらを軸にした紹介があると便利かもしれないということで、関連技術を目的別に整理し、参考になる記事や資料にリンクする形でお届けします。

テストの戦略を定めたい

ソフトウェアテストプロジェクトの最上流工程と考えられているテスト分析の方法論です。プロダクト、プロジェクトに対してそれぞれ独自の方式で戦略を検討します。テスト計画と一部被る部分もありますが、プロジェクトの予算やスケジュールをひとまずおいて技術的な視点から本当に必要なテストを考えるのに役立ちます。

マインドマップは方法論というより考えをまとめるためのツールですが、テスト戦略や設計など容易に果てしなく拡がってしまう検討事項をまとめるのにとても適しています。こちらも参照。

テストの方針を定めたい

戦略とどう違うのか説明が苦しいところですが、ここでは戦略策定の中で実際に採用されるもっとも高位のテスト方針の具体例を列挙しています。スクリプトテストは「先にテストケースを準備してから実行する」タイプの普通「テスト」と聞いて思い浮かべる方針です。なお、このテスト方針で通常生成される成果物(テスト計画、テスト設計、テストレポート等々)のひな形はIEEE829に定義されています。探索的テストはテストの実行と設計を同時に行なっていくアプローチで、リスクベーステストはテスト戦略/マネジメントにある特徴的な方向性を付与します。モデルベースドテストはソフトウェアのあらゆるレベルの(使えそうな)構造から、テストケース、テストデータを自動的に導いていく、というものです。

テストの開発プロセスを定めたい

テストスイートも分析して、設計して、実装してはじめて生まれる開発成果物ですので、当然開発プロセスが存在します。するのですが、多種多様な開発側？(この言い方はあまり好きではないのですが)のプロセスに比べてテスト側？(この言い方は(略))はかなり希少です。

テストのボリュームを”正しく”抑えたい

そもそもソフトウェアテストがひとつの技術として成立した背景にはこの問題がそびえ立っています。テストすべき無限の空間から、効率的かつ網羅性を担保しつつ現実的にテストできる量を”正しく切り出す”ための方法論がこちらです。この”正しさ”をどう捉えるかによってさまざまな技法が考案されています。また、これらの技法は要件定義や業務フローに対するテストでも粒度を大きく取ることで活用することができるので、その適用範囲は決して下流限定ではないことに注意です。

テストのヒット率を向上させたい

こちらはある程度完成しているテストに対して更に検出率を高めるためにふりかけるスパイスのような技法です。エラー推測は経験ベースのテスト技法に分類され、設計、実行するテスト担当者に対象製品への深い造詣と使用またはテスト実施経験が必要なので、案外導入の敷居が高いです。ある程度熟練したテスト設計者であれば用語は意識しないまでも、取り込まれていることでしょう。

ある特定の目的に向けてテストしたい

一般的に「テストの種類」と言うとこの辺があがってくるかと思います。単語で検索して良質な記事が出てくる割合が高いので用語だけで。JSTQBでは「テストタイプ」と呼称される、特定の品質モデルの要素を検証することに特化したテストの方式、方法論を指します。「特定の品質モデルの要素」に特化したもの、ですので必ずこれより先にテスト戦略や方針の策定を行わなければなりません。

  • テストタイプで挙げられているテスト群
ストレステスト、ロードテスト、セキュリティテスト、ユーザビリティテスト、
互換性(インターオペラビリティ)テスト、インストールテスト、などなど

異常系のテストを効率よくやりたい

異常系試験の悩みどころは正常系の試験に比べてテストケースを絞るのに規則性を使い難いところ、です。なにせ”異常”系なので、前述の「テストすべき空間」を無限に押し拡げるのにとても貢献しています。この困ったちゃんに対するアプローチはふたつ、1.正常系よりさらにアグレッシブな同値分割(≒トリアージ) 2.無限にチャレンジする。どう考えても頭の悪い2番を最もスマートに実現する方法が下記のファズテストです。

改めて整理してみて加瀬さんのサイトへのリンクが多いこと！来年のアドベントカレンダーではもう少し自分のサイトから紹介できるように技術系の記事をもっと増やそうと改めて感じました。もちろんここに挙げたのが全てではないです。新しい技法、手法も日々開発されていますので、日頃からアンテナを高くもってリストをメンテナンスしていきたいと思います。

モデルベーステストに入門する・その2

ソフトウェアテスト

一つ前の記事で、生涯一テスターさんよりコメントを頂いた部分について補強。ハンドルネームかっこ良すぎなこのかたのBlogはこちらです。ソフトウェアテストの歴史を綴る、というおそらく日本ではここ以外にないテーマで、この筋の方にはたまらない内容となっています。未見の方はぜひ。知らず知らずのうちに大変お世話になっていることの多い、あの方のBlogです。

TEFでのモデルベーステストについての議論

アーカイブはこちら。メーリングリストのアーカイブで、TEFに参加していないと読めないのでこの機会にこちらもどうぞ。
このスレッドの議論の中で辰巳さんが整理されているモデル検査とモデルベースドテスティングの違い、がとても参考になるので引用します。

1)モデル検査
・モデル化の対象：対象システムの振る舞い(状態遷移に着目)
・モデル化の目的：実装しようとしている設計(状態遷移モデル)に仕様レベルの欠陥がないか否かの検証(検査項目は別途作成する必要あり)
・モデル化の方法：状態遷移(発表論文の多くは状態遷移。他にもあり？)
2)Model-based testing
・モデル化の対象：対象システムの振る舞い(仕様)
・モデル化の目的：テストケース,テストスイート,テストスクリプトなどの自動生成
・モデル化の方法：Grammar, Finite State Machine, Marcov chains, Statechart, Decision tables, Tabular definition 等


やはり目的はテストケースやテストスクリプトの自動生成ということでそんなにズレてないようです。モデル化の方法として挙げられているステートチャートやデシジョンテーブル以外があまり馴染みのないものだったので、別途調査してみます。デシジョンテーブルからの自動テスト生成はたぶんどこかにツールや論文があるような気がします。

モデルベースドテストに入門する

ソフトウェアテスト

まったく意図してなかったのに、NativeDriver(駆動系), TABOK(自動テスト知識体系), モデルベースドテスト(ちょっとメタなテスト方法論) となんとなく部品が揃ってきた感じがします。ドキドキ。

モデルベースドテストってなんですか？

名前はよく聞くのですがいったいそれが何なのかさっぱりなのでまずは”認識”から。

個人的にはこの業界ネーミングが非常によろしくないと感じています。
テストの段階を示す用語やテスト設計方法論、テスト実行の方式を表す言葉、
そしてこのモデルベースドテスト、などメタな概念まですべて「ｘｘテスト」
という言葉がついているので、どこにどのように適用していいのか直感的には
わからない。門外漢にはいよいよサッパリ。

テストについて困ったらJaSSTのサイトを見ろ！ってぐらいとっかかりには最強なサイトなのでまずはチェック。2007年(早っ)には既にモデルベースドテストについての言及があります。

にしさんによる、

で概略を掴んでから、小川さん(日立製作所)による

という順番で確認してみると良さそうです。


にしさんの発表の冒頭でも触れられていますが、モデル検査ではないことに注意。同じセッションにモデル検査の話もあるので同じコンテキストで読むと混乱するかもです。

資料で述べられているモデルベースドテストの定義

  • 「モデルベースドテスト入門」:にしさん
モデルベースドテスト（Model Based Testing）とは
ーテスト設計モデルを用いてテストケースを設計する技術の総称
ー網羅型テストを設計している時には必ず実施しているはずである
  • 「モデルベースドテストの技術動向と研究事例」:小川さん
モデルベースドテストとは、
ーテスト対象システム（ＳＵＴ）の性質を記述したモデルから
ー全部または一部のテストケースが生成される
ーソフトウェアテスト

わかったこと

  • モデルベースドテストとは、テスト対象から導けるモデルを利用して”抽象テストケース”(テスト設計とテスト実装の間にあるイメージ)を自動的に導くテスト設計からテスト実装の直前までをカバーする手法
  • モデル検査ではないってば
    • これによってテスト設計自体や実装時のカバレッジが自動的に保証されることが嬉しい
  • 各種テスト設計方法論で用いられているモデルの種類
    • フローモデル(制御フロー、データフロー)
    • 状態遷移モデル
    • トレースベースモデル(シーケンス図やコラボ図など)
    • 組み合わせモデル
    • 統計モデル(ユーザプロファイルモデルなど)
    • 代数的モデル
    • 形式モデル

次にやること

実際のソフトウェアを使ってモデルを導く⇒それを使って抽象テストケースを導く をやってみる。

ここまでの感想

ソフトウェアテストを考えるときにテスト設計を最上位に置くより、こういうったメタな概念から連なるものと考えたほうが、応用や新しいものを生み出すときに有利に働くかなと。テストプロセスでいう、テスト分析とテスト設計の間に挟まるもの、ですね。智美塾でまさに議論しているテストアーキテクチャの一種なのかも。

TABOK - テスト自動化のスキルカテゴリ まとめ

ソフトウェアテスト システムテスト自動化


http://www.automatedtestinginstitute.com/home/index.php?

数回にわたってお送りしてまいりました、テスト自動化の知識体系TABOKのさわり(アブスト)に触れるシリーズ。訳にかなり苦しんだところもありましたので、誤訳や意味落ちについては是非ご指摘を頂ければと思います。


スキルカテゴリ1〜7がリーダー、マネージャ向け。8〜12がエンジニア向けです。テスト自動化技術者のこと、"Automator"と呼ぶのですね。Macの自動操作環境みたい。一応Windowsにも"WSH"という自動操作環境があります。簡単なプロダクトであれば操作だけならこれで充分なので、興味のある方は調べてみてくださいね。

目次