ソフトウェアの品質を学びまくる2.0スマートフォン用の表示で見るソフトウェアの品質を学びまくる2.0ソフトウェアの品質、テストなどについて学んだことを記録するブログです。資格Tweetいろいろ書いてきますが、「明らかに間違ってるだろ」とか「それは違わなくない?」っていうご指摘があれば、ぜひくださいませ。わたしは修行中の身です。一人でしんみり学んでいると、読み合わせという活動の喜ばしさがよくわかります。・・・さあ、2.5は、テストの実装と実行です。「実装」とは分かりづらい言葉ですが、要は準備の総仕上げですね。これまで、テスト対象やテスト条件を見定めたり、必要な環境を分析してきたわけですが、ここにきて、それらを実際に準備することになります。具体的には以下の作業が。スケジュール作りスケジューリングにおいて配慮すべき点は2つ。1つはもちろん、テストの目的を達成するために設定したプライオリティ。1つは、テスト環境やテストデータによって現れる制約。実環境に近いくらい十分なダミーレコードをDB上に準備したのに、最初のテストアイテムは、レコード一括削除バッチ!ってどうなのよ。一般的にテスト手順を指して用いられる。自動化時のスクリプトを指す。(JSTQB)とあります。手動か自動かによって、意味が変わるので注意ですね。procedure」とか)、自動なら「テストスクリプト」と使い分けたいところですが。テストデータの準備テストデータそのものだけでなく、それを自動生成するためのツールも含みます。単純なテキストデータであれば、Excelで簡易ツールを作ることも多いですよね。当たり前ですが、テスト環境は事前に準備して、ちゃんと動くことを確認しておけと。ここで「環境」というのは、サーバやネットワーク機器、テスト端末などだけではなく、テスト支援アプリケーションなどのツール面や、テスト中にどのログを保存しておくかといったルール面の整備も含みます。最後の段落は、若干話が各論に飛んでいますが、スクリプトに基づかないテストを、場当たり的に行うなと。testing)などが考案されていますが、これらはあくまで、エキスパートがいて初めて成立する技法ですよと。「計画なんていらない!おれは経験ベースで行くだぜ~」などと安易な気持ちで、テストの自転車操業をしないでくださいねということですね。ここで紹介された3つの技法については知識が足りていませんので、理解できたら紹介します。シラバスに「SBTMの項を参照」とあります。management」のことのようです。これについても、別途ふれたいと思います。テストの実行ようやく、実行です。テスト担当者は、「実装」で決めたスケジュールに基づいてテストケースの消化を行うことになりますが、ある程度の自由裁量(latitude)はアリ。「そういえば、こう操作したらどうなるんだろ?」的な発想は、当然生かされるべきですよね。何をしたかの記録は必須です。テスト実行の主なお仕事は、テストケースで定めた期待結果と現実の結果が、一致するかしないかを見極めるということ(と、その記録!)です。一致しないならば、それはインシデントです。ちなみに、インシデントとは以下。positives」という言葉が出てきます。元々は統計の言葉ですよね。ソフトウェアテストでいうと、それぞれ、「正常なのに欠陥と判定してしまった」「欠陥なのに正常と判定してしまった」ってことです。インシデントの原因は、テストアイテムであるソフトウェアの欠陥とは限りません。用意した環境やデータが悪いのかも知れませんし、テストケースの元となったドキュメントが誤っているのかも知れません。テストベースが間違っていることが発覚したら、テスト担当者は号泣します。その間違った範囲に基づいて設計したテストケースのうち、消化して「OK」となっていたとしても、やり直しです。人間、同じことを何度も繰り返すというのは、本当に苦痛ですよね。詳しくはシーシュポスの岩をご参照ください。本節では、テストの実行状況・結果の記録の重要性が、繰り返し強調されます。インシデントの記録の方法は、実装段階で準備されているはずですが、これは組織として標準をもっておくといいですよね。これは単に、調査や修正の元ネタになるだけでなく、品質分析のためのネタでもあり、組織として共有すべきノウハウも含まれているかも知れない、宝の山だ!(と、上司に教えられました)。先日紹介した『ずっと受けたかったソフトウェアエンジニアリングの授業』に、「オフショア開発におけるバグの認識の違い」としてこんなことが書かれています。見るwww.kzsuzuki.comところが中国などでは違います。バグは仕事上のミスで、それは罪とみなされます。即刻給料に反映され、最悪の場合には解雇されることもあります。このような会社の社員は罪と罰を強く意識せざるを得ない環境にいます。そのため、自分たちのバグは絶対認めたがらないのです。もったいないと思います。・・・どうも、「シラバスに書いてあること」と「すずきの思い」が混じってしまっており、万が一このサイトを参考にしている人がいたら、誤解を招くかも知れません。「事実と意見を区別せよ」とはよく言ったものですが、ここではなされていませんので、みなさん、シラバスを読んでください。その1この記事は、「モデルベースドテストについて学んでみよう」201...2014-10-20探索的テストと他のテストを比べてみる。7.1~7.6第7章はインシデント管理。過去のエントリはコチラ。2.5~2.7今日は、例題です。