品質保証（QA）とは。定義の三大流派と定義揺れの弊害 - 千里霧中
近年のソフトウェア業界では、テスト関連活動を担うエンジニアを「QAエンジニア」と呼ぶようになっています。ただQA（品質保証）という言葉は、旧来から二つの定義が共存しているほか、業界内の通例で更に別の意味付けが行われた結果、定義が曖昧になり誤解を生みがちな状態となっています。 そこで今回は、日本語圏で、QA（品質保証）の言葉がどのように定義されているか、整理して解説します（結論からいうと三流派あります） 国際標準規格での定義：品質マネジメントシステムの実証 IEEEやISOといった国際的な標準規格、およびそれに準拠した知識体系や標準では、古くから体系立てて品質マネジメント、品質保証、品質管理の定義を行っています。 有力な文献として、品質マネジメントの標準規格である、ISO 9000：2015の定義を紹介します。 まずISO 9000では、品質保証の前提として品質マネジメントという用語を使って
アジャイルテストでの計画・管理のツール：Test MatrixとTest Mindmap - 千里霧中
「ソフトウェアテストの小ネタ Advent Calendar 2020」の記事です。 Agile Testing CondensedやMore Agile Testingでは、リリーステスト（システム全体を対象とするテストレベル）の計画のやり方として、「リリース全体を俯瞰する視点で作成する。計画の作成・運用ではテストマインドマップ（Test Mindmap）やテストマトリクス（Test Matrix）を活用できる」のような解説がされています。そして下図でその流れを紹介しています。 執筆時点で日本語の解説がなく気になったので、今回はここで言及されている、計画と管理のツールであるテストマインドマップとテストマトリクスの内容についてメモしたいと思います。 共通する特徴 テストマインドマップ、テストマトリクスいずれも、マネジメントとチームのコラボレーションを支えるためのモデルとして活用します。具体
Classification Tree法（クラシフィケーションツリー法）について - 千里霧中
※Classification Tree法のまとまった解説として以下資料を作成しました： クラシフィケーションツリー法入門/Introduction to Classification Tree Method - Speaker Deck 最新は上記参照ください。以降はバックアップです。 ●●●● ソフトウェアテストの分野では、日本語圏と英語圏で話題や志向が違うことが結構ある。 その違いの代表例の一つに、テスト技法であるClassification Tree法がある。この技法は、海外ではISO/IEC 29119が代表的なテスト技法として挙げているなどそれなりの知名度を持っているそうだが、日本国内では知名度がかなり低い。 今回はそのClassification Tree法について、簡単に紹介したいと思う。 Classification Tree法の概要 Classification Tre
問題形成チャートについて - 千里霧中
少し前に佐藤允一さんの問題構造の書籍を読んでいたが、そこで説明される問題形成チャートが書籍で解説される問題構造をうまくまとめていて良かったので、今回紹介したい。なおこのチャートは結構昔に提唱されたものだけれど、REBOKに似た図が使われている等、今でもある程度普及しているようだ。 問題形成チャート 問題形成チャートは以下のような形を取る。主に問題の構造を明示化するのに使われる。 なお注意として、これは問題の因果関係を図化するのではなく、問題を産んだ一連の活動を図化する。例えば「テスト漏れによるバグ流出」という問題について図を描くならば、Whyツリーのようなバグ流出の要因の連なりを描くわけではない。その時のテストのやり方を図に展開して、結果として目標と現状の間にバグ流出という問題が発生している、という図を記述する。 各部の説明だけれど、この図の定義においては、問題は「目標と現状のギャップ」と
データの品質モデル（ISO/IEC 25012）について - 千里霧中
ソフトウェア品質モデルの国際的な標準規格としては、長らくISO/IEC 9126が一般的でした。ただ規格が置換されたこともあり、最近はISO/IEC 25000シリーズ（通称SQuaRE）が使われるようになっています。 ISO/IEC 25000シリーズでは、ISO/IEC 9126と比べていろいろ変更や拡張が行われています。特になかでも目を引くのがISO/IEC 25012でデータの品質モデルを新たに追加している点です。データの品質モデルはこれまでなかったものではないものの、システムの品質モデルと並ぶ位置づけで定義しているのが印象強いです。 このデータの品質モデルについてですが、上位のレベルのテスト設計・実装で活用できそうなものとなっています。 というのも、データ駆動テストやキーワード駆動テストを行うと、データ（キーワード含む）と、それ以外のスクリプトやフレームワーク部分で利用者・利用状
探索的テストの必要性 - 千里霧中
探索的テストがバグの大半を検出する 少し前にJaSST'13Tokyoに参加したのだけれど、そこでの基調講演で気になったのが、「システムテスト工程では、バグの半分は探索的テストのアプローチで検出される」という言及。その場で聞いたときは、手順のドキュメント管理が十分でない手法にバグ検出の大半を頼る体制に不安を覚えた。のだけれど、振り返ってよく考えてみると、結構自分の経験ともそんなに違わないなと感じた。 例えば自分がシステムテストでバグを見つける場合は、以下のようなパターンが少なくない。 手順に従ってテストしている最中に、期待結果に違反していないけれど、気になる症状や情報を見つける（例えばちょっと遅く感じたとか、手順が物足りないだとか） 手順の合間や空き時間にその気になる所を追っていくうちに、バグ遭遇 そのため、手順書非依存で見つけるバグが全体の半分を占めるといわれても、経験的にあまり違和感は
PFDによる開発プロセスのモデリング - 千里霧中
組み込みで認知が広がっている開発手法にXDDPというものがあります。このXDDPは色々示唆に富む手法で、実際XDDPを構成するプラクティスを活用してきました。その中で早期から気軽に使っているプラクティスにPFD(Process Flow Diagram)というものがあります。 PFDはDFDをベースに作られたもので、主に開発プロセスのモデリングに用います。 記法が単純＆明快なのと、後述しますがアクティビティ図やフローチャート等によるモデリングと比べて異なるメリットを持っているので、自分も色々な場面で活用しています。今回はそのPFDの概要を紹介したいと思います。 なおPFD自体は提唱者による詳細な資料が既にウェブに公開されているので、詳細はそちらを読んで頂ければと思います。 http://homepage3.nifty.com/koha_hp/process/PFDform3.pdf PFD
TDDカンファレンスに参加 - 千里霧中
先日TDDカンファレンスに参加。グループディスカッションの合間に急遽ライトニングトークの資料作成・発表をやらせて頂きました。本来LTトーカーとして話す予定でしたが、仕事の遅れで大遅刻してしまい、グループ内のみでの発表となってしまいました・・。主催者の @yujiorama さん大変申し訳ありませんでした。 恐怖のFragile Tests問題 View more presentations from H Iseri なお本当は別の話をしたかったのですが、とても5分で収まらなくなったのと、トラブルで資料作成時間がほとんどとれなくなっていたため、見送る形になってしまいました（上記発表資料は単純に過去の講演資料を急場で継ぎ接ぎしててなんとか仕立てたものです）。内容は固まっていますし、前々から一度言いたかったことなので、それは清書して後ほど公開したいと思います。
xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
黒背景のプレゼン資料では色盲の方に配慮する - 千里霧中
開発系の勉強会では黒背景のプレゼン資料を作成する方が少なくありません。自分も、暗い部屋で見やすい・発色をより鮮やかに感じるといった理由で、2年ぐらい前から黒背景でプレゼン資料を作ることが増えてきました。またプレゼンの印象を良くするアドバイスとして白黒反転が推奨されているのもちらほら見かけます（例えばhttp://blogs.itmedia.co.jp/kenjiro/2009/03/post-09e7.html）。 ただ過去の講演の事前レビューで @t-wada さんからアドバイスされたことなのですが、黒背景では、一定数いる色盲の方が見にくい配色が一部あるそうです。 例えば一番多い例として赤緑色盲がそうです。赤緑色盲は日本人男性の5%、白人男性の8%の割合で存在しており、程度にばらつきがあるものの以下のような特性を持っています。 赤成分・緑成分の判別がしにくい 赤成分や緑成分が暗く見える
テスト自動化の目的 - 千里霧中
最近あるMLでテスト自動化の目的について考える機会があったのですが、今回は整理としてそこで言及したことをまとめたいと思います。 色々な目的 よく言及されていますが、テスト自動化の目的は単に「人がやっていることをツールにやらせて楽をする」といったものに限りません。思いつくものでも、例えば以下があります。 繰り返し作業を効率化する 何度も繰り返す作業を自動化して、繰り返しによる作業重複分を効率化します。 継続的なテストの実現 テストの繰り返し実行を容易にして、高頻度の回帰テストを実現します。例えばCIへのテストの組み込み等を実現します。 素早いフィードバックの実現 継続的なテストの実現により、コミットといった小さな追加・変更のステップごとのテスト実行を実現します。これによりプロダクトやテストの追加・変更を小さな単位でテストをしつつ進められるようにします。 バグの早期検出の実現 頻繁な回帰テスト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
簡単な発声改善 - 千里霧中