リグレッションテストの方針立て - 千里霧中
リグレッションテストの方針の重要性 ソフトウェアに変更を加えた際に、意図せず変更とは関係のない所で故障が発生したり潜在的なバグが顕在化したりしたものは、リグレッション（和製英語でデグレードとも）と呼称されます。 リグレッションテストは、このリグレッションが発生していないか確認するテストです。このリグレッションテストは通常、変更前後でテスト成功状態が維持されることを確認して、意図しない変化がソフトウェアに発生していないか確認するアプローチをとります。 このリグレッションテストをどう方針立てするかは、テストの方針にとって重要な課題です。 というのも、ソフトウェア開発では仕様や設計の変更がありふれていますし、デバッグによる変更がリリース間際まで続きます。そこでは一般的に変更の度にテストを全てやり直すほどの期間やリソースがないため、絞り込んだ限定的なテストケースでリグレッションテストを構成せざるを
品質保証（QA）とは。定義の三大流派と定義揺れの弊害 - 千里霧中
近年のソフトウェア業界では、テスト関連活動を担うエンジニアを「QAエンジニア」と呼ぶようになっています。ただQA（品質保証）という言葉は、旧来から二つの定義が共存しているほか、業界内の通例で更に別の意味付けが行われた結果、定義が曖昧になり誤解を生みがちな状態となっています。 そこで今回は、日本語圏で、QA（品質保証）の言葉がどのように定義されているか、整理して解説します（結論からいうと三流派あります） 国際標準規格での定義：品質マネジメントシステムの実証 IEEEやISOといった国際的な標準規格、およびそれに準拠した知識体系や標準では、古くから体系立てて品質マネジメント、品質保証、品質管理の定義を行っています。 有力な文献として、品質マネジメントの標準規格である、ISO 9000：2015の定義を紹介します。 まずISO 9000では、品質保証の前提として品質マネジメントという用語を使って
モダンなテストレベル設計（ユニットテスト～システムテスト等をどう設計するか）の原則 - 千里霧中
プロジェクト全体のテストを組み立てる際に重要な課題になるのが、テストレベル設計です。テストレベル設計は、ユニットテスト、結合テスト、システムテストといったテストレベルを、どのような責務・段取りで行うか分析・設計する活動です。 このテストレベル設計ですが、ここ10年程度の間に望ましいアプローチが変わってきたと感じています。今回はこの変化と、変化後のモダンなテストレベル設計の原則について、考えていることを書き出したいと思います。 旧来のテストレベル設計のアプローチ 旧来、このテストレベル設計では、Vモデルをベースしたアプローチや、自工程完結・品質積み上げをベースとしたアプローチがよく見られました。 このうち一つ目のVモデルをベースとしたアプローチは、要求定義から設計までの上流工程への対応を観点に、テストレベルを設計するものです。 （Vモデルが必須と明言しているわけではなく、極端な例ですが）例え
QAアーキテクチャの事前検証 - 千里霧中
「QAアーキテクチャが本当に妥当なのか」は、大抵の場合、サービスやプロダクトリリース後の事後評価で判明します。例えば、以下のような指標の評価が、本当にQAアーキテクチャが妥当かの確認に有効になります。 ビジネスの成否。例えば、ビジネスのKPIの達成度、SLAの遵守度など 市場への欠陥の流出の程度 市場でのサービス・プロダクトの品質レベル。例えば、MTTF、実際のパフォーマンス計測結果、ユーザアンケート結果 QA活動の生産性の結果評価。例えば、実際にかかったコストやリソースが妥当だったかの評価 ただリリース後の事後評価では、QAアーキテクチャの問題を見つけても手遅れの場合が多いです。適切なQAアーキテクチャの実現のためには、開発途中の事前の検証で問題を見つけて問題是正する必要があります。 今回はそのQAアーキテクチャの事前検証手段について扱います。 QAアーキテクチャの検証手段の導出 QAア
TDDはゆるく実践しても大丈夫 - 千里霧中
最近、TDDのテストコードは捨てても良いかみたいな議論を見ました。 これに対する自分個人の経験上の意見ですが、TDDは雑多にテストコードを使い捨てても効果を出せると思います。 もちろん、TDDで保守性が高く価値あるテストを書いて、捨てずにCIや中長期的なリファクタリングで再利用していくと、TDDの効果を増幅できます。ただ、それをするにはスキルや事前の工夫、労力が必要ですし、できる場面に限りがあります。 そういったことをやらず、もっとゆるい姿勢で取り組んでも、費用対効果をプラスにできる手法がTDDだと考えています。 今回は、そのTDDでゆるくしてもよいポイントを、実経験からまとめたいと思います。 TDDのテストは使い捨てでいい TDDのテストはプログラマのこまごまな課題に応じて累積的に作られるため、保守コストがかかるテスト・保守する価値の低いテストが生まれがちです。そのためテストの使い捨ての
テスト自動化の目的 - 千里霧中
最近あるMLでテスト自動化の目的について考える機会があったのですが、今回は整理としてそこで言及したことをまとめたいと思います。 色々な目的 よく言及されていますが、テスト自動化の目的は単に「人がやっていることをツールにやらせて楽をする」といったものに限りません。思いつくものでも、例えば以下があります。 繰り返し作業を効率化する 何度も繰り返す作業を自動化して、繰り返しによる作業重複分を効率化します。 継続的なテストの実現 テストの繰り返し実行を容易にして、高頻度の回帰テストを実現します。例えばCIへのテストの組み込み等を実現します。 素早いフィードバックの実現 継続的なテストの実現により、コミットといった小さな追加・変更のステップごとのテスト実行を実現します。これによりプロダクトやテストの追加・変更を小さな単位でテストをしつつ進められるようにします。 バグの早期検出の実現 頻繁な回帰テスト
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
