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

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

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

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

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

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

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

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

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

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

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

こんにちは。QA事業本部 クオリティマネージメント部 QMグループのヤスゴロウです。 私は15年ほど開発エンジニアを経験した後、QAエンジニアになり今年で16年目です。 現在は、QAコンサルタントの業務を担当しております。 開発エンジニアや開発プロジェクトマネージャー（以下「PM」という）からQAコンサルタントの職種に転職することを迷っている方がいらっしゃると耳にしましたので、お役に立てればと思い、熱く語らせていただきます！ なぜ私はQAエンジニアに転身したのか きっかけ はじめに、私がQAエンジニアになった経緯をお話させていただきます。私の場合は自分からQAエンジニアになることを希望したわけでなく、前職で「CMMI( ※1 )を用いたクオリティーマネージメントシステム（以下「QMS」という）の構築プロジェクト」に入ることを上司に薦められたことがきっかけでした。 私は業務システムやアプリケーションの仕組みを考えて自分の思惑通りの出来栄え(品質)に完成させることにやりがいを感じているシステムエンジニア（以下「SE」という）でしたので、あまりの新天地へのオファーに迷いました。しかし一方で、誰もやったことがないことを社内初でチャレンジして広めることも嫌いではなかったので引き受けることにしました。 実際やってみると、様々な学習が必要だったり、開発担当者をなかなか説得できなかったりなど苦労がありました。とはいえ、社内の有識者のお知恵を拝借したり、社外のCMMIコンサルタントの指導を受けたりして、なんとか皆で力を合わせて社内のQMSを構築することができました。 悟り 経験してみて悟ったことは「QAエンジニアがQMSを構築したりプロセスを改善したりすることは、開発エンジニアが業務システムを構築したり改善(保守開発)したりすることと大差がない」ということでした。プロダクトの品質を向上するための仕組み(システム)を考えたり、業務プロセスと同様に品質担保のためのプロセス(手順)を改善・効率化したりする仕事だと分かったら、段々面白くなってきました。システム構築や改善に興味があれば、誰でもできる仕事なのだと悟りました。 飛躍 その後、QMSは運用フェーズに入ったためQMS構築プロジェクトは解散し、気づいたら部門マネージャーと私だけの間接部門で運用・改善することになっていました。1人で多数のプロジェクトの品質を見るのは大変でしたが、更に独学を繰り返し、開発エンジニアの経験を活かして、ソフトウェアエンジニアリングプロセスの詳細まで踏み込み、要件定義プロセス、設計プロセス、テストプロセスの構築(標準化)をほぼ１人で成し遂げました。 　出来上がってしまうと、あとはPDCAをまわしていくだけになってしまいました。それはそれでやりがいがありましたが、開発好きの私は運用だけでは物足りなくなってきました。 それから、社外のセミナーなどにも積極的に参加して有識者からも学ぶ機会があったとはいえ、所詮独学で自信がないところがありました。また、自信がないところがあるのに社内で一番の品質有識者のように扱われるようになってしまったため、もっと本物の有識者と一緒に働いて学んでみたい、自分がやってきたことが間違っていなかったかを確認したい(答え合わせをしたい)と強く思うようになりました。 いざ転身 このような経緯より、某開発会社の間接部門の「自称QAエンジニア」だった私は、独学で身につけたスキルを活かしてQAエンジニアの職を生業にして極めようと思い、AGESTのQAコンサルタント職へ転職しました。 そして入社後、上司の 高木陽平 さんと1on1をした際に、私のテストプロセス改善のアプローチは「かなりいい線いってたことが分かり大満足」でした。現在も多数の有識者や学習熱心な同僚達に囲まれて、希望通り楽しくお仕事をさせていただいております。 QAエンジニアの職務紹介・品質向上に貢献するアプローチの事例 では、ここからは私がQAエンジニアに転身してから経験したQAコンサルタントの職務と私が悟ってきたことをご紹介させていただきます。 開発プロジェクトにおいて、テストで不具合を見つけて解消することも必須ではありますが、テスト工程まで進捗してから修正することだけでは時間の制約など限界があります。 シフトレフト( ※2 )でテスト工程より前の上流工程から不具合を解消していくと手戻り感を削減することができます。 そのためのQAコンサルタントの職務の１つとして「開発プロセス改善」というお仕事があります。「開発プロセス改善」とは、簡単に言いますと「開発工程で不具合を混入しないような手順に変えたり、ルールを強化したりすることである」と私は解釈しております。（これだけではありませんが。） 私は、この「開発プロセス改善」において、開発経験や開発PM経験をかなり活用できております。 以下、「経験が役に立っているな！」と思う場面を「開発プロセス改善」の事例とあわせて２つご紹介させていただきます。 1.不具合の分析結果を用いて開発工程を改善するアプローチ 市場で発生した不具合、テスト工程で検出した不具合、レビューで検出した不具合(指摘事項)を分析して、混入した工程や原因となった問題を特定し、該当工程のプロセス定義（作業手順、ルール等）や成果物定義（標準文書テンプレート、記述ルール、サンプル等）などを改善するというアプローチです。 当然ながら手順やルール等を変えるためには、当事者である開発現場の皆さんとの合意形成が必要です。品質を向上するためには現状よりも重厚な手順（成果物の記述内容を増やす、レビューを必須にする、承認経路を増やすなど）を提案しなければならないことがよくあることなので、かなり開発現場の納得度の高い提案をしないと受け入れていただくことができません。 開発現場の納得度の高い提案をするためには、開発の知見があると有利であると実感しております。例えば、成果物にこういう記述項目を追加するとよいですよとか、そもそもフォーマットがないケースはフォーマットやサンプルを用意して使ってみませんかとか、自分の経験に基づいて相手が欲しい情報を提案しやすいです。 なによりも、開発担当者から「何故このようなことをやらなければいけないのか？」と問われた際は、自分が開発していた時の教訓等を思い出して例を挙げて説得することもできます。例えば、「なぜ要件ベースライン( ※3 )が必要なのか？」と問われた時、下流工程へ進む前にその時点の要件スコープを顧客と合意しておかないと、後工程で要件変更を受け入れざるを得ない状況に陥ってしまうことがある。また要件変更のために設計以降の工程で手戻りが発生してスケジュールを守れなくなったり、変更のタイミングによってはデグレード( ※4 )を発生させてしまったりすることがある、というようなことです。 あとは、開発経験があると開発担当者のツボにあわせた話がしやすいです。「この人開発者の気持ち分かってくれているなー」みたいな感じで反応が良くなったら改善を進めやすくなります。 困っている開発現場には、学術的な指導よりも今やるべきことを一緒に解決してくれるQAコンサルタントの方が喜ばれます。 2.世のベストプラクティスを用いて開発プロセスのギャップを改善するアプローチ もう１つ別の開発プロセス改善のアプローチ方法による経験をご紹介いたします。 タイトルの「世のベストプラクティス」とは、例えばCMMIのような一般的な理想論（モデル等）と実際のプロジェクトや組織のプロセスを比較して、理想通りでない部分（弱み）を洗い出し、そのギャップを改善していくというアプローチです。 参考： CMMI-DEV,V1.3日本語版 （上図は筆者が記載したもの） 正直初めてCMMIのような学術的な書物を読んだ時には解釈が難しくてドン引きしましたが、読み進めているうちに自分の開発経験や開発PM経験に当て込んで解釈すると、なるほどと思えることが増えました。結局やりたいことは開発プロジェクトのプロセスやプロダクトの品質を向上することであって、そのために理想とする方法論等が書いてあるだけなのだと気づき、「なんだ、意外と難しくないぞ！」と思えるようになりました。 私はQAコンサルタント職に就いてからは、世の有識者が難しい言葉でいろいろ書いてくれている書物などを理解して即時に技術を使いこなせるスキル向上は必要であるとは感じておりますが、すぐに全部暗記までしていなくてよいと確信しております。どこにどのような情報があるか自分の頭の中に知識と経験のインデックスを徐々に作って引き出せるようになっていければよいと悟りました。 ですので、QAコンサルタントとしてやっていけるくらいの知識を身につけるためには、自分自身の開発経験や開発PM経験と結び付けて世のベストプラクティスを学び・解釈すれば、そんなにハードルが高いことではありません。開発プロジェクトの経験がある方なら未知の世界のことは１つも無いというのが私の感想です。 QAエンジニアになってから心がけていること 以上、QAエンジニアには開発経験が役立つ例として、開発プロセス改善の主な2つのアプローチによる私のQAコンサルタント経験をご紹介させていただきました。 最後に開発プロセス改善に限らず、どのQAエンジニアの職務においても、私が最も重要だと考えていることをお話させていただきます。「開発現場に寄り添い、共感し、納得してもらう」ことです。 私は第三者的な立ち位置から開発プロセス改善を初めて実行した時は、正直プロジェクト外からアクションしていくのは難しい！と感じました。自分自身が開発プロジェクトに所属している時は、「みんなルールこうしようぜー」と言うだけで変えられたのに、第三者の立ち位置から提言する場合は、あれやこれやと言い訳されてやってもらえない、挙句の果てには「お前分かっているのか？」「お前に何が分かるのだ！」というような勢いで反感を買うこともあります。 このような経験から得た私の教訓は、「開発現場に寄り添うことが必須である」ということです。 開発現場に寄り添うために私がいつも心がけているのは「自分が同じ立場でこれをやれと言われたらどう思うか？」を常に考え、理想論だけを叩きつけないようにすることです。 弊社のようなQA会社にご依頼をいただく案件は、品質に問題を抱えていたり、品質を向上するために苦戦したりしているわけで、開発現場からすると「時間はないが、品質は担保しなければならない」等の難題に悩まされ、場合によっては猛烈疲弊した状態になっていることもあるわけです。このような開発現場の皆さんに対して、どれだけ役に立つ提案や支援ができるかがQAエンジニアのミッション達成のための肝だと考えます。 私が開発エンジニア兼PMだった時、プロジェクトをうまくまわせずに品質問題を起こしてしまったことがありましたし、そのために寝られない日々をたくさん過ごしたこともありますので、開発現場の痛みを理解するように心がけ、自分のような目にあわないようにするための最善策は何なのかを常に考えるようにしています。 時には強い意志を持って開発現場を動かすアクションが必要な場合もありますが、その時は自分の経験を例に出して提言すれば多くの方々が納得してくれます。まず自分が同じ立場ならどう思うか、どうするか、どうしたいかを真っ先に考えるようにしたら、最適解を導き出すスピードが早くなりました。 反対に、開発現場の声を聞きすぎると改善が進まない場合もあり得るので、どうしたものかと考えていた時期もありました。しかし、この開発現場に寄り添った改善活動の進め方を、社外で知り合った有識者より好評いただいたことがあり、その時から自信を持てるようになりました。 「開発現場に寄り添ってくれるQAエンジニア」と言われたら、嬉しいですよね。 まとめ ・QAエンジニアのお仕事は開発経験や開発PM経験を活用できる場面がたくさんある。 ・品質問題で困っている開発現場には寄り添って一緒に解決してくれるQAエンジニアが喜ばれる。 ・開発現場に寄り添えるQAエンジニアになるためには、第三者的な立ち位置であっても開発担当者と同等の当事者意識を持つとよい。 ・開発担当者と同等の当事者意識を持つためには、開発経験や開発PM経験があると非常に役に立つ。 以上、ご参考になりましたら幸いです。 開発現場に寄り添って、開発プロジェクトのプロセスを改善したり、品質向上を支援したりするお仕事を一緒にしてみませんか？ APPENDIX:用語の説明 (※1)CMMI 「CMMIとは、組織がプロセス改善を行う能力を評価する手法および指標。ソフトウェア開発プロセスの成熟度を測る「CMM」を元に複数の同種の手法を統合した汎用的な手法で、米カーネギーメロン大学CMMI研究所が開発、公表している。」 IT用語辞典 e-Words より引用 (※2)シフトレフト 「シフトレフトとは、製品開発などで行われる特定の工程を通常よりも前倒しして実施すること。IT分野ではソフトウェア開発におけるセキュリティ対策やテストなどで行われることが多い。」 IT用語辞典 e-Words より引用 (※3)要件ベースライン 「ベースラインとは、基線、基準線、基準値などの意味を持つ英単語。字義通り、図形などで何かの基準を表す線分を指す用法と、比喩的に、計画や標準、最低限度などを表す値やデータ、状態などを指す用法がある。」 IT用語辞典 e-Words より引用 「要件ベースライン」とはプロジェクトの要件をステークホルダー間で確認し、決まった内容や範囲(スコープ)を基準とすることである。またその基準をステークホルダー間で合意形成することを推奨する。要件ベースライン決定後の変更は変更管理をして、要件通りの品質を担保するためにはスケジュールやコストの見直し等をおこなう必要があることを説明するための根拠として使用する場合が多い。 (※4)デグレード 「デグレードとは、新しいバージョンのソフトウェアの品質が、以前より悪くなること。また、以前修正した不具合やバグが再発・復活すること。新しいファイルなどを古い内容で上書きしてしまい、更新内容が失われることを指す場合もある。」 IT用語辞典 e-Words より引用 The post 開発エンジニアからQAエンジニアに転身して悟ったこと first appeared on Sqripts .

はじめに 前回 は、テスト駆動開発（Test-driven development、以下TDD）とは何か、TDDの目的は何かについて話しました。今回は、振る舞い駆動開発（Behavior Driven Development、以下BDD）が考案された経緯と、specBDDとscenarioBDDという2種類のBDDの違いについて説明します。 BDDの誕生 BDDはDan Northによって考えられたものです。2006年に自身の記事「 Introducing BDD （邦訳： BDDの導入 – Dan North ）」でBDDという考えに至った経緯が述べられています。 Danの考えたBDDでは、TDDのルールから2つの変更を入れました。 ・クラス名やメソッド名から「test」という単語を取り除く ・テストメソッド名は「should」という単語で始める（日本語の場合、『〜〜すべき』という単語で終わる）ようにする これによって、より「振る舞い（特にユーザー視点での振る舞い）」に注目するようになりました。 Danによると、コードを変更してテストが失敗した時には、以下の3つに分類できます。 ・バグを埋め込んでしまった。悪い子だ。解決法：バグを直す ・意図されたふるまいは変わらず関連性があったが、どこか別の場所に移されていた。解決法：テストを移動し、場合によっては変更する。 ・ふるまいがもはや正しくない。システムの前提が変わってしまっている。解決法：テストを削除する。 BDDの導入 – Dan North から引用 このうち、3つ目の解決法「テストを削除する。」に対して、BDDは大きな効果をもたらします。 元々のTDDでは、「testメソッドを削除する」という行動になってしまい、「本当にテストを削除して良いの？大丈夫？」と不安になります。これは前回話した「TDDによって品質を保証している」という誤解によって、testメソッドそのものの削除に対して非常に億劫になってしまっているからです。 一方、BDDではその心理的ハードルを低くしています。「振る舞いが違うのであれば、『should』で始まっている振る舞いの定義を削除した方が良いよね」という考え方に持っていこうとしています。 Liz Keoghは 有識者との議論の中で 、「『テスト』という言葉を使用する際の問題は、誰もが自分が何をテストしているのかを知っていると想定していることです。」と語っています。逆を言うと、BDDは事実を知らないという前提に立ちやすいと言えます。 振る舞いに注目することのメリット BDDによってユーザー視点での振る舞いに注目すると良いことがもう一つあります。振る舞いに注目すると内部構造に注目せずに済む可能性が高くなります。これは、TDDではあまり得られない（得ることは可能だが、なかなか得ることに気付きにくい）効果でもあります。 例えば、自動販売機についてのプログラミングを考えた時、振る舞いに注目していない例として以下のようなテストコードを書くかもしれません。 import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.assertEquals; public class VendingMachineTest { @Test void _残高の引き算のテスト() { VendingMachine vendingMachine = new VendingMachine(); vendingMachine.setCredit(500); //500をセットする vendingMachine.minusFromCredit(100); //100を引く assertEquals(400, vendingMachine.getCredit()); //400になる } } これはTDDで書くことによって、プロダクトコードのロジックも作成できます。 ですが、果たしてこのコードは自動販売機を表すことができているのでしょうか？あまりにも内部構造に注目しすぎています。 一方で、ユーザー視点での振る舞いに注目すると以下のように書くことができます。今回は、Given/When/Thenの形で書くことにします。（Given/When/Thenの形をGherkin記法と呼びます。Gherkin記法については第6回の時に説明します） import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.assertEquals; public class VendingMachineBehave { @Test void _1000円札を投入後100円のコーラを購入するとコーラと900円のお釣りが出るべき() { //前提(Given) VendingMachine vendingMachine = new VendingMachine(); Coin coin = new Coin(1000); Goods drinkGoods = new Goods("Cola", 100); //動作(When) vendingMachine.insertCoin(coin); //お金を入れる vendingMachine.purchase(drinkGoods); //商品を購入する //結果(Then) assertEquals("Cola", vendingMachine.dispensingDrink()); //商品が出てくる assertEquals(900, vendingMachine.getChange()); //お釣りが出てくる } } これぞまさに、自動販売機での振る舞いであると感じることができるでしょう。 BDDを行う上で大切にすべきこと Liz Keoghは 先ほどと同じ有識者との議論の場で 、BDDを進めていく前提の考えを定義しました。 ・間違っていると仮定する ・どのように間違っているかを理解するために会話する ・十分なフィードバックを得られたら実装する つまり、振る舞いに注目し、認識が間違っているところがないか議論することこそがBDDで大切にしていることだと捉えたのです。 先ほどの、ユーザー視点での自動販売機の振る舞いに注目した例をもう一度見てみましょう。 import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.assertEquals; public class VendingMachineBehave { @Test void _1000円札を投入後100円のコーラを購入するとコーラと900円のお釣りが出るべき() { //前提(Given) VendingMachine vendingMachine = new VendingMachine(); Coin coin = new Coin(1000); Goods drinkGoods = new Goods("Cola", 100); //動作(When) vendingMachine.insertCoin(coin); //お金を入れる vendingMachine.purchase(drinkGoods); //商品を購入する //結果(Then) assertEquals("Cola", vendingMachine.dispensingDrink()); //商品が出てくる assertEquals(900, vendingMachine.getChange()); //お釣りが出てくる } } これを書くことで、色々な疑問が出てくるはずです。例えば以下のような疑問が出てくるかもしれません。 ・1000円札の投入は本当に可能なのか？ ・新1000円札と旧1000円札の両方で投入が可能なのか？ ・購入した場合、必ずお釣りが出てくるのか？（お釣りが出てこないで別の飲み物が買えたりしないのか） ・900円のお釣りとは、500円硬貨1枚＋100円硬貨4枚なのか、それとも100円硬貨9枚なのか？ このように、BDDでは振る舞いについて具体的に考えることで、色々な疑問を発見することを大切にしています。 specBDDとscenarioBDD 自動販売機の振る舞いに注目していない例（内部構造に寄りすぎた例）ですが、Danの作った2つのルール「クラス名やメソッド名から『test』という単語を取り除く」「テストメソッド名は『should』という単語で始める（日本語の場合、『〜〜すべき』という単語で終わる）ようにする」を適用してBDDっぽく書くことができます。 import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.assertEquals; public class VendingMachineBehave { @Test void _500円から100円を引くと400円になるべき() { //前提(Given) VendingMachine vendingMachine = new VendingMachine(); //動作(When) vendingMachine.setCredit(500); vendingMachine.minusFromCredit(100); //結果(Then) assertEquals(400, vendingMachine.getCredit()); } } このように、内部構造に寄っており実装レベルの仕様を表現しているBDDを、 Behat の作者である Konstantin KudryashovはspecBDDと名付けました。 一方、お釣りについて記述していた例のように、ユーザー視点の振る舞いに注目して表現したBDDを、 Konstantin KudryashovはscenarioBDDと名付けました。 scenarioBDDの別の言い方としてstoryBDDと呼ぶこともあります。 scenarioBDDに対応したフレームワークを用いて、ビジネス関係者にもより分かりやすい記述をする scenarioBDDはユーザー視点の振る舞いを示そうとしているため、ビジネス関係者にも理解してもらいたいという意図があります（詳しくは第4回でお話しします）。 しかし、Javaなどのプログラミング言語を用いてGiven/When/Thenの形で書くだけだと、プログラミング言語特有の記述（例えばクラスの生成記述など）が気になってしまい、ビジネス関係者には理解してもらいづらいです。 そこで、よりビジネス関係者にも理解してもらいやすくするために、シナリオ部分と実装部分を分けて記述するフレームワークが出てきました。その代表的なフレームワークとしてCucumberがあります。 先ほどまで書いていたユーザー視点での自動販売機の振る舞いのシナリオ部分を、Cucumberを用いて書くと以下のようになります。 Feature: 自動販売機 Scenario: 飲み物を買うとお釣りが出る Given 自動販売機がある When 1000 円札を入れる And 100 円の "コーラ" を選ぶ Then "コーラ" が出てくる And 900 円のお釣りが出る この記述ならば、プログラミング言語に馴染みのないビジネス関係者にも理解してもらいやすくなります。 次回予告 今回はBDDの誕生とspecBDD/scenarioBDDの違いについて説明しました。 ただし、今回説明したscenarioBDDは本来考えるべきことのほんの一部に過ぎません。 実際にscenarioBDDで考えるべき具体的なプロセスおよび例については第4回以降に説明します。 次回は、BDDと振る舞い駆動開発(ATDD)/実例による仕様(Specification by Example)との関係性について話していきます。 連載一覧 TDDとBDD/ATDD(1)　TDDはテスト手法ではない The post TDDとBDD/ATDD(2)　2種類のBDD first appeared on Sqripts .

こんにちは。QAエンジニアのTWです。 普段はソフトウェアのシステムテストを行っています。脆弱性診断について業務で触れる機会があり、脆弱性診断に興味を持ちました。この記事では自分で勉強した内容を共有したいと思います。簡単な内容ですが参考になればと思います。 ※本記事の内容は以下の書籍を参考にしています Webセキュリティ担当者のための脆弱性診断スタートガイド (第2版) 脆弱性診断とは 脆弱性とはプログラムの中に作りこまれたバグのなかでデータを書き換えたり、盗み取られることによって悪用されてしまうバグを指します。 これらの脆弱性を発見するためのテスト手法が脆弱性診断となります。代表的な脆弱性としてSQLインジェクション、クロスサイトスクリプティング(XSS)があります。 SQLインジェクションは悪用されるコードを含んだSQL文が実行されることによってデータベースを不正に操作される脆弱性です。この場合、アプリケーションに実装されたSQLの呼び出し方に不備があることが脆弱性であり、データベースを不正に操作されることで機密情報の漏洩やデータを改ざんされる恐れがあります。 クロスサイトスクリプティング(XSS)はWebサイトに設置されたユーザー入力フォームに攻撃用scriptが埋め込まれたままWebページが出力され、そのページを善意のユーザーが閲覧することで偽のページを閲覧させられたり、cookieの情報を取得されたりする脆弱性です。 脆弱性診断はOSやミドルウェアに対して行う 「プラットフォーム脆弱性診断」とWebアプリケーションに対して行う 「Webアプリケーション脆弱性診断」 がありますが 、今回は「Webアプリケーション脆弱性診断」を実行します。 OWASP ZAPとは OWASP( The Open Web Application Security Project ) という国際的な団体によって作成されたセキュリティ診断ツール(プロキシツール)です。 無料で使用でき、 Webアプリケーション脆弱性診断が可能です。 Badstoreとは わざと脆弱性を持たせたWebアプリケーション(ショッピングサイト)で脆弱性診断のトレーニングを行うことができます。 通称「やられWebアプリケーション」と呼ばれます。Badstore以外にも 「やられWebアプリケーション」は存在します。 OWASP ZAPのインストールとセットアップ OWASP ZAPのインストールとセットアップについて説明します。 1.OWASP ZAPの ダウンロードページ から使用する環境に対応したインストーラーをダウンロードします。(今回はWindows 64bit版をインストールしました) 2.インストーラーを起動し、インストールウィザードを進めてインストールを完了させます。 3.OWASP ZAPを起動します。 以下のダイアログが表示されたら「開始」ボタンを押下します。 4.「ツール」メニューから「オプション」を選択後、「Network」-「Server Certificateｓ」を選択。 ルート証明書が選択されていることを確認し、「保存」ボタンから証明書をエクスポートします。これは次項で説明するブラウザのセットアップで使用します。 ブラウザのセットアップ 今回脆弱性診断で使用するブラウザですが、EdgeやChromeはセキュリティ機能が診断に影響を与えることがあるためFirefoxを使用します。 1.ブラウザを起動後、「設定」メニュー -「一般」 – 「ネットワーク設定」 – 「接続設定」ボタンから以下画面の通りにプロキシ設定を行い、OKボタンで保存します。 2.「設定」メニュー – 「プライバシーとセキュリティ」 – 「証明書」 – 「証明書を表示」ボタンから先ほどOWASP ZAPでエクスポートした証明書をインポートします。インポート時「この認証局によるウェブサイトの識別を信頼する」にチェックをいれます。 Badstoreのインストールとセットアップ Badstoreの正規のサイトでは配布が終了しており、はじめに紹介した参考書籍にて二次配布のリンクが共有されています。 Badstoreはisoイメージとなっており、今回は仮想環境にインストールして使用します。今回は仮想環境としてVMware Workstation Playerを使用します。 1.VMware Workstation Playerを VMware Workstation Player のダウンロード からダウンロードします。 2.インストーラーを起動し、インストールウィザードを進めてインストールを完了させます。 3.VMware Workstation Playerを起動し、「新規仮想マシンの作成」を選択します 4.「インストーラディスクイメージファイル」にダウンロードしたBadStoreのisoイメージを選択し、仮想マシンの作成を完了します。 5.仮想マシンを作成後、「仮想マシンの再生」から仮想マシンを起動します。 6.仮想マシンが起動したら「ifconfig」コマンドでBadstoreのipアドレスを調べます。 7.BadStoreのFQDNである「 www.badstore.net 」とIPアドレスを紐づけるためにhostsファイル（C:¥Windows¥System32¥drivers¥etc¥hosts）を以下のように編集します。 192.168.222.128 www.badstore.net 8.Firefoxで BadStoreのURL にアクセスし、サイトが表示されればセットアップ完了です。 脆弱性診断の実行 まず自動スキャン機能として静的スキャンを実行してみます。 静的スキャンは攻撃用リクエストを送ることなくクロールのリクエスト/レスポンスだけで診断します。 診断対象のWebサイトはいくつかのWebページやリクエスト内容を持っており、診断対象のページが明確ではないですが、診断対象のページを自動的にクロールして、記録してくれるスパイダーという機能があります。 こちらの機能を実行することで自動的にクロールで発見されたページに対して静的スキャンを実行してくれます。自動で遷移できないページに対しては手動で記録する必要があります。 1.標準モードになっていることを確認し、OWASP ZAPのサイト欄からBadStoreを選択し、「攻撃」-「スパイダー」を選択します。 2.「スキャンを開始」ボタンで実行します。 コンテキストを登録していると診断対象としたくないページを設定することができますが今回は説明を省略します。 3.診断対象が自動的に記録され、静的スキャンが実行されます。 下部のMessagesタブを選択後、診断対象のURLを右クリック-「このノードのアラート」を選択すると各URLに対しての検出アラートを確認することができます。 次に、手動スキャンを実行してみます。 手動スキャンを実行するにあたっては最低限必要な診断項目や手順を定義することで、一定レベルの手動診断による脆弱性診断を行うことができる「Webアプリケーション脆弱性診断ガイドライン」を参考にして手動スキャンを実行します。 「Webアプリケーション脆弱性診断ガイドライン」は こちら のサイトから入手できます。 クロスサイトスクリプティング（XSS）が存在するか確認する 今回は前述の代表的な脆弱性であるクロスサイトスクリプティング(XSS)が存在するかどうか確認してみます。 「Webアプリケーション脆弱性診断ガイドライン」のNo.19である検出パターン「<script>alert(1)</script>」を挿入してリクエストを送信します。 まずFirefoxでBadstoreに接続し、商品検索のテキスト入力欄に「1000」を入力し、商品検索します。 2.商品検索時のURLを確認し、OWASP ZAPの履歴から同じURLを探します 3.対象の履歴を選択後、右クリックメニューの「再送信」を選択します。 4.リクエストの「searchquery=1000」部分を以下に書き換えます searchquery=1000<script>alert(1)</script> 5.レスポンスタブを選択し、「送信」ボタンを押下します。 その後レスポンスのBodyからHTMLのBODY部分を確認すると挿入した検出パターン文字列がそのまま表示されていることが分かりました。 埋め込んだ脆弱性が実行されるか確認してみる 今度は実際にブラウザのURLから直接編集したURLを入力してスクリプトが実行されるか確認してみます。 先ほどと同じようにOWASP ZAPの履歴からURLを書き換えて送信したURLをコピーし、ブラウザで接続します。するとスクリプト(<script>alert(1)</script>)が実行され、ダイアログが表示されました。 ちなみに脆弱性の対策としては、以下のように適切にエスケープ文字に置き換えることによってスクリプトの実行を防ぐことができます。 対策⇒「<」と「>」をエスケープ文字に置き換え 　実行前：<script>alert(1)</script> 　実行後：<script> alert(1) </script> まとめ 自身の勉強として脆弱性診断を行ってみましたが、以下理由によりそこそこハードルが高いと感じました。 ・HTML等のWebの知識が必要 　・検出される脆弱性の種類は様々で、脆弱性の内容や対策方法を理解するのが大変 　・自動スキャンで全ての脆弱性を検出することはできず、Webサイトに応じた手動スキャンのスキルが必要 ですが、紹介したトレーニングサイトや脆弱性診断ツールが無償で公開されているため、勉強する環境は整っています。また、ハードルが低くないが故に奥が深く、やりがいのある分野だと思います。 機会を作って、プラットフォーム脆弱性診断についても勉強してみようと思っています。 さいごに さいごに注意事項ですが、脆弱性診断は他人、他社のWebサイトやWebアプリケーションに対して実行してはいけません。 脆弱性診断はWebアプリケーションに対して攻撃を行うことで脆弱性を発見する性質もあり、法的措置を取られる可能性があります。 トレーニングはBadStoreのようなやられWebアプリケーションに対して行うようにしましょう。 さいごまで読んでいただき、ありがとうございました！ The post OWASP ZAP VS. Badstore！脆弱性診断について勉強してみた！！ first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第6回目のテーマは、世界で大人気のフレームワーク「スクラム」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 シンプルなフレームワーク「スクラム」 現在、もっとも有名な開発手法であるスクラムを解説します。スクラムは日本人の書いた論文をヒントに作られたフレームワークです。アメリカで体系化され、世界に広がり、日本に戻ってきました。 スクラムはとてもシンプルなフレームワークです。よって、改善を行うときは「シンプルかどうか」を忘れずにチェックすると良いと思います。そうしなければ、せっかくの軽量級フレームワークも、いつのまにか重量級フレームワークになってしまい、アジリティ（俊敏さ）が失われてしまうでしょう。 スクラムはスクラムガイドというガイドラインが公開されています。アジャイル開発らしく分厚いドキュメントではありません。 2020年11月現在のガイド だとわずか18ページです。スクラムはシンプルであることが有名ですが、ガイドもシンプルになっています。 逆に言うと、細かい解説のない書き方になっているとも言えるので、読み解くのが難しい人もいるでしょう。たとえば、スクラムを解説する本は、どれも18ページ以上の本ばかりなのが、シンプルさが生み出す難しさを表しています。 スクラムはシンプルですが、いくつもの分厚いスクラムの解説本が発売されているように、シンプルすぎてわかりにくい、解釈に困る、習得が難しい部分があります。この記事ではできるだけそうならないようにガイドできればと思っています。 ただ、スクラムやスクラムガイドがシンプルなのは、自分たちで考えてプラクティスを選ばせるためでもあることを覚えておくと良いでしょう。 スクラムガイドは、スクラムを理解するのにとてもいいドキュメントです。ただ、「スクラムガイドに書いてあるから」や「スクラムガイドに書いていないから」と解説する人がたまにいますが、書いてあるかどうかが重要ではありません。盲目的にガイドを受け入れすぎないように注意したほうがいいでしょう。 スクラムガイドは、時代に応じてどんどん更新されるドキュメントです。このセクションでは、2020年11月バージョンのスクラムガイドをもとに解説を行っていきます。 スクラムの三本柱 透明性、検査、適応はスクラムの三本柱と呼ばれています。 透明性： プロセスや作業、成果物を見えるようにしましょうということです。透明性なくして次の検査は実現できません。 検査： 見えるようになったものを頻繁かつ熱心に検査します。検査によって、次の適用が実現できます。 適応： いわゆる調整です。検査して理想と現実にギャップがあれば、調整して本来あるべき方向に調整していきます。 これらは後述するスクラムイベントの基盤になっています。 スクラムイベント スクラムイベントとは、スクラムのサイクルの中で発生するMTGを指しています。スクラムでは以下のようなイベントを行います。 スプリントプランニング： 短い期間内の計画を立てるイベント デイリースクラム： いわゆる朝礼 スプリントレビュー： 作ったものを検査するイベント。いわゆる成果発表 スプリントレトロスペクティブ： 自分たちを検査するイベント。いわゆるふりかえり スクラムの概要図 スクラムの流れを見ながら、スクラムイベントがどういった役割を持っているか見ていきましょう上記の図は、マウンテンゴート社が公開しているスクラムの全体図です。日本語訳が公開されていたのでこの図を使ってスクラムを使った仕事の流れを見ていきます。マウンテンゴート社は、『アジャイルな見積もりと計画づくり』の著者でも有名なマイクコーンさんのいる会社です。 まず、開発をはじめる前に、プロダクトバックログを作ります。プロダクトバックログは、いわゆる「やりたいことリスト」です。スクラムチームはプロダクトバックログを優先度順で開発し、リリースしていきます。開発やリリースが進むとプロダクトバックログが減っていくので、プロダクトバックログに責任を持つプロダクトオーナーは、プロダクトバックログを定期的にメンテナンス（増やしたり減らしたり磨いたり）していきます。 次に、 スプリントプランニング で計画を立てます。スクラムはスプリントという短い開発期間を繰り返していきます。このスプリントに合わせた開発計画がスプリントバックログです。すでにやりたいことリストはプロダクトバックログとしてあるので、そこからスプリントでやれる量を選び、スプリントバックログを作成します。 やりたいことリスト（プロダクトバックログ）ができて、スプリントでやることリスト（スプリントバックログ）ができたので、いよいよスプリントを開始します。スプリントは通常2週間から4週間のサイクルです。図の中央にある大きな円を描く緑色の矢印がスプリントをさしています。 スプリントの中にもうひとつ小さい矢印があります。これが デイリースクラムミーティング のサイクルです。デイリースクラムはいわゆる朝礼のようなもので、日々の計画の確認や調整を行う場です。 スプリントで開発を進め、最終的にスプリントのおわりに、プロダクトをリリースします。図にはありませんが、リリース前 にスプリントレビュー で成果物を検査し、 スプリントレトロスペクティブ によってスプリントでの開発を検査します。 これがスクラムの流れです。 スクラムはスクラムチームでこの流れを繰り返していきます。みてのとおり、とてもシンプルな流れです。おそらく、部分的に自然にやっているチームも多いでしょう。 スクラムチーム スクラムを行うチームをスクラムチームと呼びます。スクラムチームには、プロダクトオーナー（PO）、開発者、スクラムマスター（SM)がいます。 POは「プロダクトゴール」を決め、「やること」や「やる順番」を定義します。POだけでやることをきめられないのであれば、開発者などに相談しても問題ありません。あくまで、最終的な決定責任がPOにあるというだけです。従来型だと「要件に落とし込む人」に近い存在です。 組織が大きくなると、POがあつまるプロダクトオーナチームを作る場合もあります。 現在の人材市場を見ていると、POを仕事とする人が少ないので、一人のPOが複数チームをみるケースも多く見られます。 次に登場するのは、開発者です。開発者は開発を行います。スクラムガイドでは、フロントエンドエンジニア、バックエンドエンジニア・・・といったふうにこまかく分類されておらず、「開発者」とだけ定義されています。従来型だと「仕様を作り開発・テストする人」に近い存在です。 実際のスクラムチームは、チームだけで開発を完了させられる力が求められます。みなさんの現場で、フロントエンドとバックエンドが1名ずつ必要であれば、スクラムチームにはその2名を参加させる必要があります。 最後はスクラムマスターです。スクラムマスターはスクラムの理論やプラクティスを全員に理解してもらえるよう支援します。従来型だとプロジェクトマネージャーが近い存在です。 今回はスクラムの概要を解説しました。次回は、スクラムチームの責任に焦点を絞って解説を行います。 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ The post 第6回 世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 first appeared on Sqripts .

こんにちは。GSです。 今の時代、開発から運用までLinuxを必要とするケースはとても多いです。 WindowsユーザーがLinux環境が必要な開発を行うとき、WSL2を使うことで手軽に環境を作り利用することができます。 「Windowsは使えるが、Linuxはよくわからない」といった人が、できるだけ手間なく・手が止まることなく使える状態にし、実際に開発や検証に入れるような環境をささっと作り上げる手順をご紹介したいと思います。 ゴール Windows上からGUIを操作することなく、コマンドのコピペで環境を作り上げる 開発に困らないであろう最低限レベルに達するために必要なものをすぐ使えるように 開発や検証行為をLinuxに寄せすぎないようにし、Windowsのツールを十分に活用する WSL2とは？ そもそもWSL2は何なんのでしょうか？ WSL2とは、Windows Subsystem for Linux 2の略称で、Windows上でLinux環境を動かすための機能です。Windows 10 / 11の最新バージョンであれば、デフォルトでWSL2を使用することができます。 「Windows上でLinux環境を動かす」いうだけでなく、Windowsの一部としてのLinux、Linuxの一部としてのWindowsと言わんばかりに非常にシームレスな統合が行われるといったような特徴があります。 このシームレスな統合のお陰で、LinuxからWindows上のアプリをLinuxファイルシステムの上で起動したり、Windows GUIからLinuxへファイルを作成したりといったことも容易にできます。 検証環境（余談） 今回この記事を書くにあたり、 Windows 仮想マシンをダウンロードする – Windows アプリ開発 | Microsoft Developer にあるイメージを使用してWSL2環境構築を行っていきました。 提供されている開発用イメージは、その名の通り開発に必要なソフトウェア（WSL2も含まれる）がある程度セットアップされています。 ですので、それらを一度削除し、限りなくまっさらなWindows環境に戻し検証を行っています。 開発用マシンは英語環境のWindowsとなっています。日本語でセットアップを行いたい方は別途日本語化対応を行ってください。日本語化設定方法については「おまけ」セクションを参照してください。 また、今回の検証はHyper-V用イメージで行っており、Hyper-V内でWSL2を動かすためにホスト側で追加の設定を行っています。 Hyper-V用仮想マシンを、Winという名前に設定し PowerShellを管理者として実行 した上で Set-VMProcessor -VMName "Win" -ExposeVirtualizationExtensions $true というコマンドを実行しています。このコマンドを実行することで、Hyper-V上で仮想マシンやWSL2を実行できるようになります。 Hyper-Vは DISM.exe /Online /Enable-Feature /All /FeatureName:Microsoft-Hyper-V というコマンドを管理者として実行することでインストール可能です。 動作環境確認 CPU 仮想化支援機能がついているCPUが必要です。10年ほど前のPCでも付いている機能なので、それほど問題視する必要はありませんが、動作しない場合はお使いのコンピューターに搭載されているCPUのスペックを確認してください。 Windows バージョン ファイル名を指定して実行（Windows キー + R）より、「winver」を入力することで確認可能。 Windows 10 x64 システムの場合:  バージョン 1903  以降 ( ビルド 18362.1049  以降)。 ARM64 システムの場合:  バージョン 2004  以降 ( ビルド 19041  以降)。 Windows 11 特になし Windows 10で規定バージョンに満たない場合、Windowsそのものを更新する必要があります。 Windows Package Manager（WinGet） 「Windows Package Manager」は、「Windows 10 バージョン 1809」以降および「Windows 11」で利用可能なコマンドラインツールで、アプリケーションのインストール・アップデート・アンインストールを実行できるパッケージ管理システムです。 Linuxでいえば、「apt」や「yum」。Macで言えば「brew」などに相当します。 Windowsといえば、インストールしたいアプリケーションが提供されているホームページへアクセスしダウンロード→解凍→インストールという流れでアプリケーションをインストールすることが多いと思いますが、wingetコマンドであれば、ほしいアプリケーションをコマンド1行で打つだけで即座に導入できるようになります。 wingetのようなコマンドとして Scoop や Chocolatey Software | Chocolatey – The package manager for Windows があります。Scoopは開発者向けのアプリケーション（コマンド）が多く、Chocolateyは一般的なアプリケーションが多いです。 ファイル名を指定して実行（Windows キー + R）より、「cmd」を入力しコマンドプロンプトを開き、 winget --version を入力します。 C:\users\User>winget --version v1.4.11071 コマンドがインストールされ使える状況であれば、上記のようなメッセージが表示されます。 コマンドが見つからずにエラーとなったり、表示されるバージョンが古く更新したい場合などは、 アプリ インストーラー (microsoft.com) よりインストールまたは更新することで、最新バージョンが利用可能になります。 続けてアプリケーションを実際に検索し、インストールしてみます。 Windows Terminalをインストール winget search "windows terminal" と入力してみましょう。 C:\Users\User>winget search "windows terminal" 名前 ID バージョン ソース -------------------------------------------------------------------------------- 'msstore' ソースでは、使用する前に次の契約を表示する必要があります。 Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction ソースが正常に機能するには、現在のマシンの 2 文字の地理的リージョンをバックエンド サービスに送信する必要があります (例: "US")。 すべてのソース契約条件に同意しますか? [Y] はい [N] いいえ: y 名前 ID バージョン ソース ------------------------------------------------------------------------------- Windows Terminal 9N0DX20HK701 Unknown msstore Windows Terminal Preview 9N8G5RFZ9XK3 Unknown msstore Windows Terminal Microsoft.WindowsTerminal 1.16.10261.0 winget Windows Terminal Preview Microsoft.WindowsTerminal.Preview 1.17.10234.0 winget wingetコマンドでアプリケーション検索を初めて行う場合、「ソース契約条件に同意しますか？」というメッセージが表示されるので、Yを入力し同意します。 今回は4つ候補表示されました。ソースが msstore となっているものが、ストアアプリからインストール可能なパッケージとなります。 今回はこのストアアプリからも入れられるパッケージをwingetコマンドで入れてみます。 searchコマンドで表示されたIDをwingetコマンドの引数として指定することでダウンロードおよびインストールします（パッケージ名でもダウンロードすることは可能です）。 C:\Users\User>winget install -e --id 9N0DX20HK701 見つかりました Windows Terminal [9N0DX20HK701] バージョン Unknown このパッケージは Microsoft Store から提供されています。winget は、現在のユーザーに代わって Microsoft Store からパッケー ジを取得する必要がある場合があります。 契約の対象 Windows Terminal [9N0DX20HK701] バージョン Unknown バージョン: Unknown 公開元: Microsoft Corporation 発行元 URL: https://github.com/microsoft/terminal 発行元のサポート URL: https://github.com/microsoft/terminal/issues/new 説明: The Windows Terminal is a modern, fast, efficient, powerful, and productive terminal application for users of command-line tools and shells like Command Prompt, PowerShell, and WSL. Its main features include multiple tabs, panes, Unicode and UTF-8 character support, a GPU accelerated text rendering engine, and custom themes, styles, and configurations. This is an open source project and we welcome community participation. To participate please visit https://github.com/microsoft/terminal ライセンス: ms-windows-store://pdp/?ProductId=9N0DX20HK701 プライバシー URL: go.microsoft.com/fwlink/?LinkID=521839 著作権: Copyright (c) Microsoft Corporation 契約: Category: Developer tools Pricing: Free Free Trial: No Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction Seizure Warning: https://aka.ms/microsoft-store-seizure-warning Store License Terms: https://aka.ms/microsoft-store-license 発行元は、お客様がインストール前に上記の情報を表示し、契約に同意することを必要としています。 使用条件に同意しますか? [Y] はい [N] いいえ: Y パッケージ取得の確認/要求... パッケージ取得の成功の確認/要求 パッケージのインストールを開始しています... ██████████████████████████████ 100% インストールが完了しました インストールされ、使える状況になっているのが確認できます。 無論ストアからもインストール可能です。 https://www.microsoft.com/store/productId/9N0DX20HK701 URLを見るとわかりますが、wingetで指定したIDがURLに含まれています。 wingetコマンドを使用してのアプリケーション削除は、 winget uninstall -e --id 9N0DX20HK701 のように、installをuninstallに置き換えるだけで行えます。 以降の作業は、コマンドプロンプトではなく Windows Terminalで行っていきます 。 Visual Studio Codeをインストール Windows Terminalを起動し、 winget search -s msstore "Visual Studio Code" と入力します。 PS C:\Users\User> winget search -s msstore "Visual Studio Code" 名前 ID バージョン ------------------------------------------------------- Visual Studio Code XP9KHM4BK9FZ7Q Unknown Visual Studio Code - Insiders XP8LFCZM790F6B Unknown 今回は -s msstore オプションを付け、ストアアプリからインストール可能なアプリケーションのみを検索対象としています。 続けてインストールを行います。 winget install -e --id XP9KHM4BK9FZ7Q と入力。 PS C:\Users\User> winget install -e --id XP9KHM4BK9FZ7Q 見つかりました Visual Studio Code [XP9KHM4BK9FZ7Q] バージョン Unknown このアプリケーションは所有者からライセンス供与されます。 Microsoft はサードパーティのパッケージに対して責任を負わず、ライセンスも付与しません。 契約の対象 Visual Studio Code [XP9KHM4BK9FZ7Q] バージョン Unknown バージョン: Unknown 公開元: Microsoft Corporation 発行元 URL: https://code.visualstudio.com/ 説明: Visual Studio Code is a free, lightweight, and extensible code editor for building web, desktop, and mobile applications, using any programming language and framework. Visual Studio Code has built-in support for Git source control management and powerful integrations with GitHub, an integrated debugger, and smart code completion with IntelliSense and with AI-driven IntelliCode. With over 30,000 extensions and themes in the Visual Studio Code Marketplace, you can customize the features and the look of Visual Studio Code to fit your needs, preferences, and style. You can use Visual Studio Code to build any kind of app, for web, desktop, and mobile. Visual Studio Code supports JavaScript and TypeScript natively and offers extensions for coding in languages such as Python, Java, C/C++, C#, Go, Rust, PHP, and many more. ライセンス: https://code.visualstudio.com/License/ プライバシー URL: https://privacy.microsoft.com/en-US/privacystatement 著作権: ms-windows-store://pdp/?ProductId=XP9KHM4BK9FZ7Q タグ: programming coding code vscode vs editor 契約: Category: Developer tools Pricing: Free Free Trial: No Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction Seizure Warning: https://aka.ms/microsoft-store-seizure-warning Store License Terms: https://aka.ms/microsoft-store-license 発行元は、お客様がインストール前に上記の情報を表示し、契約に同意することを必要としています。 使用条件に同意しますか? [Y] はい [N] いいえ: Y ダウンロード中 https://sparkcdneus2.azureedge.net/cachedpackages/973b41be-5827-46f6-ab6d-637c2942eb33_9490453f2d73eb32f365c631bbad3b9d4837af27ce31ad6cb3dad56c50b0a5fa ██████████████████████████████ 6.34 MB / 6.34 MB インストーラーハッシュが正常に検証されました パッケージのインストールを開始しています... インストールが完了しました Visual Studio Codeがインストールされていることが確認できます。 ついでにVisual Studio Code拡張機能も入れてみましょう。 code --install-extension ms-vscode-remote.vscode-remote-extensionpack このコマンドを実行することで、「 Remote Development – Visual Studio Marketplace 」がインストールされます。 この拡張機能を入れておくことで、さまざまな環境に対して接続し、開発や検証作業を行うことが可能になります。 PS C:\Users\User> code --install-extension ms-vscode-remote.vscode-remote-extensionpack WSL2をインストールする Windows 10 バージョン 2004 以上 (ビルド 19041 以上) または Windows 11 を実行している方は、Windows Terminalを 管理者 モードで開き（PowerShellが管理者モードで起動します）、 wsl --install コマンドを入力します。 Windows上からPowerShellやコマンドプロンプトなどを管理者として実行する場合、右クリックから「管理者として実行」を選ぶ方は多いと思いますが、CTRL+SHIFTキーを押しながら起動（マウスクリックやエンターキー）することでも管理者として起動できます。ファイル名を指定して実行（Windows キー + R）で入力したコマンドも、CTRL+SHIFTで実行すれば、管理者モードで開くことが可能です。 コマンドを実行すると、許可ダイアログがあがってくるので、「はい」を選択します。 PS C:\Users\User> wsl --install インストール中: Linux 用 Windows サブシステム Linux 用 Windows サブシステム はインストールされました。 インストール中: Ubuntu Ubuntu はインストールされました。 要求された操作は正常に終了しました。変更を有効にするには、システムを再起動する必要があります。 メッセージの内容から、WSLのセットアップが完了し、Ubuntuがインストールされたことがわかります。 表示されているメッセージの通り、再起動を行いましょう。 wsl —list —online コマンドで、WSL環境へインストール可能なディストリービューション一覧を見ることができます。たとえばDebianをインストールしたいという場合、 wsl --install -d Debian コマンドで可能です。 再起動後、Windows Terminalが自動的に起動し、Ubuntuのインストール処理が進行します。 その過程でUbuntuで利用するユーザーとそのパスワードを設定する必要があります。 今回はユーザー名「ubuntu」、パスワード「ubuntu」で設定しました。 Ubuntu を起動しています... Installing, this may take a few minutes... Please create a default UNIX user account. The username does not need to match your Windows username. For more information visit: https://aka.ms/wslusers Enter new UNIX username: ubuntu New password: Retype new password: passwd: password updated successfully この操作を正しく終了しました。 Installation successful! To run a command as administrator (user "root"), use "sudo <command>". See "man sudo_root" for details. Welcome to Ubuntu 22.04.2 LTS (GNU/Linux 5.15.90.1-microsoft-standard-WSL2 x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage This message is shown once a day. To disable it please create the /home/ubuntu/.hushlogin file. ubuntu@WinDev2306Eval:~$ 以上でWSL2を有効にし、Ubuntuのインストールは完了です。 WSL2をコマンドでインストール出来ない場合 多少古いバージョンのWindows 10だと、 wsl -—install コマンドではインストールできません。 そのため、別途個別に必要なソフトウェアをインストールしていく必要があります。 Linux 用 Windows サブシステムと仮想マシンの機能を有効にする Windows Terminalを管理者として実行 し、以下のコマンドを実行しましょう。 dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart 実行後、再起動します。 Linux カーネル更新プログラム パッケージをダウンロードし、インストールする 再度、 Windows Terminalを管理者として実行。 wget https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi -OutFile wsl_update_x64.msi msiexec /i wsl_update_x64.msi /passive del wsl_update_x64.msi の順番にコマンドを実行し、Linuxカーネルを更新します。 PS C:\Users\User> wget https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi -OutFile wsl_update_x64.msi PS C:\Users\User> msiexec /i wsl_update_x64.msi /passive PS C:\Users\User> del wsl_update_x64.msi WSL 2 を既定のバージョンとして設定する wsl --set-default-version 2 を実行します。 PS C:\Users\User> wsl --set-default-version 2 WSLを更新する wsl —update にて更新します PS C:\Users\User> wsl --update WSL2へUbuntuをインストール PS C:\Users\User> wsl --install -d Ubuntu 以上で、手動によるWSL2とUbuntuのインストールは完了です。 Ubuntuセットアップ まずは、Ubuntuを起動してみましょう。 Windows Terminalを実行します。 画面上部の「 ∨ 」を選択すると、Ubuntuが候補として表示されていることが確認できます。こちらを選択し、Ubuntuを起動しましょう。 systemdを有効化する 今後Ubuntuへインストール及び設定していくアプリケーションのために、systemdを有効にしておきます。 以下のコマンドを 4行分一気に貼り付け 実行します。 cat <<EOF | sudo tee /etc/wsl.conf [boot] systemd=true EOF 以下が実際にインストールしてみた例です。 途中でubuntuユーザーのパスワードを聞かれますので、事前に設定したパスワードである「ubuntu」を入力しました。 ubuntu@WinDev2306Eval:~$ cat <<EOF | sudo tee /etc/wsl.conf [boot] systemd=true EOF [sudo] password for ubuntu: [boot] systemd=true コマンドを実行したら、PowerShellからwslをシャットダウンします。 PS C:\Users\User> wsl --shutdown 再度、Ubuntuを起動すると、systemdが有効になっています。 sshを有効にする まずはopenssh-serverをインストールしましょう。 sudo apt install -y openssh-server その上で、sshを有効にします。 sudo systemctl enable ssh sudo service ssh restart 以上で、sshを使うための最小限の設定は終わりですが、sshに鍵でアクセスしたい場合や、パスワードログインを無効にしたいといった場合、設定を変更する必要があります。 今回は後続で説明するTailscaleのために、初期設定のまま話を進めていきます。 docker dockerとは？ dockerは、コンテナ技術を利用してアプリケーションをパッケージング・配布するためのプラットフォームです。 誤解を恐れずに言えば、ワンコマンドで色々なアプリケーション（Webサーバーとかデータベースサーバーとか）を立ち上げてくれるすごいヤツでしょうか。 インストール 以下のコマンドを実行し、dockerが必要としているパッケージをインストールします。 sudo apt-get update -y && sudo apt-get install ca-certificates curl gnupg -y dockerインストールに必要なGPG情報をセットアップします。 sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod a+r /etc/apt/keyrings/docker.gpg docker関係のリポジトリを追加します。 echo \ "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null dockerをインストールします。 sudo apt-get update -y && sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin 今現在ログインしているユーザーをdockerグループへ所属させます（dockerコマンドを管理者権限なしに実行できるようにするため）。 sudo usermod -aG docker $(whoami) 上記工程をすべて実行した例は以下のとおりです。 ubuntu@WinDev2306Eval:~$ sudo apt-get update -y && sudo apt-get install ca-certificates curl gnupg -y Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease Hit:2 http://security.ubuntu.com/ubuntu jammy-security InRelease Hit:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease Hit:4 http://archive.ubuntu.com/ubuntu jammy-backports InRelease Reading package lists... Done Updating certificates in /etc/ssl/certs... 略 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done. ubuntu@WinDev2306Eval:~$ sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod a+r /etc/apt/keyrings/docker.gpg ubuntu@WinDev2306Eval:~$ echo "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null [sudo] password for ubuntu: ubuntu@WinDev2306Eval:~$ sudo apt-get update -y && sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin Get:1 https://download.docker.com/linux/ubuntu jammy InRelease [48.9 kB] Get:2 https://download.docker.com/linux/ubuntu jammy/stable amd64 Packages [19.2 kB] Hit:3 http://archive.ubuntu.com/ubuntu jammy InRelease Hit:4 http://archive.ubuntu.com/ubuntu jammy-updates InRelease 略 Processing triggers for man-db (2.10.2-1) ... Processing triggers for libc-bin (2.35-0ubuntu3.1) ... ubuntu@WinDev2306Eval:~$ sudo usermod -aG docker $(whoami) [sudo] password for ubuntu: この時点で一度WSLを終了し、再度起動し直してみましょう。 終了は例によってPowerShellで行います。 PS C:\Users\User> wsl --shutdown Ubuntuを再起動した後 docker run hello-world と入力してみましょう。 以下のように表示されたら、dokcerのセットアップは完了です。 ubuntu@WinDev2306Eval:~$ docker run hello-world Unable to find image 'hello-world:latest' locally latest: Pulling from library/hello-world 719385e32844: Pull complete Digest: sha256:a13ec89cdf897b3e551bd9f89d499db6ff3a7f44c5b9eb8bca40da20eb4ea1fa Status: Downloaded newer image for hello-world:latest Hello from Docker! This message shows that your installation appears to be working correctly. To generate this message, Docker took the following steps: 1. The Docker client contacted the Docker daemon. 2. The Docker daemon pulled the "hello-world" image from the Docker Hub. (amd64) 3. The Docker daemon created a new container from that image which runs the executable that produces the output you are currently reading. 4. The Docker daemon streamed that output to the Docker client, which sent it to your terminal. To try something more ambitious, you can run an Ubuntu container with: $ docker run -it ubuntu bash Share images, automate workflows, and more with a free Docker ID: https://hub.docker.com/ For more examples and ideas, visit: https://docs.docker.com/get-started/ もう一つテストで実行してみましょう。 今回はnginx（Webサーバー）を起動してみます。 docker run -d --rm --name nginx -p 80:80 nginx 実行後、curlコマンドを使うことで、nginxが起動していることを確認できます。 ubuntu@WinDev2306Eval:~$ docker run -d --rm --name nginx -p 80:80 nginx Unable to find image 'nginx:latest' locally latest: Pulling from library/nginx 5b5fe70539cd: Pull complete 441a1b465367: Pull complete 3b9543f2b500: Pull complete ca89ed5461a9: Pull complete b0e1283145af: Pull complete 4b98867cde79: Pull complete 4a85ce26214d: Pull complete Digest: sha256:593dac25b7733ffb7afe1a72649a43e574778bf025ad60514ef40f6b5d606247 Status: Downloaded newer image for nginx:latest f82668128daf973712be676fc2ed7c18e67c80de57980eb61708aba1109799e8 ubuntu@WinDev2306Eval:~$ curl localhost <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> Windowsからも動作確認が行なえます。任意のブラウザでlocalhostを開いてみましょう。 WSL2上のUbuntuの上に起動するdockerで立ち上げたnginxに対し、Windowsからアクセスできることが確認できます。 起動したnginxを終了させるには docker stop nginx を実行します。 dockerコマンドを実行しコンテナを起動させようとしたところエラーが出るという場合、すでにWindows側にdocker関係のプロダクトが入っている可能性が高いです。 WSL2側でdockerを実行したい場合、Windows側のdockerプロダクトはすべて削除しておく必要があります（厳密に言えば、削除しておいたほうが無難です）。 Windowsにインストールする「Docker Desktop for Windows」というdockerプロダクトがあります。こちらを使うことでもWindowsマシンでdockerを使うことは可能です。WSL2にdockerをインストールして使うのと、「Docker Desktop for Windows」を使うのどちらが良いでしょうか？ 個人的な意見としては、WSL2 + dockerが良いかなと思っています。というのも「Docker Desktop for Windows」だと、シンボリックリンクを多用したシェルスクリプトの実行に問題があったり、ファイルシステムのアクセス速度に問題があるからです。 Homebrew Homebrewとは？ Homebrewは、macOSやLinuxなどのオペレーティングシステム向けのパッケージマネージャで、ターミナルからコマンドを実行することで様々なアプリケーションやライブラリを簡単にインストールできます。また、自分でパッケージを作成することもできます。Homebrewを使うことで、より簡単・効率的な開発環境構築が可能になります。 インストール 以下のコマンドを実行します。 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" 実行すると、出力されるメッセージの最後の方に ==> Next steps: - Run these two commands in your terminal to add Homebrew to your PATH: (echo; echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"') >> /home/ubuntu/.profile eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)" - Install Homebrew's dependencies if you have sudo access: sudo apt-get install build-essential For more information, see: https://docs.brew.sh/Homebrew-on-Linux - We recommend that you install GCC: brew install gcc - Run brew help to get started - Further documentation: https://docs.brew.sh と表示されるので、この内容に従ってコマンドを実行します。 (echo; echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"') >> /home/ubuntu/.profile eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)" sudo apt-get install -y build-essential brew install gcc 以下が実際にインストールしてみた例です。 ubuntu@WinDev2306Eval:~$ (echo; echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"') >> /home/ubuntu/.profile ubuntu@WinDev2306Eval:~$ eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)" ubuntu@WinDev2306Eval:~$ sudo apt-get install build-essential [sudo] password for ubuntu: Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: bzip2 cpp cpp-11 dpkg-dev fakeroot fontconfig-config fonts-dejavu-core g++ g++-11 gcc gcc-11 gcc-11-base 略 update-alternatives: using /usr/bin/g++ to provide /usr/bin/c++ (c++) in auto mode Setting up build-essential (12.9ubuntu3) ... Processing triggers for man-db (2.10.2-1) ... Processing triggers for libc-bin (2.35-0ubuntu3.1) ... ubuntu@WinDev2306Eval:~$ brew install gcc ==> Fetching dependencies for gcc: gmp, isl, mpfr, libmpc, lz4, xz, zlib, zstd and binutils ==> Fetching gmp 略 🍺 /home/linuxbrew/.linuxbrew/Cellar/gcc/13.1.0: 1,668 files, 320.2MB ==> Running `brew cleanup gcc`... Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP. Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`). 以上でHomebrewのセットアップは終わりです。 このあとの工程でbrewコマンドを使い、アプリケーションをインストールしていきます。 Tailscale Tailscaleとは？ Tailscaleは、オープンソースのソフトウェアで構成された仮想プライベートネットワークを作成することができるソフトウェアです。 Tailscaleで簡単に繋がるネットワーク | Sqripts という記事を公開しているので、参考にしてみてください。 インストール 以下のコマンドを実行します。 curl -fsSL https://tailscale.com/install.sh | sh コマンド実行後、最下部に sudo tailscale up と表示されるので、そのとおりに実行します。 以下が実際にインストールしてみた例です。 ubuntu@WinDev2306Eval:~$ curl -fsSL https://tailscale.com/install.sh | sh Installing Tailscale for ubuntu jammy, using method apt + sudo mkdir -p --mode=0755 /usr/share/keyrings + + sudocurl tee -fsSL /usr/share/keyrings/tailscale-archive-keyring.gpg https://pkgs.tailscale.com/stable/ubuntu/jammy.noarmor.gpg + curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/jammy.tailscale-keyring.list + sudo tee /etc/apt/sources.list.d/tailscale.list # Tailscale packages for ubuntu jammy deb [signed-by=/usr/share/keyrings/tailscale-archive-keyring.gpg] https://pkgs.tailscale.com/stable/ubuntu jammy main + sudo apt-get update Hit:1 https://download.docker.com/linux/ubuntu jammy InRelease Get:2 http://security.ubuntu.com/ubuntu jammy-security InRelease [110 kB] Get:3 https://pkgs.tailscale.com/stable/ubuntu jammy InRelease Get:4 https://pkgs.tailscale.com/stable/ubuntu jammy/main amd64 Packages [8434 B] Get:5 https://pkgs.tailscale.com/stable/ubuntu jammy/main all Packages [354 B] Hit:6 http://archive.ubuntu.com/ubuntu jammy InRelease Get:7 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [119 kB] Get:8 http://archive.ubuntu.com/ubuntu jammy-backports InRelease [108 kB] Fetched 352 kB in 28s (12.7 kB/s) Reading package lists... Done + sudo apt-get install -y tailscale tailscale-archive-keyring Reading package lists... Done Building dependency tree... Done Reading state information... Done The following NEW packages will be installed: tailscale tailscale-archive-keyring 0 upgraded, 2 newly installed, 0 to remove and 56 not upgraded. Need to get 23.7 MB of archives. After this operation, 44.0 MB of additional disk space will be used. Get:1 https://pkgs.tailscale.com/stable/ubuntu jammy/main amd64 tailscale amd64 1.44.0 [23.7 MB] Get:2 https://pkgs.tailscale.com/stable/ubuntu jammy/main all tailscale-archive-keyring all 1.35.181 [3082 B] Fetched 23.7 MB in 17s (1419 kB/s) Selecting previously unselected package tailscale. (Reading database ... 30170 files and directories currently installed.) Preparing to unpack .../tailscale_1.44.0_amd64.deb ... Unpacking tailscale (1.44.0) ... Selecting previously unselected package tailscale-archive-keyring. Preparing to unpack .../tailscale-archive-keyring_1.35.181_all.deb ... Unpacking tailscale-archive-keyring (1.35.181) ... Setting up tailscale-archive-keyring (1.35.181) ... Setting up tailscale (1.44.0) ... Created symlink /etc/systemd/system/multi-user.target.wants/tailscaled.service → /lib/systemd/system/tailscaled.service. + [ false = true ] + set +x Installation complete! Log in to start using Tailscale by running: sudo tailscale up ubuntu@WinDev2306Eval:~$ sudo tailscale up To authenticate, visit: https://login.tailscale.com/a/XXXXXXXXXXXX Success. https://login.tailscale.com/a/XXXXXXXXXXXX といったようなURLが表示されるので、そのリンクを任意のブラウザで開き、Tailscaleにログインすることで、このWSL2で実行されているUbuntuをTailscaleネットワークに所属させることができます。 この状態でTailscaleに所属している他のマシンからssh接続してみましょう。 今回は同じTailscaleネットワークに参加しているMacから接続してみます。 ❯ ssh -l ubuntu windev2306eval The authenticity of host 'windev2306eval (100.70.248.62)' can't be established. ED25519 key fingerprint is SHA256:pQAdFPFMb3+VFgxq+S0lOFOyVuSvNTV5BrhQsb5sXtU. This host key is known by the following other names/addresses: ~/.ssh/known_hosts:38: 100.70.248.62 Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'windev2306eval' (ED25519) to the list of known hosts. ubuntu@windev2306eval's password: Welcome to Ubuntu 22.04.2 LTS (GNU/Linux 5.15.90.1-microsoft-standard-WSL2 x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage * Strictly confined Kubernetes makes edge and IoT secure. Learn how MicroK8s just raised the bar for easy, resilient and secure K8s cluster deployment. https://ubuntu.com/engage/secure-kubernetes-at-the-edge Last login: Thu Jun 29 09:44:49 2023 from 100.116.202.97 このように接続できました。 Macからみて接続しているLinuxが、実はWindowsの中のLinuxとはとても思えない状況で扱うことができます。 もう一つ、別の方法で接続テストをしてみましょう。 dockerの項目で上げた、 docker run -d --rm --name nginx -p 80:80 nginx nginx（Webサーバー）を実行した状態で、WSL2とは異なるマシン上（すなわちWSL2がインストールされたWindows 意外 のコンピューター）のブラウザから、WSL2上のLinuxを開いてみます。 今回はMacのSafariから開いてみました。 このように表示されることから、Ubuntuで起動しているnginxへアクセスできているのが確認できます。 Windows上にWSL2でLinuxをセットアップし、そこへTrailscaleを入れWebアプリケーション開発を行っている場合、同じTailscaleネットワークに所属してる人達が容易に動作確認を行えるので、たとえリモートワークのような作業状況でも、ペアプロや新人教育など多くのシーンで効率の良い作業が行えると思います。 asdf asdfとは？ asdfは、複数のプログラミング言語等のバージョンを管理するためのツールです。インストールやアンインストール、バージョンの切り替えが簡単に行えます。複数のプログラミング言語を使っている場合には、非常に便利なツールとなります。 プログラム言語のバージョン管理意外にも使え、たとえばTerraformのインストールや、Poetryのインストールなど、開発や運用に使われるアプリケーションのいくつかを導入可能です。 インストール 以下のコマンドを実行し、asdfに必要なファイルをインストールします。 sudo apt update -y && sudo apt install -y curl git asdf本体をgithubよりダウンロードします。 git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.12.0 asdfに必要な設定を行います。 . "$HOME/.asdf/asdf.sh" . "$HOME/.asdf/completions/asdf.bash" echo '. "$HOME/.asdf/asdf.sh"' >> ~/.bashrc echo '. "$HOME/.asdf/completions/asdf.bash"' >> ~/.bashrc 以上でasdfの導入は完了です。 以下が実際にインストールしてみた例です。 ubuntu@WinDev2306Eval:~$ sudo apt update -y && sudo apt install -y curl git [sudo] password for ubuntu: Hit:1 https://download.docker.com/linux/ubuntu jammy InRelease Get:2 http://security.ubuntu.com/ubuntu jammy-security InRelease [110 kB] Hit:3 http://archive.ubuntu.com/ubuntu jammy InRelease Get:4 https://pkgs.tailscale.com/stable/ubuntu jammy InRelease 略 curl is already the newest version (7.81.0-1ubuntu1.10). git is already the newest version (1:2.34.1-1ubuntu1.9). git set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 56 not upgraded. ubuntu@WinDev2306Eval:~$ git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.12.0 Cloning into '/home/ubuntu/.asdf'... remote: Enumerating objects: 8446, done. remote: Counting objects: 100% (359/359), done. 略 Or undo this operation with: git switch - Turn off this advice by setting config variable advice.detachedHead to false ubuntu@WinDev2306Eval:~$ . "$HOME/.asdf/asdf.sh" ubuntu@WinDev2306Eval:~$ . "$HOME/.asdf/completions/asdf.bash" ubuntu@WinDev2306Eval:~$ echo '. "$HOME/.asdf/asdf.sh"' >> ~/.bashrc ubuntu@WinDev2306Eval:~$ echo '. "$HOME/.asdf/completions/asdf.bash"' >> ~/.bashrc 開発言語を導入 前項でセットアップしたasdfを利用し、nodejsとpythonの最新バージョンを導入し使えるようにしてみましょう。 そのために、nodejsおよびpythonプラグインを導入します。 asdf plugin add nodejs asdf plugin add python まずはnodejsを入れてみましょう。 asdf install nodejs latest 続けてpythonをいれてみます。 pythonをインストールする前に、別途依存関係のあるファイルを導入してきます。 sudo apt install -y libffi-dev zlib1g-dev libssl-dev libbz2-dev libsqlite3-dev libreadline-dev liblzma-dev tk-dev asdf install python latest インストールしたnodejsとpythonをシステムで使うように設定してみましょう。 asdf global nodejs latest asdf global python latest これで、最新のnodejsとpythonが使えるようになりました。 以下が実際にインストールしてみた例です。 ubuntu@WinDev2306Eval:~$ asdf plugin add nodejs ubuntu@WinDev2306Eval:~$ asdf install nodejs latest Trying to update node-build... ok Downloading node-v20.3.1-linux-x64.tar.gz... -> https://nodejs.org/dist/v20.3.1/node-v20.3.1-linux-x64.tar.gz Installing node-v20.3.1-linux-x64... Installed node-v20.3.1-linux-x64 to /home/ubuntu/.asdf/installs/nodejs/20.3.1 ubuntu@WinDev2306Eval:~$ sudo apt install -y libffi-dev zlib1g-dev libssl-dev libbz2-dev libsqlite3-dev libreadline-dev liblzma-dev tk-dev Reading package lists... Done Building dependency tree... Done Reading state information... Done 略 Setting up tk-dev:amd64 (8.6.11+1build2) ... Processing triggers for man-db (2.10.2-1) ... Processing triggers for libc-bin (2.35-0ubuntu3.1) ... ubuntu@WinDev2306Eval:~$ asdf install python latest python-build 3.11.4 /home/ubuntu/.asdf/installs/python/3.11.4 Downloading Python-3.11.4.tar.xz... -> https://www.python.org/ftp/python/3.11.4/Python-3.11.4.tar.xz Installing Python-3.11.4... Installed Python-3.11.4 to /home/ubuntu/.asdf/installs/python/3.11.4 ubuntu@WinDev2306Eval:~$ asdf global nodejs latest ubuntu@WinDev2306Eval:~$ node --version v20.3.1 ubuntu@WinDev2306Eval:~$ asdf global python latest ubuntu@WinDev2306Eval:~$ python --version Python 3.11.4 next.jsを動かし、そのプロジェクトをVisual Studio Codeで編集してみる 導入したnodejsを利用し、next.jsを動かしてみます。 npx create-next-app@latest --typescript 色々聞かれますが、エンターキーを押して進めていきましょう。 プロジェクトが作成されたら、作成されたディレクトリへ移動し、npmコマンドでnext.jsを起動します。 cd my-app npm run dev 以上で、next.jsアプリケーションが起動するはずです。 動作しているか確認してみましょう。 任意のブラウザから http://localhost:3000/ を開いてみます。 起動していることが確認できました。 次の工程に進むため、起動したnext.jsアプリケーションを停止しましょう。 CTRL+Cキーで停止できます。 ここまで実際に実行した例は以下のとおりです。 ubuntu@WinDev2306Eval:~$ npx create-next-app@latest --typescript ✔ What is your project named? … my-app ✔ Would you like to use ESLint with this project? … No / Yes ✔ Would you like to use Tailwind CSS with this project? … No / Yes ✔ Would you like to use `src/` directory with this project? … No / Yes ✔ Use App Router (recommended)? … No / Yes ✔ Would you like to customize the default import alias? … No / Yes Creating a new Next.js app in /home/ubuntu/my-app. Using npm. Initializing project with template: app-tw Installing dependencies: - react - react-dom - next - typescript - @types/react - @types/node - @types/react-dom - tailwindcss - postcss - autoprefixer - eslint - eslint-config-next added 344 packages, and audited 345 packages in 27s 127 packages are looking for funding run `npm fund` for details 5 moderate severity vulnerabilities To address all issues, run: npm audit fix Run `npm audit` for details. Success! Created my-app at /home/ubuntu/my-app ubuntu@WinDev2306Eval:~$ cd my-app/ ubuntu@WinDev2306Eval:~/my-app$ npm run dev > my-app@0.1.0 dev > next dev - ready started server on 0.0.0.0:3000, url: http://localhost:3000 - event compiled client and server successfully in 153 ms (20 modules) - wait compiling... - event compiled client and server successfully in 95 ms (20 modules) - wait compiling /page (client and server)... - event compiled client and server successfully in 2.3s (463 modules) - wait compiling... - event compiled successfully in 111 ms (225 modules) - wait compiling /favicon.ico/route (client and server)... - event compiled client and server successfully in 301 ms (493 modules) ^C 続けて、WSL2上のLinux環境を、Windows側のインストールされているVisual Stduio Codeで開いてみたいと思います。 code . と入力し、Visual Stduio Codeを立ち上げてみましょう。 Visual Studio Codeのインストール部分で説明した、 Remote Development拡張機能 がインストールされているのなら、問題なく開けるはずです。 ubuntu@WinDev2306Eval:~/my-app$ code . Installing VS Code Server for x64 (695af097c7bd098fbf017ce3ac85e09bbc5dda06) Downloading: 100% Unpacking: 100% Unpacked 1779 files and folders to /home/ubuntu/.vscode-server/bin/695af097c7bd098fbf017ce3ac85e09bbc5dda06. 起動したら、「Trust the authors of all files in the parent folder ‘ubuntu’」にチェックを入れ、「Yes, | trust the authors」ボタンを押しましょう。 左のファイル一覧からapp/page.tsxを開き、「Get started by editing」の部分を「TEST」に書き換えて保存（CTRL+S）し、再度 npm run dev を実行してみましょう。 再度ページを表示してみると、上部が「TEST app/page.tsx」に書き換わっていることがわかります。 このようにして、Windows側のアプリケーションであるVisual Studio Codeを使い、Linux側に置いたファイルをシームレスに編集しながら開発を行うことができます。 便利ツールを入れていこう Homebrewで色々な便利ツールを入れていきます。 lazydocker コマンドが苦手な人でも、わかりやすくdockerの情報を表示し、dockerを操作することができます。 以下のコマンドでインストールし起動できます。 brew update && brew install lazydocker lazydocker dockerに関する詳細な情報を手軽に収集しつつ、ワンキーで色々な操作が行なえます。 lazygit lazydockerのgitバージョンです。こちらもサクサクとgitを操作できます。 brew update && brew install lazygit lazygit 開発を始めたいが、gitのコマンド操作に慣れていないという方におすすめです。 AstroNvim ほとんどの操作やファイルの編集などはVisual Studio Codeで行えます。しかしながらLinuxを触っていると、vimなどで操作をしないといけないシーンに出会うことはよくあります。 そのため、vimの操作を必死に覚えようとするのですが、これが根っからのWindowsユーザーには結構つらい作業だったりします。 vimは適切な設定をおこない拡張機能を入れていくことで使いやすくできますが、そもそもLinuxになれてない、vimになれていない人にとっては、この前段の作業すら困難なわけです。 そこである程度設定済みのvimをいれておくことで、いざというとき作業効率をよくしたり、vimそのものを触るモチベーションを高めることができるのではないか？と思いました。 そういうときに便利なのが、AstroNvimです。 AstroNvimはneovim（というvimの一種）の上に、使いやすくする設定を被せてくれるものです。 以下のコマンドでインストールしてみましょう。 brew install neovim git clone --depth 1 https://github.com/AstroNvim/AstroNvim ~/.config/nvim nvim インストールし、起動を行うと、いくつかのプラグインなどが自動的に入ります。 色々な設定が初期状態で入ってくれているおかげで、ちょっとした設定やコマンドを入力するだけで使いやすいvimベースのIDE環境が手に入ります。 まとめ できる限りコマンド入力にたより環境構築をおこない、ちょっと便利な開発環境を作り上げてみました。実際に開発に使おうとすると、もう少し細かい設定は必要になると思います。 WSL2が登場する前は、Linux開発環境を作る＝仮想マシン（VirutalBox / Vagrantなど）を入れるでした。 WSL2は昔ながらの仮想マシンセットアップと違い、立ち上げるのにそれほど時間はかかりません。 それに加え、仮想マシンではできない・やりにくいWindowsとのシームレスな連携、軽快な動作、仮想マシン以上の作り上げた環境のポータビリティ（エクスポートすることでバックアップ、移動、複製が容易に可）など、仮想マシンにはない多くのメリットがあります。 WSL2を一度も使ったことがないというWindowsユーザーの方は、ぜひ一度触ってみてください。 おまけ LinuxからWindows側のファイルを参照する /mnt/c を参照することで、Windows側のファイルを見ることができます。 vimなどで、直接ファイルを編集することもできます。 ubuntu@WinDev2306Eval:/mnt/c$ nvim /mnt/c/Users/User/test.txt WindowsからLinux側のファイルを参照する ファイル名を指定して実行（Windows キー + R）より、「\wsl$」を入力（\は日本語で言う￥（実際は半角で打つ）のことを指しています）することで、WSL2側のファイルを開けます。 Visual Studio Codeなどで、直接ファイルを開くことできますが、初回は警告が出ます。 Allowを選択することで開くことが可能です。 開発用マシンを日本語環境に設定変更する スタートメニューへ「langu」と打つことで、言語設定変更画面へのショートカットが表示されます。 「Add a language a this device」を選択し、「Langueage & region」画面を開き「Add a language」ボタンを押します。 「Choose a language to install」画面に「japan」と入力することで、日本語が候補に表示されますので、Nextボタンを押して確定させます。 日本語のインストールが作業が終わると「Sign out」ボタンが表示されるので、サインアウトして日本語化は完了です。 ただしこの作業だけでは、キーボードが英語配列認識されていたり、日本語入力ソフトが入っていないなどの問題が残ります。 この問題を修正するには、追加した日本語の横にある「…」を押し、「言語のオプションを開きます」 キーボードレイアウトを「英語キーボード（101/102キー）」から「日本語キーボード（106/109キー）」に変更し再起動します。 最後にタイムゾーンを「UTC+09:00 大阪、札幌、東京」に変更して完了です。 The post Windowsユーザーにささぐ、WSL2を利用した（ちょっと便利な）Linux開発環境作成 first appeared on Sqripts .

はじめましてTMです。私は普段ユーザー受入テストの設計、実装、実施まで一通り行う業務を担当しています。 この記事では、テスト分析・設計といったフェーズで、Chat GPTがどの程度活用できるのか実際に試したプロンプトと、得られた回答を紹介したいと思います。 AIにテスト設計をさせようと思った理由 生成AIであるChat GPTを活用することでテスト分析・設計が楽になるのでは？ 人間が考えた事と同じ事ができるか？ 今回AIを使って行なったこと テスト分析において人間が抽出したテスト要素と同じレベルでAIがテスト要素を抽出できるかの検証 人間がテスト設計し、同じようなアウトプットをAIが出力できるかの検証 ChatGPTがテスト分析・設計できるのか？できないのか？について先に結論を申し上げますと、今回の検証では分析はある程度上手くいきましたが設計では微妙な結果になりました。 上手くいったところだけ紹介したいところですが、上手くいかなかったところも参考になればと思います。 環境 SlackGPT（API） AGESTではSlack経由でChatGPTのAPIを利用できる環境（SlacGPT）が提供されているので、こちらを利用しています。 API版はWeb版と異なりモデルのトレーニングや改善には原則使われないサービスです。 API data usage policies テスト分析・設計をおこなう対象 AIにテスト分析・設計をおこなってもらう対象として、架空のECサイトのコンテンツ横断型ポイント還元キャンペーンを設定しました。 〇開催期間：7月25日（火）17:00〜8月7日（月）23:59 〇キャンペーンへの参加方法： ・キャンペーンに参加するためには、エントリーが必要です。 ・ログイン後、特設ページ内のエントリーボタンからエントリーができます。 ・キャンペーンの開催期間中に発生した購入（サービスご利用）であれば、エントリー前の購入（サービスご利用）もキャンペーンの対象になります。 〇キャンペーン内容： ①ポイント倍率最大50倍！ABCのサービスを複数ご利用でポイントアップ 2サービス以上のご利用でポイント倍率が15倍になるほか、3サービス以上のご利用でポイント倍率が5倍ずつ上昇します。期間中9サービス以上ご利用でポイント倍率が50倍になります。 ※キャンペーン期間中に1サービスあたり500円（税込）以上のご利用が対象になります。 ※ポイント倍率アップに最適な商品として、500円（税込）で販売する商品も多数ご用意しています。 ②土日限定！ポイント倍率+10倍 「ABCポイント還元祭」期間中の土日にサービスをご利用いただくことで、ポイント倍率がプラス10倍になります。 ※対象期間：7月29日（土）、7月30日（日）、8月5日（土）、8月6日（日） ③ABCゴールド会員限定！ポイント倍率+5倍 ABCゴールド会員限定で、ポイント倍率がプラス5倍になります。 ※キャンペーン期間中にABCゴールド会員に登録していて、かつ還元ポイントの集計日である9月15日（金）までゴールド会員に登録していることが条件です。 ※キャンペーン期間中から集計日までに一度でも解約された場合は、集計日にABCゴールド会員に登録していてもポイント付与の対象外とします。 ※キャンペーン期間中であってもABCゴールド会員登録前の購入分は、本施策のポイント付与対象外になります。 ④3日間限定！対象カード決済によるポイント還元 8月1日（火）～8月3日（木）の3日間限定で、対象カードによる決済額の合計に応じたポイント還元を行います。 【ポイント還元率】 ・10,000円以上30,000円未満の利用で8%還元 ・30,000円以上50,000円未満の利用で10%還元 ・50,000円以上の利用で12％還元 〇対象サービス一覧： ・ABCトラベル ・ABC保険 ・ABC外国語 ・ABC証券 ・ABCミュージック ・ABCカーシェア ・ABCTV ※レンタル・購入のみ対象、月額料金は対象外 ・ABCアミューズメント ・ABC通販 ・ABCコミックレンタル 〇注意事項： ※クーポンを利用した場合は、クーポン利用後の決済額を対象として還元ポイントを計算します。 ※ABC保険での取り扱い商品の中には、一部キャンペーン対象外の商品があります。 ※その他の注意事項につきましては、特設ページをご確認ください。 テスト分析において人間が抽出したテスト要素と同じレベルでAIがテスト要素を抽出できるかの検証 テスト要素の抽出（人間） テスト分析では、まずステークホルダーにヒアリングして何を見て欲しいのか確認します。 以下の回答を得られたとします。 サービス横断しているので、複数サービス利用するケースを見てほしい 還元するポイントが増減するので間違えていないか確認してほしい 上記を念頭にしたテスト分析では ポイントに関する要素が重要 と判断しました。 この後のテスト設計に繋げるためにも、まずはポイントに関する要素をテスト対象として抽出します。 開催期間（期間外/期間内） 参加有無（エントリーあり/なし） 複数サービス利用（ポイント倍率最大50倍、2サービス以上15倍/3サービス以上で5倍ずつ上昇） 最低利用金額（500円） 曜日（土日はプラス10倍） ゴールド会員の倍率（会員はプラス5倍） ゴールド会員の期間（キャンペーン期間中の入会/解約）ｘ（サービス利用） 対象カードの還元（8月1日（火）～8月3日（木）の3日間はABC 対象カードポイント還元（8%/10%/12%）） 対象サービス数（10サービス） クーポン（割引後の金額と最低利用金額の考慮） テスト要素を抽出していただく（AI） 今回は要素の抽出なので、結論などは記載して欲しくないため以下のようなプロンプトを実行します　 参考URL Chat GPTの回答 続いてポイントに関する要素を抽出してもらいます、いくつかプロンプトを試したところ以下のプロンプトで求めるものに近い結果が得られました。 Chat GPTの回答 要素の抽出において人間と同レベルの結果が得られたか？ Chat GPTの回答にあって私が抽出した要素になかったものが以下になります。 一部キャンペーン対象外の商品に対する考慮 ポイント倍率アップに最適な商品として、500円（税込）で販売される商品がある 「一部キャンペーン対象外の商品」については、重要なテスト要素となりえるため考慮すべきでした。 次に「ポイント倍率アップに最適な商品」については、最低利用金額500円で考慮しており、特段わけて考える必要はないと判断しました。 逆に人間が抽出したものでAIが抽出できなかったものはありませんでした。 今回はある程度プロンプトがうまくいった成功例と言えます。 テスト分析時の要素の抽出において、 プロンプトを工夫すれば 有用な回答が得られました。 また、今回工夫した点は、 ポイントに関する要素に絞った事 です。 以下のような要素の絞り込みをしていないプロンプトの場合 人間があまり重要ではないと考えた要素（参加方法）も抽出してしまいます。 人間がテスト設計し、同じようなアウトプットをAIが出力できるかの検証 テスト観点を考える（人間） ①複数サービス利用のポイントアップ 複数サービス利用（ポイント倍率最大50倍、2サービス以上15倍/3サービス以上で5倍ずつ上昇） 対象サービス数（10サービス） 利用サービス数 ポイント倍率 1 0 2 15 3 20 4 25 5 30 6 35 7 40 8 45 9 50 10 50 境界値分析を用いて、ポイント倍率がつくケースとつかないケースを確認する 同値分割を用いる（1~2の15倍UPグループ、2~9の5倍ずつUPグループ 9~10は上限到達グループ） テストデータ：1,2,3,8,9,10 対象サービス（10）は最低1回は利用する 利用サービス数ごとにポイント倍率が正しいことを確認する ②土日のポイントアップ 曜日（土日はプラス10倍） 金曜 土曜 日曜 月曜 7/28 7/29 7/30 7/31 8/4 8/5 8/6 8/7 境界値分析を用いて、土曜日になる前後の確認を実施する テストデータ：7/28 23:59:59、7/29 0:00:00、8/4 23:59:59、8/5 0:00:00 境界値分析を用いて、月曜日になる前後の確認を実施する テストデータ：7/30 23:59:59、7/31 0:00:00、8/6 23:59:59、8/7 0:00:00 最初の土日と2回目の土日でポイント10倍であることを確認する（2回目で20倍になったりしない） 土日以外の曜日でポイントがプラス10倍になっていないことを確認する ③ゴールド会員のポイントアップ ゴールド会員の倍率（会員はプラス5倍） ゴールド会員の期間（キャンペーン期間中の入会/解約）ｘ（サービス利用） ゴールド会員 会員 非会員 +5倍対象 +5倍非対象 サービス期間中の入会 入会前 入会後 +5倍非対象 +5倍対象 ポイント付与日までの解約 解約なし 解約あり 解約後入会 +5倍対象 +5倍非対象 +5倍非対象 境界値分析を用いて+5倍対象、対象外の7ケースを確認する ④対象カード決済のポイントアップ 対象カードの還元（8月1日（火）～8月3日（木）の3日間は対象カードポイント還元（8%/10%/12%）） 利用金額 還元率 ～9,999円 0% 10,000円～29,999円 8% 30,000円～49,999円 10% 50,000円～ 12% 境界値分析と同値分割を用いて8%、10%、12%の還元率になる金額をテストする テストデータ：9,999円、10,000円、29,999円、30,000円、49,999円、50,000円、50,001円 ⑤条件適合性 開催期間（期間外/期間内） 参加有無（エントリーあり/なし） 最低利用金額(500円) クーポン（割引後の金額と最低利用金額の考慮） コンディションとアクションなのでデシジョンテーブルで整理してみる – – 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 条件 開催期間内 Y Y Y Y N Y Y N Y N N Y N N N N – エントリーあり Y Y Y N Y Y N Y N N Y N Y N N N – クーポン利用あり Y N Y Y Y N Y Y N Y N N N Y N N – 利用金額は500円以上 Y Y N Y Y N N N Y Y Y N N N Y N 動作 ポイント倍率UPあり X X – – – – – – – – – – – – – – – ポイント倍率UPなし – – X X X X X X X X X X X X X X テストデータNo.1,3,4,5 No.1：クーポンを利用してポイント倍率UPされるケース No.3：クーポンを利用したら金額が500円未満になってしまったケース（他条件は対象） No.4：エントリーを忘れてしまったケース（他条件は対象） No.5：対象期間前に利用してしまったケース（他条件は対象） ※今回はプログラムが処理される順序が不明なブラックボックステストを想定して、デシジョンテーブルの動作単位で整理はしていません。 そのうえで、ひとつの条件で対象外になるケースは各条件が想定どおり動作する確認のために必要と考えました。 テスト観点を考えていただく（AI） AIには、先ほどAIが抽出した後に以下のプロンプトで指示をだしました。 Chat GPTの回答 7つのグループにわけてテスト設計してくれましたが、グループ2：ポイント倍率アップに最適な商品は、ポイント倍率アップに最適な商品として500円の商品が多数ラインナップされることであり、ポイントの増減の観点ではあまり有効とは思えません。 また、「開催期間」や「エントリーの有無」といった条件がどのグループにも現れていない結果になりました。 人間と同じような設計アウトプットが得られたか？ 今回の設計アウトプットを比較すると下図のようになりました。 グルーピングについて あまり有効ではない「グループ2：ポイント倍率アップに最適な商品」をグルーピングしています。また、人間が設計した場合は⑤条件適合性として複数条件をまとめてテスト設計していますが、（プロンプトを与えていないので当然ですが）個別の考慮にとどまっています。 考慮漏れ 要素で抽出した「開催期間」と「エントリーの有無」がなぜか欠落しました。 テスト技法について AIのテスト設計では、7グループ中6グループでデシジョンテーブルが提案されています。 しかしながら、デシジョンテーブル技法は複数の条件のもと、それぞれの場合の振る舞いを整理するために活用する技法で、今回AIがグルーピングしてくれた単位では、条件が少なすぎて有効ではないと考えられます。 具体例として、AIがテスト技法にデシジョンテーブル（と同値分割）を提案したグループ1で、デシジョンテーブルを作成してもらいました。 グループ1に対するデシジョンテーブル作成のプロンプト Chat GPTの回答 グループ1で作成してくれたデシジョンテーブルでは条件が「上限値未満」と「上限値超過」しかないので有効ではない結果となりました。 まとめ 今回の検証方法では、テスト分析では期待したアウトプットに近い結果が得られましたが、テスト設計では人間と同等のアウトプットは得られませんでした。原因は、テスト分析でAIが抽出した要素（グループ分け）をそのままテスト設計のインプットとした事です。 AIはあくまでプロンプトに従って結果を生成しているので、テスト分析の結果から、テスト設計に落とし込む過程で人間が考えた事をプロンプトに明確に指定する必要があると感じました。 おわりに ECサイトの期間限定ポイント還元という、比較的わかりやすいシステムを対象にした今回の検証結果、いかがでしたでしょうか？ 概要レベルで出してくれるアウトプットがそのまま使えそうじゃないか！？と飛びついて使用してみた生成AIですが、実際に活用しようとすると人間側の指示がかなり重要で、テスト分析やテスト設計といったフェーズ事に一気通貫で活用するのは難しい結果になりました。　フェーズごとに人間が介入して訂正する事を前提に考えると、テスト分析の結果はJSON形式などの人間にもわかりやすく、かつAIにも一定の形式になっていて加工しやすいデータ形式でアウトプットすることで、テスト分析からテスト設計への移行が楽になるかもしれません、うまく活用してQCD改善していきたいですね。 最後まで読んでいただき、ありがとうございました。 力こそパワー ■AIを活用したソフトウェアテストのサービス化を視野に、AI技術の研究開発を行う「AGEST AI Lab.」を設立しました 詳しくは こちら から The post ChatGPT！テスト設計できるのかい？できないのかい？どっちなんだい！ first appeared on Sqripts .

本連載では、ブロックチェーンの基本的な仕組みを解説しながら、オンチェーンデータを分析するための基本的な手法について、全8回で紹介します。 第3回となる今回は、暗号資産（仮想通貨）のなかでビットコインに続き第2位の時価総額 （※1） を維持しているイーサリアム （※2） について解説し、ブロックチェーンの仕組みについての理解を深めます。 ※1 CoinMarketCap （2023年6月現在） ※2 Ethereum イーサリアムとは イーサリアムは、ブロックチェーン技術を用いて実装された、分散アプリケーションのためのプラットフォームです。 ビットコインの発明とともに登場したブロックチェーン技術は、 第2回 の連載記事でも解説したとおり、「不特定多数の参加者で構成されるネットワークで、悪意のある参加者が存在したとしても、全体として正しく動き続ける分散アプリケーション」を実現することができます。ビットコインはそれをデジタル通貨として利用しましたが、ブロックチェーン技術は通貨以外にもさまざまな応用が考えられます。 例えば、簡単なマイクロブログサービスを分散アプリケーションとして実装すれば、特定のプラットフォームに依存することなく、いつでも自分のつぶやきを投稿することができ、誰かに検閲されることもなければ、サービス終了とともにデータが消えてしまうということもありません。そのようなさまざまな分散アプリケーションを簡単に実現するためのプラットフォームがイーサリアムです。 イーサリアムの誕生 ブロックチェーン黎明期の分散アプリケーション開発の多くは、ビットコインのコードベースをフォークしてきて、一部を修正するような形でおこなわれていました。第1回の連載記事でも紹介した、「ライトコイン」 （※3） や「ネームコイン」 （※4） などがその典型例です。ビットコインのコードはオープンソースとして一般に公開されており、誰でもダウンロードして実行できるだけでなく、一部を改変して独自のアプリケーションとして実行することも可能です。 しかし、ビットコインをフォークした形のアプリケーション実装では、そのアプリケーションを動かし続けてくれるためのネットワーク参加者を集めることにハードルがありました。一般的なWebサービスなどのアプリケーションであれば、開発者自身がサーバーを準備してアプリケーションを公開するだけで、世界中の人々がそのアプリケーションにアクセスできます。一方、ブロックチェーンアプリケーションの場合、そのサービスを使いたい利用者が自身のマシンにアプリケーションをダウンロードしてきて、そのマシン上でプログラムを実行し続けなければなりません。もちろん、ビットコインのようにある程度の参加者が集まれば、既存のネットワーク参加者のノードに対して通信するだけでサービスを利用できる形になるのですが、安定したサービスを提供できるレベルまでネットワーク参加者を集めるには、よほど共感されるアイデアやメリットがない限り困難でした。 そこで、すでに稼働している既存のブロックチェーンの上に、汎用的なアプリケーション層を構築するサービスも登場してきました。例えば、ビットコインの場合、トランザクションのなかにビットコインの送金だけでなく、メッセージのような小さなデータを書き込むことができる仕様がありました。ビットコインのトランザクションにテキストを書き込むことで、上記の分散型マイクロブログのようなサービスは構築できます。また、より大規模なデータを扱いたい場合でも、そのデータをハッシュ関数で小さなデータに圧縮することで、「過去にそのデータが存在しており、それ以降改ざんもされていない」といった存在証明が可能です。Blockcerts （※5） というサービスでは、大学の卒業証明書や民間の資格証明書などのハッシュ値をビットコインブロックチェーンに刻み、存在証明をおこなうことで、誰もが簡単にブロックチェーン技術を用いた証明書を発行することができます。 しかし、既存のブロックチェーンを他の用途で使うという仕組みは、もともと想定されていないハック的な使い方のため、使い勝手や効率もよくありません。そこで、汎用的な分散アプリケーションを動かすために設計された新しいブロックチェーンシステムとして、イーサリアムが登場しました。 イーサリアムは、当時19歳の学生であったヴィタリック・ブテリンによって考案されました。そのアイデアがホワイトペーパー （※6） として公開されています。2014年ごろから開発が進められているEthereumは、2023年現在までに大きなアップデートを何度も繰り返しているため、ホワイトペーパーだけを読んでも現在のEthereumの全貌を理解することは難しいのですが、当時の背景やコアコンセプトを知ることで現在の仕組みもより深く理解することができると思いますので、興味あるかたはぜひホワイトペーパーも読んでみてください。 ※3 Litecoin ※4 Namecoin ※5 Blockcerts ※6 Ethereum White Paper スマートコントラクト イーサリアムの特徴は、さまざまな分散アプリケーションのロジックを専用のプログラミング言語で記述し、ブロックチェーン上で実行できる点です。ブロックチェーン上で実行する、というのは、トランザクションを発行してブロックチェーン上の状態を変更できる、という意味です。ビットコインの場合も、抽象的にはアカウントごとにビットコイン残高という状態があり、トランザクションの実行後にその状態（残高）が変化する、という形で状態遷移をおこなっています。また、ビットコインのトランザクションも、スクリプトと呼ばれるプログラミング言語でルールが記述されている、という点も似ています。 しかし、ビットコインのスクリプト言語は、通貨の送金という用途に特化しており、無限ループなどを含む任意のロジックを記述することはできませんでした。イーサリアムの場合、無限ループを含む任意のロジックを専用のプログラミング言語で記述し、ブロックチェーンに配置しておくことができます。イーサリアムの利用者は、あらかじめ配置されたプログラムの関数を呼び出すトランザクションを発行することで、通貨の送金だけではないさまざまな用途の分散アプリケーションを利用することができます。 この、イーサリアムにおける汎用的なプログラムを、「スマートコントラクト」と呼びます。スマートコントラクトというアイデアは、デジタル通貨の研究者であるニック・サボが1997年に提唱 （※7） しています。ニックのアイデアは、現実世界における自動販売機のような自動執行される契約をデジタル上でも実装するといったものです。例えば、自動車を運転する権利などを契約に基づいて自動的に移転できるようになれば、自動車を担保にしたローンや、レンタカーの運転権利などを自動で権利者に移転したりすることができます。 2023年現在では、そのようなオンラインで物理的なものの使用権を移転できるサービスも普及しつつありますが、多くは特定企業によるサービス提供だと思われます。イーサリアムの場合、このスマートコントラクトを、不特定多数の誰もが参加できるブロックチェーンネットワーク上で実行し、特定のサービス主体に依存しない、次世代スマートコントラクトとして提唱しています。現在、一般的にスマートコントラクトと呼ぶと、イーサリアムを代表とするブロックチェーン上の分散プログラムのことを指すことが多くなっています。 ※7 The Idea of Smart Contracts ビットコインとのデータ構造の違い 同じブロックチェーン技術の応用であっても、ビットコインとイーサリアムにはさまざまな違いがあります。データ構造における両者の最も大きな違いは、UTXOモデルとアカウントモデルです。 第2回の連載記事でも解説したとおり、ビットコインのトランザクションには「Inputs」と「Outputs」という概念があり、Outputsのうちまだどこにも送られていないものが、自由に使える残高、という考え方です。この未使用トランザクションアウトプット(Unspent Transaction Output)をUTXOと呼びます。 一方、イーサリアムの場合は、通貨の送金だけでなく、文字列や複雑なデータ構造を含む汎用的な状態を管理するため、アカウントに対して通貨の残高データが紐づくアカウントモデルとなっています。 実データを観察する それでは、実際のデータを観察しながら、これまでの解説を確認してみましょう。ビットコインの場合と同様、イーサリアムも自身でノードを立ち上げて、イーサリアムネットワークから情報を取得することもできますし、イーサリアム上のデータをデータベース化したオンラインサービスも数多く存在します。 Etherscan Etherscan （※8） は、イーサリアムが登場した黎明期から存在し、機能拡張を繰り返し現在でも多くのユーザに利用されているエクスプローラーサービスです。図1に、Etherscanのサービス画面例を示します。 図1. Etherscanのサービス画面 ビットコインの場合と同様に、生成された最新のブロックや、ブロックに含まれるトランザクションの一覧が確認できます。ビットコインの場合は生成されるブロックの間隔は10分前後でしたが、イーサリアムの場合は12秒前後のため、頻繁に画面も更新されます。 ※8 Etherscan Dune イーサリアムのオンチェーンデータを用いて簡単にデータ分析をおこなえるサービスとして、Dune （※9） を紹介します。第2回の連載記事で紹介したBigQueryでも、一般公開データセットにイーサリアムのデータセットが含まれており、SQLを用いて柔軟な分析が可能です。Duneはそのブロックチェーン特化版の分析サービスであり、ブロックチェーン特有のデータ構造に細部まで対応していたり、作成したクエリやダッシュボードを他ユーザに共有したり可能なソーシャル要素もあるスタートアップサービスです。 図2は、Duneの共同創業者である @hagaetc が作成したダッシュボード例です。 図2. Dune – @hagaetc / DEX metrics のダッシュボード例 ※9 Dune イーサリアムのデータ構造 Etherscanの実データを参照しながら、イーサリアムのデータ構造について確認していきましょう。 ブロック 多くのブロックチェーンでは、複数のトランザクションをまとめたブロックが、前のブロックのハッシュ値を参照している、というデータ構造は変わりません。イーサリアムの場合も、ビットコインと同様に、ブロックとトランザクションというデータ構造を持っています。 図3. Etherscan – ブロックのサンプルデータ 図3に、Etherscanで表示したイーサリアムのブロックデータのサンプルを示します。Block Heightは、そのブロックチェーンが積み重ねてきたブロックの長さを表します。Transactionsの行を見ると、このブロックには144のトランザクションと、43の内部トランザクションが含まれていることが分かります。 イーサリアムのブロックも、イーサリアムネットワークに参加している不特定多数のノードによって自律的に生成されており、ブロックの生成に成功した参加者が、所定の手数料を受け取れる仕組みになっています。それらに関する情報が、Fee RecipientやBlock Rewardです。 イーサリアムに特徴的な仕組みとして、ガス（Gas）という概念が存在します。これは、トランザクションを発行するための手数料を計算する仕組みに関連する概念です。ビットコインの場合も、トランザクションを発行するために手数料を支払う必要がありますが、その金額は基本的にトランザクションのデータ量（bytes数）に比例します。ただし、トランザクション手数料の設定はトランザクション発行者が任意に決めることができ、優先的に自身のトランザクションを取り込んでもらうために多めの手数料を支払う、といったことも可能です。 イーサリアムの場合、トランザクション発行者が手数料を任意に決められる、という点では同じですが、そのベースとなる値はトランザクションのデータ量ではなく、トランザクションを計算するために消費するリソース量となります。これは、イーサリアムが無限ループを含むようなプログラムの実行も許容する仕組みとなっているため、トランザクションのデータ量が少ない場合でも、実行のために膨大なリソースを消費してしまう可能性があるためです。このトランザクション実行に必要なリソース量を、ガスという概念で表現しています。 あるトランザクションを実行するために必要なガスは、あらかじめ厳密に計算することは難しいものの、同じ入力に対してであれば基本的には一定のガスがかかります。このガスに対して、1ガスあたりの手数料をトランザクション発行者が指定し、Ether(単位: ETH)というイーサリアムのネイティブ通貨で支払います。 トランザクション 図4は、あるブロックに含まれるトランザクションの一覧を表示したサンプルデータです。トランザクションには固有のトランザクションハッシュ（Txn Hash）がIDとして付与されており、誰が（From）、誰に（To）、ETHを送った量（Value）、実行したメソッド（Method）、支払った手数料（Txn Fee）などが共通の情報として含まれます。 図4. Etherscan – ブロックに含まれるトランザクション一覧のサンプルデータ また、リンクとなっている適当なトランザクションのハッシュをクリックすると、そのトランザクションの詳細ページを確認できます。詳細ページに表示される内容はトランザクションの種類によって異なるため、今回は詳細を割愛し、次回以降の連載で必要なトランザクションの種類について深掘りします。 図5に、トランザクション詳細のサンプルページを示します。Overviewのほかに、他のタブを選択することで、表示内容を切り替えることができます。ここでは、Logsタブを開いてトランザクションの詳細なイベントログを表示しています。 図5. Etherscan –トランザクション詳細のサンプルデータ コントラクト Etherscanのページでは、一部のコントラクトについてはソースコードも含めて確認することができます。図5のサイト上の「View Source」から遷移したコントラクトページのサンプルを図6に示します。 図6. Etherscan – コントラクトコードのサンプルデータ イーサリアムのトランザクションの詳細な内容を把握するには、こちらのコントラクトコードまで遡って理解する必要がある場合もあります。また、Etherscanでは、コントラクトコードに実装しているメソッドをサイト上で呼ぶ機能もあります。Read Contractタブでデータ取得系のメソッドを実行することで、そのコントラクトの現在の状態などをノーコードで確認できます。 また、これはまだベータ版の機能ですが、ChatGPTのAPIを利用して、コントラクトコードの内容をAIによって解説したり要約したりといった利用が可能なCode Readerというサービスもアナウンスされました （※10） 。 ※10 Twitter – @etherscan コントラクト規格 イーサリアムでは任意のコントラクトコードを実装して実行できますが、各自がバラバラの仕様でコントラクトを実装すると、他のコントラクトで統一的に扱ったり、データの分析が困難になったりする可能性があります。 そこで、イーサリアムではよく利用されるコントラクトの用途について、標準規格の策定が行われています。その規格化は、インターネットの技術仕様の標準化に用いられているRFC(Request For Comments)をもじって、ERC(Ethereum Request for Comments)と呼ばれています。代表的なERCのコントラクト規格には、ERC-20（Token Standard）やERC-721(Non-Fungible Token Standard)などがあります。詳しくは、実際のデータ分析の回にて解説します。 次回予告 イーサリアムの登場によって、ブロックチェーン技術を活用したスマートコントラクトの開発が容易となり、さまざまな種類の分散アプリケーションが登場しました。また、コントラクト規格の標準化により、統一的なインターフェースで、それらの分散アプリケーションのトランザクションを分析することも可能となりました。 次回の記事では、ブロックチェーン上のオンチェーンデータを分析するためのクエリ言語として、SQLの基礎について解説し、オンチェーンデータ分析の準備を始めていきます。 【 第1回】：ブロックチェーンとは 【第2回】：ビットコインの仕組み The post 【第3回】イーサリアムの仕組み first appeared on Sqripts .

みなさんこんにちは。エリアマネージメント部のゆーてぃです。 今回はテストを始める前にいつも行っていることを記事にしたいと思います。 要求は人によって様々 みなさんは買い物の時にどんなものがあるか見てから決める時があるのではないでしょうか。時には店員さんに「こういう機能がついてる物がほしい」、「●円の予算に収まる物がほしい」、「在庫があってすぐに持って帰れる物から選びたい」などの要求を伝えた上でアドバイスを聞くこともあると思います。 それはテストも同じことで、テストの目的はプロジェクトによって様々で、「これらを満たすようにテストしたい」や「この予算内でテストしたい」、「いついつまでに完了するようにテストしたい」といった内容もあります。 「JSTQB Foundation Level シラバス」にも以下の記載があるように、我々は店員の目線からしっかりと要求事項を整理した上でそのプロジェクトにあったプランを検討し、共通のゴールを明確にして進めることが重要だと考えています。 （以下、JSTQB FLシラバスから抜粋） 「1.4.2 テストの活動とタスク」 テスト計画では、テストの目的と、状況により課せられる制約内でテストの目的を達成するためのアプローチを定義する（例えば、適切なテスト技法とタスクを指定し、納期に間に合うようにテストスケジュールを作成する）。 出典： ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 では「多端末テスト」に対して「できるだけたくさんの端末でテストしたい」との要求を伺った場合を例として、日頃どのようにゴールを決めているか、一つ一つ説明していきたいと思います。 要求事項を整理 ・目的の確認 多端末テストを行う目的として「画面比が異なることによる表示バグがないか確認したい」や「OS依存の不具合を見つけたい」、「一般ユーザー向けに公開する推奨環境を検討したい」など目的は様々あります。 目的を理解していないと、目的にあった端末を選定できず、テストアプローチも正しく検討できません。目的から外れた効果の薄いテストにならないよう、まずは目的を明確にします。 ・プロダクトタイプ、ユーザー層の確認 テスト対象のプロダクトがどのようなもので、どのユーザー層をターゲットとしているかで、テスト端末の選定幅も変わってきます。たとえば、BtoBなのであれば、ユーザーとなる企業で実際に使われている端末でテストするのが効果的ですし、BtoCなのであれば市場シェア率を考慮した選定を行います。 また、性別、年代によってシェア率は変わりますのでユーザー層を把握した上で端末選定を行うとより効果的になります。 ・制約事項の確認 次にプロジェクトの制約事項について確認していきます。 予算、納期、リソースのすべてに余裕があり、やりたいテストをすべて実行可能なプロジェクトはない。と言っても過言ではないと思います。制約事項を把握することで正しい優先度付けができると考えています。 テストプランの検討 ある程度の情報が揃ったところで一度テストプランを3パターン程検討します。 ・パターン1： 品質優先 のおすすめプラン 要求をしっかり理解した上で、テストの知見、実績ベースの過去データをもとに品質を高めることを優先としたアプローチを検討し、予算、納期への影響を明確にします。 ・パターン2： 品質、納期をキープする プラン 目的の達成、且つ納期に間に合うアプローチを検討し、テスト内容、予算への影響を明確にします。 ・パターン3：一部目的を削り 制約内でテスト するプラン 決められた予算、納期の制約内でテストを行った場合のテスト内容、および品質に対するリスクを明確にします。 そして、テストプランを検討した後は、各パターンの期待される効果を説明した上ですり合わせを行います。もちろん我々としては「品質優先のおすすめプラン」を推奨しますが、プロジェクトによってマッチするものは変わってくると思います。最後はしっかりとすり合わせた後、プランを選択することで、共通のゴールが明確な状態でプロジェクトを進めることができます。 まとめ 今回はテストを始める前にいつも行っていることを「多端末テスト」を一例として記事にしてみました。何れのプロジェクトでも要求は様々だと思いますので、我々はスタート前にしっかりとゴールを決めた上で、プロジェクトを進めることが重要だということを日々念頭において、業務を遂行したいと思います。 The post お客様満足度の高いテストプランの組み立て方～3つの確認でゴールを決めよう～ first appeared on Sqripts .

AGEST Academyです。 本記事では、ソフトウェアテストを始めたばかりの人、まだソフトウェアテストをやったことがない人に向けて、「ソフトウェアテストとは」どういうものかについてご紹介します。 新米テスターの「ぱなも・ホワイト」 とテスト経験258年の「ニャックス・ブラック」 が、それぞれの経験に基づいて楽しくお話しています。 本記事を通して、皆さんの考えるソフトウェアテストについて少しでも触れられましたら幸いでございます。 (1)ニャックスのソフトウェアテスト 新米テスターのぱなもでキュルン。 よろしくキュルン。 テスト経験258年のニャックスだ。 よろしく。 困ってることはあるか？ 先輩にとって、テストってどういうものキュルン？ どうした？ テストの話をしても理解がなくて……うまく伝わらないキュルン。 私も 学校のテストとは 違うのか、問われたことがある なんて答えたキュルン？ 学校のテストは、こうなるべきという決められた解答がある。ソフトウェアテストには、 答えが一つでない 場合もある。 不確実で創造的 なものだ。 すごくわかるキュルン！ 実際は、学校のテストでも「 生徒・教師・保護者・それ以外の関係者 」でそれぞれテストの捉え方が違うはずだ。 関係者が学校のテストについてどう向き合っているのか調べたものを紹介する。 　※ なぜ(学校で)テストをするのか 要約：「言語テスト研究」でよく言及される 「妥当性」や「信頼性」といった基本概念 をとってみても、教師との思惑のずれが見える。「妥当性」とは、「 測ろうとしている能力をテストが測っているか 」を表し、「信頼性」とは「 測ろうとしている能力を安定して測っているか 」を表している。これらの概念の大前提は， テストでは何らかの「能力」を測ろうとしている ということである。 ＜出典＞ 三省堂 TEACHING ENGLISH NOW vol.27 妥当性や信頼性 という表現が非常に興味深い。 このレポートとテストの思想は近い ものだ。 人によってこんなにも捉え方が違うキュルン？ 面白いキュルンっ～～！！ 良いセンスだ。 私にとってのソフトウェアテストは、 価値観の違いが生む人のすれ違いを減らす活動 だ。 （でも、先輩のようにうまく伝えられる自信がないキュルン……） (2)有識者のソフトウェアテスト ソフトウェアテスト技術者資格認定で知られるJSTQBのテストを紹介する 「すべてのライフサイクルを通じて実行する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価すること」 ＜出典＞ JSTQB用語集 – テスト(testing) 難しいキュルン…… 文章は固いかもしれないな。 次に、IEEE Software誌の元編集長で知られるSteve McConnellのものを紹介する。 「ソフトウェアテストは、もっともポピュラーな品質改善方法である」 ＜出典＞ Steve McConnell 品質改善キュルン？ ぱなもくんには、苦手な教科があるだろうか？ 社会が苦手キュルン。 テストの結果はどうだった？ 特に悪かったキュルン……。 テストの結果から社会が特に苦手だということが客観的にも分かる状況であるな。 このケースでは、テストの結果が良くないところを重点的に勉強して、次のテストで結果を出せばいい。 キュルキュルン！ 良くないところをピンポイントで良くしていく、テストの結果が品質改善のきっかけになるキュルンね～！ (3)高橋寿一さんのソフトウェアテスト 興味深い話をしているね 寿一さんにとって、ソフトウェアテストとはどういうものキュルン？ なくてはならないものだね。 そうだな……例えば、 品質マネジメント は 品質保証と品質コントロール に分類されるが、テストが密接に関わっている。 どちらの視点でソフトウェアテストを捉えるかでも議論の余地はあるね。 ぱなもくんだと……例えば、テスターとしてのテストは、製品の良くない事象（不具合）を見つけて、開発者に報告するだろう。そして、修正された製品に良くない事象がなくなっていることを確認し、製品の品質コントロールを手助けしていくことも多いだろう。 その通りキュルン この場合のソフトウェアテストとは、 プロダクト（製品）とその関係者をより良い方向に支援していく仕事 といったところだろうか。 Steve McConnellもいうように、テストはプロダクト（製品）とその関係者双方の品質改善を担うと考えている。 すごい仕事キュルン！！ すごい仕事だよ。 例えば、Glenford J Myersは以下のように言ってるね。 「テストとは、非常に創造的であり、知的に挑戦しがいのある仕事である」 ＜出典＞ ソフトウェア・テストの技法 第2版 Glenford J.Myers テストの仕事は、やりがいでいっぱいキュルン！ ははは、ソフトウェアテストで学ぶべきことはまだまだあるからね。応援しているよ。 (4)まとめ 章 説明 (1)ニャックスのソフトウェアテスト ソフトウェアテストは、答えが一つでない場合がある。もっと不確実性があり、創造的なもの。 (2)ニャックスのソフトウェアテスト ソフトウェアテストは、価値観の違いが生む人のすれ違いを減らす活動 (3)高橋寿一さんのソフトウェアテスト ソフトウェアテストとは、プロダクト（製品）とその関係者をより良い方向に支援していく仕事 出典先 説明 書籍 根岸雅史 ※学校のテスト 「妥当性」とは，「測ろうとしている能力をテストが測っているか」を表し，「信頼性」とは「測ろうとしている能力を安定して測っているか」を表している。これらの概念の大前提は，テストでは何らかの「能力」を測ろうとしているということである。 三省堂 TEACHING ENGLISH NOW vol.27 JSTQB用語集テスト(testing) すべてのライフサイクルを通じて実行する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価すること ISTQB公式 Steve McConnell ソフトウェアテストは、もっともポピュラーな品質改善方法である 知識ゼロから学ぶソフトウェアテスト【改訂版】 高橋寿一 Glenford J.Myers テストとは、非常に創造的であり、知的に挑戦しがいのある仕事である ソフトウェア・テストの技法 第2版 悩みは解決できたか？ 大丈夫キュルン！ これからは、もっと自信を持って話すキュルン♪ 良かった。 不安があればまた聞いてくれ。 本記事では、「ソフトウェアテストとは」というテーマに沿って、様々な表現や解釈があるということをご紹介いたしました。 今回内容に含まれなかった「 市場に出回った不具合による損失 」というものがあります。 JSTQB_FLシラバスでは、これらの損失を「(1)経済的な損失」「(2)時間の浪費」「(3)信用の失墜」「(4)障害や死亡事故」として取り上げています。このように 損失 や リスク といった視点からも、テストの有効性を証明することが可能です。 本記事を通して、ソフトウェアテストのやりがいを少しでもお伝えできていましたら幸いです。 Sqriptsでは、ソフトウェアテストに関する技術や考え方をお役立ち資料で紹介しています。本記事の詳しい内容については こちら からダウンロードいただけます。 The post テストの基礎１～ソフトウェアテストとは？～ first appeared on Sqripts .