SQA Insider

ソフトウェア品質保証、ソフトウェアテストについてのメモ書き。

動的SSL証明書発行 (Dynamic SSL Certificate Generation) が有効なSquidを作る

Software Testing

まともに動く環境にするまでかなりはまってしまったので、誰かの役に立つようにメモ。
CentOS 6.5 で動作確認。参考にした元ネタ: http://sysmagazine.com/posts/168515/

Squidで使用するOpensslの準備

インストール

wget http://www.openssl.org/source/openssl-1.0.0k.tar.gz
tar -zxf openssl-1.0.0k.tar.gz
cd openssl-1.0.0k
./config shared --prefix=/opt/squid/openssl --openssldir=/opt/squid/openssl
make
make install

ln -s /opt/squid/openssl/lib/libssl.so.1.0.0 /usr/lib64/libssl.so.1.0.0
ln -s /opt/squid/openssl/lib/libcrypto.so.1.0.0 /usr/lib64/libcrypto.so.1.0.0

オレオレ証明書の発行

cd /opt/squid/etc/
openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout squidCA.pem -out squidCA.pem
chmod 400 squidCA.pem
openssl x509 -in squidCA.pem -outform DER -out squid.der

Squid

インストール

wget http://www.squid-cache.org/Versions/v3/3.4/squid-3.4.6.tar.gz
tar -zxf squid-3.4.6.tar.gz
cd squid-3.4.6
./configure --prefix=/opt/squid --enable-ssl --enable-ssl-crtd --with-openssl=/opt/squid/openssl --enable-icap-client
make all
make install

証明書発行のキャッシュディレクトリを用意

mkdir /opt/squid/var/lib
/opt/squid/libexec/ssl_crtd -c -s /opt/squid/var/lib/ssl_db
chown -R nobody /opt/squid/var/lib/ssl_db

squid.conf の編集

下記の記述を追加。

####Dynamic Certificate Generation####
http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/opt/squid/etc/squidCA.pem
always_direct allow all
ssl_bump client-first all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER

Squidの起動準備

ログの所有者の変更と、（必要に応じて）スワップディレクトリの準備を行う。

chown -R nobody /opt/squid/var/logs
/opt/squid/sbin/squid -z

Squidの起動

/opt/squid/sbin/squid

クライアント側の準備

ブラウザーに squid.der をインポートしておく。

  • IEの場合「信頼されたルート証明機関」にインポートする。
  • Firefoxの場合、「この認証局による Web サイトの識別を信頼する」を選択してインポートする。

テストの進捗管理

Software Testing

管理対象のテストセットが複数のファイルに分かれているのであれば、それぞれのファイルに集計表シートを1枚作成し、さらにひとつ管理用のファイルを作成し外部から参照するとよい思います。
これはテスト実行者にとっての進捗把握と、テストマネージャーによる進捗管理を兼ねるようにするのが目的です。
テストマネージャーは日常的には、管理用ファイルだけを見ればテストの実行状況を把握できるようにするのがゴールとなります。

管理すべき項目

テストの進捗管理では、以下の項目を管理する必要があります。

  • テストケース数
  • 合格数
  • 不合格数
  • スキップ数
  • 実行件数・・・合格数＋不合格数
  • 未実行件数・・・テストケース数－実行件数
  • テスト除外数・・・あらかじめ実行対象外としたテストケースの数でスキップとは異なる

また、バグの発生・処理状況についても同じファイルにプロットすると、テストが有効かどうかについての考察ができます。（テスト実行数 vs バグ検出数 および スキップ数 vs 未修正バグ数）

これは以下の項目を管理対象とします。

  • 検出バグ数
  • 修正バグ数・・・ステータスがRESOLVED以上になったもの

なお、品質保証のためのバグ曲線は追加の要素が発生しますので別途作成するべきです。一つのファイルに機能を持たせすぎるとわかりにくくなります。もちろん、元の生データを共有する分には問題ありません。

検出バグ数の取り方

下記は一例ですが、ノイズが混入しないように気を付ける必要があります。

  • ターゲットマイルストーン=現在のプロジェクト
  • バグでないもの（仕様、要望、重複）を除く
  • 欠陥であっても、プログラムでないもの（仕様書、マニュアル、開発ツール、質問、オンラインヘルプ）を除く（これは流儀による）

チケットの棚卸しを習慣づける

SQA ITS

製品の息が長くなってくると、LATERのままになっているチケットが山積するようになってきます。
これらについてはかならず定期的に棚卸しを行います。

開発部門だけでなく社内のその製品に関するあらゆる人に声をかけて、棚卸しを実施します。
棚卸しを行うタイミングは、プロジェクトの谷間がよいでしょう。
当然、次期プロジェクトのスケジュール・予算の見積にも影響するためです。

棚卸しでは、以下のいずれかの判断をするようにします。

  • 今のメジャーバージョンで直す気がない、制限事項とする・・・WONTFIX にして CLOSED にする。
  • 今のメジャーバージョンで直す気がある・・・ターゲットマイルストーンを再設定して REOPENED にする。
    • トラッカーにはあらかじめ将来のマイルストーンを入力しておく必要があります。
  • 今のメジャーバージョンでの仕様として扱うこととする・・・INVALID にする。

ポイントとしては、即断できるものから決定していき、判断に迷うものについては
個別に製品企画会議を開催するとよいと思います。

ITS (Issue Tracking System) トラッカー運用ガイド #1

SQA Software Testing ITS

優先度決定のための要素の定義を明確にする

新規チケットに対してどのように対処するべきか判断できるよう、優先度決定のための要素の定義を明確にしておく。
これはチケットのトリアージをする際に拠りどころとなる情報なのでとても大切です。
また、基準を明確にしておくことで報告者が報告を遠慮することがなくなります。
（ルールとして、些細な現象についての定義をしておけば、些細な現象を堂々と報告できるようになります。）

要素の定義ですから、内容の正しさというものは組織ごとに設定するものとなります。
以下はあくまでサンプルです。

発生したときのインパクトの大きさ

  • データ消失
  • 脆弱性
  • メモリ破壊
  • システムの停止
  • 誤課金
  • リソースの浪費
  • 低パフォーマンス
  • 処理の誤り
  • デザイン間違い
  • 文言間違い
  • アクセシビリティの課題

再現率

  • m回試行してn回以上
  • m回試行してn回以上
  • m回試行してn回以上

利用時の発生頻度

  • かならず
  • そこそこ
  • まれに
  • ほとんどない

回避手段の有無

  • なし
  • あり（難しい）
  • あり（簡単）

機能ごとの重要性

  • 基本提供機能
  • エクスポート機能
  • ログ機能
  • インストール機能
  • アップデート機能
  • 設定変更機能

ITS (Issue Tracking System) トラッカー設計ガイド

SQA Software Testing ITS

トラッカーにおけるチケットのワークフローは、ライフサイクルを表すステータスと、何らかの属性を表すレゾリューションによって成り立っています。

ここでのポイントは、チケット処理の過程でボールを持つ役割の数以上にステータスを増やさないということです。ステータスの数はできる限り少なくし、運用上必要な属性情報はレゾリューション、カスタムフィールド、タグを使って実現するようにトラッカーを設計します。

ステータス

上記の理由から、必要なステータスは下記の5つのみとなります。

  • [NEW] (起票者が [NEW] にする。)
  • [RESOLVED] (修正担当者が [RESOLVED] にする。)
  • [VERIFIED] (検証担当者が [VERIFIED] にする。)
  • [REOPENED] (検証担当者が [REOPENED] にする。)
  • [CLOSED] (リリース担当者が [CLOSED] にする。)

実際のところ、このほかに [REJECT] (却下) に相当するステータスを実装しているトラッカーは多いように思いますが、これはライフサイクルではなく、処理結果の一種（レゾリューション）であるため、ステータスとしては適切ではないと考えます。

また、[ASSIGNED] (アサイン済み) のようなステータスをデフォルトで導入しているトラッカーもありますが、基本的に「担当者」フィールドに By Name が入っているのであれは、アサイン済みであると判断できるため、冗長となりうるステータスと考えます。

【備考】 あくまで我々が管理しているのはバグではなくインシデントですので、バグであると判断されたかどうかによってワークフローを変えるべきではありません。通常のライフサイクルに載せることによって、修正担当者がインシデントをどのように切り分けたかにせよ、その判断の妥当性について検証担当者は確認をする機会を得ることができます。

レゾリューション

レゾリューションには、チケットがあるステータスのときにひもづけられる属性のうち、汎用的に利用したいものを定義します。
個人やプロジェクト単位で追加で利用したい属性に関しては、レゾリューションではなくタグを利用するをおすすめします。
これは組織において取得可能なメトリクスの粒度を統一するためという品質保証上の理由がひとつ、もうひとつはトラッカーの設定が複雑になるのを避けるためというプロジェクト効率化の理由がひとつです。
レゾリューションはステータスを変更するときにしか設定されませんが、タグば必要に応じていつでも付け外しをしてもよいという性質があります。

レゾリューションとして定義した方がよいもの

それぞれ、修正担当者が [RESOLVED] にする際にあわせて使用します。

INVALID

報告された内容は仕様通りの動作です。
単純な起票間違いはここに含んではいけません。

DUPLICATED

重複した報告です。

FIXED

調査した結果、バグでした。コードの変更が終わりました。

LATER

調査した結果、バグでしたが、直近のマイルストンに向けては修正しません。

WONTFIX

調査した結果、バグでしたが、この製品においてはもう修正せず、制限事項とします。

WORKSFORME

再現できません。より詳細な条件や再現手順を追記して再度報告してください。

タグで運用した方がよいもの

起票間違い

操作ミスにより登録されてしまったチケットで、INVALIDとは異なります。
ノイズとなってしまうので、管理者はそのチケットを削除するか、適切なトラッカーに移動させるかするべきです。

要望

要件定義漏れに相当する可能性がある内容の報告です。
仕様の欠陥に対する指摘は含まない点に注意が必要。