ペネトレーションテストとは？ ペネトレーションテスト （侵入テスト）とは、情報システムのセキュリティ対策を評価するために行われるテストの一つです。 実際に攻撃者となって脆弱性を利用しシステムに侵入することで、潜在的なリスクを具体的に把握 します。これによりセキュリティレベルの客観的な評価や改善につながります。 ペネトレーションテストの目的 ペネトレーションテストの主な目的は、セキュリティ対策の妥当性や実際の攻撃を模擬することで、理論上では考えにくいセキュリティリスクを特定します。 主な実施目的は下記の通りです。 リアルな攻撃シナリオでの評価 システムの評価を実際の攻撃シナリオに基づいて行うことが、ペネトレーションテストの一つの大きな目的です。実際の攻撃者がどのようにシステムを突破しようとするのか、その視点からセキュリティの有効性を検証します。これにより、実際のセキュリティ事情を反映した具体的な改善策を立案できます。 複数の脆弱性を組み合わせた攻撃の評価 一つの脆弱性だけでなく、複数の点を組み合わせて攻撃される可能性もあります。ペネトレーションテストでは、個々の脆弱性を単体で評価するだけでなく、それらを一組にして攻撃された場合のリスク評価も行います。 システム管理者の反応評価 システムに不正侵入しようとする活動を検知して、システム管理者が該当する活動に適切に対応できるかどうかを評価するためにも、ペネトレーションテストは必要です。これにより、組織全体のインシデント対応能力を向上させることができます。 法的・規制上の要求への対応 特定の業界や地域では、サイバーセキュリティ法やグローバルな規制に従うために、ペネトレーションテストが求められる場合があります。それらの要求に準拠するためにも、ペネトレーションテストの実施は不可欠です。 以上のように、ペネトレーションテストの目的は広範で包括的であり、その中核には、システムと組織全体のセキュリティポスチャを強化するという役割があります。 ペネトレーションテストの必要性 情報システムの脆弱性は、システムの設計・開発・運用の各ステージで生まれる可能性があります。この脆弱性が悪意ある第三者に利用されると、重要な情報が盗まれたり、システムがダウンしたりすることにつながります。ペネトレーションテストにより、これらのリスクを把握することができます。 いかなるセキュリティシステムでも、理論的なテストやモデリングだけでは十分な評価はできません。 ペネトレーションテストでは、実際の攻撃シナリオに沿った試験を行うことで、セキュリティの懸念点が具体的に可視化され、セキュリティ対策の優先順位が明確になります 。 また、システム管理者やデベロッパーが予測しきれない視点からの攻撃も含めて、システムへの攻撃耐性を評価できます。たとえば、設計段階で想定していなかった使われ方をするユーザーや、システム全体としては見えにくい特定部分への攻撃など、様々な角度からの評価が可能になります。 一方で、企業のITスタッフやエンドユーザーが、どのようにしてシステムが攻撃される可能性があるのかを理解する機会ともなります。これにより、意識向上を目指した取り組みとして、教育やトレーニングの一部として取り入れることができます。 多くの場合、特定の規模や業種の企業は、定期的なセキュリティ評価を行うことが法律により義務付けられています。また、ペネトレーションテストは顧客の個人情報やビジネスの秘密を保護するための信用度の一部としても見なされます。 以上のように、ペネトレーションテストは攻撃をされた場合のリスク、攻撃者の視点の理解、スタッフの意識向上、法令遵守と信用維持を目指して行うのが理想的です。 脆弱性診断との違い 脆弱性診断は、システムやアプリケーションが持っている可能性のある脆弱性を発見するための評価です。主にエンジニアによる手動のテストや自動化されたツールを使用した脆弱性をスキャンによって、脆弱性がシステムに存在するかどうかを調査します。 一方、ペネトレーションテストは、見つけた脆弱性を実際に利用してみることで、その影響を評価します。つまり、実際に攻撃を模擬してシステムに侵入を試み、どの程度のダメージを与え得るかを評価します。 そのため、脆弱性診断とペネトレーションテストは、目的も手法も異なります。前者はシステムやアプリケーションの脆弱性を発見することに重きを置く一方で、後者はそれらの脆弱性が実際に悪用された場合の影響を評価します。 以上のように、脆弱性診断とペネトレーションテストは、セキュリティ評価の異なる側面を補完するもので、どちらも有効なセキュリティ対策の一部として扱われます。これらを組み合わせることで、システムの脆弱性を発見し、それが実際に攻撃者に利用された場合のリスクを評価することが可能になります。 ペネトレーションテストの進め方 一般的なペネトレーションテストの進め方は下記の通りです。 1. プロジェクトの範囲定義（Scoping） まず初めに、テストの目的、スコープ、時間割、テスト対象、そしてどのような方法を用いて攻撃を模倣するかなどを定義します。ここで取り決められる内容は、組織のセキュリティポリシーや要件、そして予算によって異なる場合があります。 目的 何を達成するためにテストするかを明確にします。 スコープ テストの対象となるシステム、ネットワーク、またはアプリケーションを定義します。 時間割 テストの種類やスコープに応じて、テストの期間を設定します。 テスト対象 検証したい特定の脆弱性や関心項目を明示します。 攻撃方法 使用するツールや手法、そしてどの程度まで侵入を試みるかなどを定義します。 2. 情報収集（Reconnaissance） 次に、テストの対象について情報を収集します。これには公開情報（例えば、WHOISデータやDNSレコード）や非公開情報（システム設定やネットワーク構造等）の両方が含まれます。 3. 脆弱性探索（Vulnerability Assessment） 収集した情報を基に、システムやアプリケーションの脆弱性を探索します。これには自動化ツールや手動テクニックの両方を使用します。 4. 侵入試験（Exploitation） 次に、発見した脆弱性を利用して実際にシステムへの侵入を試みます。これがペネトレーションテストの主要な部分であり、システムがどの程度まで攻撃耐性があるのかを評価します。 5. 脆弱性利用（Post-Exploitation） 侵入成功後は、どの程度の被害が想定されるかを評価します。例えば、機密情報へのアクセスや、追加的なシステム控えへの侵入などが考えられます。 6. 報告（Reporting） 最後に、テストの結果を詳細に報告します。これには、見つかった脆弱性、それらがどの程度重要か、そしてそれらを修正するための推奨料が含まれます。 ペネトレーションテストサービスの活用と選定ポイント ペネトレーションテストは専門的な知識と技術を必要とし、しかも定期的に行うべきであるため、手間と時間がかかります。そのため、専門のサービスを活用することが推奨されています。 ペネトレーションテストサービスを選定する際のポイントとしては、まず、サービス提供者が持つ専門的な知識と経験を確認してください。さらに、提供されるレポートの質や、テスト後のサポートも重要な要素です。テスト結果を基にした改善策の指導や再テストなどを含む継続的なサポートがあれば、セキュリティ対策の品質を高められます。 ペネトレーションテストサービスの活用 ペネトレーションテストサービスは有効なセキュリティ対策の一つであり、専門的な知識と技術が必要なため、企業にとっては外部のプロフェッショナルサービスに委託することが一般的です。以下にその主な理由を示します。 専門的なスキル ペネトレーションテスターは、最新の脅威と攻撃技術を理解し、それらに対抗するための専門的な技術と知識を持っています。 客観性 外部のサービス提供者は、内部のエンジニアや開発者が見落とす可能性のある問題を特定できます。 時間とコストの節約 サービスを利用することで、企業は自身のリソースを他の重要なタスクに集中することができます。 ペネトレーションテストサービスの選定ポイント ペネトレーションテストサービスを選定する際には、次の要素に注意を払うと良いです。 能力と経験 提供者はどの程度テストの経験があり、どのような方法でテストを実施するか？ 報告 テストの結果はどのように報告され、それは明確で理解しやすいか？ どのような改善策が提案されるか？ サービス後のサポート テスト終了後にもサポートを提供してくれるか？ 具体的には、レポートの解説や必要に応じてフォローアップのサポートがあるか？ コスト サービスのコストは理解しやすく、それが予算内に収まるか？ ビジネスの成長やニーズの変化に応じてスケーリングするオプションがあるか？ 以上の要素を踏まえて、ペネトレーションテストサービスを選定すると良いでしょう。また、選定したサービスが企業のセキュリティ目標と合致していることを確認します。 参考： 脅威/シナリオベース・ペネトレーションテスト（株式会社AGEST） まとめ ペネトレーションテストは、情報システムのセキュリティ対策を検証するための重要なテストです。脆弱性診断がシステムの弱点を示すのに対し、ペネトレーションテストは実際の攻撃の視点から、現実の脅威に対する耐性を試すものです。このようなテストを定期的に行うことで、システムのセキュリティレベルを維持し、改善することができます。それが手間や時間がかかる作業であっても、ペネトレーションテストサービスを活用することで、一歩進んだセキュリティ対策を行うことが可能です。 The post ペネトレーションテストとは？脆弱性診断との違いや手法について first appeared on Sqripts .

はじめに 前回 は、BDDとATDDとSbEの違いについて説明しました。 今回は、BDDで勘違いされやすい部分について説明していきます。 BDDはツールの1つではない 「BDDとは何か？」と聞くと、「振る舞いを用いてテストを自動化するもの」「Given/When/Thenを使って書かれた自動テストのコード」と答えられることが多いです。 しかし、これは誤解です。 Seb Roseは自身の書籍『 The BDD Books – Discovery （邦訳： The BDD Books – Discovery Japanese Edition ）』の中で、以下のように述べています。 私はビジネスチームが参加しない形の「BDD」を実施しているチームをたくさん見てきました。（中略）個人としては基本的にはそれらは BDD にまったく従っていないと考えています。彼らはせいぜい、（中略）高価なテスト自動化プラットフォームとして使用しているだけです。 結果として得られるのは、たいていは遅くてメンテナンスが難しく、組織にごく限られた価値しかもたらさない自動テストスイートです。 BDD は協調に関するものです。 BDDツールを使用したり、Given/When/Thenを使用してテストを自動化しても、開発アプローチは少しも BDD にはなりません。 The BDD Books – Discovery BDDは会話を重視します。特に、ビジネス関係者（非開発チーム）との会話を重視し、共有言語(Shared Languege)の構築を大切にしています。そのため、同書籍では「business」という単語が非常に多く出てきます。 プロセスに組み込まれたBDD 書籍『 The BDD Books – Discovery （邦訳： The BDD Books – Discovery Japanese Edition ）』の中では、プロセスとしてのBDDについても説明しています。今回はその一部を軽く紹介します。 BDDのプラクティスの概要 この書籍では、BDDのプラクティスを以下の3つのフェーズに分けています。 BDDでよく勘違いされるのは、この3つのうち「自動化(Automation)」のみに注目してしまうことです。 そうではなく、 協調作業が行われる「発見(Discovery)」が最も大切です。 同書籍では、この順序でプラクティスを採用することが大事であり、「発見(Discovery)」のプラクティスを採用するだけでも大きな効果を得られると語っています。 逆に、「自動化(Automation)」のみを採用してもBDDで期待しているメリットを得られません。 BDDを用いたプロセス 上ではBDDのプラクティスの概要を示しましたが、実際にBDDを用いたプロセスはどのようになるのでしょうか。その中身について描いた図は以下の通りです。 先ほど紹介したBDDのプラクティスと対応づけると以下のようになります。 ・発見(Discovery)…#2 要件ワークショップ ・定式化(Formulation)…#3 定式化 ・自動化(Automation)…#5 自動化 知らないことを分かっていない分野(unknown unknowns)への挑戦 2002年にラムズフェルド国防長官（当時）が会見時に発した言葉 を元にした「ラムズフェルド行列(Rumsfeld matrix)」というものがあります。 BDD、特に「発見(Discovery)」のフェーズでは、ラムズフェルド行列の右下の部分「Unknown unknowns（知らないことを分かっていない）」状態のものを見つけ出し、右上の部分「Known unknowns（知らないことを分かっている）」状態にシフトさせる活動を目指します。 次回予告 今回はBDDに対して「振る舞いを用いてテストを自動化するもの」「Given/When/Thenを使って書かれた自動テストのコード」という考えが誤解であると言うこと、BDDのプラクティスを3つに分けて考えられていることを紹介しました。 次回以降は、それぞれのプラクティスで行う内容を具体例を用いつつ説明していきます。 連載一覧 TDDとBDD/ATDD(1)　TDDはテスト手法ではない TDDとBDD/ATDD(2)　2種類のBDD TDDとBDD/ATDD(3)　BDDとATDDとSbE The post TDDとBDD/ATDD(4)　ツールとしてのBDDとプロセスに組み込まれたBDD first appeared on Sqripts .

こんにちは。まーくー＆くまねこです。 ゆるっとシリーズ第3弾です。 今回はくまねこからまーくーへ、探索的テストでより良い結果を出していくためのあれこれを会話形式でお話しさせていただきます。 最後まで楽しんで読んでいただければ幸いです！ 第1回 ゆるっと♪ファームウェアテストよもやま話 第2回 ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験 自己紹介 まーくー QA業界経験2x年のベテラン（おじさん）エンジニア。 JSTQB ALTM試験のことを考えるふりをしながら歩いていたところ、くまねこに声をかけられる。 くまねこ QA業界経験1x年のエンジニア。 前回の記事 を投稿後、JSTQB FLに無事合格。 弱い陽ざしの窓辺から外を眺めていたところ、通りかかったまーくーに話しかける。 イラストby くまねこ 今回はいつもと逆の展開…!? それでは、二人のやりとりをお楽しみください。 探索的テストについて、改めて考えてみる あっ、まーくーさん、お疲れ様です。JSTQB ALTMの勉強中ですね。(ニヤニヤ) そうね・・・そろそろ具体的に試験に向けて勉強しなくちゃだから！（話を合わせておこう♪）。で、どうしたんだい？（ニヤニヤしてる…何かあるな？） 前の記事を投稿した 後、探索的テストのことをあれこれ考えていまして…。まーくーさん、ちょっと意見を聞かせてもらえませんか？ もちろん良いよ！早速本題に入っていきたいところだけど、私もくまねこさんも探索的テストは経験してるけど、簡単に認識を合わせておこう。 探索的テストとは？ 探索的テストは、形式的ではない（事前定義されていない）テストであり、テスト実行時に動的に設計、実行、ログ記録、および評価をする。テスト結果を使用してコンポーネントまたはシステムについての理解を深め、さらにテストを行わなければならない領域のテストケースを作成する。 テスト技術者資格制度 Foundation Levelシラバス Version 2018V3.1.J03 要するに経験ベースのテスト技法で、テスト対象を動作させながらテスト設計/実行/結果の確認まで行うものだったね。詳細は以下の記事に記載があるから、お互いこちらを理解している前提で話を進めていこう！！ 探索的テストとは？スクリプトテストなどの他のテストとの違いやメリット・デメリットについて解説 はい！ 探索的テストの取り組み例の紹介 じゃあ、どんな感じで進めようか？ そうですね。今まで第三者検証として僕が行った探索的テストの進め方・考え方をお伝えして、まーくーさんが気がついた点をコメントする形が良いです。 OK。探索的テストのプロジェクト開始から流れに沿って話していこう。 プロジェクト開始からですね。まず実際の製品を動作させながら、製品全体の理解・お客様と探索的テストのゴールを認識合わせをするための活動を行います。プロジェクトによって仕様書などのドキュメント有無・量が異なるため、お客様の製品紹介ページやマニュアルなども参考にして、機能や画面単位で分類していきます。この分類は、お客様とテスト内容を共有する際や、テストチームにとってもテスト対象の全体像を俯瞰するのに役立ちます。 ふむふむ。まずはテスト対象を俯瞰できるようにするってことね。 洗い出した機能や画面に対して、プロジェクトの状況・目的と、前述の作業結果(製品を動作させた感触/分類結果など)から、実施優先度をつけていきます。優先度については、テストを行う観点数や工数で重み付けをしていきます。ここでお客様のご要望も反映して、観点のカスタマイズや優先度の調整を行います。 テストチャーターを使った探索的テストをする場合には、テストチャーターも作成します。探索的テストはスクリプトテストのように手順などを詳細に記載したドキュメントは残さないことが多いですが、チャーターを作成すると、お客様にもテスト担当者にもテスト範囲の全体像・テストの実施状況を見える化できて便利です！ テストチャーターとは？ テストチャーターはテストの目的や観点を記載します。作成したテストチャーターをテスト担当者間で共有して、テストを実施することで経験のバラツキを軽減することができます。 探索的テストとは？スクリプトテストなどの他のテストとの違いやメリット・デメリットについて解説 プロジェクトや探索的テストの期間によって明確なフェーズとして表現しないこともありますが、本記事では「テスト計画（準備）」という表現で進めます。 ここまでが事前準備だね。特に気を付けていたことってあるかい？ プロジェクトの目的にもよりますが、最初からテスト範囲を絞り込み過ぎないこと、ですね。まずは全体的に触ってみることで、予測と実際の動作があっているかの感触を得る期間を作ります。その結果から、不具合が潜んでいそうな機能を絞り込んでいくようにする事で、いきなりある一部分だけ深く掘り下げてしまい、他の不具合が潜んでいる部分に時間をあてられなくなるということが無くなると思います。 全体の感触を得たのち機能を絞り込み、効率的に探索できるよう計画することで、より良い成果を出すことに繋げられると思っています。 技法としてセッションベースドテストを取り入れて、機能や画面単位で時間を区切ってテストを行うようにして、全体的なテストと掘り下げたテスト、状況によってどちらにも時間が割けるように心がけています。また、”時間”という単位であれば、お客様も作業ボリューム感を実感しやすいと思います。 なるほど。不具合が出そうなところをテストできないってのは探索的テストではいちばん避けたいことだよね。時間で作業ボリューム感を共有するってのも分かりやすいと思うよ。 あと、すぐに探索的テストに入れる環境が整っているのか？対象システムにテスト可能なデータがあるのか？などの確認もこのフェーズに含まれるね！ じゃ次はテスト開始！テスト中はどんなことを心がけているのかな？ 実際にテストを行ってみると、不具合の検出状況やテストのための工数が想定と異なる場合があります。そのため、計画通り全体的な確認が終了したところで中間報告の場を設けて、後半の進め方を検討していきます。例としては以下のようなケースですね。 ・ これまでに検出した不具合の発生状況から、該当機能のテストをより掘り下げていくか ・ 類似の機能/画面で問題が起きないか、対象範囲を広げてテストを行うか 探索的テスト期間中でも、テスト内容を柔軟に調整して、テストの効果を最大化できるようにしています。 適宜、テストの状況をお客様と共有しながら進めているんだね。掘り下げるか？広げるか？それが問題だ！(笑)探索的テスターの腕の見せ所だね！ 他にもテスト実施のときに気を付けていることっていったら何かあるかい？ 対象製品の目的やユーザーの利用シーンを想像しながらテストを行うこと、ですね。 「ユーザーはこの機能を使ってこういうこともやりたいのではないか」と考えたり、「どういう状態になるとユーザーが困ってしまうか」など、エラーを推測しながらテスト実施しています。 ふむふむ、ユーザー目線でのエラー確認は特に大事だよねぇ。探索的テストはイマジネーションが命！で、テスト報告はどのようにしているのかしら？ チャーターから概算実施ケース数やテスト工数を集計したり、検出した不具合のまとめ（件数や重大度の高かった不具合）をご報告する形です。これらのテスト結果を元に、プロジェクトの目的に対して探索的テストの成果をお話ししていきます。また、お客様の課題に対する情報提供や、今後の品質向上に向けたアイデアをご報告します。 ありがとう。探索的テストの一連の流れはこんな感じかな？ そうですね。まとめるとこんな感じです。 きれいにまとめたねぇ！何を気にして作業を進めたのかが分かりやすい！！！ Yeah! \ / まとめ -より良い結果のために必要な事とは？- この作業の中で、まーくーさんだったら、どのようなところを工夫しますか？ この中で言ったら、テスト計画(準備)の所だね。お客様のプロジェクト内で探索的テストの立ち位置(取り扱い)や、テスト結果をどんな情報として求めているかをしっかりヒアリングするかな。 つまりお客様が「探索的テスト」に「何を」求めているか？目的とゴールをしっかり把握するところが大事 だと考えているよ。 ふむふむ。 とにかく不具合を見つけて欲しいのか、不具合が無いことをスクリプトテストの補完的に確認するのか、時間的な制約で準備の期間が取れないから、探索的テストでもある程度網羅的に見て欲しいとか・・・その目的とゴールをはっきりさせることで、その後の動きも変わってくるよね。 ふむふむふむふむ。 また言葉の定義もお客様と認識合わせしておくことも必要だよね。例えば、”ケース数”という言葉を使ってやり取りをする場合、同じ”1ケース”と言ってもスクリプトテストとは粒度が異なったりするし。もっともこれは、機能テストとユースケーステストとかでも同じだけど ふむふむふむふむふむふむ。 （あ、ふざけ始めた・・・飽きてきたのか？？？気を取り直して）こういった探索的テストの定義をお客様としっかり認識を合わせた上で、必要であればスクリプトテストとの比較や一般的な指標(テスト密度/バグ密度etc）との比較、お客様内の指標があれば、その指標との比較なども使いながら、お互いに理解しやすい形でテスト結果をアウトプットできるようすると良いと考えているよ。 ふむふm…あっ！ありがとうございます！なるほど…ここまでの話だと、『探索的テストの内容』についてフォーカスが当たっていましたが、『目的に対する最終的な成果（何がアウトプットされるか、そこで何がわかるか）』を最初にしっかりと共有しておくことで、より良い成果を出していけるようになりますね！ そうだね、コメントした内容は探索的テストだけに限らない部分もあるけれど、上記を考慮しつつ探索的テストのメリットである、『少ない工数でのテスト』や『スピード感を持ったテスト』という特性を活かしながら進めていけると良いね！これからも心のアクセルふかしていこう！ Yeeeeeeeeeeaaaaaaaaaah! \ / 次回予告 今回はここまでにして、JSTQB ALの学習に戻ろうかな！（ ）次回の記事はどんな感じにしようか？ 次回のまーくー＆くまねこは、 ・まーくー、JSTQB ALTM試験、いったいいつ受けるの？まだでしょ！（仮） ・くまねこ、JSTQB FL試験を振り返る！（仮） の2本でーす。 最後まで読んでいただき、ありがとうございました！よろしければ、過去のゆるっと♪シリーズもお楽しみください！次回もまた見てねー ﾉｼ ﾉｼ ゆるっと♪シリーズ 第1回 ゆるっと♪ファームウェアテストよもやま話 第2回 ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験 第3回 ゆるっと♪どうやってる？探索的テストの世界！ The post ゆるっと♪どうやってる？探索的テストの世界！ first appeared on Sqripts .

前回の記事 では、組織の中でテスト自動化を普及するためには個人やチームが頑張るだけではなく、組織でどう取り組むかについて考える必要があるというお話をしました。 たとえばマネジメント層の理解や適切なリソース配分などが大事、という内容でしたが、組織で普及していくために欠かせない要素は他にもあります。 それは、テスト自動化に関わる個々のエンジニアがテスト自動化について知識とスキルを身につけること、です。 テスト自動化に限らず、組織の後押しだけでは物事は進みません。現場で業務をおこなうひとりひとりが技術や考え方を身につける必要がありますよね。 今回は前回の記事とは視点を変えて、実際にテスト自動化をおこなう個人に焦点を当て、テスト自動化スキルを身につける方法について解説します。 なお、本記事中の「テスト自動化」は前回までと同様、E2Eテストなどテスト対象のUI、とくに画面を操作しておこなうようなテストのことをターゲットとします。 テスト自動化をおこなうために身につけるべきもの システムテストの自動化をおこなうにはさまざまなスキルが必要ですし、同時にすでに知られているベストプラクティスやアンチパターンなどの考え方を把握しておくことも大切です。 これらをひとつずつ挙げていくとキリがないですし、何においても「学ぶべきこと」は無限にあります。 ここでは 技術面 知識面 の2つの側面から主な例を説明し、次の項目でその学び方についてご紹介します。 技術面 技術面、テクニカルなスキルとして身につけておきたい点は大きく2つです。 ①プログラミングのスキル ひとつは、プログラミングのスキルです。 SeleniumやPlaywright、SikuliXなどのライブラリを用いる場合はプログラミング言語でテストを書く必要があるため、当然プログラミングスキルは必要になります。 しかし、最近ではノーコード・ローコードのテスト自動化ツールも普及しています。プログラミングのスキルがなくてもテスト自動化にトライできる環境が整ってきているといえるでしょう。 ここで注意が必要なのは、テストを自動化できることと、自動化したテストをうまく使い続けられることとは別である、という点です。たとえノーコード・ローコードのツールであっても、行いたいテストに応じた詳細な設定などをおこなう機会はあり、「結局JavaScriptを書く必要が出てきた」というシチュエーションもよくあります。 また、テスト手順の一部を共通化したり、同じ手順でもより効率的な操作の仕方を考えたりと、一般的なプログラミングで求められるスキルが転用できる部分は多々あります。 プログラミングのスキルがなくてもテストは自動化できるけれども、うまくやる、継続するためにはあったほうがいい、と考えておきましょう。 ②テスト対象を構成する技術要素のスキル もうひとつは、テスト対象を構成する技術要素に関するスキルです。 極端なことを言えば、「テスト対象を自分でも作れるくらいになりましょう」です。ただ、これからテストを自動化を学ぼうと思っている方にとってはハードルが高いですよね。こんなことを書いているわたし自身も、いまテストしているWebサービスと同じものを作れ！と言われたら、おそらくできないと思います。 QAエンジニア・テストエンジニアの方が開発者と同等のスキルを身につけることは大変です。ただ、ここで言いたいのは、基本的なところについては実際に手を動かして理解をしましょう、ということです。 たとえばWebサービスのテストを自動化したいのであれば、HTML・CSS・JavaScriptなど、使われている技術要素に関する基本的な理解が必要です。Windowsのアプリケーションを自動化するには、ウィンドウハンドルの考え方や、場合によってはWin32APIを知っておくことも必要かもしれません。 以上2点がベースにあれば、あとは個々のツールやライブラリの使い方を身につけることで、テスト自動化に関して「手を動かして進める」ことができるでしょう。 ただし、手を動かせるだけではテスト自動化ができるとは言えません。技術面のスキルと同時に、考え方についても学ぶ必要があります。 知識面 手を動かしてテストを自動化するだけでなく、どんなテストを自動化するかや、テスト自動化自体をどう進めていくかを考えることも必要です。 そのために必要な知識として、こちらも大きく2つが挙げられます。 ①ソフトウェアテストの知識 ひとつはソフトウェアテストに関する知識です。テストプロセスや、各テストレベルにおいてどんなテストをおこなうべきか、などを知っておく必要があります。 ソフトウェアテストについての知識がなくとも、技術面で挙げたスキルを持っていればテスト自動化はできます。しかし、『 テスト自動化の8原則 』にも 2. 手動でおこなって効果のないテストを自動化しても無駄である テスト自動化の8原則 とあるように、そもそもテストとして有効かどうかが重要なポイントです。 意味のあるテスト自動化をおこなうためには、その土台としてソフトウェアテストに関する知識が必須です。 ②テスト自動化の知識 もうひとつは、テスト自動化に関する知識、とくに一般に公開されている事例およびベストプラクティス・アンチパターンは押さえておくべきです。 テスト自動化も取り組む組織が増えてきたおかげで、「こうしたらうまくいった」「こうしたら失敗した」といった事例が多く公開されています。これからテスト自動化を学ぶ方にとっては、とてもありがたい状況です。 他社での成功事例をそのまま真似すればいい、というわけではありません。しかし、すくなくとも同じ失敗をしないように他社事例を把握しておくことは大切です。 学ぶための手段 ここまで、技術面と知識面それぞれ身につけておくべき代表的な事項について説明しました。 ここからは、実際にそれらの事項を身につけるにはどうしたらいいのかをご紹介します。 わたしが考える、テスト自動化に関する技術と知識を身につける最良の方法は「詳しい人に教わりながら実務でテスト自動化をおこなう」です。そうはいっても、そんな方法で身につけられる機会というのはそうそうない、とも思っています。 たとえば社内の研修がある、もしくは詳しい方に聞ける環境があれば、それらを最大限活用するところから始めましょう。 なかなかそうした機会が得られない、身の回りにはない、という場合は以下を参考に学び始めてみてください。 技術面の学習方法 身につけるべき内容、として先に挙げた プログラミングのスキル テスト対象を作るためのスキル については、書籍やWebサービスなどが多数あります。 プログラミングが未経験である、という場合は簡単な入門書から始めてみたり、最近ではWebブラウザ上でプログラミング学習ができるサービスを利用したりするのがオススメです。わたしが過去、テストエンジニア向けにプログラミングを教えていた際には、ブラウザ上で説明を読みながらコードが書けるタイプの学習サービスを用いていました。独力で書籍を頼りに学習するのに比べ、効果的に身についていた印象です。 プログラミングの感覚が掴めたら、ごく簡単なものでもよいので、動作するアプリケーションを作ってみましょう。 また、最近ではプログラミングや開発に関して学ぶためにChatGPTを使うのも有効です。プログラミング言語を指定して「こんなものを作りたいから、順序立てて説明してほしい」と書くと丁寧に教えてくれますし、エラーが出た場合に「こんなエラーが出たが、どう解決すればいいか」と聞くと答えてくれます。 あまりにもChatGPTに頼りすぎてしまうとスキルアップに繋がらないため、ある程度自分で考えたうえでどうしてもわからない場合に質問をするか、「直接答えを書かずにヒントを教えてほしい」と依頼すれば上手にサポートしてくれます。 テスト自動化に関する技術を学ぶ際は、プログラミングを学ぶのとは少し違ったアプローチになります。 わたしのオススメは、テスト会社や第三者検証会社、テスト自動化ツールを開発している会社がおこなっているハンズオンに参加することです。誰かに教わりながら実際に手を動かしてテスト自動化ができるという点で、よい機会になるでしょう。 一方ハンズオンだけでは実践レベルのスキルを身につけることが難しいので、学んだことを手元で、できれば業務でテストを自動化したい対象でおこなってみるのが理想です。 SeleniumやPlaywright、あるいはKatalonStudioなど無料で使えるツールやライブラリもあるので、これらを用いて実践してみることが一番です。 テスト自動化ツールは テスト自動化関連ツール・ライブラリまとめ – Qiita にまとめてありますので、ここから無料のものを探して使ってみてください。 他には、動画で学ぶという方法もあります。 たとえば Test Automation University | Applitools では、テスト自動化に関するさまざまなツールやライブラリの使い方など、実践的な動画が公開されています。すべて英語にはなってしまいますが、動画自体はYouTubeにアップされており、自動翻訳で字幕をつけることもできます。 知識面の学習方法 技術面の学習に比べると、テスト自動化の知識をたくさんインプットするほうが始めやすいかもしれません。 身につけるもの、として挙げた「ソフトウェアテストに関する知識」は、書籍や資料がたくさん存在します。 個別のテスト技法に習熟することも大事ですが、テスト自動化の前提知識として学ぶ場合にはテストプロセスやテストの全体像を把握することのほうが優先です。 テストプロセスなど、ソフトウェアテストに関して学ぶには ASTERセミナー標準テキスト ASTERオンラインセミナー – YouTube が無料でいますぐ見られる点でオススメです。こちらを読んで＆視聴して、必要に応じて書籍などを読むのがよいでしょう。 テスト自動化について学ぶには、『 テスト自動化の普及と推進【前編】～阻害要因と対策 』の最後でもご紹介した、以下の書籍やサイトが参考になります。 Test Automation Patterns Experiences of Test Automation: Case Studies of Software Test Automation システムテスト自動化 標準ガイド (CodeZine BOOKS) ただ、上記はいずれも英語だったりボリュームが多かったりと、最初に読むには大変かもしれません。 もっとも短くてポイントをおさえられるのは、本記事でもご紹介している『 テスト自動化の8原則 』です。こちらはテスト自動化研究会が公開しているもので、テスト自動化をおこなううえで意識すべき点が簡潔にまとまっています。 他にも、 玉川 紘子(たまがわ ひろこ) | Sqripts さんの連載も読んでおくとテスト自動化を実際に運用する面で大切なことを学べます。 学習の両輪を回そう 本記事では、技術面と知識面の2つの側面からテスト自動化について何をどう学ぶかを説明しました。 テスト自動化のコードやスクリプトだけが書けても継続的な自動化は難しいですし、一方で知識のみがあっても手を動かせなければ自動テストは実現できません。技術と知識はどちらも必要です。 手を動かすことと、ベストプラクティス・アンチパターンなどを知ることの両輪を回しながら学習と実践をしていきましょう。 連載一覧 テスト自動化ツールの選定【前編】～ツールの比較表をどう活用するか テスト自動化ツールの選定【後編】～AI自動テストツールを選ぶ時に気をつけるべきポイント テスト自動化の普及と推進【前編】～阻害要因と対策 テスト自動化の普及と推進【後編】～個人レベルでテスト自動化を学ぶ The post テスト自動化の普及と推進【後編】～個人レベルでテスト自動化を学ぶ first appeared on Sqripts .

▼ 参加応募フォームはこちら イベント概要 AIを”どう使うか？”に注目が集まっていますが、完璧ではないAIを” どうテストするか？ “についてはほとんど議論がされていません。 AIプロダクトのテストについて、AIテストの第一人者であるStuart Reid博士と西康晴先生をお招きして特別セミナーを開催します。 なお、当セミナーは オフラインのみでの開催 （於：帝国ホテル東京）です。 ※1 AIの話題に浸りながら、コーヒーブレイクも味わえる、オフラインならではの体験をお届けします。 AIテストについての新たな知識と、共に学ぶ仲間とのつながりを得る貴重な機会をお見逃しなく！ ※1　オンライン配信はありません Sqripts会員を特別ご招待！ 今回は当セミナーに Sqripts会員のみなさまを抽選でご招待 します。 ぜひご参加ください。 まだSqripts会員ではない方は、本イベントを機に会員登録（無料）をご検討ください。 ご登録いただくと、会員限定で公開している各領域のエキスパートによる特集記事もお読みいただけます。 ▼ 参加応募フォームはこちら Speakers ▼ 参加応募フォームはこちら 日時・場所 日時： 2023年9月26日（火曜日）18:30～20:30（Door Open 18:15） 場所： 帝国ホテル東京　本館3階 鶴の間 〒100-8558東京都千代田区内幸町1-1-1 交通アクセス： 帝国ホテル東京「アクセス」ページ ▼ 参加応募フォームはこちら タイムテーブル 18:30-18:35 開会挨拶 18:35-19:15 Reid博士 講演　※同時通訳サービスをご提供いたします 19:15-19:40 Coffee Break * Networking　　　　　　　　　　　　　　 19:40-20:10 西 康晴 氏 講演 「AIのAIによるAIのためのテスト」 20:10-20:30 高橋 寿一 講演 「AIテスト及びシフトライト戦略」 20:30 閉会 ▼ 参加応募フォームはこちら 募集要項 応募資格 2023年9月7日17時時点で参加応募フォームからのお申込みかつ、 Sqripts無料会員の登録が完了していること 応募方法 下記「セミナー参加応募フォーム」に入力の上ご応募ください。 Sqripts会員未登録の方は、応募フォーム入力後画面より無料会員登録をお願いします。 （Sqripts無料会員登録は こちら ） 応募期限 2023年 9月 7日　17時00分 定員 60名（応募多数の場合は抽選） 参加費 無料 当選発表 抽選結果は9月中旬にメールでご連絡します ご案内 当日参加される方は、お名刺を2枚ご持参ください セミナー参加応募フォーム MktoForms2.loadForm("//lp.agest.co.jp", "730-KXO-656", 1567); お問い合わせ先 当セミナーに関するお問い合わせ先 株式会社AGEST　マーケティング本部 TEL： 03-6735-2051 　※土日祝除く10～18時 Mail： ml-IS_group@agest.co.jp The post ◆ご招待◆9.26開催！Stuart Reid博士 特別セミナー｜知識ゼロから学ぶAIテスト first appeared on Sqripts .

こんにちは、クオリティマネージャーのこやまです。 QAメンバーやプロジェクトマネージャーの方で、お客様や上司から「不具合を分析して対策をまとめて」と言われたことはありませんか？ 不具合分析と言われるとなぜなぜ分析と信頼性成長曲線分析が思いつきます。信頼性成長曲線分析は不具合収束の傾向を把握できますが、不具合の原因特定までできません。一方、なぜなぜ分析では、不具合の詳細な調査に多くの時間と労力が必要です。 そこで、効率よく原因と傾向が分析できる「ODC分析」があると知り、調べた内容をご紹介します。 ODC分析とは 1992年に米IBM社 ワトソン研究所で確立された「欠陥分類手法」です。ODC分析のODCは「Orthogonal Defect Classification」の略称で、直訳すると「直交　欠陥　分類」となります。「直交とは直線どうしが直角に交わること」との意味で、お互いに依存しない別軸から欠陥を分類して分析する手法だと理解しました。 お客様よりテスト工程の不具合分析についてご相談をいただいたため、ODC分析を使用してみようと思い「ソフトウェア不具合改善手法ODC分析　工程の『質』を可視化する」 ※1 を用いて更に知識を深めました。 この書籍には以下のように記載してあります。 『ODC分析は、成長曲線のような数量的状態の統計的分析とRCAのような局所的な原因分析とちょうど中間に位置づけられる。ODC分析は、個々の不具合の要因分析とその要因の数値的な分析という両面を持ち合わせている分析手法といえる』 不具合の測定・分析手法におけるODC分析手法の位置付づけ ソフトウェア不具合改善手法 ODC分析 RCA(Root Cause Analysis:根本原因分析) ODC分析の手順 ODC分析の手順ですが、大きくは３段階で分析する手順を簡単に説明します。 A.分析したいシステムの不具合を分類 B.定規や尺度、指標となる不具合の分類結果と比較 C.プロセス実施の改善策を提供 A.分析したいシステムの不具合を分類 分析する前に不具合に関する考え方を理解する必要があります。ODC分析では、不具合はお互いに依存しない4つの属性（タイプ、トリガー、ソース、インパクト）で構成され、これらの属性が相互作用を起こして引き起こされると考えられております。 各不具合に対して４つの属性それぞれの属性値を割り当てて分類します。因みに属性値は選択肢として予め定義しておきます。 属性の概要 ※1 属性 属性概要 例 タイプ属性 プロセスに関わる不具合を示唆する属性 値の設定、条件分岐、機能性など トリガー属性 不具合を表面化した動機 レビュー、結合テスト、総合テストなど ソース属性 不具合を含んでいたコードの箇所 新規、再利用、修正など インパクト属性 ユーザ、顧客への影響 使用性、性能、信頼性など 引用元 ※1 には属性の詳細や選択肢も掲載されています。 ソフトウェア不具合改善手法 ODC分析 Ｂ.定規や尺度、指標となる分類結果との比較 定規や尺度、指標となる分類結果は、「プロセス・シグネチャー」と言われており、「開発プロセスの期待」です。「開発プロセスの期待」とは『「正しくプロセスを実施すれば、正しく「しかるべき不具合」の分布になる」』（引用※１）というものです。 ODC分析では前記Aでの分類結果の内、「プロセス・シグネチャー」と異なる点に課題があると考えます。分析したいシステムの不具合を分類した結果と「プロセス・シグネチャー」をグラフ化すると視覚的に異なる点を確認できます。 なお、最初にODC分析を行う場合、定規や尺度、指標となる「プロセス・シグネチャー」を策定する必要がありますが、同じ開発プロセスで成功したプロジェクトの不具合内容を基にODC分析を行い「プロセス・シグネチャー」とするなどの方法が考えられます。 Ｃ.プロセス実施の改善策を提供 前記Bで比較した違いの原因を調べ、原因から示唆されるプロセス実施の「やり方」を考察し、「弱点」を見つけ出し、改善策を策定します。 例として、あるプロジェクトでのプロセス・シグネチャーと現状の不具合分類結果のグラフ、現状の評価、総合評価を以下に紹介します。 プロセスの期待（プロセス・シグネチャー）’（出典 ※1 P108）　 ソフトウェア不具合改善手法 ODC分析 プロジェクトの現状（出典 ※1 P108） ソフトウェア不具合改善手法 ODC分析 現状の評価 『設計・単体テスト工程でのFunction（機能性）の不具合が少なく、機能テスト（統合テスト）で、急増している。設計上はまだまだ機能性の不具合が残存しており、次工程で漏れ出る可能性が高い。』 ソフトウェア不具合改善手法 ODC分析 総合評価 『システムテストの開始基準を満足していないレベルと考える。このままシステムテストを開始すると、前工程で修正すべき不具合が多発し、システムテストの妨げになり、十分なシステムテストができないと考える。前工程の特にFunction、Timing/Serializeを見直しを行ったうえで、開始作業を判定すべきである。』 ソフトウェア不具合改善手法 ODC分析 試しに実施した感想 少ない件数ですが過去の不具合データで試しにODC分析を行った感想です。プロセス・シグネチャーと比較することで、プロセスにおける差異を視覚的に説明することができました。しかしながら、全不具合1件ずつに対して4つの属性を割り当てる作業は、属性毎に多数の選択肢から選ぶ必要があり作業に時間を要しました。 また、複数の担当者で作業をする場合、人により異なる解釈をしてしまうと同じ割り当て結果になるとは限らず、正確な分析ができない可能性があると感じました。分析する前に各選択肢の意味を関係者間で認識合わせしておくのがよいと思います。 導入する際は、不具合管理ツールの入力項目として4つの属性を追加し、各属性に選択肢を定義して、いつ誰がその属性を入力するのか等のワークフローを決めておき、関係者へ説明してから利用開始するのがよいと考えました。 まとめ ODC分析を利用することで、不具合の調査から対策の策定までを行い、プロセスの品質を改善できます。ただ、属性に割り当てる選択肢が多いため、最初は時間が必要になるかもしれません。ですが、事前準備と慣れで解消できると考えます。慣れてしまえばODC分析は効率的な技法であり、QAメンバーやプロジェクトマネージャーが活用を検討してみる価値がある技法だと確信しました！ ※1　杉崎 眞弘 (著), 佐々木 方規 (著), 日科技連ODC分析研究会 (編集), 2020/08/21, 「 ソフトウェア不具合改善手法 ODC分析 」, 日科技連出版社 The post ODC分析：なぜなぜに疲れたQAメンバーに捧ぐ分析手法 first appeared on Sqripts .

「テスト推進」という仕事 はじめまして、おかじです。私は、テスト推進というポジションの業務を担当しています。 テスト推進とは、簡単に言うとテスト分野を専門としたPMO（プロジェクトマネージメントオフィス）のような仕事です。PMOはPM（プロジェクトマネジャー）やプロジェクトチームに対して、プロジェクトの計画・実行・状況管理などをサポートし、プロジェクトの品質向上を図る役割を担っていますが、一方テスト推進はテストの計画・実行・状況管理などをサポートし、プロジェクトの品質向上を図る役割を担っています。 本記事は、テスト推進業務の経験を元に「現場で意外と困ることの多いテスト環境利用問題」をテーマにテスト環境利用管理について記載します。 これからテスト推進を担当する方にとって、この記事がなにか参考になればと思います。 意外と困るテスト環境利用問題 テスト環境の利用調整に困っているという声をよく耳にします。「テスト環境の管理なんて必要ですか？」と思う方もいると思います。例えばスタンドアローンのアプリケーションのように、自前で用意した環境だけでテスト対象アプリをインストールしてテストできるものであれば、テスト環境利用の問題は発生しないと思います。しかし複数の機能群（サーバー群）から構成されるシステムや特殊なハード機器がある場合などは、簡単に複数のテスト環境を用意することは難しく、テスト環境の利用管理が必要になってきます。 テスト環境利用管理の検討が必要なケース、テスト環境利用で起きる問題例を以下に記載します。 テスト環境利用管理の検討が必要なケース 複数のサーバー群で連携動作するシステムである場合。 マルチベンダー開発や関連事業者が複数いる場合。 複数の案件が同じ環境利用で絡む場合。 テスト環境利用で発生する問題 テスト環境を利用したいが、他のチームが利用して使えない。 　→　テストスケジュールの見直しが発生した。 環境を占有利用していたが、他のチームが別作業を行って作業中にトラブルが発生した。 　→　テスト実施のやり直しや環境故障の修復作業が発生した。 環境を利用し始めた際に想定の環境状態と実際の環境状態が異なり、トラブルが発生した。 　→　予定作業が始められず、スケジュール遅延となった。 などなど。 このようなトラブルが続出してしまうとトラブル対応工数や調整工数の増加、スケジュールの再計画の発生が各作業者の負担を増加させてしまい、その結果より大きなミスを誘発してしまう可能性もあります。 「現場で意外と困ることの多いテスト環境利用問題」に対して、私はテスト環境の利用管理を行うことでテスト環境利用問題を軽減し、テストを推進するよう取り組んでいます。 テスト環境の利用管理 大規模なプロジェクトになると以下のような体制で開発することがあります。 体制：複数社・複数チーム 環境構成：大規模Webシステム・サーバー数十台単位の構成 利用状況：複数案件が並走 上記のように複数のサーバーで構成された環境、複数会社やチームによって複数案件が並走しているプロジェクトでは、テスト環境利用管理が必須となります。 これから私が実際に行ってきた管理方法をベースに、テスト環境利用管理の４つのポイントを紹介します。 【ポイント１】環境利用の管理表を考える 【ポイント２】作業区分の定義を考える 【ポイント３】環境変更区分の定義を考える 【ポイント４】環境管理の運用を考える 【ポイント１】環境利用の管理表を考える テスト環境利用管理を行うために、把握しやすい管理表が必要です。 私は日単位の管理表と時間単位の管理表の二つをエクセルで作成して管理しています。この二つに分けた管理を行っている理由は俯瞰的な状況と詳細な情報を管理し易くするためです。 日単位の管理表 日単位の管理表は、利用予定の俯瞰的な確認、プロジェクト内での情報共有を図ることに利用します。また、主要な環境状態（資材、マスターデータ、システムの設定状態など）を一緒に記載することで、環境状態も可視化できるようにしています。 時間単位の管理表 時間単位の管理表は同日に複数チーム、複数作業が並走した場合に各作業時間や順序を調整したり、環境変更を伴う作業の記録を残すために利用しています。 この時間単位の管理表があることで、より詳細な作業対象環境、作業時間帯を把握できるようになります。 【ポイント２】作業区分の定義を考える 作業区分定義の目的は、利用調整が必要になる作業なのかを簡易的に把握するために定義します。私は「占有作業」「非占有作業」「部分占有作業（条件付き作業）」の３つの区分で整理しています。 占有作業 環境変更など、他の作業と並走不可能な作業 非占有作業 システム動作を停止しなければならない作業がない。他の作業と並走可能な作業 部分占有作業（条件付き作業） 一部のサーバー、一部のデータ領域のみを占有し、条件によっては他の作業と並走可能な作業 【ポイント３】環境変更区分の定義を考える 環境変更区分定義の目的は、環境の状態が変わるのか、変わらないのか、一時的に変えて元の状態に戻すのかを簡易的に把握するために定義します。 環境変更なし 資材変更、設定変更、マスターデータ変更などを伴わない。 環境変更あり 資材変更、設定変更、マスターデータ変更などを伴う。 環境一時変更あり 資材変更、設定変更、マスターデータ変更を伴うが作業後に元の状態に戻す。 【ポイント４】環境管理の運用を考える 環境管理の運用を考える際の重要なポイントは「続けられる運用であること」です。 ルールが複雑で理解しにくかったり、時間や手間が掛かってしまうものだと、管理の考え方が良いものでも続かなくなってしまいます。 私が現場で設けている運用ルールは大きく以下５点です。 日単位の管理表に予定を記載したい場合は、各チームから環境管理者に申告する。 環境変更を伴う作業や同日に複数利用者がいる場合、利用者が時間単位表に作業を記入する。 時間単位で作業が重複した場合、記入した利用者から環境管理者へ連絡する。 環境管理者は各チーム情報をもとに調整が必要な場合、関係者を集め調整を行う。 環境占有、環境変更を行う作業は作業開始時、作業完了時にメールで周知連絡を行う。 これらの運用は、管理者を置くことで作業情報を集約すること、また作業重複時の調整役とすることで、認知されていない環境変更の抑止を目的としています。 最後に 本記事では環境利用管理を行う際にポイントとなる考えを記載しましたが、環境利用管理を行うことで以下の様なメリットがあります。 環境利用状況を視覚化することで各チームのテストスケジュール計画がし易くなる。 調整が必要となる作業を把握し易くすることで環境利用の調整工数を削減できる。 環境状態を視覚化することで、各チームが利用開始時に想定と異なる環境状態になっていた場合の作業遅延リスクを低減できる。 管理者に環境の利用状況を集約するこで、環境変更に伴うトラブルが発生した際の、変更が行われた作業を特定しやすくなる。 など、環境を利用する作業者の負担を軽減することができます。 ソフトウェア品質の根幹には「人はミスをするもの」という考えが根底にありますが、人がミスし易くなる時を考えると作業者の負担が大きい時にミスを犯しやすくなると思います。逆に考えれば、作業者の負担を軽減することで、ミスは減らせるのではないでしょうか。 些細な環境利用管理という側面からでも、作業者の負担を軽減することで作業者のミスを減らすことに繋がり、ソフトウェア品質の向上への間接的なアプローチになると思います。 最後まで読んでいただき、ありがとうございました。 The post テスト推進虎の巻 ～テスト環境利用管理～ first appeared on Sqripts .

本連載では、ブロックチェーンの基本的な仕組みを解説しながら、オンチェーンデータを分析するための基本的な手法について、全8回で紹介します。 第4回となる今回は、オンチェーンデータ分析の手法としてSQLを用いることのメリットについて、SQLの背景にある概念や歴史などを交えながら解説していきます。 データ分析のためのSQL SQLとは、もともとリレーショナルデータベースと呼ばれるデータベースシステムからデータを抽出したり、データを操作したりするための専用の言語でした。近年では、SQLの完成度と汎用性の高さから、データベース分野に留まらず、広くデータ分析の用途でもSQLが活用されています。 コード1. SQLのサンプルコード CREATE TABLE sample ( id INT, name TEXT, description TEXT ); INSERT INTO sample VALUES (1, 'AAA', 'some text'); INSERT INTO sample VALUES (2, 'BBB', 'some text'); SELECT id, name FROM sample WHERE id <= 1 LIMIT 10; ここで、単なるデータの集合とデータベースの違いについて補足しておきます。まず、「データ」という言葉の定義自体がさまざま存在しますが、ここでは「一定の形式（フォーマット）で整えられた事実や数値」といった意味で取り扱うこととします。例えば、ある企業に属する従業員のIDや氏名、生年月日などをCSV形式やJSON形式で保存したテキストファイルは、典型的なデータの一種です。 一方、データベースとは、こうしたデータの集合を体系的に構成し、データを簡単に検索したり、整合性を持って更新したりできるようにしたものを指します。無秩序なデータを単に寄せ集めたもので、目的のデータを簡単に抽出したり更新したりできないような状態になっているデータの集まりであれば、一般的にはデータベースとは呼ばれません。 なお、ビッグデータの文脈では、従来のデータベースで管理されているような体系的なデータの集合を「構造化データ」、それ以外の多種多様で雑多なデータ群を「非構造化データ」と呼ばれることもあります ※1 。ICT技術の発展に伴い、この「非構造化データ」が急速に生成・保存されるようになったことで、ビッグデータの活用という概念が注目を集め始めました。この文脈に即して冒頭の説明を言い換えると、「SQLはもともと『構造化データ』を操作するために利用されていた言語だが、近年では『非構造化データ』に対してもSQLを適用してビッグデータ分析に活用する事例も増加している」とも表現できます。 ※1 総務省 平成25年版 情報通信白書 – ビッグデータの概念: https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h25/html/nc113110.html 3層スキーマ 多くのデータベースシステムでは、物理的に保存されたデータのフォーマットとは別に、抽象的な概念としてのデータモデルを備えています。 米国国家規格協会（ANSI）の標準化計画要求委員会（SPARC）が提唱した「3層スキーマ」というモデルでは、データベースの構造を「外部スキーマ」「概念スキーマ」「内部スキーマ」という3つのスキーマに分けて定義しています。これは、データの物理的な保存形式である「内部スキーマ」と、データを加工して利活用するビューとしての「外部スキーマ」との間に、緩衝材となる抽象的な「概念スキーマ」の層を配置することで、データの独立性を保つための構造です。 図1. 3層スキーマ 3層スキーマの考え方を用いず、物理的なデータを直接プログラミング言語などで加工してデータ分析する手法も存在します。CSVファイルなどで保存されたデータをPythonなどで読み込み、直接加工するような方法です。 このとき、物理的なデータの格納方法を変えたいときに、同時にプログラム側の改修が必要となったり、逆にデータの表示形式を変えたいときに、物理的なデータの格納方法を変更しなければならなくなったりすることがあります。こうした状態はデータの独立性が存在しない状態と言えます。一人のデータ分析者がデータを取り扱うだけであればそれほど問題はないかもしれませんが、多くの分析者が同時に同じデータを扱ったり、分析者とは異なる人物がデータの保存方法をメンテナンスしていたりする場合には、3層スキーマのような形でデータの独立性を担保してあげたほうが良いでしょう。 こうしたデータの独立性を担保するために、SQLという言語は共通のインターフェースとして非常に都合が良かったため、データベース分野だけでなく、広くデータ分析のために活用されてきています。 リレーショナルモデル データベースの種類には、オブジェクトデータベースやグラフデータベース、ドキュメントデータベースなど様々なものが存在しますが、SQLとともに広く普及しているデータベースの種類がリレーショナルデータベース（RDB）です。 さきほど説明した通り、多くのデータベースでは、物理的なデータを直接取り扱うことは少なく、抽象的なデータモデルを持っている場合があります。リレーショナルデータベースの場合は、リレーショナルモデル（関係モデル）と呼ばれる独自のデータモデルを持っており、そのモデルはSQLの思想にも強く反映されています。 リレーショナルモデルでは、データを取り扱うための基本的な構造を「リレーション（関係）」と呼びます。ただし、これは日常生活における「関係」や「リレーションシップ」という言葉から連想するものとはかなり異なる、数学的な独自用語であることに注意が必要です。 日常生活における「関係」という言葉は、「親子関係」や「因果関係」など、２つの項目に注目した場合が多いでしょう。例えば、「サザエさんとタラちゃんは親子関係である」や「風が吹けば桶屋が儲かるのは因果関係である」といった形です。 この「関係」という言葉を少し数学的に表現すると、「2つの集合A, Bに対して、直積A×Bの部分集合を、AとBの間の二項関係と呼ぶ」といった表現ができます。集合AやBを人物の集合とすると、直積A×Bというのは、その集合に含まれる人物同士のすべての組み合わせの集合となります。その人物同士の組み合わせには、親子関係である組み合わせもあれば、そうでない組み合わせも含まれるでしょう。このとき、親子関係にある組み合わせのみを取り出した集合を、数学的には「直積A×Bの部分集合」という表現をします。 リレーショナルモデルにおけるリレーション（関係）は、上記の数学的な二項関係の定義をN項関係に拡張し、「属性の定義域(ドメイン)D1, D2, D3, …, Dnに対して、 直積D1×D2×D3×…×Dnの部分集合Rを関係と呼ぶ」と定義されます。 例えば、日本人のすべての名字を含む集合Aと、日本人のすべての名前を含む集合Bを、それぞれ名字の定義域、名前の定義域として直積A×Bを計算すると、A×Bにはすべての日本人の名字・名前の組み合わせと、存在しない架空の人物の名字・名前の組み合わせが含まれることになります。このとき、実際に存在する日本人の名字・名前の組み合わせを「日本人の名字・名前を示す関係」と呼ぶ、といった考え方が、リレーショナルモデルのデータの表現方法になります。 図2. 名字・名前のリレーション（関係）のサンプル このリレーション（関係）を人間が理解しやすいように可視化する際に、よく属性列とデータ行とで構成された二次元テーブルの形式で表現することが多いため、リレーショナルモデル＝二次元テーブルだと考えてしまいがちです。しかし、CSVファイルやエクセルファイルで取り扱われることの多い二次元テーブルの表示形式と、抽象的な集合論に基づくリレーション（関係）とでは、見え方が似ていても厳密には異なるものなのだということを頭の片隅に置いていただければ、SQLの理解が深まるでしょう。 関係代数とSQL リレーショナルモデルでは、上記のように定義したリレーション（関係）というデータモデルに対して、関係代数と呼ばれる演算を定義しています。これは、「整数」という型のデータに対して、足し算や引き算などの演算を定義しているようなイメージです。リレーションに関係代数を適用することで、リレーションの形を変形したり、新たなリレーションを生成したりすることができます。SQLという言語は、この関係代数を簡単に記述するための言語であり、PythonやJavaScriptのようなコンピュータへの命令を記述していく命令型言語よりは、抽象的な関数や述語論理に基づくHaskellやPrologのような宣言型言語に近いプログラミング言語です。 SQLや関係代数の重要な特徴として「閉包性」と呼ばれる性質があります。これは、リレーション（関係）に対して関係代数を適用した結果は、必ずリレーション（関係）になる、という性質です。例えば、整数に対して足し算や引き算を何度繰り返し適用したとしても、その結果は常に整数であり、突然文字列データになったりはしません。このことは、基本的な演算子を無数に組み合わせて複雑な計算を表現することができる点や、どれほど複雑な演算子の組み合わせを適用した計算結果であっても、それを別の演算子の入力として利用できる点などが保証されていることを意味します。 図3. 関係代数の閉包性（関係代数演算の出力は、別の関係代数演算の入力となれる） したがって、SQLによるデータ加工やデータ分析のためのクエリ文は、非常に複雑な処理を記述できる柔軟性と、それを別のクエリと組み合わせることのできる可用性を担保することができます。この性質により、SQLはデータベースのみならず、ビッグデータ領域を含む幅広い領域でのデータ加工・データ分析用途のために活用され続けています。 標準SQL規格 SQLの言語仕様は、米国国家規格協会（ANSI）や国際標準化機構（ISO）によって標準化されており、異なるデータベースや分析システムであったとしても基本的に同じSQLの標準規格に準拠しており、SQL文の保守性や移植性の担保に貢献しています。ただし、システムによって標準規格への準拠状況が異なっていたり、独自の機能拡張が行われていたりすることも多いため、100%同じSQL文が他のシステムでも流用できるというケースは多くありません。それでも、独自フォーマットのファイルシステムを直接操作するプログラムを移植するよりは、遥かにデータの独立性を保った運用が可能です。 また、標準SQL規格は、古い規格で書かれたSQL文との後方互換性を維持しながら、データ分析用途で需要の高い構文も取り入れつつ進化を続けています。特に、SQL99で導入された共通表式（WITH句）や、SQL:2003で拡張されたウィンドウ関数などは、近年のデータ分析用途では必須の構文となります。詳しい構文の説明は本連載記事の次回以降でおこないますが、SQLを用いたデータ分析のための技術選定をする際には、これらの標準SQL規格への準拠度合いなども参考にしていただければと思います。 オンチェーンデータのためのSQL実行基盤 本連載の第2回や第3回記事において、ビットコインやイーサリアムのオンチェーンデータをSQLで分析できるオンラインサービスとして、Google BigQueryやDuneなどをご紹介しました。 特に、Duneというサービスは、ブロックチェーンのオンチェーンデータ分析に特化したスタートアップであり、これまで複数のSQL実行エンジンを利用しながらバージョンアップを繰り返してきました。ここでは、Duneが採用したSQL実行エンジンをサンプルとしながら、SQLを用いたデータ分析の利点や注意点などを解説します。 Dune 初期のDune v1では、オープンソースのリレーショナルデータベースマネジメントシステム（RDBMS）であるPostgreSQLを用いて、オンチェーンデータのオンライン分析サービスを提供していました。その後、データフォーマットを修正したDune v2が登場し、SparkSQLによるSQL実行環境が追加され、2023年8月現在ではDuneSQLという独自のSQLを用いたインターフェースに移行しています ※2 。 ここで、Dune v1とv2の採用しているSQL実行エンジンの違いについて深掘りしてみましょう。PostgreSQLのようなRDBMSは、さまざまなアプリケーションのバックエンドとして、多数のトランザクションを同時に実行するOLTP(Online Transaction Processing)を想定して実装されています。 サンプルデータとして、日本の全人口1億人強の戸籍データベースを想像してみましょう。OLTPで想定するデータ処理としては、約1億人のデータベースから該当する人物のレコードを抽出し、詳細データを表示したり、一部のデータを更新したりする処理が考えられます。このとき、約1億人のデータをCSVなどのファイルベースで管理していると、検索のためのコストも高く、多数の更新トランザクションを同時に実行することも困難となります。このような用途を効率的に処理するためにRDBMSのようなデータベースが存在し、高速な検索のためのインデックス機能や、トランザクションの排他制御などの機能を提供しています。 一方、Dune v2で採用しているようなSparkSQLやDuneSQLなどのSQL実行エンジンは、OLTPではなくOLAP（Online Analytical Processing）と呼ばれるデータ処理を想定して設計されています。さきほどの約1億人の戸籍データベースを例にすると、全人物の平均年齢を計算するような処理がOLAPで想定しているデータ処理です。このようなデータ処理は、もちろんPostgreSQLのようなRDBMSでも可能ではありますが、必ずしも効率的ではありません。そのため、RDBMSとは異なる方向性で最適化したソリューションが登場してきました。OLAP用途のデータ処理で広く採用されているアーキテクチャとして、「列指向」と「分散処理」が挙げられます。 ※2 Introducing Dune SQL: https://dune.com/blog/introducing-dune-sql 列指向アーキテクチャ 列指向とは、データの物理的な保持形式を、レコードのような行単位ではなく、属性値などの列単位とするアイデアです。代表的な実装として、Apache Parquetというオープンソースの列指向データファイル形式があります。 さきほどの戸籍データベースから全人物の平均年齢を計算するという処理の場合、あらかじめ各人物の年齢、もしくは生年月日を記録したデータだけを1箇所にまとめたデータフォーマットにしておいたほうが、ファイル読み込みの効率が良いでしょう。また、全人口が1億人強存在するデータベースであっても、年齢や生年月日といったデータのバリエーションは1億通りあるわけではなく、当然同じ年齢や同じ誕生年、誕生月の人物が大量に存在します。そのようなデータは一般的に圧縮効率がよいため、さらにデータの読み込み効率を上げることができます。Databricksの資料 ※3 によると、1 TBのCSVデータをParquet形式のデータに変換することで、データサイズが130 GBにまで削減でき、クエリの実行時間もCSVの場合に236秒だったものが、Parquetでは6.78秒にまで短縮されるというデータもあります。 ※3 Databricks – Parquetとは: https://www.databricks.com/jp/glossary/what-is-parquet 分散処理アーキテクチャ 大量のデータに対してOLAP型のデータ処理をおこなう場合、ボトルネックとなるのはデータ読み込み部分です。このボトルネックを解消するために、列指向と並んで用いられるアーキテクチャが分散処理です。例えば、読み込み性能が100MB/sのハードディスクに2TBのデータを保存した場合、そのデータすべて読み込むためには、単純計算で2万秒（約6時間）かかってしまいます。これを、100台のハードディスクにデータを100分割して同時に読み込むことができれば、読込み時間を100分の1に短縮できるのではないか、というのが分散処理の根源的なアイデアです。 ディスクIOを分散化するための代表的な分散ファイルシステムが、Apache Hadoopというプロジェクトのコア機能であるHDFS（Hadoop Distributed File System）です。このHDFS上のCSVファイルやParquetファイルに対してデータ処理をおこなう方法として、HadoopではMapReduceと呼ばれる分散処理のプログラミングモデルを提供していました。しかし、MapReduceモデルのプログラムをJavaなどのプログラミング言語で実装するのは、専門のスキルが必要であったため、そのハードルを下げるために、SQLのクエリ文を自動的にMapReduceのプログラムに変換するApache Hiveのようなプロジェクトが登場しました。さらにHiveの処理性能を向上させるソリューションとしてApache SparkのSparkSQLや、Trino（旧Presto）などが登場しました。Duneで採用しているDuneSQLは、このTrinoをベースにしています。 SQLの物理データ独立性 DuneのSQL実行エンジンが、PostgreSQLからSparkSQL、TrinoベースのDuneSQLに遷移していったように、データの増加やプロジェクトのフェーズ、技術の進歩といったさまざまな要因で、データの物理的な格納方法が劇的に変わることが想定されます。そのような物理層での変更があった場合でも、SQLをインターフェースとして分析ロジックを実装していれば、その影響は最小限に留めることができます。 もちろん、PostgreSQLやSparkSQL、DuneSQLの間でも、関数や予約語の微妙な違いや、対応している構文に差異があったりして、100%書き換えが必要ないというわけではありません。また、効率的なSQLを記載するためには、列指向や分散処理などの物理層のアーキテクチャを理解する必要がある場合もあります。しかし、物理層と分析ロジックが密に結合しているようなデータ分析環境は、多人数による共同管理や業務分担に支障をきたすことが多いでしょう。SQLを用いたデータ分析では、リレーショナルモデルをベースにした概念スキーマ層が暗黙的に存在し、物理層とアプリケーション層とのデータ独立性を保つことが容易となります。 ブロックチェーン上のオンチェーンデータや、その他ビッグデータの分析に興味を持たれた方は、ぜひ今後の連載を参考に、SQLを用いたビッグデータ分析に挑戦してみてください。 次回予告 ブロックチェーン上のオンチェーンデータを分析するための手法として、SQLを用いるメリットについて、リレーショナルモデルやSQL実行エンジンの考え方や歴史などから深掘りをしました。 次回の記事では、これまでも何度か登場してきたDuneが提供するイーサリアムのオンチェーンデータをサンプルとして、データ分析のためのSQL基本構文について解説していきます。 連載一覧 【第1回】：ブロックチェーンとは 【第2回】：ビットコインの仕組み 【第3回】：イーサリアムの仕組み 【第4回】：ビッグデータ分析のためのSQL基礎 The post 【第4回】ビッグデータ分析のためのSQL基礎 first appeared on Sqripts .

初めまして、テストエンジニアのやままいです。 テストスイートはテスト設計と密接に関わりのある要素です。しかし、テスト技法やレビュー等と異なり、”確立した手法があまり説明されていない”ように感じました。そこでテストスイートについて調べる過程で得た知見や私なりの考えをまとめようと思います。 この記事では、まずテストスイートの定義を再確認したあと、具体例を用いて実際にテストスイートの作成手順をご紹介します。それから作成したテストスイートをベースに「テストスイートのまとめ方」について考えていきたいと思います。 テストスイートとは まず、テストスイートについてJSTQB Foundation Levelシラバス（以下、JSTQB FLシラバスと記載）とISTQB_Glossary（以下、ISTQB用語集と記載）にどのように記載されているか見てみましょう。 （以下、JSTQB FLシラバスから抜粋） テスト手順や（存在する場合）自動化テストスクリプトからテストスイートを作成する。 効率的にテスト実行ができるように、テスト実行スケジュール内でテストスイートを調整する（5.2.4 節を参照）。 テストケースやテスト手順を作成（テスト手順は可能な限り自動化）し、テストスイートにまとめた後、テスト実行スケジュールを作成してテストを実行する順序を定義する。 ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 （以下、ISTQB用語集から抜粋） 特定のテストランで実行されるテストスクリプト、またはテスト手順のセット。 ISTQB Glossary つまりテストスイートとは、効率的にテスト実行ができるように 何らかのルールに沿ってテストケースをまとめたもの と定義できそうです。 では、テスト実行を効率化するテストスイートのまとめ方とは、どのようなものでしょうか？　ここからは具体例をもとに実際にテストスイートを作成しながら考えてみましょう。 実際にテストスイートをまとめてみる テストケースを洗い出す まず具体例として、会員用webページの簡単なテストを想定します。テスト対象の画面と要素を以下に記載します。 【A：ログイン画面】 「ログインボタン」と「その他の要素（入力フォーム含む）」を表示する 正常値（登録情報）を入力して「ログインボタン」を押下するとマイページ画面へ遷移する 不正値（空欄含む）を入力して「ログインボタン」を押下するとエラー画面へ遷移する 【B：エラー画面】 「戻るボタン」「その他レイアウト」を表示する 「戻るボタン」を押下するとログイン画面へ遷移する 【C：マイページ画面】 「ログアウトボタン」「その他レイアウト」を表示する 「ログアウトボタン」を押下するとログイン画面へ遷移する 上記の仕様をもとに状態遷移図を作成し、10個のテストケースを識別しました。 では、早速上記の10テストケースを、テスト実行の効率化を目標にまとめてみましょう。 確認内容でまとめてみる まず【Ver 1.0】では同じ確認内容で並び替えを行いました。同じ確認内容であれば、似たような確認手順になるのでテスト実行を効率化できるかもしれません。このテストスイートを上から順に確認していくと仮定して検証してみましょう。 実行順序（1）～（2）のテストケースは同じ画面なので効率良く確認ができそうです。ですが、実行順序（3）を実行しようとした場合、ログイン画面からエラー画面への遷移が発生しています。同様に実行順序（4）と（5）、（6）と（7）なども、テストケース終了時の画面が次のテストケースの開始画面と異なるため、余分な手順（下準備）が発生してしまいました。 では、さきほどの【Ver 1.0】に下準備の工程を追加してみましょう。 下準備を含めると、テストケース10個を確認するのに15回の手順が必要となっていることがわかります。これでは効率的とは言えません。逆に、下準備が必要ない構成にするほど効率的になると言えます。 次は、下準備を減らすために各テストケースの終了時の画面と、前提条件となる対象画面が揃うように並べ替えてみましょう。 終了時の画面と前提条件が一致するようにまとめてみる テストケース間の下準備が不要になり、10個のテストケースを10回の手順で完了できる構造にできました。ここで完成としても良いですが、更に同じテスト対象のテストケースを隣接させることで連続性を高めることができます。たとえば、実行順序（1）と（3）、（4）と（6）、（8）と（10）は、確認内容こそ異なりますが同じボタンを確認するテストケースです。同じテスト対象を隣接させることで前後のテストケースの連続性が高まりテスト実行がより効率的になるでしょう。それでは、同じテスト対象を確認するテストケースを隣接させてテストスイートを並べ替えてみます。 同じ要素が隣接するようにまとめてみる いかがでしょうか？ テストケース実行終了時の画面が次のテストケースの前提となる画面となり、確認する要素が隣接することで連続したテスト実行ができるテストスイートが完成しました。 テストスイートの目的である”テスト実行の効率化”を十分に達成できたと考えます。 テストスイートのまとめ方について考える テストケースを並べ替えることで実行順序を効率的にできました。ここで、ひとつの疑問を提示します。それは「”テストを早く実行できること＝効率が良い”なのか？」ということです。テストの目的は、テストケースを実行することでプロダクトの表示や動作を担保し、品質を保証することです。品質には様々な特性があり、どの品質を重視するかはプロジェクトやプロダクトにより異なります。 たとえば、「システム・ソフトウェア製品の品質モデル（JIS X 25010）」 ※1 の品質特性である「使用性」には、副特性として「ユーザインタフェース快美性」というものがあります。これはUIの美しさを表す特性で、一例として”画面間での要素デザインが統一されているか”といった観点が考えられます。プロジェクトが目指す品質としてテスト観点で追加するほどではない場合でも、担保できればユーザの満足度を高めることができそうです。この品質特性の不具合を見逃さないテストスイートを考えた場合、「表示確認」というテスト観点がまとまっている【Ver 1.0】のテストスイートの方がデザイン不一致に気づきやすく、該当する不具合検知の可能性を高めることができそうです。 他にも「保守性」の副特性である「解析性」を担保する場合、”ログイン成功時／失敗時のログ情報フォーマットが統一されているか”といったテスト観点が考えられます。こちらもテスト対象である「ログインボタン（正常値）」と「ログインボタン（不正値）」が隣接している【Ver 1.0】のテストスイートの方がログ情報フォーマットの比較がしやすそうです。 以上から【Ver 3.0】よりも【Ver 1.0】の方が”不具合検出という点で効率化されている”ことがわかりました。適切なテストスイートの作成を行うには、どのような効率を高めるかを明確にして作成することが重要だと言えそうです。 ※1　[ システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−システム及びソフトウェア品質モデル JIS X 25010：2013（kikakurui.com） ] まとめ テストスイートを適切に作成することでテスト実行手順を効率化できました。さらに、品質特性など何の効率を目的としているのかを意識すると、テストスイートの最適なまとめ方も変化することがわかりました。 今回紹介した以外にも、過去の不具合傾向やリスク、システムの実装状況など様々な要因で求める効率は変わってきます。また、状況によっては目的とする効率を達成する方法として、テストスイートで解決するのが最善なのかといった点にも注意する必要があるでしょう。 担当するプロジェクトやプロダクトの状況・性質・要件を適切に理解して、より良いテスト実装をするためにもテストスイートを上手く使いこなせるようにしていきたいですね。テストスイートを使いこなして、効率的で生産性の高いテストを作っていきましょう。 The post テストスイートって何？ テストケースのまとめ方を考える first appeared on Sqripts .

アジャイル開発とは変化するビジネス要件に素早く対応するためのソフトウェア開発手法です。この記事では、その重要な一部であるアジャイルテストについて詳しく説明します。 アジャイルテストとは？ アジャイルテストとは、アジャイル開発手法におけるテストのアプローチで、開発の早い段階から連続的かつ反復的にテストを行うことを重視します。開発サイクル全体に渡りテストが組み込まれ、フィードバックが素早く反映されることで品質の向上とリスクの軽減を図ります。また、テスターと開発者の協力を推奨する点も特徴の一つです。 アジャイル開発が普及した背景と課題 アジャイル開発の普及に至った背景には複数の要因があります。まず、1990年代後半から2000年代初頭にかけて、インターネットの普及によりネットベースのビジネスが急速に成長しました。これにより従来型のウォーターフォールモデルでは迅速な対応が難しいと認識されるようになりました。新しくなるビジネス要件への短時間での適応が求められ、変化に素早く対応できるソフトウェア開発手法の必要性が高まったのです。 また、従来のウォーターフォールモデルでは、リリースまでに長期間を要し、その期間中に市場環境や企業のビジネス戦略が変わってしまうケースが多く見られました。そうすると、結果としてリリース時点でのソフトウェアが既に古くなってしまい、想定していたビジネス価値を提供できないという問題が生じていました。これらがアジャイル開発手法の普及を後押ししました。 しかし、アジャイル開発が普及するにつれて、いくつかの新たな課題も浮かび上がってきました。従来のウォーターフォールモデルでは、テストは開発の最後の段階に位置していましたが、アジャイルでは開発とテストが連続的に行われます。 この状況では、「短いリリースサイクル」と「頻繁な変更」という二つの要素が互いに関係し合っていますが、同時にトレードオフの関係にあります。 「短いリリースサイクル」は、素早く製品や機能を顧客に提供できる利点がある反面、「頻繁な変更」は、開発チームに対する負荷となる可能性があります。変更が迅速であるため、テストや品質管理の適切な実施が難しくなる場合もあります。 また、迅速なリリースが求められる状況では、品質の低いコードや設計がリリースされることがあります。この問題は「技術的負債」と呼ばれ、長期的に見るとソフトウェアの品質や開発効率を低下させる要因となります。 これらの課題に対応するため、新たなアジャイルテストの手法が生まれ、普及しました。 アジャイルテストのメリット アジャイルテストは、アジャイル開発の特徴と共に、以下のようなメリットを提供します。 フィードバックの早さ アジャイルテストは開発サイクルの初期から行うため、テスト結果に基づくフィードバックが非常に早く提供されます。これにより、問題が発見された際の修正コストが大幅に削減でき、品質向上に貢献します。 高い適応性 アジャイルテストは、ビジネスの要件が変わった際に即座に対応することができます。テスト計画は継続的に更新され、プロジェクト目標に対する柔軟な適応が可能となります。 意思決定の迅速さ アジャイルテストでは、テスト結果に基づくデータ駆動型の意思決定が可能となります。これにより、品質の問題やリスクを迅速に認識し、必要な対応を計画することができます。 チームワークとコミュニケーションの改善 アジャイルテストは、開発者とテスターの協力を促す手法です。この方法を採用することで、コミュニケーションの改善が図られ、全体の開発プロセスが円滑に進むようになります。たとえば、テスターが開発サイクルの早い段階から関与することで、問題や要件に関する意見交換が促進されるなどの効果が期待できます。 問題の早期発見 アジャイルテストの手法と短い開発サイクルは、ソフトウェアの機能に問題がある場合に早い段階で見つけることが可能です。これにより、修正や改善のための追加作業を迅速に行うことができます。 以上のように、アジャイルテストは、開発プロセスの各段階で高い柔軟性と機能性を提供し、これに基づいた意思決定を可能にすることで、最終的な製品の品質を向上させることができます。 アジャイルテストのメリットの反面、以下のような気を付けないといけない点もあります。 繰り返し迅速なフィードバックを得ることができる反面、詳細なドキュメント作成が後回しになることが多く、新メンバーが参加した際に問題が生じる可能性がある アジャイル開発では頻繁にリリースが行われるため、適切なテスト自動化が求められるが、その導入や維持には手間やコストがかかる リリースや開発の反復期間が短いと、テスト設計と実行のための時間が削られ、テストカバレッジが十分でなくなることがある 新機能が頻繁に追加または変更される場合、テストの優先順位や範囲を決定することが難しくなることがある アジャイル開発では頻繁な変更に合わせてテストケースを随時更新する必要があり、これが作業の負担になることがある アジャイルテストとウォーターフォールテストとの比較 アジャイルテストとウォーターフォールテストは、開発とテストのプロセスに大きな違いがあります。 アジャイルテスト 連続的なフィードバック： アジャイルテストでは、開発とテストが交互に行われるため、コードの品質に関するフィードバックをすぐに受け取ることができます。これにより、バグや問題が早期に発見され、修正が容易になります。 変更への柔軟な対応： アジャイルテストでは、新たな要件や変更に対する柔軟な対応が可能です。アジャイルなアプローチでは、開発者とテスターが継続的にコミュニケーションを取りながら、テスト計画やテストケースを柔軟に更新していくことが重要です。これにより、変更に迅速に対応し、効果的かつ要求事項に適合した品質保証を実現することができます。 ユーザーフォーカス： 顧客のニーズやフィードバックを通じて、ユーザーストーリーや要件を明確にし、ユーザーが求める機能や改善を実現します。これにより、顧客との連携を強化し、より使いやすい製品を提供することが可能となります。 ウォーターフォールテスト 逐次的な進行： ウォーターフォール開発では、ソフトウェア開発プロセスが段階的に行われます。各フェーズ（要件定義、設計、開発、テストなど）は明確に区切られ、一つのフェーズが完了すると次のフェーズに進みます。 変更の難しさ： 一度開発が始まると、新たな要件や変更を取り入れるのは困難で、かつコストがかかる場合があります。 開発終盤でのテスト： テストは開発プロセスの終わり、あるいはリリース直前に行われるため、バグや問題が発見されても修正が難しくなる可能性があります。 総じて、アジャイルテストは変化の速い現代のソフトウェア開発に親和性が高く、ウォーターフォールテストは安定した要件と長期的な計画が可能なプロジェクトに適しています。 参考） 【第1回】アジャイル時代に求められる「品質」とは何か？ さまざまなアジャイルテストの手法 ここでは、広く普及しているアジャイルテストと親和性が高いアプローチをいくつかご紹介します。 DevOps DevOpsは開発（Dev）と運用（Ops）が連携して作業を行う考え方で、これにより開発からリリース、運用までのプロセスが連続的かつ無駄なく進められます。テストはこのサイクルの一部として自動化され、リリースの質と速度を上げる役割を果たします。 シフトレフト シフトレフトとは、「品質保証のためのテスト活動を可能な限り開発プロセスの早い段階に取り入れる」アプローチのことです。早い段階で問題点をフィードバックすることで、大きな手戻りや未然にバグを防ぐことを目指します。シフトレフトを適切に行うと、ソフトウェアの品質向上に繋がるだけでなく、全体のテスト時間を短縮し、コストを抑える効果も期待できます。 テスト駆動開発 テスト駆動開発（TDD）は、まず要件を満たすテストを作成し、それに合格するプロダクトコードを書いていくソフトウェア開発手法です。TDDには、品質の高いコードの生成と、バグの早期発見と修正を容易にするなどの利点があり、信頼性の高いソフトウェアの開発に貢献します。 探索的テスト 探索的テストは、テスターが自身の経験と直感に基づきテストを進める方法です。予定されていたテストケースに捉われず、リアルタイムでテスト設計と実行が行われます。これにより、従来のテストでは見逃されがちなバグを発見することが可能となります。 上記のアプローチは、ウォーターフォールテストにおいても活用することは可能ですが、アジャイルテストにおいては、より親和性が高いとされ、多くのプロジェクトで採用されています。 アジャイルテストの4象限 アジャイルテストの4象限は、特定のテスト活動がプロジェクトにおいて何を目指し、どのような視点で行うべきかを明示するフレームワークです。以下の4つの象限が存在します。 象限1 – （技術面・開発チーム支援に焦点） ユニットテストやコンポーネントテストなどのコードレベルのテストが含まれます。これらは主に開発者が行い、ソフトウェアの基本的な機能性と内部の品質を確認します。 象限2 – （ビジネス面・開発チーム支援に焦点） この象限には一般的に機能テスト（手動/自動）、ストーリーテスト、プロトタイプ作成などが含まれます。これはビジネスエキスパートが行い、システムがビジネス要件を適切に満たすかを判定します。 象限3 – （ビジネス面・プロダクト批評に焦点） ユーザー受け入れテスト（UAT）、探索的テスト、ユーザビリティテストなどが含まれます。これらのテストはエンドユーザーやステークホルダーが行うこともあり、システムがユーザーの期待に照らして適切に動作するかを評価します。 象限4 – （技術面・プロダクト批評に焦点） この象限ではパフォーマンス、負荷、セキュリティ、互換性などをテストします。これにより、システムの非機能的な側面を評価し、技術的な限界を確認します。 これらの象限は個別に役割を持ちながら、全体としてソフトウェアの内外の品質を総合的に確保する指標になります。そして、各象限のテストはソフトウェア開発ライフサイクルのそれぞれの部分で実行され、独立していても相互に関連し合っています。 重要なことは、これらの象限が階層的な順序を表すものではなく、すべての象限のテストが全体として協力してソフトウェアの品質を確保するということです。 自動化ツールによるアジャイルテストの効率化 アジャイルテストでは継続的なインテグレーションと高速なフィードバックが求められます。そのため、テストの自動化は、アジャイル開発において非常に重要な要素となります。 自動化による主な利点 速度と効率  テスト自動化ツールは、高頻度で繰り返されるテストケースを迅速に実行する機能を提供します。これにより、テストの実行に費やされる時間が大幅に短縮され、開発チームは早期にデバッグを開始できます。 一貫性と高い精度 自動化ツールはヒューマンエラーを排除し、テストケース間で結果の一貫性を保障します。 リグレッションテストの簡易化 新しいコードを追加または改修するたびに、全体のシステム動作に影響を与えることなく、変更が正しく統合されていることを確認するためには、頻繁にリグレッションテストを行う必要があります。このテストを効率的に実行するために、テストの自動化は有効です。 人気のある自動化ツール Selenium ウェブアプリケーションのテストに広く使用されるオープンソースのツールです。多言語対応しており、複数のブラウザでのテスト実行が可能です。 JUnit Javaで書かれたアプリケーション向けにユニットテストを作成、実行するためのフレームワークです。 TestNG JUnitから派生したテストフレームワークで、テストケースのグループ化、並列実行、テストケースの依存関係の定義など、高度な機能を提供します。 Cucumber BDD（ビヘイビア駆動開発）スタイルのテストを作成、実行するためのツールで、テストケースを自然言語に近い形式で書くことができます。 Jest JavaScriptのテストフレームワークで、スナップショットテスト、モック、統合されたアサーションライブラリなど、豊富な機能を備えています。 上記のようなツールの利用はアジャイルテストにおいて有効ではあるものの、全てのテストケースを自動化するべきだというわけではありません。テスト自動化はコストと時間を必要としますので、高頻度で繰り返し行われるテストや、人間による実行が困難または時間がかかるテストに対して優先的に自動化を検討すべきです。 アジャイル開発におけるテスト駆動開発とは テスト駆動開発（Test Driven Development：TDD）は、まずテストを作成し、それに合格するプロダクトコードを書いていくソフトウェア開発手法です。テストケースを先に作成することで、要件を明確にし、品質を担保しながら効率的な開発を行います。 TDDは以下の繰り返しプロセスで構成されます。 1.「Red」テストの作成 まず、失敗するテストケースを書くことから始めます。このテストはまだ実装されていない機能を対象とするため、初めて実行すると必ず失敗します。この工程は要件を明確に理解していることを確認するためのステップです。テストツールにおいてテストが失敗すると赤色でエラー表示されるため、「レッド」と呼ばれます。 2. 「Green」コードの実装 つぎに、テストを成功させるためのコードを書きます。ここで重要なのは、完璧なコードではなく、設定したテスト条件をクリアする「最小限」のコードを書くことです。 3. 「Refactor」コードの改善 コードがテストに合格したら、コードをリファクタリングして整理し、冗長性を排除します。コードのリファクタリングは、小規模な段階で行うべきです。後回しにすると、プログラムが大きくなるにつれて修正が難しくなります。 このTDDのサイクルは、コードあるいは機能の一部分を書くたびに繰り返されます。これにより、アプリケーション全体が組み上げられます。 TDDでは、開発の初期段階からテストに着目し、コーディングの品質を向上させることを目指します。テストファーストのアプローチによって、開発者は繰り返しコーディングとリファクタリングを行いながらテストを実行します。これにより、開発段階で不具合を早期に検知し修正することが容易になるだけでなく、システムを理解するための手掛かりを提供し、作業における安心感を高めることができます。TDDは近年の短サイクルの開発プロセスにおいて特に有効であり、コーディングの品質向上に貢献する重要な手法として広く認識されています。 参考） テスト駆動開発（TDD）への招待 まとめ アジャイルテストは、ソフトウェア開発プロセスの品質と効率性を改善する強力な手段です。現代のビジネス環境は絶えず変化し続けており、ソフトウェア開発においては柔軟に対応することが不可欠です。迅速なフィードバックを通して、顧客の要求に柔軟に対応するアジャイルテストは、このような状況下で非常に効果的なアプローチとなります。 また、開発チームとテストチームが協力し、テスト駆動開発やテスト自動化、探索的テストなどの先進的な手法を組み合わせることで、生産性や品質、顧客満足度の向上も期待できます。 この記事がアジャイルテスト導入のきっかけとなったり、チーム全体での実践を通じて品質向上と効率化を図る参考になれば幸いです。 The post ソフトウェア開発におけるアジャイルテストとは？ first appeared on Sqripts .

こんにちは！エンジニアのまさです。 最近、会社で利用するためのSlackBotを作成する機会がありました。時間をかけずに簡単に実装する方法を模索し、SlackBoltを利用することにしました。その結果、簡単にSlackBotを実装することができました。今回はその内容を紹介したいと思います。 はじめに Slackは、ビジネスチャットとして広く使われており、多くの企業で導入が進んでいると思います。私の会社でもSlackをコミュニケーションツールとして利用しています。 Slackはそのまま利用してももちろん便利ですが、Slackアプリケーションを作成することで更に便利にSlackを活用することが可能です。Slackアプリケーションの作成というとハードルが高いイメージがあるかもしれませんが、SlackBoltを利用することで、簡単にアプリケーションの作成をおこなうことができます。 Slackアプリケーションでできること Slackアプリケーションには多くの機能があります。以下は、その一例です。 チャットボットの作成 Slackアプリケーションを使用することで、簡単にチャットボットを作成することができます。チャットボットは、簡単なタスクの自動化や、情報の収集、ユーザーとの対話、など多くの用途に利用されます。 スケジュール管理 Slackアプリケーションを使用することで、スケジュールを管理することができます。例えば、チャットボットを使用して、会議のスケジュール調整を行うことができます。 ファイル共有 Slackアプリケーションを使用することで、ファイルの共有が簡単にできます。例えば、Google DriveやDropboxとの連携を行い、ファイルの共有を行うことができます。 通知の送信 Slackアプリケーションを使用することで、通知を送信することができます。例えば、重要なイベントが発生した場合に、Slack上で通知を行うことができます。また、チャットボットを使用して、自動的に通知を送信することもできます。 Slackアプリケーションを作成することで、Slackの利便性を更に高めることができます。 この記事では、特にチャットボットの作成について紹介します。 SlackBoltとは？ SlackBoltは、SlackのAPIを使用して、簡単にSlackアプリケーションを作成することができるフレームワークです。このフレームワークは、特にWebSocketを使用する場合に優れたパフォーマンスを発揮します。 SlackBoltを使うことで、Slackアプリケーションを簡単に開発できます。Slackアプリケーションは、ビジネスチャットとして広く使用され、多くの企業で導入されています。Slackアプリケーションを利用することで、Slackをより便利に活用できるだけでなく、ビジネスプロセスの改善や生産性向上にもつながります。 特に、WebSocketを使用する場合には、SlackBoltのパフォーマンスが優れています。WebSocketは、リアルタイム通信を実現するための技術であり、HTTPよりも高速で効率的です。SlackBoltは、WebSocketを使用して、SlackアプリケーションとSlackのリアルタイムAPIの間で通信を行います。WebSocketを使用することで、Slackアプリケーションは、Slack上のイベントに対してすばやく反応することができます。 この記事では、SlackBolt for PythonのWebSocketを使って、簡単にSlackアプリケーションを作成する方法について説明します。SlackBolt for Pythonのマニュアルは こちら から参照できます。 Slackアプリケーションの登録 まずは作成するSlackアプリケーションの登録を行います。Slackにログインした状態で こちらのページ(slack api) にアクセスし、ページ上部の「 Your Apps 」をクリックします。 アプリケーションの編集画面に遷移するので「 Create New App 」をクリックします。 作成するアプリケーションのタイプを選択します。シンプルにアプリケーションを作成する場合は「 From scratch 」、YAML等でmanifestを指定する場合は「 From an app manifest 」を選択します。 次にアプリケーション名の設定とこのアプリケーションを使用するWorkspaceを選択します。 項目を入力後「 Create App 」を押下することでアプリケーションの登録が完了します。 Slackアプリケーションの構成設定 Slackアプリケーションを作成すると下記の画面からアプリケーションに必要な情報の取得や設定が可能になります。 まずはチャットボットアプリケーションを作成するために必要な情報を取得するため、左サイドバーの「 OAuth & Permissions 」をクリックし、「 Bot Token Scopes 」セクションまで下にスクロールします。 「 Add an OAuth Scope 」をクリックし、「 chat:write 」というスコープを追加します。 スコープ追加後にページ最上部の「 Install App to Workspace 」をクリックします。 アプリケーションのインストールが完了するとOAuth&Permissions画面から「 Bot User OAuth Access Token 」を確認できるようになります。これは後で実際にアプリケーションを作成する際に必要になりますのでメモ等に保存しておきましょう。 「 Basic Information 」のページを開き、「 App-Level Tokens 」の「 Generate Token and Scopes 」をクリックしてトークンを作成します。このトークンに「 connections:write 」のスコープを追加します。ここで作成されたトークンも後ほどアプリケーションを作成する際に必要になりますので控えておいてください。 左サイドメニューの「 Socket Mode 」を選択し、「 Enable Socket Mode 」を有効にします。 ここまででアプリケーションの構成の設定は完了です。 チャットボットアプリケーションの実装 登録したアプリケーションの実体となるpythonアプリケーションを実装します。 WebSocketアプリケーションのクライアント実装となるので、インターネットに接続可能なPC上でpythonアプリケーション実装することで動作させることが可能です。サーバーアプリケーションではないのでドメインを取得したりする必要はありません。 アプリケーションの実装は以下のようになります。 import re import os from slack_bolt import App from slack_bolt.adapter.socket_mode import SocketModeHandler # BotTokenの設定 app = App(token=os.getenv("SLACK_BOT_TOKEN")) @app.message(re.compile(r"^!bot ((.|\\s)*)$")) def handle_message(message, say, context): # ユーザー名を取得 user = message['user'] # 会話メッセージを取得 talk = context["matches"][0] # メッセージを投稿 say(f"こんにちは! <@{user}>さん、あなたの会話内容は'" + talk + "'です") # アプリケーションの実行 if __name__ == "__main__": SocketModeHandler(app, os.getenv("SLACK_APP_TOKEN")).start() このプログラムを見ていただけるとわかるとおり、先ほどのSlackアプリケーション設定時に取得したトークンを2つ設定しています。 一つがOAuth&Permissions画面で取得した「 Bot User OAuth Access Token 」です。もう一つは「 Basic Information 」のページで取得した、「 App-Level Tokens 」になります。 プログラムを実行する際は環境変数「 SLACK_BOT_TOKEN 」に「 Bot User OAuth Access Token 」を、「 SLACK_APP_TOKEN 」に「 App-Level Tokens 」を設定します。 export **SLACK_BOT_TOKEN=xoxb-XXXXXXXXXXX export SLACK_APP_TOKEN=xapp-XXXXXXXXXXX** プログラムは以下のようにして起動します。 python app.py プログラム起動後、Slack側で登録したアプリケーションをチャンネルに追加します。 当該チャンネルで以下のようにメッセージを送信します。 !bot テストメッセージ このメッセージにボットが反応し「こんにちは！@XXXXXさん、あなたの会話内容は’テストメッセージ’です」とメッセージが投稿されます。 以上でSlackのチャットボットアプリケーションの実装は完了です！ おわりに いかがでしたでしょうか？ 今回のサンプルのチャットボットアプリケーションでは、ユーザーから受け取ったメッセージをそのまま返すだけでした。そのため、業務を大きく効率化するものではありませんでした。しかし、受け取ったメッセージから様々な処理を行うように調整することで、業務を効率化するアプリケーションを作成することが可能です。 実際に運用する際には、アプリケーションを起動しておくための環境が必要になると思います。しかし、サーバーアプリケーションではないため、環境の選択の幅が広がると思います。Slackを利用している方は、Slackアプリケーションの活用を検討してみることをおすすめします。 The post SlackBoltのWebSocketを使った簡単なSlackアプリケーション作成のススメ first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第7回目のテーマは、「スクラムチームメンバーの責任」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 スクラムマスターの責任 スクラムマスターのメインの仕事は支援です。 スクラムガイド を見ると、スクラムマスターが支援する内容がたくさん並んでいます。 ⾃⼰管理型で機能横断型のチームメンバーをコーチする スクラムチームが完成の定義を満たす価値の⾼いインクリメントの作成に集中できるよう⽀援する スクラムチームの進捗を妨げる障害物を排除するように働きかける すべてのスクラムイベントが開催され、ポジティブで⽣産的であり、タイムボックスの制限が守られるようにする これらはスクラムチームに対する支援内容の一覧です。これがPOや組織に対しても続きます。まずはPO。 効果的なプロダクトゴールの定義とプロダクトバックログ管理の⽅法を探すことを⽀援する 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう 複雑な環境での経験的なプロダクト計画の策定を⽀援する 必要に応じてステークホルダーとのコラボレーションを促進する 次に組織。 組織へのスクラムの導⼊を指導・トレーニング・コーチする 組織においてスクラムの実施⽅法を計画・助⾔する 複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう ステークホルダーとスクラムチームの間の障壁を取り除く やることがたくさんあるので、筆者が顧客に説明するときは、これらの動詞部分を並べて伝えます。 コーチする ⽀援する 働きかける 守られるようにする ⽀援する 理解してもらう ⽀援する 促進する 指導・トレーニング・コーチする 計画・助⾔する 理解・実施してもらう 取り除く このように、スクラムマスターは色んな方向でいろんな支援を行います。ただ、スクラムマスターは支援するだけなので、実務はスクラムチームがやります。 よって、スクラムマスターはチームができることはやらないけど、チームができないことをやるのが仕事といえます。 プロダクトオーナー責任 POの責任 プロダクトオーナーは、POと呼ばれます。POの責任を見ていきましょう。 まず、プロダクトゴールを策定し、明示的に伝えることです。プロダクト自体のゴールである、プロダクトゴールを策定し、開発チームやステークホルダーに明示的に伝えていきます。 現実の開発では、プロダクトゴールとは別に、プロダクトのロードマップであったり、プロダクトのマイルストーンのような中長期的な計画も作り上げていく必要があります。プロダクトオーナーは、短い期間であるスプリントだけでなく、プロダクト全体、四半期、半期、年次・・・というように高い視点を持つ必要があります。 次に、プロダクトバックログアイテムの作成、優先順位付けです。プロダクトバックログアイテムは、ユーザーストーリーと呼ばれる形になっていることが多いです。もしくは機能であったり、フィーチャとよばれることもあります。 プロダクトバックログアイテムは、ビジネス側の人間も関心があるものです。よって、そのビジネスの専門用語やドメイン知識が入り込んでいるかもしれません。もちろん、スクラムチームはそれらを学んでいきますが、開発するためには、だれでも理解できる言語や表現でまとめていく必要があります。 技術的な情報がプロダクトバックログアイテムの完成に必要になるかもしれません。その場合は、開発者に手伝ってもらいながら完成します。 プロダクトバックログアイテムを積み重ねていくと、プロダクトバックログになります。 プロダクトバックログの管理はPOのもっとも重要な役割とも言えます。これがきちんとできていなければ、間違ったものを、間違った優先順位で開発しなければなりません。 開発者の責任 最後に開発者の責任を見ていきましょう。 開発者はスプリントごとの計画の作成に責任を持ちます。計画はPOやスクラムマスターも交えながら作り上げていきます。開発者はスプリントバックログの作成に積極的にかかわります。スプリントバックログは、チーム全体で責任を持つものです。 次に、完成の定義を守ります。完成の定義は完了の定義とも呼ばれています。開発者は、なにかを完成させる上で「これが満たされれば完了」という基準を作り、その基準を厳守します。 そして、毎日計画を適応させ、スプリントごとのゴールであるスプリントゴールを目指します。適応はスクラムの三本柱にも登場しました。スプリントゴールとは、スプリントごとに立てるゴールです。ゴールがないと、スプリント自体が生み出す価値がぼやけてしまいます。このスプリントで何を成し遂げたいのか？スプリントゴールによって提供する価値の解像度を上げます。 最後はお互いに責任を持つことです。開発者とくくっていますが、スクラムチームにはフロントエンドエンジニアがいたり、バックエンドエンジニアがいたり、QAエンジニアがいたりするかもしれません。それぞれは得意分野が異なるため、異なる部分で責任を持ち合い、スプリントゴールを目指していきます。 スクラムチームが気をつけること スクラムチームは開発をするだけのチームではありません。 POはビジネスと開発の間に立つ通訳者だとしても、通訳だけしていればいいわけではありません。ビジネスや顧客が言うことすべてが正しいとは限らないため、さまざまなフィードバックをもとに、プロダクトとしての判断をしなければならないからです。 また、POと開発者は上下関係でもありません。 だから、開発者たちは「意味はわからないけどとりあえずこれ作ればいいのね」というように、いわれたことをやるマシーンになってはなりません。境界を超えてビジネスやプロダクトにも関心を持つ姿勢が必要です。これはビジネスやPOも同じです。 そして、何事もそうですが、正しさを目指してはいけません。 スクラムがいくら正しくできても、ビジネスやプロダクトがうまくいくとは限らないからです。スクラム、さらにいうとアジャイル開発はとても楽しい開発手法です。だから、大好きすぎて正しさを求め過ぎ、原理主義者に進化してしまう人も多くいます。 チーム内で熱量の差が生まれると、そこからメンバーの間にギャップが生まれてしまう可能性が高まります。熱意は双方向にぶつかって良い方向に向かうものです。熱量をきちんとうけとめ、消化できるチームを目指すといいでしょう。 そして、正しさを目指すよりも、自分たちが成し遂げたいゴールを達成できるかを考えるようになりましょう。 今回はスクラムチームの責任を解説しました。次回はスクラムイベントの具体的な実施方法を解説します。 連載一覧 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 The post 第7回 わかるようでわかりにくいスクラムチームの責任 first appeared on Sqripts .

こんにちは。テストオートメーションを担当しているWです。 気が付けば前回自分の担当した[ 記事 ]から約1年ぶりの投稿となりました。 今回は自動テストを実装する上でほぼ避けては通れないXPath/CSSセレクタについて、自動テストの安定性と絡めて話していきたいと思います。 はじめに 近年ではユーザの操作をレコーディングしてテストシナリオを作成できる自動テストツールが増えてきてテスト自動化の間口が広がっているのを感じます。 このような自動テストツールはコードが書けなくても自動テストを作成できることが最大の売りですが、万能という訳ではありません。 レコーディングできても実行時にうまく要素が識別できないということがよくあります。 そのような場合にはXPathやCSSセレクタで要素を指定するということが要求されます。 XPathやCSSセレクタを取得するだけならChromeの開発者ツールから簡単に行うことができますが、それをそのまま自動テストに使ってしまうと自動テストの安定性を著しく低下させることになるかもしれません。 本記事では自動テストでXPath/CSSセレクタを使用するときに気をつけるべき点について、自動テストの安定性の観点から検討していきたいと思います。 またそれに合わせて、XPath/CSSセレクタを取得する際に便利なツールの紹介も行います。 Chromeの開発者ツールによるXPathの取得 CSSセレクタについてはここで話をする範囲ではXPathと記載方法が異なるだけになるので、読み替えて確認していただければと思います。 ここでは例として、株式会社AGESTサイトのトップページの検索ボックスをXPathで指定することを考えたいと思います。 XPath自体はChromeの開発者ツールから以下のように簡単に取得することができます。 ブラウザ上のXPathを取得したい要素を右クリックをして「検証」を選択 開発者ツールでXPathを取得したい要素を右クリックして「コピー」→「XPathをコピー」を選択 上記の手順により検索ボックスのXPathを取得すると以下のような文字列が得られます。 //*[@id="wrapper"]/header/div/div[2]/div[2]/form/input このXPathで検索ボックスを指定できるのですが、XPathの書き方は何通りもあるため、これはその1つにすぎません。 XPathの詳細については他の様々なサイトで解説されているのでここでは全てを説明しませんが、自動テストの安定性という観点からこのXPathについて簡単に見ていきたいと思います。 XPathに含まれる / は階層構造を示す このXPathは7つの要素が / で繋がっているため、7つの要素の階層構造（下図の赤枠）を指定してテキストボックスを指定していることになります。 これを言い換えると、テキストボックス自体に変更が加えられていなくても、その手前の6階層の要素（下図の黄色枠）のどれかが変更されただけでテキストボックスが特定できなくなる可能性があります。 div[2] はその階層における2番目のdiv要素を示す このため、div要素の順番が変わってもテキストボックスが特定できなくなります。 これらのことから、このXPathを自動テストで使用すると自動テストの安定性が著しく低くなってしまう事が容易に想像できると思います。 安定性の高いXPathとは？ 先に述べたことを踏まえると、自動テストの安定性を高く保つには以下の点に気をつけてXPathを記述しなければなりません。 / を減らす（＝階層構造の指定を避ける） [n] を減らす（＝順番の指定を避ける） しかしながら、テスト自動化をやり始めたばかりでXPathについてあまり理解していない人がこのようなXPathを書くのは難しいと思います。 そこで、私も実際に使用している便利なXPath/CSSセレクタ自動生成ツールを紹介したいと思います。 POM Builder 私がお勧めするXPath/CSSセレクタ自動生成ツールは、[ POM Builder ]です。 これは、LogiGear社が提供するブラウザの拡張機能でChromeとEdgeに対応しています。 インストール方法（Chrome） [ POM Builder公式サイト ]へアクセス 「Add to Chrome」を選択 chromeウェブストアが開くので、「Chromeに追加」を選択 以下のポップアップが表示される場合は「拡張機能を追加」を選択 使用方法 ブラウザ上を右クリックをして「検証」を選択 「要素」内のタブから「POM Builder」を選択 この時、幅が狭いと折りたたまれているので「>>」をクリックして展開する 開発者ツール上でXPathを取得したい要素を選択する 上記の手順で任意の要素のXPathやCSSセレクタの取得が可能になります。 Recommended Locatorには最適なロケータを提示してくれるので、Selenium等でコードをガリガリ書く際にも有用です。 またLOCATOR TESTの欄にXPathやCSSセレクタを入力して検索をすると、そのページ内に該当する要素が何個あるのか表示してくれるので、自分でカスタマイズしたXPathの確認も行うことができます。 ここで株式会社AGESTサイトのトップページの検索ボックスのXPathをPOM Builderで取得してみましょう。 //input[@name='s'] どうでしょうか。 開発者ツールから取得したXPathと比べると、階層構造の指定や順番の指定が全く入っておらず、非常にすっきりとしたXPathが取得できました。 このXPathであればname属性の値さえ変えられない限りテキストボックスを検出することができます。 検索ボタンのXPathも比較してみましょう。 開発者ツール：//*[@id="wrapper"]/header/div/div[2]/div[2]/form/button POM Builder：//button[@class='search-submit'] こちらもPOM Builderによって生成されたXPathの方が階層や順番の指定がなく、自動テストの安定性が維持できるものとなっています。 もう一つ、ソリューション・サービス画面の「AQアジャイル品質/QA品質保証」セクションの要素を見てみましょう。 開発者ツール：//*[@id="qa"] POM Builder：//section[@id='qa'] これを自動テストの安定性という視点で考えてみると、どちらもIDの指定をしていますが、POM Builderはタグの種類もsectionに指定しています。 その点、開発者ツールのXPathはタグの種類については指定していません。 この要素についてはタグの種類を変更されても要素を特定できる開発者ツールのXPathの方が安定性が高いようです。 いくつかの要素について具体的にXPathを比較してみましたが、多くの場合においてPOM Builderが安定性の高いXPathを生成してくれることがわかったかと思います。 ただしPOM Builderも万能というわけではないので、開発者ツールとPOM BuilderのXPathを比較して、安定性の高い方を採用するというやり方がおすすめです。 まとめ 自動テストの安定性が高くなるXPathについて考察をしました。 安定性の高いXPath/CSSセレクタの自動生成ツールのPOM Builderを紹介しました。 POM Builderを使用して安定性の高いXPath/CSSセレクタを取得する方法について紹介しました。 自動テストの安定性を高めて、保守の負担が少ない自動テストライフを過ごしていきましょう！ The post 自動テストの安定性からXPath_CSSセレクタについて考える first appeared on Sqripts .

はじめに 前回 は2種類の振る舞い駆動開発（Behavior Driven Development、以下BDD）としてspecBDDとscenarioBDDについて紹介しました。 今回は、BDDと同じようにTDDの発展として語られる受け入れテスト駆動開発(Acceptance test–driven development、以下ATDD)や実例による仕様(Specification by Example、以下SbE)について説明します。 受け入れテスト駆動開発(ATDD) 受け入れテスト駆動開発(ATDD)は、書籍『 BDD in Action: Behavior-driven development for the whole software lifecycle 』によると、「Story Test-Driven Development」という呼び名で1990年後半から手法として存在していました。その後2003年に、Kent Beckが著書『 Test Driven Development: By Example （邦訳： テスト駆動開発 ）』の中で言及しています。この書籍の中では、「アプリケーションレベルのテスト駆動開発（ATDD:application test-driven development）」と紹介されていましたが、現在広く知られている「受け入れテスト駆動開発(Acceptance test–driven development)」とほぼ同じ概念と思われます。 ATDDは、Featureを実装する前に、Featureの受け入れ基準となる自動テストを作成する手法です。 ATDDとBDDの違い ATDDとBDDは関心ごとが違います。 ATDDは、受け入れ基準に注目し、 自動化すること に重きを置いています。ATDDについては書籍『 テスト駆動開発 』の付録Cに書かれているATDDのフィードバックループが分かりやすいです。この図を見ると分かる通り、失敗する受け入れテストを実装することが前提です。 図C.2 TDDにおける内側と外側のフィードバックループ （『 実践テスト駆動開発 』図1-2に基づき作成） なお、「失敗するユニットテストを書く→テストを通るようにする→リファクタリングする」というTDDに該当する内側のフィードバックループの部分（図の緑囲み部分）を「狭義のTDD」と呼び、「失敗する受け入れテストを書く→受け入れテストを通るようにする（狭義のTDDの部分）」というATDDに該当する外側のフィードバックループの部分も含めて「広義のTDD」と呼ぶことがあります（図の赤囲み部分）。 つまり、「TDDの考え方の対象が広がったものがATDDである」という捉え方です。 ※1 一方、BDDは実装できる（自動化する）ことが前提ではありません。 会話に重きを置き、共有言語(Shared Language)を増やしていくことを大切にしています。 結果として自動化したスクリプトを書くことができるかもしれませんが、自動化できなくても構わないと考えています。詳しくは、第4回（次回）以降の記事で書いていく予定です。 また、対象とする抽象度の幅にも違いがあります。ATDDはその名の通り、（特にユーザー視点での）受け入れレベルが対象です。一方、BDDは振る舞いに着目している限り、受け入れテストだけでなく、統合レベルでも活用することができます。 ※1 正確に言うと、広義のTDDこそが本来のTDDの思想でした。しかし、狭義のTDDの部分を「TDD」と考える人が多かったため、わざわざATDDという言葉を用いて表現することになったという経緯があります。 実例による仕様(SbE) 実例による仕様(SbE)は、 2002年にMartin Fowlerによって生み出された用語 です。 基本的には、その名の通り「実例を用いて仕様を表現しよう」というコンセプトです。 Gojko Adzicは 著書『Specification by Example: How Successful Teams Deliver the Right Software』 の執筆を通じて、要件の発見が重要であると強調したかったと思われます。 SbEとBDDの違い SbEとBDDは、現在の対象ドメインの状態のどの部分に対応するプラクティスなのかで違いがあります。（以下の表は Liz Keoghが定義した内容 を元に作成） BDDはLv.4やLv.5のように、 まだ明確な答えが誰も分かっておらず、模索していく段階 から効果を発揮します。 一方、SbEはLv.3のように、誰かが行っているが、それを 仕様として表現できていない段階 について注目しています。 違いは何となく分かったが… ここまででBDDとATDDとSbEの違いについて説明してきました。 しかし、現実世界において本当に使い分けて利用しているのでしょうか？ ここで、 Liz Keoghが2011年に自身のブログで書いた言葉 を紹介します。 BDDと広義のTDD（もしくはATDD）の違いは呼び方です。「BDD」という単語を用いる方が役立つ人もいれば、「TDD（もしくはATDD）」という単語を用いる方が役立つ人もいるというだけです。 Liz Keogh, lunivore Lizは、この言葉を書いた数年後に、本記事で紹介した「SbEとBDDの違い」の定義を言語化しています。 しかし最近では、ATDDとBDDの違いが少なくなっているかもしれません。ATDDを行っている人たちがBDDで大事にしている「会話」や「共有言語」も大切にしていますし、BDDを行っている人たちも自動化を疎かにしようとは思っていません。普段の業務の中で「ATDD」と呼んでいても「BDD」と呼んでいても、本連載に書いている考えを大切にして進めてもらえればと思います。 次回予告 今回はBDDとATDDとSbEの違いについて説明しました。 次回はBDDの考え方により焦点を当て、BDDで勘違いされやすい部分について説明します。 連載一覧 TDDとBDD/ATDD(1)　TDDはテスト手法ではない TDDとBDD/ATDD(2)　2種類のBDD TDDとBDD/ATDD(3)　BDDとATDDとSbE The post TDDとBDD/ATDD(3)　BDDとATDDとSbE first appeared on Sqripts .

こんにちは！QA事業本部所属、WEBコンテンツ制作者のくるみです。 今回はソフトウェアテストの知識が浅いWEBコンテンツ制作者が、JSTQB認定テスト技術者資格（Foundation Level）に合格したお話です。 動機 現在、私はWEBコンテンツ作成に従事していますが、今年の春の組織変更により所属としてはQA事業本部となりました。業務としては引き続きコンテンツ作成を担当していますが、今後テストエンジニアとしての社内研修の予定がありました。 そんな自分にとって未知の業務に対する不安を払拭するべく、その旨先輩に相談をしてみました。その先輩から「JSTQBの試験を受けるとスキルアップに繋がるよ」と後押しされ、意気揚々とCBT試験の申し込みを済ませたのでした。受験日は約1か月後…。 数ある体験談や勉強方法で検索すると「シラバス2018を一通り読んで合格できた」「1日2時間勉強すれば楽勝でした！」のようなお話が目につきます。たぶんそれを書かれている方は、もともとテスト業界の知識があったり、常日ごろ鍛錬されている方々かと思われるのです。 私はその体験談をうのみにして、約1か月の準備での受験を決意してしまったのです。浅はかでした。 受験対策と進め方 私が学習に使ったのはJSTQB（FL）教材と、「 AGEST Academy 」JSTQB対策講座。 ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応 ～世界トップレベルのテストエンジニアトレーニングプログラムの提供～ AGEST Academy 初めて手にする青い本「シラバス2018対応」。 1章付近までうんうんと読み進めていけるのですが、2章からだんだんと聞きなれない用語や単語に苦しめられます。「テストスイート」何それ？甘いの？そんな状態でまったく理解できず、そっと本を閉じます。 こんな時は、先輩に弱音を吐くとよきアドバイスがいただけます。今回も、 「AGEST Academy」 社内e-learing「JSTQB対策講座」 を受講してみたらどうだろうか。と、素敵なアドバイスをいただきました。もっと早く教えていただきたかった。 さてこちらのe-learing、要点がすっきりまとめられているので「シラバス2018対応」から入るより敷居が低いです。動画はわかりやすく、自然と新しい用語に慣れていきます。わかってくると面白いのでサクサクと学習が進みます。模擬テストもあるので、自分の理解度が図れます。「AGEST Academy」社外提供もされているようなので、興味のある方は一度、お問い合わせしてみてはいかがでしょうか。 AGEST Academy お問い合わせ 「AGEST Academy」をひと通り受講し講師陣のおっしゃる通り、基本である「シラバス2018対応」へ戻ります。不思議なことに内容をすんなり脳が受け付けます。要点のみならず、文章の細部まで抵抗がなくなっているのを感じました。 後は「シラバス2018対応」を基に、用語やプロセス、手法の目的、タイミング、特徴などをよく理解できるよう一覧化。ちょっとした空き時間でも確認できる便利資料となりました。 某動画サイトのJSTQB読み聞かせVerも、家事やウォーキング中に視聴、隙あらばJSTQBをねじ込む日々を送りました。 受験当日～結果発表まで やれることはやった、と受験当日。リラックスしてCBTにて試験に挑みます。先人達の「2択までは絞れる。しかし、それからが問題だ。」という言葉は本当でした。模擬テストなどでは、設問文や選択肢にヒントが隠れていたのですが、本番はさすがに隠れていません。1問90秒以内、後にどんな問題が控えているのかわからないので、迷いを払い粛々と画面を進めます。 あっという間の60分。なんとか最終問題までたどり着きましたが、ああ、今回はダメだ。次回頑張ろう、ケーキ食べて帰ろう…。と空しく画面を眺めて終了しました。が、それから約一週間後の朝8時、嬉しい知らせが入ります。 「JSTQB認定試験-試験結果のお知らせ」というタイトルのメールにて、合否がでたから確認してね、とのこと。まったく楽しくない気持ちでサイトを覗いたところ、そこには「合格」の2文字。思わず近くにいた方々にも確認していただきましたが、夢ではなく「合格」。パチパチパチ。おめでとう！と皆さんからの賞賛の声。じわじわと顔がにやけ、そのまま1日を過ごしたくるみなのでした。 まとめ　～合格までの道のり～ ◆「AGEST Academy」/某動画サイト視聴： ・耳からの情報取得、要点学習 ◆青本「シラバス2018対応」： ・通読する　⇒文章の端々まで読むことをおすすめします。 ・用語・単語集を作成する ・プロセスやタイミング、手法、特徴など抜粋し一覧化 ⇒一覧にしたことで理解度がUPしました。 ◆模擬テスト(AGEST Academy)： ・模擬テストで、CBTテスト形式に慣れ親しむ ・テスト実施後、解説を読む ⇒自身の理解度も図れますが、解説を読んで納得することも多々ありました。 模擬テストですが、もう少し「適用」問題が多ければよいなと思いました。 今回、私の場合は、「AGEST Academy」で耳から入る情報を取り掛かりとして進めましたが、やはりそこは個人差があるので、ご自分にあった学習方法で進めていかれたらよいと思います。 始めはつまずいても、理解できると面白いJSTQB（FL）。皆さんもチャレンジしてみてはいかがでしょうか。 The post 非テストエンジニア、JSTQB（FL）を受けてみた first appeared on Sqripts .

脆弱性診断とは 脆弱性診断とは、情報システムに存在するセキュリティホール（脆弱性）を見つけ出し、それを評価・報告する作業のことです。これにより、組織はそのシステムの防御策を強化し、潜在的な攻撃から身を守ることができます。 脆弱性診断の目的 脆弱性診断の目的は、セキュリティの脆弱性を発見し、そのリスクを把握することです。さらに、その情報を基にシステムのセキュリティ対策を計画・実行することが可能になります。 1. 脆弱性の発見 システムの脆弱性を特定することが、診断の主な目的です。脆弱性とは、悪意のある攻撃者がシステムを侵害したり情報を盗んだりするための入り口となる可能性がある部分です。これに対する防御策が不十分な場合、企業は機密データの漏洩やサービスの中断といった重大なリスクにさらされます。 2. リスクの評価 診断が明らかにする脆弱性それぞれには、それぞれ異なるリスクレベルがあります。そのため、診断の一環として重大性の評価も行われます。脆弱性の影響範囲や攻撃可能性などを考慮し、リスクを高、中、低のようにレベルに分類します。これにより、企業は最も緊急性の高い問題から対処することができます。 3. 対策計画の策定 最終的に、脆弱性診断は企業が自身のシステムにどのような対策を施すべきかを明確にするという目的があります。この対策は、短期的なもの（例 : パッチの適用）から長期的なもの（例 : セキュリティポリシーの見直し）まで幅広く、評価されたリスクレベルに応じて優先されます。 以上が脆弱性診断の主な目的となります。個々の脆弱性を発見し、リスクを評価・ランク付けすることで、企業は情報システムのセキュリティ強化に取り組むための具体的な手段を見つけることができます。 脆弱性診断の必要性 今日の情報システムは複雑で変化に富み、絶えず新たな脆弱性が発見されています。そのため、一度設定した防御策だけ頼りにするのではなく、定期的な脆弱性診断を行い、システムの最新の状態を確認することが求められます。 デジタルテクノロジーもまた日進月歩で進化し続けており、新しいハードウェアやソフトウェアは常に登場しています。これら新しいテクノロジーは新たな脆弱性をもたらす可能性があります。そのため、企業は定期的に診断を行って新たな情報システムの脆弱性を特定し、これらの新しいリスクを管理する必要があります。 そのうえ、サイバー攻撃者は新しい攻撃手法を開発するため、絶えず新たな脆弱性を探し求めています。一度設定した防御策だけに頼っていると、新しい攻撃手法によって企業のデータやシステムが侵害されるリスクがあります。脆弱性診断を定期的に行うことで、新たに生まれた脆弱性を把握し、適切な防御策を迅速に施すことが可能になります。 また、企業が業務で使用する情報システムは、個人情報保護法や金融業界の規制など、様々な法規制を遵守しなければなりません。これらの規制は企業が適切なセキュリティ対策を講じることを求めており、脆弱性診断はその一部となる場合があります。 つまり、脆弱性診断はテクノロジーの変化と共に進化するサイバー犯罪から身を守り、法規制を遵守するために不可欠な活動です。企業は定期的な脆弱性診断を行ってシステムの最新の状態を確認し、必要なセキュリティ対策を講じることが求められます。 ペネトレーションテストとの違い 脆弱性診断とペネトレーションテストは似ていますが、違いは次の通りです。脆弱性診断は情報システムの脆弱性を探すことに重きを置きますが、ペネトレーションテストはその脆弱性を利用して実際に侵入を試みることに重きを置きます。つまり、ペネトレーションテストは脆弱性診断を一歩進めたものと言えます。 脆弱性診断 目的：情報システムに存在する脆弱性を見つけ出すこと 結果：脆弱性リスト、その影響度、修正方法の推奨など ペネトレーションテスト 目的：脆弱性を利用してシステムを侵害することが可能なのかを確認すること 結果：システムに対する実際の攻撃の可能性、影響度、侵害した後のシステムの状況など つまり、脆弱性診断はあくまで情報システムの脆弱性の存在と可能性に焦点を当てたものであり、ペネトレーションテストはさらに深堀し、実際の攻撃がどの程度の影響を与えるかを評価します。 これにより、企業は既知及び未知の脆弱性に対する真のリスクを理解し、より適切な防御策と対応策を選択できます。 脆弱性診断の主な種類 脆弱性診断にはいくつかの種類があります。主なものは次の2つです。 Webアプリケーション診断 Webアプリケーション診断は、その複雑なロジックと数多くのユーザーインターフェースにより、特に脆弱性が発生しがちなWebアプリケーションが対象となります。この手法の主な特徴は以下の通りです。 テストスコープ Webアプリケーション診断は、Webアプリケーション全体におけるデータ入力、データ処理、そしてデータ出力で問題が生じる可能性があるすべてのポイントをチェックし、脆弱性の有無を診断します。 様々な脆弱性の探索 インジェクション攻撃、クロスサイトスクリプティング(XSS)、クロスサイトリクエストフォージェリ(CSRF)、不適切な認証・認可などの広範な脆弱性が検証対象となります。これらの脆弱性は情報流出、不正なシステム操作、サービス停止など重要なリスクを引き起こします。 プラットフォーム診断 プラットフォーム診断は、オペレーティングシステム、ミドルウェア、ネットワークなど基盤となるシステム上で動作する全体の環境を対象に行います。重要な特性は次の通りです。 複数のプラットフォームを対象とする プラットフォーム診断では主にOS（Windows、Linux、macOS等）、ミドルウェア（Webサーバー、データベース管理システム等）、ネットワーク機器（ルーターやスイッチ）などを対象とします。これらの各コンポーネントが正しく構成されているか、また更新漏れなどによる脆弱性がないかを確認します。 様々な脆弱性の探索 プラットフォーム診断は、不適切な設定、未パッチのソフトウェア、弱い認証メカニズムなど、幅広い種類の脆弱性を探します。これらの脆弱性は、盗聴、改ざん、システム停止といった、システム全体に影響を及ぼす可能性のあるリスクを引き起こします。 脆弱性対策の推奨 脆弱性が発見されれば、システム管理者への報告と併せて、適切な修正策や対処法を推奨します。これによりシステムやネットワークのセキュリティを全体的に向上させることが可能になります。 脆弱性診断の方法 脆弱性診断には2つの主な方法があります。 手動診断 手動診断は、専門家が直接システムを調査し、細かくチェックする方法です。これにより、自動診断では見つけ出せない脆弱性を発見することができます。 人間の専門家が直接システムを調べることで、その直感や経験が活きる点が大きな利点となります。彼らはパターンを理解し、異常な挙動を感知し、状況に応じて戦略を調整する能力を持っています。これにより、自動化ツールだけでは見落とすような脆弱性やリスクを見つけ出すことができます。 この特性から、手動診断は、システムやアプリケーションの深い理解を必要とする複雑なシナリオや、脅威ランドスケープが急速に変化している状況において、特に効果的な方法であると言えます。 ツール診断 ツール診断は自動化された診断方法で、脆弱性診断ツールを使用して危険性をスキャンします。これにより、大規模システムのような広範囲の環境でも効率的に脆弱性を検出することが可能です。ただし、ツールだけに依存すると一部の脆弱性を見逃す可能性もあるため、手動診断と併用することが推奨されます。これらの特性を以下に示します。 広範囲のシステムに対する診断 ツール診断は、大規模な環境でも効率的に診断を行うことが可能です。これは、自動化ツールが一度に多くのシステムをスキャンして脆弱性を特定するのに適しているからです。 高速・効率的な脆弱性スキャン 一般的に、自動化ツールは手動診断よりも速く結果を提供します。ツールは既知の脆弱性に対するシグネチャを活用し、それらを効率的に検出します。このため、時間の制約がある場合や頻繁に診断を実施する必要がある場合には特に有効です。 標準化されたレポーティング 自動化ツールは一般的に、組織規模の問題を容易に追跡、比較、管理できる標準化されたリポートを提供します。これは、トレンド分析や優先事項の特定、プログレスのトラッキングに有効です。 ツール依存の欠点 自動化ツールは多くの効果的な診断を提供できますが、それだけに依存すると問題が発生する可能性があります。自動ツールは主に既知の脆弱性に対して高い効率を発揮しますが、新しいものや複雑な攻撃手法に対するディテクション能力は限定的です。また、誤陽性（false positives）の結果を出す可能性もあります。 以上のように、ツール診断は適切に使用すれば非常に強力な手法となりますが、その限界を理解し、必要に応じて手動診断など他の方法と組み合わせることが重要です。 脆弱性診断の進め方 脆弱性診断を進める上での具体的な各ステップについて詳しく説明します。 以下のプロセスを通じて、継続的にシステムのセキュリティ状況を確認し、適切な対策を行って脆弱性を減らすことが目指されます。 １．計画 このフェーズでは、診断の目的と範囲を明確に定義します。対象とするシステムやアプリケーション、診断テストの手法（手動診断、ツール診断）および診断の日程などを決定します。全てのステークホルダーに計画を伝えることで、診断を円滑に進めるための協力を得ることができます。 ２．診断 目的と範囲に基づき、具体的な診断作業を開始します。手動方法であれば、専門家の知識と経験を活用して、ネットワークやシステムのセットアップ、設定、動作を詳細に調査します。ツール診断では、選定した自動化ツールを使用します。これらのツールは、大量の情報を迅速に分析し、可能な脆弱性を特定します。 ３．解析・評価 診断により見つけた可能な脆弱性を詳細に分析し評価します。この段階では、各脆弱性の重大性、攻撃が発生した場合の影響の程度、実際の脅威に対する評価などを行います。評価は企業のビジネス目標やリスク許容度により差異が出る場合があります。 ４．報告 各脆弱性について詳細かつわかりやすい報告書を作成します。各脆弱性の説明、その重大性、推奨される対策などを明記します。報告はハイレベルな管理者から技術的な詳細を必要とするIT部門まで、幅広い聴衆に適した形で提示する必要があります。 ５．対策 報告書で指定された対策を実施します。これは、ソフトウェアのパッチ適用、システム設定の改善、新しいセキュリティポリシーの導入など、見つけられた脆弱性によります。対策実施後は、再診断を行い、効果を確認します。 脆弱性診断サービスの活用と選定ポイント 脆弱性診断サービスの選定ポイントを下記に列挙します。これらのポイントを考慮することで、企業のニーズとリスク許容度に合った最適な脆弱性診断サービスを選択することが可能になります。 実績 サービスプロバイダの経験と成功事例は、その能力を判断する基本的な指標です。プロバイダが過去にどのようなプロジェクトを成功させてきたか、それらのプロジェクトがあなたの業界や要件とどう関連しているかを確認します。そのうえで、具体的な事例や参考情報、お客様のフィードバックを求めると良いでしょう。 手法 診断手法が手動診断とツール診断の両方をカバーしているかどうかを確認します。ツール診断は広範なスキャンを高速に行うため有効ですが、新たな脅威や特定のコンテキストに対応するためには手動診断の方が適しています。そのため、手動診断とツール診断のバランスが取れたサービスを選ぶと良いでしょう。 報告 診断サービスから提供される報告内容を考慮します。良い報告書は脆弱性の詳細とその影響をわかりやすく説明するだけでなく、それに対する具体的な対策の提案も含むべきです。そして、その報告が技術的な人々だけでなく、非技術的なステークホルダーに対しても理解しやすい形であることが重要です。 対応 診断後のフォローアップとサポートが提供されるかどうかを確認します。良いサービスプロバイダは、脆弱性の修正と追加的な診断に関するサポートを提供し、問題を完全に解決するための助けとなるはずです。また、継続的なセキュリティ管理と改善に対するアドバイスやサポートも提供する場合があります。 参考： サイバーセキュリティ診断（株式会社AGEST） まとめ セキュリティ対策は、情報システムが脆弱性に由来するリスクから身を守るために必要不可欠です。定期的な脆弱性診断を通じて脆弱性を把握し、優先順位をつけて対応することが重要です。そして、その診断は必ずしも自分たちだけで行わなければならないというわけではありません。専門的な知識が必要な場合や、内部リソースが不足している場合は、外部の脆弱性診断サービスの活用も有効です。 The post 脆弱性診断とは？その必要性や診断方法について first appeared on Sqripts .

前回まではシステムテストの自動化に用いるツールの選定方法について説明しました。 テスト自動化ツールを適切に選ぶことで、チームでの開発・テストが効果的に行えるようになるでしょう。 しかし、特定の開発チームだけの取り組みに留まらず、開発部門全体や会社全体の施策として普及・推進を求められる場合も。そこで今回と次回は、組織におけるテスト自動化の普及・推進について扱います。 前編となる本記事では「阻害要因と対策」として、テスト自動化や自動テストの活用を組織で広めていくうえでの阻害要因についていくつかのパターンを取り上げ、各要因に対してとるべき対策について解説します。 なお、本記事中の「テスト自動化」は前回までと同様、E2Eテストなどテスト対象のUI、とくに画面を操作しておこなうようなテストのことをターゲットとします。 テスト自動化に対して「組織」で取り組むのはなぜか ここで、今回のテーマである「普及と推進」について考えてみましょう。 ある開発チームでテストを自動化する場合、自分たちのテストが効果的に行えればそれでいいのでは、と思われるかもしれません。 たしかに、開発チームの中でテスト自動化を行いうまく回せている状態になれば、それはすばらしいことです。しかし、わたしが見てきたテスト自動化の導入事例においては、大きく分けて以下の2つのパターンで組織的な取り組みとしてのテスト自動化を求められる場合がありました。 パターン1．特定チームでの成功事例を横展開 1つは、ある開発チームでのテスト自動化で一定の成果が出た場合に、それを他の開発チームへと展開するように求められるパターンです。 テストを効果的におこなうことへの課題を抱えた開発チームはまだまだ多くあります。そうした状況において、「個別の取り組みの成功事例を他チームへと展開してほしい」とマネージャーや経営層から求められるのは、自然なことかと思います。 また、マネジメント層からの要請というトップダウンの形だけではなく、他チームから直接声がかかるボトムアップの形でも横展開につながる可能性があります。こちらも理由はさまざま考えられます。単純に成功事例を聞きつけて「自分たちも」となることもあれば、年度目標に「開発効率化」を掲げるもなかなかうまくいかず、1月くらいになって他チームのテスト自動化事例を取り入れてなんとか年度内に着手したパフォーマンスを・・・ということもあるかもしれません。 こうした組織内での要請があった場合、テスト自動化に成功したチームにおいて主体的に動いていた方が自然と「テスト自動化の推進役」としての動きを期待されます。 パターン2．開発部門や会社としてテスト自動化を目指す パターン1と異なり、部門や会社として「テスト自動化をやっていくぞ」という決定のもとでテスト自動化を推進するパターンもあります。パターン1のトップダウン型に近いですが、こちらは個別の部門やチームでの成功事例を元にするのではなく、最初から組織全体でテスト自動化が行われる状態をゴールとして開始します。 このパターンの場合、組織の中でテスト自動化の推進役を任命したり、特定の（もっとも反発がなく、うまくいきそうな）開発チームを選んで「やってみなさい」という指示が出たりします。 組織で取り組むことが、継続的な成功につながる いずれのパターンにも共通するのは、テスト自動化をおこなっているチーム・部門とおこなっていないチーム・部門が共存するのではなく「できるだけ皆やったほうがいい」という意識はある、という点です。 とくに、ITエンジニア全般の中途採用がなかなか進まないと言われている昨今においては、開発におけるさまざまな部分を少しでも効率化したいというのは自然な考えです。 しかし、この「テストを自動化して効率化したい」という共通認識がある状態にもかかわらず、なかなかテスト自動化がうまくいかない、組織の中で広がっていかないという声もよく聞かれます。このギャップはどこから生まれるのでしょうか。 それは「大事である」「やりたい」という気持ちに反し、組織として適切なフォローがなされていないから、というのがわたしの考えです。テスト自動化を個別のチームで軌道に乗せるところまでは、優秀なエンジニアの存在や、開発チームの皆の努力によって達成できます。しかし、問題はその先です。せっかくテスト自動化がうまくいきそうなチームがあったとしても、組織としてのフォローがなければ継続的な成功には至れません。まして、他チーム・他部署への横展開は困難になります。 補足：書籍や公開資料における、自動化普及の位置づけ 書籍や資料によっては、「組織にどう展開するか」を初期段階から検討することが、当然のように書いてあるものもあります。たとえば JSTQBのテスト自動化エンジニアシラバス や、書籍『 Experiences of Test Automation: Case Studies of Software Test Automation 』などです。これらの中には「パイロットプロジェクト」という言葉が出てきます。これは、組織におけるテスト自動化普及のため、最初に特定のプロジェクトでテスト自動化の導入をトライアル（パイロット）し、そこから他のプロジェクトに展開していくというものです。 組織面の阻害要因と対策 ここからは、実際に組織においてテスト自動化を進めていく上でよくぶつかりがちな壁、つまりテスト自動化の阻害要因とその対策について説明します。 これからテスト自動化を始める場合は、ぜひこれらの壁にぶつかる前に手を打つようにしてください。 体制、工数、予算などのリソースをかけられない 1つ目の阻害要因は、体制や工数、予算など、テスト自動化を進めるうえでのリソースが得られないことです。 これまで手動でおこなっていたテストを自動化しよう、と考えたときに、どうもその労力を少なく思われてしまう傾向にあるようです。 現場レベルでは、たとえばテストエンジニアに対して「テストの合間にやってよ」であったり、開発者に「案件の手が空いたときにちょっとやっておいてよ」などと依頼されることもあります。これらの「合間」「手が空いたとき」は、基本的には 永久に訪れない ため、テスト自動化はいつまでたっても進みません 上記の問題は、組織全体の認識あるいはマネージャーの指示として「テスト自動化よりも、開発や（手動での）テストなど普段の業務が優先」という共通認識が生まれているために起こってしまいます。 わたしがテスト自動化のコンサルテーションをおこなう際には、「システムテストの自動化は、既存のテスト対象システムと同規模の対向システムを構築するのと同じくらいの心構えが必要ですよ」と説明しています。必ずしも同等の規模になるわけではありませんが、そのくらい考えること・やることが多いと思って始めたほうが確実です。 そのため、主担当となる個人もしくはチームを任命してテスト自動化を推進することをオススメしています。 可能な限り 専任の担当者をアサインし、他業務との掛け持ちではなくテスト自動化業務のみをおこなってもらう 有料のツールを契約するだけの予算を確保しておく 専任の担当者以外にも、開発者やテストエンジニア・QAなどのステークホルダーに対して、担当者からのQ&A対応やヒアリング対応をする工数を確保しておく ことが大切です。 一方、専任をアサインすることの注意点もあります。それは、「＊＊さん（もしくは＊＊チーム）に任せればやってくれる」と思われてしまうことです。専任の担当者やチームはあくまでも推進役であり、最終的なテスト自動化の主体は各開発チームになる、ということを最初から周知したうえで進めていくのが安全です。 改善を良しとする文化がない、内部での抵抗がある 2つ目の阻害要因は、内部での反発に関するものです。 経営層やマネジメントレベルで「テストを自動化して効率化しよう」という点で合意ができても、メンバー層で同意が得られるとは限りません。これは、前述のパターン2、組織として「自動化をやる」という決定が先で現場に降りてきている場合に発生しがちです。 内部で抵抗・反発をされる理由も多々考えられますが、代表的なものは以下です。 大変である、かえって仕事が増える 仕事がなくなる これまでのやり方を変えたくない、新しいことを覚えたくはない テスト自動化が大変だ、やることが増える、という面もたしかにあるため、これらはテスト自動化の推進役やマネジメント層からていねいに説明する必要があります。とくにテスト自動化の導入初期においては、手動実行よりも工数が増えるという考えも一般的です。しかし、これは一時的なものであり、テスト自動化を導入して自分たちの仕事のやり方を変えていくことで、ゆくゆくは楽になるということを理解してもらわなければなりません。 一方、仕事がなくなる、これまでとやり方を変えたくない、といった反発に対処するのは大変なことです。これらはテスト自動化というよりも仕事に対するマインドセットや組織カルチャーの問題です。 こうした反発が個人であれば外れてもらうという選択もできますが、チーム単位でこうしたマインドになっている場合はそうはいきません。 対症療法的なやり方にはなりますが、まずは組織の中でアーリーアダプターにあたるチームや、新しいやり方や改善に対して能動的に取り組んでくれるチームを選び、そこからテスト自動化の導入を進めていくのがセオリーです。そこで成功事例を作り、だんだんと組織に浸透させていくことで、当初反発していたチームが「やらない」理由を減らしていくという作戦です。 期待値や目標設定が適切でない 3つめの阻害要因は、期待値や目標設定が適切ではない、つまり「期待しすぎる」というものです。 たとえば、 自動化率100% 大幅なコスト削減 テストを自動化すると新しいバグが見つかる などです。これらはテスト自動化に対する過剰な期待であり、こだわりすぎるとかえって時間やコストがかかったり、テスト自動化が止まってしまうこともあります。 マネージャーなど、テスト自動化の推進を指示する立場にある方は、まずは世のテスト自動化を知るところから始めてみてください。最近は書籍や企業ブログでの事例公開なども増えており、テスト自動化でつまづきがちなポイントや「大変さ」などの情報が手に入りやすくなっています。 一方、テスト自動化を推進する立場のQAエンジニア・テスト自動化エンジニアの側も、マネージャー含め周囲の適切な理解を得るための活動をする必要があります。こちらも、世の中に公開されている参考情報をまとめて説明することもひとつの手です。あるいは、過剰な期待をされていると感じた場合には「なるほど！では、OSSを使って一部の自動化をやってみますね！」と言って小規模なトライアルを行い、テスト自動化を行った結果の試算を提示するというやり方もあります。 テストを自動化する工数 既存のテストのうちどの程度を自動化できるのかの割合 それによってテスト実行がどの程度効率化されるのか テスト自動化に伴う追加のタスク などを試算して説明を行えば、期待値と実際とのギャップが伝わりやすくなるでしょう。 ※既存のテストケースをそのまま自動化するのはアンチパターンですが、ここでは説明材料を得るための手段としてあえて用いています。 よく言われるように「銀の弾丸はない」ことをていねいに説明することが大切です。 現場サイドから、正しい理解を広めていきましょう 今回は、組織内でテスト自動化を普及・推進するうえでの阻害要因とその対策について説明しました。 テスト自動化を継続的におこなっていくためには、個人や個々のチームの取り組みで留めるのではなく、組織全体として取り組むこと・適切な支援が必要です。 現場で普及・推進を担う担当者・担当チームからは、マネージャーをはじめ組織の中で適切な期待値設定とフォローが受けられるよう働きかけていくことが大切です。 こうした「理解を得て、推進していくこと」はテスト自動化に限った話ではなく、開発におけるさまざまな取り組みに共通する課題でもあります。専任の主担当をおくこと、適切な期待値・目標を設定すること、などは他の技術要素やプラクティスを広める際の考え方と通じるものです。 本記事の最後に、テスト自動化の普及・推進の参考になる情報源を載せてあります。こちらを見ていただきつつ、組織全体でテスト自動化に取り組んでいけるよう、活動してみてください。 参考情報 本記事の内容、とくに組織におけるテスト自動化の阻害要因への対策に関しては、わたしの実体験に加えて以下の書籍やサイトも参考にしています。 組織でテスト自動化を進めていくことになった、あるいは今困っている、という方はぜひ参考にしてください。 Test Automation Patterns テスト自動化におけるよいやり方や避けるべきことなどがまとまっているWikiです。本記事の内容は、とくにManagement IssuesやManagement Patternsに関連しています。 Experiences of Test Automation: Case Studies of Software Test Automation 古い本ではありますが、テスト自動化に関する多数の事例が掲載されています。 システムテスト自動化 標準ガイド (CodeZine BOOKS) テスト自動化についての考え方や期待値の設定については、こちらの書籍も参考になります。技術的な内容も含まれていて厚みがありますが、本記事にもっとも関係する「11章組織内へのツールの導入」だけでも読んでみてください。 Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン こちらはテスト自動化に関する書籍ではありません。しかし、なんらかの技術や考え方・取り組みを社内で普及・推進していくうえで参考になります。 連載一覧 テスト自動化ツールの選定【前編】～ツールの比較表をどう活用するか テスト自動化ツールの選定【後編】～AI自動テストツールを選ぶ時に気をつけるべきポイント The post テスト自動化の普及と推進【前編】～阻害要因と対策 first appeared on Sqripts .

こんにちは。QAエンジニアをしているうえやまです。現在、アジャイルQAとして日々業務を行っています。 7/25に開催された、「AGEST・Autifyの導入事例から考える、アジャイル開発に最適化したQA組織とテスト設計」にオンライン参加してきました。私自身アジャイル開発の現場で自動テストの作成に携わっていることもあり、内容をレポートしたいと思います。 セミナー概要 AGEST・Autifyの導入事例から考える、アジャイル開発に最適化したQA組織とテスト設計 普段様々な組織の品質保証部門の方とやり取りをしているAGESTとAutifyが実際に感じているトレンドの変化や、テスト自動化を軌道にのせる段階、のせた後にお客様が直面する課題やそれを克服した事例など、幅広くパネルディスカッション形式でお話しして下さいました。 テスト自動化プラットフォーム・Autifyの説明もあるので、興味がある方は一読ください。 【登壇者】 備後 宏美（びんご 　ひろみ）さん 株式会社AGEST QA事業本部 アドバンスドテストソリューション部 テストオートメーショングループ グループ長 堀 明子（ほり　めいこ）さん オーティファイ株式会社 カスタマーリライアビリティエンジニア テスト自動化を成功させるための３つのポイント AGESTのテストオートメーショングループ グループ長 備後さんが解説して下さいました。詳しい資料はSqriptsの以下からダウンロードできますが、ここでは学びになったことをかいつまんで記載します。 テスト自動化を成功させるための3つのポイント １．目的を正しく定めよう テスト自動化がもたらす効果が、設定されるべき正しい目的になる 目的は、その後のツールの選定やテスト範囲の選定にも影響を与える非常に重要なポイントになる 過度な期待は失敗のもとになるため、目的の優先度付けをする なんとなく自動化を始めてしまいそうですが、最初の目的設定が肝心ですね。 ２．ツールを正しく選ぼう まずはテスト対象で絞る →Webサイト、スマホネイティブアプリ、デスクトップアプリケーション　など 必要なスキルレベルを考える →長期的にメンテナンスしていくことを見据え、自社内で安定供給できるスキルレベルにあわせたツール選定を行う テスト対象、継続運用のための必要スキルで絞る 　→有償ツールやソフトウェアを使う場合、コストの見極めも必要になる。 膨大にあるツールの中からどのように最適なツールを選べば良いのか迷いますが、今後自動化ツールを選ぶ際の参考になりそうです。 ３．小さく適用しよう 最初に広範囲の自動化をゴールとするのではなく、小規模なゴール設定をして進めていく 一度運用にのせることで様々な課題が出てくるので、課題の優先度付けをして改善活動を進めていく（１サイクル目は課題抽出と割り切ってOK） まずは小さく運用してみることが、自動化の第一歩になるのですね。 Autifyの特長と説明 Autifyのカスタマーリライアビリティエンジニア 堀さんが実演しながら説明して下さいました。まずは３つの特徴として以下を挙げていました。 アジャイル開発のための、ソフトウェアテスト自動化プラットフォーム「Autify」 ノーコードで誰でも高速に自動テスト構築・運用できる AIが変化を検知　メンテナンスコストを削減 カスタマーサービスによる伴走 アプリが変化するとテストツールが追従できなくて落ちる、ということがありますがAIが変化を検知してくれるのは嬉しいですね。ビジュアル的な変化も検知し、前回の成功時との比較画像にハイライトが出るようです。AIの機能に関しては、今は詳しく言えないとのことですが今後リリースの新機能もあるとのこと。 また、Autifyで簡単にできることとして３つ挙げていました。 1.テストシナリオの作成 実演で見せていただきましたが、以下のような流れでした。 テストしたい画面を開く → レコーディングしながらケース化したい操作（クリック、入力など）を行う→ 期待値を登録する → 一連の操作がそのままテストケース化される ↓テストケース化されたもの テストシナリオは1行ずつ書いていくイメージでしたが、Autifyでは簡単な操作ならかなり短い時間でケース化出来そうです。 2.マルチOS/ブラウザテスト モバイルブラウザ含め複数環境で同じシナリオを回せるので、複数環境でのテストが必要なアプリにはとても便利な機能です。 3.テストシナリオ・結果の一元管理 ダッシュボードが簡単に作れるとのことで、開発や他のQAメンバーとテスト結果の傾向を分析するのに便利そうです。 実際のツール、エビデンスの出し方を見せて貰えると想像がつきやすく、Autifyの特徴を学べました。 実際に顧客と向き合っている中で感じるQA組織や開発組織の変化（コミュニケーション、テスト設計など） 最後に、登壇者のお二人がQA組織や開発組織の変化についてパネルディルカッションを行いました。質疑応答も含めたくさんのやりとりがありましたが、テーマに沿った一部を紹介します。 Ｑ．昨今アジャイルが増えているが、早い段階からQAが入れるようになったことによるテスト設計の変化は？ Ａ．「スプリントでは探索ベースのテストを行い、その中でリグレッション出来るものは自動化にし、小さく増やしていくと良さそう。最初から自動化を強いるのではなく確実に変わらないところを作ることが大事。浮いた時間を探索テストに充てることも出来る。」 Ｑ．自動化に向いているテストは？ Ａ．データ駆動で同じテストを何パターンか回すようなもの。必ず通るところや重要な機能から作っていく方が無駄になりにくい。開発と同様共通パーツを作って、メンテナンスしやすくすることが大切。 また、QAだけでなく開発含めたチーム全体で品質に対する責任を負うことが重要だと話されているのが印象的でした。様々な自動化導入事例を見てきた中で上手くいっているチームの特徴もそのようなチームが多いとのことで、開発・QA一体となってテスト自動化を進めることの大切さがわかりました。 まとめ 今回はアジャイル・自動化に特化した内容で、限られた時間の中でも学びの多いセミナーでした。自動化の運用において「多くの課題が出ることは当然で、課題の優先度付けをして改善活動を進めていけば良いだけ」という言葉から、課題に対して前向きな気持ちになれました。 また、「出来るだけ自動化したい」と「実装・メンテナスコストが掛かる」の間で自動化する範囲に悩むことは度々あるので、「データ駆動で回せるようなテスト」「必ず通すところや重要なところ」という基準を意識して今後自動化する範囲を考えていけたらと思います。 最後まで読んで頂き、ありがとうございました。 The post 「AGEST・Autifyの導入事例から考える、アジャイル開発に最適化したQA組織とテスト設計」参加レポート first appeared on Sqripts .

自動テストは自動化したからと言って必ずしも効率化できるわけではありません。 自動テストの理解が不十分であると効果のある自動テストの運用が続かず失敗に終わります。 実際の現場ではシナリオを実装した後に数回実行しただけで、「効果が得られない」「メンテナンスが追いつかない」などの問題に直面し、対策が打てず自動化を断念する現場が多く見られます。 これらの問題は導入前の検討が足りていないことが原因です。 自動テストの初心者が自動テストの経験や知識がない場合に、「取り敢えず自動化してみよう」と進めてみても、シナリオを作り切った運用段階に問題が発覚し、修正するには大きな工数がかかってしまい、自動化を断念することが多いです。 自動テストを成功させるためにはいくつもの失敗するポイントに対して事前に対策をとる必要がありますが、初見ではどこにどのようなリスクが潜んでいるかわかりません。 これらのリスクへの対応は自動テストのシナリオ作成から運用の一連の作業を成功させた経験があれば対応できます。成功経験があればどこにどのようなリスクが潜んでいるか分かるため、事前に対策を行うことができます。自動テストに失敗しないためには事前のリスクの潰しこみのための導入前の検討が重要です。導入前の検討によって１つ１つリスクを潰しこみし、自動テストを確実に成功させることができます。 自動テストの導入検討の内容は以下になります。 (1)目的と役割を決める (2)成功基準を決める (3)自動化するテスト内容を決める (4)テストケースの内容を分析する (5)評価対象のシステムを分析する (6)自動化ツールを選定する (1) 目的と役割を決める まず自動テストを始める際に決めることは「目的と役割を決める」です。ここが明確になっていなければ、自動テストをうまく進めることができません。 目的：テスト工数を削減し効率化 役割：デグレ確認（品質向上ではない） 自動テストは大きく効率化するものではなく、劇的に品質を上げるものでもありません。同じテストを何度も実行することでデグレ確認を効率化するものです。自動化すれば効率化できるということではありません。運用で何度も実行する自動化でなければ、実行する意味がありません。そのためには自動化する目的を明確にし、目的に合致したテストのみ自動化していくことが大事です。この目的と役割を達成することが終わりではありません。この後に何をするかが重要です。 「削減工数で追加試験を行い、総合的に品質を上げる」、「安定した品質のソフトを短期間にリリースする」などを行い、品質とスピードの両立を行うことが自動テストの本当の目的です。 やみくもに自動化することにならないよう目的と役割を明確にし方向性を持つことが必要です。 (2) 成功基準を決める 自動テストを進めるにあたり、成功の基準を導入前に決めます。 成功基準を決めずに進めてしまうことで、問題が発生しても問題と気づかず運用を続けてしまうことがあります。実施に現場で自動テストを導入した結果、ツールの選定や設計を間違えメンテナンスを行うには非効率な構造や半自動化など問題を抱えた状態で運用を進めても非効率になり続かない自動テストを行うことになります。 以下の例はシステムテストの自動テストを行う場合の成功基準になります。 導入前に基準を決めておくことでこの基準をクリアできる自動化プロセスの構築を目標にします。 30％以上の効率化/工数削減ができること 必要なテストが自動化できていること 実行途中で処理が止まらないこと 実行結果の誤判定がないこと 実行から結果確認まで自動化できること 共通関数などメンテナンス対策を行っていること 実行シナリオの維持管理（増減、変更）ができていること 実行の失敗から問題解決までの流れができていること こういった基準を作らず成り行きで進めた自動テストの成功は困難です。成功基準を作り基準をクリアできる自動化ツールの選定や自動化システムの設計や構築を行うための指標にします。 また導入後の振り返りでこの基準をクリアできたか検討するために使用するとよいです。 (3) 自動化するテスト内容を決める ここでは何の試験を自動化するかを検討します。何度も実施する価値があり、不具合出ると問題になる試験を自動化するべきです。以下は自動化するテスト内容の例です。 試験内容 試験詳細 基本動作 基本機能で不具合が出ては問題のため自動化することで確認する。 市場不具合 一度市場で発生した不具合は2回出すと問題のため確認する。 顧客/ユーザの要求の高い機能 安心/安全や顧客の要求の高い機能の確認を自動化し確認する。 ユーザがよく使う機能 よく使われる機能で不具合が出ると問題なので自動化し確認する。 新機能など注目の高い機能 新機能や法律に関する機能で不具合を出すと問題のため自動化する デグレが多い機能 開発期間でデグレが多い機能は自動化し確認する。 また似たテストを自動化することが無いよう優先順位を付けて必要なテストを絞り込むとよいです。 ここで実施するテストを定義しなければ、自動化しやすいテストを自動化するという方向に進んでしまいます。 必要のないテストを自動化しないためにも自動化するテストを明確にすることは必要です。 (4) テストケースの内容を分析する テストケースの前提条件、実施手順、期待結果が自動化シナリオを作成できる記載になっているか確認します。シナリオ作成はテストケースをプログラム化しますが、そのためには手順、設定値、期待結果が具体的になっていることが前提です。そのような記載になっていない場合はテストケースの修正を行う必要があります。 またテストケースの手順や期待結果などの記載が正しいか確認を行わなければ、シナリオ作成時のテスト実行時にエラーが発生すると「テストケースの記載ミス」「不具合」「シナリオ作成ミス」か原因追及に時間がかかります。そのためにもシナリオ作成前には1度テスト実施し、テストケースの記載に問題ないことを確認しておくべきです。 (5) 評価対象のシステムを分析する シナリオ作成時には評価対象を理解しておくと、必要な自動化ツールや自動化するべき品質か判断ができます。 ここで確認するのは以下の2点です。 評価対象の品質状況の調査 評価対象の仕様の理解 評価対象の品質状況を調査し自動化可能なテストか判断することが必要です。不具合が発生している機能は自動化を避け、不具合のない機能を自動化するべきです。メモリリークなどの不具合が発生している場合には長時間のシナリオの実行に影響するため自動テストの実行時に注意が必要です。 そもそも不具合が多いと自動化できないので品質が安定するまで自動化をするべきではないと判断できます。 また自動化シナリオ作成には評価対象の仕様を理解することは必須です。仕様を理解しておかなければシナリオ作成の方針が立てることができません。どのような自動化ツールを選ぶべきか判断することもできません。 この際に評価対象の調査だけでなく評価に使用するツールもあれば同様に調査が必要です。 (6) 自動化ツールを選定する これまで検討してきた内容を踏まえて自動化ツールを選定していきます。 自動化の目的、成功基準などから自動テストの方針に合わせた自動化ツールであるか確認します。 自動テストの目的や評価対象、評価内容に合致し成功基準をクリアできる自動化ツールを選定します。 選定する際の確認ポイントの例は以下になります。 テスト対象の機能の自動化ができること 自動化対象のテスト項目の「前提条件の設定」「手順の実行」「期待結果の確認」の自動化ができること 共通関数の作成ができること エクセルやテキストファイルの操作ができること クロスブラウザができること Windowsコマンドの実行ができること データ駆動型の自動化ができること こういった検討を行わず、最初に自動化ツールを選んでしまうとその自動化ツールで自動化できる範囲しか自動化することができず、自動化するテスト内容が限定されてしまいます。 その結果、必要なテストを自動化できず、運用段階で実行する価値のない自動化をしていることに気づき、自動化断念となってしまうことがあります。 また期待結果の確認ができないなど機能が不十分な自動化ツールを選んでしまうと実行結果を手動でログを確認するなど人間の手を入れる必要が発生するなど半自動化となってしまい、非効率になり自動化しているメリットが無くなります。そういった失敗にならないよう検討するべき内容を調査したうえで自動化ツールの選定を行わなければなりません。 当社のプロダクトであるTestArchitectでは上記の確認ポイントは一通り実現可能になります。 まとめ 自動テストの導入検討は自動化できるかどうかの検討を行うものではなく、効果的な運用を検討するものです。検討すべき内容を確認することでリスクを軽減した自動テストが可能になり、自動テストのゴールが明確になり、成功に近づけることができます。 自動テストの成功は導入検討で決まるといっても過言ではありません。導入検討にはスキルや経験が必要で簡単にいくものではありません。 AGESTではこれらの導入検討を導入支援サービスの中で実施しており、お客様の課題に合わせた最適なソリューションをご提供いたします。 The post 【第1回】自動テストはなぜ失敗するのか？ first appeared on Sqripts .

こんにちは。性能テストグループのけんです。この記事では私が主に担当している性能テストについて、引き続き共有していきます。 前回の投稿 では対象シナリオについて説明しました。 今回は、対象シナリオを使用してどのように負荷をかけるのかを説明していきたいと思います。 ＜ 性能テストのススメ 過去記事 ＞ #1 性能テストの目的と種類 #2 テスト計画 #3 対象シナリオ（運用プロファイル） テストパターン ISTQBのシラバスには性能テストの主要な活動として以下の項目が定義されています。今回のスコープは テスト計画 、 テスト分析 、 テスト設計 になります。 参考文献： 「ISTQB テスト技術者資格制度 Foundation Level Specialist シラバス 性能テスト担当者 Version 2018.J01」 テストパターンとは 「ロードプロファイル」というものがISTQBのシラバスで以下の通り定義されています。 ロードプロファイルは、本番でテスト対象のコンポーネントやシステムにて行うと思われる動作を仕様化するものである。 ロードプロファイルは、指定した数のインスタンスで構成される。 インスタンスは、特定の期間にわたり、定義済みの運用プロファイルのアクションを行う。 インスタンスがユーザーである場合、「仮想ユーザー」という用語を一般的に適用する。 難解ですが、ざっくりと要約すると「負荷のかけ方」を具体的に仕様化したものがロードプロファイルということになります。当社ではロードプロファイルのことを「テストパターン」と定義しており、基本的には「 テストパターンの数 ＝ テストの実行回数 」として提示しています（再実施や繰り返し実施分は除く）。 テストの目的を明確に テストパターンを定義するためには、まずテストの目的が明確になっていることが前提となります。そして、その目的に応じたテストの種類を紹介します。 以上が、テストパターンの定義において考慮すべきテストの目的と種類の一覧です。詳しい情報については、過去記事「 #1 性能テストの目的と種 」でより詳細に説明していますので、ぜひご確認ください。 目的が明確になることで、適切なテストの種類を選定できます。そして、テストの種類が決まることで、負荷をどのようにかけるべきかが大まかに決まります。その後、具体的なテストパターンを定義していくことになります。要約すると以下の様になります。 目的を明確化 ↓ テスト種類を決定 ↓ テストパターンを定義 テストパターンの構成要素 テストパターンを構成する要素には以下の4つがあります。 これらの要素をそれぞれ決定してテストパターンを作成します。それぞれの構成要素について説明していきます。 1. 対象シナリオ 対象シナリオ（運用プロファイル）についての説明は 前回の記事 をご確認ください。ここでは決定済みの対象シナリオをどの様に使用して負荷をかけるかを検討します。大きく２つに分類すると「シナリオ単体」と「シナリオ複合」があります。 シナリオ単体 対象シナリオを単体で負荷をかけて実行します。対象シナリオが複数ある場合、シナリオ単位での性能を一つずつ確認することでボトルネックを特定しやすくなります。対象シナリオが複数ある場合はその数の分だけテストパターン数が増えます。それによってテスト実施回数と作業工数が増加するため、必要に応じてシナリオ単体でのテスト対象を選別してください。 シナリオ複合 複数の対象シナリオを同時に負荷をかけて実行します。より運用想定に近い負荷を設定することで、テスト結果の信頼性が高くなります。シナリオ単体と比較するとテストパターン数が少なくなるため、テスト実施回数と作業工数は少なくなりますが、ボトルネックの特定が難しくなります。 シナリオ単体とシナリオ複合の特性 シナリオ単体とシナリオ複合の特性を以下の表にまとめました。 ※ 対象シナリオの数に比例して増減 基本的にはシナリオ単体を実施し、問題なければシナリオ複合を実施することが望ましいです。ただし、限られた作業時間で実施する場合、最終的にシナリオ複合で合格しないといけないことから、始めから最後までシナリオ複合のみを実施するケースが多いのが実情です。 シナリオ複合の検討事項 シナリオ複合の場合、さらに検討すべきことがあります。それは「対象シナリオの選定」と「シナリオ毎の負荷量」です。 対象シナリオの選定 通常は全てのシナリオを複合して実行しますが、運用上におけるユースケースを考慮すると同時に発生しないシナリオがあるため、これらは別々に実施する必要があります。例えば、朝の出勤ラッシュ想定における出勤処理や退勤ラッシュ想定における退勤処理などです。 シナリオ毎の負荷量 対象シナリオ毎にそれぞれ負荷量を設定する必要があります。負荷量は「個別」に設定する場合と「実行比率」で設定する場合があります。各リクエストの負荷量が明確となるデータまたは資料が存在する場合は、データ通りの負荷量を「個別」に設定します。ユーザーアクセス数のデータは存在するけどリクエスト単位では不明確な場合等は、シナリオ毎の「実行比率」を検討した上で負荷量を設定します。 2. Ramp-Up期間・Ramp-Dowm期間 当社ではJMeterの設定に倣って「Ramp-Up期間・Ramp-Dowm期間」で記載していますが、 ISTQBのシラバスでは「ランプアップ・ランプダウン」と記載されており、以下の通り説明しています。 ランプアップ：段階的に負荷を高めていくこと ランプダウン：段階的に負荷を下げること Ramp-Up期間 では何のために設定するのかの説明ですが、ISTQBのシラバスではRamp-Up期間について以下の説明があります。 ランプアップにおいては、負荷状態を段階的に変化させて、着実に増加する負荷がシステムの応答に与える影響をモニタリングすることが望ましい。 これにより、ランプアップに十分な時間が割り当てられていること、システムが負荷を処理できることを確認できる。 いきなり大量の負荷をかけて「うまくいきませんでした」と言われても、それはそうでしょうとしか言いようがありません。負荷を徐々に上昇させることで、どのタイミングで性能が落ちるかを確認しましょう、ということですね。また、Ramp-Up期間を設定しない場合、全てのスレッドの最初のリクエストが時間のずれなしで同時に実行されるため、非常に負荷が高くなります。この瞬間的な負荷を分散させるためにRamp-Up期間を設定する必要があり、基本的に当社では必ず設定しています。 稀に、瞬間的かつ同時の実行を確認したい！シナリオのループは不要！というご要望があります。こちら当社で対応はしていますが、運用想定の負荷か？という観点ではあまり現実的ではないことと、初回アクセス時のリクエストのみのデータを元に出した統計が応答性能の評価としては適切とはならないことから、なるべく負荷テストを別途で実施することを推奨しています。 Ramp-Down期間 Ramp-Down期間を何のために設定するのかは、残念ながらISTQBのシラバスには記載されていません。当社で主にRamp-Down期間を設定するケースは、突然のピーク負荷から定常状態に戻るまでの一連の性能を確認するテスト、つまりスパイクテストの実施時になります。特に、システムがオートスケール構成の場合、スケールアウトしたコンポーネントが負荷の減少によって適切にスケールインするか確認するためにRamp-Down期間を設定することがあります。 3. 負荷継続時間 「負荷継続時間」という用語はISTQBのシラバスにはありません。当社では「一定のスレッド数で負荷を継続させる時間」を負荷継続時間と定義しています。 負荷継続時間の長さはテストの目的によって設定します。もちろん設定しない場合もあります。 4. 負荷量 負荷量とは、システムに負荷を生成するために設定するための量のことで、 スレッド数 か スループット 、または その両方 で定義する場合があります。 スレッド数 当社ではスレッド数について以下の通り定義しています。 「 対象シナリオを同時に並列で実行する数です。同時に接続するユーザー数に相当します。 」 因みにISTQBのシラバスには「コンカレンシー」というものが以下の通り定義されていますが、「コンカレンシー ＝ 同時/並列に実行されるスレッド数」と解釈してよさそうです。 コンカレンシーとは、同時/並列に実行されるスレッドの数を示す尺度である。 システムとのやりとりでは、同時/並列ユーザーの数を表すこともある。 ここで注意したいのはスレッド数は同時かつ並列で実行されるユーザー数を表すものであり、実行される総ユーザー数とは異なる点です。例えば、以下の図のパターン1では生成するスレッド数は1つですが、1ループ目をユーザーAで実行し、2ループ目をユーザーBで実行しているため、1スレッドで2ユーザー実行したことになり、1スレッド＝1ユーザーとはなりません。 パターン2は「スレッド数＝ユーザー数」となりますが、パターン1と比較すると負荷量は2倍になります。 同じユーザー数でもスレッド数の定義方法によって負荷量が変動するので、より運用想定に近い負荷量でテストしたい場合はスループットを確認すべきです。 スループット スループットについて、ISTQBのシラバスでは「システムスループット」と定義されており、以下の説明があります。 システムスループットとは、単位時間内にシステムが処理する特定のタイプのトランザクション数を示す尺度である。 例えば、1時間あたりの注文数や、1秒あたりのHTTPリクエスト数などである。 システムスループットは、ネットワーク上を移動するデータ量であるネットワークスループットとは区別する必要がある 一般的に使用される「ネットワークスループット」とは別であるということがわかります。性能テストにおいては「システムスループット」の使用頻度が高いため、当社では「 システムスループット ＝ スループット 」として定義しています。スループットは「 計測対象の実行回数 / 時間範囲 」で表され、実行回数と時間範囲の単位は要件によって異なります。 スループットの単位 スループットの単位には以下があります。 ※ スループットの単位とは違うかもしれませんが、参考値としてよく検討されるデータなので紹介しています 表に記載の 単位 について、一度定義した上で説明しておけば後からの説明が楽なのですが、馴染みがない方だと認識齟齬が発生する可能性があるため、当社では表の 定義例 の通り「100リクエスト/秒」の様に表記しています。また、要件によっては「1,000ログイン/3分」や「50,000回シナリオ実行/10分」などの場合もあるので、全てにおいて対応可能な表記はやはり「 計測対象の実行回数 / 時間範囲 」となります。 スループットの時間範囲 スループットの時間範囲はできる限り短い範囲で定義することが望ましいです。例として10万DAU（100,000ユーザー/日）というアクセスログがあった場合、1分間あたりで計算すると「100,000ユーザー / 24時間 / 60分 ＝ 69.44ユーザー/分」となるのでこれで負荷をかければいいよね…とはなりません。 なぜならシステムにアクセスが集中する時間帯とそうではない時間帯があるからです。例えば以下の表では一日の総ユーザー数は10万ですが、20時に2万ユーザーのピークアクセスあるので「20,000ユーザー/1時間」の負荷量でテストをすべきと考えます。これを分間スループットにすると「333.33ユーザー/分」となり、先ほど算出した「69.44ユーザー/分」から見ると5倍近い負荷量となりました。 さらに言うと、1時間の中でも波があるので、より詳細なデータがあればそれに合わせたスループットを定義してください。 単位の粒度 は、以下の様に細かい方がより良いです。 データがない場合 新規サービスの新規稼働など、アクセス量のデータが存在しないこともあると思います。その場合は現状で取得可能な粒度の粗いデータから予測値を概算することになりますが、最終手段として 負荷倍率をかける 方法があります。先ほどの例で負荷量を5倍にすると「100,000ユーザー / 24時間 / 60分 * 負荷倍率5倍 ＝ 347.22ユーザー/分」となり、おおよそ近いものになります。ですがそもそも負荷倍率を何倍かけるかというのはテスト対象のシステムがどの様な使われ方をするのかで大きく変わってくるため、一概に何倍すればよいという規定はありません。そのため、予測値から検討する場合はどうしても最終的にはこの負荷倍率でいこう！という「決め」が必要となります。 ここで気を付けたいのは、決めた負荷倍率で性能テストを実施しても、運用開始してからのアクセス数の実績データとはどうしても乖離が出るため、後になって実施した性能テストの妥当性について問題となる可能性があることです。これを回避するため、できる限り高い負荷倍率をかけるという力技で解決できればいいですが、負荷をかける側と受け側（対象システム）共に費用面の兼ね合いが発生します。 個人的に最も大切と考えるのは、決定権あるいは責任を持つ方にテストを検討・決定した内容をしっかりと伝えてリスクを認識してもらうことです。これによって、テスト実施時よりも遥かに高い負荷が発生した場合の対策を検討するというタスクが発生するはずです。 対策が決定していれば、万が一に備えた上での運用を開始できるはずです。アクセス量のデータが存在しないときに負荷量を決定するためのポイントを以下にまとめました。 ・ 想定の負荷量を可能な限り予測して検討 ・ 検討結果に負荷倍率をかける（コストが許せば負荷倍率を上げる） ・ 実運用時との負荷量の乖離によるリスクの報告 ・ 想定以上の負荷が発生した場合の対策を決定 参考図 Ramp-Up期間・Ramp-Dowm期間、負荷継続時間、負荷量の相関図については、過去記事「 #1 性能テストの目的と種類 」の 負荷のかけ方 をご確認ください。 さいごに テストパターン（ロードプロファイル）について駆け足で説明したのですが、かなりの長文となってしまいました。それでもスループットやスレッド数についてはまだまだ説明が不足しているので、引き続き連載を続けていきたいと考えています。 次回記事もどうぞよろしくお願いいたします。 【連載】性能テストのススメはこちら The post 性能テストのススメ #4 テストパターン（ロードプロファイル）第一章_構成要素 first appeared on Sqripts .