ソフトウェアプロセス改善手法SaPIDでは、プロセス改善で目指すべきものとして「顧客・会社・現場三方よし」を提唱しています。これは次の改善を一緒に成立させるように志向するというものです。 顧客価値につながるプロダクトを提供して顧客満足を引き出す、顧客のための改善 チームがより効率的に・生産性高く活動でき、チームの労苦を減らす、現場のための改善 プロジェクトのコストが下がり、ビジネスとして利益が上がる、会社のための改善 この三方よしは、三者のトレードオフ（例えば顧客満足を得るためにチームが過労状態に陥るなど）を超越させて、プロセス改善の有効性、実現性を支えます。 ソフトウェアQAの基本方針として…

エンジニアリング活動で好きな言葉に三現主義があります。三現主義は「実際に現場で現物を観察し、現実を認識する」という問題認識についての考え方です。現場・現物・現実の三つの現から、三現主義と命名されています。 この三現主義はソフトウェアの品質管理/品質保証の活動でも全般的に通用する普遍的なグッドプラクティスです。 その一つとして、ソフトウェア品質リスクのマネジメントで重要な考え方になります。これは、次の2つの理由から、リスクの認識に三現主義が求められるためです。 リスクレベルと実際のリスクの乖離への対応のため 理由の一点目として、ソフトウェア開発における品質リスクは本質的に定量化困難であることが多…

品質改善サイクルの著名なものの一つに、SDCAサイクルがあります。 SDCAサイクルは、改善手段として標準化を活用するための改善サイクルです。PDCAサイクルの応用例の一つです。次の4つのフェーズを繰り返して改善します。 Standardize（標準化）。プロセス化、手順化で、良い方法を標準化する Do（実行）。標準化された手順に従って活動を進める Check（評価）。標準が適切に遂行されているか、標準が効果を発揮しているか評価する Act（改善）。評価結果に基づいて改善を実施する SDCAサイクルは、主にハードウェアの開発・製造で活用されます。ランダム故障を減らし、品質のバラツキを抑えるため…

自分はここ10年ほどテストエンジニア（SET含む）、QAエンジニアとして働いているのですが、そういった役割でも結構プログラミング機会があります。例えば次のようなものです： 統合テストやEnd to Endテストの自動テストの実装 組込み開発の治具の開発 中大規模なテスト自動化システムの開発 CI/CDデプロイメントパイプラインの実装（パイプライン定義だけでなく、周辺のビルドスクリプトや自動化処理の実装含む) QC/QA活動でのデータのモニタリング/分析 QC/QC活動に絡む開発協力（プロダクトの監視設計やユニットテスト実装など） これらは、簡単な雑用コードの実装レベルに閉じず、本格的な開発も含…

コードの読みやすさ、保守しやすさの指標の一つに、コグニティブ複雑度（認知的複雑度、Cognitive Complexity）があります。計測手段が充実してきていることもあり、今回はこのコグニティブ複雑度の概要と、計測方法についてまとめます。 コグニティブ複雑度とは コグニティブ複雑度とは、ソースコードの理解しにくさ・複雑さを示すメトリクスです。{Cognitive Complexity} a new way of measuring understandability ソースコードの理解しにくさ・複雑さを示すメトリクスとしてはサイクロマティック複雑度が著名です。コグニティブ複雑度は、このサイク…

「品質保証（QA）とは。定義の三大流派と定義揺れの弊害 - 千里霧中」で触れたとおり、QAの定義は日本国内では曖昧化しています。それに伴って、QAエンジニアの定義も曖昧化している状態です。曖昧化しているポイントは主に以下の二点です。 「品質保証（QA）」の定義が曖昧 チームとの関係性（開発チームに入るか、第三者検証に様に独立性を保つか等）が曖昧 こうしたQAエンジニアの定義のブレ・曖昧さは、完全内輪向けならば許容される場合があります。 ただ、外部から知見を取り込んだり、外部から人材を募集したりと、外部組織と接点を持つと支障が出ます。例えば「QAエンジニアを募集」と人材要件に書いても、読み手によ…

品質特性は要求定義やテスト分析、品質評価など、様々な場面で使われる考え方です。この品質特性についてですが、同じ対象に適用する場合でも「全体に適用する場合」と「全体を構成する個々の要素に適用する場合」で様変わりすることがある点、注意が必要です。 ISO/IEC/IEEE 29148 での要求が備えるべき特性 例えば、要求エンジニアリングの標準規格であるISO/IEC/IEEE 29148:2018では、要求の記述が備えるべき特性をリストアップしているのですが、そこでは個々の要求事項が備えるべき特性と、それら総体の要求の群・集合が備えるべき特性を明確に区別しています。 個々の要求事項が備えるべき特…

登壇 講演に苦手意識・下手さを感じているため、登壇は一貫して受け身でお声がけ頂いた場合のみ対応しているのですが、それでも今年は様々な機会を頂きました。 その中で印象的だったイベントが2つあります。1つは開発生産性カンファレンスで、申込者数が4桁を超えていてかなり緊張した記憶があります。もう1つは「井芹さんが語る！」のイベントです。自分はこれまでテストネタで講演してきましたが、現職がQAエンジニアということで、QA特化でテストの話題を極力避けたコンテンツに方向転換しました。いずれも大変好評なアンケート・フィードバックを頂き勇気を頂きました。機会を作っていただいたFindy様ありがとうございました…

先日、@IT開発変革セミナーと、「井芹さんが語る！」という二つのイベントで、高品質と高スピードを両立させるソフトウェアQAアプローチについて講演する機会をいただきました。 speakerdeck.com運営者、参加者の方々、後者にお声がけいただいたt_wadaさん、大変ありがとうございました。 なお後者のイベントは聴講者の方がconnpass、techplay合わせて500人近くと久しぶりに大きな規模になり、準備段階から緊張していました。無事に終わり、安心して年を越せそうです。井芹さんが語る！ 高品質×高スピードを両立させるためのQAアプローチ - connpass 高品質×高スピードを両立さ…

QA/QCの活動で実施する品質のモニタリングは、継続的に・繰り返し行われるため、なるべく自動化し評価の手間を少なくするのが理想です。そのためには、最初期にモニタリング設計を行い、モニタリングの仕組みを構築することが重要です。 例えばテスト実行のモニタリングならば、必要な情報（テスト実行数、テスト結果など）を自動で収集できるように、テストドキュメントのフォーマットや管理場所を最初期から整備しなければなりません。 こうしたものは、後から追加しようとしても、横断的なフォーマット変更や構成管理場所の変更が必要になり費用がかさみます。特にプロジェクトの規模が大きくなるほど、モニタリングの追加・変更コスト…

ここ最近話題になることが多いプロパティベーステストはHaskellのQuickCheckを源流としています。そこで今回はHaskellでの実装を通して、実例ベーステストとプロパティベーステストのコードを例示します。 テスト対象 今回はテスト対象として一般的なFizzBuzzを使います。FizzBuzzは15で割り切れるならFizzBuzz、それ以外で、F3で割り切れるならばFizz、5で割り切れるならBuzzを表示するというプログラム課題です。 テスト対象のコードを以下に示します。 fizzbuzz :: Int -> String fizzbuzz n | n `mod` 15 == 0 =…

先日、企業様にて「アジャイルを支えるテストアーキテクチャ設計」と題して、テストの抽象レベルの設計や、テストの戦略立てでアジャイルを支えるアプローチについて講演させていただきました。アジャイルを支えるテストアーキテクチャ設計/Test Architecting for Agile - Speaker Deck内容は以前講演させていただいた「ソフトウェア開発での高品質と高スピードを両立させるテストアプローチ」の中の1トピックにテーマを絞り、さらに依頼で指定いただいたアジャイルに方向性を特化して、深掘りしたものになります。 機会をいただいた永田さん、参加者の方々、大変ありがとうございました。

テスト容易性の確保にかかわる責務設計、リファクタリングのためのデザインパターンに、Humble Objectパターン（Humbleオブジェクトパターン、質素なオブジェクトパターン）があります。Humble Objectパターンは、ユニットテストのデザインパターン集であるxUnit Test Patternsで定義されたものです。近年は書籍「単体テストの考え方/使い方」でテスト容易性を確保する基礎的技術として紹介され、認知が広がっています。Humble Objectパターンは自動テスト、特にユニットテストをターゲットとします。大まかな概要として、以下を実施します。 自動テストで実行しにくいオブジ…

リファクタリングは、設計やコードを綺麗に保つという普遍的に求められる活動の一要素です。常識的な習慣として推進すべき活動です。 ただ、有効性の理解を得られないままリファクタリングを行って物議を醸す場面も存在します（例えばここのはてなブックマーク等で巻き起こった議論などです）。 実際、リファクタリングは、以降の保守作業をサポートしてこそ価値がでるものであり、考えなしにいつでも一律実施すればよいというものではありません。リファクタリングの対象やチームの状況によって、リファクタリングをすべきかどうか、線引きがされます。 このリファクタリングをすべきかどうかの基準ですが、一言でまとめると「妥当な保守性の…

一定以上の規模のプロジェクトでは、開発プロセス設計において、テックリードなど有識者による横断的なテクニカルレビューをどうするかが課題になります。 そこでは、次の課題への対応が求められます。 レビューのレバレッジ性の確保。少数のレビューアの影響力を全体に発揮させる。 レビューのピンポイント性の確保。多数の業務作業の中で、有識者の力が求められる作業に集中してレビューを設ける。 このレビューのレバレッジ性・ピンポイント性の確保のためには、開発プロセス設計において、レビューのレバレッジポイント（少ないリソースで大きな影響を発揮できるポイント）を設け、そのレバレッジポイントにレビュー工程を確保するアプロ…

先日、開発生産性 Conference 2024のSpecial Sessionにて、「高品質と高スピードを両立させるテストアプローチ」と題して講演をさせていただきました。https://speakerdeck.com/goyoki/test-approach-that-improves-quality-and-agility-together speakerdeck.com2000人弱の参加者で緊張する登壇でしたが、準備を通して最近の経験や学びを体系的に整理でき、良い機会になりました。 声をかけていただいた運営の方々、参加者の方々、大変ありがとうございました。

モデリングの対象が同一でも、何をどうモデリングするかには無数の選択肢があります。 そこであるべきモデルを方向づけするのが、次の目的と制約です。 目的：モデリングで達成を助けたいもの 制約：モデリングの自由度を制限するもの 目的について まず目的についてです。例えば「机のモデリングをしたい」という場合でも、目的によってモデリングの方向性が変わります。 例えばその目的が「机が入口を通り抜けられるか知りたい」のならば、モデリングの対象は「机の幅・高さ・奥行」になります。一方「机を提供部品で組み立てたい」という目的があるならば、モデリングの対象は「机の部品構成、組み立て手順、完成図」になります。 制約…

ソフトウェアプロダクトライン開発とは ソフトウェアプロダクトライン開発（SPLE：Software Product Line Engineering。ソフトウェア製品系列開発）は、複数の類似した製品群（プロダクトライン）の開発についての開発手法・テクニックです。プロダクトラインで共有する資産を効果的に運用して、プロダクトラインの価値を高めたり、開発生産性を高めたりすることを目指します。ここでいうプロダクトラインは次のようなものです。 仕向け地ごとといった複数のバリエーションのグループ 異なるグレード群のグループ SPLEは、複数の製品で共有する共通資産をソフトウェアプラットフォームとして開発し…

社外のコミュニティ活動として、2017年からテスト設計コンテストU-30クラスの創設とその審査員長を続けていたのですが、立候補あり今年度から大段さんに引き継ぐことになりました。良いタイミングなので、今回振り返りながら、自分の審査委員活動の総括をできればと考えています。 テスト設計コンテストとは テスト設計コンテスト（テスコン）は、文字通りテスト設計の良否を競うコンテストです。https://www.aster.or.jp/business/contest.htmlテスコンは、指定の仕様書に対してテスト設計を行い、それを審査基準に従って点数化して順位を競います。（1回だけ中止がありましたが）20…

リグレッションテストの方針の重要性 ソフトウェアに変更を加えた際に、意図せず変更とは関係のない所で故障が発生したり潜在的なバグが顕在化したりしたものは、リグレッション（和製英語でデグレードとも）と呼称されます。 リグレッションテストは、このリグレッションが発生していないか確認するテストです。このリグレッションテストは通常、変更前後でテスト成功状態が維持されることを確認して、意図しない変化がソフトウェアに発生していないか確認するアプローチをとります。このリグレッションテストをどう方針立てするかは、テストの方針にとって重要な課題です。というのも、ソフトウェア開発では仕様や設計の変更がありふれていま…

最近、Software Design 2月号にて、シフトレフトテストの解説記事を執筆する機会をいただきました。Software Design 2024年2月号シフトテストレフトは、シフトレフトの一種で、「テスト対象を動かして動的にテストするタイミングをなるべく早く設けよう」というアプローチです。対象を動かす動的なテストでは、単に「動的なふるまいを確認できる」というものに収まらない、多数の知見が得られます。例えば「企画書では魅力的だったけど、動かしてみると微妙」「数値上の開発進捗と比べて品質が全然作りこまれていない」「競合プロダクトとの競争が厳しいものになりそう」といった感覚的な知見がその一つで…

※品質保証のエンジニアである筆者が自省・戒めのために書いた記事になります 品質管理（Quality Control）、品質マネジメントは国内では製造業を中心に発展し、プロダクトの競争力向上に貢献してきました。 JTCと呼ばれる旧来からのメーカーでは、その実績・年功の蓄積に応じて、独立性を保った品質管理・品質保証部門が権威を獲得し、今でもソフトウェア開発に強い影響力を保持するようになっています。筆者は複数のメーカーを転職やコンサルで巡って来ましたが、例えば品質保証部門が承認しないとマイルストーンで開発がブロックされる、プロダクトがリリースできないといった権限を持つ体制が、今なお普遍的に見受けられ…

今年、書籍執筆の機会をいただいているのですが、執筆期間が短く、プライベート時間にかなりの間文字を書き続けています。（体が無理できなくなったのも合わさって）そこで気になったのが、自分の自宅のPC環境の使いづらさでした。 その流れで今年後半はPC環境の整備に凝り始めたのですが、今回はそこで購入して良かったものをまとめたいと思います。 モニタ： 32インチ 4Kゲーミングモニタ（MSI Optix MPG321UR-QD） Amazon.co.jp: MSI ゲーミングモニター 144Hz 32インチ量子ドット IPSパネル スリムベゼル 鮮やかな発色 4K UHD/1ms/HDR600対応/G-S…

「実践プロパティベーステスト」の発売をきっかけに、国内でプロパティベーステストの話題がホットになっています。 今回はこのプロパティベーステストの概要とテクニックについて、Pythonをサンプルに解説します。 プロパティベーステストとは プロパティベーステストは、「プロパティ」が成立するかを確認するテストです。ここでいうプロパティは「事前条件に対する事後条件・不変条件の関係を、実行可能にしたもの」です。 このプロパティ、プロパティベーステストは、よく実例ベーステスト（Exampleベーステスト、事例ベーステスト）と対比して解説されることが多いため、今回もそれに習います。 まず実例ベーステストは、…

組み合わせテストは、「組み合わせ爆発」という言葉がある通り、テストケースの規模が大きくなりがちです。それに付随して、開発のスピードやコスト、必要リソースに悪影響を及ぼすこともあります。 そのため、組み合わせテストの組み合わせ削減は、テストケースの削減、そしてそれに伴うリソースや期間の削減に貢献しやすい領域です。 今回は、その組み合わせテストの組み合わせを削減するアプローチについて解説します。 組み合わせテストの組み合わせを削減するアプローチ パラメータと値を削減する。組み合わせを実現不能にする パラメータ（因子）を減らしたり、パラメータが取りえる値（水準）を減らしたりすると、テストすべき組み合…

ユニットテストのコードカバレッジ（テストカバレッジ。ステートメントカバレッジやC0、C1など）は、不適切な運用が根強く見られます。多いのが、コードカバレッジの確保だけをテストの十分性目標にして、まずいテストを書いてしまうパターンです。 今回はこのコードカバレッジについて、現代的な開発を支えるための適切な運用について解説します。 コードカバレッジのみを直接のテストの十分性の目標にしてはいけない 結論から言うと、まずユニットテストは以下を目標として作成します。 ふるまいの仕様が実現されているか確認する プログラマが感じる品質リスク（いわゆる不吉な臭い等）が許容できる水準であることを確認する 法規制…

大規模な開発では、抽象レベルの高いテスト設計（いわゆるテストアーキテクチャ設計が代表例）を通して、大規模なテストを中小規模のテスト要素に分割するアプローチがとられます。 例えば次ようなものです： システムオブシステムズのレベルで、各企業組織など独立性のあるプロジェクトごとにどうテストを分担するか分担設計する プロジェクト全体のレベルで、システムテスト、各結合テスト、ユニットテスト等をどうするかテストレベル設計を行う 各テストレベルごとに、どのようなテストタイプやテストコンテナ（例えばセキュリティテスト、性能計測、周辺機器接続テストなど）を構成するかテスト設計する この抽象レベルの高いテスト設計…

最近の開発では、CI/CD、自動テスト、継続的テストが当たり前となっていますが、その影響で、それらのCI/CD方針、テスト方針と、Git等のバージョン管理のブランチ方針をどう連携させるかが、定番の課題になっていると感じています。 今回は、このブランチ方針、CI/CD方針、テスト方針を連携させて、開発の品質とスピードを向上させるアプローチについて解説します。結論から言うと、要点は以下の二つとなります。 バージョン管理のブランチ方針は、CI/CD方針、テスト・QA方針と不可分であり、連携を考えながら方針立てする必要がある ブランチ方針の工夫で、CI/CD、テスト・QAの開発インフラリソース消費を削…

近年のソフトウェア業界では、テスト関連活動を担うエンジニアを「QAエンジニア」と呼ぶようになっています。ただQA（品質保証）という言葉は、旧来から二つの定義が共存しているほか、業界内の通例で更に別の意味付けが行われた結果、定義が曖昧になり誤解を生みがちな状態となっています。 そこで今回は、日本語圏で、QA（品質保証）の言葉がどのように定義されているか、整理して解説します（結論からいうと三流派あります） 国際標準規格での定義：品質マネジメントシステムの実証 IEEEやISOといった国際的な標準規格、およびそれに準拠した知識体系や標準では、古くから体系立てて品質マネジメント、品質保証、品質管理の定…

先日、テスト設計コンテストU-30クラスに関連するイベントとして、テスト設計のチュートリアル講師の機会を頂きました。https://speakerdeck.com/goyoki/test-design-tutorial今回のチュートリアルでは、初学者向けに、勉強会やセミナーで解説されるテスト分析と、実際の現場のテスト分析のギャップを埋めることを意図して、講演を組み立てました。その背景ですが、テスト観点分析、テスト条件分析の解説では、テストレベル、テストタイプ、仕様を小さく切り取って、最初から小さいスコープで分析を進めるものが多い印象を受けます。その知識のみを、複雑で規模の大きな現場のテスト設計…