>& STDOUT

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

あとで見る的にURLとタイトルを自分にDMするブックマークレット

こんぴた的な話

戯れに書いたのが案外ものすごく使ってるのでしぇあ。

javascript:location='http://twitter.com/home?status='+encodeURIComponent('d ★ココを自分のIDにする★ '+document.title+' '+location.href);

任意の名前のブックマークのURLを上記に書き換えてください。★をIDにするのをお忘れなく。

ところで

見ての通り window オブジェクトにぶら下がっている encodeURIComponent() はメジャーブラウザ全てで利用できるようです。この window オブジェクトはずっとブラウザベンダの好き放題の拡張がされてきたのですが、HTML5 でようやく規定されました。HTML5 で一番嬉しい仕様のひとつ。良かったね！ navigator とか location オブジェクト！

http://www.w3.org/TR/html5/browsers.html#the-window-object

ちなみに HTML5 では window オブジェクトは browsing context という実装上の概念から WindowProxy 経由でアクセスすることになっています。これは、iframe の中 や open された window から見てどの window が親なのか、はたまた先祖なのか仕様を整理するためにあるようです。history オブジェクトも session history という概念でここに定義されていますが、実体は window.history で返せとあるので特に戸惑うことなく利用できるでしょう。

と、ここまで書きながら仕様を眺めてて、locaion オブジェクトに href が無い！と焦ったのですが implements URLUtils; の先にありました。ふう。

Rubyのメモ

こんぴた的な話

「初めてのRuby」でいろいろ新鮮だったのでメモ。なお、本書は「(他言語をやってるヒト向けの)Ruby入門書」であり、決してプログラミング初心者向けではないことに注意。プログラミング自体はじめての方は「作りながら学ぶ Ruby入門」とかオススメっぽいです。

初めてのRuby

初めてのRuby
作りながら学ぶ Ruby入門

作りながら学ぶ Ruby入門

1 がオブジェクト

Rubyの洗礼というかなんというか。「何でもオブジェクト」っぷりはJavaScriptの上行ってました。

hortensia:~ snsk$ ruby -v
ruby 1.8.7 (2011-12-28 patchlevel 357) [universal-darwin11.0]
hortensia:~ snsk$ irb
>> 1.to_s(10) #引数は基数。この場合、10進数で文字列に変換。
=> "1"

もう少し詳しく書くと整数はFixnum、少数はFloatというオブジェクトにになります。巨大な数はBignumで、どこまでがFixでどこからがBigか、は実行系によって異なるようです。

>> 1.class
=> Fixnum
>> 1.1.class
=> Float
>>

なお、rubyでは変数がオブジェクトではなく格納されているアドレスへのポインタであるため、インクリメントが利用できないそうです (参考)

> num = 1
=> 1
>> num++
?> p num
SyntaxError: compile error
(irb):22: syntax error, unexpected tIDENTIFIER, expecting kDO or '{' or '(' from (irb):22
>> num+=1
=> 2

制御文 じゃなくて 制御式

if(hoge != 0){/*do something*/} という擬似コードがあったとき、他の多くの言語では hoge != 0 だけが「式」ですが、Rubyではこの手の制御構文が「式」として定義されています。 先ほどの擬似コード例では、 if(hoge != 0){/*do something*/} 全体が「式」です。式なので評価され、時に値を返します。if式においては実行された文の戻り値が if 式の左辺に入ります。よって、下記のような書き方が可能で、わりと一般的なんだそうな。

status = if unitTestResult == "green" then
    "passed"
else
    "failed"
end
p status #=> "passed"

また、rubyでは繰り返し処理にイテレータを使うのが一般的で、each、times、upto、downto、など専用のメソッドが豊富に用意されています。これをブロック付きメソッド呼び出しと一緒に使うことでオブジェクト(のメンバ)に対する繰り返しを表現するようです。ここ初心者詰まりそう。


1から100まで出力する一例は以下のとおり

100.times do |i|
  puts i
end

"||"で囲まれたローカル変数iに対してブロック内の処理を行う。ちなみに、do と end の代わりに { と } を使うこともできますが、基本的には「rubyっぽい」do と end を使い、

  • ブロック付きメソッドがインラインの場合
  • ブロック付きメソッドの戻り値を利用する場合
  • ブロック付きメソッドからメソッドチェーンを利用する場合
  • openが自動的にリソースを開放することを明示するためにブロックを使う場合

に限り波括弧を使う、という使い分けが本書で提示されていました。
特に思想ないのでこれにしようと思います。

nil と false のふたつの擬似変数以外は全て"真"

「0」も「""」も全部 "真"。
「0以外」が全部"真" なCいくつだかの仕様の真逆ですね。これは他言語からのヒト引っかかりそう。

File::open はブロックを渡すと自動的に開放してくれる

おお！便利！と思ったのですが、これだけ覚えてると「ブロックを渡さない場合は明示的にclose呼ぶ必要がある」が抜けそうで怖いです。

=== は Object#== の別名

PHPやJSから来たヒトがよく引っかかるところです。Good partsでは「常に === を使え」って書いてあるし。Rubyの === は型チェックしません。な、なんだってー！とつぶいたところ「ビルトインクラスと比較することで一応型チェック的なことはできるけど、言語の思想自体がダックタイピング推奨っぽい」とレスいただきました。なるほど。

軽量品質保証 - Lightweight Quality Assurance In Software Development-

軽量品質保証の部品


はじめに

「ソフトウェア品質保証」という活動や技術分野にみなさんはどのような印象をお持ちでしょうか。工業製品で無敵を誇った品質大国ニッポンの志はソフトウェア品質保証にも受け継がれ、特に「モノづくり」の課程に対する姿勢は欧米からも範とされています。世界初のソフトウェア品質知識体系ことSQuBOKも日本の編纂によるものであり、その多くの知識エリア、特にテスト技法や経営まで視野にいれた品質マネジメントについては日本発の考え方や方法論が存在感を示しています。それだけに、「何かとっても難しそう」「具体的にどうしたら”出来た”と言えるのか、言っていいのかわからない」と感じる方も多いのでは無いでしょうか。特に、組織からの支援や潤沢な資金を与えられることの少ない非クリティカルシステム、超短期開発の現場において。さらに懸念されることは、そういう印象を持った結果、「ソフトウェア品質保証」という取り組み自体を諦めてしまう、または目の前にあるいくつかのそれらしい方法を組み合わせてお茶を濁してしまうことです。



”正しい”方法は、対象とする製品に見合った適切な品質の見極めとそれを保証する方策自体をデザインすることです。しかし、それにはソフトウェア品質保証技術に対するそれなりの造詣と経験が求められます。だからこその技術分野なのですが、余裕のない現場がこの技術分野への取り組み自体を諦めてしまう、おざなりにしてしまうのはとても残念なことに感じます。言うなれば、いまこれから「ソフトウェア品質保証」を学ぼうとする人には「富士山」しかない状況です。これから登山を嗜んでみようかと考える人が「富士山以外は山と呼ばない」と言われたら多くの人は怯むと思います。おそらく、これが現状です。

ソフトウェア品質保証の「高尾山」を

はじめて登山をする人が周りに居たら、関東なら誰もが「まずは高尾山に登ってみたら？」と薦めるハズです。山登りの厳しさではなく、楽しさを先に実感してもらうことで、さらなる高みを目指すモチベーションの土台を作る意図がそこにはあると思います。これをソフトウェア品質保証の世界にも当てはめられないか。もっと言えば、非クリティカルシステム、超短期開発の現場で悩むQAエンジニアにいったん「それでいいんだよ」「しっかりやってるよ」と言ってあげたい。そうして、まず小さな、確実な成果を出してもらうことで、プロセス自体の改善や、さらなる高みを目指すモチベーションを持って貰いたいと考えました。

できるの？そんなこと

直接的な動機の面は以上ですが、本当にそんなプロセスを定義することが出来るのでしょうか？先人たちの研究の成果や、ツールの発達によって、品質保証技術自体の適用も低コストで行える芽が出てきたと感じています。例えば一昔前に「レビュー指摘数」というメトリクスを採取するのはかなりのコストを必要としました。しかし、現在レビューはSCMに付属の機能や、専用のOSSツールを利用することが特に非クリティカルシステム、超短期開発の現場においては当たり前になっており、指摘数とその対応程度、及びターンアラウンドタイムなどを採取することが容易になっています。

ここがキモで、こういう現場はツールの導入やプロセスを変えることを厭いません。ということは品質保証技術を適用するためのツールや技術の導入のハードルも低く、残りの関門は「何があるのか、何を選べばいいのか知らない」だけである可能性が高いのです。であれば、そこだけビシっと定義してあげれば割と容易に成果を出すことが可能になるのではないでしょうか。

具体的なプロセスや利用する技術の選定はこれからですが、本ブログや書籍で何度か触れたことがある品質モデルの定義は最初のステップとして入れたいと考えています。ハードルを下げると言っているのにそんな難しそうな手順を入れて大丈夫なのかと感じられるかもですが、ここを外すとすべてを大きく間違えてしまう、外せない技術のひとつであると考えています。もちろん、1, 2時間で出来るようにデザインします。

軽量品質保証 - Lightweight Quality Assurance はどんな特徴を持つか

現時点での要件やメッセージを考えてみました。

  • ひとり、またはふたり程度で実現可能であり、組織を必要としない
  • 2週間程度のプロジェクトにゼロから適用出来る
  • 極限まで人的、調達的コストを掛けない
  • 省いた部分のリスクを明らかにする
  • 継続的改善へのアプローチを盛り込む
    • 何度も行うことを前提とする
  • 正確に間違えるよりも、漠然と正しくありたい
  • 安い、早い、うまい

検討を進める中で落ちるかも知れませんがまずはここを達成したいなと思います。

軽量品質保証 - Lightweight Quality Assurance は何で無いか


いまあるソフトウェア品質保証を革新/刷新するものではない

ミッションクリティカルな製品や多くの組み込み系など、いまある体系を正しく理解し、適切に設計すべき分野もたくさんあります。そういう分野ではどうしても軽量というわけには行かないことが多いと思われます。

対立軸ではない

もし仮に重量品質保証というものがあり、そう感じておられる方がその対立軸として本件を捉えられているとしたらそれは明確に誤りです。どちらも単なる現場へのアプリケーションであり、重視する品質概念自体に違いはありません。

特定の開発プロセスを前提とするものではない

適用出来る開発プロセスの種類を限定するつもりは無いです。結果として向き不向きが生まれてしまう可能性がありますが、継続的改善は盛り込みたいと思っています。

興味があるので議論に加わりたい

ありがとうございます。下記にグループを作成しましたので、お気軽にご参加ください。ほとんどの資料、議事録等の管理にGoogleのインフラを利用する予定です。他のメールアドレスをご利用の方は、Googleのアカウントに、現在ご利用頂いているアドレスをひもづける形で、インフラを利用できる体制を整えて頂けますよう、お願い致します。

https://groups.google.com/group/Lightweight-QA

もしかしたらこのアドレスは取れない(他の人が取ってる)かなと思いましたが、案外あっさり取れました。

その一歩先にあるもの

この考えの大本は、各地の非クリティカル、超短納期開発に関わる若手のQA、テストエンジニアから「本当にできているのか自信がない」「やり方がわからない」という生の声をたくさん聞いたことがキッカケになっています。中には「おお！すごいじゃないですか！」と手放しで称賛できるプロセスもあったのですが、僕が言うだけでは何の足しにもなりません。いったん、公で作られた低いハードルを超えてもらうことで、ソフトウェア品質保証技術者としての矜持をきちんと持ってもらい、その先の探求に興味を持ってもらうことで、これがスコープとしないクリティカルシステムや大規模開発の分野における研究とも対流が発生するようになると考えています。そうして、この技術分野全体の活性化とさらなる発展に繋がっていくと良いな、とも考えてはいますが、達成できなくてもいいです。ゲンバの人たちが楽しく仕事できることがゴールです。

references

ISO/IEC25010 品質モデル

ソフトウェアテスト

長らくソフトウェア品質モデルとして親しまれてきた ISO/IEC9126 が ISO/IEC25010(ISO/IEC 25000 SQuaRE シリーズの一部) として補強、改訂されましたので、ここで紹介したいと思います。参考文献 *1 がかなりイケているのでそちらを直接参照されても良いかと思います。

利用時の品質

9126時点では主特性のみの定義であった「利用時の品質」に副特性が定義されました。主特性自体も「効率性」「有効性」「安全性」「満足性」から多少の変更が見られます。



ISO9126時点での利用時品質の定義


注目すべきはコンテキストカバレッジで、システムの利用が机の前に限らなくなってきた昨今の状況がよく反映されているように思います。

データ品質

データ品質は主特性というより、以下の様なカテゴリに分かれます。

  • 固有のデータ品質特性
    • システムが介在しなくても存在、評価できるデータが本来持つ品質特性。例えば紙の書類の回覧でも同様の品質が求められる
  • システム依存のデータ品質特性
    • データをシステム上で運用する段になってはじめて問われはじめる特性
  • 固有及びシステム依存のデータ品質特性
    • 前述のふたつの側面を併せ持つ特性。例えば「日付データ」などは、年号/日付 の記述方式といったデータ自体の特性と、システムで扱われる際のフォーマットの側面からの特性の両方を併せ持つ

システム/ソフトウェア製品品質

こちらは9126でもおなじみ、品質モデルというとこれを想起される方も多いでしょう。注目すべきはセキュリティが主特性として昇格している点や、9126では全主特性の子に存在した標準適合性が削除されている点などです。

テスト計画やテスト基本設計を考えるときについそのまま当てはめようとしてしまいますが、保守性や移植性など、テストよりプロセス、プラクティスで保証されるべき性質のものがあったり、その製品に本当に「互換性」が求められるのか？など、何段も製品に寄った運用が必要になります。

*1:システム／ソフトウェア製品の品質要求定義と品質評価のためのメトリクスに関する調査報告書 2011 年 3 月 経済産業省 ソフトウェアメトリクス高度化プロジェクト プロダクト品質メトリクス WG

テストの本書きました。

ソフトウェアテスト


Androidアプリテスト技法

Androidアプリテスト技法


「書店で見掛けました！知ってる人が表紙に載っているのって嬉しいですね」


と会社の同僚に言われてふと、昔小劇場演劇に関わっているころ、同じように他の劇団のチラシの演者やスタッフ欄に知り合いの名前見つけて嬉しくなったことを思い出しました。本件に限らず「知っている人」の著作は受信精度が全く異なるものですよね。


記念すべき1冊め。下記目次のうち、僕は1章、および2章のテスト分析の部分までを書きました。あまり予算が取れない種のスマートフォンアプリ開発プロジェクトに向けた軽量なテスト分析の方法を提案しています。なお、僕の執筆部分については、Androidにまったく限定しておりません。逆に3章以降はテスト部がこれまで蓄積してきた"いますぐ使える"テスト実行のためのTips満載ですので、お好みに合わせてどこからでも拾い読みして頂ければと思います。

1 Androidテスト基礎(そもそもテストとは?
　テストの重要性
　ソフトウェアテストの考え方
2 Androidテスト実践(挑戦!テスト分析
　テスト設計技法‐同値分割法・境界値テスト
　状態遷移テスト ほか)
3 AndroidテストTips(ロジックのテストをしたい
　Activityのテスト
　バックグラウンド ほか)


ありがたいことにAmazonでは既に入荷待ちになっていますが、もし街の書店で見かけたら是非お手にとってみてくださいね。執筆に関わられたみなさま、お疲れ様でした。レビューアのみなさま、およびテスト部を支えてくださった部員のみなさまへ、ご支援のほど感謝です。

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つのポイントが変わることはありませんので、これを如何に軽量化するかを考えてみて頂けると、よろしければ一緒に考えて頂ければ幸いです。

開発遅延

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

おわりに

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

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

ご指摘と改版履歴