今回は、私が今勉強していることについて書きたいと思います。
また、その主な内容としてJSTQB(Japan Software Testing Qualification Board)のFoundationLevel試験(http://www.jstqb.jp/)の内容をもとに進めたいと思います。
＊本当は合否がわかってから書きたかったというのは、この際おいておきましょう。
内容は、以下の内容です。
(参考書は、JSTQBのHPで公開されているシラバスですが、偶然、弊社技術部の本棚で見つけた“JSTQB(FoundationLevel試験)教科書”です)
[１]：テストの基礎
[２]：ソフトウェアライフサイクルを通じてのテスト
[３]：静的技法
[４]：テスト設計技法
[５]：テストマネジメント
[６]：テスト支援ツール
この中から、いくつかの内容を抜粋して紹介していきたいと思います。
[１]テストの基礎
(1)テストとは何か
１．テスト実行作業…計画、テスト条件選択、テストケースの設計
２．テスト実行時の作業…実行結果の確認、テスト終了基準の検証、テスト結果の報告
３．テスト実行後の作業…テストウェアの整理
４．全体を通して行う作業…コントロール(テストマネージャーが行う)
(2)テストの目的
１．欠陥の検出
２．大正ソフトウェアの品質レベルが十分であることの確認と提示
３．欠陥の作りこみ防止
(3)テストの流れ
１．製品がリリースされるまでのテスト
・開発でのテスト(コンポーネントテスト、統合テスト、システムテスト)
・受け入れテスト
２．保守テスト
３．運用テスト
(4)デバッグとテスト
デバッグとは？
欠陥の原因を突き止めてソースコードを修正し、正しく修正したことを確認する開発作業のことです。しかし、テスト担当者がデバッグを知らなくてもいいのかというとそうではないと思います。なぜなら、システムの欠陥だと思われたことが、実はそうではなく、環境が原因の事象かもしれないのに、開発担当者へ欠陥だと主張するのは優しくないと思うからです。
私自身、1年目の時はデバッグの見方もよくわからず報告後に「環境のせいでした、すみません。」などと、言っていたのを覚えています。私の場合、今でもそうであるということは、内緒にしておいてください。(5)ソフトウェアテストの原則
原則１：テストは欠陥があることしか示せない
たまたまテストしていないパターンの故障がおきた。まさかと思うかもしれないですが、このまさかがよくあります。テストでは、「故障する＝欠陥がある」を示すことが出来ても「故障しない＝欠陥がない」ことは示すことが出来ないのです。
原則２：全変数テストは不可能
全変数テストとは、ソフトウェアに入力する可能性のある、すべてのパターンをテストすることです。
<ex>２つの数をの和を求めるテスト。
この時、１桁の正の数値のみが対象だとすると、全パターンは、10×10=100(パターン)である。しかし、これは正常系のみのテストである。異常系のテストは？-1入れたら?10いれたら？実際故障の多くの原因は「予期せぬ」入力パターンで引き起こされます。まして、組み合わせテストもしなくてはいけないとなれば、膨大な時間が必要となり、全変数網羅などとうてい不可能なのです。
そのためにも、ソフトウェアの性質や目的、使われ方など、重点的にテストをする場所を絞ること、優先順位を決めてテストすることが重要となるのです。
(＊テストの優先度(順番)については、QAエンジニアのinomata先生が書いていましたね(http://shanon-tech.blogspot.jp/2012/08/blog-post.html))。
原則３：初期テスト
欠陥が作りこまれないように開発の早い段階で初期テストをすることが、大変重要になります。作りこんでしまってからでは、修正にかかるコストがかかってしまいます。
ソフトウェアの欠陥をリリース間際で見つけると、設計者はその設計またはコーディングを行った時のことを忘れてしまい、その結果、原因を特定するのに時間がかかり、間違った修正の仕方をしてしまいます。
原則４：バグゼロの落とし穴
ソフトウェアテストで故障を見つけて、欠陥を完全に治したとしても、ソフトウェアとしては役に立たないことがあります。
<ex>「入力時に４桁までしか入力できない」というインシデントがあり、修正して５桁も100桁も入力できるようになったとします。しかし、この対応により、動作が遅くなり、そのソフトウェアが使い物にならないというクレームに繋がります。「～ができない」という問題がなくなったことは確かですが、また別のインシデントとなったのです。
インシデントの報告を受け、修正を行うことは大切ですが修正を行う際に、機能や性能、システム全体に影響はないか、といったことを確認することも修正する上で大切な作業だということを忘れないことが、重要です。
[２]～[４]のテスト技法については、いつかに、これまたQAエンジニアのinomata先生が書いていたと思うので、興味のある方は履歴をたどってみてください。以下、URLよりご参照ください(http://shanon-tech.blogspot.jp/2011/05/blog-post.html)。
[５] ：テストマネジメント
(1)テスト組織と独立性
・同じ開発プロジェクト内の独立したテストチーム
・同じ会社内にある独立したテストチームで、プロジェクトマネージャーや上位管理者の直属組織
・顧客、ユーザーコミュニティー、ITから派遣された独立したテストチーム
・使用性、セキュリティー、標準準拠(ソフトウェアが標準や規定に準拠していることを認定する)など、ある特定のテストをする独立したテストのスペシャリスト
＊独立性が低い順に記しています
(2)独立したテストの利点と欠点
１：利点
・先入観がないため、開発担当者と異なる視点で欠陥が見つけられる
・システムの仕様策定中や実装中に想定通りか検証できる
２：欠点
・開発チームから隔絶される(完全に独立の場合)
・独立したテストチームが、最終チェックポイントとしてボトルネックとなる
・開発担当者の品質に対する動機付けが弱まる
＊「テストはテストチームがすべて実施するから、品質の確認はテストチームに任せています」などといった発言が出てくる場合は、開発チームの品質に対する意識が薄れている状況を表しています。開発チームの観点でテストは実施されなくてはいけません。
[６]：テスト支援ツール
(1)ツール支援によるテストの利点とリスク
１：ツールで期待できる効果
・ツールにより自動化できるため反復作業が減る
・繰り返しテストを実施できるため、一貫性や再実行性が増加する
・ツールによるテスト結果を用いることで、客観的な評価が可能になる
・テストやテストケースの情報へのアクセスが容易になる
２：ツールを使うことによるリスク
・テストツールの効果を過大に期待してしまう
・テストツールを初めて導入する場合い要する時間、コスト、工数を過小評価する
・大きな効果を継続的に上げるためには必要な時間や工数を過小評価する
・ツールが生成するテスト資産を保守するために必要な工数を過小評価する
・ツールに過剰に依存する
・ツールを利用できるテスト担当者が限られてしまうため、ツールを利用することがかえって工数が増大する
このツールについて、QAマネージャの井上先生がJenkinsについて書いている(http://shanon-tech.blogspot.jp/2012/07/awsselenium.html)ので、のぞいてみると、とても幸せになれるかもしれないですね！！私自信、このセミナーに視聴者として参加してきましたが、自分がやっていること、どう考えられて実行されてきて今があるのかなどがよくわかった気がします。
さらっと、書いてきましたが、まだまだ私も知識不足で毎日がお勉強の毎日です。
以上、最近、上司に「倉持、SQL書けるの？すごいじゃん。」と言われて、喜んでいる倉持の記事を終わりにしたいと思います。
