みなさん、こんにちは！　QA事業本部のゆーすけです。 連載形式でJSTQB FLの解説をしており、第6回連載ではテスト技法の途中まで書かせていただきました。 今回テスト技法の続き、、と見せかけて、2023年4月にISTQB FLシラバスのメジャーバージョンが4.0にあがったので、こちらについてちょっと触れていきたいと思います。 ISTQB CTFL Syllabus v4.0 Certified Tester Foundation Level (CTFL) v4.0 [NEW!] こちらはまだJSTQBによる日本語訳は出ていないので、現在はISTQBの英語版のみの提供となります。 Version2018時のリリース時系列を見る限りは、ISTQB→JSTQBリリースまで半年程度になっていますので、2023年の下期にはJSTQBからリリースされるのではないかと思います。 そしてJSTQB FL資格への適用は21年2月（当時はPBT）からとなっていますので、現在行っているFL CBT試験の内容の3.1→4.0適用は1年近く先のことになるかもしれません。 とはいえ、学習してほしい内容の指針が変更→ベースとして求められる知識幅の変更になっているので、直近でFL資格取得を考えている人、既にFLを取得している人含め、全てのISTQB/JSTQB学習者は是非把握しておくべき内容だとは思います。 以下、有識者の見解および機械翻訳をベースで大きな変更点について触れていきたいと思います。 Testing Throughout the Software Development Lifecycle 2.1に ・Testing as a Driver for Software Development ・DevOps ・shift-left ・Retrospectives などの項目が追加されています。 DevOps、シフトレフト、レトロスペクティブなどはすっかり耳なじみとなったワードですよね。 Testing as a Driver for Software Developmentはテストのことを考えた開発体制であり、シラバスでは ・TDD（テスト駆除開発） ・ATDD（受け入れテスト駆除開発） ・BDD（ビヘイビア駆除開発） が挙げられており、こちらもよく聞くワードになっていると思います。 ATDDはTest Analysis and Design（テスト技法）の項目にも取り上げられていますので、理解し活用できるようにしておきましょう。 Static Testing 静的テストの項目は、一部レビュー観点のものが削除されたようです。 Test Analysis and Design まずは、ユースケーステストの項目が削除されました！ つい最近、 JSTQB学習のススメ #6 〜Foundation〜 | Sqripts こちらでユースケーステストのことを書いたばかりなので、残念という思いもありますが、FLでユースケーステストの内容をこの粒度で記載するのもどうなんだろう、という思いもあったので、納得と言えば納得だったりします。 あとは、中項目として「Collaboration-based Test Approaches」が追加されており、内容としては、 ・Collaborative User Story Writing ・Acceptance Criteria. ・Acceptance Test-driven Development (ATDD). の3章構成となっています。 ・Collaborative User Story Writing 日本語で馴染みの言葉にすると「ユーザーストーリーマッピング」になるのかな、と思います。 これに関しては直近（5/26）開催されたJaSST東北で、ユーザーストーリーマッピングに関する基調講演が行われており、そちらに関する参加記事が載る（載っている？）予定ですので、そちらを見ていただければと思います。 Acceptance Criteriaは「受け入れ基準」という日本語訳になり、ATDDはそのままの用語で日本でも使われていると思いますが、日本語訳だと「受け入れテスト駆除開発」になります。 TDD、レトロスペクティブなど含め、全体的にアジャイルの要素が入っているのがCTFL 4.0のイメージですね。 Managing the Test Activities テスト技法からユースケーステストが削除されたように、FLのテストマネジメントからは 「テスト戦略とテストアプローチ」が削除になったようです。 またテストマネジメントの項目も他同様、アジャイルや自動化の概念から ・Test Pyramid（テストピラミッド） ・Testing Quadrants（テストの四象限） の項目が追加されています。 Test Tools FLのレベルの適切ではない項目が何点か削除されているようです。 おそらくテスト自動化含め、AL側に移行されるものかと考えられます。 まとめ 全ての変更点を網羅しているわけではないですが、ざっと気になったところをまとめるとこのようなかたちになると思います。 気になる方は原文を訳しながら読んでみることをおススメします。 また、シフトレフト、CD/CI、TDDなどは、AGESTでは「QA for Development」 というソリューション提案をしておりますので、気になった方はこちらも確認いただけると幸いです。 「QA for Development」ソリューション – 株式会社AGEST（アジェスト） では、次回こそはFLシラバスのテスト技法の続きを載せたいと思います。 JSTQBのFLシラバス4.0がリリースされる前には、3.1ベースのものは全て書ききりたい、と思っていますので、引き続きお付き合いいただければと思います！ The post 【最新動向】ソフトウェアテストの国際規格「ISTQB CTFL」4.0の爆速レビュー first appeared on Sqripts .

こんにちは、テストオペレーショングループのりきおです。 本記事は、スプレッドシートで作成したテスト項目書に対してGAS（GoogleAppsScript）を使って体裁修正する方法についてご紹介していきたいと思います。テスト項目書はもちろん、あらゆるドキュメント作成の際に少しでもご参考にして頂けると幸いです。 ※なお、本記事では「デザイン」「見た目」等は、まとめて「体裁」と総称します。 はじめに いきなりですが、下図のように同一の項目内容で体裁のみが異なるテスト項目書があったとします。 それぞれを見比べたとき、どちらがより 見やすい と感じますか？ あるいは、どちらがより 円滑にテストを実行できそう だと感じますか？ パターンA パターンB ・ ・ ・ 恐らく、多くの人は パターンB を選ぶのではないでしょうか。 パターンBは、項目の所属がカテゴライズ化されたような体裁となっているため、「どの画面（大項目）」の「どの場所（中項目）」の「どの機能（小項目）」を指しているのかが、パターンAよりも識別しやすくなっています。上図の例では項目数が20個と少ないため、両者の視認レベルにそこまで大きな差異はありませんが、例えば、項目数が数百～数千項目に及んでいたり、項目内で似たような文言が散見されるような場合だと、より顕著な結果となるのではないでしょうか。 しかし、上記で挙げたように数百～数千項目が記載されたテスト項目書を手動で体裁修正した場合、それなりに作業工数がかかってしまったり、また、コピペで修正した場合には修正対象や記載内容の誤植といったヒューマンエラーが起きる可能性があることも事実です。 そのような事態を踏まえて、今回はパターンBを例にスプレッドシートで作成したテスト項目書に対してGASを使って一発で体裁修正したときの方法について、次章以降より解説していきたいと思います！ 要件定義 それでは、コーディングに入る前にパターンBがどのように体裁修正されているかを一度整理しておきましょう。 1.基本要件 はじめに、体裁修正を行う要件を確認していきます。修正内容をまとめると、以下の通りとなっていることが分かります。 ・同列の上下で同じ値が連続する場合、下のセルの文字色をグレーに変更する ・同列で上下で同じ値が連続する場合、下のセル上部の罫線を非表示とする ・「中項目」は「大項目＋中項目」、「小項目」は「大項目＋中項目＋小項目」でそれぞれ比較する 2.機能要件 続いて、上節で整理した内容に基づき、機能要件を手順に沿って定義していきましょう。 基本機能（判定・描画処理） 1. 制御処理：実行回数（N回目）を確認し、状態に応じて以下の通り制御する 　1-A：指定した回数に到達した場合 　　　　・体裁修正処理を終了する 　1-B：指定した回数に未達の場合 　　　　・「2. 判定処理」以降の処理を行う 2. 判定処理：各列の項目間の上下行（N行とN＋1行）の値を比較する 　※上下行の値が「同じ」と判定される条件は以下の通り 　・大項目：「大項目」の上下行の値が同じ 　・中項目：「大項目」「中項目」の上下行の各値がそれぞれ同じ 　・小項目：「大項目」「中項目」「小項目」の上下行の各値がそれぞれ同じ 3. 修正処理：「2. 判定処理」の比較結果に応じて以下の通り体裁修正する 　3-A：同じ値だった場合、下行（N＋1行）の項目を以下に体裁修正する 　　　　・文字色設定：グレー（#cccccc） 　　　　・上罫線描画：FALSE 　3-B：異なる値だった場合、下行（N＋1行）の項目を以下に体裁修正する 　　　　・文字色設定：そのまま（何もしない） 　　　　・上罫線描画：TRUE 4. 実行回数や比較対象の行数にて共通で使用しているインデックス（N）をインクリメントし、「1. 制御処理」に戻る フローチャート： 実際のコーディング処理とは少し異なりますが、イメージとしては下図のような感じとなります。 補足： ・初回実行時、上行（項番#1）の項目は修正対象とならないため、以降の処理でも常に「下行（N＋1行）」の項目を修正対象とします。 ・「3-B：異なる値だった場合」の処理として、パターンAのように体裁修正前の全ての項目が「文字色：黒」かつ「横罫線：あり」となっていれば「何もしない処理」でも問題ないですが、テスターへの注記として意図的に文字色が黒以外に設定されていたり、罫線が描画されていないといった体裁上の誤植があった場合などを考慮して、今回は「文字色：そのまま」「上罫線描画：TRUE」とします。 以上が今回の要件の概要となります。 本章でまとめた要件を元に、次章でコーディングしていきましょう！ コーディング 本記事ではGASのエディタページのコーディングから解説していきます。 ※GASの概要については、別記事「 業務改善にはコレ！＼Google Apps Script／ 」でもご紹介しております。ご興味がある方、GASとはなんぞやという方は、是非読んでみて下さい。 1.スプレッドシート・項目シートの取得 はじめに、実行対象となるスプレッドシートと項目シートを取得しましょう。 関数名は「TestSheetFix」としています。 function TestSheetFix() { const activeSheet = SpreadsheetApp.getActiveSpreadsheet(); const activeSheetName = SpreadsheetApp.getActiveSheet().getName(); const fixSheet = activeSheet.getSheetByName(activeSheetName); 今回はアクティブ状態のシート（現在開いているシート）であれば全てのシートが実行対象となるようにコーディングしているため、シート名に依存せずに実行することができます（間接参照）。 言い換えれば、実行対象以外のシートがアクティブだった場合にも体裁修正処理が走るので、扱いには少し注意が必要です。 補足 実行対象のシート数が少ない場合や特定のシートに対して実行したいといった限定的な用途であれば、以下のように実行対象のシート名を直値で指定する方法でも良さそうです（直接参照）。 function TestSheetFix() { const activeSheet = SpreadsheetApp.getActiveSpreadsheet(); const fixSheet = activeSheet.getSheetByName('実行対象のシート名'); 2.行・列・範囲の取得 次に、取得したシート内で実行対象となる行・列・実行範囲を定義していきましょう。 対象は以下4点です。 1)先頭行の定義 はじめに、実行範囲や修正対象となる行を指定するために、上図スプレッドシートで赤枠に該当する行位置の変数を定義しておきます。 let firstRowUpper = 4; let firstRowLower = firstRowUpper + 1; ・firstRowUpper（先頭上行）：4行目 ・firstRowLower（先頭下行）：5行目（先頭上行＋1行） 2)最終行の定義 続いて、体裁修正する範囲の末尾を決定するために、上図スプレッドシートで赤枠に該当する行位置の変数を定義しておきます。 let lastRow = 23; ・lastRow（最終行）：23行目 3)実行範囲の定義 項目の先頭行と最終行を取得した後は、それぞれを減算して体裁修正する実行範囲（実行回数）を定義しましょう。 let fixRange = lastRow - firstRowUpper; ・fixRange(19)　：lastRow(23) – firstRowUpper(4)  ※「下行」が修正対象であり一番最後に実行する行は22行目（最終行 – 1行目）のため、全項目数に対して1項目少ない値が実行範囲となります。 4)列番号の定義 最後に、比較対象や実行する列を指定するために、上図スプレッドシートで赤枠に該当する列番号を定義しておきます。 let primaryItemCol = 3; let secondaryItemCol = primaryItemCol + 1; let tertiaryItemCol = primaryItemCol + 2; ・primaryItemCol（大項目列）　 ：C列＝3列目 ・secondaryItemCol（中項目列）：D列＝4列目（大項目列＋1列目） ・tertiaryItemCol（小項目列）　  ：E列＝5列目（大項目列＋2列目） 変数の戻り値 デバッグで各変数の戻り値を確認してみると、下図の結果となりました。 どれも適切な値が定義できてますね！ 補足 行位置及び列番号は直値で指定しています。タイトルの文字列をキーとして検索する方法やgetNextDataCellメソッドなどでセル位置を取得する方法も検討しましたが、タイトル名が変更された、意図しない文字列が存在していたため想定外のセル位置が取得された、といったケースを考慮してより確実性の高いコーディングにしています。そのため、対象の行・列番号や実行範囲は任意に指定できる反面、行・列が追加・削除された場合、別シートに対して実行したい場合などは再定義する必要があります。 3.比較対象の取得 続いて、体裁修正時に比較する項目の値を取得していきます。 今回は、スプレッドシートから値を直接取得するのではなく、あらかじめ全ての値を配列に格納し、その各要素を比較するようにコーディングしています。 ※理由は別章「実行結果」に記載。 let primaryItemAry = fixSheet.getRange(firstRowUpper, primaryItemCol, fixRange + 1, 1).getValues().flat(); let secondaryItemAry = fixSheet.getRange(firstRowUpper, secondaryItemCol, fixRange + 1, 1).getValues().flat(); let tertiaryItemAry = fixSheet.getRange(firstRowUpper, tertiaryItemCol, fixRange + 1, 1).getValues().flat(); ※「fixRange」は、「全体の項目数 – 1項目」となっているので、ここでは不足している「1」を加算しておきます。 変数の戻り値 「大項目（primaryItemAry）」を例に配列の中身を確認してみると、下図の結果となりました。 「中項目」「小項目」でも同様に、該当する全ての項目が格納されています。 次節「4.体裁修正処理」では、これらの要素を上から順に2つずつ参照していくことで、スプレッドシート上の上下列も間接的に比較できるようになっています。 補足 今回は、「大項目」「中項目」「小項目」の各列ごとに一次元配列に格納するようにコーディングしていますが、列数が多くなる場合などは以下のようにまとめて同じ配列に格納する方法でも良さそうです。 その際、要素指定には注意が必要です。 let itemAry = fixSheet.getRange(firstRowUpper, primaryItemCol, fixRange + 1, 3).getValues(); 4.体裁修正処理 修正時に必要となる各値を定義・取得できたところで、体裁修正処理に入ります。 制御処理 別章「要件定義」で整理した内容に基づき、for文によるループ実行で各行・列の体裁を修正していきます。 ループ数の条件は「fixRange（実行範囲）」を指定します。 for (let i = 0; i < fixRange; i++) { ここで定義した変数「i」は、以降の体裁修正処理でも使用します。比較対象となる配列要素や修正対象となる行位置に「i」を指定、または加算することで、ループ時のインクリメントに追従して修正処理の対象が変化する制御となります。 「大項目」の体裁修正 if文で「大項目」の上下行の値を比較し、その判定結果を元に体裁修正する内容を分岐させます。 if (primaryItemAry[i] === primaryItemAry[i + 1]) { fixSheet.getRange(firstRowLower + i, primaryItemCol).setFontColor('#cccccc') fixSheet.getRange(firstRowLower + i, primaryItemCol).setBorder(false, true, null, null, null, null, '#000000', SpreadsheetApp.BorderStyle.SOLID) } else { fixSheet.getRange(firstRowLower + i, primaryItemCol).setBorder(true, true, null, null, null, null, '#000000', SpreadsheetApp.BorderStyle.SOLID) }; 同じ値の場合 ： if 大項目[ 上行 ] ＝ 大項目[ 下行 ]  ・文字色設定：setFontColor 　　文字色：#cccccc（グレー） ・罫線設定：setBorder 　　上部：FALSE（描画しない）　※上部罫線が引かれていた場合は削除 　　左部：TRUE（描画する）　※左部罫線が引かれていなかった場合を想定 　　下部：null（何もしない） 　　右部：null（何もしない） 　　水平：null（何もしない） 　　垂直：null（何もしない） 　　罫線色：#000000（黒） 　　罫線スタイル：SOLID（細い実線） 同じ値以外の場合 ：else  ・文字色設定：setFontColor　 　　→　コード記述なし（何もしない） ・罫線設定：setBorder 　　上部：TRUE（描画する）　※上部罫線が引かれていた場合は上書き 　　左部：TRUE（描画する）　※左部罫線が引かれていなかった場合を想定 　　下部：null（何もしない） 　　右部：null（何もしない） 　　水平：null（何もしない） 　　垂直：null（何もしない） 　　罫線色：#000000（黒） 　　罫線スタイル：SOLID（細い実線） 「中項目」の体裁修正 体裁修正する内容は「大項目」と同じですが、判定条件に「大項目同士が同じ場合（primaryItemAry[i] === primaryItemAry[i + 1] && ）」を含めています。 if (primaryItemAry[i] === primaryItemAry[i + 1] && secondaryItemAry[i] === secondaryItemAry[i + 1]) { fixSheet.getRange(firstRowLower + i, secondaryItemCol).setFontColor('#cccccc') fixSheet.getRange(firstRowLower + i, secondaryItemCol).setBorder(false, true, null, null, null, null, '#000000', SpreadsheetApp.BorderStyle.SOLID) } else { fixSheet.getRange(firstRowLower + i, secondaryItemCol).setBorder(true, true, null, null, null, null, '#000000', SpreadsheetApp.BorderStyle.SOLID) }; 「小項目」の体裁修正 こちらも体裁修正する内容は「大項目（中項目）」と同じですが、判定条件に「大項目同士かつ中項目同士が同じ場合（primaryItemAry[i] === primaryItemAry[i + 1] && secondaryItemAry[i] === secondaryItemAry[i + 1] && ）」を含めています。 if (primaryItemAry[i] === primaryItemAry[i + 1] && secondaryItemAry[i] === secondaryItemAry[i + 1] && tertiaryItemAry[i] === tertiaryItemAry[i + 1]) { fixSheet.getRange(firstRowLower + i, tertiaryItemCol).setFontColor('#cccccc') fixSheet.getRange(firstRowLower + i, tertiaryItemCol).setBorder(false, true, null, null, null, null, '#000000', SpreadsheetApp.BorderStyle.SOLID) } else { fixSheet.getRange(firstRowLower + i, tertiaryItemCol).setBorder(true, true, null, null, null, null, '#000000', SpreadsheetApp.BorderStyle.SOLID) }; 以上が各コーディング内容となります。下記にまとめとして、全体のコーディング＋スクリプト実行時間を測定する処理を含めたソースコードを記載しています。少しでもご活用いただけたらと思います。 5.ソースコード /** * 関数名 :TestSheetFix * 内容 :スプレッドシートで作成したテスト項目書の体裁を修正する * 修正対象：C列[4行目～最終行]：大項目（primaryItem） * 　　 D列[4行目～最終行]：中項目（secondaryItem） * 　　 E列[4行目～最終行]：小項目（tertiaryItem） * * ※ 流用する際は、テスト項目書に応じて「先頭行の定義」「最終行の定義」「各列の定義」を再定義して下さい */ function TestSheetFix() { //実行時間計測用：開始 const startTime = new Date(); //スプレッドシート・項目シートの取得 const activeSheet = SpreadsheetApp.getActiveSpreadsheet(); const activeSheetName = SpreadsheetApp.getActiveSheet().getName(); const fixSheet = activeSheet.getSheetByName(activeSheetName); //先頭行の定義 let firstRowUpper = 4; let firstRowLower = firstRowUpper + 1; //最終行の定義 let lastRow = 23; //実行範囲の定義 let fixRange = lastRow - firstRowUpper; //列番号の定義 let primaryItemCol = 3; let secondaryItemCol = primaryItemCol + 1; let tertiaryItemCol = primaryItemCol + 2; //比較対象の取得 let primaryItemAry = fixSheet.getRange(firstRowUpper, primaryItemCol, fixRange + 1, 1).getValues().flat(); let secondaryItemAry = fixSheet.getRange(firstRowUpper, secondaryItemCol, fixRange + 1, 1).getValues().flat(); let tertiaryItemAry = fixSheet.getRange(firstRowUpper, tertiaryItemCol, fixRange + 1, 1).getValues().flat(); //体裁修正処理 for (let i = 0; i < fixRange; i++) { //「大項目」の体裁修正 if (primaryItemAry[i] === primaryItemAry[i + 1]) { fixSheet.getRange(firstRowLower + i, primaryItemCol).setFontColor('#cccccc') fixSheet.getRange(firstRowLower + i, primaryItemCol).setBorder(false, true, null, null, null, null, '#000000', SpreadsheetApp.BorderStyle.SOLID) } else { fixSheet.getRange(firstRowLower + i, primaryItemCol).setBorder(true, true, null, null, null, null, '#000000', SpreadsheetApp.BorderStyle.SOLID) }; //「中項目」の体裁修正 if (primaryItemAry[i] === primaryItemAry[i + 1] && secondaryItemAry[i] === secondaryItemAry[i + 1]) { fixSheet.getRange(firstRowLower + i, secondaryItemCol).setFontColor('#cccccc') fixSheet.getRange(firstRowLower + i, secondaryItemCol).setBorder(false, true, null, null, null, null, '#000000', SpreadsheetApp.BorderStyle.SOLID) } else { fixSheet.getRange(firstRowLower + i, secondaryItemCol).setBorder(true, true, null, null, null, null, '#000000', SpreadsheetApp.BorderStyle.SOLID) }; //「小項目」の体裁修正 if (primaryItemAry[i] === primaryItemAry[i + 1] && secondaryItemAry[i] === secondaryItemAry[i + 1] && tertiaryItemAry[i] === tertiaryItemAry[i + 1]) { fixSheet.getRange(firstRowLower + i, tertiaryItemCol).setFontColor('#cccccc') fixSheet.getRange(firstRowLower + i, tertiaryItemCol).setBorder(false, true, null, null, null, null, '#000000', SpreadsheetApp.BorderStyle.SOLID) } else { fixSheet.getRange(firstRowLower + i, tertiaryItemCol).setBorder(true, true, null, null, null, null, '#000000', SpreadsheetApp.BorderStyle.SOLID) }; }; //実行時間計測用：終了 const endTime = new Date(); //実行時間(s)の算出 const runTime = (endTime - startTime) / 1000; //ログ出力 console.log(runTime); }; 実行結果 1.実行結果 それでは、以下のテスト項目書に対してコードを実行し、結果を確認してみましょう！ 実行前のテスト項目書 ※項目内容は別章「はじめに」のパターンA・Bと同じですが、下記の通り少し細工をしています。 罫線 　・#6：「大項目」の左部に罫線が引かれていない 　・#7（#8）：「中項目」の下部（上部）に罫線が引かれていない 　・#12（#13）：「中項目」の下部（上部）に太字の罫線が引かれている 　・#18：「小項目」の左部に赤い罫線が引かれている 　・先頭行上部：項目を区別するために太字の罫線となっている 　・最終行下部：項目を区別するために太字の罫線となっている 文字色 　・#16：「小項目」が赤字になっている 補足 上記の「罫線」は体裁上で特に意味をなしておらずテスト設計者による誤記だと想定し、修正対象としています。ただし、先頭行上部と最終行下部の太字の罫線については意図した描画であるため、こちらは修正対象としません。また「文字色」については、テスト設計者が項目内容に対する注記やテスターへの補足といった意図した設定の可能性があるため、こちらも修正対象としていません。 果たして、結果は如何に・・・？ 実行後のテスト項目書 期待通りの体裁となりました！ 罫線及び文字色が各条件に従って修正されており、今回の要件通りとなっています。 実行時間 20項目程度だと約0.6秒で実行できました。はやい！ 補足 GAS内で一発で実行できたため、実行後のUndo(Ctrl + Z)・Redo(Ctrl + Y)も一発で対応可能でした。修正結果を戻したい場合や意図しない修正を入れてしまった場合などでも、一発で手戻りできます。 2.ハマりポイントと改善策 最後に、実装時にハマったポイントとその改善策を記載しておきます。 当初は、体裁修正処理で比較対象となる上下の値をスプレッドシートから直接取得する方法で実装していたのですが、どうしても実行速度が遅くなってしまう問題が起きていました。 調べたところ、関数やメソッドの実行対象にスプレッドシートなどGAS以外のサービスを指定した場合、実行時にAPI連携が発生するようです。そのため、上述のようにfor文中にgetValueメソッドを記述し、かつ取得元にスプレッドシートを指定すると、ループするたびにリクエスト回数が増加してしまい、結果としてスクリプト実行時間が伸びてしまっていたことが遅延の原因でした（当然と言えば当然でした…）。 なので、事前に全ての比較対象となる値を一括で配列に格納し、体裁修正処理でこれらの要素を参照することで、比較時の処理をGAS内で完結できるように改善しました。 参考までに、改善前後のイメージ図と500項目に対して体裁修正したときの実行時間を以下に記載しています。 実行イメージ 　 実行時間 　改善前 　 　419秒＝約7分で完了しました。手動作業よりは多少早いくらいでしょうか…？ 　改善後 　 　 約7.6秒で完了しました！かなり良化しました◎ おわりに 今回ご紹介した方法であれば、500項目でも7.6秒程度で体裁修正できたため、作業コストが大幅に削減できるのではないでしょうか（項目数が多ければ多いほど効果的！）。 ただし、本記事ではあくまでも仮のテスト項目書に対するサンプルコードを解説しているため、ご使用いただく際は対象ドキュメントの目的や用途に応じて適宜カスタマイズして頂ければと思います。 また、こうした「GAS × スプレッドシート」といったサービスを上手く組み合わせて業務を適切に自動化・効率化し、作業をドンドン捗らせちゃいましょう！ The post GoogleAppsScriptを使ってテスト項目書の体裁を一発で整える first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第2回目のテーマは、「アジャイルマニフェスト」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 アジャイルマニフェスト アジャイルソフトウェア開発宣言。通称アジャイルマニフェスト アジャイルマニフェストは、わずか10行のWebページです。アジャイル開発やそれに関連するプロセスを学んだり、実践していくと、マニフェストの内容をたびたびふりかえるケースが増えます。それぐらいアジャイル開発の本質をついた内容になっています。特に重要とされる部分は、2段落目にある4つの価値観です。これを読みやすく書き直すと以下になります。 プロセスやツールよりも 個人と対話 に価値をおきましょう。 包括的なドキュメントよりも 動くソフトウェア に価値をおきましょう。 契約交渉よりも 顧客との協調 に価値をおきましょう。 計画に従うことよりも 変化への対応 に価値をおきましょう。 よく「アジャイル開発はドキュメントを重要視しない」と解釈している人がいますが、それは間違いです。ここで伝えたいことは、上記文章の通り、「〜よりも〜に価値をおきましょう」なので、どっちも重要。ただし、しいていうなら後者に価値をおいていきましょうということになります。 次に、太字の部分を抜き出してみましょう。 個人との対話 動くソフトウェア 顧客との協調 変化への対応 アジャイル開発に取り組んでいく場合、ふりかえりなどのタイミングでこの4点に価値をおけているか？を確認するといいでしょう。そうすることで、アジャイル開発が向かおうとしている方向を確認するコンパスのように使えるはずです。 アジャイルソフトウェアの12の原則 アジャイル宣言の背後にある原則 アジャイルマニフェストの4つの価値の下には、『アジャイルソフトウェアの12の原則』と書かれたリンクがあります。アジャイルマニフェストは4つの価値が目立ちますが、このアジャイルソフトウェアの12の原則も重要な内容になっています。 4つの価値は、17人の開発方法論者が合意できた価値観でしかありませんが、原則は、価値よりも具体的な内容が書かれているため、指針になります。では、その内容を見ていきましょう。 1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します アジャイルチームは価値の最大化を常に考えています。さらに、顧客満足を優先した意思決定を行っていきます。 なにか判断が必要なときに、顧客満足を最優先にできているか？ アジャイルコーチであれば、価値あるソフトウェアを早く継続的に提供できているか？ チームに問いかけていきます。 2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます 4つ目の価値である「変化への対応」に紐付いた原則です。アジャイル開発は変化への対応を重視した方法なので、変化に弱くなっている場合は、自分たちのやり方を根本的に見直さなければなりません。 とはいえ、何でも変化に対応できるわけではありません。開発の後期で変化を受け入れるなら、それに伴い再計画が必要になったりします。何かを受け入れるなら、何かを捨てなければならなくなるというシンプルな考え方です。 3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします 「開発の速さ」に関する原則です。アジャイル開発は長期的な開発なのですが、小さく期間を区切って、リリースを繰り返しながら積み上げていく開発になります。 もし、仕事を小さくするのが難しい場合は、アジャイル開発に適したシステムではないかもしれません。アジャイル開発に取り組む前に、リアーキテクチャのような仕事を小さくする方法を検討するといいかもしれません。 4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません アジャイルチームを組成する場合、もっとも難易度が高いのがこの原則かもしれません。とくにビジネスと開発が組織的に分かれている場合は、なかなか対策を打ちにくい部分でもあります。 ただ、ビジネスでも開発でも、同じゴールを目指すのであれば、この原則はなんとか実現したいものです。はじめは難しくとも、 まずはMTG時間を使ってコミュニケーションの場を作る 開発チームのにビジネスの出張席を作る（もしくはその逆） 同じ場所で働く 専用の部屋で働く・・・ と徐々にやれることをやっていく形にするといいと思います。 5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します よく、「アジャイル開発は優秀な人じゃないとできないのではないか？」と質問されますが、自分なら「意欲に満ちた人が必要」と答えます。 もちろん優秀な人に集まって欲しいとは思いますが、必須条件ではないと考えているからです。 6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです 4つの価値にある「個人との対話」に紐づく原則です。 最近はオンラインでの仕事が広まり、ツールも便利になったので、オンラインのコミュニケーションがやりやすくなってきました。少し前、筆者は久しぶりにオフラインでMTGをやったのですが、オンラインと比べて、ダントツにコミュニケーションが取りやすく感じました。 いくらツールが発達したとしても、そのツールをうまく活用したとしても、オフラインのコミュニケーションにまさるものはないのかもしれません。 7. 動くソフトウェアこそが進捗の最も重要な尺度です 4つの価値にある「動くソフトウェア」に紐づく原則です。アジャイルチームの成果は、動くソフトウェアで測られます。 整備されたドキュメントやテスト結果をまとめたレポートも重要ですが、動くソフトウェアほどシンプルに成果を確認できる手段はありません。 8. アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません この文のポイントは、「持続可能な開発」です。つまり、アジャイルチームはムリ・ムダ・ムラを避けていかなければなりません。 そうしなければ、どこかでムリがたたり、持続可能な開発ができなくなるでしょう。 9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 読み取るのが難しい文章です。原文を DeepL で訳してみましょう。 Continuous attention to technical excellence and good design enhances agility. 優れた技術と優れたデザインへの継続的な配慮が、アジリティを高めています。 アジャイル開発はすばやく開発する方法ではありますが、技術やデザイン（設計）を放置しているわけではありません。優れた技術やツールがアジリティ（俊敏性）を生み出すのは当然ですし、よい設計もアジリティを上げるために必要な要素になります。 10. シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 これはトヨタの考え方が現れた原則です。スクラムを見ると、まさにこの原則に従っているように感じます。 11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 この原則も読み取りにくい内容です。そういうときは原文をDeepLに通してみましょう。 The best architectures, requirements, and designs emerge from self-organizing teams. 最適なアーキテクチャ、要件、設計 は、自己組織化したチームから生まれる。 興味深いのは、アーキテクチャを考えるのは「だれか」ではなく、「チーム」であることだと思います。チームを重要視するアジャイル開発らしい原則です。 日本語では「生まれる」となっていますが、原文はemerge （【自動】 表面に出てくる、現れる、出現する、浮かび出る）なので、ベストなアーキテクチャはチームから自然に生まれてくる・・・というニュアンスになります。 12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。 最後はふりかえりの重要性です。「アジャイル開発ができない場合でも、ふりかえりは絶対やったほうがいい」と思います。 アジャイルマニフェスト、12の原則の意味 以上が、アジャイルマニフェスト、アジャイルソフトウェアの12の原則の解説です。 4つの価値については、若干ふんわりした表現になっていますが、原則を一緒に読み解いていくと、具体的にどうあるべきかが見えてきます。 世の中にはたくさんのアジャイル開発にまつわる本や記事がありますが、それらが行き着く先はアジャイルマニフェストや12の原則です（この記事もそうだと思います）。 アジャイルに正しさを求めると、原理主義的になり弊害が生まれやすいのですが、アジャイルチームの人であれば、自分たちの現状を、価値や原則に照らしあわせることで、自分たちの現在位置や、理想の状態がわかるようになるはずです。 The post 第2回 声に出して読みたいアジャイルマニフェスト first appeared on Sqripts .

こんにちは、QAエンジニアのカンパチロックです。 今回は、テストフェーズにおいてQAの価値を向上させる方法の1つとして、分散トレーシングおよびその標準規格であるOpenTelemetryについて説明します。これにより、システム内で発生する問題をより迅速かつ正確に特定し、開発プロセスをより迅速かつ効率的に進めることができます。 分散トレーシングとは まず、分散トレーシングにという用語について皆さん聞いたことはありますでしょうか？ 商用の製品としては、Dynatrace、NewRelic、DatadogなどのAPM（Application Performance Management）製品に実装されている為、こちらの名前を聞いた事がある方もいらっしゃるかもしれません。 分散トレーシングの概要は、ユーザーからのリクエストに伴う様々なサービス呼び出しやデータストアへのアクセスなど、一連の処理（トランザクション）をパラメータやログと組み合わせて追跡・管理することです。これにより、従来のログ管理では分析に時間がかかる問題の原因を特定するプロセスが劇的に高速化されます。分散トレーシングの利点は、まさにこの迅速な問題解決能力にあります。 特にマイクロサービス環境下では、多くのサービスが複雑な関係性を持って連携しており、問題発生時に、問題の発生元となるサービスの特定に多くの時間を要するリスクがあり、その対策としての分散トレーシングの導入についても注目されております。 分散トレーシングのOSSとして有名なJeagerのサイトでは、分散トレーシングで収集したデータの可視化イメージとして下記のようなイメージが掲載されています。 左側のグラフのように、取得したデータからサービス間の連携状況を可視化したり、右側のウォータフォールチャートのように、ユーザのリクエストから発生する一連の処理について、どのサービスでどの程度の時間が掛かっているかや、処理実施時のパラメータ情報やエラー発生時のエラーログなどをトランザクション毎に確認できることができます。これらの可視化機能により、システム全体のパフォーマンスや問題の特定が容易になります。 引用元:  https://www.jaegertracing.io/docs/1.33/architecture/#span 詳細については、以下のサイトで説明されていますので、ご参照下さい。 分散トレーシングとは メリット、仕組みなどを解説 | Splunk ディストリビューティッド (分散) トレーシングの概要 OpenTelemetryについて ここからは、より具体的な内容として、OpenTelemetryについて説明します。 OpenTelemetryは、分散トレーシングの共通規格を提供するプロジェクトで、2019年にそれまで別々の規格であったが統合されて誕生しました。これにより、分散トレーシングの標準化が一層進んでいます。 分散トレーシングにおいて、ベンダーロックインが課題となっていました。これは、別のAPM製品に乗り換える際に、新しいAPM製品に合わせたエージェントの再配置やソースコードの修正が必要だったためです。しかし現在、多くのAPM製品がOpenTelemetry規格に対応しているため、APM製品の乗り換え時のインパクトが大幅に軽減されています。極端な例として、接続先サービスの切り替えのみで乗り換えが完了するケースもあります。 今後、分散トレーシングを導入する際には、標準規格であるOpenTelemetryについて理解を深めることが重要であると考えられます。これにより、より効率的なトレーシングシステムの構築や、さまざまなAPM製品との互換性が向上し、将来的な拡張性も確保されます。 OpenTelemetryで出来ること OpenTelemetryでは、主要な取得情報としてTrace、Metrics、Logの3要素があります。言語ごとに対応状況は異なりますが、以下にそれぞれの要素について簡単に説明します。 Trace：ユーザのリクエストを起因とした各種サービスでの処理内容や処理時間を記録したもの Metrics：サービス実行時の各種統計情報（サービスの実行回数やレスポンスの平均値など） Log：サービスで発生したイベントを記録したもの（Traceと紐付け可能） 詳細については、OpenTelemetryの Signalsドキュメント を参照してください。 なお、大規模なアクセスが想定されるサービスの分散トレーシングにおいて、全てのリクエスト情報を取得・保存すると、分散トレーシングの仕組み自体が負荷のボトルネックとなる可能性があります。そのため、一般的には取得・保存するリクエストをサンプリングします。ただし、サンプリングされたTrace情報からは全体の統計情報を取得できないため、別途Metrics機能が提供されています。 OpenTelemetryでは、将来的にProfilingのサポートを追加することが計画されており、コードベースでの実行機能や処理時間をより詳細に取得できるようになる可能性があります。 https://github.com/open-telemetry/oteps/issues/139 OpenTelemetry規格とは別に、Apache SkyWalkingのような一部のAPM製品では、すでにプロファイル情報をトレーシングの一部として組み込む機能が実装されています。 SkyWalking Python Agent Supports Profiling Now OpenTelemetryでは、各言語用のライブラリが提供されており、多くの場合、自動計装（自動インストゥルメンテーション）によってアプリケーションへのトレーシング機能の導入が容易になっています。自動計装により、手動でコードに計測ポイントを追加することなく、既存のアプリケーションに対してトレーシングやメトリクスの収集が可能となります。言語ごとの対応状況や自動計装の詳細については、以下のリンクを参照してください。 また、JavaScriptに関しては、Node.js用とBrowser用のライブラリが用意されており、ブラウザ側からTrace情報を送信する事も可能となっています。 Instrumentation OpenTelemetryを活用した可視化のレベル 上記で説明したTrace、Metrics、Logの情報を各サービスから収集することにより、システム全体の可視化が実現可能です。ここでは、どのようなレベルの可視化が可能かを検討してみたいと思います（あくまで可能性を示すものであり、現時点では実現が難しい事柄も含まれるかもしれません）。 前項でも少し触れましたが、OpenTelemetryのJavaScriptライブラリには、ブラウザ用のライブラリも提供されています。これにより、ブラウザから送信された情報をトレーシングのエンドポイントとして扱うことが可能です。 npm: @opentelemetry/auto-instrumentations-web さらに、リクエストだけでなく、ユーザの操作（フォームへの入力やボタンのクリックなど）もトレーシングできるため、ブラウザ上でユーザが行った操作からバックエンドの処理までの一連の動作をトレースすることが可能です。これらの機能を利用することで、エンドユーザーの体験とシステム全体のパフォーマンスをより詳細に把握することができます。 これらを組み合わせて得られる情報のイメージは、以下のような形になるでしょう。 ユーザがトップ画面で検索キーワードを入力し、検索ボタンを押下した。 検索ボタンの押下により、XXX APIのリクエストが発生し、その際の検索パラメータはXXXだった。 バックエンドサーバがリクエストを受け付け、外部サービスBのAPIを実行した。その際のパラメータはYYYだった。 サービスBではデータストアに検索クエリを発行し、取得した結果をもとにバックエンドサービスにレスポンスを返した。 バックエンド側で未処理のエラーが発生した。その際のスタックトレース及びエラーメッセージはZZZだった。 従来のログ管理では、個々のサービスのログをそれぞれ分析し、原因箇所を特定する必要がありましたが、OpenTelemetryを各サービスに実装することにより、上記のような情報取得が可能になります。 OpenTelemetryの各種ライブラリが提供するAuto Instrumentation機能を活用することで、主要なトレース情報（外部サービスのAPIコールやデータストアへのクエリ実行など）は簡単な設定とライブラリのインストールだけで実現可能です。これにより、個別のプログラムを修正してトレースを実装する必要が大幅に減り、効率的な可視化が実現できます。 分散トレーシングとQAについて ここまで、分散トレーシングおよびその標準規格であるOpenTelemetryの概要について説明させていただきましたが、我々AGESTのようなQAを主業務とする企業において、これらの機能がどのように活用できるかを考察してみたいと思います。 分散トレーシングは、運用目的のツールや性能テストでのボトルネック調査といったイメージが強いですが、それだけではなく、その導入の容易さや、原因調査能力の高さや、収集情報の有用性から、一般的なテストにおいてもバグ発生時の原因究明を迅速に行える可能性もあります。このように、分散トレーシングはテストプロセスにおいても重要な役割を果たすことができるのです。 従来、QAと開発の関係では、不具合が発生した場合、QA側が発生手順、発生日時、再現率などの情報を開発者に伝え、開発者がログ解析や原因調査を行うのが一般的でした。しかし、分散トレーシングの導入によって、QA側が開発者により詳細な情報を提供できるようになりますし、開発の実態やサービス内容をより深く理解した上でのQA実施が可能となります。 この変化によって、従来のQAの枠組みを超えた、新しい形のQAサービスが提供できる可能性があります。 最後に 以上、分散トレーシングとQAについてでした。 分散トレーシングは、現代の複雑なシステム開発において欠かせない技術の一つです。QAの観点から見ると、テスト工程においてトレーシング機能を活用することで、システムの挙動を正確に把握し、品質管理をより効果的に行うことができます。 しかし、この技術を活用するためには、開発チームとの密なコミュニケーションが必要です。開発チームと共に、テスト戦略を練り上げることが、高品質なソフトウェアの開発につながります。 今後も、常に最新のテスト技術に目を向け、学び続けることが大切です。皆さんもぜひ、分散トレーシングをはじめとする最新のテスト技術を取り入れ、より高度な品質管理に取り組んでみてはいかがでしょうか The post 分散トレーシングの活用による次世代のテストを考える first appeared on Sqripts .

現代のソフトウェア開発では、競争力を維持し、顧客ニーズに迅速に対応するために、より短いスパンでのリリースが求められるようになりました。従来の開発手法ではこれが難しいとされており、こうした課題に対応するために注目されているのがDevOpsです。 この記事では、初級者エンジニア向けに、DevOpsの基本知識やアジャイル開発との違い、DevOpsのライフサイクルや導入方法まで、詳しく解説していきます。DevOpsに興味を持っている方や、DevOpsを導入するメリットを知りたい方は、ぜひこの記事を読んでみてください。 DevOpsとは？ DevOps（デブオプス）は、ソフトウェア開発における開発者を意味する（Development）と運用者を意味する（Operations）を組み合わせた造語です。DevOpsは、開発チームと運用チームが協力して、一つのチームとして、スピーディにソフトウェアを開発し、品質や生産効率を高めることを目的としています。 従来の開発チームと運用チームは、役割が異なるために対立することがありました。一般的に、プログラムを作成する開発チームと、システムの運用を担当する運用チームに分かれて作業を行います。開発チームの役割は、競合他社との競争力を得るため、システムに新しい機能を追加することであり、運用チームの役割は、安定したサービスを提供し続けることです。しかし、新しい機能を追加したい開発チームに対し、運用担当者はシステムの安定稼働を優先するため、機能追加に慎重になることがありました。 DevOpsはこのような問題を解決するために、開発チームと運用チームが協力して、一つのチームとして開発にのぞむための手段と言えます。開発と運用の間の壁が取り払われることで、効率的かつ効果的なソフトウェア開発と運用が実現されます。 DevOpsの基本 DevOpsは、開発チームと運用チームが協力してソフトウェアを作ることを目指すため、以下のような考え方を基本とします。 ソフトウェア開発ライフサイクルの自動化 共同作業とコミュニケーションの向上 継続的な改善と無駄の最小化 ユーザーニーズの重視とフィードバックループの最短化 これらの基本原則を理解した上で、開発・運用の各プロセスを自動化することで、効率的かつ効果的なソフトウェア開発と運用を実現し、継続的に改善することができます。 DevOpsが重要な理由 DevOpsの重要性は、開発と運用のコラボレーションを促進し、開発から運用までの一貫性を確保することにあります。また、自動化ツールを活用することで、作業の効率化と品質向上を実現できます。さらに、DevOpsは迅速なビジネス対応とイノベーションの促進にも寄与します。これらの理由から、DevOpsは現代のソフトウェア開発において、必要不可欠な要素です。 DevOpsとアジャイル開発の違い DevOpsとアジャイル開発は、ともにソフトウェア開発において重要な手法ですが、それぞれのコンセプトは異なる側面があります。 アジャイル開発の特徴は以下のとおりで、どちらかというと開発に注力した考え方をしています。 要件や仕様の変更を積極的に受け入れるようにしている 設計・開発・リリースのような工程でできるだけわけずに、小さな機能ごとの開発を短い期間内で繰り返し行っていく コミュニケーションを重要視し、自己組織化されたチーム 一方で、DevOpsは、先ほどDevOpsの基本で説明した4点の考え方を特徴としており、運用と開発のつなぎこみに注力する側面が強いです。 つまり、アジャイル開発はソフトウェア開発の具体的な手法であり、DevOpsはソフトウェア開発と運用の手法となります。 DevOpsとCI/CDとの違い DevOpsとCI/CDは、ときどき混同されがちですが、それぞれ異なる概念であり、同時に密接な関係があります。 CI/CDはContinuous Integration（継続的インテグレーション）とContinuous Delivery（継続的デリバリー）の略称で、ソフトウェア開発における自動化の実践です。 CI/CDによる自動化は、DevOpsの考え方と相性が良く、効率的かつ効果的なソフトウェア開発と運用を実現するために、DevOpsアプローチの中でCI/CDが活用されることが多いです。つまり、CI/CDはDevOpsの実践において重要なツールとして機能し、両者は相互に補完しあう関係にあります。 DevOpsのライフサイクル DevOpsはソフトウェア開発と運用に関わる考え方ですが、その具体的なプロセスはどうなっているでしょうか？DevOpsのライフサイクルには、計画・コーディング・ビルド・テスト・リリース・デプロイ・運用・モニタリングの8つのステップがあります。DevOpsのライフサイクルを正しく実施することで、開発チームと運用チームが協力し、より迅速かつ信頼性の高いソフトウェア開発を実現することができます。 以下に各ステップの概要を説明します。 計画（Plan） DevOpsのライフサイクル最初のステップは計画です。このステップでは、開発チームと運用チームが協力して、ソフトウェアの要件定義や開発計画を策定します。計画ステップでは、開発と運用の間でのコミュニケーションが重要であり、双方が協力して開発計画を策定することが大切です。 コード（Code） 計画ステップの次はコーディングステップです。このステップでは開発チームがプログラムのコードを開発し、ソースコード管理システムにコードを格納します。単体テスト、コードレビューなどの手順を経て、コードを完成させます。 ビルド（Build） コーディングステップが完了したら、次のステップはビルドです。ビルドステップでは、開発チームがソースコードをビルドして動作可能なアプリケーションを作成します。自動化ツールやクラウドサービスを活用して、ビルドを迅速かつ安全に行います。 テスト（Test） ビルドしたアプリケーションに不具合がないかを確認するステップです。ここでは、開発チームがアプリケーションをテストし、バグを特定して修正します。テストステップでは、自動テスト、手動テスト、セキュリティテストなどの手順を経て、ソフトウェアの品質を確認します。 リリース（Release） リリースステップでは、ソフトウェアの新しいバージョンが完成し、デプロイの準備が整います。リリース管理ツールを使用して、ソフトウェアの異なるバージョンを管理し、必要に応じてロールバックできるようにします。 デプロイ（Deploy） リリースされたアプリケーションやソフトウェアの新しいバージョンを実際の本番環境に配置します。デプロイの工程では、リリースされたバージョンのアプリケーションが実際のサーバー、クラウド環境、または他のインフラストラクチャに配置され、本番環境での動作が確認されます。 運用（Operate） 運用ステップは、ユーザーサポートやトラブルシューティング、システムメンテナンスを実施し、システムを安定稼働させます。 モニタリング（Monitor） モニタリングステップでは、運用チームがシステムの稼働状況を監視し、問題が発生した場合には、迅速に対応します。 DevOpsのライフサイクルは、開発と運用を連携させ、自動化することを重視したプロセスです。この方法により、ソフトウェア開発と運用のパフォーマンスと品質を向上させることができます。 DevOpsの開発手法 DevOpsの開発手法は、ソフトウェア開発プロセスにおいて、開発チームと運用チームが協力して、アプリケーションの開発・テスト・デプロイ・運用を継続的に改善するための手法です。 DevOpsの開発手法には、以下の項目があります。 継続的インテグレーション 継続的デリバリー 継続的デプロイメント コミュニケーションと共同作業 継続的フィードバック これらの手法を正しく理解し、導入することで、開発チームと運用チームがより密接に連携し、効率的かつスムーズなアプリケーションの開発・テスト・デプロイ・運用が可能になります。 継続的インテグレーション 継続インテグレーションは、コードの変更を共有リポジトリにマージした後、自動化されたビルドとテストを実行することで、問題を早期発見することができ、品質を向上させるための手法です。この手法により、開発者はコードの変更に伴う不具合を迅速に解決し、品質の高いソフトウェアを提供できるようになります。また、テストを自動化することで開発者は時間と手間を省くことができるので、より大規模なプロジェクトでも効率的に作業できます。 継続的デリバリー 続的デリバリーは、ソフトウェアのリリースプロセスを自動化し、常にリリース可能な状態を保つ手法です。この手法は、アプリケーションのリリースに必要な準備を自動化することでリリースの速度と安全性を向上させるだけでなく、品質の向上、コストの削減、チームメンバーのストレス軽減などのメリットもあります。 ただし、リリース自体は人が手動で実行する必要があるため、デプロイプロセスの設計と慎重なテストが必要です。 継続的デプロイメント 継続デプロイメントとは、ソフトウェア開発で変更を行うたびに、リポジトリから本番環境やテスト環境に自動的にリリースする手法です。この手法により、リリースのスピードを向上させることができます。継続的デプロイメントでは、ビルド、テスト、デプロイが自動化されているため、開発チームや運用チームの負担を軽減し、素早いリリースを実現できます。 継続的デプロイメントと継続的デリバリーの違いは、継続的デリバリーは本番環境にリリースする前に、人の承認作業が必要になる点です。一方、継続的デプロイメントでは変更が行われたらすぐに本番環境にリリースされるため、より迅速なリリースが可能です。 このように、継続的デプロイメントは、開発者がより頻繁に変更をリリースできるため、ユーザーのフィードバックをより早く反映することができます。 コミュニケーションと共同作業 DevOpsの成功には、運用チームと開発チームの共同作業が不可欠であり、そのためには組織内でのコミュニケーションが欠かせません。具体的には、チャットアプリやプロジェクト管理ツールなどのDevOpsツールを使用してリアルタイムで情報共有やコミュニケーションを促進することが重要です。例えば、SlackやMicrosoft Teamsなどのチャットアプリは、リアルタイムでチームメンバーと瞬時にコミュニケーションを取ることができ、問題点を素早く共有し、対応することができます。また、プロジェクト管理ツールの例として、Azure DevOpsやJiraなどがあり、タスクの進捗状況の共有やプロジェクト全体の進捗管理を行うことができます。これらのツールを活用することで、タスクの進捗状況や問題点の共有がスムーズになり、組織全体が目標に向かってより密接に連携できるようになります。 継続的フィードバック 継続的にフィードバックを得ることで、顧客のニーズに合わせた製品の改善が可能になります。具体的には、プロトタイプやモックアップのように開発の早期段階からフィードバックを獲得する方法や、A/Bテストやカナリヤリリースのように本番稼働中のシステムからフィードバックを獲得する方法があります。 このように、継続的にフィードバックを得ることで、開発チームは製品を改善し、より高品質な製品を提供できるようになることから、顧客との信頼関係を築くことができるようになります。 DevOpsを導入するメリット DevOpsはソフトウェア開発と運用のパフォーマンスと品質を向上させることができますが、その具体的なメリットは何でしょうか？DevOpsのメリットは以下のようなものがあります。 開発スピードの向上 DevOpsの考え方やプラクティスを取り入れることにより、開発と運用のプロセスを効率化し、自動化を促進することができます。これにより、開発者はより迅速にアプリケーションを開発することが可能になります。また、DevOpsにより、開発者と運用者がより密接に連携できるため、開発者はより早い段階でフィードバックを受け取ることができます。 信頼性の向上 自動化されたテストやデプロイメントプロセスを通じて、システムの品質を向上させることができ、信頼性の高い製品を提供できます。 生産性の向上 DevOpsの導入により、開発者と運用者はより迅速にシステムを開発・デプロイすることができます。またリリースまでのプロセスを迅速化することで、ユーザーのフィードバックを早く反映させることができ、生産性を向上させることができます。 共同作業性の向上 DevOpsツールにより、開発チームと運用チームがより密接に連携することができるので、コミュニケーションの障壁を取り除くことができます。またチーム全体でシステムの状態を把握できるため、共同作業性を向上させることができます。 拡張性の向上 DevOpsの考え方では、インフラストラクチャもアプリケーションコードと同様にコードで管理することが推奨されます。この手法をInfrastructure as Codeと呼び、インフラをコードで定義することで、標準化されたパターンでリリース、更新、複製が可能です。これにより、インフラと開発プロセスを統合し、システム全体をより効率的に管理できます。 セキュリティ面の向上 DevOpsでは、開発と運用のプロセスを効率化し、自動化を促進することが重視されます。この自動化の一環として、セキュリティポリシーに基づいた自動チェックが実装されることが望ましいです。これにより、継続的にビルド・テストされたコードは、セキュリティポリシーに基づいて自動的にチェックされ、安全なソフトウェアを迅速に提供できるようになります。 DevOpsモデルの導入方法 このように、DevOpsはソフトウェア開発と運用に多くのメリットをもたらしますが、導入には、いくつかの障壁があります。 DevOps導入の障壁 DevOps導入の障壁として、以下の2つが挙げられます。 企業文化の変革の必要性 DevOpsは、開発チームと運用チームが協力してソフトウェアの開発から運用までをスムーズに行うことを目指す仕組みです。しかし従来のシステム開発方針では、開発チームと運用チームは別々に働き、それぞれに異なる目標や評価基準が存在していました。そのため、DevOpsを導入する際には、両者の役割や責任を明確にし、コミュニケーションや協調性を高めるための企業文化の変革が必要になります。 ツールの選定 DevOpsを実現するためには、適切なツールを選定することが重要です。しかし、数多くのツールが存在するため、どれを選ぶべきか判断することは容易ではありません。 DevOpsを実現するためのツール DevOpsを実現するためには、AzureやAWSなどのクラウドプラットフォーム、CI/CDツール、コンテナ管理ツールなどが必要です。 クラウドプラットフォーム クラウドプラットフォームを利用すると、インフラの設定や管理を自動化し、環境を柔軟にスケールアップ・スケールダウンできます。AzureやAWSはその代表例です。 Azure Microsoftによる提供で、Windowsとの親和性が高い点が特徴です。AIやIoTなどの先進的な技術にも対応しています。 AWS Amazonによる提供で、最も普及しているクラウドプラットフォームの一つです。サーバーレスアーキテクチャやコンテナ技術、マイクロサービスなど、最新の技術にも対応しています。 CI/CDツール CI/CDツールには、コードをビルド・テストしてリリースまでの自動化を支援する機能があり、Azure DevOpsやAWS CodePipelineが代表的なツールとして知られています。 Azure DevOps Azureクラウド上で提供されます。コードの管理からビルド、テスト、リリースまでの一連のプロセスを一元管理できます。また、GitHubやJenkinsなどの外部ツールとの連携も可能です。 AWS CodePipeline AWSクラウド上で提供されるCI/CDツールです。このサービスもビルド、テスト、リリースなどのプロセスを自動化できます。AWSの各種サービスとの連携が容易です。 コンテナ管理ツール DevOpsにおいては、コンテナ技術を活用することが多いため、コンテナ管理ツールも重要な役割を担っています。コンテナのデプロイや管理、スケーリングなどを支援する機能があります。代表的なツールとして、Azure Kubernetes ServiceやAWS Elastic Kubernetes Serviceが挙げられます。 Azure Kubernetes Service Azure上で提供されるKubernetesベースのコンテナ管理ツールで、Kubernetesクラスタの作成、管理、スケーリングを自動化できます。Azureで稼働するアプリケーションをKubernetes上で実行できるため、高い可用性や拡張性を実現できます。 AWS Elastic Kubernetes Service AWS上で提供されるKubernetesベースのコンテナ管理ツールで、コンテナの管理、スケーリング、自動復旧などを支援します。Amazon EC2上でKubernetesクラスタを構築するため、EC2の自動スケーリングやロードバランシングなど、AWSの各種サービスとの連携が容易になります。 これらのツールは、DevOpsの実践をサポートするものであり、組織やプロジェクトの要件に応じて選択・組み合わせることが可能です。また、これらのツールを効果的に活用することで、開発プロセスの自動化や効率化、コラボレーションの強化が実現できます。ただし、ツール自体がDevOpsを実現するわけではなく、適切な文化やプロセスが整備された上でツールを使うことで、DevOpsの恩恵を最大限に活用できることを理解しておくことが重要です。 Four Keysの 4つの指標 DevOpsの実践においては、プロジェクトの進捗やチームの効率化を評価する為の指標が不可欠です。そのための指標として、GoogleのDevOps Research And Assessmentチームが提唱した「Four Keys」があります。この指標を使用することで、ソフトウェア開発チームは、自分たちのパフォーマンス評価し、改善することができます。 Four Keysは、以下の4つの指標から構成されています。 デプロイ頻度 変更リードタイム 変更障害率 平均修復時間 これらの指標を定期的に測定することで、開発チームは、ソフトウェアの品質を向上させるために必要な改善点を把握できます。自身のパフォーマンスを客観的に評価し、改善することができます。 以下に、4つの指標について解説します。 デプロイ頻度 デプロイ頻度とは、開発チームが新機能や修正をリリースする頻度を示します。デプロイ頻度が高いほど、開発チームが効率的にリリースを行っていることが示されます。 変更リードタイム 変更リードタイムは、コードの変更から、本番環境でリリースされるまでの時間を示します。短い変更リードタイムは、新機能やバグ修正に迅速に対応できることを示します。 変更障害率 変更障害率とは、デプロイが原因で本番環境で障害が発生する割合を指します。変更障害率が低いことは、開発チームが信頼性の高いソフトウェアを提供できていることを示します。 平均修復時間 平均修復時間は、障害が発生してから修復するまでにかかる時間を指します。平均修復時間を短縮することで、障害を早期発見し、迅速に対応できるようになります。 Four Keyの指標は、開発チームのパフォーマンスを測定するものであり、改善に役立ちます。これらの指標を把握することで、開発チームは自身のパフォーマンスを客観的に評価し、継続的に改善を繰り返すことで、より高品質なソフトウェアを提供することができます。 まとめ 本記事では、DevOpsの基本的な概念や導入メリットについて解説しました。DevOpsは、開発チームと運用チームのコラボレーションを促進し、より効率的な開発が可能になる手法であり、今後ますます重要性が高まることが予想されます。 この記事が、エンジニアの皆さんの今後のソフトウェア開発をよりよいものにする助けになれば幸いです。 The post DevOpsとは？基本知識や導入メリットを解説 first appeared on Sqripts .

ISO/IEC/IEEE 29119は、ソフトウェアテストに関する国際標準です。この標準を理解し、適用することで、ソフトウェアの品質を向上させることが期待されます。本記事では、 ISO/IEC/IEEE 29119を学ぶ理由やメリット、デメリットについて説明します。 ISO/IEC/IEEE 29119とは？ ISO/IEC/IEEE 29119は、国際標準化機構（International Organization for Standardization; ISO）によって開発されたソフトウェアテストに関する国際標準です。この標準は、いくつかの既存のテスト標準やベストプラクティスを統合し、現代のソフトウェア開発とテストのニーズに対応するように設計されています。 ISO/IEC/IEEE 29119の歴史は、2007年に始まります。ソフトウェアテストワーキンググループ（WG26）が、SC7（ISO（国際標準化機構）とIEC（国際電気標準会議）が共同で運営するJTC1（統合技術委員会1）の下で活動するサブコミッティー）の一部としてソフトウェアテスト標準を開発・維持するために2007年に設立され、新しいテスト標準の開発を開始しました。これは、以前のソフトウェアテスト標準（ISO/IEC 12207, ISO/IEC 15288, IEEE 829, IEEE 1008, BS 7925-1, BS 7925-2）が、それぞれ異なるアプローチや用語を使用しており、一貫性や適用範囲が限定的であったためです。 この新しい標準の目的は、ソフトウェアテストのプロセス、ドキュメント、技法に関する包括的で一貫性のある指針を提供することでした。その結果、 ISO/IEC/IEEE 29119は、5つのパートから構成される一連の標準として策定されました。 ISO/IEC 29119-1:2013 – ソフトウェアテストのための概念および定義 ISO/IEC 29119-2:2013 – ソフトウェアテストプロセス ISO/IEC 29119-3:2013 – ソフトウェアテストドキュメント ISO/IEC 29119-4:2015 – ソフトウェアテスト技法 ISO/IEC 29119-5:2016 – キーワード駆動型テスト 最初の4つのパートの作業が始まった直後、ISO/IEC 33063のテストプロセス評価（Part 2で定義されたテストプロセスに対する評価）が別の提案によって作成され、これに続いてISO/IEC/IEEE 29119-5のキーワード駆動型テストが開発されました。その後、WG26は、他の標準によってカバーされる動的テストを補完するために、レビューに関する別の標準（ISO/IEC 20246）を開発し、これが2017年に発行されました。 その他にも、以下に示すように、いくつかの分野で作業が進んでいます。 • 2020年発行 – AIベースのシステムのテストに関するガイドライン（ISO/IEC TR 29119-11） • 2021年発行 – アジャイルプロジェクトでのISO/IEC/IEEE 29119（すべてのパート）の使用に関するガイドライン（ISO/IEC TR 29119-6） • 進行中 – 自動車システム向けソフトウェアのテストでのISO/IEC/IEEE 29119の使用に関するガイドライン（ISO/IEC TR 29119-7） • 進行中 – モデルベースのテスト（ISO/IEC TR 29119-8） • 進行中 – ゲームテスト（ISO/IEC TR 29119-9） • 進行中 – 性能テスト（ISO/IEC 29119-10） • 進行中 – インシデント管理（ISO/IEC/IEEE xxxxx） • 進行中 – 生体認証システムのテストでのISO/IEC/IEEE 29119の使用に関するガイドライン（ISO/IEC 29119-13） • 進行中 – データ移行テスト（ISO/IEC TR 29119-14） • 進行中 – 静的解析（ISO/IEC 29119-15） • 進行中 – 大規模で複雑なシステムのテストに関するガイドライン（ISO/IEC TR 29119-16） 上記の標準番号にTRとついているものは技術報告書と呼ばれるもので、情報提供の意味合いが強く、厳密には国際規格(IS)とは異なります。また、インシデント管理の標準は、純粋にソフトウェアテストに関するものではないため、ISO/IEC 29119ソフトウェアテストシリーズの一部とは見なされず、ランダムな番号が割り当てられます。 国際規格は5年間毎に見直しがされ、必要であれば更新されます。実際、最初の4つのパートは2021年と2022年に更新されました。 • 2021年発行 – テストプロセス – 第2版（ISO/IEC/IEEE 29119-2） • 2021年発行 – テスト文書 – 第2版（ISO/IEC/IEEE 29119-3） • 2021年発行 – テスト技法 – 第2版（ISO/IEC/IEEE 29119-4） • 2022年発行 – 一般的な概念 – 第2版（ISO/IEC/IEEE 29119-1） ISO/IEC/IEEE 29119を学ぶ理由 ISO/IEC/IEEE 29119を学ぶ理由には内発的要因と外発的要因の2つあります。まずは、内発的要因ですが、主要な要因に以下の３つがあります。 a) 品質の向上 ソフトウェアテストは、品質を確保するための重要なプロセスです。 ISO/IEC/IEEE 29119は、テストプロセスの標準化を目指しており、学ぶことで品質向上につながります。 b) 信頼性の向上 ISO/IEC/IEEE 29119は、国際的な標準であり、それに従うことで、顧客やビジネスパートナーからの信頼を得ることができます。 c) 効率化 標準化されたテストプロセスは、効率的な作業ができるようになります。これにより、開発サイクルが短縮され、コスト削減にもつながります。 次に外発的要因ですが、ISO/IEC/IEEE 29119は国際規格である性格上、その準拠が求められることが挙げられます。ISO/IEC/IEEE 29119の準拠が求められる場合は、主に以下のような状況です。 a) クライアントの要求 顧客やクライアントが、ソフトウェア開発プロジェクトやテスト活動においてISO/IEC/IEEE 29119に準拠することを要求することがあります。これは、品質保証のための一般的な基準を確立し、プロジェクトのリスクを低減するためです。 b) 法規制や業界標準 特定の業界や分野では、法規制や業界標準によってISO/IEC/IEEE 29119に準拠することが求められることがあります。これは、ソフトウェアの安全性や信頼性を確保し、利害関係者に対する責任を果たすためです。 c) 国際的な取引 多国籍企業や国際的なプロジェクトでは、異なる国や地域の組織間で一貫した品質基準を確立するために、ISO/IEC/IEEE 29119に準拠することが求められることがあります。 ISO/IEC/IEEE 29119のメリット ISO/IEC/IEEE 29119を導入するメリットは多くありますが、主なものは以下の4つになります。 a) 組織全体での共通言語 ISO/IEC/IEEE 29119を導入することで、組織内でのコミュニケーションが円滑になります。共通の言語を持つことで、誤解やミスが減少し、作業効率が向上します。 b) テストプロセスの標準化 テストプロセスが標準化されることで、繰り返し実施するテストの品質が向上します。また、新しいプロジェクトに対しても、テストプロセスを迅速に適用できます。 c) ドキュメントの統一 ISO/IEC/IEEE 29119は、ドキュメントのフォーマットや内容も規定しています。これにより、ドキュメントの品質が向上し、情報の共有や管理が容易になります。 d) トレーサビリティの向上 標準化されたドキュメントやプロセスにより、テストのトレーサビリティが向上します。これにより、問題が発生した際に原因を特定しやすくなり、迅速な対応が可能となります。 ISO/IEC/IEEE 29119のデメリット ISO/IEC/IEEE 29119の導入はメリットだけではなく、考慮しなければいけないデメリットも存在します。主なものは、以下の3つです。 a) コストと時間 ISO/IEC/IEEE 29119を導入するには、初期費用や研修費用が必要です。また、標準に沿ったプロセスやドキュメントを整備するための時間も必要となります。 b) 柔軟性の低下 標準化されたプロセスやドキュメントは、柔軟性が低下する可能性があります。特定のプロジェクトに対して最適な方法が標準と異なる場合、適応が難しくなることがあります。 c) 過剰な成果物 ISO/IEC/IEEE 29119は、ドキュメントやプロセスに関して詳細な規定をしています。これが、場合によっては過剰な成果物を生む可能性があり、作業効率が低下することがあります。 まとめ ISO/IEC/IEEE 29119は、ソフトウェアテストに関する国際標準であり、品質や信頼性の向上、効率化に役立ちます。また、組織全体での共通言語やドキュメントの統一、トレーサビリティの向上などのメリットがあります。一方で、コストや時間、柔軟性の低下、過剰なフォーマリティなどのデメリットも考慮する必要があります。 学ぶ理由やメリット、デメリットを理解した上で、組織のニーズや状況に応じて ISO/IEC/IEEE 29119の導入を検討してください。適切に適用することで、ソフトウェアの品質向上や効率化に大きく貢献することができます。 The post ISO/IEC/IEEE 29119とは? 学ぶ理由、メリット、デメリットを分かりやすく解説 first appeared on Sqripts .

こんにちは！フロントエンドエンジニアのつかじです。 今回はNext.jsアプリケーションに Microsoft Clarity を導入してみたいと思います。Microsoft Clarityは、ユーザーエクスペリエンスを向上させるための無料の分析ツールです。このツールを使って、ユーザーの行動を理解し、アプリケーションのパフォーマンスを最適化しましょう。 なぜMicrosoft Clarityを導入するのか？ Microsoft Clarityは、ウェブサイトのユーザーエクスペリエンスを向上させることを目的とした無料の分析ツールです。Clarityを導入する際の具体的な目的は下記の通りです。 ユーザー行動の理解 ヒートマップやセッション再生機能を利用して、ユーザーがウェブサイトでどんな行動をしているのかを知ることができます。これで、ユーザーのニーズや問題点を見つけ出し、対応策を考えることができます。 ユーザビリティの向上 セッション再生機能を利用して、ユーザーがウェブサイトで困っている場所や、ナビゲーションが難しいところを特定することができます。それらの問題を解決するための改善策を実施することでウェブサイトをもっと使いやすくできます。 コンテンツの最適化 ヒートマップ機能を利用して、ユーザーが最も興味を持っているコンテンツや、なかなかスクロールされないエリアを特定できます。これを参考に、コンテンツの配置やデザインを工夫し、ユーザーの興味を引くサイトに仕上げることができます。 コンバージョン率の向上 インサイトを利用して、コンバージョンまでのユーザーの動きを調べ、コンバージョンの障害となるポイントを見つけ出します。これを解決することで、コンバージョン率を向上させることができます。 デバイスやブラウザの最適化 インサイトダッシュボードで、ユーザーがどんなデバイスやブラウザを使っているのかを調べ、それに合わせて最適化を行います。これにより、すべてのユーザーに適したウェブサイトの提供が可能になります。 Next.jsアプリケーションへMicrosoft Clarityを導入する 1. Microsoft Clarityのアカウント作成 まずはじめに、 Microsoft Clarityのウェブサイト にアクセスし、アカウントを作成します。 アカウント作成が完了したら、プロジェクトを追加して、トラッキングコードを取得します。このトラッキングコードがNext.jsアプリケーションに必要になります。プロジェクトの追加はウェブサイト名とURLのみの入力で簡単に登録可能です。 2. Next.jsアプリケーションにトラッキングコードを追加 さて、Microsoft Clarityのトラッキングコードを手に入れたら、次はNext.jsアプリケーションに導入していきます。以下の手順で導入できます。 １． _document.tsx ファイルを作成する pages フォルダ内に _document.tsx ファイルを作成します。すでに作成済みの場合は、そのファイルを開いてください。 ２．Microsoft Clarityのトラッキングコードを追加する _document.tsx ファイルの <Head> タグ内に、Microsoft Clarityのトラッキングコードを追加し、デプロイを行います。 ※ YOUR_TRACKING_CODE の部分は、実際のトラッキングコードに置き換えてください。 import Document, { Head, Html, Main, NextScript } from "next/document"; class MyDocument extends Document { render() { return ( <Html> <Head> {/* ここにトラッキングコードを追加 */} <script type="text/javascript" dangerouslySetInnerHTML={{ __html: ` (function(c,l,a,r,i,t,y){ c[a]=c[a]||function(){(c[a].q=c[a].q||[]).push(arguments)}; t=l.createElement(r);t.async=1;t.src="https://www.clarity.ms/tag/"+i; y=l.getElementsByTagName(r)[0];y.parentNode.insertBefore(t,y); })(window, document, "clarity", "script", "YOUR_TRACKING_CODE"); `, }} /> </Head> <body> <Main /> <NextScript /> </body> </Html> ); } } export default MyDocument; 以上で導入は完了です。簡単でしたね。 Microsoft Clarityのダッシュボードでユーザー行動のデータが表示されるようになります。ヒートマップやセッション再生などの機能を使って、ユーザーの行動を分析し、アプリケーションの最適化を行いましょう。 終わりに Next.jsアプリケーションへMicrosoft Clarity導入はかなり簡単でしたね。Microsoft Clarityと統合することで、無料で分析データを取得し、ウェブサイトのユーザーエクスペリエンスを向上させることができます。これらの情報を活用して、ウェブサイトを改善し、より多くのユーザーにとって魅力的なコンテンツを提供しましょう。 The post Next.jsアプリケーションにMicrosoft Clarityを導入してユーザーエクスペリエンスを向上させよう！ first appeared on Sqripts .

テスト駆動開発のスタイルを取り入れているもののテストのことはあまりよくわかっていないプログラマーと、テストへの熱い情熱をもちつつプログラマーの事情はわかっていないテスターとが、小さな障害の発見をきっかけとして出会い、役割の壁を崩しながら少しずつ協調するようになっていく、小さなお話です。 登場人物 プロ之 … プログラマー テス緒 … テスター 前回、プロ之さんとテス緒さんは協力して、問題の原因が古いIE対応サービスにあることを突き止めました。しかし、IE対応サービスはすでにサポート外でサービスも停止済みであることがわかりました。プロ之さんは停止済みサービスが今後問題を起こすはずがないと結論し、テス緒さんは原因追及が振り出しに戻ってしまい途方に暮れています。 問題はどこにいった？ プロ之さんはIE対応サービスが1年以上前に終了していると聞き、自分の目でもゲートウェイが存在せずクラスター内にも稼働していないことを確認しました。テス緒さんと調べていた問題がIE対応サービスに存在していたとしても、実行されなければ今後問題になるはずがありません。修正する意味もありません。 「(完全に時間の無駄だっただろうか？)」プロ之さんは考えてみました。「(そんなことはない)」とプロ之さんは自分で答えました。調査を通じて新しく学んだことは多く、テストの考え方や観点も参考になるし、今後テストチームとコミュニケーションするときもスムーズにできそうです。「(一定の満足が得られた、有意義な活動だった)」そう結論しながら、イシュー管理システムにテス緒さんが数週間前に作ったチケットを、開発チームの担当者として「対応なし」でクローズしようとしました。 その寸前に、テス緒さんからチャットのメッセージが届きました。「ちょっと相談できる？」 プロ之さんはメッセージで返信しました。「いまチケットをクローズするところです。どんな相談ですか？」 テス緒(以下、T)「問題の他の原因について」 プロ之(以下、P)「原因は判明しました。発生した現象と完全に一致しています。他の可能性は考えられません。今後実行しないコードなのでこれ以上問題は起きません。これ以上の調査と対応は優先順位を下げるべきです」 T「そうだよね、でもおかしい気がして。話せない」 P「これまでの調査や議論は無駄ではなかったと考えています。テス緒さんにもいろいろ教えていただきましたし、有意義でした。ですが今回の問題はクローズです。いまクローズするところです。そうしないとチームリーダーにも文句を言われます」 突然背後で呼び出し音が鳴り、プロ之さんは飛び上がりました。鳴ったのは社用携帯電話で、開発チームの緊急連絡用なのでめったに使いません。プロ之さんは用心して、通話をスピーカーフォンモードにしました。 携帯電話からはテス緒さんのあわてた声が聞こえてきました。「ああよかった、番号間違えたかと思った。どうしても話をしたくって。あ、すみません、番号間違ってないですよね？ プロ之さんだよね？」 P「そうです」 T「よかった！ もうこれからどうしたらいいかわかんなくなっちゃって、リーダーにも次の作業をせっつかれるし、相談に乗ってもらえないし、プロ之さんもう話してくれないし、調べても無駄とか話しても有意義じゃないとか冷たいし」 P「そんなことは言ってません。ですが現時点ではやるべきことをやりました。これ以上は優先順位を下げるべきです。問題のコードが書かれたのはずいぶん前なので十分な調査ができる気はしません。1年以上動作していませんし…」 「1年前！」テス緒さんの大声で携帯電話が震えました。「ちょっと待ってちょっと見て日付」 プロ之さんからのチャットで大量のログが送られてきました。大量すぎて内容は把握できませんが、日付の部分を眺めると1ヶ月か2ヶ月前のものになっています。 T「見て！ IE対応サービスが1年以上動いてないのに、このログは1ヶ月前なんだよ！ データがおかしくなっているところも、最近1年以内にあったはず。だからきっとほかに原因があるはずで…プロ之さん？ 聞いてる？」 プロ之さんは考え込んでいて、聞こえていませんでした。「(あのコードは1年以上動いていない。このログを出すのはあのコードしかあり得ない。このログは1ヶ月前に、本番環境で出ている。ということは)」 「あのコードがどこかで動いている」プロ之さんは声に出して言いました。 テス緒さんは聞き返します。「でもIE対応のサービスは動いていないんでしょう？」 「動いていないはずです。それが理論的推論です。ですが動いています。これは観測した事実です。推論と事実では、必ず事実が勝ちます。コードは動いています」プロ之さんは断言しました。 2人のヒートアップしたやり取りから、新たな可能性が見えてきました。プロ之さんは調査結果から自分の結論を出しました。テス緒さんは、うまく言葉にできないもやもやを抱えながら、プロ之さんのヒントに新たな糸口を見出しました。 ここでは、プロ之さんが冷静な判断を見せています。調査結果自体は事実ですが、そこから論理的に出した結論は推論です。推論は強力な武器ですが、もしそれに反する証拠や事実が新たに見つかったら、間違っているのは推論のほうです。見つかった事実に合わせて、論理を組み立て直すことになります。 そして2人がヒートアップしながらも、相手を非難したり、萎縮させたりはしていない点にも注目できます。同じことを同じように言っても、相手によっては攻撃を受けたように感じたり、守りに入ったりして、率直な議論ができなくなる場合があります。この2人がこれまで積み重ねてきた関係性とお互いへの信頼があるからこそ、第三者から見たら激しく見えるようなやりとりでも建設的になります。2人それぞれの性格も、関係あるかもしれません。 ポイント: 観測した事実と論理で導かれる可能性を統合して問題を絞り込む 信頼関係を積み重ねているからこそ率直な議論ができる それは人の問題で、チームの問題 ここからは後日談になります。プロ之さんはログを出力しているインスタンスを見つけ、インスタンスの内部を調査して、本来は存在しないはずの該当コードがデプロイされているのを確認しました。さらにインスタンス固有のAPI設定を手で書き換えた形跡があり、そのせいで呼び出されないはずのIE対応サービスのコードが実行されていたことがわかりました。その特定のインスタンスでのみ発生する現象だったため、これまで見落とされてきたのです。 この発見は開発チームと運用チーム両方で重大な問題として調査することになりました。その結果、2年前に大規模なリリースをしたとき、開発者が動作確認をするため一時的にIE対応サービスのコードをデプロイし、APIの設定も書き換えていたのですが、それを元に戻し忘れていたことがわかりました。作業ミスをしたのは、なんと今の開発チームリーダーだったとのことです。 対応としてAPI設定を正しく直したのはもちろんですが、このような作業ミスが起きたこと、それを今まで見逃してきたことも問題視され、対策が検討されました。開発リーダーのような優秀な人でもミスをするのだから、本番環境を直接操作するような運用は危ないと再認識され、リリース作業の自動化が前進しました。また不要なコードのデプロイ防止策として、リリースノートをテストチームと共同で書くという案を検討しています。 テストチームでもテスト観点を見直しました。ソフトウェアを動かして確認するだけでは見落としが発生するという認識から、デプロイプロセスの確認や、設定内容の確認などもテストに含めることにしたのです。こうした確認の一部は開発チームの力を借りて自動化されました。テス緒さんが「同じ内容のテストを手で繰り返すなら自動化すべき」と主張したのが採用されたそうです。 ポイント: ソフトウェアの問題は、誰かが「やらかした」結果なので、人の問題と言える 起きた問題ではなくその原因を直しに行く。問題が起きないように直す 問題を解決した！さてお次は？ いろいろな変化が起きていく中で、プロ之さんとテス緒さんは久しぶりにリアルで顔を合わせました。 T「やー、なんだか大変なことになっちゃったね。手順も変わるしツールも新しくなるし。よく、お前のせいだからな！ ってリーダーに言われるんだよ。笑いながらだけど」 P「私たちのせいではありません。タイミング良く見つけただけです。開発リーダーも少し静かになっていましたが、今は新しいことに取り組むのに忙しそうです」 T「開発リーダーさんは新しいこと好きそうだよね。でもこれが落ち着いたら、いろいろ良くなりそう。テストチームでもテスト自動化を勉強してるんだよ」 P「開発プロセスが現代的になりそうですし、DevOpsの考え方も進んでいます。良くなりそうですね」 テストで見つかった問題をきっかけとして、各チームが対策を取り、チーム間の協力も強化されそうです。失敗から学べる、優秀な組織のようです。人為的ミスを減らす工夫は、品質にも良い影響がありますし、作業の効率化にもつながります。問題への見事な対応だと言えます。 G.M.ワインバーグの著書『コンサルタントの秘密』(1990, 共立出版)に、こんな言葉が紹介されています。 第一番の問題を取り除くと、第二番が昇進する 一番の問題、いま最も重要な問題、まず解決すべき問題を無事に解決できたら、それは素晴らしいことです。しかし同時に、それまで二番手だった問題がトップに躍り出てきます。問題に対処しても問題はなくならない、また次の問題が現れるだけであるという法則です。[ 1 ] T「ところでね、昨日こんな不思議な現象があったんだけど…」 P「テストチームのテスト自動化で、気になることが…」 2人もまた新たな問題を見つけたようです。問題は途切れないかもしれませんがひとつずつ片付ければ、ひとつずつ状況を良くしていけます。小さな問題でも大きな問題でも、根本的な原因をたどって改善のきっかけにできます。こんどの問題は簡単なものでしょうか、チームやプロダクト全体を巻き込むようなものでしょうか、はたまた…？ ポイント: 問題を解決しても問題はなくならない。次の問題が登場する チームの品質とプロダクトの品質を両方とも改善していく 本連載は今回が最終回となります。最後まで読んでいただき、ありがとうございます。 [1] 書籍ではワインバーグが13歳の時、スーパーでアルバイトをした話が紹介されています。そこで、野菜売場でルタバガ(カブに似た野菜)の売れ行きがとても悪いことに気づきました。野菜売場責任者のルウディーが売場スペースを整理しようとして、ワインバーグになにかアイデアがないか聞きました。ルタバガを減らすのはどうかとワインバーグが答え、ルウディーはその案を喜んで採用します。ルウディーはルタバガを片付けてから、こうワインバーグに聞きました。 「で、ルタバガの次は何だね」 問題をひとつ片付ければ、次の問題が登場します。おまけにそれも片付けるよう期待されてしまうかもしれません。これが「ルウディーのルタバガの法則」です。 第4回：立場を越えて問題を追及しよう 第3回：大事(だいじ)なことが本当に大事か確かめよう 第2回：それぞれの得意をつなぎ合わせよう 第1回：引っかかりを感じたら相談しよう The post 【テスターと開発者が上手に協力するには】第5回：テストを通じてチームとプロダクトとに貢献しよう first appeared on Sqripts .

こんにちは！フロントエンドエンジニアのつかじです。 皆さんはREST APIクライアントをどのように開発していますか？私はAPIクライアントを手作業で作成するのは手間がかかるため、普段のプロダクト開発ではOpenAPI Generatorを使って自動生成しています。しかし先日、Microsoftが新しいAPIクライアント生成ツール「Kiota」を 発表 しました。気になった方も多いのではないでしょうか？ 今回は、Microsoftから新しく発表されたAPIクライアント生成ツール「Kiota」を使って、Node.js(TypeScript)のプロジェクトでAPIクライアントを生成し、実際に動かしてみたいと思います。 1. Kiotaのインストール こちら の公式ドキュメントを参照してインストールします。 ※ 私は.NET toolでインストールしました 2. Node.js(Typescript)サンプルプロジェクト作成 npm init npm install -D typescript ts-node npx tsc --init 3. Kiotaの依存パッケージをインストール Kiotaが生成したAPIクライアントのビルド、実行のために抽象化パッケージへの参照が必要です。 npm install @microsoft/kiota-abstractions npm install @microsoft/kiota-http-fetchlibrary npm install @microsoft/kiota-serialization-form npm install @microsoft/kiota-serialization-json npm install @microsoft/kiota-serialization-text 4. KiotaでAPIクライアントを生成 今回は Swagger PetStore からAPIクライアントを生成したいと思います。 Swagger PetStoreは、Swagger（現在のOpenAPI）のサンプルAPIで、ペットストアの基本的な操作を提供しています。Swagger PetStoreは、APIの定義、実装、ドキュメント化のデモンストレーションを目的として設計されており、試すことができます。 Kiota CLIにて下記のコマンドを実行 kiota generate -l typescript -d <https://petstore.swagger.io/v2/swagger.json> -c PetStoreClient -o ./petstore-client すると、 petstore-client ディレクトリ以下に下記のAPIクライアントのコードが無事に生成されました！ . ├── kiota-lock.json ├── models │ ├── apiResponse.ts │ ├── category.ts │ ├── createApiResponseFromDiscriminatorValue.ts │ ├── createCategoryFromDiscriminatorValue.ts │ ├── createOrderFromDiscriminatorValue.ts │ ├── createPetFromDiscriminatorValue.ts │ ├── createTagFromDiscriminatorValue.ts │ ├── createUserFromDiscriminatorValue.ts │ ├── index.ts │ ├── order.ts │ ├── order_status.ts │ ├── pet.ts │ ├── pet_status.ts │ ├── tag.ts │ └── user.ts ├── pet │ ├── findByStatus │ │ ├── findByStatusRequestBuilder.ts │ │ ├── findByStatusRequestBuilderGetQueryParameters.ts │ │ └── findByStatusRequestBuilderGetRequestConfiguration.ts │ ├── findByTags │ │ ├── findByTagsRequestBuilder.ts │ │ ├── findByTagsRequestBuilderGetQueryParameters.ts │ │ └── findByTagsRequestBuilderGetRequestConfiguration.ts │ ├── item │ │ ├── createWithPetPostRequestBodyFromDiscriminatorValue.ts │ │ ├── index.ts │ │ ├── uploadImage │ │ │ ├── uploadImageRequestBuilder.ts │ │ │ └── uploadImageRequestBuilderPostRequestConfiguration.ts │ │ ├── withPetItemRequestBuilder.ts │ │ ├── withPetItemRequestBuilderDeleteRequestConfiguration.ts │ │ ├── withPetItemRequestBuilderGetRequestConfiguration.ts │ │ ├── withPetItemRequestBuilderPostRequestConfiguration.ts │ │ └── withPetPostRequestBody.ts │ ├── petRequestBuilder.ts │ ├── petRequestBuilderPostRequestConfiguration.ts │ └── petRequestBuilderPutRequestConfiguration.ts ├── petStoreClient.ts ├── store │ ├── inventory │ │ ├── createInventoryResponseFromDiscriminatorValue.ts │ │ ├── index.ts │ │ ├── inventoryRequestBuilder.ts │ │ ├── inventoryRequestBuilderGetRequestConfiguration.ts │ │ └── inventoryResponse.ts │ ├── order │ │ ├── item │ │ │ ├── withOrderItemRequestBuilder.ts │ │ │ ├── withOrderItemRequestBuilderDeleteRequestConfiguration.ts │ │ │ └── withOrderItemRequestBuilderGetRequestConfiguration.ts │ │ ├── orderRequestBuilder.ts │ │ └── orderRequestBuilderPostRequestConfiguration.ts │ └── storeRequestBuilder.ts └── user ├── createWithArray │ ├── createWithArrayRequestBuilder.ts │ └── createWithArrayRequestBuilderPostRequestConfiguration.ts ├── createWithList │ ├── createWithListRequestBuilder.ts │ └── createWithListRequestBuilderPostRequestConfiguration.ts ├── item │ ├── withUsernameItemRequestBuilder.ts │ ├── withUsernameItemRequestBuilderDeleteRequestConfiguration.ts │ ├── withUsernameItemRequestBuilderGetRequestConfiguration.ts │ └── withUsernameItemRequestBuilderPutRequestConfiguration.ts ├── login │ ├── loginRequestBuilder.ts │ ├── loginRequestBuilderGetQueryParameters.ts │ └── loginRequestBuilderGetRequestConfiguration.ts ├── logout │ ├── logoutRequestBuilder.ts │ └── logoutRequestBuilderGetRequestConfiguration.ts ├── userRequestBuilder.ts └── userRequestBuilderPostRequestConfiguration.ts 5. Kiotaで生成されたAPIクライアントでAPIを叩く 次に、生成されたAPIクライアントを使って、実際にSwagger PetStore APIにアクセスしてみましょう。 以下のサンプルコードを** index.ts **というファイル名でプロジェクトディレクトリに作成し、 import { AnonymousAuthenticationProvider } from "@microsoft/kiota-abstractions"; import { FetchRequestAdapter } from "@microsoft/kiota-http-fetchlibrary"; import { PetStoreClient } from "./petstore-client/petStoreClient"; (async () => { const authProvider = new AnonymousAuthenticationProvider(); const adapter = new FetchRequestAdapter(authProvider); const client = new PetStoreClient(adapter); const pet = await client.petById("1").get(); console.log(pet); })(); 実行すると、コンソールログにレスポンスの内容が表示されます。これでSwagger PetStore APIとのやりとりができるようになりました！ おわりに 今回は、Microsoftから発表されたばかりのKiotaを使って、TypeScriptのAPIクライアントを簡単に生成することができました。Kiotaは新しいプロジェクトであり、まだ発展途上ですが、今後の機能追加や言語サポートにも期待大ですね！みなさんもぜひ試してみてください！ The post Microsoftの新しいAPIクライアント生成ツールKiotaを試してみた first appeared on Sqripts .

テスト自動化のお仕事をしているきむらです。 Windowsアプリの自動操作に興味があるけど、自動化ツールが色々あってよくわからない。 自動化ツールのセットアップとか難しそう。。 そんな、自動化の世界に飛び込めずにいる方のために、自動化ツールをインストールしないで、Windowsに標準搭載されている「UI オートメーション」機能を使って、アプリを自動操作する方法を紹介したいと思います。 用意したPowerShellのスクリプトをコピペして実行するだけで体験できますので、気楽な感じでお付き合いいただければと思います。 環境 この記事のPowerShellスクリプトは下記の環境で動作確認しています。 Microsoft Windows 10 Pro 22H2 PowerShell 5.1.19041.2673 Microsoft Windows 11 Pro 22H2 PowerShell 5.1.22621.963 Microsoft Edge 112.0.1722.58 UIオートメーションとは 「UIオートメーション」は、ざっくり言うと「ユーザーインターフェイスをプログラムから操作したりすることができる」機能で、Windowsに標準搭載されています。 もっと詳しく知りたい方は「 UI オートメーションの概要 」をご参照ください。 Windows PowerShell ISEを起動する 「Windows PowerShell ISE」はWindowsに標準搭載されているPowerShellの統合開発環境で、PowerShellスクリプトを効率的に作成することができるアプリです。 タスクバーの検索ボックスに「powershell」を入力して、検索結果から「Windows PowerShell ISE」を選択して起動します。起動したら、ツールバーの「スクリプトを新規作成します」ボタンを選択します。（またはメニューバーから [ファイル] > [新規作成] を選択します。） 上半分の背景が白色のウィンドウが「スクリプトウィンドウ」で、こちらにスクリプトをコピペしていきます。 下半分の背景が紺色のウィンドウは「コンソールウィンドウ」で、コマンドを入力・実行したりするウィンドウです。 UIを自動操作するための土台となるスクリプトコピペする まずは、UIを自動操作するための土台となるスクリプトをコピペします。 このスクリプトには、要素をクリックしたり、キーボード操作をする関数（部品のようなもの）が書かれていて、この関数を使って自動操作をおこないます。 下記のスクリプトをコピーします。 # Windows PowerShellでアプリを自動操作するスクリプト # UI オートメーションを使うための準備 Add-Type -AssemblyName "UIAutomationClient" Add-Type -AssemblyName "UIAutomationTypes" $AutomationElement = [System.Windows.Automation.AutomationElement] $TreeScope = [System.Windows.Automation.TreeScope] $Condition = [System.Windows.Automation.Condition] $InvokePattern = [System.Windows.Automation.InvokePattern] $SendKeys = [System.Windows.Forms.SendKeys] $Cursor = [System.Windows.Forms.Cursor] # マウスの左クリック操作をおこなうための準備 $SendInputSource =@" using System; using System.Drawing; using System.Runtime.InteropServices; using System.Windows.Forms; public class MouseClick { [StructLayout(LayoutKind.Sequential)] struct MOUSEINPUT { public int dx; public int dy; public int mouseData; public int dwFlags; public int time; public IntPtr dwExtraInfo; } [StructLayout(LayoutKind.Sequential)] struct INPUT { public int type; public MOUSEINPUT mi; } [System.Runtime.InteropServices.DllImport("user32.dll")] extern static uint SendInput(uint cInputs, INPUT[] pInputs, int cbSize); public static void Click() { INPUT[] input = new INPUT[2]; input[0].mi.dwFlags = 0x0002; input[1].mi.dwFlags = 0x0004; SendInput(2, input, Marshal.SizeOf(input[0])); } } "@ Add-Type -TypeDefinition $SendInputSource -ReferencedAssemblies System.Windows.Forms, System.Drawing $MouseClick = [MouseClick] # 要素を取得する関数 function GetElements { Param($RootWindowName = $null) if ($RootWindowName -eq $null) { try { return $AutomationElement::RootElement.FindAll($TreeScope::Subtree, $Condition::TrueCondition) } catch { return $null } } else { $childrenElements = $AutomationElement::RootElement.FindAll($TreeScope::Children, $Condition::TrueCondition) foreach ($element in $childrenElements) { if ($element.GetCurrentPropertyValue($AutomationElement::NameProperty) -eq $RootWindowName) { return $element.FindAll($TreeScope::Subtree, $Condition::TrueCondition) } } Write-Host "指定された名前 '${RootWindowName}' のウィンドウが見つかりません。" } return $null } # 要素を検索する関数 function FindElement { Param($RootWindowName = $null, $PropertyType, $Identifier, $Timeout) $startTime = (Get-Date).Ticks do { foreach ($element in GetElements -RootWindowName $RootWindowName) { try { if ($element.GetCurrentPropertyValue($AutomationElement::$PropertyType) -eq $Identifier) { return $element } } catch { continue } } } while (((Get-Date).Ticks - $startTime) -le ($Timeout * 10000)) throw "指定された要素 '${Identifier}' が見つかりません。" } # クリック操作をおこなう関数 function ClickElement { Param($RootWindowName = $null, $PropertyType, $Identifier, $Timeout = 5000) $startTime = (Get-Date).Ticks do { $element = FindElement -RootWindowName $RootWindowName -PropertyType $PropertyType -Identifier $Identifier -Timeout $Timeout $isEnabled = $element.GetCurrentPropertyValue($AutomationElement::IsEnabledProperty) if ($isEnabled -eq "True") { break } } while (((Get-Date).Ticks - $startTime) -le ($Timeout * 10000)) if ($isEnabled -ne "True") { throw "指定された要素 '${Identifier}' が有効状態になりません。" } if ($element.GetCurrentPropertyValue($AutomationElement::IsInvokePatternAvailableProperty) -eq "True") { $element.GetCurrentPattern($InvokePattern::Pattern).Invoke() } else { # IsInvokePatternAvailablePropertyがFalseの時はマウスカーソルを要素に移動して左クリックする $clickablePoint = $element.GetClickablePoint() $Cursor::Position = New-Object System.Drawing.Point($clickablePoint.X, $clickablePoint.Y) $MouseClick::Click() } } # キーボード操作をおこなう関数 function SendKeys { Param($RootWindowName = $null, $PropertyType, $Idendifier = $null, $Keys, $Timeout = 5000) if ($Idendifier -ne $null) { $element = FindElement -RootWindowName $RootWindowName -PropertyType $PropertyType -Identifier $Idendifier -Timeout $Timeout $element.SetFocus() } $SendKeys::SendWait($Keys) } # Microsoft EdgeでWebキャプチャの保存操作をおこなう関数 function SaveWebCaptureByMicrosoftEdge { SendKeys -Keys "^(+S)" ClickElement -PropertyType "AutomationIdProperty" -Identifier "view_52561" ClickElement -PropertyType "AutomationIdProperty" -Identifier "save_button_id" Start-Sleep -Seconds 3 SendKeys -Keys "{ESCAPE}" } # ↓↓↓↓↓ この行以降にアプリを自動操作するスクリプトを書く ↓↓↓↓↓ 次に「Windows PowerShell ISE」のスクリプトウィンドウに貼り付けます。 「ここで一度ファイルに保存しておこうかな」となるかもしれませんが、 ここでは保存しないでください。 ファイルに保存すると、PowerShellの実行ポリシーの設定によってはスクリプトが実行できなくなるためです。 PowerShellの実行ポリシーについてはあとで説明します。 電卓を自動操作するスクリプトをコピペして実行する では、Windowsアプリの自動操作の練習台として定番（？）の電卓を自動操作してみましょう。 「電卓を起動して、1から10までを足し算する操作」を自動操作してみます。 下記のスクリプトをコピーします。 ################################################################################ # 電卓を自動操作する ################################################################################ # 足し算する値の範囲を設定する $start = 1 $end = 10 # ボタンをクリックした後の待機ミリ秒を設定する $waitMilliseconds = 300 # 電卓アプリを開始する Start-Process calc -Wait # 電卓アプリを操作する foreach ($count in $start..$end) { # 数値を1桁ずつに分割する $array = $count.ToString().ToCharArray() # 電卓アプリの数値ボタンをクリックする foreach ($number in $array) { ClickElement -RootWindowName "電卓" -PropertyType "AutomationIdProperty" -Identifier "num${number}Button" Start-Sleep -Milliseconds $waitMilliseconds } # 現在のカウントで処理を分岐する if ($count -ne $end) { # 範囲の終わり以外の時は[＋]ボタンをクリックする ClickElement -RootWindowName "電卓" -PropertyType "AutomationIdProperty" -Identifier "plusButton" Start-Sleep -Milliseconds $waitMilliseconds } else { # 範囲の終わりの時は[＝]ボタンをクリックする ClickElement -RootWindowName "電卓" -PropertyType "AutomationIdProperty" -Identifier "equalButton" Start-Sleep -Milliseconds $waitMilliseconds } } 次に、スクリプトウィンドウの「141行目」に貼り付けます。 これで準備ができました。 では、ツールバーの緑色の「 ︎」（スクリプトを実行）ボタンを選択して、スクリプトを実行してみましょう。 電卓が起動して、1から10までを足し算する操作がおこなわれて、計算結果に55が表示されます。 操作間隔を空けずに自動操作する 実行したスクリプトは、自動操作の様子を確認しやすいように操作の間隔を空けています。 自動操作の間隔を空けずに実行するとどうなるか見てみましょう。 「1から10までの足し算」はあっと言う間に終わってしまいますので、ついでに足し算する範囲を「1から100まで」に変更してみましょう。 まず、スクリプトの147行目の「 $end = 10  」を「 $end = 100 」に編集します。 145 # 足し算する値の範囲を設定する 146 $start = 1 147 $end = 100 次に、スクリプトの150行目の「 $waitMilliseconds = 300 」を「 $waitMilliseconds = 0 」に編集します。 149 # ボタンをクリックした後の待機ミリ秒を設定する 150 $waitMilliseconds = 0 ツールバーの緑色の「 ︎」（スクリプトを実行）ボタンを選択して、スクリプトを実行してみましょう。なお、スクリプトの実行を途中で停止したい時は、ツールバーの赤色の「■」（操作の停止）ボタンを選択します。電卓が起動して、1から100までを足し算する操作が爆速でおこなわれて、計算結果に5050が表示されます。筆者の環境では、自動操作の間隔を空けた時の実行所要時間は「およそ1分50秒」で、間隔を開けない時の実行所要時間は「およそ15秒」でした。 Microsoft Edgeを自動操作するスクリプトをコピペして実行する 続いて、ブラウザを自動操作するスクリプトを紹介します。 ブラウザの自動操作は「Selenium」や「Autify」、「mabl」などの自動化ツールを使う方が多いかもしれませんが、ちょっとした操作であれば「UI オートメーション」でも自動操作することができます。 今回は「Microsoft Edgeを起動して、Bingのトップページを開いたあとに、検索とWebキャプチャを保存する操作をおこない、最後にダウンロードフォルダーを開く」操作を自動操作してみます。 「Microsoft Edge」を初めて使う場合は、初回実行時の設定が必要になりますので、一度「Microsoft Edge」を起動して初回実行時の設定を完了させておいてください。 また、アドレスバーに「edge://settings/downloads」を入力しEnterキーを押下して表示されるダウンロードの設定項目「ダウンロード時の動作を毎回確認する」が既定値の「オフ」になっていることを前提として自動操作しますので、設定を「オン」にしている場合は「オフ」に設定してください。 まず、電卓を自動操作するスクリプト（141行目から最後の行まで）を削除します。 次に、下記のスクリプトをコピーします。 ################################################################################ # Microsoft Edgeを自動操作する ################################################################################ # 検索する値を設定する $searchWords = @( 'フェンダー' 'ギブソン' 'ポール・リード・スミス' ) # ページ読み込み完了待ち秒数を設定する $pageLoadWaitSeconds = 3 # Microsoft Edgeを開始する Start-Process msedge -Wait # Microsoft Bingのトップページを開く SendKeys -PropertyType "AutomationIdProperty" -Idendifier "view_1020" -Keys "https://www.bing.com/{ENTER}" Start-Sleep -Seconds $pageLoadWaitSeconds # 「$searchWords」に記載されている値を検索してWebキャプチャを保存する $index = 0 foreach ($word in $searchWords) { # 2回目以降の検索時は検索ボックスの内容をクリアする if ($index -gt 0) { ClickElement -PropertyType "AutomationIdProperty" -Identifier "sb_form_q" ClickElement -PropertyType "AutomationIdProperty" -Identifier "sw_clx" Start-Sleep -Seconds 1 } # 検索ボックスに値を入力して検索する SendKeys -PropertyType "AutomationIdProperty" -Identifier "sb_form_q" -Keys "${word}{ENTER}" Start-Sleep -Seconds $pageLoadWaitSeconds # 1回目の検索時は画像リンクをクリックする if ($index -eq 0) { ClickElement -PropertyType "NameProperty" -Identifier "さらに表示" ClickElement -PropertyType "NameProperty" -Identifier "画像" Start-Sleep -Seconds $pageLoadWaitSeconds } # Webキャプチャを保存する SaveWebCaptureByMicrosoftEdge $index += 1 } # エクスプローラーでダウンロードフォルダーを開く explorer.exe $env:USERPROFILE\Downloads スクリプトウィンドウの「141行目」に貼り付けます。 なお、 145 # 検索する値を設定する 146 $searchWords = @( 147 'フェンダー' 148 'ギブソン' 149 'ポール・リード・スミス' 150 ) の「フェンダー」とかの文字列は、とりあえず適当に書いただけですので、他の文字列に編集してもよいです。 では、ツールバーの緑色の「 ︎」（スクリプトを実行）ボタンを選択して、スクリプトを実行しましょう。 Microsoft Edgeが起動してBingのトップページを開いたあとに、検索とWebキャプチャを保存する操作が繰り返しおこなわれ、最後にダウンロードフォルダーが開きます。 ※ うまく動かない時は、ツールバーの赤色の「■」（操作の停止）ボタンを選択してスクリプトを停止してください。 PowerShellの実行ポリシー 「 UIを自動操作するための土台となるスクリプトコピペする 」で、 ひとまずファイルに保存したくなるかもしれませんが、ここでは保存しないでください。 ファイルに保存すると、PowerShellの実行ポリシーの設定によってはスクリプトが実行できなくなるためです。 PowerShellの実行ポリシーについてはあとで説明します。 と書きましたが、ここでファイル保存した状態でスクリプトを実行してみましょう。 「Windows PowerShell ISE」ウィンドウのツールバーのフロッピーディスクアイコンのボタン（スクリプトを保存します）を選択します。（またはメニューバーから [ファイル] > [名前を付けて保存] を選択します。） 「名前を付けて保存」ダイアログが表示されたら、任意の場所・ファイル名で保存します。 では、ツールバーの緑色の「 ︎」（スクリプトを実行）ボタンを選択して、スクリプトを実行しましょう。 お使いの環境によりますが、PowerShellの実行ポリシーが「スクリプトの実行が許可されていない」ポリシーに設定されている場合は、悪意のあるスクリプトの実行を防止するための安全機能が働き「セキュリティ エラー」が発生して、スクリプトの実行が中断されます。 そこで今回は「今現在使用しているWindows PowerShell ISEのみスクリプトの実行を許可」してみます。 まず、コンソールウィンドウに下記を入力して実行します。 Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process すると、異様に横長なダイアログが表示されるので [すべて続行] を選択します。 これでファイル保存したスクリプトが実行できるようになりましたので、試しにもう一度ツールバーの緑色の「 ︎」（スクリプトを実行）ボタンを選択して、スクリプトを実行してみましょう。 今度は「セキュリティ エラー」が発生せずにスクリプトが実行されます。 今回は「今現在使用しているWindows PowerShell ISEのみスクリプトの実行を許可」しましたが、他に「現在のユーザーにスクリプトの実行を許可（-Scope CurrentUser）」したりすることができます。 もっと詳しく知りたい方は「 about_Execution_Policies 」をご参照ください。 さいごに 今回は自動化ツールをインストールしないで、Windowsに標準搭載されている「UI オートメーション」機能を使ってアプリを自動操作する方法を紹介しました。 ブラウザの自動操作は「 Microsoft Edgeを自動操作するスクリプトをコピペして実行する 」で書いたように各種自動化ツールを使う方が多いかもしれませんが、簡単な内容であれば今回体験したように、自動化ツールをインストールしなくても自動操作することができます。 これを機に、自動化に取り組んでみてはいかがでしょうか。 また「自動化ツールをインストールすることができない環境で自動化したい」という状況の時にも対応することができるようになりますので、頭の片隅に残しておいていただけると、いつか役に立つ時がくるかもしれません。 それではまた機会があれば。 The post UIオートメーション〜コピペで体験Windowsアプリの自動操作 first appeared on Sqripts .

はじめに みなさんは、「ブロックチェーン」という言葉を聞いたことがあるでしょうか？ ブロックチェーンとは、ビットコインやイーサリアムなどの「暗号資産」と呼ばれるデジタルな通貨や資産を実現するために使われている技術です。 暗号資産は、銀行の預金や企業発行の電子マネーなどとは異なり、暗号技術を用いて誰でも自由に通貨を発行できる点に特徴があります。暗号資産技術により、2023年4月現在までに、少なくとも9000種類（※1）を超える暗号資産が発行され、暗号資産取引所などで取引が行われています。 ブロックチェーンの技術的な特徴として、暗号資産などの取引データがすべて公開され、誰でもデータを閲覧したり、取引が正当なものかを検証したりできる点があります。例えば、2009年から稼働しているビットコインのブロックチェーンでは、稼働当時から現在までの「どのアカウントがどれくらいのビットコイン残高を持っているか」「過去どんな取引をしたか」といった情報を誰でも自由に閲覧できます（図1）。 図1. Blockchain.com で閲覧できるビットコインの取引データ例 こうしたブロックチェーン上のデータは【オンチェーンデータ】とも呼ばれ、パブリックなビッグデータとしての活用が検討されています。 ブロックチェーンの応用例は、暗号資産のような通貨や資産の送付や売買だけでなく、土地や建物などの物理的な資産と紐づく【デジタル資産】や、それらを対象とした【金融商品】、データの永続性を利用した【証明書サービス】、ゲーム内アイテムやコインを現実の資産として扱える【ブロックチェーンゲーム】など、さまざな分野やアプリケーションに広がりを見せています。 それとともに、オンチェーンデータとして利用できる情報源や活用の幅も広がってきています。 本連載では、ブロックチェーンの基本的な仕組みを解説しながら、オンチェーンデータを分析するための基本的な手法について、全8回で紹介します。 分析のためのツールとして、データべースやビッグデータのデータ処理のために広く使われている【SQL】と呼ばれるクエリ言語を利用します。これまでSQLを使ったことがない人も対象にして、初歩的な構文から実践的なテクニックまでを幅広く紹介していく予定です。 ブロックチェーンのオンチェーンデータ分析に興味がある人はもちろん、これからブロックチェーンを学びたい人や、SQLのスキルを身につけたい人にとっても役立つ情報を発信していきますので、ぜひご活用いただければ幸いです。 ※1 CoinMarketCap ブロックチェーンとは 本連載の第1回目では、ブロックチェーンの歴史について概観し、代表的なブロックチェーンの違いや関係性について紹介します。 ビットコインの誕生 2008年11月、サトシ・ナカモトを名乗る人物がビットコインと呼ばれる新しい電子通貨に関する論文を発表しました。翌2009年1月にはビットコインのソフトウェアが公開され、運用が開始されます。このビットコインを実現するために発明された中核技術が、のちにブロックチェーンと呼ばれています。 このとき投稿された論文（図2）は、PDFで9ページ程度の短い文章であり、現在 bitcoin.org にて各言語に翻訳されて公開されているため、興味のある方はぜひ読んでみてください。 図2. Bitcoin: A Peer-to-Peer Electronic Cash System ビットコインの技術的な解説は本連載の第2回目以降の記事に譲るとして、今回はその社会的受容の歴史について紹介します。 ビットコイン受容の歴史 ビットコインの論文は、サトシ・ナカモトによって暗号理論に関するメーリングリスト（※2）に投稿されましたが、メーリングリストのメンバーからは懐疑的な反応が寄せられました。ビットコインのアイデアは、単に数学的なアプローチで証明できるものではなく、「ビットコインの運用に関わる実際のユーザーたちがどのように行動するか」といった経済学的な側面や、「世界規模の自律的分散システムが正常に動作し続けられるか」といったコンピュータサイエンス的な側面が複雑に絡み合っており、想像だけで理解することが難しいものだったためです。 そこで、サトシ・ナカモトは、実際に動作するシステムのコードを作成し、アイデアに賛同してくれたメンバー間でそのシステムを動かしてみることにしました。いくつかのバグ修正のあと、そのシステムは動作を開始し、約10分に1回のペースで、新しいビットコインが「採掘」され、メンバーの間で送金しあえる新しい電子通貨が誕生しました。 当初、この新しい電子通貨には全く価値が付いていない単なる電子データでした。そこで、ビットコインのアイデアに賛同する人たちは、ビットコインを通貨として流通させるため、ビットコインを現実のお金で取引できるサービス（※3）を公開しました。新しいビットコインを採掘するためには、ある程度の計算パワーが必要だったため、その計算にかかる電気代をベースとして、1ドルあたり1,000 BTC前後で取引が開始されはじめました。 ビットコインと現実の通貨が交換できるようになると、次第にそのユースケースが登場していきます。特に世間から注目を浴びた例として、2010年11月に起きたWikiLeaksスキャンダルや、2011年頃のシルクロードという取引サイトへの糾弾が挙げられます。 WikiLeaksによってアメリカの外交機密文書が公開された事件が発生した際、WikiLeaksに対する制裁として、PayPalを用いたWikiLeaksに対する送金が停止されたり、WikiLeaks創設者の銀行口座が凍結されたりといったことが行われました。WikiLeaksの是非は別として、特定の民間企業によって資産の移動を凍結されてしまう事態に対して反発が起こり、一方でビットコインを用いたWikiLeaksへの募金は止められなかったため、「送金の自由を誰にも止めることができない」というビットコインの性質に注目が集まりました（※4）。 また、シルクロードというサイトでは、匿名で送金が可能なビットコインを用いて違法な薬物が取引されていたり、マネーロンダリングに悪用されていたりする実態が糾弾されましたが、それらのニュースを通じてビットコインへの関心も高まり、2011年には1 BTCが30ドル以上で取引されるなど、最初のビットコインバブルを迎えました。 ※2: Satoshi’s posts to Cryptography mailing list ※3: New Liberty Standard ※4: Could the Wikileaks Scandal Lead to New Virtual Currency? ※5: Schumer Pushes to Shut Down Online Drug Marketplace アルトコインの誕生 ビットコインへの関心の高まりとともに、ビットコインの仕組みを流用した新たな暗号資産も登場し始めます。ビットコインの採掘や送金は、約10分に1回行われるブロック生成ごとにおこなわれますが、この間隔を短くして高速にトランザクションを実行できるようにした「ライトコイン」（※6）や、ビットコインにDNSの機能を付加した「ネームコイン」（※7）など、さまざな改良や改変をおこなったコインが発行されました。これらを総称して、「アルトコイン」と呼ばれます。 初期のアルトコインは、ビットコインのプログラムをフォーク（コピー）してきて、必要な改変をおこなったあと、賛同者たちでその改変プログラムを実行する形で発行されました。しかしこのやり方は、新しいコインの発行や維持する賛同者たちを多く集める必要があり、ハードルの高いものでした。 そこで、新たにプログラムをフォークして動かすことなく、より簡単に独自のコインを発行できるプラットフォームとして、Mastercoin(Omni)（※8）やCounterparty（※9）なども登場しはじめました。 ※6: Litecoin ※7: Namecoin ※8: Omni Layer ※9: Counterparty イーサリアムの誕生 ビットコインに続いてさまざまなアルトコインが登場する中で、大きな転換点となったのが、2015年のイーサリアム（※10）の登場です。 ビットコインをベースとした派生コインの多くは、あらかじめ決められた送金処理などを実行することはできますが、その表現力は限定的でした。そこでイーサリアムは、ビットコインが発明したブロックチェーンという仕組みを拡張し、ブロックチェーンの上で汎用的なプログラムを実行するためのプラットフォームの実現を目指しました。 イーサリアムを用いることで、ユーザーはわずか数十行のプログラムを記述してデプロイするだけで、独自の暗号資産をブロックチェーン上で実現することができるようになりました。 このように、新たな暗号資産を発行するハードルが劇的に下がる一方で、成功した暗号資産は初期の値段から数百倍～数万倍の価値に跳ね上がることも珍しくなく、一つのプロジェクトで数億円～数百億円の資金調達が実現されるなど、多くの投資資金が暗号資産に流入していきました。 ※10: Ethereum DApps, NFT, DeFiの誕生 イーサリアムを用いると、独自の暗号資産の発行だけでなく、汎用的なプログラムそのものをブロックチェーン上で動かすこともできるようになりました。 例えば、ある既存の暗号資産と、自身で発行した独自の暗号資産を交換するために、どこかの取引所サービスでその暗号資産を取り扱ってもらう必要はなく、イーサリアム上のプログラムで自動的に暗号資産同士の交換をおこなうことができます。そのような、ブロックチェーン上の取引所をDecentralized Exchange（DEX）と呼びます。 また、暗号資産を用いたギャンブルのようなサービスをブロックチェーン上で動かすこともできますし、より複雑なゲームロジックを実装することも可能です。 イーサリアム上のプログラムはスマートコントラクトと呼ばれ、スマートコントラクトを用いたアプリケーションはDecentralized Apps（DApps）とも呼ばれます。 イーサリアム上でさまざまなスマートコントラクトが開発されるようになると、類似の用途のコントラクトは共通規格化して統一的に扱いたくなります。そのような統一規格として、Fungible Token（FT）と呼ばれるトークン規格であるERC20や、Non-Fungible Token（NFT）と呼ばれるトークン規格であるERC721などが策定され、次第にイーサリアム上でDAppsを開発するエコシステムが整っていきました。 さまざまなDAppsの中で、特に影響の大きかったサービスの類型として、Decentralized Finance（DeFi）サービスが挙げられます。DeFiとは、大まかには暗号資産を対象とした金融商品を実装したり取引したりできるDAppsサービスの総称です。DeFiの登場により、将来価格が上がりそうな暗号資産に投資をするだけでなく、保有している暗号資産を誰かに貸し出して金利を得たり、複数の暗号資産のデリバティブ取引を組み合わせてリスクヘッジをしたりといった資産運用を、銀行や証券取引所を介することなくブロックチェーン上で行うことができるようになりました。 DeFiを用いた暗号資産の運用は、年利10%から数百%を上回ることもあり、より多くの投資資金を集めるきっかけとなりました。 ポスト・イーサリアム争い～現在 ビットコインやイーサリアムの歴史は、これまで説明したような成功や進歩の歴史だけでなく、違法取引やマネーロンダリング、消費者被害、環境への悪影響など、さまざまな負の側面も持っています。 短い紙面ですべての課題を解説することはできませんが、ここではイーサリアムの技術的課題と解決へのアプローチの潮流について簡単に紹介します。 さまざまなDAppsサービスがイーサリアム上で開発・運用されるとともに、ブロックチェーンのスケーラビリティ問題が深刻化していきました。 スケーラビリティとは、システムが処理すべきタスクの増大に対して対処可能な特性のことです。一般的な分散システムでは、システムを構成するノードを追加していくことで、タスクを分散処理してシステム全体の処理能力が向上できるようなアプローチを取ります。 しかし、古典的なブロックチェーンのアーキテクチャでは、いくらシステムを構成するノードを追加しても、システム全体として処理できるタスク量は増加しません。初期のイーサリアムの仕組みでは、秒間10-20トランザクションを処理することが限界でした。VISAクレジットカードのネットワークが秒間24,000トランザクションを処理可能（※11）であることと比較すると、イーサリアムのパフォーマンスは世界規模のトランザクションを処理する性能を満たせていません。 このスケーラビリティ問題は、2023年現在でも解決できていない課題の一つですが、大きく分けて２つの潮流があります。 一つは、スケーラビリティを兼ね備えた新しいブロックチェーンプラットフォームサービスを開発し、イーサリアムを超えていこうとする潮流です。代表的なプロジェクトとして、Solana（※12）やPolkadot（※13）などが挙げられます。イーサリアムの直面した課題をゼロベースで解決していこうとする場合が多く、必ずしもイーサリアムと互換性を保っているわけではありません。 もう一つは、既存のイーサリアムをLayer-1として、その下位に位置するLayer-2チェーンを接続し、イーサリアム自体にスケーラビリティ特性を付加しようとする潮流です。代表的なプロジェクトとして、Arbitrum（※14）やOptimism（※15）、zkSync（※16）などが挙げられます。 これらの技術はまだまだ発展途上であり、暗号資産の時価総額から考えても、ビットコイン、イーサリアムに続く第3のブロックチェーンサービスは流動的です。 本連載の中では、数あるブロックチェーンサービスの中でもある程度の地位を固めたと考えられるビットコインとイーサリアムについて、それぞれのオンチェーンデータを深掘りしていく予定です。 ※11: Visa ※12: Solana ※13 Polkadot ※14: Arbitrum ※15: Optimism ※16: zkSync オンチェーンデータ分析のすすめ 最後に、データ分析のスキルを学ぶ上で、オンチェーンデータが題材として適していると筆者が考えているメリットをまとめます。 まず、データ分析するために使えるリアルなデータが、誰でもアクセスできる状態で豊富に蓄積されている点がメリットとして挙げられます。 多くのサービスで蓄積されているデータの権利は、そのサービスを運用している企業や団体に帰属しており、一部の例外を除いて自由に閲覧したり活用したりできる状態にはありません。そうしたサービスのダミーデータを生成して練習することもできますが、人為的に生成されたデータと、実サービスで多くの人々によって蓄積されたデータとでは、得られる情報量に大きな違いがあります。 また、オンチェーン分析のためのツール群が充実している点も、初学者にとっては大きなメリットとなります。 例えば、Google BigQueryでは、ビットコインやイーサリアムなどの主要なブロックチェーンのトランザクションデータが、パブリックデータセットとして簡単にアクセス可能な状態で提供されています（※17）。ブロックチェーンデータ分析のための専門ツールを提供しているDune Analytics（※18）では、イーサリアムのトランザクションデータに対してSQLを用いて集計したり、ダッシュボードとして可視化したりする機能を無料で提供しています。 これらのサービスを用いることで、環境構築やデータの準備にほとんど時間をかけることなく、低コストでデータ分析の演習を始めることができます。 さらに、ブロックチェーンを用いたサービスを提供している企業や団体の多くは、こうしたオンチェーン分析に対する需要も高く、学習からコミュニティへの貢献までの距離感が非常に近いこともメリットとして挙げられます。 一般的な業界では、SQLを数週間から数ヶ月程度学んだ人が、いきなり実践的な成果を出せるケースは多くないでしょう。一方、ブロックチェーン界隈の現状では、プロジェクトの数に対してオンチェーン分析を行えるスキルを持った人材が圧倒的に不足しているため、初学者であっても実践的な成果を出すチャンスが多くあります。 ブロックチェーンサービスのエコシステムでは、オンチェーン分析の成果に対してグラントのような報酬を設定しているプロダクトも多く存在しているため、そういったグラントの獲得を目標に設定して学習するというのも、モチベーションを維持するために有効な手段です。 今回の記事でオンチェーン分析に興味を持っていただいた方は、ぜひ第2回～8回の記事も参考にしていただき、ブロックチェーンに対する理解やSQLのスキルを磨いていただければ幸いです。 ※17: Google Cloud Datasets ※18: Dune Analytics The post 【第1回】ブロックチェーンとは first appeared on Sqripts .

みなさん、こんにちは！　QA事業本部のゆーすけです。 JSTQB CBT試験みなさん受けてますかっ！？（前回と同じ入り方） ついに、テストアナリストのCBT開始の連絡もありましたね、しかもテストアナリストはPBTやテストマネージャーCBTとは異なり、「3年間の業務経験」という条件がなくなっていますので、より現場に近い資格になったんじゃないかな、と思います。 また、年内には ・アジャイルテスト担当者 ・自動車ソフトウェアテストテスト担当者 ・テスト自動化エンジニア も開始予定とのことなので、自分もそろそろアジャイルテストと自動化エンジニアの勉強を再開しようかと思っているところです！（自動車はPBTで取得済み） ということで、JSTQBの学習のススメ連載の6回目となります！ ▼1～4回のおさらいです！ 1回目 JSTQBってなんだろう？→Foundation Levelから始めよう 2回目 Foundation Levelの構成ってどうなっているんだろう？ 3回目 テスト基礎について 4回目 テストのライフサイクルについて 5回目 静的テスト 　 JSTQB Foundation Levelの構成は以下のようになっていて、6回目の今回はみんな大好きテスト技法について触れていきたいと思います。 １：テストの基礎 ２：ソフトウェア開発ライフサイクル全体を通してのテスト ３：静的テスト　 ４：テスト技法　　　←今回はココ ５：テストマネジメント ６：テスト支援ツール テスト技法って？ テストを効率的かつ効果的に進めるための考え方、アプローチ方法ととらえると分かりやすいかもしれません。シラバスにも記載されていますが、テス技法ありきでテストを考えるのではなく様々な要因のもと正しくテスト技法の取捨選択、適用範囲を決めていることが大事になります。 プロダクトの性質上、適用できない/適用しても効果的ではない、というテスト技法もあるので、技法の特性特色はここで適切に把握するようにしていきましょう。 FLシラバスでは、動的テストの「ブラックボックス」「ホワイトボックス」「経験ベース」の3つに分類しています。以前の記事にも使ったテスト図に付け加えると以下のようなかたちになります。 ブラックボックスのテスト技法 上の図とは順番が異なりますが、シラバス記載の順序通りにブラックボックステストの技法から簡単に触れていきましょう。 同値分割 同値はデータの処理からグループ分け（同値クラス化）をする考え方です。 例えば、数字入力のフォームにて、 ・0～50 ・51～100 ・101～ の入力結果において異なる処理が行われる場合、上記の3つカテゴリが有効同値クラスとなります。 テストを行う際は、同値内の中央値を使用くするのが一般的と言われています。 境界値分析 境界値分析はIPAなどでは限界値分析とも呼ばれます。 コーディングにおいて、”＞”（大なり）、”＜”（小なり）と、“≧”（大なりイコール）、”≦”（小なりイコール）を取り間違える、というのはありそうでなさそうだけど、実際はありえる分かりやすいコーディングミスの一つです。想像することのできるコーディングミスで、最も単純でその割に影響度が果てしなく大きいので、出来れば重要な数値周りは境界値の観点でテストを行い、「問題ない」というお墨付きをもらっておきたいところですよね。 ※設計書上で数字の分岐定義、統一がされていない、「以上以下」と「より未満」が入り混じるようなものは要注意です。 先ほどの同値分割と同じ数字でいうと、 ・0～50 ・51～100 ・101～ 0、50、51、100、101が境界値分析として取り扱うべきテスト対象となります。 ※境界値として2値をとる、という方針になった場合。3値の場合は0、49、50、51、99、100、101が対象となります。 同値と境界値の関係を簡単な図にすると以下のようになります。 デシジョンテーブル 決定表とも呼ばれるテスト手法で、デシジョンテーブルのことを取り上げた記事もあります。 いまさらデシジョンテーブルというものを考えてみた | Sqripts 上の記事にも記載していますが、テストケースを省略できるパターン、省略できないパターン、デシジョンテーブルではなく原因結果グラフが適切な場合などいろいろ考えられますが、Foundation Levelではまずは簡単なテスト条件からテーブルを作成できれば問題ないと思います。 デシジョンテーブル記事の再掲となりますが、 　想定： 　　映画館のチケット割引サービス 　 　仕様： 　　通常金額1900円 　 　割引システム： 　　ファーストデイ：毎月1日はだれでも1200円 　　レディースデイ：毎週水曜日は女性なら1200円 という条件があった場合、以下のようなテーブルが作られます。 条件からデシジョンテーブルを作ってみる、という内容はJSTQB ALテストアナリストや、IVEC（IT検証技術者認定試験）でも頻出しているので、自分で条件を考えて実際に数回テーブルを作ってみる、というのがいいと思います。 状態遷移テスト これまた別ブログ記事参照で申し訳ないですが、状態遷移を取り上げた記事がありますので、より深く知りたい方はこちらを参考にしてみるといいかもしれません。 幅広いソフトウェアとテストレベルで適用可能な状態遷移テスト | Sqripts 状態遷移テストは、「状態遷移図」または「状態遷移表」を作って考えます。 それぞれの特色としては、 　状態遷移表：無効値も含めて考えるため、仕様の抜け漏れに気づきやすい 　状態遷移図：フロー図で表すため、遷移が視覚的に分かりやすい ということがあります。 状態遷移テストはJSTQB ALテストアナリストでも引き続き掘り下げられていく手法のため、FLの段階でしっかりと状態遷移図、状態遷移表のどちらも作れるようにしていきましょう。 ※JSTQBテストアナリスト試験では、状態遷移図を作ってNスイッチカバレッジを求めよ、というのが頻出傾向でしたが、最新PBTではなくなった、という嘆きの声もあるようです。 ※嘆きの声が書かれた記事がこちら シラバス改定後初のJSTQB ALTA試験受けてきた #1 | Sqripts ユースケーステスト まずはシラバスから抜粋すると ソフトウェアアイテムとの相互作用の設計方法であり、テストケースは、ユースケースから導出可能である。 ユースケースには、ソフトウェア機能の要件が盛り込まれている。 （省略） 各ユースケースは、1 つのサブジェクトと 1 つ以上のアクターとの相互作用による振る舞いを明確にす る（UML 2.5.1 2017） と記載されています。 つまりユースケースは、ソフトウェア機能要件（要件定義～詳細設計）で定義されたものがテストベースとなります。 ただし、ユースケーステストをISTQB GLOSSARYで調べると ブラックボックステスト技法の一つ。ユースケースの動作を実行するようにテストケースを設計する。 同義語：ユーザシナリオテスト、シナリオテスト と記載されているので、ユースケース図をテストベースとしたテストだけではなく、ユーザーを想定した一連のテストを丸めて呼んでいる、代表的な例としてユースケース図をベースに作成する、とざっくりとした理解でもFLの段階ではいいと思います。 このあたりはSWEBOK-SQuBOKや、ISO/IEC/IEEE 29119など、他の学習を取り入れ、そのうえで自分の中でのユースケース定義、シナリオテスト定義などをしっかりと定め、認識齟齬なくテスト活動を行っていく、ということが重要なところとなります。 ちなみにシラバスにも記載されているユースケースにおける、サブジェクトとアクターはこのように表せます。 なんと次回に続く…… 今回テスト技法を「ブラックボックス」「ホワイトボックス」「経験ベース」の3つを取り上げる予定でしたが、3つ全て取り上げるとかなりのボリュームになりそうなので、今回はブラックボックスだけの内容として、残りの2つは次回にまわしたいと思います。 次回はなるべく早めに掲載できるよう頑張りますので引き続きお付き合いいただけますよう何卒宜しくお願いいたします！！ The post JSTQB学習のススメ #6 〜Foundation〜 first appeared on Sqripts .

はじめまして、AGESTクオリティマネージメント部の坂本です。 今回は弊社が新たに開始するコード解析サービスについてご紹介したいと思います。 QA for Development QA for Developmentとは「開発のための品質保証」を実現するAGESTの新しいソリューションです。「不確実性が高い時代のモノづくり」の品質課題にオールインワンで向き合うため、AGESTは開発×テストの二刀流のノウハウを持った”次世代QAエンジニア”による新しい価値提供を行います。 今回ご紹介するコード解析サービスは、こちらの新ソリューション「QA for Development」のサービスのひとつです。どのようなものか、どのようなメリットがあるのか、また具体的な進め方や成果物についてご紹介します。QA for Developmentについての詳細は下記のページをご覧ください。 QA for Development コード解析サービス サービス概要 コード解析サービスとは、コード品質にお悩みのお客さまのソースコードを様々な観点から解析、品質を計測し、改善点を検出・作成するサービスです。 当サービスにより問題（指摘事項）やコード量の傾向等が可視化され、コードの問題箇所が見えてきます。また、問題箇所への最適な対応もご提案するため、結果として問題が減少し、クリーンなコードになることが期待できます。また継続的なコード品質の維持についても考えますので、一度受けて終わり、ではなく受けたあともコード品質をあげる仕組みができます。 ( ※1 ) コード品質とは 一言にコード品質といっても様々な観点が存在します。 たとえば下記の観点があります。 1.保守性 コードのメンテナンスのしやすさを表します。 　a.可読性 　変数やメソッド、クラス等への適切な命名、シンプルなロジックを作成する等で向上します。 　b.テスト容易性 　クラス、メソッドへの適切な責務の割り当てをする等で向上します。 　c.変更しやすさ 　定数を利用する、コードを重複させない、グローバル変数を使わない等で向上します。 2.再利用性 コード（モジュール、クラス）の再利用のしやすさを表します。適切な責務の割り当て、モジュール分割によって向上します。適当にクラスやメソッドを作成しているといらない機能が入っていたり、変に特化している部分があったりして再利用できないことがよくあります。 3.効率性 CPU利用やメモリ消費の多寡を表します。無駄なファイル入出力、メモリ確保をなくしたり、DBであればインデックスが効くようにクエリを発行する等で向上します。多くの場合プログラム実行速度に直結します。 4.移植性 プログラムを異なる環境に移植した際に動作させる容易さを表します。CPUやOS、ミドルウェア等に依存したコード（改行コードのべた書き、特定のDBにしか存在しない命令等）を減らすことで向上します。 5.信頼性 エラーへの強さを表します。具体的には例外的な入力があってもデータが壊れない、エラーが発生した場合フェイルセーフな動作をする等があります。例外的な場面に備えた処理を実装することで向上します。このようにコード品質には様々な面があり、プロジェクトによって注力するべきところも変わってきます。 低品質コードのリスク 前項で記載したなかでプロジェクトに必要な観点を満たしている割合が低いものを品質の低いコードということができます。それではそもそもコードの品質が低いと、誰がどう困るのでしょうか。 例えば下図のような、作業への影響、その結果として起こりうるリスクがあげられます。 テスタビリティの低下 テストがしにくくなることで、コードカバレッジやテストケースの漏れが発生し、欠陥検出率が低下します。その結果、市場不具合が発生し、顧客に損害が発生する、自社の信頼を失う等の影響が発生します。またプロジェクトもテストがスムーズに実施できないことで進捗遅れが発生します。 メンテナンス性の低下 メンテナンスがしにくくなることで、不具合修正の難易度が上がり、デグレードの発生確率が上がります。また機能追加・変更をする際にも影響範囲の広さや再利用性の低さからコストが増えます。 移植性の低下 移植性が低下すると異なる環境でソフトウェアを利用したいとなった際、修正が必要な箇所が増え、コストが増大します。 可読性の低下 可読性が低下するとコード解析の難易度が上がります。結果として不具合修正や改修時のコストが増えます。また意図を理解できずにロジックを修正した結果、欠陥を埋め込んでしまうリスクもあります。 対策 低品質コードは様々な工程で問題を引き起こします。そのため低品質コードを生み出さないことが大切です。対策も様々ですがたとえば下記のようなものが考えられます。 コードレビューを実施する 有識者によるコードレビューを行うことで、問題のあるコードを検知し、修正することが可能です。ただしすべてを見るにはコストが高く、プロジェクトの状況によっては難しいことも多々あります。またレビューアのスキルに依存するため、効果はその時々で大きく変わってきます。 静的コード解析を実施する Linterといわれる静的コード解析ツールやSonarQubeを利用した解析を行い、コードの問題箇所をリストアップできます。リストアップされた指摘を精査していき、問題箇所を修正することでコードの品質を向上させることが可能です。ただし環境・言語によっては導入が難しいことがあります。また警告の量が多く、些細な指摘に埋もれてクリティカルなものに気づかないことも起きえます。 コードメトリクスを計測する コードメトリクスを計測し、その結果をもとにレビューを実施したり、クオリティゲートを設定したりすることで、効率よくコード品質の低下を防ぐことができます。メトリクスにはステップ数、循環的複雑度（Cyclomatic Complexity）、継承の深さ、クラス結合度等、様々なものが存在します。プロジェクトの特性や言語によって利用するものを選定します。 静的コード解析とは 静的コード解析 (せいてきコードかいせき、static code analysis) または静的プログラム解析 (static program analysis)とは、コンピュータのソフトウェアの解析手法の一種であり、実行ファイルを実行することなく解析を行うこと。   静的コード解析 – Wikipedia コーディング規約違反やリソースの解放忘れ、到達不能コード等数多くの問題を指摘してくれるものです。CIに組み込んで違反コードをマージさせないような仕組みにすることもあります。 コードメトリクスとは コード メトリックスとは、開発者が開発中のコードをより理解できるようにする、ソフトウェアの一連の基準です。   コード メトリックを計算する – Visual Studio (Windows) | Microsoft Learn LOC(コード行数)、循環的複雑度(Cyclomatic Complexity)、CKメトリクス(オブジェクト指向言語用のメトリクス群)等、数多くのメトリクスが存在します。 コード上の複雑な箇所を見つけたり、多くの箇所から利用されているものを見つけたりするようなことが可能です。 コード解析サービスを利用するメリット 低品質コードの対策としては前項であげたものがありますが、それまでやっていなかった場合は実際にやるとなるとどうすればいいのかわからず、とりあえずやってみたけど特に得るものもなく徒労に終わるといったこともあります。 そういった場合にはノウハウを持った専門家に依頼することが有効です。 弊社のコード解析サービスはまさにこの対策を提供するものです。 サービスを利用するメリットとしては下記があげられます。 専門家がコード解析、それを受けた改善点のご提案するため、効果をあげやすい 外部の目が入ることで、新しい観点のレビューが実施される 自社で実施した場合にかかる工数が大幅に削減される 静的解析の結果は些細なものがフィルタリングされるため、重要なものにのみ集中できる メトリクスの閾値に適切なものが設定できる プロジェクトにマッチしたCI/CDへの導入方法がわかる(※1) 一度サービスを受けた後は実施した作業・メトリクス計測・閾値設定を継続、改良するだけでコード品質維持が可能になる。他のプロジェクトにも適用しやすくなる。 特に下記のようなことにお悩みのお客さまにおすすめです。 上流工程で品質を担保していきたい 静的コード解析を導入したいが方針が決まらない、導入したが成果が見えない コードメトリクスによるクオリティゲートを設定したいが何をどんな基準で設定すればいいかわからない 不具合が大量に発生してしまっていて手を打つ必要がある 今後もコード品質を向上させていきたい 下図は改善後イメージです。 コード解析サービスの進め方 それでは実際にコード解析サービスがどのように進められていくのかご紹介します。 おおまかなフローとしては下図のようになります。 1.事前準備 まずは対象プロジェクトの状況、課題のヒアリング、目標ヒアリング・設定をします。その後プロジェクト環境に適用可能な商用ソフトウェア、OSS等の調査、インストールを実施していきます。実はここが一番大変だったりします。OSSも玉石混交で、思うように動作しないものも多くあり、利用するソフトの調査に時間と手間がかかります。またお客さまのビルド環境が特殊だったりすると急激に適用できる商用ソフトウェア、OSSが減り、どうしようもないときはOSSをカスタマイズしたりちょっとした補助ツールを作成したりといったこともあります。 2.ソースコードの受領 git等のリポジトリからcloneしたり、プロジェクトフォルダをコピーいただいたり、基本的にはビルド可能なプロジェクトの全ソースをご連携いただきます。解析の中にはビルドしないと解析できないものも存在するためです。 ここでまずはビルド、テストが通るかの確認をします。 3.各解析の実施 下記を実施します。 　a.コードリーディング 　メトリクス計測の結果や、ヒアリング結果から要注意の箇所を確認していきます。コーディングルールがどうなっているか、重複コードがないか、バッドプラクティスのコードがないか等を確認します。 　b.静的コード解析 　SonarQubeやlinter等を利用し静的コード解析を実施します。独自環境であればそれに組み入れられるよう手順を構築します。 　c.メトリクス計測 　各言語ごとに利用可能なOSSや弊社ツールを利用し、必要なメトリクスを計測します。こちらも環境にあわせて手順を構築します。 4.解析結果の分析 解析結果を分析し、重要な指摘をリストアップ、整理していきます。指摘の傾向からどのようなところに注意が必要かを判断します。メトリクス計測した結果からはコードの状態をレポートします。複雑度等が事前に設定した閾値を超えている場合は何が問題なのかを分析します。また各メトリクスから不具合の発生しやすい要注意スポットを割り出します。ここもナレッジがないと難しいポイントとなります。 5.改善点、対応案の作成 指摘や具体的なコードの問題、メトリクスから改善点、対応案を作成し、レポートします。いま存在する問題点の解消と今後コード品質を維持するための施策を含めてご提案します。 6.CI/CDへの導入提案・支援( ※1 ) CIにツールを導入する必要があると考えられる場合にはそこへの導入提案・支援を実施します。継続的にコード品質を上げていく仕組みづくりを考えます。 レポート例 プロジェクトごとに内容は変わりますが、一例として下図のようなレポートを出します。 対象プロジェクトに合わせて設定したメトリクスと閾値にしたがって閾値を超えている箇所を可視化 プロジェクトのコード品質を可視化、またコード内の具体的な問題箇所についても整理し、改善案作成 まとめ 低品質コードは様々なリスクを発生させます。もしリスクが顕在化した際のダメージは甚大になりうるものです。それを避けるためには低品質コードを生み出さないことが重要です。コードレビューや静的コード解析、メトリクス計測等を実施し、コード品質を向上させていきましょう。上流工程の品質向上は後工程のコスト削減や市場不具合の減少につながっていきます。 もしコード品質が低く困っているがノウハウがなくどうすればよいかわからないというようなことがありましたら、ぜひ弊社へご相談ください。エキスパートがお客さまに最適な改善案をご提案します。 ※1 既存のCI/CDへの組み込み対応のみとなります。新規のCI/CD構築支援につきましては別途サービス開始予定となっております。 参考： コード解析 – 株式会社AGEST（アジェスト） The post コード解析サービスのご紹介 first appeared on Sqripts .

こんにちは、AGESTでエンジニアをしているやまたろうです。 皆さんは、FigmaやAdobeXDといったデザインツールをご存知でしょうか。Webシステム開発に携わっている方であれば、聞いたことがあったり、使っている方が多いと思います。 デザインツールという名前を聞くと「デザイナーのためのツール」という印象を持たれるかもしれません。（私も最初はそう思っていました）しかし、実際にエンジニアとしてデザインツールを使って得られたものは想像以上に大きかったので紹介させていただきます。 本記事は、筆者がメインで利用しているFigmaをベースにお話しします。 超高速なプロトタイピング 私はフロントエンド領域を得意とするエンジニアで、2日もあればTwitterのクローンアプリを作れる程度には自信があります。なので、実務でプロトタイプを作成する際はFirebaseやSPAフレームワークを駆使していました。また、デザインツールを活用したプロトタイプは、インタラクションの表現に乏しい「紙芝居」に近いものしか表現できないと思っていたため、実際にアプリケーションの利用イメージを伝えるためには、アプリケーションを開発してしまうことが確実であると考えていました。しかし、それは大きな誤りでした。 以下は、この記事のために作成したサンプルのログインページのイメージです。非常にシンプルな画面ですが、プログラム開発の場合、画面を作る時間に加えて、開発環境の構築やユーザーに触れてもらうためのホスティングなどの設定を行う必要があるため、短く見積もっても30分はかかります。しかし、Figmaを使用する場合は、それらの工程は必要ないため、5分もあれば作成することができます。 また、Figmaのコンポーネント機能を使用することで、状態や振る舞いを持ったUIパーツを定義することができます。そのため、懸念していた紙芝居のような印象を与えることはありません。むしろ、「もうアプリケーションを開発したの？」と勘違いされることのほうが多いです。 よくあるトグルスイッチ プログラムを書かずにコンテキストメニューを表示まで再現可能 その他、豊富なプラグインや無料で公開されているUI Kitを利用することで更に効率よくプロトタイプ/デザインを作成することができます。こちらはオススメが数多く存在するので実際に見たり触ったりして頂くのがよいと思います。 Figma Community 円滑なコミュニケーションの実現 今まではプロトタイプ修正後、デプロイしてからチャットやメールで変更した旨を共有していたのですが、Figmaであればリアルタイムでデザインやプロトタイプが変更されるのでコミュニケーションコストが大きく削減されました。 また、Figmaのコメント機能で修正すべき箇所に直接フィードバックが貰えるので、メンバー間で認識の齟齬が減ったように思います。 UIに直接フィードバックを受けることができるので、どこかを伝える必要がない ドキュメント作成の選択肢が増える 設計資料の中で言葉だけでは伝わりにくい箇所に図面を活用するのですが、Figmaで作成することが増えています。 以下は、Mermaidで作成した構成図を具体的にイメージを持ってもらうために簡略化やアイコンを追加してFigmaで作り直した例です。 Mermaidで作成したエンジニア向け資料 Biz向けFigma製の資料 一般的に、PowerPointを使って図面を作られている方が多いと思いますが、見た目に特化したツールではありませんし、Illustratorは学習コストや料金面で手が出しにくいため、私はFigmaやAdobeXDなどのツールを活用することをおすすめします。 見た目や資料の品質は別のスキルが必要になりますが、自由にデザイン・レイアウトを作れるのはデザインツールならではの長所だと思います。 さいごに 元々はデザイナーさんとのコミュニケーションのために触り始めたFigmaですが、使えば使うほどこのツールの汎用性の高さと洗練された機能に驚かされます。特に資料を作るのが苦手なエンジニアの方であれば十分な恩恵を得られると思うので、利用していない方は是非試してみてください！ それでは、よいFigmaライフを The post エンジニアでも使える！デザインツールFigmaがもたらす効果とは？ first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第1回目のテーマは、「アジャイル開発の過去、現在、未来を知ろう！」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 アジャイルの現在位置 アジャイル開発の現在・過去・未来～今を知り、源流を訪ね、先を見据える～ 上記の図は、平鍋健児さんという方が2010年に発表した『 アジャイル開発の現在・過去・未来～今を知り、源流を訪ね、先を見据える 』から引用した図です。アジャイル開発が生まれるまで、生まれてからの流れがとても良くわかるすばらしい資料なので、読み解いてみましょう。 アジャイル開発は2001年頃に生まれました。ただ、その前から様々な方法論がありました。たとえば、図の左上にある「EVO」、「FDD」、「Crystal」は、アジャイル開発が登場する前に生まれた開発手法です。 その下には「Patterns」や「TPS」が並んでおり、そこから「XP」につながっています。Patternsは、建築家クリストファー・アレグザンダーが考えたパターンランゲージが元になっています。パターン・ランゲージとは、「こういった場合だと、この方法がいい」といったパターンを解説したものです。この考え方をソフトウェア開発に取り入れたのがXP（エクストリーム・プログラミング）です。TPSはトヨタ生産方式（Toyota production system）です。TPSは日本企業であるトヨタが考えた手法で、もともとは自動車の生産に関係する方法論でしたが、XPだけでなくLean（リーン）やScrum（スクラム）など、様々なソフトウェア開発手法にも影響を与えています。 さまざまな流れは、現在主流になっているスクラムなどを巻き込みながら、「アジャイル開発」へとつながっていきます。 アジャイル開発が誕生した後にもさまざまな方法論や手法が登場しています。たとえばリーンスタートアップがきっかけになってリーンUXなど、リーンの考えをベースとした手法がいろいろ出てきました。また、さすがにXPやスクラムといった有名な手法を超えるものは少ないですが、DevOpsのような考え方も今では当たり前になってきています。 さらに、ソフトウェアの開発方法だけでなく、ソフトウェア開発における組織論、大規模開発などにもアジャイル開発の思想は広がっています。 アジャイルマニフェストの誕生 アジャイル開発は2001年に生まれたと書きましたが、その誕生には面白いストーリーがあります。 2001年、アメリカのソルトレイクシティに、開発手法に詳しい17人が集まり議論を行いました。当時は会議室が見つからず、しかたなく空いていたスキーリゾートを予約して集まったそうです。 その議論の結果、「アジャイルソフトウェア開発宣言（通称：アジャイルマニフェスト」が誕生しました。このアジャイルマニフェストの誕生が、アジャイル開発の誕生となっています。アジャイルマニフェストは、以下のような1枚のWebページで公開されています。 アジャイルソフトウェア開発宣言 この時の様子は、アジャイルマニフェストの背景にも描かれています。背景をみると、ホワイトボードのようなものの前に、幾人かの男性が集まって話し合っている姿があります。ひとりはこちらを向いて、ホワイトボードのどこかを指差しているように見えます。おそらく、こちらを向いている人は、書籍『リファクタリング』などで有名なマーティン・ファウラー氏です。それ以外の背を向けているメンバーも、スノーバードに集まった17人の方法論者です。 また、アジャイルマニフェストの下側には、集まった17人の署名があります。名前を見てみると、世界初のWikiを開発したワード・カニンガム氏や、エクストリーム・プログラミングの生みの親であるケント・ベック氏、スクラムの生みの親であるジェフサザーランド氏なども名を連ねています。 様々な言語に翻訳されたアジャイルマニフェスト アジャイルマニフェストは、わずか10行の文章でしかありません。しかし、このわずか10行のテキストが世界中へと広がり、今では一般的に使われる手法へとなりました。その証拠に、アジャイルマニフェストのページを下にスライドさせていくと、他の言語に翻訳されたページへのリンクが並んでいるのがわかります。この記事を書いている時点では、68の言語に翻訳されているようです。 当時のスノーバードの様子。おそらく世界で一番有名なホワイトボードではないでしょうか？ アジャイル開発の10年、20年 毎年アメリカで開催されるアジャイルカンファレンスは、世界最大のアジャイル開発に関するカンファレンスです。 アジャイルマニフェスト誕生10年を祝うイベント。マイクを持っているのは書籍『アジャイルプロジェクトマネジメント』の著者ジム・ハイスミス氏 2011年は、アジャイルマニフェストが誕生して10年たった記念すべき年でした。その誕生を祝して、アジャイルカンファレンスにおいて、特別なイベントが開催されました。 イベントのテーマは「Back to where it all began. Back to the future」です。日本語に訳すと「すべてのはじまりの場所に帰ろう。そして未来へと進もう」という内容で、ケント・ベック氏を除く16人の署名者が集まり、当時を振り返りました。このときのレポートは、 アジャイルマニフェスト署名者たちが再会する「The Big Park Bench」～Agile 2011 Conference に書いたので、当時の熱気を感じたい方はぜひ一読ください。 現在では、アメリカだけでなく、ヨーロッパでも1000人規模のイベントが行われています。もちろん国内でもたくさんのイベントや勉強会、コミュニティが生まれています。日本語に訳された書籍だけでなく、日本語の書籍もたくさん登場しました。アジャイルマニフェストは、現在も広がり続けているのです。 アジャイルマニフェスト20周年となる2021年にも、誕生を祝うイベントがありました。残念ながら、コロナ禍だったのでオンラインイベントとなりましたが、数人の署名者がスノーバードのホワイトボード前に集まるイベントでした。こちらも 動画が公開されている ので、ご興味があればぜひご確認ください。 アジャイル開発の現在と未来 アジャイル開発の現在から未来を見ていきましょう。この数年のニュースを調べてみると、現在に至るまで、アジャイルの広がりがよくわかります。海外に目を向けてみると、 80％以上の企業がアジャイル開発を取り入れている というデータもあります。 ただ、アジャイル開発はその国の文化にも影響を受けており、日本や香港の場合、ウォーターフォールのような従来型の手法が根強いため、なかなかアジャイル開発の導入が進まないケースもあるようです。 では、なぜ、ここまでアジャイル開発がメインストリームとなったのでしょうか？ その理由はいくつかありますが、まず、変化の激しい時代になったからでしょう。作れば作るほど売れる時代から、消費者ですら何がほしいかわかっていない時代になっているため、消費者のニーズを掘り当てながら進んでいく開発が必要になりました。 また、技術の進化もアジャイル開発に影響を与えています。たとえば、クラウド・仮想化・コンテナといった技術は、開発にスピードや柔軟性といった恩恵を開発者に与えました。手軽に使えるサービスや技術を活用しながら、よりアジャイルに開発ができるようになってきています。 最後に、アジャイル開発が成熟したこともあげられます。アジャイル開発はその名の通り、ソフトウェア開発が中心の理論でしたが、プロダクトマネジメントやビジネス、あらゆる仕事にその考え方が浸透し、広がっています。もうアジャイル開発はソフトウェア開発だけのものではなくなってきています。 これらの状況をふまえて、アジャイル開発の未来をちょっとだけ考えてみると、アジャイル開発はプロダクトマネジメント、テストや品質などを中心に議論が進んできています。この10年でアジャイル開発は当たり前になりました。ニューノーマル（新たな常識）と言えるかもしれません。さらに10年でプロダクトマネジメントやテストや品質分野が成熟していく可能性を秘めています。 さらに、アジャイル開発の拡大を元に、組織やスケールが課題になりつつあります。よって、アジャイル開発に対応するために、企業レベルの変化が求められていく可能性もあります。 The post 第1回 アジャイル開発の過去、現在、未来を知ろう！ first appeared on Sqripts .

はじめまして、QAコンサルタントのヤスゴロウです。今回は私の経験に基づくテストのアプローチ方法をご紹介させていただきます。 テストベースがないシステム テストベース ( ※1 ) 昨今のシステム開発事情 デジタル化が進んだ昨今では新規システム構築は稀で、既存システムのマイグレーションや既存システムの改修・保守開発( ※2 ）が多いと感じております。例えば、システム利用者のフィードバックを受け、改善のための改修・保守開発を繰り返してサービス向上やユーザビリティ向上等をおこなっているようなケースです。 こういった背景の中、弊社へいただくQAコンサルタントやテスト実施のご相談は、既存システムの不具合に悩まされている場合が多い気がしております。 しかもその既存システムに対して改修・保守開発を繰り返しているうちに、サブシステムが増えたり機能間の関係や仕様が複雑になったりする等の理由で、現在の開発担当者が全仕様を把握できていない状況をお見かけすることがあります。 とはいえ、競争の激しい現代においてビジネスを成功するためには、改修・保守開発をスピーディかつ不具合なく実施しなければいけないという使命があるため、大変な世の中だなと改めて思ってしまいます。 私も前職で15年程SE/PGや開発PMに従事しておりましたので、システム開発に携わっている方々の痛みに共感しております。 また、改修・保守開発は長期に渡っている場合があるため、ずっと同じ担当者が開発しているとは限らず、有識者の退職により全仕様を把握している方がいないというようなことはよくあることです。 このような事情から ・改修箇所の影響範囲の特定がうまくできない。 ・隠れ仕様に気づかず、設計、実装、テストの考慮漏れが発生する。 等の原因で本番障害が発生し、既存システムの品質改善や品質向上に悩みを抱えている企業様もいらっしゃいます。現代は避けたくても避けられない道なのかもしれません。 なぜテストベースがない場合があるのか 前述のような昨今のシステム開発事情より、テストベースとなるシステムの最新ドキュメントがない理由は大きく2つあると私は解釈しております。 1.引継ぎ情報不足 長期に渡り改修・保守開発を繰り返していると、開発担当者の入れ替えがあり、引継ぎがうまくできないケースがあると思います。 システムが大きくなればなるほど全仕様を理解することが難しいため、既存ドキュメントを改修する知識が不足し、また正しく更新する自信がないことにより、その時の改修箇所（差分）のみしかドキュメントを書かなくなってしまうのではないかと思います。 2.時間 ビジネスの機会損失を避けるためにシステムリリースのスピードを優先することがあります。動くもの（プログラム）は必須で新しくなっていきますが、そのベースとなる要件定義書や設計書等のドキュメント修正は「時間がないため後回し」にしてしまう場合があります。後で修正しようと思っていても、次のリリースの開発に追われ、ずっと修正できなくなってしまうケースもあると考えます。 また、ちょっとした改修の場合は、簡単なメモ程度で仕様を決めて済ましてしまう場合もあるかもしれません。理想は既存システムのドキュメントを更新して常時最新仕様を理解できるドキュメントを保持することですが、上記のような理由によりドキュメントを最新化できなくなっているのではないでしょうか。 テストベースが無いとどう困るのか 改修・保守開発を繰り返しているシステムにはテストベースとなる最新ドキュメントがない場合があることをお話してきました。では、なぜQA担当者はテストベースが無いと困るのでしょうか。 テストを実行するためには、まずシステムの正しい仕様を理解する必要があります。そして仕様に沿ってテストケースを作成し、「何を以って合格とするか」の基準となる「期待する結果」を定義する必要があるため、そのよりどころとなる情報が無いということになってしまいます。 特に、第三者検証の会社にテストを依頼する場合は、仕様を把握するためのテストベースとなる最新ドキュメントが原則必要となります。 必要なテストベースは実施するテストレベル( ※3 )にもよりますが、例えば利用者目線で業務の流れを一通りテストしてほしいというご依頼であれば、業務フローや業務ルール（処理の分岐条件等）を理解できるドキュメントをご提供いただきたいです。ですが「テストを実施してほしいが、最新仕様を理解できるドキュメントは無いです」と言われてしまった場合、どうすればよいでしょうか？ どういうアプローチがあるか アプローチのアイディア 私が担当したWebサイトのプロジェクトでテストベースがなかった時のアプローチをご紹介します。 私はJSTQBで学んだ「テストオラクル( ※4 )」が使えるのではないかと考え、探してみることにしました。テストオラクルになりそうなものはないか調べた結果、以下3つのものを使用しました。 (1) Webサイト上に公開されている説明やFAQ (2) 運用担当者やシステム管理者向けの業務マニュアル (3) 過去の障害事例 テストオラクルを使ってみる まずは、「利用者に公開している(1)Webサイト上に公開されている説明やFAQの通りに動作しなければ不具合である」とする作戦が良いと考えました。幸いお客様にも良いアイディアだと言っていただけたので、早速テストエンジニアに実践してもらいました。残念ながら(2)は最新なのか分からないものが多かったのですが、Webサイト上に書いていない条件分岐になる業務ルールは正解と見立てて参考にしました。(3)からはテストしたい業務に関係する実際にあった障害をピックアップし、障害が発生した画面操作手順や業務の流れを理解して、テスト条件や期待する結果を検討するための参考にしました。 設計書等のドキュメントに書かれた仕様通りに開発されていることだけが正解ではなく、Webサイト上で利用者向けに告知していることが期待通りにできなければNGにしようと考えたら、あとは意外とスムーズに進みました。 テスト設計の具体例 では、どのようなテスト設計の考え方があるのか一例としてECサイトを例にご紹介させていただきます。皆さんもECサイトで買い物をすることがあるかと思いますが、注意して読んでみると以下のような「業務ルール」と思われることが書かれている場合が多いです。 ・XXXX円以上購入すると送料無料 ・当月XXXXX円以上購入すると翌月顧客ランクアップ ・離島など地域によって特別送料を課金 ・配送方法（種類）を選択 ・決済方法（種類）を選択 ・在庫切れの場合 ・到着前にキャンセルする場合 ・返品する場合 等です。 前述の「(1)Webサイト上に公開されている説明やFAQ」を読み込むと、たくさんの業務ルールがあることに気が付きます。業務ルールを デシジョンテーブル のようなマトリクス表に整理するとテストケースを作成できるようになります。 具体的なイメージをもっていただくために以下に簡単な例を挙げさせていただきます。 例）ECサイトで送料無料になる条件 ・顧客ランクがプラチナの場合 ・顧客ランクがゴールドの場合、かつ１注文あたりの購入金額が5000円以上の場合 ・顧客ランクがシルバーの場合、かつ１注文あたりの購入金額が10000円以上の場合 得られるテスト結果の例（メリット） 私もプロジェクトにおいて、前述のような考え方でテストオラクルから業務ルールを洗い出してテストケースを作成し、テストを実行したら、それなりに不具合を挙げることができました。不具合を一覧にしてシステムの有識者に確認していただいた結果、「サイト上に公開されている説明やFAQ」の方が誤っている場合もあり、サイト上の表記を修正することで、品質向上につながりました。。 その他、長期に渡り立ち止まることなく改修・保守開発を繰り返しているシステムの品質を認識できる良い機会にもなりました。「思っていた以上に潜在不具合があったのだね・・・」というような感想をいただくこともありました。また、最新のテスト設計書ができあがったことにより、システムの有識者以外の方が仕様理解に活用できるようになりました。 まとめ ・長期に渡り改修・保守開発を続けている既存システムのテストはテストベースとなる最新ドキュメントがない場合が多く難易度が高いが、工夫すれば品質向上のための強化テストを実施することができる。 ・テストベースが無い場合は、いかに適切なテストオラクルを見つけ出して妥当な「期待する結果」を導出するかが重要である。 ・場合によっては仕様理解用のドキュメントとしてテスト設計書が利用できることもある。 今回ご紹介したWebサイトのようなフロントシステムの場合はテストオラクルが探しやすいと思いますが、目に見え辛いバックエンドシステムの場合にはどのようなテストオラクルを見つけ出せるのか、今後の課題として取り組んでいこうと考えております。 APPENDIX:用語の説明 ※1 テストベース 「テスト分析と設計のベースとして使用するあらゆる情報」（ ISTQB Glossary より引用）具体的には、以下のようなものである。 ・要件仕様。ビジネス要件、機能要件、システム要件、ユーザーストーリー、エピック、ユースケースの他、コンポーネントやシステムに期待される機能および非機能の動作を指定する類似の作業成果物などがある。 ・設計および実装情報。システムやソフトウェアに関するアーキテクチャー図もしくはドキュメント、設計仕様、コールフローグラフ、モデル図（UMLやER図など）、インターフェース仕様、コンポーネントもしくはシステムの構造を指定する類似の作業成果物などがある。 ・コンポーネントまたはシステム実装そのもの。コード、データベースのメタデータやクエリー、インターフェースなどがある。 ・リスク分析レポート。コンポーネントやシステムの機能、非機能、構造の各側面を考慮する。 出典： ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03 「1.4.2 テストの活動とタスク」 ※2 改修・保守開発 IPAのソフトウェアデータ白書 「表　開発プロジェクトの種別の選択基準」中段「スクラッチ開発」の「b:改修・保守」に該当する開発プロジェクト 出典： 独立行政法人情報処理推進機構 (IPA) 「ソフトウェア開発分析データ集2022」 2022年9月26日 発行 P.197 この表の通り、母体となる既存システムの規模に対して、どの程度「機能仕様の追加・変更があるか」により、開発プロジェクトの種別を判断してステークホルダー間で共通認識を持つことができる。 ※3 テストレベル 「具体的にインスタンス化したテストプロセス」（ ISTQB Glossary より引用）具体例としては、単体テスト、結合テスト、総合テストのようなテストプロセスの段階。 ※4 テストオラクル 「テスト対象のシステムの実行結果と比較する期待結果のソース」（ ISTQB Glossary より引用）　具体例としては、実在するベンチマーク用のシステム、他のソフトウェア、ユーザーマニュアル、個人の専門知識等など。コードであってはならないと言われている。 The post テストベースがないシステムの不具合を見つけるアプローチ first appeared on Sqripts .

はじめに 旅が大好きな、いしだぁぁです！ 私は、現在ソフトウェアテストとはかけ離れたアノテーション（詳細は後述）に関わるプロジェクトに従事しており、ソフトウェアテストの経験は浅いですが、JSTQBのFL取得に向けた学習を行っています。 ソフトウェアテストを勉強していくうちに、アノテーションの作業プロセスは、ソフトウェアテストプロセスと類似していることが分かりました。 アノテーションの作業プロセスに、ソフトウェアテストプロセスを応用すれば、よりよいプロジェクトになれるのでは、とそう考えました。 まずは、ソフトウェアテストプロセスの良いところをどのように取り入れていけばよいのかと考えたとき、最初に頭に浮かんだのは「学ぶことは、模倣から始める」です。 「模倣」は、否定的に見られがちですが、個人的には、ただ真似るだけではなく、その中から工夫も改善も自然と生まれ、重要な要素であると考えています。 このテックブログを通して、アノテーションのようなソフトウェアテスト以外のプロジェクトでも、ソフトウェアテストの様々な仕組みや技法を知ることによって、プロジェクト成功への近道となるヒントがもらえるのではないか、と感じていただければ幸いです。 アノテーションとは！？ 「アノテーション」と聞くと、あまりなじみがなく、遠い存在だと感じる方が多数いらっしゃるかもしれません。 私もその中の一人でした。 アノテーションとは、英語で「注記・注釈」という意味であり、ITの分野では、対象となるデータの一つひとつに、タグやメタデータと呼ばれる情報の付与を行う作業です。 アノテーションの対象となるデータには、以下の３種類があります。 画像＆動画データ 音声データ テキストデータ より詳しく言うと・・・アノテーションとは、AI開発のプロセスにおける必須の通過点であり、機械学習に使われる教師データを作成する工程を指しています。 教師データって！？ 例えば、みかんの画像があったとします。 この画像を「みかん」とAIに認識させるためには、みかんの画像に「これはみかん！！」という情報を付与してAIに学習させる必要があります。学習用の画像それが教師データです！！この教師データをたくさん作り学習させることで、AIがみかんを認識できるようになります。 しかしながら…AIにみかんの画像だけを学習させればいいというわけではなく、同時に例えば「りんご」との違いも認識する必要があります。AIにみかんだけの画像ばかり学習させてしまったら・・・りんごの画像を見せたときに、りんごをみかんと認識してしまう可能性があります。そのため、りんごのデータも学習させる必要があります。そうすることで、AIはみかんとりんごの特徴の違いを認識できるようになります。 このように教師データを使った機械学習によって形作られたAIは・・・実は、ビジネスや日常生活等のあらゆる場面に潜んでいます。 「これは便利だ！」、「すごい・・・技術が進歩している！！」と思っていたそこのあなた。 それらのモノにはアノテーションを使った学習済みAIが組み込まれている可能性があり、ビジネスや日常生活などで直面する問題を解決する手助けとなっているかもしれません！ アノテーション作業自体はとてもシンプルですが、AIの教師データとなり、その品質がAIの動作に大きく影響を与えます。AIが正しく動作するように、一枚一枚丁寧に作業してあげる必要があります。ですので、 日々我々は「重要な役割を担っているんだ！」という使命感を持って 作業しています。 ソフトウェアテストとアノテーションの作業プロセスについて 書籍『ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応』（以下「ソフトウェアテスト教科書」と称する）に出会う前までは、アノテーションの作業プロセスについて深く考える機会がありませんでした。 ソフトウェアテストを勉強していくうちに、アノテーションの作業プロセスは「実行前作業」「実行時の作業」「完了作業」「全体を通して行われる作業」の4つに分類され明確になるのでは・・・と気付きました。さらに、アノテーションの作業プロセスには、ソフトウェアテストプロセスとの類似点があることにも気付きました。 何を隠そう、私はソフトウェアテスト教科書に出会う前までは・・・事前準備や納品等の事後作業もすべて「作業実行」に含まれると思っていました。つまり、アノテーションの作業プロセスは、「作業実行」1つのみであるというのが、私の最初の考えでした。お恥ずかしい限りです・・・ それでは、両方のプロセスの全体像を見ていきましょう。 ご覧の通り、両方とも「実行前作業」「実行時の作業」「完了作業」「全体を通して行われる作業」の4つに分類することが可能です。 私が現在担当しているプロジェクトについて、ソフトウェアテストプロセスと同じように整理することができました。 ソフトウェアテストとアノテーションのプロセスの類似点について つぎに両方の類似点に着目していきましょう。 プロセス/作業内容 ソフトウェアテスト アノテーション 実行前作業 テスト計画（開始基準の設定） ・テスト目的の決定＆共有 ・テスト範囲の決定　等々 作業前準備（開始基準の設定） ・作業目的の決定＆共有 ・作業範囲の決定　等々 実行時の作業 ・実行レポートへの反映 ・欠陥レポート作成、反映　等々 ・実行レポートへの反映 ・欠陥レポート作成、反映　等々 完了作業 ・テスト結果の報告　 　> 実行レポート提出 　> 欠陥レポート提出 ・テストウェアの整理 ・作業結果の報告 　> 実行レポート提出 　> 欠陥レポート提出 ・改善活動 　> 各レポートの整理整頓　等々 全体を通して行われる作業 ・進捗管理 ・終了基準等の達成状況の確認 ・進捗レポート作成＆提出　等々 ・進捗管理 ・各メンバーの目標値の達成状況の確認 ・進捗レポート作成＆提出　等々 ご覧の通り、プロセス内の作業内容にも多くの類似点があることがわかりました。 多くの類似点の存在を知ったことで、今ではプロジェクトでうまくいかないことがあったら、ソフトウェアテストプロセスや作業のやり方・良いところを模倣して参考にすればよいのだ！という安心感を持って進めることができています。 応用事例の紹介 それでは、実際にソフトウェアテストプロセスを、アノテーション作業プロセスに応用してみると、どのような効果が得られたか、いくつか応用事例を紹介します。 応用事例１「開始基準」の応用 ソフトウェアテスト教科書には、このように記載されています。 開始基準 「開始基準が満たされないままにテスト活動を開始すると、難易度が上がり、テスト時間が増え、コストも増え、リスクが高まります。」 アノテーションは、画像が驚くほど大量にあります。画像が何万枚もある中で、どこから作業を始めればよいか、どこまで作業をすればよいか、といったような迷いが出ないように事前に入念な準備が必要となります。 特に初めて作業するデータに着手する時は、開始基準の設定に多くの時間を費やすようにしています。例えば、トレーニングに要する時間や相互チェックの実施方法、頻度を事前にお客様と相談して決めておく必要があります。 トレーニングに要する時間 どれくらいできればよいか どこまでやるか 相互チェックの実施方法 全量チェックか、サンプリングチェックか どのくらいの頻度でやるか これらを考慮せずに作業を進めてしまうと、予想以上に工数がかかったり、手戻りが発生したりしてしまうという大変な思いをしたことがありました。 作業を円滑に進めるためには、開始基準を明確化し、お客様としっかり連携を行いながら、チーム内の情報共有を行うことがとても重要であると、毎回実感しています。 応用事例２「工数に影響する要因（人の特性）」の応用 ソフトウェアテスト教科書には、このように記載されています。 テスト工数に影響する要因（人の特性） テスト工数を見積もるためには、テスト工数の見積りに影響を与える要因を知っておく必要があります。考慮もれによるテスト工数の見積り誤りを防ぐためです。 見積りに影響を与えるものとして、テスト対象であるプロダクトの特性、開発プロセスの特性、人の特性、テスト結果などが挙げられます。 人には得意分野や不得意分野があり、それぞれの能力や実力には個人差があります。そのため、実際の作業に入る前に、各メンバーが十分にトレーニング期間を設けて、各メンバーの能力と実力を正確に把握することが必要となります。 各メンバー同士も作業に必要なスキルや知識を共有できますし、作業管理者も各メンバーの能力と実力に合わせた作業分担やスケジュールを立てられるようになります。 以上のように、工数に影響する要因として人の特性を把握することが、工数見積りの精度向上につながる重要な要素であると、毎回実感しています。 応用事例３「欠陥マネジメント」の応用 ソフトウェアテスト教科書には、このように記載されています。 欠陥マネジメント 欠陥は、検出時点から分類、修正、最終確認まで、きちんと追跡しなければなりません。その対策が終了するまでマネジメントできなければなりません。 欠陥をマネジメントするためには、発生したすべての欠陥を記録しなければなりません。 アノテーションミスを見つけることは重要ですが、それらをきちんと管理していかなければなりません。以前は適切に管理できておらず、記録が見つからない、同じ失敗を繰り返すなんてことがありました。今は記録を取り比較することで、優先順位を付けられますし、ミスの記録を参照することによって、将来的なミスの予防につなげられるようになっています。アノテーションミスの記録を残し活用することがとても重要であると、毎回実感しております。 以上、応用事例を３つ紹介しましたが、ソフトウェアテストプロセスを応用することで、 作業の効率が上がり、他の作業に割ける時間が増えるなど、様々な効果が生まれました！ 同時に、「学ぶことは模倣から始める」ということが大切であるとひしひしと感じました。 おわりに 最後になりましたが・・・ 今のプロジェクトをよりよいものにしていきたいという思いから始まった挑戦 　 ソフトウェアテストプロセスの他分野への応用 「学ぶことは、模倣から始める」 　「物事の上達は、模倣にあり」 うんうん、模倣だっていいさ。 まずは、模倣してみることから始めて改善に役立てたいと考え、ソフトウェアテスト教科書を読み込んで、とことん模倣してやろう！という気持ちで改善活動をスタートしました。 この改善活動によって、ソフトウェアテストプロセスとの類似点があるという新たな気付きや、模倣から始まり改善に役立てたという新発見をもたらしました。そして、応用事例で紹介したように様々な効果が得られ、業務改善に役立てることができました。 今回の学びは、ソフトウェアテストプロセスの中から、模範となるものを見つけて、そこから模倣して、改善に役立てるのが、私にとってプロジェクト成功への近道であるとわかったことでした。 教科書は読んで終わりではもったいないです！！ ソフトウェアテストプロセスの良いところを模倣して、改善活動してみませんか？ ひょっとしたら、ビジネスだけではなく日常生活シーンでも改善に役立って、心豊かな生活のヒントをもらえることがあるかもしれませんよ！？ 今回の活動を通して、「他分野へのソフトウェアテストのプロセスの応用」が利くということがわかりましたので、今後も試行錯誤を繰り返しながら改善活動を継続していきたいと思います。 皆さんもぜひ、模倣から始めて、新しいことに挑戦してみてはいかがでしょうか。 追伸 2月末、JSTQB認定テスト技術者資格 Foundation Level試験を受けてきました～さて、結果はいかに！？ 次回、試験結果・・・それとソフトウェアテスト経験が浅い私の勉強の進め方も紹介するので、お楽しみに♪ The post 模倣だっていいさ　挑戦してみた　ソフトウェアテストプロセスの他分野への応用 first appeared on Sqripts .

デバッグとは デバッグの語源や由来 デバッグという言葉は、不具合を表す「バグ（bug）」という言葉に由来するとされています。 実際にコンピュータに虫がはまり込んで故障を起こし、虫を取り除いたことにちなんで名付けられたと言われています。 デバッグの重要性 デバッグは、ソフトウェア開発の重要なプロセスの１つであり、プログラムが期待通りに動作しない場合に、その原因を特定し修正することです。デバッグが重要な理由は、ソフトウェアにバグがあると、それが原因でソフトウェアが正しく動作しなくなる（バグ）ことがあるためです。 例えば、予期せぬ動作が発生したり、データの損失、セキュリティ上の問題など、様々な問題が発生する可能性があります。そのような問題は、顧客やユーザーから不満やクレームが出ることがあり、企業の信頼性や評判に悪影響を与える可能性があります。そのため、デバッグはソフトウェア開発において欠かせない作業であり、十分な時間とリソースを費やすことが重要です。 デバッグとテストの違い デバッグとテストは関連性がありますが、異なるプロセスです。具体的に言うと、テストはソフトウェアの品質を評価するために、入力値や条件を変えながら繰り返し実行し、正常動作やエラーが発生しないことを確認するプロセスです。 一方、デバッグはテスト中に検出されたエラーを修正するために、エラーの原因を特定して、修正するプロセスです。つまり、テストとデバッグは密接に関連していますが、テストはソフトウェアの品質を確保するためのプロセスであり、デバッグはテスト中に検出されたエラーを修正するためのプロセスであると言えます。 デバッグのプロセス バグの発見 プログラムのバグは、さまざまな方法で発見できます。テスト段階、ユーザーからのフィードバック、エラーメッセージ、クラッシュやフリーズなどの動作異常などがそれに当たります。開発者自身がコードをレビューして問題を見つけることもできます。 さらに、自動テストツールを使ってバグを検出することもできます。自動テストツールは、テストスクリプトを作成して自動的にテストを実行し、ソフトウェアの動作を評価します。 また、静的解析ツールを使って、ソースコードの構文やロジックを解析し、潜在的なバグを検出することもできます。バグを発見するためには、多様な手法を駆使し、徹底的にテストを行うことが重要です。 バグの原因の特定と分析 バグが発見されたら、それを修正するためにバグの原因を特定し原因を分析する必要があります。バグの原因を特定するために、開発者はデバッグ技術を使用して問題を特定します。これには、デバッガーの使用、ログファイルの分析、コードのレビューなどが含まれます。 バグの原因を特定したら、原因を分析し、修正するための対策を検討する必要があります。バグが発生した環境を再現し、修正されたコードが望ましい結果を生成することを確認するために、テストを実行する必要があります。 バグの修正と検証 バグの修正には、バグが含まれるコードの変更が必要です。修正後には、テストを実行して、修正が正しく機能していることを確認する必要があります。テストは、単体テスト、結合テスト、システムテスト、受け入れテストなど、さまざまなレベルで行われます。また、コードの修正が予期せぬ影響を及ぼしていないかをテストするレグレッションテストもあります。 デバッグプロセスの成功には、開発者が良好なデバッグ技術を持っていることが不可欠です。また、デバッグ過程で生成される情報を分析し、問題の特定と解決策の検討を行うことが重要です。最終的に、バグの修正とテストが行われ、問題が解決されたことが確認されるまで、デバッグプロセスは続きます。 デバッグの手法 机上デバッグ 机上デバッグとは、プログラムのコードを読み込み、問題を予測し、推論する手法です。コードを熟知していることが前提となります。机上デバッグでは、コードのシミュレーションや手計算によって、プログラムの実行過程を想定し、問題を特定することができます。具体的には、変数の値の変化や制御フローの動きを手計算で追いながら、どこで問題が発生しているかを推論することができます。 机上デバッグは、デバッグの初期段階でよく使われますが、複雑なプログラムになるほど限界があるため、実際にプログラムを実行しながらデバッグする必要があります。 デバッガを使う デバッガを使うことで、実行中のプログラムの状態を見ることができます。デバッガを使って実行中のプログラムにブレークポイントを設定することで、特定の箇所で実行を止めることができます。ブレークポイントで実行を止めた後は、その時点での変数の値を確認したり、ステップ実行という機能を使って、1行ずつプログラムを実行しながら問題を特定することもできます。デバッガは、複雑なプログラムのデバッグに非常に有効であり、開発者にとって欠かせないツールの1つです。 デバッグを効率的に行う方法 設計書を確認し、仕様を把握する ソフトウェア開発においては、設計書に基づいてプログラムを作成します。プログラムに不備がある場合、設計書に不備がある可能性があります。そのため、設計書を確認し、仕様を把握することが重要です。 設計書は、ソフトウェアの全体像や各機能の詳細な仕様、ユーザーインターフェースの設計などが記載されているため、設計書を確認することで、プログラムがどのように動作するかを把握することができます。プログラムに問題がある場合、設計書を再度確認し、仕様が適切に反映されているかを確認することが重要です。 設計書の内容が不明確であったり、不備がある場合は、開発チーム内で議論を行い、問題を解決する必要があります。 わかりやすいプログラムを書く わかりやすく、コンパクトにまとめられたプログラムを書くことで、デバッグの効率が上がります。変数の名前を適切につけたり、処理をわかりやすく分割することで、デバッグがしやすくなります。 また、コメントを付けることで、プログラムの処理内容や意図が明確になり、デバッグがよりスムーズに進むでしょう。さらに、コーディング規約に従ってコードを書くことで、複数人での開発においてもコードの可読性が向上し、デバッグ作業が効率的に行えます。 ログを出力し確認できるようにしておく プログラムが実行される際に、ログを出力することで、プログラムの動きを確認することができます。ログを出力することで、特定の箇所でプログラムが異常終了したり、想定外の値が返されたりすることがわかります。 また、ログを出力することで、プログラムの動作を再現することができます。バグを再現することができれば、その原因を特定しやすくなります。ログを出力する際には、必要な情報だけを出力するように設定することが大切です。大量のログが出力されると、逆にデバッグの効率を下げてしまいます。 分割統治法 分割統治法は、問題を小さな部分の問題に分割し、それらを再帰的に解決していく手法です。大きな問題を小さな問題に分割することで、それぞれをより単純な問題として解決することができます。 例えば、ある関数において発生しているバグの原因を探したいが、処理が大きく複雑になってしまった場合、問題のある箇所とない箇所を分けることで問題箇所を絞り込んでいきます。 分割統治法は、アルゴリズムやデータ構造の設計にもよく用いられる手法です。 デバッグツール デバッグツールを利用するメリット・デメリット デバッグツールのメリット デバッグツールを利用すると、以下のようなメリットがあります。 プログラムの実行中にデータの値を確認できるため、プログラムの振る舞いをリアルタイムで確認できます。 デバッグツールは、プログラムの構造を理解するのに役立ちます。コードの一部分だけでなく、プログラム全体を俯瞰することができます。 デバッグツールは、コードの実行速度を計測することができます。これにより、プログラムのボトルネックを見つけることができます。 デバッグツールのデメリット デバッグツールを利用すると、以下のようなデメリットがあります。 デバッグツールは、プログラム実行時にリソースを消費するため、プログラムの速度が低下する可能性があります。 デバッグツールの操作方法を理解するまでに時間がかかる場合があります。 デバッグツールは、プログラムが動作している環境に依存するため、特定のプログラミング言語やプログラム実行環境に限定される場合があります。 代表的なデバッグツール 代表的なデバッグツールには、以下のようなものがあります。 Visual Studio Debugger：Microsoft Visual Studioに含まれるデバッグツール。C/C++やC#、Visual Basic.NETなどで書かれたプログラムのデバッグに使用されます。 Xdebug：PHPのデバッグツール。PHPスクリプトのデバッグやプロファイリングに使用されます。 WinDbg：Microsoft Windows上で動作するデバッグツール。Windowsのカーネルやドライバ、アプリケーションのデバッグに使用されます。 gdb（GNU Debugger）：UNIX系OS上で動作するデバッグツール。C言語やC++言語で書かれたプログラムのデバッグに使用されます。 Valgrind：Linux環境で動作するプロファイリングツール。メモリリークやプログラムの最適化に使用されます。 まとめ デバッグは、ソフトウェアの品質を維持するための重要なプロセスです。バグの発見方法には多様な手法があり、自動テストツールや静的解析ツールも使用できます。 デバッグの目的は、テストとは異なるプロセスで、テスト中に発見されたエラーを修正することです。バグを修正するためには、バグの原因を特定し、原因を分析する必要があります。プログラムの問題がある場合、まず設計書に不備があるかどうかを確認することが重要です。また、コードの品質を上げることでデバッグをしやすくすることが大切です。 デバッグをうまく活用してプログラム開発を行いましょう。 The post ソフトウェアプログラミングにおけるデバッグとは？ first appeared on Sqripts .

テスト駆動開発のスタイルを取り入れているもののテストのことはあまりよくわかっていないプログラマーと、テストへの熱い情熱をもちつつプログラマーの事情はわかっていないテスターとが、小さな障害の発見をきっかけとして出会い、役割の壁を崩しながら少しずつ協調するようになっていく、小さなお話です。 登場人物 プロ之 … プログラマー テス緒 … テスター 前回、テス緒さんとプロ之さんはそれぞれのリーダーから指摘を受け、プロダクトにとって大事なこと、チームにとって大事なことが何なのか考え直しました。そしていま調べている問題も大事なことだから、継続して調べようと2人で決意しました。 プログラマーが切り込む話 テス緒さんはテストチームリーダーと、プロ之さんは開発チームリーダーとそれぞれ交渉し、もうしばらくこの問題を追及していいことになりました。2人はそれぞれ自分の時間を使って調査を進め、これからお互いの発見を持ち寄って話し合うところです。 プロ之(以下、P)「total_hoursを更新する可能性がある箇所を、コールグラフを使って探したらAPIと画面合わせて4箇所ありました。APIはその先にUIがあるので、画面的には9箇所になります」 テス緒(以下、T)「えっそんなに？」 P「でも画面によっては他の項目を更新するだけなので、実際にtotal_hoursを変えられるのは4画面です」 T「あ、それならわかる」 P「4画面のどのパスもテストでカバーしているし、とりあえずおかしくは見えませんでした。ところがですね、念のためgrepしたら…」 T「ぐれーぷ？」 P「…リポジトリ横断して全検索したら、まったく別のアプリでtotal_hoursがヒットしました。更新していないバージョンで、どうやらIE対応のもののようです。現状稼働しているのか、よくわかりません」 プロ之さんはツールを駆使して、関係ありそうな箇所を絞り込みました。こうしたツールは開発中や、特にデバッグ時によく使うものです。 T「すごい！ よくそんな詳しく調べられたね」 P「基本的なことですよ」 T「ホームズみたい！」 P「カンバーバッチみたいですか？」プロ之さんの顔がちょっと嬉しそうになりました。 テス緒さんが「あ、ロバート・ダウニー・Jr.だと…」と言いかけるとプロ之さんの顔が曇ったので、あわてて話題を変えました。※1 ポイント: 問題の原因となり得る箇所を特定するために深く掘り下げるアプローチがある 開発者が原因追求に利用するツールはテストや調査でも利用価値がある ※1 著者はジェレミー・ブレット派です。 テスターが見逃さない話 テス緒さんはログを画面共有で表示しながら説明しました。「テストケースを増やすのはやめにして、表示がおかしいあたりのデータが登録されたときのログを500行くらい絞り込んで眺めたのね」 P「ただ眺めるんですか？」 T「他の仕事もあるからずっと眺めてたわけじゃないけど、ときどき引っ張り出してね。何度も見てると、だんだん“引っかかるな”って感じがしてきて、そうしたら！ 気がついたのよ」 P「ただ眺めるだけで？」 T「っていうか、絞り込んだログだけ眺めても何もわからなかったんだけど、別の条件にしたらログの出方が違っているのに気がついて。ほとんど同じなんだけど、あっちは”recorded”なのに、こっちは”record”になってて、スペルが違うでしょ。表示がおかしくなるのは、”record”って出ているときだけみたいで」 P「すごいですね。執念というか」 T「気になったから気にしてただけだけどね。これ、なんでだかわかる？」 ポイント: ログやデータなどを広範に調べ、問題の起きる条件を追求するアプローチもある 意味がわからなくても些細な違いや違和感を拾い上げると、突破口になることもある ついに問題を突き止めた！ プロ之さんは少し考えて答えました。「わかりませんが、調べればわかると思います。その部分はログの固定文言だと思われるので、検索すればすぐ見つかると思います」 プロ之さんはそう言いながらもうキーボードを叩いています。テス緒さんはプロ之さんがどう作業を進めるのか知りたくなって、画面共有してもらうように頼みました。 T「タイピングすごい速いんだね。あ、検索ってコマンドで実行するの？ いつも検索ツールを使ってるけど、そっちの方が早いね」 P「ログを検索するのとコードを検索するのは違いますよ。でも良かったらあとで教えます。それはともかく、ログに”recorded”ではなく”record”と出力する箇所が見つかりました。total_hours更新で絞り込むと…やった、1箇所だけです。それに…先ほどのIE用サービスの中です。これはビンゴですよ」 T「じゃあそのサービスを使っている画面を使えば、現象を再現できるかも！」 プロ之さんはIE用のサービスを手元の開発環境で立ち上げて、テス緒さんは以前に作ったテストケースを実行しました。数件実行したところで、テス緒さんが声を上げました。 「出た！ できた！ こっちの画面で入力して、あっちの画面だと9.9だけど、この画面は10.0になってる。やったよプロ之さん！ 突き止めたよ！」 「やりましたね。古いモジュールが原因だったんですね。おめでとうございます」プロ之さんは表情はあまり変えず、しかしいつもより早口で言いました。 テス緒さんはくちびるを尖らせて言いました。「何言ってるの、おめでとうなんてひとごとみたいに。プロ之さんと私で一緒にやりとげたんだから、もっと喜んで！ ほら、やったーって言って！ やったーって」 「確かにそうですね。私も嬉しいです。でもやったーと言う必要は…言わないといけないんですか？…はい、では、や、や、ヤッター」 こうして、テス緒さんがテスト中に発見した不思議な挙動の原因が判明しました。まだ開発環境で確認しただけなので、本番環境でも同じ結果になるか追加の確認が必要です。また原因がわかったら、修正して正しく動くようにすることになります。問題の性質によっては、修正が難しいことがあったり、影響が軽微なら修正不要と判断する場合もあります。プロ之さんは既に、どう修正を進めるのが良さそうか考え始めています。 2人はここでいったん作業を終えることにしました。1週間後にまた集まることにして、それまでに本番環境での確認を進めたり、IE対応サービスがなぜ最近修正されていないのか調べたりしてくることにしました。テス緒さんもプロ之さんも、大きな壁を乗り越えた充実感と自信に満ちあふれて、明るくセッションを終了しました。 ポイント: 開発者にもテスターにもそれぞれの直感があり、両方を組み合わせて使う おたがいのスキルや経験、人間性を尊重しあうと能力を発揮できる 真の問題とは？(次回に続く) テス緒さんはIE対応サービスを使うために、過去のテスト資料を調べていました。そこで見つけたテストケースには、なんと「IE対応終了のテスト」として、画面がすべて使えないと確認するテストケースが書いてありました。実際に試しても、本番環境ではIE対応サービスにアクセスできません。 テス緒さんは考えました。「(問題がある箇所を見つけたのに、アクセスできないんだったら実際には問題が起きるわけがない！ まったく違うところに問題があるのかなあ？ それじゃあ調べたのが全部ムダになってしまう。どうしよう…)」 同じ頃プロ之さんは先輩の開発メンバーから、IE対応は1年以上前に終了しており、サービスも停止していると教わっていました。それを聞いてプロ之さんも考えます。「(終了しているサービスなら問題は起き得ないし、修正しても意味はない。修正の検討は時間の無駄になった。ここまでの調査も無駄と言える。これ以上、時間を使う意味はない)」 本連載の次回では、2人がついに真の問題に到達し、連載も最終回となります。 The post 【テスターと開発者が上手に協力するには】第4回：立場を越えて問題を追及しよう first appeared on Sqripts .

こんにちは、エンジニアをしているタカです。 今回は 私が受けた アジャイルソフトウェア開発技術者試験の 受験レポートを記したいと思います。 アジャイルソフトウェア開発技術者検定試験とは アジャイルソフトウェア開発技術者検定試験 アジャイルソフトウェア開発技術者検定試験は、アジャイルソフトウェア開発に関する知識やスキルを認定するための検定試験です。 Lv1, Lv2がありますが、Lv1は受験するための条件は無く、アジャイル開発の基礎知識に関する問題が出題される入門的な位置づけです。 なお、検定試験は指定された全国の試験会場と日時での受験が可能です。 受けようと思ったきっかけ 直近のプロジェクトでスクラムマスターの役割で開発に携わっており、体系的な知識の整理に役立ちそうと感じたことや、現時点で会社の推奨資格に上げられていることもあり、受けてみようと考えました。 申込完了まで 受験申し込みは、公式サイトからリンクされているプロメトリックのサイトでプロメトリックIDを取得のうえ、試験日の3営業日前までに会場と時間を指定して申し込みを行います。 Lv1の場合、受験料金は11,000円（税込）でした。 申し込みが完了するとメールで確認証が送られてきますが、念の為、画面に表示された確認証を印刷しておきましょう。 学習 アジャイル検定公式テキスト が販売されており、体系的な知識を整理するためにも、こちらを購入して学習することをおすすめします。 プロジェクトでアジャイル開発に携わっている場合は、このテキスト以外に学習は特別必要ない印象でした。 ただし、本番試験は60問で合格条件が80%のため、単純計算で48問以上の正答が必要となります。 ミスを極力減らす必要があるため、XP、スクラムなどの様々なアジャイルのフレームワークの用語や考え方を知っておくと良いので、必要に応じて、アジャイルサムライなどの関連書籍も一読しておくと安心かと思います。 なお、試験内容については守秘義務があり、過去問題も出回っていませんが、公式テキストに演習問題が付いています。 試験当日の流れ 当日は、試験開始時間より前に集合時間が設けられており、その時間まで会場に向かい、確認証と、確認証記載の本人確認書類を提示して受付を済ませます。 私は会社近くの受験会場に申込み、徒歩で会場に向かったのですが、初めて行く場所だったので入り口を探すのに5分ほど迷い…結果的にギリギリの到着になりました。 どのような試験にも言えることですが、初めて行く場所には早め早めに付くように心がけていきましょう。 なお、集合時間に遅れた場合は受験ができないと明記されているので要注意です。 入室～試験中 時間になったら、指定される最低限の持ち物だけを持って入室します。 なお、ティッシュは持ち込みが許されており、鼻炎持ちの私には大変助かりました。 他の荷物はロッカーが準備されているので、そこにしまっておきます。 試験時間は60分で全て選択式となります。 時間は余る印象なので、問題と回答をよく読み、全て回答したらもう1周最初から読み込んで、ケアレスミスを無くすことを心がけていきましょう。 前述の通り問題内容はここでは掲載できませんが、私の結果は97点で合格でした。 試験が終了するとその場で結果が出るので、事前に指示された通りに退出し、受付の方に報告後に荷物を持って退出となります。 結果レポートはメールで受け取れ、後日合格証明書が送られます。 おわりに 今回の内容は以上となります。 Lv1試験はいつでも受けれる試験かつ難易度はそこまで高くないため、比較的受けやすい試験になります。 興味をお持ちの方の参考になれば幸いです。 The post アジャイルソフトウェア開発技術者検定Lv1 受験レポート first appeared on Sqripts .