こんにちは。自動テストエンジニアのおすしです。 2023年8月にLogiGear社の自動テストツール「TestArchitect」がモバイルアプリのテストに対応しました。今回はこの機能の概要を紹介します。 TestArchitectとは 「 TestArchitect 」はAGESTのグループ会社であるLogiGear社が開発した自動テストツールです。10年以上の運用実績があります。当初は特定の顧客の要望に沿って開発されたオンデマンドツールでしたが、機能追加と改善を繰り返して汎用性の高い製品に進化しました。現在も積極的に開発が進められています。 2023年8月にモバイルネイティブアプリのテスト機能が追加( v9.3 )されたことで、数ある自動テストツールの中でも対応できるテスト範囲が広いツールとなりました。レコード機能を利用した簡単な自動テストから、ほかツールとの連携やスクリプトを利用した複雑な自動テストまで作成できる適用範囲の広いツールです。 TestArchitectの特徴 TestArchitectのメリット キーワード駆動と豊富な組み込みアクションで実装とメンテナンスにかかるコストが少なく、テストコードの可読性が高いためレビューのコストも減らせるというメリットがあります。テスト対象がWindowsネイティブアプリ、ブラウザの他、モバイルネイティブアプリ（Androidアプリ/iOSアプリ）にも対応しているため、他の自動テストツールと比べても幅広い開発チームで利用可能です。 動作環境 TestArchitectはWindows PCで動作します。 Windows 10,11 ※その他動作環境は自動化対象や連携するツールによって異なります。詳しくは公式ドキュメント「 Supported platforms 」をご参照下さい。 テスト対象 Webブラウザ（Chrome、Edge、Firefox、IE） Windowsネイティブアプリ Androidネイティブアプリ iOSネイティブアプリ 主な機能 キーワード駆動型テスト TestArchitectはキーワード駆動型テストを採用しています。操作内容がシンプルなキーワードで記述できるため可読性が高いテストを作成できます。また、テストの修正も容易になるという利点があります。 レコード機能 操作した内容を記録してテストコードとして利用できるため、誰でも簡単にテストが作成できます。記録したテストは簡潔なUIで表示され編集も容易です。 ※v9.3では、Webブラウザ、Windowsアプリテストがレコード機能に対応しています。モバイルアプリテストについても開発中です。 あらゆる操作に対応するアクション TestArchitectは 膨大なアクション が定義されています。テストで必要な操作はこれらのアクションを組み合わせることで実現可能です。ユーザーが自分で開発する必要はありません。 プログラミング言語が利用可能 テストはプログラミング言語でカスタマイズすることも可能です。既にプログラミング言語で実装したテストがある場合、それをTestArchitectのテストに組み込むこともできます。 利用可能言語 Java Python C# その他、画像認識機能、他社ツールとの連携機能、自社端末を利用可能、DBと連携したデータ駆動型テストができるなど、様々なオーダーに対応できる機能を備えています。 モバイルアプリテスト機能 テスト環境の構成図 TestArchitectのモバイルアプリテスト機能はAppiumサーバーを利用して動作します。手持ちの端末のほか、Remote TestKitなどの端末クラウドサービスも利用可能です。 Appiumサーバーを介して操作するため、iOS端末をテストする場合はXcodeをインストールしたMacが必要です。 作成できるテストの例 TestArchitectはAndroidとiOSを交互に操作したり、複数の端末を切り替えながら操作することができます。AndroidとiOSで音声通話を行うテストや、3端末以上でメッセージのやり取りをするテストなどを実装することができます。このような複雑な操作でも組み込みアクションが用意されているためコーディングの必要はありません。 また、モバイルアプリ、Windowsブラウザ、Windowsアプリなどを切り替えて操作するクロスプラットフォームテストも作成できます。モバイルアプリで登録した情報をWindowsのデータベースアプリで確認する、といったテストも作成可能です。 テスト作成の手順 iOS端末で写真を撮影するテストを作成する手順を紹介します。 端末への接続 TestArchitectの「インタフェースビューワー」機能に接続する端末の情報を入力して「接続」ボタンをクリックします。 要素の取得 ミラー画面上で取得したい対象をクリックすると要素のプロパティが表示されます。要素の検出に利用したいプロパティにチェックをいれて保存するだけで取得が可能です。 保存ボタンを押すと、TestArchitectのインターフェースに取得した要素が表示されます。 テストコードの作成 組み込みアクションと取得した要素を利用してテストを作成します。ExcelライクなUIであるため、スクリプト言語で作成したテストケースよりも分かりやすいテストコードを作成できます。要素の名前には英数字以外に日本語が利用可能です。 テストの実行と結果レポート 「インタフェースビューワー」を利用した時と同様に接続先の端末情報を入力するだけで実行できます。 テスト結果レポートはhtml形式で出力されます。失敗時だけではなく、操作毎にスクリーンショットを自動的に撮影するように設定することができます。それらのスクリーンショットは操作箇所が赤い丸で囲まれ、確認箇所は赤い枠で囲まれています。テストの内容が分かりやすく、結果の確認をスムーズに行うことが可能です。 ・カメラアプリをtapする前後でスクリーンショットを撮影した場合のレポート ・操作や確認箇所は赤い〇などで明示されます。 使用感 私はAppiumとプログラミング言語のPythonを利用してフルスクラッチの自動テストを作成した経験があります。それと比較すると、TestArchitectを利用した自動テストには多くのメリットがあると思います。 テストコードが速く作成できる フルスクラッチで実装したときはAppium Inspectorで要素を取得してコピペでコードに張り付ける作業を何回も繰り返す必要がありましたが、TestArchitectはインターフェースビューワーでスマホのミラー画面をクリックするだけでインターフェース定義に出力できます。テストコードについても既にほとんどのアクションが準備されているため、それを呼び出すだけで終わります。アクションの使い方はF1キーを押すだけでTestArchitectから該当のアクションを解説した公式ドキュメントに遷移できます。探す必要はありません。フルスクラッチのコーディングよりもかなり速くテストコードが作成できます。 ただ、アクションが膨大にあるため、慣れるまでは使いたいアクションを探すのに時間がかかります。 テストコードが読みやすい 私はコードの羅列とインデントによる区別に慣れていたので、TestArchitectのExcelみたいな見た目はちょっと…と思っていましたが実際に使ってみるとかなり読みやすい印象です。さらにアクションやインターフェースに日本語名を使うと内容が一目で分かります。自動テストの実装担当者やレビュアーにはエンジニアではないメンバーが含まれる場合があるため、コードが読みやすい点はメリットがあると思います。 テスト実行が簡単 実行するテストケース、実行対象の環境（端末などの接続先）を指定したテスト実行用のバッチファイルをワンクリックで作成できる機能がとても便利です。テストスイートやテスト端末毎に作成しておくと必要なテストをすぐに実行することができます。Jenkinsなどの外部ツールで定期実行するといったCI/CDに組み込むことも簡単です。 プログラミング言語が利用可能 TestArchitectはJavaやPythonといったライブラリが充実しているプログラミング言語で拡張できるため、公式のサポートがないツールを連携させたり、かなり特殊な処理でも自動テストに組み込むことができます。他のテスト自動化ツールの多くは対応している言語がJavaScriptのみであったり、限定された範囲でしか利用できないといった制約があります。いざとなったらコードを書ける点は自動テストエンジニアとして安心できる機能だと思います。 おわりに TestArchitectのモバイルテスト機能は、Appiumとプログラミング言語を利用したテストと比較すると簡単にかつ速く作成ができ、修正にかかる工数も少なく済みます。操作が容易である一方で、自動テストツールの中でも多機能かつ拡張性が高いという特徴があります。 TestArchitectはFreeライセンスを提供しています。自動テストツールを探している方はぜひお試しください。 https://www.testarchitect.com/ AGESTではTestArchitectの導入を考えている方、少しでも興味がある方に向けて説明会を実施しています。お気軽にお問い合わせ下さい。 The post TestArchitectモバイルテスト機能の紹介 first appeared on Sqripts .

こんにちは、バックエンドエンジニアのまるです。 この記事では、Protocol BuffersのLinterの一つである Buf を使ったLintついて、実践例とともにご紹介します。 Protocol Buffersとは Protocol Buffersは、Googleが開発したバイナリデータのシリアライズ形式です。データ記述形式の一種なのでJSONやXMLと比較されることもありますが、ProtocolBufferはバイナリ形式で保存されるため、JSONやXML形式などのテキストベースの形式よりもデータサイズが小さく、より高速にデータ転送ができます。 Protocol Buffersは、Googleが開発したRPCフレームワークである gRPC に使われています。Protocol BuffersとgRPCの関係は、JSONとHTTP通信の関係によく似ています。HTTP通信がデータ記述形式としてJSONを使用するように、gRPCはProtocolBufferを使用して通信を行います。 Bufとその他のLinterの比較 我々のプロジェクトでは、初めはProtocol BufferのLinterとして Google API Linter を採用していました。Protocol BuffersがGoogle製なので、LinterもGoogle製のものを使えば安心だろうと考えていたためです。 しかし、Google API Linterのルールはいささか厳しすぎたため、プロジェクトのシステム構成の見直しのタイミングでLinterの選定を見直すことになりました。再選定の際に決めた要件は以下の3つです。 最近まで更新がある（開発が止まっていない） 個人開発でない（今後も更新が続けられる可能性が高い） Lintのルールが厳しすぎない 検討したLinterは以下の通りです。 prototool 直近の更新が2020年と古く、公式の発言を見ても今後アップデートされる可能性が低い。 protolint 個人開発である点が不安。 Buf prototoolの後継にあたる。更新頻度は高く、ルールも問題ない。 これらのLinterを使って軽くPoCを行い、最終的にはすべての要件を満たしていたBufを採用しました。 .protoファイルの準備 ここから、実際にBufを使ったlintの例をご紹介します。 Bufをインストールする前に、まずはLint対象の.protoファイルを用意しましょう。今回は、以下のような簡単な.protoファイル（book.proto）を使います。 書籍データを作成するCreateBookと、書籍データを取得するGetBookという2つのメソッドがあります。この2つのメソッドのResponseは共通のメッセージ型（Book）を使用しています。 syntax = "proto3"; package book.v1; service BookService { rpc CreateBook(CreateBookRequest) returns (Book); rpc GetBook(GetBookRequest) returns (Book); } message Book { string id = 1; string title = 2; string author = 3; int32 pages = 4; } message CreateBookRequest { string title = 1; string author = 2; int32 pages = 3; } message GetBookRequest { string id = 1; } 以下のようなディレクトリ構成にして、v1の下にbook.protoを置きましょう。 sample-project └── pb-proto └── book └── v1 └── book.proto これで準備完了です。 Bufのインストールとセットアップ 次に、Buf CLIをインストールします。 $ brew install bufbuild/buf/buf Homebrew以外のインストール方法については、公式の インストールガイド を参照してください。 buf CLIのインストールが終わったら、Lintのためのセットアップをします。プロジェクト直下に以下のような内容の buf.work.yaml を作成しましょう。 directories にはpb-protoを指定します。 version: v1 directories: - pb-proto 最後に以下のコマンドを実行します。これにより、  buf.yaml  がpb-protoディレクトリに生成されます。 cd pb-proto buf mod init 最終的なディレクトリ構成が以下のようになっていたら成功です。 sample-project ├── buf.work.yaml └── pb-proto ├── buf.yaml └── book └── v1 └── book.proto BufをつかったLint さっそくBufを使ってbook.protoをLintしてみましょう。 $ buf lint ./book/v1/book.proto 出力を見てみると、いくつかLintエラーが出ていることが分かります。 pb-proto/book/v1/book.proto:5:3:"book.v1.Book" is used as the request or response type for multiple RPCs. pb-proto/book/v1/book.proto:5:46:RPC response type "Book" should be named "CreateBookResponse" or "BookServiceCreateBookResponse". pb-proto/book/v1/book.proto:6:3:"book.v1.Book" is used as the request or response type for multiple RPCs. pb-proto/book/v1/book.proto:6:40:RPC response type "Book" should be named "GetBookResponse" or "BookServiceGetBookResponse". 1つ目と3つ目は、「 Book というメッセ―ジ型が複数のRPCで使われている」ために生じたエラーです。 Bufの公式の Configuration and options ページには、以下のような記述があります。 最新の Protobuf 開発において最も重要なルールの 1 つは、すべての RPC に対して一意のリクエストメッセージとレスポンスメッセージを持つことです。複数のRPC間でProtobufメッセージを共有すると、このProtobufメッセージのフィールドが変更されたときに複数のRPCが影響を受けることになります。（筆者翻訳） Configuration and options 要は「メッセージ型を使いまわすな」ということを言っていますね。どのような名称に変更するべきかは2行目と4行目を参考にすればよいです。 修正後のbook.protoは以下のようになります。 syntax = "proto3"; package book.v1; service BookService { rpc CreateBook(CreateBookRequest) returns (CreateBookResponse); rpc GetBook(GetBookRequest) returns (GetBookResponse); } message CreateBookRequest { string title = 1; string author = 2; int32 pages = 3; } message CreateBookResponse { string id = 1; string title = 2; string author = 3; int32 pages = 4; } message GetBookRequest { string book_id = 1; } message GetBookResponse { string id = 1; string title = 2; string author = 3; int32 pages = 4; } もう一度Lintをかけてみると、エラーが出なくなったことが分かると思います。 開発の都合で無効化したいルールがある場合は、buf.yamlに except の段落を作って無効化したいルール名を指定するとよいです。 以下が RPC_RESPONSE_STANDARD_NAME と RPC_REQUEST_RESPONSE_UNIQUE を無効化したbuf.yamlの例です。 version: v1 breaking: use: - FILE lint: use: - DEFAULT except: - RPC_RESPONSE_STANDARD_NAME - RPC_REQUEST_RESPONSE_UNIQUE こうすると、修正前のbook.protoでもLintが通ります。他のルールの名称については公式ページの Rules and categories を参照してください。 終わりに Bufを使ってProtocol BufferをLintする方法をご紹介しました。BufはLint機能を使うだけなら非常にシンプルで、学習コストがかからないと思います。 この記事がみなさんのお役に立てば幸いです。 The post Protocol BuffersのLintチェック入門: Bufを使った実践ガイド first appeared on Sqripts .

本連載では、ブロックチェーンの基本的な仕組みを解説しながら、オンチェーンデータを分析するための基本的な手法について、全8回で紹介します。 第6回の今回は、引き続きオンチェーンデータのオンライン分析サービスのDune（ https://dune.com/ ）を用いて、Ethereumを対象としたデータ分析の演習を始めていきます。 Raw Blockchain Dataの確認 Duneの提供するデータテーブルには、第5回の記事でもご紹介した通り、Decoded projectsやSpellsなどの分析のために加工された便利なデータテーブルが揃っています。しかし今回は、ブロックチェーンの基本的なデータ構造を理解するためにも、ブロックチェーンの生のデータに近いRaw Blockchain Dataを中心に取り扱ってみましょう。 EVM Raw Table Data Duneでは、BitcoinやEthereumをはじめ、Polygon、Optimism、BNB Chainなど、さまざまなブロックチェーンのデータを提供しています。このうち、BitcoinやSolanaなどの少数の例外を除き、ほとんどのブロックチェーンはEthereum Virtual Machine(EVM)と呼ばれる仮想マシンを利用しています。 Ethereumのクライアントプログラムにはいくつかの実装が存在しますが、すべてのクライアントが同じEVMの仕様に準拠することで、実装の違いを気にすることなく同じスマートコントラクトを実行して同じ結果を得ることができます。また、Ethereum以外のブロックチェーンであっても、EVMの仕様に準拠しているチェーンであれば、Ethereum用に実装されたスマートコントラクトを動かすことができます。 スマートコントラクトを実行可能なブロックチェーンは数多く存在しますが、その中でもEVMと互換性のあるチェーンがデファクトスタンダードとなっているため、まずはEthereum(EVM)のデータ構造に慣れておくと汎用性が高まります。 BlocksとTransactions 第3回の記事 でもご紹介したとおり、多くのブロックチェーンはブロックとトランザクションというデータ構造を持っています。 Ethereumにおけるブロックとトランザクションの生データは、Dune上ではそれぞれ「ethereum.blocks」「ethereum.transactions」というテーブル名で参照できます。 下記のコード1.をDuneのクエリエディタに記載し、RunをクリックしてEthereumのブロックデータを10件取得してみましょう。FROM句に欲しいデータのテーブル名を指定し、SELECT句に欲しいカラム名を列挙します。すべてのカラムを取得したい場合は「＊」を利用できます。また、すべてのデータを取得するのは非常に時間がかかる可能性があるため、LIMIT句で取得するデータの件数を指定する癖をつけておくと安心です。 コード1 . Ethereumのブロックデータを10件取得するクエリ SELECT *FROM ethereum.blocksLIMIT 10 無事に実行が終了すると、図1のようなクエリ結果画面が表示されます。なお、SQLにおけるテーブルは、表計算ソフトにおけるテーブルとは異なり、順序を持たないデータの集合ですので、取得される10件のデータは実行ごとに異なるものが取得される可能性があります。今回の実行結果では、2015年9月12日のタイムスタンプが付与された、ブロック番号「224095」のデータが1件目に取得されています。 図1. ethereum.blocksテーブルのサンプルデータ Duneで取得したデータが正しいかどうか、Etherscan（ https://etherscan.io/ ）のサイトでも確認してみましょう。Etherscanの検索窓にブロック番号を入力して検索すると、該当ブロックの詳細情報を記載したページが閲覧できます。 図2 . ブロック番号「224095」の詳細情報（ https://etherscan.io/block/224095 ） 図1と図2を比較してみて、TimestampやDifficultyなど、基本的な情報が一致していることを確認してみてください。 データ加工のためのSQL 上記のブロックデータを対象として、SQLを用いた簡単なデータ加工の演習をしてみましょう。 SQLにおけるデータ加工のための演算は、大きく分けて数値や文字列などのスカラ値を対象とした演算と、データの集合であるテーブル（リレーション）を対象とした演算が存在します。両者について具体例を確認してみましょう。 値を対象とした演算 図1で示したクエリの出力結果のうち、タイムスタンプを表す「2015-09-12 17:04」といったデータや、ブロック番号を表す「224095」といったデータに対して、SQLを用いて好きな加工を施すことができます。特に、ブロックチェーンのデータの多くはタイムスタンプを付与された時系列データですので、タイムスタンプを分析しやすい形に加工する機会が多くあります。 コード2に、タイムスタンプを取り扱う典型的な関数の記載例を示します。yearやmonthといった関数は、タイムスタンプから特定の要素を抽出する関数です。date_trunc関数は、タイムスタンプを指定した桁で切り捨てた値を取得する関数で、日次や週次でのデータ集計を実施したい場合によく用いられます。format_datetime関数はJavaの時刻関数ですが、Dune SQLではこのようなSQL標準には存在しないものの有用な関数も多く対応が行われています。 Dune SQLでどのような関数が実装されているかは、公式のドキュメント（ https://dune.com/docs/query/DuneSQL-reference/Functions-and-operators/ ）を参照してください。 コード2 . タイムスタンプを加工する関数例 SELECT time, year(time), month(time), day(time), date_trunc('day', time), date_trunc('week', time), format_datetime(time, 'MMM-dd-yyyy KK:mm:ss a +z'), number FROM ethereum.blocks WHERE number = 224095 LIMIT 10 図3. 「コード2」の実行結果例 SQLにおける値を対象とした演算の注意点として、対象テーブルに含まれるすべてのレコードのカラムに対して、同じ演算が適用される点に注意してください。例えば、100件のデータが存在した場合に、一般的な手続き型のプログラミング言語では、for文などのループ構文を用いて、1件ずつ演算を適用していくことが多いと思います。一方、SQLは集合演算を基本としているため、ループ構文などは存在せず、100件のデータすべてに必ず同じ演算が適用されることになります。 また、値を対象とした演算では、入力したテーブルに含まれるレコード数と、出力されるレコード数は必ず一致することにも注意してください。100件のレコードを含むテーブルに対して値を変更する演算を実行した場合、出力結果のレコード数も必ず100件となっています。 もし、期待している分析結果がレコード数の増減を伴うようなものであれば、次のテーブルを対象とした演算が必要です。 テーブルを対象とした演算 集合演算としてのSQLを使いこなすためには、テーブルに対して演算をおこなって別のテーブルを作成する、というイメージを持つことが重要です。 集合演算としてのSQLを体験する前準備として、さきほど示したdate_trunc関数を用いて、タイムスタンプを日付で切り落としした一時データを作成してみます。コード3では、date_truncの計算結果カラムに対して、AS句を用いて「day」という名前を付けています。コード2のような書き方では、出力結果のカラムが「_col1」「_col2」といったデフォルトの連番名となっていましたが、これらに分かりやすい名前をつけることで、分析の見通しやクエリの再利用性が向上します。 また、取得するレコードの条件をWHERE句で指定し、レコードの絞り込みをおこなっています。WHERE句の次に指定した式がTRUEとなるレコードだけが出力結果に表示されます。「timestamp ‘2023-01-01 00:00:00’ <= time」という条件式は、’2023-01-01 00:00:00’という文字列をtimestamp型に変換し、timeカラムの値と比較している式です。 コード3 . date_trunc関数を用いた前処理 SELECT time, date_trunc('day', time) AS day, number, size FROM ethereum.blocks WHERE timestamp '2023-01-01 00:00:00' <= time 図4 . 「コード3」の実行結果例 図4に示したとおり、タイムスタンプから時刻情報が切り落とされ、日付情報を示すdayカラムを持ったサンプルレコードを取得することができました。 このサンプルレコードを対象として、日付ごとにどれくらいのブロックが生成されているかを集計するクエリを記述してみましょう。 まず、テーブルに対して演算を適用することをイメージするために、コード4のような書き換えをおこなってみてください。コード3に限らず、すべてのSELECT文の出力結果はテーブル（リレーション）の形式をしているので、その出力結果をFROM句に指定して、さらに別のSELECT文を記述することが可能です。コード4の実行結果は、図4で示したコード3の実行結果と同じです。 コード4 . 「コード3」のSELECT文をFROM句に指定したクエリ SELECT * FROM ( SELECT time, date_trunc('day', time) AS day, number, size FROM ethereum.blocks WHERE timestamp '2023-01-01 00:00:00' <= time ) 集約関数 テーブルを対象とした演算として代表的なものに、集約関数と呼ばれる関数群があります。コード5は、コード3の出力結果のテーブルに対して、集約関数であるcount, max, min関数を適用したクエリです。 コード5 . 「コード3」の出力結果に集約関数を適用したクエリ SELECT count(1), max(day), min(day) FROM ( SELECT time, date_trunc('day', time) AS day, number, size FROM ethereum.blocks WHERE timestamp '2023-01-01 00:00:00' <= time ) 図5 . 「コード5」の実行結果例 コード5の計算結果は、FROM句で指定したテーブルに含まれるレコード数、dayカラムの最大値と最小値を示しています。ここで、出力結果のテーブルのレコード数が1件となっていることに注意してください。テーブルを対象とした演算は、値を対象とした演算と異なり、入力テーブルのレコード数と出力テーブルのレコード数は必ずしも一致しません。 GROUP BY句 集約関数をGROUP BY句と組み合わせて使うことで、集約をおこなう粒度を指定することができます。GROUP BY dayと指定することで、dayが同じ値を持つレコード群を単位として集約関数を適用し、dayをキーとした新たなテーブルが生成されています。なお、計算結果の表示順はデフォルトでは不定のため、ORDER BY句を用いることでソートして表示することができます。 コード6 . 日付ごとにブロック数をカウントするクエリ SELECT day, count(1) FROM ( SELECT time, date_trunc('day', time) AS day, number, size FROM ethereum.blocks WHERE timestamp '2023-01-01 00:00:00' <= time ) GROUP BY day ORDER BY day 図6 . 「コード6」の実行結果例 WITH句（共通テーブル式） 任意のSELECT文の結果はFROM句に指定して新たなSELECT文への入力として指定できますが、多くのSELECT文がネストしたクエリは可読性が下がる可能性があります。 WITH句を用いた共通テーブル式という構文を用いると、SELECT文の結果に一時的なテーブル名を付与することができ、一連のクエリのなかで再利用ができるようになります。 コード7は、コード3のSELECT文の結果にtmpという名前を付け、WITH句を用いて共通テーブル式化したクエリです。出力結果はコード6と同様になります。 コード7 . WITH句を用いた「コード6」の書き換え WITH tmp AS ( SELECT time, date_trunc('day', time) AS day, number, size FROM ethereum.blocks WHERE timestamp '2023-01-01 00:00:00' <= time ) SELECT day, count(1) FROM tmp GROUP BY day ORDER BY day JOIN句 テーブルを対象とした演算には、レコードをフィルタしたり集約したりするWHERE句や集約関数とは逆に、複数のテーブルを組み合わせてレコード数やカラムを増加させる演算も存在します。 上記のblocksテーブルに含まれる情報だけでは、ブロックに含まれるトランザクション数などを把握することができませんでした。ブロックごとのトランザクション数の集計は、transactionsテーブルを用いて計算できます。transactionsテーブルの計算結果と、blocksテーブルのカラム情報を組み合わせて結果に表示させたい場合は、複数のテーブルを指定したキーで結合するJOIN句が利用できます。 コード8は、WITH句による共通テーブル式で、トランザクション数を集計したtx_countテーブルを作成し、blocksテーブルのnumberカラムと、tx_countテーブルのblock_numberカラムとをキーにして結合したクエリです。 コード8 . ブロックに含まれるトランザクション数の集計クエリ WITH tx_count AS ( SELECT block_number, COUNT(1) AS tx_count FROM ethereum.transactions GROUP BY block_number ) SELECT number, time, miner, difficulty, tx_count FROM ethereum.blocks AS b JOIN tx_count AS t ON b.number = t.block_number ORDER BY b.number DESC LIMIT 10 図7. 「コード8」の実行結果例 次回予告 今回の記事では、ブロックチェーンの基本的なデータ構造であるブロックやトランザクションのテーブルをサンプルとして、データ分析で役立つSQLの基本的な構文や、SQL特有の思考方法について紹介しました。次回記事では、EVMのデータ構造の深掘りや、発展的なSQLの構文について解説しながら、オンチェーンデータ分析の演習を進める予定です。 連載一覧 【第1回】ブロックチェーンとは 【第2回】ビットコインの仕組み 【第3回】イーサリアムの仕組み 【第4回】ビッグデータ分析のためのSQL基礎 【第5回】Ethereumデータ分析演習 1 The post 【第6回】Ethereumデータ分析演習2 first appeared on Sqripts .

こんにちは。 エンジニアの nobushi です。 RDBを扱うWebアプリケーションを構築しているとRDBのレプリケーション環境を必要とすることもあると思います。 アプリケーション側で対応が必要なのでできれば開発を行うローカル環境の段階で導入したいところです。 そこで今回は手軽にローカルのdocker-composeでRDBのレプリケーション環境を構築してみたいと思います。 使用するRDBは PostgreSQL です。 ついでに検証用に pgAdmin も導入してみます。 導入 docker-compose が使える環境で、任意のディレクトリに以下のファイルを配置して / db_primary/ init.sh pg_hba.conf db_read_replica/ entrypoint.sh docker-compose.yml 配置したディレクトリで起動してください。 docker compose up -d docker-compose.yml services: db_primary: image: postgres:14.8 command: -c "hba_file=/etc/postgresql/pg_hba.conf" environment: - POSTGRES_PASSWORD=hoge - POSTGRES_DB=main volumes: - db_primary_data:/var/lib/postgresql/data - ./db_primary/pg_hba.conf:/etc/postgresql/pg_hba.conf - ./db_primary/init.sh:/docker-entrypoint-initdb.d/init.sh healthcheck: test: ["CMD", "pg_isready", "-U", "postgres"] db_read_replica: image: postgres:14.8 entrypoint: /etc/postgresql/entrypoint.sh volumes: - db_read_replica_data:/var/lib/postgresql/data - ./db_read_replica/entrypoint.sh:/etc/postgresql/entrypoint.sh healthcheck: test: ["CMD", "pg_isready", "-U", "postgres"] depends_on: db_primary: condition: service_healthy pgadmin: image: dpage/pgadmin4:7.3 volumes: - pgadmin_data:/var/lib/pgadmin environment: - PGADMIN_DEFAULT_EMAIL=johndoe@example.com - PGADMIN_DEFAULT_PASSWORD=johndoe ports: - 50080:80 volumes: db_primary_data: driver: local db_read_replica_data: driver: local pgadmin_data: driver: local 構成はPostgreSQLのインスタンスがプライマリ、レプリカでそれぞれ一つ、 pgAdminが一つです。 またそれらのデータ保持用のボリュームを定義しています。 db_primary/init.sh #!/bin/sh -xeu psql -v ON_ERROR_STOP=1 <<- _EOT_ CREATE USER replicator WITH REPLICATION; SELECT pg_create_physical_replication_slot('my_replication_slot'); _EOT_ db_primary/pg_hba.conf local all all trust host all all 127.0.0.1/32 trust host all all ::1/128 trust local replication all trust host replication all 127.0.0.1/32 trust host replication all ::1/128 trust host replication replicator 0.0.0.0/0 trust host all all all scram-sha-256 db_read_replica/entrypoint.sh #!/bin/sh -xeu pg_basebackup \\ -h db_primary \\ -D ${PGDATA} \\ -S my_replication_slot \\ -X stream \\ -U replicator \\ -R || true /usr/local/bin/docker-entrypoint.sh postgres プライマリDB プライマリDBで必要なことは以下の3点です。 レプリケーションスロットの作成 レプリケーションユーザーの作成 レプリケーションユーザーの認証設定 レプリケーションスロットの作成 レプリケーション接続を行うためのレプリケーションスロットを作成します。 init.sh で行っています。 SELECT pg_create_physical_replication_slot('my_replication_slot'); レプリケーションユーザーの作成 レプリカ側からの接続用にユーザーを作成します。 init.sh で行っています。 CREATE USER replicator WITH REPLICATION; このサンプルではセキュリティは気にしないのでパスワードは設定しません。 レプリケーションユーザーの認証設定 pg_hba.conf は認証設定ファイルです。 デフォルトの pg_hba.conf は /var/lib/postgresql/data/pg_hba.conf にありますので、それをベースにして以下の設定を追加しています。 host replication replicator 0.0.0.0/0 trust この設定により replicator ユーザーのレプリケーション接続は接続元に関係なくパスワード不要となります。 本サンプルはローカルの環境用ですので簡易的に設定します。 db_primaryの設定 使用する pg_hba.conf を変更するためにコマンドを設定しています。 command: -c "hba_file=/etc/postgresql/pg_hba.conf" また、ファイルを差し替えるためにvolumeを設定しています。 - ./db_primary/pg_hba.conf:/etc/postgresql/pg_hba.conf - ./db_primary/init.sh:/docker-entrypoint-initdb.d/init.sh レプリカDB レプリカDBでは pg_basebackup を使用してレプリケーションを作成します。 pg_basebackup はPostgreSQLの起動前に実行し、 PostgreSQLの起動時にはレプリケーションDBが既に生成されているように制御する必要があります。 そのためにENTRYPOINTを差し替えて、 従来のENTRYPOINTの前に pg_basebackup を実行するようにしたのが entrypoint.sh です。 pg_basebackup の引数はプライマリDBの設定内容に合わせたものです。 また、2回目以降の起動時にはすでにデータがあるため pg_basebackup がエラー終了します。 その場合はエラーを無視するように || true をつけています。 pg_basebackup \\ -h db_primary \\ -D ${PGDATA} \\ -S my_replication_slot \\ -X stream \\ -U replicator \\ -R || true また、プライマリDB側が起動した状態でないと起動に失敗するため、 composeでプライマリDBのステータスがHealthyになってから起動するように制御しています depends_on: db_primary: condition: service_healthy pgAdminで検証 ではpgAdminで動作確認してみます。 pgAdminへのアクセスは docker-compose の通りであれば http://127.0.0.1:50080 でアクセス可能なはずです。 login ログイン画面が表示されるので docker-compose の環境変数で設定した以下のメールアドレス、パスワードでログインします。 johndoe@example.com / johndoe 接続 ログインしたら各サーバーへの接続を追加します。 General / Name Connection / Host name Connection / Username Connection / Password db_primary db_primary postgres hoge db_read_replica db_read_replica postgres hoge 検証 この段階でレプリカDB側にも main データベースがある等 プライマリDBと同期していることが分かります。 ではプライマリDBにテーブルを追加してみます。 レプリカDB側にも同期されました。 またレプリカDB側にテーブルを追加しようとするとエラーが発生します。 ERROR: cannot execute CREATE TABLE in a read-only transaction 所感 ローカルでRDBのレプリケーション環境ができればアプリケーションのテスト等やりやすくなると思います。 compose一発で構築可能なのでぜひお試しください。 The post PostgreSQLのレプリケーション環境をDockerで手軽に立ち上げてみる first appeared on Sqripts .

2023年9月26日に帝国ホテルで開催された「Stuart Reid博士来日イベント　特別セミナー／知識ゼロから学ぶAIテスト」に参加してきました。 完璧ではないAIを”どうテストするか？” “AIをどう使うか？”に注目が集まっていますが、完璧ではないAIを”どうテストするか？“についてはほとんど議論がされていません。 AIプロダクトのテストについて、AIテストの第一人者であるStuart Reid博士と西康晴先生をお招きして特別セミナーを開催します。 セミナー概要 今から1年ほど前、2022年の秋までは、生成AIなどで話題になるものはあっても、認知度もそれほど高くなく、現在ほど普及はしていませんでした。 ところが2022年11月、 OpenAI が ChatGPT を発表すると、またたく間に注目を集め、IT業界だけでなく、いわゆる世間一般、教育業界、子供たちにまで認知されるようになりました。 AIは今まさに、急速な拡大期を迎えているといえます。 このAIというもの、「すごい！」と感嘆の声を挙げたくなることも多いのですが、反面、「完璧でない」と感じることが多いのもまた事実です。 ChatGPTを使ったことのある方なら経験があるかもしれませんが、しれっと「間違った答えをさも真実のように」伝えることがあります。 ここが、” AIが完璧ではない “ところです。 完璧ではないAIですが、せっかくの便利なモノなので利用しない手はありません。しかし、利用してみたところでやっぱり完璧でないので「AIの品質」が課題になる。 どのように利用していくのか、はたして利用していけるのか…。 そんなことに頭を悩ませる品質界隈の方々にプレゼントされたのが、本日の特別セミナー「知識ゼロから学ぶAIテスト」です。 まさに「AIの品質」にスポットを当て、エキスパート3名の講演を聞くことができました。 Building Trust in AI through Risk: An Emerging Test Specialism｜Stuart Reid博士講演 まずはStuart Reid博士が登壇されました。 タイトルを直訳すると、 リスクを通じてAIの信頼を築く： 新たなテスト専門分野 となります。 AIテクノロジーの95％は機械学習システム（Machine Lerning System）とのことで、MLSを中心に講演が進みます。 冒頭から一気にひきつけられる内容でした。 （要約） 2022年には92％の企業がAIに投資をし、AIから大きな利益を得られるようになってきています。 市場に大きなインパクトを与え、AIの時代が到来したことを告げています。 しかし、AIには「信頼できない」という問題が依然としてあります。 世界で約半数の人は 「AIの利益はリスクを上回る」 と答えていますが、AIを「 信頼しない 」「 データをAIと共有したくない 」と考える人も38％もいます。（日本やイギリスは「信頼しない」の割合が高い） 一方でイギリスのほぼすべての人がSNSを使用しています。 しかし驚くべきことに、実に45％の人はSNSがAIを使用していることを知らないで使用しています。 AIのメリットを享受していることを知らずに「信頼しない」と答えているということです。 信頼がなければAIは発展していくことができません。 では、信頼を得るためにはどうすればよいのか。 テストをすることです。 テスト業界には大きなチャンスが訪れています。 ここからMLSのリスクと重要性に関するお話になるのですが、講演に先駆けて特別寄稿されている こちらの記事 にも詳しく解説されていますので、ぜひご参照ください。 【日本語】AIのリスクベーステスト/Risk-Based Testing for AI 中でも、「入力データのリスク」では、 「ineffective data governance（非効果的なデータガバナンス）」について、「39％がデータプライバシーは生成AIのリスクであると考えているにも関わらず、このリスクを軽減しようとしているのは20%のみ。 約半分はテストをしていない。テストをせずに公開して利益を得ることを選択している可能性がある」 「開発リスク」では、 「lack of explainability (e.g. selected algorithm is difficult to explain) （説明不足（例：選択したアルゴリズムの説明が難しい））」について、「39％が、生成AIには説明の欠如というリスクがあると考えているにも関わらず、このリスクを軽減しようとしているのはわずか18％」 「開発フレームワークのセキュリティテストについて、53％はリスクがあると考えているのに、軽減を図っているのはわずか38％」 など、MLSのテスト実施割合の低さ、品質の問題点について数値を用いて大変わかりやすく解説していただき、あらためて問題意識を持つことができました。 AI（MLS）独自のテストについてもReid博士の寄稿文に詳しく解説されております。 【日本語】AIのリスクベーステスト/Risk-Based Testing for AI (日本語翻訳版) コーヒーブレイク オフライン開催のセミナーならではのコーヒーブレイクでは、帝国ホテルのサンドイッチとコーヒーで一息。 参加者同士の名刺交換、登壇者と参加者の雑談風景が見られるのも、オフライン開催ならではです。 オンラインに慣れてしまっているこのごろですが、やはりこのような風景はいいですね。 会場を眺めていると、いろいろな雑談や笑い声が聞こえてきて、温かみを感じました。 AIのAIによるAIのためのテスト｜西康晴博士講演 続いては西康晴博士の講演「AIのAIによるAIのためのテスト」です。 時々会場を笑いに包みながら、様々な事例とともにAIテストの具体例を解説してくださいました。 シベリアンハスキーと狼を見分けるAIを作成した。 どのようにシベリアンハスキーと狼を見分けているかというと、顔や鼻、耳を見ているわけではなく、バックグラウンドに雪があるかどうかだけで判断している。 このようなAIを信頼できるか？というお話は大変興味深いものでした。 また、AIのテストにおいては、 ・これまでのテスト技術が使えない ・自動化が必須 ・性能や不具合の因果関係の説明や理解は極めて難しいため、XAI（Explainable AI）（AIの中身を説明できた気になる技術）が大事になる というお話もあり、あらためてAIをテストすることの難しさを感じました。 メタモルフィックテスト AIテストの代表的な一つが「メタモルフィックテスト」であるとし、詳しく解説くださいました。 ・メタモルフィックテストとはAIの間違いを探すことが主 ・判定ミスを起こさせることで、どこで判別しているかがわかる ・テストケース自体をAIで生成するという研究が盛んにおこなわれている ⇒「泳いでいるコアラの画像を入力するとモルモットと判別する」というテストケースを生成する、など 西博士もおっしゃっていましたが、このあたりのテストは発見も多く「面白い」とのこと。 スライドを見ながら講演を聞いているだけでも、大変興味深く面白かったです。 大規模言語モデル（LLM） 続いて大規模言語モデル（LLM：Large Language Models／ChatGPTなど）のバグを見つけるお話がありました。 LLMは人間のように会話しますが、一切知性を持っていない。 「次の単語予測マシーン」にすぎないから、 単語を崩すゲーム をやらせると間違える。 西博士のお話にあった例を、さっそく帰社後にChatGPT（GPT-3.5）で試してみました。 　1.　4桁×4桁の掛け算をやらせるとまず間違える 不正解 。 正解は、1958×5089=9,964,262　です。 続いて単語テスト。 2.　Sで始まりSで終わる単語を教えて 不正解 いい線いってましたが、5番を間違えていました。 もう一つ試してみます。 3.　Pで始まりPで終わる単語を教えて 不正解 これも惜しかったですね。 間違えているにもかかわらず、回答の後に注意事項まで述べてくれるChat-GPTに感謝して実験を終わりたいと思います。 さて、レポートに戻りますが、西博士の講演は、 AIを恐れる必要はありません。 AIを使いこなせる会社が勝ちます。 進む方向はもうわかっています。 どちらに進むかは、みなさんが決めることです。 と締めくくられました。 AIテスト及びシフトライト戦略｜高橋寿一博士講演 続いて高橋寿一博士の講演「AIテスト及びシフトライト戦略」です。 11/16刊行予定！こちらもよろしくお願いします。 AIというのは避けて通れなくなっているが、AIのテストというのは大変だと感じている。 テストの仕方も複雑になっている。 2～3年前まではShift-Leftを唱えてきたが、今はなぜShift-Rightなのか。 というお話しから始まりました。 参考　 いまさら「シフトレフト」について考えてみた Shift-Rightについては、 ・あまり定義はない ・Shift-Leftでやりたいが、できないため仕方なくShift-Right手法をとっている ソフトウェアの巨大化、複雑化に伴い、Shift-Rightを考えていく必要がある時期に来ている。 実際にビルドをして客先に出る直前、もしくは客先に出てからテストをしなければならないということが、今後増えてくるのではないか。 とのことで、品質に携わる方々の仕事は増えていく、Shift-Leftもやらなければならないし、Shift-Rightも増えていくのではないかと予測されていました。 AIのテストについては、 ・答えがないテストと言われている ・基本テストケースが無限大 ・といってもテストケース（データ）がちゃんと作れない そんな中で、まだ完璧なソリューションは持っていないが、なんとか品質を担保していきたいと研究しているところである、というお話しでした。 まとめ 今回のプレミアムセミナーは「知識ゼロから学ぶAIテスト」ということで、専門用語すら怪しかった私ですが、非常にわかりやすく、また興味をそそられる内容でした。 AIを利用した技術はまだまだこれから進歩・進化していきますが、興味を持ってAIと仲良くしていきたいと感じました。 3人の博士には熱く楽しい講演をお聞かせいただき、本当にありがとうございました。 The post 「知識ゼロから学ぶAIテスト」セミナー参加レポート first appeared on Sqripts .

どうもITインフラエンジニアのあっきーです。 普段の業務はお客様先に定期的にお伺いしサーバーやクライアント端末などのメンテナンスやコンサルをしています。 ここ最近は「Windows Server 2012/2012 R2」のマイクロソフトサポートが2023年10月に終了してしまう話題が多くあります。 「Windows Server 2003」から「Windows Server 2012/2012 R2」へリプレイスを行い、現在も稼働しているケースが多いようで、必然的にこのタイミングでのリプレイスが喫緊の課題になっています。 サポート終了後は、マイクロソフトからの新規のセキュリティパッチが提供されなくなります。その為、新たな脆弱性が見つかった場合、その脆弱性を狙った攻撃を防ぐことが難しくなります。また、トラブル時にマイクロソフトのサポートも受けられないため、ビジネスが止まるリスクが高まります。既に「Windows Server 2012/2012 R2」のリプレイスのお話は多く頂いておりますが、その中でも多い相談はActive Directory（アクティブ・ディレクトリ）の移行、ファイルサーバーの移行を含む案件です。 今回はActive Directoryの移行に関してお話させて頂きます。Active Directoryとは、Windows Server 2000から提供が開始された機能で、ネットワークにつないでいるクライアント端末やサーバー、プリンター、アプリケーションなどの情報を収集し、一元管理できるディレクトリサービスです。Active Directoryの歴史は長くなるので今回は割愛いたします（笑）。 では本題に戻ります。Active Directoryを移行する手順はいたるところで紹介されていますが、今回は、Active Directoryが稼働している「Windows Server 2012 R2」から「Windows Server 2019」若しくは「Windows Server 2022」へリプレイスする際に注意が必要な事を紹介します。Active Directoryの移行作業では、お客様へのヒアリング、旧サーバーの調査、初期設定、ネットワーク設定、Active Directory参加等々の作業後、ドメインコントローラー昇格作業に入りますが、稀に下図のようなエラーが発生する事があります。 ADサーバーリプレイス時に考慮して構成されている場合は出ないイレギュラーなエラーですが、「Windows Server 2022」ではSYSVOL共有のレプリケートにDFS-Rを利用しています。新規構築では発生しないのですが、Windows Server 2003頃からActive Directoryを利用していて、バージョンアップしたリプレイスをした際にFRSからDFS-Rに変換していない時に見かけます。ちなみに、FRSとは以前から使用されていたレプリケーションサービスで、「Windows Server 2016」まではサポートされており、Windows Server 2019以降ではサポートされておりません。 💡 Active Directory の SYSVOL レプリケーション方式として、従来ではファイルレプリケーションシステム（FRS：File Replication System）が使われていましたが、ドメイン機能レベル Windows Server 2008 から分散ファイルシステムレプリケーション（DFS-R：Distributed File System Replication）が利用できるようになりました。また、DFS-R へ切り替えることで「SYSVOL 変更情報の差分のみが同期される」、「SYSVOL に変更が発生した場合は即時に同期が行われる」などのメリットがあります。 とうことで、こういうケースの時はドメインコントローラー昇格作業前にActive Directory の SYSVOL レプリケーション方式をFRSからDFS-Rに変換する作業が必要となります。FSRからDFS-Rに変換するには下記変換コマンドを利用します。 【FRS⇒DFS-R変換コマンド】 　dfsrmig.exe /CreateGlobalObjects 　dfsrmig.exe /GetGlobalState 　dfsrmig.exe /GetMigrationState 　dfsrmig /SetGlobalState 1 　dfsrmig /GetMigrationState 　dfsrmig /SetGlobalState 2 　dfsrmig /GetMigrationState 　dfsrmig /SetGlobalState 3 　dfsrmig /GetMigrationState コマンド実行後、問題なくFRSからDFS-Rに変換されたことを確認できれば、ドメインコントローラーの昇格作業が実施できます。その後、ADのマイグレーションを行えばリプレイス完了となります。 今回はActive Directory移行時の注意点として「FRS」と「DFS-R」の話をさせて頂きました。 まだ1年間ぐらいはWindows Server 2012/2012R2のリプレイスは多くあると見ています。最近は全く想定しない手順が必要となるケースはあまりありませんが、同じようなケースのリプレイスや新規構築でも決まった手順通りに進まないイレギュラー手順は発生するものです。当社ではイレギュラーな手順が必要になった時は再現環境を作り、問題を特定して手順確立とナレッジ化を行って対応の品質向上に取り組んでいます。 The post Active Directory移行時の「FRS」と「DFS-R」 first appeared on Sqripts .

はじめに 前回は、自動販売機を題材にして、BDDを用いたプロセスの「定式化(Formulation)」の部分までを説明しました。 今回は、「自動化(Automation)」の部分を説明します。 5. 自動化 前回の記事の「4. レビュー」まで、自動化については一切考えていませんでした。（BDDは自動化が目的ではないと第4回でお伝えした通りです。） ここまできて初めて、自動化について考えます。 今回は、前回作成した以下のGherkin記法のシナリオをインプットにして自動化を行います。 Feature: 自動販売機   Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る     Given 自動販売機がある     When 550 円を入れる     And 120 円の "コーラ" を選択する     Then "コーラ" が出てくる     And 430 円が出てくる 自動化の手順0. BDDのフレームワークを導入する BDDで行うためのフレームワークを導入します。本記事では、 プログラミング言語…Java フレームワーク…Cucumber ビルドツール…Maven で臨みます。 また、IDEはIntelliJを使用しており、「Cucumber for Java」のプラグインがインストール済みです。記事中に載っている画像は全てIntelliJのスクリーンショットであることをご了承ください。 Cucumberの構造を理解する Cucumberは以下の構造を作成して動かします。 Gherkin記法のシナリオとテストコードが分かれているのが、CucumberをはじめとしたBDDフレームワークの特徴です。 これにより、ビジネス関係者はGherkin記法のシナリオを見るだけで、どのような振る舞いを定義しているのか理解することができます。その際に、プログラミング特有のスキルは必要ありません。 CucumberのプロジェクトをCloneする 今回は、 cucumber-java-skeleton のプロジェクトをCloneします。 Cloneの仕方とCucumberの実行の仕方についてはプロジェクトのReadmeをご覧ください。 テストが実行できることを確認する GradleもしくはMavenを用いて、プロジェクトのReadmeに書いてある通りにテストを実行します。 例えばMavenの場合、以下のようにテストが実行できればOKです。初期状態ではテストが失敗するようになっています。 IDE上でフィーチャーファイルのテスト実行できることを確認する GradleもしくはMavenでテスト実行すると、IDEのフィーチャーファイル上でCucumberの実行ができるようになっています。 今回はCloneしたプロジェクトにデフォルトで入っているmaven/src/test/resources/io/cucumber/skeleton/belly.featureのファイルを開いてみましょう。すると、以下の画像のようになっているはずです。 この中で、行番号の1行目もしくは3行目の右側についている三角形2つのアイコンをクリックします。すると、以下のようなウィンドウが出てくるはずです。この中の一番上にある「Run ‘〜〜’」をクリックすると、IDE上でCucumberのテストを実行できます。 実行後、以下の画像のような結果になればOKです。 不要なファイルおよび記述を削除する 実際のプロジェクトを記述する上で以下のファイルは不要なので、削除してください。 maven/src/test/resources/io/cucumber/skeleton/belly.feature maven/src/main/java/io/cucumber/skeleton/Belly.java maven/src/test/java/io/cucumber/skeleton/StepDefinitions.java 以上で、Cucumberを用いてBDDの自動化を行う準備ができました。 自動化の手順1. フィーチャーファイルに記載する 新たにフィーチャーファイルを作成し、前回作成した以下のGherkin記法のシナリオを記載します。今回はmaven/src/test/resources/io.cucumber.vendormachine/vendormachine.featureというファイルを作成しました。 Feature: 自動販売機   Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る     Given 自動販売機がある     When 550 円を入れる     And 120 円の "コーラ" を選択する     Then "コーラ" が出てくる     And 430 円が出てくる 自動化の手順2. フィーチャーファイルを実行し、失敗を確認する 「自動化の手順1」で作成したフィーチャーファイル上で、Cucumberの実行をします。 すると、以下のようにテスト失敗となるはずです。 この時点では失敗している状態が正解となります。なぜならばシナリオを記述しただけで、それぞれのステップに対する実装をしていないためです。 なお、上のテスト失敗時の画像では、以下のようなテスト実行ステータスになっています。 Feature: 自動販売機 Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る Given 自動販売機がある //←テスト失敗 When 550 円を入れる //←実行スキップ And 120 円の "コーラ" を選択する //←実行スキップ Then "コーラ" が出てくる //←実行スキップ And 430 円が出てくる //←実行スキップ Feature: 自動販売機 Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る Given 自動販売機がある //←テスト失敗 When 550 円を入れる //←実行スキップ And 120 円の "コーラ" を選択する //←実行スキップ Then "コーラ" が出てくる //←実行スキップ And 430 円が出てくる //←実行スキップ 自動化の手順3. ステップ定義ファイルを作成し、Givenステップの実装を行う 「自動化の手順1」で作成したフィーチャーファイルを開くと、以下のようになっています。 このうち、4行目から8行目の背景色がついている部分は、コンパイルエラーの状態を示しています。今回の場合、それぞれの行に対応するステップ定義がないためコンパイルエラーとなっています。 そこで、まずは4行目の「Given 自動販売機がある」に対するステップ定義を作成します。 「自動販売機がある」の文章上にカーソルを持っていくと、ヒントとなる豆電球のアイコンが出てきます。 豆電球のアイコンをクリックし、「Create step definition」をクリックします。 すると、ステップ定義ファイルの作成ウィンドウが出てきますので、適当なファイルを作成します。 今回は、ファイル名を「VendorMachineDefinitions」、ファイルパスを「maven/src/test/java/io/cucumber/skeleton」としました。 ウィンドウの「OK」ボタンを押すと、以下の画像のようなmaven/src/test/java/io/cucumber/skeleton/VendorMachineDefinitions.javaファイルが自動作成されるはずです。 ここまで行ったらもう一度、「自動化の手順1」で作成したフィーチャーファイル上で、Cucumberの実行をします。 すると、前回とテスト結果が少し異なっているのが分かるでしょうか。 ステップ定義ファイル作成前のテスト結果 ステップ定義ファイル作成後のテスト結果 ステップ定義ファイル作成前では「自動販売機がある」の部分でテスト失敗になっており「550円を入れる」は実行スキップとなっていました。 一方ステップ定義ファイル作成後では「自動販売機がある」の部分は表示されず、「550円を入れる」の部分でテスト失敗になっています。 これは、「自動販売機がある」の部分のテストが成功しており、次のステップである「550円を入れる」のステップ定義が見つからないためテスト失敗となっていることを示しています。 自動化の手順4. Givenの中身を実装する ステップ定義ファイルおよびメソッドを作成しただけでは、具体的に実装ができていません。そこで、次に中身の実装を行います。 今回の場合、以下の画像のように記述します。現時点ではVendorMachineクラスが無いにもかかわらず、まるで存在しているかのように書くのはTDDを書く時と似ていますね。 この時点ではコンパイルエラーが発生している状態になっていればOKです。 自動化の手順5. コンパイルエラーの解消を行う 「自動化の手順4」で発生していたコンパイルエラーの解消を行っていきます。 今回の場合、maven/src/main/java/io/cucumber/vendormachine/VendorMachine.javaを作成することでコンパイルエラーの解消を行いました。 自動化の手順6. Whenステップの実装を行う 先ほどまでと同様に、今度は「When 550 円を入れる」のステップの実装を行います。 豆電球のアイコンをクリックし、「Create step definition」をクリックします。 今回は先ほどの「Given 自動販売機がある」と同じファイル上にステップ定義の実装を行うため、「VendorMachineDefinitions(io.cucumber.skeleton)」を選択します。 すると、VendorMachineDefinitionsファイルは以下のようになります。（変数名はarg0からinsertedAmountに変更しました） Tips シナリオ記載時に「When 550 円を入れる」と、数値の前後に半角スペースを記載すると、Cucumberが自動的に数値の変数だと判断してくれます。 同様に「Then “コーラ” が出てくる」のように、用語を””で括ると、Cucumberが自動的に文字列の変数だと判断してくれます。 Whenの中身を実装する Givenの時と同様に、TDDのような感覚で実装していきます。今回の場合、以下のようになります。 なお、Givenの時に生成したVendorMachineクラスを活用したいため、Given内のローカル変数だったvendorMachineをフィールド変数に変更しています。 そして、VendorMachineクラス内は以下のように変更します。 以下同様に、ステップ定義と実装を作成していきます。 おわりに 今回は「自動化(Automation)」として、BDDのフレームワークであるCucumberを用いた実装方法を紹介しました。 今回は説明しませんでしたが、BDDとしてのステップ定義を完成させた後は、より細かいテストを書いたり、実装部分のリファクタリングを行っていったりします。 その過程で色々と実装内容を変更することになるとは思いますが、今回のステップ定義を完成させておくことにより、外側の振る舞いは動くことを確認できるという安心感を持って変更することができます。これが、BDDやATDDの良さでもあります。 本連載「TDDとBDD/ATDD」も今回で最終回となります。今回は「自動化(Automation)」というプログラミング部分について説明していきましたが、BDDにおいて何よりも重要なのは「発見(Discovery)」で行うビジネス関係者との協調作業です。自動化のみを行って、Seb Roseに「開発アプローチは少しも BDD にはなっていません。」と言われないようにしましょう。 また、本連載をきっかけにBDDに興味を持った方は、ぜひThe BDD Booksシリーズをお読みいただければと思います。 The BDD Booksシリーズの書籍紹介ページは以下の通りです。 『 The BDD Books – Discovery （邦訳： The BDD Books – Discovery Japanese Edition ）』 『 The BDD Books – Formulation （邦訳：The BDD Books – Formulation Japanese Editionはもうすぐ出版予定）』 『The BDD Books – Automation』はもうすぐ出版予定 それでは、BDDを通じてビジネス関係者と協調しながら、日々の業務を行ってみてください。 連載一覧 TDDとBDD/ATDD(1)　TDDはテスト手法ではない TDDとBDD/ATDD(2)　2種類のBDD TDDとBDD/ATDD(3)　BDDとATDDとSbE TDDとBDD/ATDD(4)　ツールとしてのBDDとプロセスに組み込まれたBDD TDDとBDD/ATDD(5)　BDDのプロセスその1「発見(Discovery)」と実例マッピング TDDとBDD/ATDD(6)　BDDのプロセスその2「定式化(Formulation)」とBRIEFの原則 TDDとBDD/ATDD(7)　BDDのプロセスその3「自動化(Automation)」 The post TDDとBDD/ATDD(7)　BDDのプロセスその3「自動化(Automation)」 first appeared on Sqripts .

はじめまして、QAエンジニアの桜 満開です。 最近よく生成AIという言葉を聞いたり目にしたりすることはありませんか？ 生成AIが実用化されてきている要因としましては、「コンピュータ性能の向上」「コロナ禍による労働環境の変化」「少子化による労働人口の減少」など、様々な要因はあるかとは思いますが、人間の稼働削減の必要に迫られ、この数年で飛躍的に進化を遂げてきている技術です。 ソフトウェアテストにおいても、AI活用によるテストの自動化は試みられており、「生成AIによるテストスクリプトの自動生成」といった活用も行われてきています。 ここまで便利に思える生成AIですが、急速に発展する技術にはそれを正しく利用するために留意しておかないといけないことがあります。 そう、タイトルにもある「著作権」です。 去る令和5年6月19日に文化庁による著作権セミナー「AIと著作権」が開催され、文化庁からの生成AIの利用時における著作権の考え方について、一定の指針が発表されました。 生成AIを利用してコンテンツを生成する場合も、状況によっては著作権の対象となりえる場合があります。 ここでは、セミナーでのポイントを抑えながら、生成AIや著作権について一緒に考えていきたいと思います。 ※本ブログ内容は令和5年8月時点の内容となります。 セミナー概要 セミナー名：令和5年度 著作権セミナー「AIと著作権」 主催者　　：文化庁著作権課 開催日　　：令和5年6月19日 著作権法の正しい理解に基づいて生成AIの利活用がされるよう、現行の著作権法の考え方やAIと著作権の関係についての説明が行われました。 第１部では著作権制度の概要についての解説。 第２部ではAIと著作権について、生成AIと著作権の関係についての解説。 という、２部構成で約１時間のセミナーとなっていました。 アーカイブ映像や講義資料は 文化庁のWebサイト から確認することができます。 そもそも著作権とは？ まずはセミナーの第１部「著作権制度の概要についての解説」と同じく、著作権について 文化庁の著作権テキスト の内容を引用しつつ確認・整理していきます。 著作権保護の目的 著作権テキスト 4ページ に以下のように記載されています。 適切な権利保護によって「創作の促進」を図り、権利の制限によって「公正な利用」を確保し、もって「文化の発展に寄与」することを目的としています。 文化庁著作権テキスト ※ 文化庁の著作権テキスト 4ページ より掲載 要は 「文化の発展に寄与」 するためには、新たな創造 「創作の促進」 が不可欠で、「創作の促進」を促すには、権利の保護・権利の制限で著作物の 「公正な利用」 を確保し、著作者に不利益にならないように利用できるようにすることで、創作の循環が生まれるようにする。ということのようです。 セミナーでも、 「著作者等の権利・利益を保護すること」と、「著作物を円滑に利用できること」のバランスを取ることが重要と考えられている。 と話されていました。 著作物について 次に著作物についての定義を確認しましょう。 著作権テキスト 5ページ の記載内容に、 著作権法では、著作物は、 「(a)思想又は感情を (b)創作的に (c)表現したものであつて、(d)文芸、学術、美術又は音楽の範囲に属するもの」 文化庁著作権テキスト と定義されています。 つまり、 思想や感情などの含まれないデータや事実といったもの 創作ではなく模倣であったり、ありふれたもの 表現していないアイデアのまま 工業製品 というように、定義から外れるものは著作物と認められない可能性が高いです。 業務に身近な著作物について それでは、ソフトウェアテストにおける身近な著作物についてはどのようなものがあるでしょうか？ ソフトウェアテストにおける作成物では、 要件定義書 詳細設計書 テストスイート テストシナリオ テストスクリプト テストサマリーレポート など、様々な作成物が存在するかと思います。 これらについて、著作物の定義や種類にあてはめてみると、 思想を創作的に表現した言語やプログラムの著作物としてなり得るもの は、 テストシナリオ テストスクリプト テストサマリーレポート 辺りでしょうか。 ただ、テストの目的としては「誰が操作しても正しい結果が得られること」を目的としているので、そこに対して創作性を見出すことは難しいかもしれません。 そもそも生成AIとは？ 続いて、今回のセミナーでは説明として触れられていませんでしたが、「生成AIとは何なのか？」「AIと何が違うのか？」を確認しておきます。 AIと生成AIの定義について AIについて 厚生労働省から公開されている「 AIの定義と開発経緯 」には、 人工知能（AI：artificial intelligence）については、明確な定義は存在しないが、「大量の知識データに対して、高度な推論を的確に行うことを目指したもの」（一般社団法人 人工知能学会設立趣意書からの抜粋）とされている。 AIの定義と開発経緯 と記載されています。 その他に総務省から公開されている「 人工知能(AI：エーアイ)のしくみ 」でも、 「AI」に関する確立した定義はありませんが、人間の思考プロセスと同じような形で動作するプログラム、あるいは人間が知的と感じる情報（じょうほう）処理（しょり）・技術（ぎじゅつ）といった広い概念で理解されされています。 人工知能(AI：エーアイ)のしくみ という記載があります。 AIは明確に確立された定義は無い。 という少し曖昧な技術ですが、大量のデータに対して 人間が思考・処理を行うことと同じように、コンピュータが動作を行うことを目的とした技術。 ということで、主に人間の代わりに処理を行うコンピュータを指すことが多い印象です。 生成AIについて NIKKEI COMPASSの生成AIの解説 には、 生成AI(英:Generative AI)は、画像、文章、音声、プログラムコード、構造化データなどさまざまなコンテンツを生成することのできる人工知能のこと。 NIKKEI COMPASSの生成AIの解説 大量のデータを学習した学習モデルが人間が作成するような絵や文章を生成することができる。 NIKKEI COMPASSの生成AIの解説 とあります。 つまり、AIが処理や技術を指していることに対して、 生成AIはそのAI技術を使って新たなコンテンツを生成することを目的 としています。 生成AIの学習段階と生成段階 生成AIを利用して新たなコンテンツを生成するためには、まずAIにデータを蓄積して情報を学習させる「学習段階」というものがあります。 この学習段階で蓄積するデータによって、AIの特徴づけが行われたりします。 次に、学習済みのAIに対して新たなコンテンツを生成させるために、利用者がどのようなコンテンツを 生み出したいかといった要求をAIに指示を出してコンテンツを生成する「生成段階」というものがあります。 この指示の出し方でも最終的な生成物の仕上がりが左右されます。 主な生成AIサービス 昨今話題に上がっている主な生成AIの種類では、「画像生成AI」「テキスト生成AI」「動画生成AI」「音声生成AI」など様々なものが展開されています。 例えばテキスト生成AIについては、サポートセンターなどへチャットで問い合わせた際に、質問に応じた生成メッセージが返答される。 という機会が身近に増えているかと思います。 ソフトウェアテストにおいても、テキスト生成AIにてテストケースの自動生成やテストスクリプトの自動生成、テストデータの自動生成など、生成AI活用の場面も増えてきています。 生成AIを利用する上での著作権に関するポイント では、実際に生成AIを利用する上で著作権に注意するポイントはどこになるのか、著作権セミナーの２部で解説されていた内容を元に確認していきます。 冒頭で触れていた、「生成AIを利用していても、状況によっては著作権の対象となりえる場合」について、また「対象とならない場合」についても具体的に見ていきましょう。 １．学習段階における学習のもととなった著作物 まず１つ目に、AIの開発・学習段階における、AI学習の元となったデータについての著作権に関する問題が説明されています。 結論としては、令和5年6月時点の著作権法第３０条の４の解釈では、 AI開発のための情報解析は既存の著作物に表現された思想や感情の享受を目的とした利用ではない。 （権利制限規定） と考えられることが多く、原則として著作権者の許諾なくAI学習を行うことができるようです。 セミナーでは、一般的な深層学習におけるAI学習段階の一例を元に説明されていました。 ※ 文化庁の著作権セミナーテキスト 30ページ～ より掲載 こちらに書かれているように、AI学習段階においてはWeb上のデータを収集して学習していくことが多く、さらに数十億点というような大量データの著作権の有無の判別や、著作者からの許諾を得る。 ということが困難で非現実的という状況から、下記の取り組みが行われてきたようです。 平成21年改正：インターネット情報検索サービスのための複製、電子計算機による情報解析のための複製等について、権利制限規定を整備 平成24年改正：いわゆる「写り込み」、技術の開発又は実用化のための試験の用に供するための利用等について、権利制限規定を整備 次世代知財システム検討委員会〔知的財産戦略本部・H27～28〕 新たな情報財検討委員会〔知的財産戦略本部・ H28～29〕 これらの取り組みの結果、著作権法第３０条の４が導入され、 ＡＩ開発のための情報解析のように、著作物に表現された思想又は感情の享受を目的としない利用行為は、原則として著作権者の許諾なく行うことが可能です（権利制限規定）。 と法改正になっているようです。 ※ 文化庁の著作権テキスト 65ページ より掲載 ただし、あくまで 著作権者への経済的利益を害するものではない。 ということが前提の思想としてはある為、 「著作権者の利益を不当に害することとなる場合※」は、本条の規定の対象とはなりません。 ※例えば、情報解析用に販売されているデータベースの著作物をＡＩ学習目的で複製する場合など。 という但し書きの条件や、 著作権者の著作物の利用市場と衝突するか、あるいは将来における著作物の潜在的販路を阻害するかという観点から、最終的には司法の場で個別具体的に判断されます。 とも説明されていました。 ソフトウェアテストにおいてもAI開発・学習が行われていますが、多くの企業では自社の過去のナレッジからAI学習を行っていることが多いようです。 私の所属会社（AGEST）につきましても、先日7月11日にAI技術の研究開発を行う「AGEST AI Lab.」の設立を発表いたしております。 こちらの ホームページ に情報公開しておりますので、ご参照いただければと思います。 ２．生成段階における入力情報の著作物 ２つ目に、生成AIを利用してデータを生成する段階における、入力情報となるものの著作権に関する問題が説明されています。 結論としては、 生成AI利用の有無に関わらず、既存の著作権同様の考え方が適用される。 ということのようです。 セミナーで説明されていた内容としましては、 ＡＩを利用して画像等を生成した場合でも、著作権侵害となるか否かは、人がＡＩを利用せず絵を描いた場合などの、通常の場合と同様に判断されます。 AI生成物に、既存の著作物との「類似性」又は「依拠性」が認められない場合、既存の著作物の著作権侵害とはならず、著作権法上は著作権者の許諾なく利用することが可能です。 これに対して、既存の著作物との「類似性」及び「依拠性」が認められる場合、そのようなAI生成物を利用する行為は、 ① 権利者から利用許諾を得ている ② 許諾が不要な権利制限規定が適用される ……のいずれかに該当しない限り、著作権侵害となります。 ということでした。 ※ 文化庁の著作権セミナーテキスト 44ページ より掲載 上記内容のとおり、特にAIだからということではなく、既存の著作権同様の考え方が適用されている。 ということでした。 ただ、生成AI利用という点でいうと、特に 生成物を作成するためのテキストの入力情報についても、「類似性」「依拠性」を問われる。 という点は気をつける必要がありそうです。 ３．生成AIの生成物自体の著作権の有無 ３つ目に、生成AIで生成した生成物自体に「著作権は認められるのか？」「著作者は誰になるのか？」という問題が説明されています。 結論としては、 AIが独自で創出したものは著作物にならず、利用者の創作意図が介入している場合は著作物になる。 ということのようです。 セミナーで説明されていた内容としましては、 AIが自律的に生成したものは、 「思想又は感情を創作的に表現したもの」ではなく、著作物に該当しないと考えられます。 （例）人が何ら指示※を与えず（又は簡単な指示を与えるにとどまり） 「生成」のボタンを押すだけでAIが生成したもの　※プロンプト等 これに対して、人が思想感情を創作的に表現するための「道具」としてAIを使用したものと認められれば、著作物に該当し、AI利用者が著作者となると考えられます。 というように、あくまで 著作物は人の「思想や感情などを創作的に表現したもの」である ので、それに当てはまらない利用方法をしている場合は著作物には該当せず、当てはまる場合は利用者の著作物として考えられるようです。 この考え方は中々に興味深く、人の思想や感情が入っていなければAIが生み出す生成物について、たとえ創造性が高いものであったとしても著作物になり得ず、著作者もいない。というケースが出てくる可能性があります。 たとえ同じような生成物だとしても、 「AI独自で創り出したもの」と「人の創作意図が介入して創り出したもの」とでは著作物の有無が異なる。 ということになります。 何と言いますか、新しい時代に入っているのだ。と改めて認識する感覚ですね。 さいごに 生成AIを業務利用する際にはどのようなことに注意すべきか ここまで著作権セミナーの解説内容を振り返りながら、著作権や生成AIについて確認してきましたが、結局のところ生成AIを活用して業務利用を行っていくに当たって、注意しておくポイントをまとめておきましょう。 ・ ポイント１つ目：著作物となり得るのかどうか 生成AIの開発・学習段階、生成段階、生成物について、著作物の定義 「(a)思想又は感情を (b)創作的に (c)表現したものであつて、(d)文芸、学術、美術又は音楽の範囲に属するもの」 と照らし合わせて著作物と見なされるかを確認しておくことが重要です。 ・ ポイント２つ目：著作者の権利を侵害していないか １つ目の確認で著作物であった場合、生成AIを利用してコンテンツを生成する上で、著作権の侵害に該当しないかどうかの確認が必要となります。 基本的に「権利制限規定」以外での利用は著作者に許諾が必要となります。生成AIの利用で著作者の利益を不当に侵害していないことが考え方の基本となります。 今後の著作権法の改正についてもチェックが大切 生成AIに限らず、技術の進歩に応じて著作権法も日々時代に合わせて改正されています。 先日に文化庁で行われた著作権セミナーのように、技術の進歩に応じて考え方を整理・検討して提示したり、法改正や施行が行われています。 文化庁で公開されている著作権テキストも現在は令和5年度版が公開されていて、前年度から記載内容の変更箇所もあります。 先端技術については法改正の整備頻度も早いので、文化庁などの発信情報を注視していくことが大切だと改めて感じました。 The post 生成AIと著作権について考える first appeared on Sqripts .

みなさん、こんにちは！　QAエンジニアのゆーすけです。 9/22にJaSST新潟が開催されました。（ JaSST ） 新潟でのハイブリット開催（オフライン＋オンライン）のため、当初は業務の傍らオンライン視聴ができればと思ってましたが、掲げたテーマに強い興味を抱いたため、業務を調整して新潟現地参加をしてきました。 「QAスキルアセスメントを活用したQA標準化とQA人材育成」 今回の新潟のテーマがこちらになります。 アセスメントとはざっくりいうと評価、分析といった類の意味合いとなります。 ひと昔前のAGESTでは、各役割（職務ないし職能）に対しての定義が 「求められる役割を満たすこと」 というような記載もあり、役割に対しての解釈が個人で異なる、また会社として標準スキルの定義が曖昧な部分もあったため、目指すべきキャリアに対しての研鑽すべきスキル提示ができてないものもありました。 順次job description（以下JD）を整理しているものの、役割に対して求められるスキルや、スキルに対する待遇というものはそれぞれの組織で大きく異なっていて、ここに明確な解はありません。 現在、役割に応じたジョブ定義、持っていてほしいスキル、資格などを鋭意設計中ですが、なかなか自分の所属組織外の情報を聞けるという機会も中々に稀だと思い、せっかく聞くのであれば現地で生の声を聞こうと思い、新潟に足を運ばせるきっかけとなりました！ 基調講演として、Sqriptsスクリプターである 湯本氏 によるfreee社での取り組みを語っていただいております。 講演内容レポートに関して、情報の誤認識、拡大解釈、認識のバイアスなどがあるとfreee社にご迷惑をおかけしてしまうことになりそうなので、印象に残った箇所の抜粋とそれに対する自分の考えやAGESTの方向性を取り上げていきたいと思います。 分化の違いを理解したうえで、自己の分化を確立する QAの経験があるといっても、組織が違えば根本的な部分での分化の違いはある 採用とあわせて、自社としてのQAを確立する必要性があった こちらはまさにその通りすぎる、と思いました。 自分も採用面接に携わることがありますが、これはクライアント様とMTGする時も思うことがあります。 分化が違えば同じ用語を使っていても中身の意味が全く違う、というようなことは多々あるので、 「コミュニケーションを重ねる」 「異文化である、ということを大前提で考える」 「自分の中の指標・ものさしをしっかりと固める必要がある」 といったようなことが大事である、と改めて感じるお言葉でした。 教えるもの、教えないものを切り分ける QA人材の育成で必要なことは、何を教えるのか、どこまで教えればいいのかを明らかにすること ～ オンボーディングで行う内容と、OJTで行う内容を明確に分かる これはなるほどな、と。 AGESTでも入社後のオンボーディングを1～1.5ヵ月で行っていますが、オンボーディングを実際に受けていないメンバーは実際のオンボーディングで明確に何をどの粒度まで教えているか、ということまでは切り分けられてないな、と。 基本的には現場で必要そうな内容をオンボーディングに入れ込んでいますが、あえてオンボーディングでは扱わずOJTに任せる（その代わり必ずOJTで扱うようメンバー理解が必要）ということは効果的になるものもあるな、と強く感じた内容でした。 スキルラダーのロール定義 スキルラダーのロール定義 スキルラダーに関しては自分も初聞きの単語でした。 ラダーは梯子を意味しておりスキルラダーとするとスキルの専門性をあげていくための指標。 キャリアマップ/パス、JDとは異なり昇進、報酬とは関連しない純粋なスキルマップのようなものとなり、今の自分のスキル位置を計れるようなもの、という理解をしています。 ジュニア層の定義は各分野の初歩は全てできるべき、ミドル層からは役割に特化して専門的にスキルアップできるように この内容に関しては、AGESTでも同じような考えをしています。 なぜならAGEST QA部門で考えているJDでも、ジュニア層は全ての初級を理解し、その上で専門性のあるテストエンジニア、テストマネージャー、テクニカルテストエンジニアなどに分かれるように設計しているので、新たな観点を得られたということはありませんが、それ以上に大きな安心感を得られた、という思いになりました。 スキルラダーの評価軸：自立性 freee社の自立性評価として、「サポートありき」「サポートが必要だから基本はできる」「サポート不要」「人のサポートができる」としている、とのことでした。 ここもある似ている考えをしており安心感を覚えた内容ですが、個人的には test.sff や守破離の考え方にもある「改善、改良、新規プロセスを生み出すことができる」といったものも上位評価として置きたいと考えています。 アウトプットを標準化すると人の流動化が容易になる これは自社プロダクトが複数ある前提特有かな、という思いが強い内容でした。 自社内に複数プロダクトがあり、QAのアウトプットをプロダクト横断で標準化することでプロダクト移動をしても覚えなおしがなく一定上の効果が見込まれる、という内容という理解をしていますが、第三者会社ではアウトプットの内容は顧客側に依存することがあります。（そもそもテストに対するインプットデータが絶対的に標準化されない） 第三者検証会社でも自社フォーマットで運用して構わないものは標準化を行っていますが、顧客に向き合い、顧客ごとの体制/要望に寄り添い臨機応援に対応、カスタマイズしてて成果を出す、というのが第三者検証会社ならではの面白味なのかもしれない、とあらためて感じました。 評価とカルチャー ほか心に残った内容としては 人事評価はスキルラダーでは行わず、アウトカムで行う スキルラダーは採用には活用しない。採用はカルチャーフィットが重要 というのが評価、採用にも携わる立場としては今後も意識して考えるべき内容だな、と思っています。 今回一部お見せいただいたスキルラダーは提示することで、スキルの客観的向上の可視化＝評価、待遇直結といったようなことも起こりやすいのかな、と思いますが、 成果により会社貢献 ↑ 成果を出すためのプロセス、ジョブ定義 　　↑ プロセスを達成するためのスキル 　　　　↑ スキルを習熟するための研修、オンボーディング、および各種資格奨励 のようなことが基本である、と。 また、採用においてもスキルや経験の確認を重要視していた時代（十数年前）も確かに自分にもありましたので、この2つは自分の襟を正すきっかけになったのではないかな、と思っております。 まとめ 今回スキルラダーや、freee社で使用されているテストチャータ等、具体的なものも見せていただきましたが、実際に何を考え何を構築するかは所属組織次第だと思っています。 freee社の事例はあくまでfreee社にあった内容であり、湯本氏も講演資料冒頭で 「組織作りの参考にしてね！」 と記載しているので、大事なのは事例を100%受け止めるのではなく、 スキルアセスメントや標準化などを考えることがカルチャー形成になり、 カルチャーが定まることによって方針、方向性がより強固なものになり、 それが自社ブランドになっていく、 ということが、今回のカンファレンス参加で持ち帰った内容になります。 この自分の考えもあくまで自社カルチャーにあわせた考え方も多いと思いますので、 皆様も組織作りや組織の中での動き方の参考にしていただければと思います。 またもしAGESTのカルチャーに興味を湧くようなことがありましたら、気軽にお問い合わせをしていただければと！！ The post 今こそQAスキルアセスメントについて考えてみた（JaSST新潟レポートにかえて） first appeared on Sqripts .

こんにちは、見習いフロントエンジニアのぱやぴです。 今回はframer-motionを使用して、React＋Typescriptでカレンダーコンポーネントに月の変更時のアニメーションを追加する方法を紹介します。 はじめに まず、完成したものをご紹介します。 （フレーム数の問題でカクカクしていますが、実際はスムーズに動作します！） 実装 それではアニメーションの実装をしていきます。。 使用技術 TypeScript: “^4.8.4” React: “^18.2.0” framer-motion: “^9.0.0” date-fns: “^2.29.3” アニメーション作成前の準備 まず、date-fnsを使用して以下のようなコンポーネントを作成しました。 import { addMonths, subMonths } from "date-fns"; import { useState } from "react"; import { Month } from "./Month"; import { CalendarHeader } from "./CalendarHeader"; export interface CalendarProps { date?: string; } export const Calendar = ({date}: CalendarProps) => { const currentDate = date ? new Date(date) : new Date(); const [month, setMonth] = useState(currentDate); const onNext = () => { setMonth(addMonths(month, 1)); }; const onPrev = () => { setMonth(subMonths(month, 1)); }; return ( <div> <CalendarHeader onNext={onNext} onPrev={onPrev} month={month} /> <Month month={month} /> </div> ); }; アニメーションの作成 まず、アニメーションの定義を行います。 月が進む場合と月が戻る場合の2つのパターンのアニメーションと最終的な位置を決めます。 月が進む場合は右から、月が戻る場合は左から移動してくるように設定し、最終的に0になるようにしました。 const variants = { enter: (isNext: boolean) => { return { x: isNext ? 100 : -100, opacity: 0, }; }, center: { x: 0, opacity: 1, }, }; 状態の作成 月が進んでいるか戻っているかの状態を管理し、月を変更するタイミングで状態を更新します。 const [isNext, setIsNext] = useState<boolean>(); const onNext = () => { setMonth(addMonths(month, 1)); setIsNext(true); }; const onPrev = () => { setMonth(subMonths(month, 1)); setIsNext(false); }; アニメーションの適用 アニメーションを適用したいコンポーネント（今回はMonthコンポーネント）を motion.div コンポーネントで囲み、アニメーションの設定を行います。 import { motion } from "framer-motion"; ~~~ return ( <div> <CalendarHeader onNext={onNext} onPrev={onPrev} month={month} /> <motion.div key={month.toString()} custom={isNext} variants={variants} initial="enter" animate="center" transition={{ opacity: { duration: 0.2 }, x: { type: "spring", stiffness: 300, damping: 30 }, }} > <Month month={month} /> </motion.div> </div> ); custom プロパティに渡した変数は、 variants プロパティで渡した関数の引数として使用されます。 initial プロパティには描画時のアニメーション、 animate プロパティには描画後のアニメーションを設定します。 transition プロパティを使用することで、opacityの速度やx軸の移動方法など、さまざまな設定を行うことができます。 詳細な設定については、以下のリンクで確認できます： https://www.framer.com/motion/transition/ 今回はxの動きに "spring" を使用して、少し反発するようなアニメーションに設定しています。 初回描画時のアニメーション 上記のままでは初回のカレンダー描画時に月が左からスライドインするようなアニメーションが発生します。 初回のみアニメーションを行わないようにするため、 initial プロパティに条件分岐を追加しました。 ~~~ <motion.div key={month.toString()} custom={isNext} variants={variants} initial={isNext === undefined ? "center" : "enter"} animate="center" transition={{ opacity: { duration: 0.2 }, x: { type: "spring", stiffness: 300, damping: 30 }, }} > <Month month={month} /> </motion.div> ~~~ 完成図 import { addMonths, subMonths } from "date-fns"; import { motion } from "framer-motion"; import { useState } from "react"; import { Month } from "./Month"; import { CalendarHeader } from "./CalendarHeader"; const variants = { enter: (isNext: boolean) => { return { x: isNext ? 100 : -100, opacity: 0, }; }, center: { x: 0, opacity: 1, }, }; export interface CalendarProps { date?: string; } export const Calendar = ({ date }: CalendarProps) => { const currentDate = date ? new Date(date) : new Date(); const [month, setMonth] = useState(currentDate); const [isNext, setIsNext] = useState<boolean | undefined>(undefined); const onNext = () => { setMonth(addMonths(month, 1)); setIsNext(true); }; const onPrev = () => { setMonth(subMonths(month, 1)); setIsNext(false); }; return ( <div> <CalendarHeader onNext={onNext} onPrev={onPrev} month={month} /> <motion.div key={month.toString()} custom={isNext} variants={variants} initial={isNext === undefined ? "center" : "enter"} animate="center" transition={{ opacity: { duration: 0.2 }, x: { type: "spring", stiffness: 300, damping: 30 }, }} > <Month month={month} /> </motion.div> </div> ); }; 最後に framer-motionを使用することで、簡単にアニメーションを追加することができました。 アニメーションを追加するだけで、より洗練されたコンポーネントになりました！ framer-motionを使えば、比較的簡単に複雑なアニメーションを作成できますので、さらに学習を進めて、プロダクト内で活用できるリッチなコンポーネントを作成していきたいと思います。 読んでいただき、ありがとうございました。何か参考になれば幸いです。 The post framer-motionでReactのカレンダーコンポーネントを少しリッチに first appeared on Sqripts .

お客様とサービスの間には有形、無形の連続する接点が存在します。この接点の一つ一つを「ユーザーインタフェース（UI）」といい、連続する接点がお客様やお客様に関わる方々にもたらす記憶や感情、想いといったものを「ユーザーエクスペリエンス（UX）」あるいは「顧客体験」と呼びます。 ここ近年、IT技術の発展によってUIは高度に進化し、お客様のUXも大変リッチになってきました。 一度、素晴らしい体験をしたお客様の満足度レベルが上がると、これまで不満なく使ってきたシステムやサービスに満足できなくなります。特にWebサービスなどは、お客様が同じデバイスから各種のサービスを既にご体験なさっていることも多く、ご提供したいサービスそのものではなく入口のメンバー登録など多くのサービスと共通のUI部分で競合以外のサービスと比較されてしまいサイトを離れてしまうといった残念なことが起こってしまいます。 また反対に慣れ親しんだサービスのUIが急に、或いは一方的に変更されてしまったことに不満が募りそのサービスから離れてしまうといったことも起きてしまいます。 本記事では、お客様に不満を抱かせない、更には満足いただけるシステムやサービスを提供し続けるために私たちは何をすればよいのかということをご一緒に考えたいと思います。 ユーザビリティ改善で品質改善スキルが上がる 3 つの理由 　皆さんがシステムやサービスを提供する側でいらっしゃる場合、ユーザビリティを具体的に意識するのはいつごろでしょうか？ サイトの直帰率や平均滞在時間の指標が思わしくない時？ UAT ※1 でユーザビリティに関する問題が山のように指摘された時？　 いえ、このコラムを読んでくださっている読者の方ならば「いつも意識している」とおっしゃる方が大半に違いありません。 では具体的に改善を図るのはいつごろでしょうか？ 実は、ユーザビリティの改善は企画や要件定義工程から始めると手戻りも少なく、組織としての品質改善スキルもどんどん向上していく優れものの取り組みなのです。 「えっ？ユーザビリティとか可用性って非機能要件の一つだから、ユーザビリティ向上って品質改善そのものでは？」 鋭い読者の方はそのようにご指摘くださるかもしれません。ですが、わざわざユーザビリティ改善を取り上げるのは次の3つの理由があるからです。 理由①　改善された、良くなったことが分かりやすい 理由②　組織全体で取り組むことが出来る 理由③　1/0(イチゼロ)ではなく段階的に改善していける ※1　参照　 JUAS「非機能要求仕様ガイドライン」 工夫や努力を分かってもらえると一層やる気が出ませんか 一つずつ説明していきましょう。 まず、「理由①　良くなったことが分かりやすい」ですが、この理由だけでユーザビリティ改善に取り組むべき価値がある理由です。品質の中には改善しても効果が分かりづらい、どこがどのように良くなったのか説明しづらいものもあります。 例えば「保守性－構成管理効率 ※2 が0.5から0.6にあがりました」と言われたら上がったのが良いか悪いかさえ門外漢には判断しづらいですが、「エンドユーザー5人中3名が当惑して先に進めなかった箇所が5人全員先に進めるようになりました」と聞くと良くなったことが分かりやすいですよね。 改善をアピールしやすいと言い換えても良いでしょう。人間、褒められるとやる気が出るのは自然なこと。改善をさりげなくアピールして組織内で認められたり、何よりもエンドユーザーに喜ばれたりと改善のモチベーションが向上します。そして更に良くしようという原動力となり好循環が働くようになれば自主的に改善に励むようになります。 ※2　保守性－構成管理効率：保守作業における各種資源（プログラムやドキュメント、使用データ（DBを含む））のバージョン管理における機械管理の実現割合： JUAS「非機能要求仕様ガイドライン」 より 組織のみんながお客様の方を見ることで連帯感が強まります 次に「理由②　組織全体で取り組むことが出来る」ですがこれはユーザビリティの定義をお伝えすると分かりやすいかもしれません。 ユーザビリティ ※3 とはJIS Z 8520によりますと「特定のユーザが特定の利用状況において，システム，製品又はサービスを利用する際に，効果，効率及び満足を伴って特定の目標を達成する度合い。」と定義されています。 つまり改善を図る前に「どういったユーザー」が「どういった状況で」「何を目標・目的に」使った場合使いやすいのかを明確に定義する必要があります。そして一般的に組織の中でターゲットユーザーやメインユーザーの情報を多く持っているのは企画や営業、ユーザー対応部門といった方々です。 となれば、ユーザビリティの効果的な改善には、通常開発と品証部門のしかも機能によっては限られたチームのみが人知れず頑張っているところ、多くの部門を巻き込んで取り組むことが出来ます。 あなたが提供しようとしているシステムやサービスが基幹システムの場合、経理や総務といった部門の方がユーザーの代わりに問題点を見つけてくださるかもしれません。 特許関係でしかやり取りの無かった法務部門の方が、ターゲットユーザーのペルソナにピッタリかもしれません。 すると、関わった方たちも改善項目の進捗を気にかけてくださるようになります。自分からも色々と直接伺うことが増えたり各部署へ情報発信をしたりすることが自然と行われていきます。 多様な方が関わってくださればくださるほど気づきの機会も増えますし、カバーできる範囲も広くなっていくと思いませんか？ その他の品質項目も改善には色々な部門からの協力を仰ぐ必要がありますが、そういった協力を仰ぐ前に、大きな負担を相手に掛けず気軽なお願いでネットワークを築いていけるチャンスを作ってくれる点はユーザビリティ改善活動の得難い利点です。 ※3　参照　JIS Z 8521：2020　人間工学−人とシステムとのインタラクション− ユーザビリティの定義及び概念 スモールサクセスが品質改善活動への肯定感をどんどん高めます 最後の理由は「段階的に改善していける」点です。 個人的な挑戦において「初めから大きな成功を目標に掲げず、小さな目標を掲げて成功体験を積み重ねていった方が、目標達成率が高い」と聞いたことはありませんか？これは組織での改善でも言える事です。 そしてユーザビリティは「効果，効率及び満足を伴って特定の目標を達成する度合い」なので「達成した、できなかった」の1/0(イチゼロ)ではなく、改善のステップを段階的に設定することが可能です。 短い期間で小さな改善を示すことによってあなたやあなたのチーム、システムやサービスが確実に「変わっていく」「良くなっていく」という印象と信頼を周りに感じていただくことが出来ます。 すると信じられないかもしれませんが、その他の改善活動を行う際も「あの人は、あのチームは、有言実行の実績があれもある、これもある」と思って快く協力してくれることが増えてくるのです。 お客様に不満を抱かせない、更には満足いただけるシステムやサービスを提供し続けるにはお客様への深い理解と不断の品質向上が必要です。これらを充実感と共に実施できるのが「ユーザビリティ改善」という取り組みです。 是非皆さんも「ユーザビリティ改善」から品質改善を始めてみませんか？ The post 「ユーザビリティ」後回しになっていませんか？― 品質改善スキル向上にも役立つ「ユーザビリティテスト」をご紹介 first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第9回目のテーマは、「エクストリーム・プログラミング（XP）」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 価値・原則・プラクティス XPの話をする前に、価値・原則・プラクティスを解説します。スクラムやXPのように、世の中にはさまざまな開発手法がありますが、それぞれの手法には価値・原則・プラクティスが定義されてるケースが多いです。これらがどういった意味を持つのかを見ていきましょう。 まず、価値とは、「何を考え、何を行うのかを判断するのに使用する基準」です。開発手法が持つ価値観なので、開発手法が大切にしていることが価値としてまとめられています。この価値があることで、開発手法を利用する人は、「自分たちは、この開発手法の価値を満たしているだろうか？」と判断ができます。 価値はふんわりした言葉になるので、じゃ、どうやったらその価値を実現できるのか？がわかりにくいと思います。たとえば、アジャイルマニフェストの一例をあげると、「個人と対話を」という価値がありますが、これをどう実現すればいいか？ これだけではそこまでわかりません。 また、価値だけだと間違った判断になってしまう可能性があります。たとえば、アジャイルマニフェストだとコミュニケーションに価値を置いてますが、「コミュニケーションを重視したいから1000ページのドキュメントを書こう！」となると、ドキュメント作成に時間がかかりすぎて、アジャイルな開発とは言えません。そこで登場するのが原則です。 原則は、価値とプラクティスを支える橋のような存在です。原則は、「具体的な指針」なので、具体的に何をすればいいかわかりやすいものになっています。 アジャイルマニフェストの原則を見てみると「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」というのもあります。この原則を守って、価値を実現していこうというものです。 先程の例にでてきた「1000ページのドキュメントを書こう！」の場合、「フェイス・トゥ・フェイスで話をする」や「シンプルさ（ムダなく作れる量を最大限にすること）が本質です」という原則にマッチしません。マッチしないので、価値を満たさない可能性のあるアクションだと気がつけます。 プラクティスは、価値へと向かう原則をより具体的にしたものです。アジャイルプラクティスとも呼ばれます。プラクティスには「実行」、「練習」、「習慣」という意味があり、アジャイル開発だと「アジャイルになるための習慣」という表現がふさわしいかもしれません。アジャイルプラクティスをやればアジャイル開発になる！とはかぎりませんが、少なくとも価値へと続く橋のような存在になります エクストリーム・プログラミング XPの考案者のケント・ベックさんは、Javaエンジニアであれば誰もが知っているであろうテストフレームワーク「JUnit」を開発したひとりです。 XPは、価値・原則・プラクティスに分かれて解説されています。XPは、コミュニケーションやチーム運営だけでなく、具体的なエンジニアリングプラクティスが揃っているので、開発者の方であれば共感しやすい内容にもなっています。ただ、エクストリームとあるだけあり、極端なプラクティスも多く、ペアプログラミングなど、賛否両論を呼ぶプラクティスも多数あります。 XPを解説した書籍は、第1版が出た5年後に第2版が登場しました。第2版は内容も修正・追記されています。副題も変わっており、第1版では「ソフトウェア開発の究極の手法」だったのが「変化を受け入れる」になっています。ここでは、手元にあるエクストリーム・プログラミング第2版『 XPエクストリーム・プログラミング入門―変化を受け入れる 』を使って説明しています。 まずは、XPの価値を順に見ていきましょう。XPの価値は5つあります。 XPの価値 XPの価値： コミュニケーション ひとつ目の価値は「コミュニケーション」です。書籍では「もっとも重要」とされています。 XPの生みの親であるケント・ベックさんが、実際の仕事において、顧客とのやりとりがうまくいかず失敗するプロジェクトを多く見てきたため、コミュニケーションをもっとも重要視するようになったという逸話もあります。 XPに限らず、アジャイル開発全般において、チームの意識を高め、効率的な協力関係を生み出すためには、コミュニケーションは必須の価値とも言えます。 XPの価値：シンプルさ 2つ目は「シンプルさ」です。 シンプルさは、開発するシステムであったり、問題や課題の解決策であったり、さまざまなものに適用できる価値観です。私自身も、若手エンジニアを育成するときは、「140文字以内で報告をしてみよう」とか「これがもっともシンプルな方法だろうか？」といった話を意識してしています。 もちろん、複雑なシステムも必要でしょうが、開発活動も開発するシステムも、コミュニケーション方法も、できるだけシンプルな方が、よいシステムに近づけるように思います。 XPの価値： フィードバック 3つ目は「フィードバック」です。 完璧なシステムを開発するのはとても難しいことです。たとえ、完璧になったとしても、時間の流れや世の中の変化によって、それもすぐ不完全になってしまいます。 ただ、完璧を目指していく姿勢はとても大切です。自分の力だけで完璧になれればよいですが、フィードバックがあればよりはやく完璧に近づけるでしょう。十分な改善を行うためには、さまざまなところからやってくるフィードバックが重要になります。 また、アジャイル開発に取り組むのであれば、フィードバックに慣れておくのも必要だと思います。たとえば、コミュニケーションを重視するアジャイル開発では、フィードバックをもらうだけでなく、あなたからもフィードバックを与えるケースが多くなるはずです。よいフィードバックをする習慣を身に着けておくと良いでしょう。 そして、フィードバックにはポジティブなものもあれば、ネガティブなものもあります。ネガティブな場合でも、どうすればよくなるのか？ ポジティブに相手とコミュニケーションを取っていく必要があります。 ネガティブなフィードバックは、誰もがすぐに受け入れられるものではないでしょう。相手を気遣って本当のフィードバックを避けてしまう気持ちもわかります。 しかし、将来の宝になるかもしれないフィードバックが与えられない、受け取れない環境は健康的な環境とは言えません。ネガティブな内容であっても、チームで話せる、話し合える、そういうチームを目指してみてはどうかと思います。 XPの価値： 勇気 4つ目は「勇気」です。 フィードバックでも書きましたが、真実を伝える勇気、新しい解決策を探す勇気など、開発のなかで様々な勇気が求められます。ふりかえりでも勇気を持ったチャレンジを考えていきます。 アジャイル開発では、どんどん変化を受け入れていくため、勇気を持った対応がとても重要です。そうでなければ、新しいチャレンジができなかったり、できることだけやってしまったりして、その結果、改善が進まなくなり、「なんだかうまくいかない」となってしまうでしょう。 個人的には、やりなおせるものであればどんどんチャレンジしてほしいと思いますが、どれだけ心配であっても、作業全体の20％ぐらいはチャレンジを入れていかないと、現場が良くなっていく体感が得られにくいのではないかと思います。 XPの価値： 尊重 最後は「尊重」です。 書籍には、「これまでの4つの価値の背後にあるのが尊重」とあります。続けると「ソフトウェア開発で人間性と生産性を同時に改善するには、チームにおける個人の貢献が尊重されるべき」と書かれています。 アジャイル開発では、コミュニケーションを重視します。コミュニケーションはひとりではできないものです。相手に対する尊重であったり、敬意であったり、よいコミュニケーションに必要な価値は、アジャイル開発でなくとも持っておきたいものだと思います。 連載一覧 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 第8回：スクラムイベントの実践方法 第9回：エクストリーム・プログラミングとその価値 The post 第9回 エクストリーム・プログラミングとその価値 first appeared on Sqripts .

こんにちは、QAコンサルタントのツマミです。 唐突過ぎますが私ツマミ、JIS（日本産業規格：Japanese Industrial Standards）が大好きです。 お客様のプロダクト品質やプロセス品質の課題に対して何か基準は無いか、定義や分類法は無いかと探ると何かしらのJISに行き当たるのは本当にすごいことだと思います。そんなJISのいずれかの制定に絡んでいればもっと学術的な話や裏話の一つもできたかもしれませんが、そこはあくまで利用者側のツマミ、JISの一つひとつを道に例えて、こんなことが(書いて)あったよ、こんなことを見つけたよといったことをお気楽な道行のごとく書き連ねて参りたいと思います。 さて、初めてのさんぽは JIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」 。ゆるゆると楽しんでまいりたいと思います。 どうぞ皆さま、ちょっとした気分転換としてこのJISさんぽにお気楽にお付き合いの程、よしなに願い奉ります。 今回のJIS JIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」 とは この規格はツマミがAGESTで担当している「UI/UX向上支援サービス」と深いかかわりがあります。表題にあるように、人とシステム（サービスであったり、プロダクトであったり）との間でのやりとり(インタラクション)がどうあればよいかについて、原則が具体的かつ豊富な事例を添えてまとめられています。 インタラクション(Interaction)：相互作用，相互の影響 Weblio英和辞典 なぜ、このJISを選んだのか 「新しくて」「例が豊富で」「カテゴリ分類が手ごろ」と三拍子揃っているので、ユーザビリティを評価する際に使いやすい点が「UIやUXを検討しよう」という方にとって役立つと思ったからです。 「新しい」本JISは改訂が2022年です。一つ前の版でも2008年改訂なので新しい見解が盛り込まれていることが期待できます。 「例が豊富」後で詳しく述べたいと思いますがなんと141もの例が示されています。 「カテゴリ分類が手ごろ」レーダーチャートにした時に形の違いが分かりやすい7カテゴリという所が買いだと思っています。 道行 まえがき、序文 まえがきは8行。前半で「一般社団法人人間工学会」と「一般財団法人日本規格協会」が原案を出したと記載されています。それとJIS Z 8520:2008からの改訂であること。後半4行で示されている「この規格が著作権法で保護対象になっている云々」は重要なことですがどのJISでも記載されているはずなので、実質前半の4行がこの規格の前書きといってよいですよね。 あっさりしたまえがきと本文における豊富な例との対比にちょっとグッと来てしまいます。 1章　適用範囲 「安全を重視するシステム、共同作業、人工知能などの一部の応用技術には適用しない」ものの、それ以外の全てのインタラクティブシステムに適用可能と書いてあることからも分かるとおり、かなり適用範囲の広い規格です。 また、対象（利用者）も要求仕様に関係するエンジニアやUI関係の設計者、評価者だけでなく使いやすい製品を調達しようとする購入担当者も使えるということが書いてあります。 確かに、インタラクティブシステムを使いやすくしようと思う方や、使いやすさを何らかの形で評価する方に使っていただきたい規格です。 2章　引用規格 「この規格には、引用規格は無い」と記載されています。つまりこの規格単独で利用することが出来るわけで、本文の豊富な例も相まってUI/UX教育に使いやすいのではないでしょうか。 3章　用語及び定義 ここでは11の用語が定義されています。ツマミが特に着目したのは3.8項で定義されている「ユーザ」についてUI/UX評価での解釈を明確にするために、3.8A「ユーザエンゲージメント」を追加し、より詳細に定義されている点（この定義を含めると12個の用語が定義されていることになります）。 「エンゲージメント」は英語では一般用語だそうですが、日本語だと「婚約」の意味がまだ強く、ここで定義されている「インタラクティブシステムがユーザとシステムとのインタラクションの継続を促し、動機付けるような機能及び情報を提供すること」という意味はしっくりこないような気がします。 ただ、この「ユーザエンゲージメント」の考え方が盛り込まれていることによって、この規格がUX(ユーザエクスペリエンス)の設計や評価にも使えるようになっているので、わざわざ用語として定義されているのはこの規格の良い点の一つだと思っています。 その他、「アクセシビリティ」「利用状況」「ユーザビリティ」「ユーザエクスペリエンス」「ユーザインタフェース」などUI/UX教育で押さえておきたい用語が定義されています。 4章　インタラクションの原則 概要に7つの原則が記載されているのですが、ここに”7”という数字を持ってくることに「規定自体を分かりやすくしよう」という心意気を感じてしまうのはツマミだけでしょうか。 ここには7つの原則について概要が記載されており、また原則に含まれる主な推奨事項が表になっていますが、やはり概要だけで理解するのは少々厳しい。是非、5章の「原則及び推奨事項」を読んでいただきたいところです。 この4章の一番の読みどころは「推奨事項を一つしか適用しない場合，原則を完全に満たしたことにはならない」と「設計推奨事項を分類することよりも，それらの意味を理解して利用することの方が重要」のどちらかなのではと思います。学ぶ立場で読むと後者の「理解して利用することの方が重要」に目が行きがちですし、もちろん大切な考え方です。しかしながら前者が意味するところの「一つ適用できたからと言って改善できた！とはならない」というUI/UX改善時の注意点は、肝に銘じておきたいところです。 また、4章には、JIS Z 8530 で示される「人間中心設計」との関係が記載されていますが、ツマミには規定していることが違うということだけ伝わってきて、もう少しかみ砕いて記述されていると嬉しかったなぁと思ってしまいます。要は使いやすいインタラクティブな製品やサービスとはどういったものか、どのような特徴を備えているのかを示しているのがこのJIS8520、他方JIS8530は使いやすいインタラクティブな製品やサービスを作る際の作り方やプロセスがどうあればよいのかを示しているのだと理解しました。 5章　原則及び推奨事項 この章では7つの原則についての説明が記されています。 パッと見ると文章量に圧倒されそうになりますが、7つの原則それぞれが「原則(節題)－原則の説明ー注記－補則/細則ー補則/細則の説明－事例」という構成になっていることを予め知っておくと、とても理解しやすく記載されていることが分かります。 そのまま引用すると著作権に触れてしまいますから、例えば5.1節をツマミが理解した範囲でかみ砕きますと、まず節題として「5.1 ユーザーが行うタスクへの適合性」が記載されています。 続いて、この原則の説明が述べられます。5.1節の場合、「手段と目的を取り違えないように、手段が凄くなくてもユーザーが目的を達成できることが重要です」といったようなことが書かれているわけです。 そして、この説明に対して注記が記載されています。「達成する目的自体もユーザーニーズに沿ったものでないと駄目ですよ」「手段も奇をてらったものではなく、何がしたいかの本質に沿った手段を選びましょう」といった原則の説明をきちんと理解するためのアドバイスが注記として記載されている訳です。文章が延々と続くとつい本文だけ拾い読みしてしまいたくなりますが、是非、注記も読み込んで欲しいですし、その価値があります。 更に、原則をもう少し具体的にした補則、細則的な項目が述べられ、続く各項でこれらの補則、細則について詳しい説明と例が示されます。例えば5.1節の場合、3項目が挙げられていますが、3つ目の項目では「ユーザーが入力したり決定したりしやすいように予め適切な設定をしておきましょう」というようなことが書かれている訳です。そしてこの項目を実現するための推奨事項が複数点挙げられ、更に推奨事項を理解しやすくするために実施例がほぼ全項目2点以上挙げられています。 このように7つの原則が複数の項目に詳細化され、各々に例が複数示されるため、全部で141点もの例が掲載されるに至るわけです。 しかも、この例が工夫されていて、異なったインタラクティブシステムや別手段による対応策について述べられているので異なる観点から原則について考えることができます。推奨事項を「～は実現できているか？」といった形でチェック項目にし、例のいずれかを自分たちのサービスや製品に当てはめた書き方にするだけでかなり使えるチェックリストが出来ると思われます。 附属書A(参考)　この規格の推奨事項を適用するためのチェックリスト 前項で「かなり使えるチェックリストが出来ると思われます」と書かせていただきましたが、なんと本JISにはすでに付録としてこのチェックリストがついています。それが「この規格の推奨事項を適用するためのチェックリスト」です。 このページをコピーするだけでチェックリストとして使えます。ただし、例は掲載されていません。ツマミとしては、例を是非ご自身のサービスや製品に適した事例に書き換えていただいてチェック項目に追加することをお勧めします。事例を考えることが自身の勉強にもなりますし、チェックリストを利用する方に対して適切な利用に関するハードルを下げる事にもつながります。 参考文献 本JISを策定するための参考文献となった33点の資料が並んでいます。もし、本JISに触れて更に色々と知りたいとなったならこれらの資料にも是非あたってみてください。 JIS Z 8530「人間工学－人とシステムとのインタラクション－インタラクティブシステムの人間中心設計」はいつかこのJISさんぽでも取り上げたいと考えております。 附属書JA(参考)　JISと対応国際規格との対比表 本JISとISO9241-110:2020との対比が一覧表となっています。大きく2点が追加となっていて、1点目は「ユーザーエンゲージメント」、定義が追加されています。 2点目は「自己記述性」、分かりづらいから「インタラクティブシステムの自己記述性」としたと書いてあるのですが、まだわかりづらいかもしれません。 インタラクティブシステム＝自己なんですよね。インタラクティブシステムが今どうなっているのか、期待する結果を得るためにはどうすればよいのか、といったことをインタラクティブシステム自身がユーザーに分かりやすく情報提供しているかといったことなのですが、「記述性」という言葉が案外難しい。自己記述性に関する問題に気づきやすいよう、指摘しやすいよう例を読み込んで言葉の意味を説明できるようにしておかないと今後手こずりそうな気がします。 以上がJIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」となります。 今日見つけた宝物： 「代替テキスト 」 このJISの4章に図が示されている ※1 のですが、この図について「代替テキスト ※2 」が記載されていました。 音読アプリを使えばどんな図が記載されているか分かるようになっている点はアクセシビリティに関する規定として「あらまほしきことなり（望ましい、理想的である）」と感じました。 JISは登録すれば無料で閲覧できるPDFファイルが提供されていますが、同様に音声ファイルも提供されています。代替テキストがあれば音声ファイル利用者も使い勝手が良いですよね。 ※1：参照文献の図1：ユーザーシステムインストラクションのための指針に関する主要な情報源の関係 ※2：代替テキスト　画像をテキストによって説明したもの 最後までお付き合いくださりありがとうございます。本日の道行きはいかがでしたでしょうか。次のさんぽはJIS Z 8522「人間工学－人とシステムとのインタラクション－情報提示の原則」を予定しております。次回またご一緒できることを楽しみにしております。 参照： JIS Z 8520 インタラクションの原則 The post JISさんぽ (01) JIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」 first appeared on Sqripts .

こんにちは。チュンです。 オンラインで開催されたソフトウェア品質シンポジウム2023の本会議に参加してきました。 複数の講演や発表を聴講しましたが、基調講演と当社社員が登壇した発表についてご紹介します。 参考までに、 昨年の参加レポート です。※参加レポート内のソフトウェア品質シンポジウム2022の公式サイトは、 こちら に変更されています ソフトウェア品質シンポジウムとは ソフトウェア品質シンポジウム とは、1981年から開催されている日本科学技術連盟主催の歴史あるシンポジウムです。 今年で42回目を迎え、本会議前日の9/6に（今回は9/2(土)も）併設チュートリアルが開催され、本会議が9/7〜9/8の2日間で行われました。本会議1日目の終了後には、本会議Special Talk Session (STS)も行われました。 本会議レポート 基調講演について 今回の基調講演は 狩野 紀昭先生の「Kano Modelから品質について学ぶ！」でした。 狩野先生の講演を直接聴講できる貴重な機会です。 品質の概念として学習したことはありましたが、聴講前におさらいをと思い、ChatGPTで「狩野モデル」で確認してみたところ、ほしい回答が得られず…。 「Kano Model」で確認してみると難なく回答が得られました。まさに世界的な「Kano Model」であることを実感した次第です。 「Kano Model」の誕生 「Kano Model」の誕生について、狩野先生のこどもの頃の品質の思い出から始まり、「魅力的品質と当り前品質」の論文が学会誌に掲載されたところまでを語ってくださいました。 研究のきっかけとなったのは、 こども時代からの期待である「すぐに壊れる玩具を作らない」（よい品質とは壊れにくいものという期待をもって育った） 「品質不良の低減」 これらが、学生時代に学んだ「消費者を満足させるという品質」と同じであるということにギャップがあった、というところからだそうです。 「消費者を満足させるという品質」は、品質不良を低減するなどというだけでは十分ではなく、『「不満をもたらす品質」と「満足を与える品質」は異なる』という漠然とした考えから始まったとのことでした。 その後、ハーズバーグの動機付け・衛生理論に出会い、疑問を解明できるかもしれない、ということから研究を進めて論文を提出したそうです。 …が、品質管理分野以外の文献調査が不足しているとの理由で却下されたことがあるとのこと。 他の分野には明るくなかったようですが、研究室でアルバイトをしていた方から哲学者のアリストテレスにたどりつき、最終的に論文が認められるに至ったとのことでした。 そのアリストテレスが「形而上学」で主張していた質についての内容から、「品質とは、ある事物に関して２つの品種が存在する時、それらの種差を指す」ということを、アリストテレスの品質論として説明してくださいました。 魅力品質のライフサイクル Kano Modelの特徴として、品質要素を二次元で図式化していることがあげられます。 各品質要素を図解すると以下のようになります。 一元品質：ないと不満、あれば満足なもの 当り前品質：ないと不満、あっても満足とならないもの 魅力品質：なくても不満にはならないが、あると満足なもの 無関心品質：あってもなくても不満にも満足にもならない。関心がないもの 魅力品質理論図解 この魅力品質理論ですが、多くは「無関心品質」として生まれてそのまま終わってしまうことが多いようです。 ただ、その「無関心品質」の一部は「魅力品質」となり、さらにその「魅力品質」が「一元品質」に、いずれはそれが「当り前品質」になる、というようなライフサイクルがあります。 この魅力品質のライフサイクルについて、狩野先生が大学で講義していた時代に、他の品質関連に関する内容と比較すると学生の理解力に問題があったそうです。 狩野先生は学生が理解できないのは教える側が悪い、として、どうやったら理解が深まるのかについて、「MaryとJohnの恋の物語」として二人の恋の変化に例えて解説するようにしたところ、学生の理解力が大幅に上がったとのことでした。 それまでとは異なる雰囲気の資料で驚きましたが、確かにこれならわかりやすい、と感じました。 余談ですが、自分も教える側になることがあります。 なかなか理解してもらえない、と思うこともありますが、教える側が悪い！と断言された狩野先生のことばにグサッときました。 教える側として改善しなければいけないですね。 競合優位としての品質の歴史的変化 競合優位としての品質は歴史的に変化しているという、品質の3レベルについてのお話もありました。 第1レベル：品質統制（顧客苦情解消、製品の基本的要件への適合） 第2レベル：品質管理（顧客満足、顧客の明示要求の実現） 第3レベル：魅力品質創造（顧客歓喜、顧客の潜在要求の実現） 第2レベルが出てくると第1レベルは当たり前になる、というように、品質競争は変化するというお話でした。 品質は第1レベルから第2レベルへ発展し、さらには第3レベルとなるように発展してきたとのことです。 これらの話の中で、突如「BFの3レベル論」という資料が提示されたのですが、BFって？と思っていたら、「BoyFriend」のことでした。 品質3レベル論をいろいろな3レベルに例えるようにレポートを書かせた際、学生が考えた場合の例として提示されていたものです。 このようにくすっと笑ってしまうような内容が講演中のところどころに含まれており、狩野先生の人柄が垣間見えたようでした。 まとめ（業務における「品質」を考えてみた） ご紹介しきれていない内容もありますが、基調講演では全体的にハードウェアを前提としてお話しされていました。 基調講演後には「ソフトウェア、サービスにおける魅力的品質とは？」というパネルディスカッションもあったのですが（こちらはSNS禁止のため割愛）、ソフトウェアやサービスにも大きく関連する内容です。 別の一般発表や講演で、狩野先生のお話を引き合いに出されている方も複数いらっしゃいました。 論文発表当初から時間は経過していますが、現時点でも色褪せずマーケティングの場でも活用されていることなどを考えると、狩野先生から直接お話を聴けたことは本当に貴重でした。 自分自身は、テスト業務を担当しています。 お客様が開発した製品に対するテストの依頼を受け、テストを担当することが多いです。 品質管理として「品質不良の低減」のための業務であり、「不満をもたらす品質」にあたるものだと考えます。 そのため、今回のお話のメインである「魅力品質」を意識して業務することはほとんどありませんでした。 今回のお話を聴いて、少し視点を変えてみました。 そもそも、お客様から依頼されている「ソフトウェアテスト業務」そのものの品質を考えてみると、お客様からの期待や要望という意味では、この「魅力品質」に関連するのではないかと。 お客様から依頼されたテスト業務そのものに対して、最低限の成果を出すということは「当り前品質」であり、期待に対して成果を出すことが「一元品質」にあたるのかなと思いました。 お客様との会話の中から潜在的な要求を読み解くことができ、それらに対応することができれば、それは「魅力品質」になるのではないのかと。 長期間担当する場合には、ライフサイクルとして変化することもありそうです。 業務に対する姿勢として、「当り前品質」をこなすことはもちろんですが、一元品質や魅力品質にも対応できるようになるため、日々精進していく必要があると感じました。 ※注：本文内の表記について、論文名やパネルディスカッションの名称は「魅力的品質」、その他は講演中の資料に提示されていた「魅力品質」としています。 林 尚平さんの発表について 本会議2日目には、当社社員の林 尚平さんによる経験発表がありました。 発表のテーマは、 IoT技術を用いた組込み系製品のラズベリーパイを使用した自動化の問題点と解決方法 です。 林さんは本Sqriptsにおいてスクリプターとしても 記事 を執筆しており、テスト自動化エンジニアとして活躍しています。 こちらの特集もおすすめ！ ■ 【連載】自動テストはなぜ失敗するのか。失敗事例からひも解く成功への道筋 Sqripter：林 尚平 問題点 IoT組込み系製品のテストを自動化するためには、自動化ツールを製品やサーバ、シミュレータといった機器と連携させる必要がありますが、ラズベリーパイを用いて自動テスト環境を構築したとのことでした。 テスト自動化の導入にあたって選定した自動化ツールでは、前提条件の設定やテスト実行結果の確認ができないことが判明したようですが、他の自動化ツールでは代用できないことを自動化できるといったメリットがあったことから、その自動化ツールを用いた環境構築ができないかを検討し、「AutoIt」と連携させることで不足する機能追加の対策をしたそうです。 これにより、自動テストの導入としては成功できたようなのですが、その後の運用フェーズでエラーが多発してしまったとのこと。 エラーの要因としては、テスト対象が数十機種にもおよんでいたこと、ツールを２つ連携させたことにより環境構築が複雑になってしまい、ヒューマンエラーが発生してしまったことなどが挙げられていました。 解決方法 解決のために着目したこととして、できるだけシンプルなテスト自動化環境を構築することが望ましいとのことで、自動化ツールの選定について検討し、AGESTのプロダクトである TestArchitect を利用する方法を紹介しています。 TestArchitectであれば、ハーネス機能によりラズベリーパイを制御する機能を取り込んで使用することができるため、環境構築をシンプルにすることが可能となります。 まとめ 自動化ツールの選定については、プロジェクトの状況などにもよると思いますが、導入だけではなく、運用まで見据えることも重要な要素であると改めて感じました。 TestArchitectは、デスクトップやWebアプリケーションをはじめ、モバイルにも対応しており、幅広いシステムの自動化が可能なツールです。 現在はこれらのシステムに利用されているケースが大半ですが、林さんの発表のとおり、ハーネス機能を用いることで組込み系製品の制御が技術的に可能であることが判明しました。 TestArchitectが組込み系製品の自動化ツールとして利用できることは、まだまだ知られておりません。 本記事をご覧いただいた方で気になった方がいらっしゃいましたら、ぜひお問い合わせください。 お問い合わせ先 さいごに ご紹介した内容以外にもたくさんの講演や発表がありました。 基調講演や特別講演はもちろんですが、一般発表として多くの品質に対する考え方などを聴講することで、「基本の本質を学び、 見つめなおす場をご提供します」という開催概要にもあるように、日々の業務を見つめなおす学びの場となりました。 同時間帯に聴講したい内容が重なっていたこともあり、悩ましくもありましたが、アンケートに回答してアーカイブ視聴特典をいただいたので、アーカイブでさらに学びたいと思います。 The post 狩野モデル（Kano Model）から考えるテストエンジニアの”品質”　～ソフトウェア品質シンポジウム2023参加レポート～ first appeared on Sqripts .

はじめに 前回は、自動販売機を題材にして、BDDを用いたプロセスの「発見(Discovery)」の部分（2.要件ワークショップ）までを説明しました。 今回は、「3. 定式化(Formulation)」の部分を、BRIEFの原則を交えつつ説明します。 3. 定式化 定式化では、システムの振る舞いの例（実例マッピングでいう具体例の部分）をシナリオの形で文書化します。 例えば、以下のような実例マッピングができた時に、書かれてある具体例「550円を入れて120円のコーラを選ぶとコーラと430円のお釣りが出る」をシナリオの形で文書化します。 例えば、Gherkin記法を用いて以下のように書けます。 Feature: 自動販売機 Scenario: 飲み物を買うとお釣りが出る Given 自動販売機がある When 500 円硬貨を入れる And 50 円硬貨を入れる And コンボボックスから 120 円の "コーラ" を選択する Then "コーラ" が出てくる And 100 円硬貨が 4 枚出てくる And 10 円硬貨が 3 枚出てくる Gherkin記法 Gherkin記法とはGiven/When/Thenなどのいくつかのキーワードを用いて、実行可能な形式で記述する構文方法です。 今回は、以下の6つのキーワードが登場します。 Feature…ソフトウェアのフィーチャーの概要を記述するためのキーワードです。 Scenario…ビジネスルールを表す具体例を記述するためのキーワードです。 Given…システムの初期段階やシナリオの前提を記述するためのキーワードです。 When…実際に行うアクションや操作を記述するためのキーワードです。 Then…期待される結果を記述するためのキーワードです。 And…複数のGiven/When/Thenに値する内容が出てきた時には、この「And」のキーワードで繋げます。 例えば今回書いた内容の場合、以下のような内容を説明していることになります。 自動販売機についてのフィーチャーです。 「飲み物を買うとお釣りが出る」という具体例について記述します。 「自動販売機がある」という前提があります。 以下の操作を行います。 「500 円硬貨を入れます」 「50 円硬貨を入れます」 「コンボボックスから120 円のコーラを選びます」 すると、以下の結果が期待されます。 「コーラが出てきます」 「100 円硬貨が 4 枚出てきます」 「10 円硬貨が 3 枚出てきます」 シナリオを改善する さて、今回Gherkin記法で書いたような以下のシナリオがあれば全て大丈夫なのでしょうか。 Feature: 自動販売機   Scenario: 飲み物を買うとお釣りが出る     Given 自動販売機がある     When 500 円硬貨を入れる     And 50 円硬貨を入れる     And コンボボックスから 120 円の "コーラ" を選択する     Then "コーラ" が出てくる     And 100 円硬貨が 4 枚出てくる     And 10 円硬貨が 3 枚出てくる このままでも実行可能なテストを作成していくことが可能ですが、もう少しシナリオの改善を考えることができます。 自分一人で考えても良いですが、他の人からフィードバックを得ながら進めるとなお良いでしょう。BDDを用いたプロセスの「#4. レビュー」の部分に該当します。 シナリオを改善する時の参考になるのが、BRIEFの原則です。 BRIEFの原則 BRIEFの原則とは、シナリオをより良くするために考えられた経験則です。それぞれの頭文字5つとBriefという言葉自体の計6つからなります。以下の説明は、「 【翻訳記事】テスト自動化の対象となるテストシナリオの整理に役立つBRIEFの原則 （原文は Keep your scenarios BRIEF ）」から引用。 Business language（ビジネス言語）…ビジネスチームのメンバーが明確に理解できる用語を使用すべきです。 Real data（実際のデータ）…具体的な実際のデータを使用すべきです。 Intention revealing（意図を明らかにする）…シナリオのアクターが達成しようとしている意図を明らかにすべきです。達成する方法のメカニズムを説明するのではありません。 Essential（必須）…シナリオの目的は、ルールがどのように振る舞うかを説明することです。 この目的に直接関与しない部分は偶発的なものであり、削除すべきです。 Focused（焦点を絞る）…ほとんどのシナリオは、1つのルールの説明に焦点を絞るべきです。 Brief（簡潔である）…ほとんどのシナリオを5行以下に制限することをお勧めします。 【翻訳記事】テスト自動化の対象となるテストシナリオの整理に役立つBRIEFの原則 今回のシナリオにBRIEFの原則を適用して改善する それではBRIEFの原則に当てはめて今回のシナリオを改善していきましょう。 ビジネス言語を用いる(Business language) 今回のシナリオの中で「コンボボックス」という単語は、実際の画面を想定して表現しており、ビジネス言語ではありません。また、コンボボックスでなくチェックボックスなどであっても今回行いたい内容を満たすことができます。そのため、以下のようにシナリオを改善します。 Feature: 自動販売機   Scenario: 飲み物を買うとお釣りが出る     Given 自動販売機がある     When 500 円硬貨を入れる     And 50 円硬貨を入れる      And コンボボックスから 120 円の "コーラ" を選択する      And 120 円の "コーラ" を選択する     Then "コーラ" が出てくる     And 100 円硬貨が 4 枚出てくる     And 10 円硬貨が 3 枚出てくる 意図を明らかにして(Intention revealing)、必須(Essential)の目的のみに焦点を絞って(Focused)記述する 今回のシナリオで示したい目的は、「飲み物を買うと飲み物の値段を引いた金額だけお釣りが出る」ということです。重要なのは金額であり、どんな硬貨が出てくるかは今回のシナリオの意図ではありません。そのため、以下のようにシナリオを改善します。 Feature: 自動販売機 Scenario: 飲み物を買うとお釣りが出る Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る Given 自動販売機がある When 500 円硬貨を入れる And 50 円硬貨を入れる When 550 円を入れる And 120 円の "コーラ" を選択する Then "コーラ" が出てくる And 100 円硬貨が 4 枚出てくる And 10 円硬貨が 3 枚出てくる And 430 円が出てくる なお、どんな硬貨が出てくるかを示したい場合は、別のシナリオとして記述を検討すべきでしょう。おそらく、「発見(Discovery)」に立ち戻って、実例マッピングでいう具体例（緑色の付箋）やルール（青色の付箋）を追加することになると思います。 結果として簡潔(Brief)なシナリオになっている 改善した結果、以下のようなシナリオになりました。 Feature: 自動販売機   Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る     Given 自動販売機がある     When 550 円を入れる     And 120 円の "コーラ" を選択する     Then "コーラ" が出てくる     And 430 円が出てくる これを見ると、シナリオ自体は5行に収まっており、簡潔になっています。 「BRIEFの原則は必ず全て守るべき」ではない BRIEFの原則は必ずしも全て適用すべきではありません。 例えば今回の場合、シナリオで示したい目的は「飲み物を買う」ということなので、必須(Essential)の原則に従うと「コーラ」を指定する必要がありません。一方で、実際のデータ(Real data)の原則に従うと、「コーラ」という具体的なデータを用いた方が良いと思われます。 このように、原則の一部は排反する可能性があるので、その場に適した内容を適宜考えてください。 おわりに　〜BDD以外でもBRIEFの原則を活用する〜 今回は「3. 定式化(Formulation)」のプラクティスとして、Gherkin記法のシナリオをBRIEFの原則に従って改善していきました。 なお、BRIEFの原則はBDDの場面以外での活用も考えると良いでしょう。例えば、TDDやUnitテストの作成時には、色々なことが気になりすぎた結果、テストの意図(Intention revealing)が明らかになっていないことが多々あります。 ぜひ、そのような場面でもBRIEFの原則を活用してみてください。 連載一覧 TDDとBDD/ATDD(1)　TDDはテスト手法ではない TDDとBDD/ATDD(2)　2種類のBDD TDDとBDD/ATDD(3)　BDDとATDDとSbE TDDとBDD/ATDD(4)　ツールとしてのBDDとプロセスに組み込まれたBDD TDDとBDD/ATDD(5)　BDDのプロセスその1「発見(Discovery)」と実例マッピング TDDとBDD/ATDD(6)　BDDのプロセスその2「定式化(Formulation)」とBRIEFの原則 The post TDDとBDD/ATDD(6)　BDDのプロセスその2「定式化(Formulation)」とBRIEFの原則 first appeared on Sqripts .

こんにちは、QAエンジニアのカンパチロックです。 今回は、マイクロサービスアーキテクチャにおける通信の品質保証としてCDCテストと、その実行において規模や多機能性に応じて一般的に使用されるツールである Pact の使用についてのワークショップを紹介します。このワークショップを通じて、CDCテストとPactの基本的な使い方や有用性を紹介できればと思います。 マイクロサービスとCDCテスト マイクロサービスアーキテクチャは、開発の効率化、デプロイメントの簡易化、そしてスケーリングの容易さをうたった誘惑的な選択ですが、サービス間の適切な通信はシステム全体のスムーズな運用に不可欠です。その中心に位置するのが、Consumer Driven Contract (CDC) テストです。 CDCテストは、各サービスが他のサービスとの通信契約を順守しているかを確認し、システム全体の信頼性と安定性を向上させる有効な手段です。そして、CDCテストを容易に実施できるツールとして、Pactが広く活用されています。 この記事では、Pact Workshop JSを用いてCDCテストを行うための知識と具体的な事例についてご案内します。深く理解や体験を通じて、マイクロサービスアーキテクチャを検討する開発者さんたちの視野を広げ、より豊かな選択肢を提供できればと考えています。 CDCテストの基本 Consumer Driven Contract (CDC)  テストは、マイクロサービス間の相互通信をテストするための方法論です。このテストでは、各サービス（ここでは”コンシューマー”）が他のサービス（”プロバイダー”）との間で期待する通信の動きや振る舞い、すなわち”契約”を定義します。この手法の目的は、サービス間の通信が予期された方法（つまり契約に従って）で行われることを保証することです。 CDCテストの一般的なフローは以下の通りです。 契約の定義 ：すべては、コンシューマーがプロバイダーに期待する振る舞いを正確に規定する契約の定義から始まります。この契約は、具体的には特定のリクエストに対する期待されるレスポンスを示す仕様となるべきです。この手間をかける理由は、明確な契約によりコンシューマーとプロバイダーの間の誤解や食い違いを最小化し、次の段階であるテストの成功率を高めるためです。 コンシューマーによるテスト ：次に、コンシューマーは上記の契約を基にしてテストケースを作成し、実行します。このステップでは、期待したレスポンスがプロバイダーから正確に返すことができるか、システムの限界をテストすることが目的です。この結果により、コンシューマーは契約が正しく機能することを確認でき、信頼性の高いコードをプロバイダーサイドに提供できます。 契約の共有 ：テストが無事合格した後、コンシューマーは契約をプロバイダーと共有します。このステップは、双方向のコミュニケーションと協調を促進し、広範で一貫性のある結果を生むために不可欠です。 プロバイダーによるテスト ：最後に、プロバイダーは受け取った契約に基づいて、自身のテストケースを作成し実行します。このステップでは、プロバイダーが契約仕様を適切に遵守していることを確認します。これにより、双方のマイクロサービス間の信頼性が高まり、安全なプロダクション環境への適用が可能となります。 Pactの特性 CDCテストの基本を理解したところで、次に紹介するのは、CDCテストを実施するための強力なツール、Pact( https://docs.pact.io/ )です。 Pactは、CDCテストを効果的に実施するためのオープンソースのフレームワークです。主に、コンシューマーとプロバイダー間の契約を定義し、その契約が適切に遵守されていることを確認するためのテストを作成、実行、検証する作業を容易にします。 出典： https://docs.pact.io/ Pactのもう1つの大きな利点は、言語に依存しないことです。これにより、異なる技術スタックを持つマイクロサービス間でも使用することができます。さらに、視覚的に理解できるテスト結果を提供し、契約違反が発生した場合にはその詳細を明示します。これにより、開発者は問題を素早く特定し、その修正に努めることができます。 しかしながら、この章ではPactの全機能について詳しく説明するのではなく、PactがCDCテストをどのようにサポートするか、そしてそれがなぜ重要なのかに焦点を当てたいと思います。Pactの詳細な機能や使用方法については、 公式ドキュメンテーション をご覧ください。 ワークショップ紹介 これまでに、CDCテストとPactについて説明してきましたが、まだ、これらの概念が抽象的に感じるかもしれません。そこで、このセクションからは具体的な実践体験を通して、Pactの使用方法とCDCテストのメリットをわかりやすく説明します。 Pact Workshop JSは、CDCテストの実践的な運用を体験できるワークショップです。ここでは、Pactを使用したマイクロサービス間の契約の定義方法とそのテスト方法を体験できます。このワークショップは、現場で直接応用することができる知識とスキルを得るためのネタ足しとなります。さらに、約60分で完了できるよう設計されています。 ワークショップのレポジトリは以下からアクセスできます。 https://github.com/pact-foundation/pact-workshop-js このハンズオンワークショップは、Pactを使ってCDCテストを体験する機会となります。 CDCテストを正確に理解し、適切に設定することでマイクロサービスの信頼性を向上させることができます。この機会をぜひ活用して、CDCテストの実践的な運用を体験してみてください。 準備手順 ワークショップの為の準備は、Pact Workshop JS公式ののgithubに記載されておりますが、以下のソフトウェアのインストールが必要となりますので、事前にインストールして下さい。 Docker Docker Compose Node + NPM ソフトウェアを全てインストールしたら、次に下記のコマンドを実行し、ワークショップのリポジトリをcloneしてください。 git clone <https://github.com/pact-foundation/pact-workshop-js.git> 以上がワークショップの準備手順になります。これで準備は完了です！ 学習内容 Pact Workshop JSは、Pactを使用したConsumer Driven Contract (CDC) テストの具体的な手順と例を学ぶためのワークショップです。このワークショップは11のステップで構成されていますが、それらは以下の4つの主要なフェーズに分かれています。 ステップ1 – 5: Pactの利用の基本 ：このフェーズでは、コンシューマとプロバイダの間で通信の契約を定義し、それに基づいてテストを作成、実行、検証します。これにより、Pactを利用したCDCテストの基本的な流れを理解します。また、コンシューマとプロバイダ間の通信契約がしっかりと担保されることを確認します。 ステップの実施内容としては、コンシューマ側のエンドポイント名の誤認識により結合テストが失敗する状態をスタートとして、PactによるCDCテストにより問題の検知・解消を行うところまでが含まれていますので、CDCテストの有益性を確認する上では十分な内容と思います。 ステップ6 – 7: データ状態(stateHandlers)を利用したテスト ：次のフェーズでは、プロバイダ側に格納されているデータの状態に応じたテストを行います。これにより、データ状態と応答データの関係性の検証をPactで行う方法を学びます。具体的には、対象のIDの商品が存在しないケースや、商品が全くない場合のケースについての実装を行います。 APIのエンドポイント、リクエスト、レスポンスの形式などは、IDL(Interface Definition Language)を利用することで静的な検証を行うことが可能ですが、データの状態に基づくレスポンス内容は動的な性質を持つため、テストでの検証が必要となります。PactではstateHandlersの機能を利用することで、これらの動的なレスポンスを効率的にテストすることが可能となります。 ステップ8 – 10: 動的なデータについてのテスト ：この段階では、動的なデータ（例えば、認証トークンなど）についてのテストを行います。この段階では、動的なデータを扱うテストケースでPactをどのように利用するかに焦点を当てます。具体的には、APIの認証機能としてタイムスタンプを含むトークンの組み込みをユースケースとして考えます。ここでは、このような問題を解決するためにPactをどのように活用するかを学びます。 ユニットテストで期待値を検証する際、日付情報や一時的な認証トークンのような動的なデータの取り扱いは常に課題となります。PactではRequestFilterという機能を使ってこれらの動的な要素に対応したテストを実装することが可能です。これにより、テストの信頼性と精度が大幅に向上し、問題解決の手間を削減できます。 ステップ11: Pact Brokerを利用した効率的なPactファイルの管理 ：最後のフェーズでは、Pact Brokerを導入し、Pactファイルの管理を効率化します。Pact Brokerは、Pactファイルのバージョン管理、共有、検証結果の追跡などを行うことができ、複数のサービスやチーム間での契約テストを容易にします。さらに、Pact BrokerはCDCテストの結果を一元的に管理し、それを基に自動的にデプロイを許可するか判断するなど、CI/CDパイプラインとの統合を強力にサポートします。これにより、CDCテストの結果を直接CI/CDプロセスに反映させることが可能となり、開発プロセス全体の効率化に寄与します。 ワークショップでは、Pactのテストが意図的に失敗する状況も設けています。それらを「なぜテストが失敗するのか？」を自己学習の一環として理解することが求められます。 このように、各ステップを順次進めながら、Pactの使用方法とその有益性を深く理解することが、このワークショップの主な目的です。 体験と洞察 ワークショップを終えてみて感じたのは、CDCテストの全体的なフローを理解し体験することができ、さらにはPactを使用して契約を定義し、テストを作成、実行、検証する方法を学ぶことが非常に有益だったということです。 このワークショップの最終段階でPact Brokerの組み込みを行ったことにより、「最後にいつCDCテストが行われたか？」や「どのバージョンのプロバイダと接続を確認したか？」といった情報をWeb上で簡単に確認できるようになったのも大きな収穫でした。 また、ワークショップで学んだことは基本的な例にすぎません。実環境のCDCテストは、さらに多くのシナリオをカバーできると思います。特に、マイクロサービス環境では、CDCテストによって実現されるサービス間のネットワークグラフは、各サービスの接続状況を一覧表示することに非常に役立ちます。 その為、このワークショップが期待以上に価値ある体験であったと感じています。 出典： https://github.com/pact-foundation/pact_broker#network-diagram 最後に 今回は、 Consumer Driven Contract (CDC) テスト と Pact に関するワークショップについてご紹介いたしました。これらの知識とツールが、あなたの開発プロセスを更に丁寧で、効率的なものに進化させ、より高品質なソフトウェア作りに貢献することを心から願っています。 このワークショップを通じて、新たなスキルを獲得し、自身の技術スタックを拡張するための第一歩となることを期待しています。どうぞ、この機会にワークショップを試してみてください。 The post CDCテストに触れてみよう。Pact JS workshopを利用したCDCテストの実体験 first appeared on Sqripts .

前回の記事（ テスト自動化とテスト設計【前編】～作成済のテストケースの整理と加工 ）では、テスト自動化のために既存のテストケースを整理・加工する際のポイントについて説明しました。 今回はテスト自動化を前提としてテスト設計（およびそれに伴うテスト計画やテスト分析の見直しなど）を行う際の方法について考えます。 これまでの連載記事とは異なり、「こうするとよい」「こうしましょう」といった、わたしの経験や一般の知見に基づくノウハウの共有という意味合いは少なくなっています。 むしろ、「わたしはこう考えて、こんなことをやっている。世の中ではこんなことが言われている。みなさんはどうですか？」といった、半分は読み手の皆さまへの問いかけとして本記事を書いています。 これをきっかけに、テスト自動化を前提としたテスト設計について情報の流量が増え、議論が活発になればうれしいです。 テスト自動化とテストプロセスとの関連についてあらためて整理 テストエンジニアやQAエンジニアの間でも、テスト自動化を業務で行っている方や経験がある方が増えているようです。 ソフトウェアテスト自動化カンファレンス2022アンケート結果サマリー より テスト自動化研究会が行ったアンケート結果の毎年の推移をみると、テスト自動化の経験がない方は少しずつですが下がっています。 しかし、テスト自動化が普及している一方で、テストエンジニアが普段の業務で扱っている「テストプロセス」と、「システムテストの自動化」とを完全に別のものとして考えてしまっている場合があるように思います。 上の図に近い形の方法が、 前回の記事 でご紹介したやり方です。 ただ、これも前回の記事で何度か触れたように、このやり方で進める場合はデメリットもいくつか考えられます。たとえば自動化をする際の手戻りが多くなるリスクがありますし、暗に「手動実行の効率化・工数削減」という視点で考えてしまいがちでもあります。 本記事でお伝えしたいことのひとつは、先の図における「手動テストの世界」と「自動テストの世界」は別々のものではなく、下図のように同じプロセスで検討されるべきものである、という点です。 テスト設計の先が2つに分岐していますが、実際には先の図で「手動テストの世界」として表現したテストプロセスと、そのアウトプットやフェーズには大きな違いがありません。 つまり、テストプロセスのアウトプットをあとから自動化向けに加工するのではなく、テスト自動化を考慮してテストプロセスに沿って進み、手動・自動それぞれのアウトプットを作成するほうが効果的ということです。 手動実行が前提のテスト設計と、自動化を考慮したテスト設計との違い 手動実行が前提のテスト設計、つまりテスト手順をあとから自動化するパターンの場合と、自動化を考慮したテスト設計とでは何が異なるのでしょうか？テスト分析やテスト設計の段階で自動化について考えておくと、どんなメリットがあるのでしょうか？ ひとつは、 前編 で触れた – 手順や期待結果の具体化 – 順序や依存関係の整理 などが後追いではなく最初から行えるという点です。 他にも、以下のような違いが考えられます。 テストの範囲が広がる・網羅度合いが高まる 手動実行を前提としてテスト設計を行うと、プロジェクトの現実的なリソースでできる範囲でテストケースを作成する場合があると思います。 自動実行によって効率的に実行できるのであれば、本来やりたかった範囲をすべてテストする、網羅度合いを高めるといった選択ができるかもしれません。手動実行時に比べてテストケースの量を増やすことができる、とも言えます。 もちろん、テストは多ければ多いほど良いわけではありません。しかし、手動実行ではリソース等の制約があってできなかった範囲・量のテストが実行できる可能性が生まれる点は、メリットと考えられます。 実行頻度・フィードバックサイクルを増やせる テストの範囲や網羅度合いに加えて、実行頻度やフィードバックサイクルを増やせる、というメリットがあります。 手動でシステムテストを実行する場合、たとえば「システムテストフェーズ」として一定の期間を設け、この期間内にシステムテストをすべて完了させるというやり方があります。その場合、テストケースもシステムテストフェーズで1回ずつ実行される前提で作成します。 しかし、自動実行を考慮してテスト設計を行うことで、「システムテストフェーズで行うテスト」というひとかたまりのテスト設計ではなく、より段階を分けて考えることができます。リグレッションテストに相当するテストをCIパイプラインに組み込んだり、もしくはステージング環境で毎晩実行したりと、テストの目的や内容に応じて実行タイミングや頻度を分け、増やすことができます。 自動化を考慮したテスト設計のポイント これらのメリットを得るために、テスト分析やテスト設計の段階から自動化を考慮しておくことが大切です。 自動化を考慮してテスト設計を行う際のポイントは前述の「手動実行が前提のテスト設計と、自動化を考慮したテスト設計との違い」がほぼそのまま該当します。 ただ、ここまでに出てきていない注意点としては – 自動化によって抜けがちな観点に注意しましょう ということをお伝えしておきます。 手動実行向けのテストを自動化する際にも同様の注意が必要になりますが、テストを自動実行することによる実行効率UPと引き換えに、手動実行時に人間が暗に確認しているさまざまな観点が抜け落ちることになります。 単純な例で考えると、たとえばテスト設計時に「ログイン処理は簡単に自動化できるから、自動実行するテストとして設計しよう」と考えたとします。そうするとログインに関するテストは自動実行でカバーできているからOK！と思いがちですが、ログイン処理における画面表示の問題などは単純な自動テストスクリプトでは見逃されてしまいます。 こうした、自動実行するテストでカバーできていない範囲・観点があるにもかかわらず、機能や画面としては自動テストで見ている、という場合は必要な観点が見逃されがちです。 まとめ 今回はテストプロセス、とくにテスト設計時にテスト自動化を考慮して行う際の考え方等について説明しました。 こうした、テストプロセス中のどのタイミングで、自動化に関するどんなことを考慮するかについてはまだまだ議論や改善の余地があると考えています。 わたしも普段の業務における自動化向けのテストケース設計のやり方はいろいろと模索中で、 過去のテスト設計コンテスト決勝進出チームの成果物 なども繰り返し参照しながらよりよい形を考えています。 本記事がなんらかのヒントになればもちろんうれしいですが、それ以上に「もっとこう考えるべきでは」などいろいろな意見をいただけると、よりありがたいです。 参考 – 自動テストを活躍させるための基礎作りとテスト設計の工夫 – Speaker Deck – テスト設計チュートリアル U-30版 資料 2019 連載一覧 テスト自動化ツールの選定【前編】～ツールの比較表をどう活用するか テスト自動化ツールの選定【後編】～AI自動テストツールを選ぶ時に気をつけるべきポイント テスト自動化の普及と推進【前編】～阻害要因と対策 テスト自動化の普及と推進【後編】～個人レベルでテスト自動化を学ぶ テスト自動化とテスト設計【前編】～作成済のテストケースの整理と加工 テスト自動化とテスト設計【後編】～テスト自動化のためのテスト設計 The post テスト自動化とテスト設計【後編】～テスト自動化のためのテスト設計 first appeared on Sqripts .

JSTQB FL の取得に向けて学習中のみなさん。初めまして、Yoです。 シラバスの読み込みは順調ですか？各項目をしっかり理解できていますか？ JSTQBの学習において、シラバスの熟読は避けて通れません。しかしながら、シラバスは言い回しが少々難解であったり、耳慣れない用語が多かったりとなかなかとっつきにくいものです。私もFL学習の初期には全然理解が追い付かずに苦労しました。 本記事では、シラバスを理解する上で私が個人的につまづいた箇所をかみ砕いて解説していこうと思います。 今回はプロダクトリスクとプロジェクトリスクについて解説します。 シラバスにおいて プロダクトリスクとプロジェクトリスクについて、JSTQB FLシラバスでは以下のように解説されています。 ※少々長いので、箇条書きにされている具体例は割愛します。 プロダクトリスクについて プロダクトリスクは、作業成果物（例えば、仕様、コンポーネント、システム、テストケース）がユーザー、および/またはステークホルダーの正当なニーズを満たすことができない恐れを含む。プロダクトの特定の品質特性（例えば、機能適合性、信頼性、性能効率性、使用性、セキュリティ、互換性、保守性、移植性）に関連するプロダクトリスクは、品質リスクとも呼ばれる。 ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 出典： ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 プロジェクトリスクについて プロジェクトリスクは、発生した場合にプロジェクトの目的達成に悪影響を与える ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 出典： ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 英語の意味を考える シラバスの引用だけではまだ表現が固くて取っつきにくいので、英語の意味を考えていきましょう。 プロダクトは「製品」、プロジェクトは「事業、計画」といった意味の言葉です。つまり、プロダクトリスクは「製品に対するリスク」プロジェクトリスクは「計画に対するリスク」と言い換えることができます。 ※プロジェクトの和訳として、ここでは計画の方を採用しました。 もっと簡単に表現してみる 英語で意味を噛み砕いてみると、それぞれのリスクがどういったものか、多少はイメージしやすくなったのではと思います。更に、それぞれのリスクを「製品」「計画」というキーワードに着目して言い換えてみましょう。 プロダクトリスク = 製品の利用者に害があるリスク、製品の提供者に不都合があるリスク プロジェクトリスク = 計画通りに進まないリスク、計画そのものが抱えるリスク こうして両リスクを言い換えてみると、冒頭で引用したシラバスの記述が理解できるかと思います。 シラバスの例を具体的に考えてみる 言葉の意味の解説が済んだところで、ここでは両リスクが具体的にどういう物かを考えてみます。 先ほどのシラバス引用では割愛しましたが、シラバスには具体例が箇条書きで記載されているので、それらを見てみましょう。 プロダクトリスクの例 プロダクトリスクの例について、シラバスに以下のような記載があります。 特定の計算結果が状況によって正しくないことがある。 ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 これがプロダクトリスクである、と答えありきで言われると、確かにそうかもなと思うかもしれませんが。ヒントなしで何のリスクであるかと答えるためには、両リスクがどの様なものであるかをしっかり理解していることと、例からどの様な事象に発展してしまうのかを想像することが大切です。 この例では、計算の結果が正しくないということですので、以下のような事象に発展する可能性があります。 ショップの購入者への請求額の誤り 在庫数の表示と実態の不整合 これらのようなことが実際に起こってしまうと、利用者は金銭的な損害を被りますし、サービス提供者は機会の損失が発生する可能性があります。これらは「製品」の機能不備によって引き起こされたものであるため、プロダクトリスクになります。 プロジェクトリスクの例 プロジェクトリスクの例としては、以下のような記載があります。 テスト環境が予定した期限までに用意できないことがある。 ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 経験がある方もいらっしゃるのではないでしょうか。予定通りに環境が出来上がらない場合、どういった事態が考えられるでしょうか。すぐ思いつくのは、 テストが遅延する などでしょう。更に言うと、リリース判定、申請、リリース等が後ろにずれてゆき、当初計画していたスケジュール通りに開発が完了しないということが起こりえます。そうなると当然。 開発コストの高騰 等も発生しえます。これらは「計画」に影響を与えるリスクであるため、プロジェクトリスクだと判断できます。 上記の例のように、「どこで」「どの様に」悪影響があるのかを具体的に考えることで両リスクの判断が可能になります。 例題 ここまでで両リスクの説明と、具体例からの判別について一通りの解説ができたので、応用として簡単な例題を解いてみましょう。 以下のうち、プロダクトリスクはどれか A：ループ制御構造が正しくコーディングされていない B：人員のスキルやトレーニング不足 C：ツールによる支援が遅れる D：欠陥や他の技術的負債が累積する それぞれに対し、リスクが何に影響を与えるかと、どの様な問題が発生するかを想像して回答してください。 回答はAです。合っていたでしょうか。 解説になります。プロダクトリスクはどれか、という問いですので選択肢のうち「製品」が直に利用者か提供者に不都合をもたらすリスクであれば正解となります。Aはアプリなどで考えると離脱不可やフリーズなどを引き起こしかねないため「製品」のリスクとなります。故にプロダクトリスクとなります。 他3つのリスクに関して、個別の解説は省きますが、ザックリと言ってしまえば「うまく製造できない」という結果に繋がります。これは「計画」に対するリスクとなるためプロジェクトリスクです。 いかがでしたでしょうか。両リスクはシラバスで取り上げられる例も多いので一つ一つ覚えると大変ですが、内容を理解した上で想像することで問題の難易度がぐっと下げることが可能です。 リスクにどう対処するか JSTQB FL対策というテーマからは若干逸れますが、それぞれのリスクに対して、業務でどのようなアプローチをとると良いのか、リスクを判断できるとどういうメリットがあるのかという話をしたいと思います。 プロダクトリスクに対処する プロダクトリスクに対処するものとして、リスクベースドテストというものがあります。リスクベースドテスト自体もFLで軽く触れられているものになりますが、可能性や影響から優先度を決定していくアプローチになります。ただ、当然ながらリスクベースドテストでなくとも、テストの対象となる機能にはどういったプロダクトリスクがあるかを常に意識することは重要です。 可能性や影響を適切に判断することによって、テスト優先度やテストの詳細度合い等を決定することができるというメリットがあります。例としては、要件レビューに参加し、リスクの観点からレビューを行う、非機能テストの戦略をリスクに基づいて決定するなどです。 プロジェクトリスクに対処する プロジェクトリスクへの対処は、JSTQBでは主にTMで解説される内容のため簡潔に、かつ個人の見解も含むものになりますが、自身が担当する範囲で、何かしら作業が滞る要因は全てプロジェクトリスクです。 阻害となっている要因（たとえばテスト環境構築の遅れなど）を適切に判断することができれば、テスト実行スケジュールの再検討などができるようになり、影響を最小限に抑えることができます。 環境構築はあくまで一例ですが、プロジェクトリスクを判断できるということは、プロジェクトやチームが抱える問題を発見できるということでもあるため、テストコントロールの観点においてもプロジェクトリスクを適切に判断できることは重要となります。 このように、対処のアプローチ、対処することのメリットも異なるため、それぞれの対処法だけでなく、それぞれを正しく「判別」出来ることが重要になります。 まとめ 以上でJSTQB FL対策の第1回、プロダクトリスクとプロジェクトリスクの解説は終了します。あくまで私が受験時に苦戦した内容をまとめているものになるため、「そんなことは知っている」という方もいるでしょうが、私と同じ個所で苦戦している方がいらっしゃいましたら、この記事で理解のお手伝いが出来れば幸いです。 本記事はFL対策と銘打っていますが、テストに向けてというだけでなく、JSTQBの用語理解にも役立てていただければと考えています。JSTQBの用語を基準とすることで認識の共通化を図ることでステークホルダとのコミュニケーションにおいてエラーも発生しにくくなると思いますので、プロジェクト内のポジションに関わらず、用語を深く理解することは重要と考えます。 では、また別の記事でお会いしましょう。 The post JSTQB FL対策 弱点強化解説　～１回目～ first appeared on Sqripts .

こんにちは、エンジニアのタカです。 普段はスクラムマスターや開発者としてプロダクトの開発に関わっています。 チームではスクラム開発を導入しており、今回はNotionでのバックログ管理の話をしたいと思います。 当初のバックログ管理方法 自分が所属するチームでは、バックログは、当初Miroで原案を作ったのちGitHub + ZenHubにて作成し管理していました。 バックログに加えバグや要望も同様にGitHub + ZenHubで管理していましたが、ナレッジやドキュメントはNotionに作成しており、下記のような課題を持っていました。 バックログ、要望、バグが混ざって見にくい バックログとドキュメントを参照するのに複数のサービスを行き来するのは手間がかかる Sprint単位のバックログや状態が把握しにくい 現在のバックログ管理方法 これらの課題を解決するため、バックログ等をすべてNotionに移植し、ボードビューのグループとサブグループを用いて見やすいビューを作成し管理するようにしました。 実際に使用しているビューの形式はこちらです。 ※実データは載せられないため、形式は同じもので仮のデータを入れたものになります。 縦軸に担当者、横軸にSprint、プロパティにはバックログのステータスとindex（通し番号）を表示しています。 また、タイトルにも indexを付与することで、他pageからバックログをリレーションのプロパティとして関連づける際に検索しやすくしています。 ※今は手動で付与していますが、Notion APIを用いれば半自動などでの付与も可能だと思います。 いちいちバックログ名を検索するのは大変ですが、番号で検索することで、スムーズに目的のバックログを表示することができます。 プロパティはこちらです。（最低限のものを表示しています） 担当者は今回のブログ記事用のデータベースを作成して割り当てていますが、Notionのユーザー一覧でも問題ないかと思います。 Tasksは後述する開発者のタスクボードへのリレーションです。 こちらは自分達のチームでは関連付けを追加する機会が多いこともあり、セクションとして表示しています。 なお、今回はページ内容は空白ですが、ユーザーストーリーや受け入れ基準など開発に必要な内容を記述していきます。 要望、BUGの管理 これらはバックログとは異なるデータベースとし、主にテーブルビューで管理しています。 先ほどのプロパティからは省いていますが、バックログのページとリレーションを設けることで、互いに参照ができるようにしていきます。 なお、同じデータベースで管理するのも一つの方法なので、ここを分けるかどうかはチームで運用しやすい方法を選択するのが良いかと思います。 タスクボード 開発チームのタスクも別のデータベースを作成し、バックログと同じ形式のボードビューとして利用しています。 これらに互いにリレーションプロパティを作成することで、開発チーム プロダクトオーナーの情報共有に役立っています。 その他通知設定 Notionではビューの設定で簡単にSlack通知を行うことが出来るため、自分たちのチームではこれを活用しています。 例えばバックログボードやタスクボードのステータスが指定のものに変更されたときにSlackに通知を行なえます。 例として、自分たちのチームではステータスを横軸にした別ビューを作り、ステータスがQAメンバの評価待ちを表す 開発完了 というステータスになったら、QAメンバの居るチャンネルに通知するといった運用を行っています。 おわりに 今回の内容のまとめです。 バックログや要望一覧などをNotionに移植することで、各種課題を解消 データベースを分けた場合も、リレーションを活用することでリンクしやすくする バックログの管理方法にお困りの方は、ぜひ参考にしてみてください。 なお、Notionには継続的に新しい機能が追加されており、以下の2つの機能を今後は試す予定です。 スプリント機能 GitHub連携機能 The post Notionでプロダクトバックログを管理するビューを作成する first appeared on Sqripts .

こんにちは。ゆーてぃです。 2023年9月8日(金)に開催されたJaSST’23 Hokkaidoに参加してきましたので参加レポートを書いてみたいと思います。 テーマ「心動かさる”コト”の品質」 今回のテーマは、「心動かさる”コト”の品質」とし、利用時品質、UI/UX、DevOpsに焦点をあて、ソフトウェアテストと品質の今後のあり方を考えます。 JaSST’23 Hokkaido 北海道外の方がこのテーマを目にすると、「動か さる 」ん？誤字？と思うかもしれませんね。私は生まれも育ちも北海道なので何の違和感も覚えず、よいテーマだなと思いました。 JaSST’23 Hokkaidoの開催要項にも書かれていますが、「～さる」は北海道弁で「自分の意思以外の何かによってそうさせられてしまう」という意味となり、私はよく弁解のためにこの言葉を使ってきました。 おい！なんでそのボタン押したんだよ！→いや、押ささったんだよ！ 私は言い訳に使うことが多く(たぶん？)ネガティブな言葉として捉えてましたが、今年のテーマを見て、ポジティブな表現としても使える良い方言だな、と感じました。そしてソフトウェアを使用する人の心が動かさる仕事がしたいなと思いました。 基調講演「ユーザビリティとソフトウェア品質」 今回の基調講演では、国立研究開発法人理化学研究所革新知能統合研究センター 兼 東京都立大学客員教授／公立千歳科学技術大学客員教授の福住 伸一様が登壇され、様々なユーザビリティの考え方や捉え方、さらにソフトウェアの品質としての利用時品質、製品品質におけるユーザビリティの問題点についてお話をされてました。 DX(デジタルトランスフォーメーション)が注目されている中で、「デジタル化していけばいいんじゃなくて、人間中心に考えていかないとダメだろう」という観点から、どのように考えていけば良いかについて例を挙げながら語られていました。印象に残った内容をピックアップして記事にまとめたいと思います。 人間中心の考え方 1980年代後半から、ユーザビリティという概念が提唱され、当初は「何とかして使えるようにする」という目標から、「使いやすくする」という思想へと変化しました。さらに、視覚的なGUIにとどまらず、聴覚や触力覚などにも広がり、ユーザビリティの捉え方が多様化してきています。 この変遷の中で、顧客との要求明確化に課題があると指摘され、システムの利用に焦点を当て、ユーザビリティやユーザエクスペリエンスを満たすために人間中心設計とインタラクティブシステムの活用が重要だと強調されました。 人間中心設計とは 国際規格ISO9241-210で定められた、 システムの利用に焦点を当て、人間工学(ユーザビリティを含む。)の知識および技法を適用することによって、インタラクティブシステムをより使いやすくすることを目的とするシステムの設計および開発へのアプローチ。とのこと。 人間中心設計では実際に以下のことが重要とお話をされてました。 ・例 発表者(ユーザ)は、限られた発表時間(利用状況)の間に発表を完了させるために(利用目的)、どれだけの時間が残されているか(前提条件)を知る必要がある。ユーザ要求事項は、タイマーを使って、残り時間および経過時間を計測し、視覚的および聴覚的情報として提示する、などとなる。 このように、利用者が誰で、どのような操作や環境で行うかを考慮し、利用状況と関連付けながら要件を抽出し、ユーザ要求事項に合致する設計解を作成、および評価を行う流れを繰り返すことにより、ユーザ要求事項に適した設計につながると述べられました。 所感 利用状況を理解し、要求事項を明確にした上で設計し、評価することは、私たちが担当している機能テストでも同様に重要な要素です。非常に興味深い内容であり、多くの共感を覚えました。そして、何よりも重要なのは、このサイクルを繰り返し、より良いものにしていくことだと感じました。 新しい利用時品質 次に「新しい利用時品質」についてご紹介いただきました。以下の理由から新しい利用時品質の考え方が必要だと述べられています。 従来は製品やシステムが仕様を満たすことで品質が評価されていた(製品品質)。 デジタル化が進んでそれらを「使う」ことの影響が直接のユーザだけでなく、所属する組織や社会にも及ぶようになってきた。 これらの影響をできる限り制御できるようにすることが、組織の社会的責任として感じられる(利用時品質)。 デジタル化が進むことにより使う人の影響範囲が広くなったため、ユーザと製品・システムの1対1の影響ではなく、製品・システム・サービスを利用したことによって、多くの人々や社会など間接的な影響に目を向ける必要があるとお話をされてました。 また、製品品質モデルと利用時品質モデルの動向について、以下のように紹介されました。 品質モデルとして、製品品質モデルと利用時品質モデルの2つが存在する。 製品品質モデルにはusability(使用性)として品質特性が含まれている。 利用時品質モデルではusabilityが使用されていないという問題があった。 製品品質モデルとインタラクションの原則の品質特性であるusabilityに関連する品質副特性が、実質的に製品品質モデルの品質副特性として活用されている。 そのため、製品品質モデルの品質特性名を「usability」から「interaction capacity(インタラクション能力)」に変更することが適切ではないかという議論が国際規格の中で進行中であるようです。この変更については、直近の国際会議で合意がされており、現在最終審議中であるとのことです。 所感 常日頃、ユーザ目線でのテストを心がけていますが、今後は「ユーザ周辺目線」なるものが必要になるかもしれませんね。 製品を使うユーザだけでなく、さまざまな属性を持つユーザや所属する組織、会社、その他の関係者にも影響が及ぶことを考える必要があり、視野を広げて物事を検討することが、今後のテストにおいてより重要になると感じました。 最後に 福住様は最後に以下をまとめとしてお話をされています。 ユーザビリティ(を含めた人間工学)とソフトウェア工学はもっと仲良くすべき ユーザビリティはさまざまな観点からアプローチされており、これまで一緒に考えてこなかった部分があることが指摘されています。より密接に連携し、協力して取り組むべきだと述べられました。 人間中心設計で抽出されるユーザ要求事項を上流の段階で要件に組み込む 上流の段階でユーザ要求事項をうまく要件に組み込む方法を向上させる必要があり、要件定義は行われても、それを具体的な仕様に落とし込むことが難しいことが指摘されました。結果的に、ユーザビリティが把握しづらくなるという課題が示されました。 開発プロセスの中で段階的にユーザビリティを評価する方法 発表の最後で、福住様はこの問題に焦点を当て、テストの観点で確認してもらえると嬉しいと述べ、発表を終えられました。 所感 今回はユーザビリティと品質に関する内容をお話いただきました。こういった概念を理解した上でテストするとよりユーザエクスペリエンスが向上に繋がると感じました。 また、今回お話いただいた内容は開発、テストエンジニアも双方で考えることによって、より良い品質になるのではと考えさる内容でした。 ワークショップ 今回、オンサイトでワークショップに参加してきました。合同会社CGFMの金内 和子様、金内 透様が開催する「クライアントも開発メンバーも巻き込んで作るUIデザイン」をテーマにしたワークショップになります。 ワークショップの流れ ワークショップは以下の流れで即興演劇、ユーザシナリオ作成、ペーパープロトタイプ作成、簡易ユーザテストを行いました。 １）抽選により4人1組のチームを作成 ２）即興演劇 一人がユーザになり切って空想でアプリを使用します。 この時、ペルソナの心境、考えなどを言葉に出しながらアプリを触ります。 他のメンバーはペルソナの心境やアプリの情報など、ユーザ役の言葉を付箋にメモしていきます。 ３）ユーザシナリオ作成 ２で書いた付箋を時系列で整理し、ユーザシナリオを作成します。 ４）ペーパープロトタイプ作成 手書きで簡易的なUIを作成していきます。 これが思ったよりも難しく、ついペルソナの人物像、課題を忘れてしまう場面もありました。 ５）ユーザテスト 紙で作成したUIに対してどうやってテストしていくんだろう？と思っていましたが、一人がサーバ役をやるんです！ユーザが遷移ボタンなどを押すと、サーバ役が別画面の紙に差し替える方法でユーザシナリオを進行していきます。 道中に不具合などがあればユーザシナリオ、ペーパープロトタイプを修正し、再度ユーザテストします。 その後各チームで1名テスターを選出して、別のチームへ赴きそのチームのシナリオと簡易ユーザテストを実際に進められるか、といった流れで進めていきました。 所感 「早くつくって、早く試す」と金内様が強調されておりましたが、兎に角すごい早い速度で進行していきました。1つの工程は5分程度だったかと思います。 また、初めは自分のチーム内で話ながら進めていたため、完成したもので概ね問題ないだろうと思っていたものが、別チームの方が進めてみると思ったように進まない、というのが大体のチームで起きていたと思います。 これでよかろうと思って作成したものが、実はユーザからしたら分かりにくかったり、使いにくかったりするため、実際に使用するユーザの事を考えてUIを作成することの難しさを体験できました。 まとめ 「心動かさる”コト”の品質」をテーマに参加させていただきましたが、どの講演内容も考えさる内容でした。日頃、機能テストを担当しているため、機能性を中心に考えてしまいがちですが、様々なユーザ要求を達成するには使用性に目を向けることも重要であると再認識しました。 今まで機能テストでもユーザ目線でのテストは心掛けて実施してきましたが、今回の講演やワークショップで学んだ内容を活かして、よりユーザの事を考えたテストが行えるよう日々精進していきたいと思います。 The post JaSST’23 Hokkaido 参加レポート first appeared on Sqripts .