CLOSEしたチケットをREOPENしてはいけない
CLOSEしたチケットの扱いを「リリース済み」としている場合には、そのチケットをREOPENすることは過去の事実を改変することになるのでできません。
仮にリリースした後に、先祖返りをした場合や、極めて類似する現象が発生した場合であっても、それらは新規のチケットとして起票します。全てのチケットはリリースに紐づいていると考えるとわかりやすいと思います。
派生開発の場合などでそのコードに潜在的に問題が含まれる場合も同様で、別途チケットを発行します。
ITSの設定で可能であれば、CLOSEしたチケットのステータス変更をできないようにしておくといいと思います。
もし同じ内容のチケットが多すぎると感じるようであれば、問題は別のところにあります。多すぎると感じないのであればいくら同じ内容のチケットがあっても構いません。このあたりは文化の違いです。
仕様は完璧には文書化できない
仕様と仕様書をわざと混同させる人が世の中には多いように感じます。
外部仕様を外部仕様書と言い換え、システムテストの項目数が外部仕様書のカバレッジを十分満たすようにし、
自分たちの製造したシステムは要求通りであると主張するテクニックですが、
これは「仕様は完璧に文書化できる」という理解しがたい主張に基づいているわけです。
誰だって良い仕様書を書こうと努力するはずですが、
もともとドキュメンテーションは仕様を伝えるための一つの手段に過ぎず、
仕様書がないと仕様は明らかにならないわけではなく、
また、仕様書さえあれば仕様が明確にできるわけでもありません。
ドキュメントに対しての承認さえ発注者から得られれば、
仕様に対しても承認を得たと解釈しようとするのは、やってはいけないことのひとつです。
QAは外部仕様策定とどう関わるべきか
外部仕様の策定リードですが、現実的には設計担当者が外部仕様を決めざるをえない事態になることが多い気がします。
また、しばしば経営者やUIデザイナー、マーケティング担当者、声の大きい顧客、
またはその代理人のような営業担当者が具体的に外部仕様を決めたがることもあります。
いろんな人が仕様策定に関わるということは健全なことだと思いますが、
問題なのはみんなで議論するというよりは、いつもその時の声が大きい人間に振り回されがちということですね。
Quality Branding のことを考えれば、ひとつのガイドラインを用意して、
それに沿った仕様になっているかQAが確認するべきなんだと思いますが、
ガイドラインがないのであれば、もう自分の考えだけをよりどころにするしかありません。
そんなときのために審美眼のようなものをもっておきたいものです。
自動プロキシ構成スクリプト (PACファイル) の標準仕様的なもの
いざ、PACファイルを適切に扱えているかのテストをしようとしても、
PACファイルの仕様はもともとNetscape独自のものだったようで、
標準仕様書のようなものは見当たりません。
Netscapeのサイトからも消えてしまっているので、
ウェイバックマシンのお世話になるしかないところですが、
日本人であれば下記の日本語訳を参照するのがいいと思います。
http://www.kandk.co.jp/html-memo/Server/cached/proxy-auto.html
テスト対象のソフトウェアのPACファイルの解釈が適切であるかどうかを知るには、
テストオラクルとしてIEやFirefoxなどのふるまいをあてにするしかないように思います。
オレオレ証明書で動いている、ユーザーログインが必要なWebアプリのテストサーバーに対して、JBlitzでユーザーログイン下を再現して負荷をかけたいとき
JBlitzでセッション偽装オプションを試してもどうしてもうまく動かなかったときのメモです。
準備: オレオレ証明書を使用した試験サーバーにアクセスできるようにする
- テストサーバーのオレオレ証明書をPEM形式で保存する。Firefoxであれば、ページ情報からエクスポートできる。
- JBlitzで使用するJREのbinで、下記のコマンドでオレオレ証明書をデフォルトのKeyStoreに格納する。(JREによりcacertsのパスは異なる)
keytool-import-fileFCServer.pem-keystore"C:\ProgramFiles(x86)\Java\jre6\lib\security\cacerts"
セッションを偽装する
ユーザーごとの処理をして負荷をかけるにはセッション管理を適切にする必要がある。
JBlitzでセッション管理を有効にしても、どうにもうまくいかなかったので、
ブラウザのリクエストを偽装して負荷テストをする。
手順は以下の通り。
