これは何の記事？
普段私がやっている、ソフトウェアテストおよびそれに関連する業務についてを言語化したものです。
単純に作業内容を書いても仕方ないので、私が気を付けていることなどについても記載していきます。
今まで自分がしていることを文章などでアウトプットすることが少なかったので、Advent Calendar の力を借りてつらつらと書いてみています。
※書きたいことが多すぎるので、適宜追記していきます
※※Advent Calendar までに間に合いませんでしたすみませんorz
用語はなるべく JSTQB の用語に合わせるように頑張っています。
以下、JSTQB で定義されているテストプロセスについて、それぞれ記載していきます。
テスト戦略の策定
案件が立ち上がる最初から QA としてアサインされた場合は、まずテスト戦略を考えます。
考えることは、体制（リソース）、スケジュール、テスト環境、ツールの利用計画、アプローチ、実施方法、進捗管理方法、不具合管理方法、リリース判定、クライテリア、成果物の定義、など色々ありますが1、それ以前に私が大事だと思っていることは顧客の要求の正しい認識です。
目指す品質が決まっていないと、戦略も立てられないので。
あとテスト戦略は、一度決めたらずっとそれに従うのではなく、絶対に後から変更、修正が入ることを想定して作ってます。
よほど小さい案件を除いて、状況が変わらない案件はないと思っているので。
むやみに変更するのも良くないですが、そもそもテスト戦略は達成したい品質を達成するために考えているものなので、そのときそのときに最適な手段を選択することは良いことだと考えてます。別に、戦略なくても品質目標達成できるならなくてもいいですし。
また、案件が必ず上手くいく保証はどこにもないので、むしろ、上手くいかないときのケースを考えておくことは重要です。
起こり得るリスクに対して、対処法まで書けていたら十分でしょう。
テスト計画
キーワードはテスト戦略の方に書きましたがリソースやスケジュール、アプローチについて実際に考えます。
テスト戦略同様、開発初期段階で実施したいです。というか、実際のところテスト戦略とテスト計画は一緒にやってしまっています。案件に途中からアサインされた場合は別ですが。
リソースを考えるときはアサインするひとのスキルレベルとか、スケジュールを考えるときは開発が遅延しても巻き返せるバッファとか、など色々なことを考えながら計画します。
あと、後述するテストの自動化を行いたいときは、この段階で計画してます。
開発初期段階であればテスト容易性について開発と相談できるので進めやすいです。
私は snskさんが提唱している「PQM:プラクティカルクオリティモデル」という ISO25010 の品質特性を利用した手法をよく好んで使用しています。
http://snsk.hateblo.jp/entry/20120227/p1
テスト分析
テスト戦略や計画のことは置いといて、「さあ、テスト実施をしよう！」と思ったときに最初にやるのはテスト分析ですね。
ただ実際は、テスト分析とテスト計画はほぼ一緒になってやってしまうことが多い、というか、テスト分析～テスト計画～テスト実装は行ったり来たりします。
あるいは、検出された不具合から新たなテスト条件に気付く、ということもあります。
なるべく最初の段階で多くのテスト条件をだして網羅したいんですけどね。。腕の良いテスタ（テストオペレータ）さんというのは、製品知識とテスト条件を多く持っているのだろうなと思います。
ちなみに私はよく、3色ボールペン法を使ってテスト分析します。
下記を参考にさせていただいています。
http://www.slideshare.net/takashiyamasaki378/ss-55384920
http://www.slideshare.net/Ikedon/ss-33986487
テスト設計・テスト実装
（テスト実装という用語は JSTQB にありましたっけ？）
テスト分析の次に何をするかと言うと、テスト条件を基にテストケースへの落としこみをします。
テスト実行するためのパラメータの付与はこの段階で行います。
テスト実行
実行はテストオペレータの方にお願いすることも多いですが、自分でテスト実行することもある、というか、楽しいのでできれば自分でやりたいです。
許されるならいくらでも探索的テストしちゃいます。
実際、探索的テストの考え方は大事だと思っていて、テストケースに従ってテスト実行しているだけだと、検出可能な不具合は限られてしまいますからね。
テスト分析の項目で書きましたが、持っている製品知識やテスト条件をフル活用して実行することは大事かなと思います。あとその時の思いつきや ”勘” も大事にしたい派です。
あとは、テスト対象には「必ず不具合が存在する（はずだ）」と思いながら取り組む姿勢が大事だったりします。精神論のようですが「この機能は単純だから」とか「開発が優秀だから」とか思っていると、結構見逃します。
ここで注意しておきたいのは、探索的テストはアドホックテストやモンキーテストとは違い、学習・設計・実行・結果のフィードバックを同時に行うアプローチのひとつということで、ただ好き勝手にテストすれば良いわけではないということです。
探索的テストについては下記を参考にさせていただいています。
http://www.slideshare.net/goyoki/ss-34292539
http://jasst.jp/symposium/jasst14kyushu/pdf/S3.pdf
システムテスト自動化
テストに限らずですが、システムテスト自動化というのは、近年の案件の小型化や短納期化などによって、その重要性が増してきているように感じます。
ただ、むやみに自動化を行っても大抵の場合は失敗すると思います。テスト戦略あるいはテスト計画を行う段階で自動化するかしないかの目処はつけておき、計画的に自動化を進める必要があります。
自動化をする／しないの判断は色々な観点から考えるべきだと思いますが、一番分かりやすいのは ROI でしょうか。
自動化は、導入コスト、運用コスト、メンテナンスコストなどが掛かります。
さすがに ”自動化＝コスト削減” のように考えるひとは少なくなったと思いますが、自動化によりどれだけ利益に貢献できるのかを正しく計測することは難しいなと思っています。
システムテスト自動化の初期において、どこから手を付けていけばいいか、については何度も繰り返し行うテスト、デグレを防ぎたいクリティカルなテスト、自動化しやすいテスト、などの辺りから自動化を考えていくことはありだと思います。
以前、システムテスト自動化標準ガイドの読書会に参加したのですが、基本的なことが分かりやすくまとまっているのでご紹介します。
http://makopi23.blog.fc2.com/blog-entry-181.html
不具合報告
不具合報告をするときに気をつけていることはいくつかあります。
・ 簡潔で分かりやすいこと
・ 誰が読んでも理解できること
・ 最低限、以下の項目を記載していること
内容の説明、環境、再現手順、現状動作、期待動作、再現率、
環境や再現手順については他のひとも再現できるよう記載します。
リリース判定
一通りの開発とテストが完了したら、リリース判定を行います。V&V の Validation です。
判定するためには、あらかじめクライテリアを作成しておき、チームや、場合によっては顧客と合意しておく必要があります。
また、その判断のために計測が必要なこともあります。
-
実際に考えるのはテスト計画
品質目標の設定というのは ”テスト戦略” のスコープ外なのかもしれませんが、実務では私はテスト戦略の策定のひとつとしてやっています。
ただ ”達成したいソフトウェアの品質” をずばり言ってくれるお客様は中々いないです。ほぼいないです。
そのような場合はこちらで品質目標を決めて提示してあげます。
機能要件は比較的決めやすいところがありますが、非機能要件を決めるのはいつも難しさを感じます。パフォーマンスとかセキュリティとか。
で、品質目標決めたら顧客やチームメンバと合意をすることが非常に大事です。
品質目標決めたら顧客やチームメンバと合意をすることが非常に大事です。 ↩