チームスピリットデベロッパーブログ

チームスピリット開発者のブログ

JSTQBのCBT化を前にしてISTQB Test AnalystをCBTで受験してきた

QA テスト

こんにちは。QAエンジニアの橘です。

JSTQBの試験について、従来紙ベースであった試験がCBT（パソコンを使った試験）に移行されることが発表されています。

JSTQB、「コンピュータによる認定試験」の導入準備を開始 | ICT教育ニュース

JSTQBとは、日本におけるソフトウェアテスト技術者資格認定の運営組織で、 各国のテスト技術者認定組織が参加しているISTQB（International Software Testing Qualifications Board）の加盟組織として2005年4月に認定されています。（JSTQB認定テスト技術者資格-JSTQBについて-より引用）

CBTでの試験は10月以降とアナウンスされていますが、

待てなかったのでISTQBでTest Analystを受けてきました。

無事合格したので、受験までの流れや勉強方法について書いていきたいと思います。

ISTQB Test Analystとは

ISTQB Advanced Level Test Analyst（以下AL-TA）とはISTQBによる認定資格で、試験ではテストプロセスのうちテスト分析、テスト設計、テスト実装、テスト実行を行う者として必要な知識があるかどうかが問われます。

受験には下位資格であるISTQB Foundation Level（以下FL）の合格が必要になります。

JSTQBのAL-TAの受験には業務経歴申請書の提出が必要でしたが、ISTQB試験の提供団体であるBrightestに問い合わせたところISTQBのAL-TAではそうした書類は不要とのことでした。

CBT化後のJSTQBのAL-TA試験で業務経歴申請書の提出が必要になるのか気になるところです。

AL-TAの受験方法

英語での受験になりますが、ISTQBのAL-TA試験は日本のテストセンターで随時受験することができます。 以下受験方法になります。受験料は225ユーロ（約3万1700円）です。

※2022年6月時点での手順なので、今後変更がある可能性もあります。

  1. BrightestのSign inページでアカウントを作成します。
  2. 試験カタログからISTQB® - Certified Tester Advanced Level - Test Analyst (2019 Syllabus)を検索して選択します。※Technical Test Analystと間違えないように注意
  3. 試験の受験場所は「At a test center」を選択します。
  4. 受験の際の言語は「English」を選択します。
  5. training providerを選択し、re-sit（再試験）であるかどうかを回答します。training providerについては僕の場合は自習での受験だったので「No Training Provider (Self-Study)」を選択しました。
  6. Consecutive Appointments（連続して試験予約）をするかどうかについての画面では、そのまま「Next」で次の画面に行きます。
  7. Admission PolicyやReschedule Policyなど諸々のポリシーが表示されるので、読んでから「Agree」で次の画面に行きます。
  8. 当日の受験場所であるテストセンターを選択します。東京の場合は新宿、池袋、秋葉原など各地のテストセンターを選択できます。
  9. 試験日と開始時間を選択します。カレンダー上で選択可能な日付と時間が表示されるので都合の良い日時を選択します。
  10. 申し込み内容を確認し、「Proceed to Checkout」で支払い画面に行きます。
  11. クレジットカードを選択し、各種情報を入力して支払いを行います。

AL-TAの試験内容

https://www.istqb.org/certifications/test-analystのシラバスに沿って

  1. テストプロセスにおけるテストアナリストのタスク
  2. リスクベースドテストにおけるテストアナリストのタスク
  3. テスト技法
  4. ソフトウェア品質特性のテスト
  5. レビュー
  6. テストツールおよび自動化

の6分野から選択式の問題が40問出題されます。

各問題の配点は同じではなく1〜3点のいずれかで、80点満点です。より難しい問題ほど配点が高くなっています。65%（つまり52点）以上の得点で合格となります。

試験時間は120分です。なので1問あたり2分〜3分で解答する必要があります。

なお試験終了後に紙でスコアレポートを受け取れるので試験結果はすぐに分かります。

AL-TAの勉強方法

AL-TAの試験勉強にあたって、以下のものを参考にしました。

シラバス日本語版を読んでからサンプル問題を解き、サンプル問題の解説やAdvanced Software Testingを読んで理解を深めつつ、個別の用語については社内で質問したりネットで調べたりしました。

またAdvanced Software TestingはAL-TAを意識していてサンプル問題もあるので（ただし品質特性などは内容がやや古い）、シラバスとの整合性に注意しながら追加で解きました。

試験勉強のTips

第3章「テスト技法」と第4章「ソフトウェア品質特性のテスト」からの出題が体感的に全体の7割くらいを占めるので、これらの分野を比較的重めに勉強しました。

第3章「テスト技法」

  • 同値分割法や境界値分析などFLで出題されたテスト技法に加え、クラシフィケーションツリー技法・ペアワイズテストなどについて出題されます。各テスト技法を理解して正しく適用できるかが問われるので、サンプル問題やソフトウェアテスト技法練習帳などで実際に手を動かしてみるのがいいかと思います。
  • 経験ベースのテスト技法（エラー推測、探索的テストなど）についても出題されます。
  • テスト技法をどのような場面で適用するのがいいかについて、シラバスを読んで理解しておきましょう。

第4章「ソフトウェア品質特性のテスト」

  • ISO/IEC 25010の製品品質モデルをベースに出題されます。シラバスに記載されている品質特性/副特性にはどのようなものがあるか、品質特性のうちテストアナリストという役割において重視するものがどれかを押さえておく必要があります。
  • 特に機能適合性（functional suitability）の副特性の機能正確性（functional correctness）・機能適切性（functional appropriateness）・機能完全性（functional completeness）については、提示されたテストケースはこれらのどの副特性をテストするものか、あるいは与えられたシナリオにおいてどの副特性のテストをするのが適切かといった形で出題されます。それぞれの副特性の自分なりの理解は以下のような感じです。
    • 機能正確性（functional correctness）：不正な動作がないか
    • 機能適切性（functional appropriateness）：ニーズを満たしているか
    • 機能完全性（functional completeness）：要求に対する実装の網羅度

全体

  • 問題文が基本的に長いので、長めの英文を読むのに慣れておいた方がいいと思います。
  • 1つのシナリオに複数の設問があるという形式の問題が4組ほどあります。解いていてTOEICのリーディングセクションを思い出しました。
  • 1シナリオ複数設問の問題ではモニターの左半分にシナリオ、右半分に設問が表示されます。場合によっては文章全体が1画面に収まらないのでやや見ずらいですが、シナリオと設問の画面領域の幅はマウスのドラッグで調節できます。

受けてみた感想

文章が長い問題が多く試験時間120分をほぼ使い切る形になり、なかなか集中力を要求されました。元気な状態で受験したいですね。

また、AL-TAの勉強を通してテスト技法や品質特性について理解を深めることができたと思うので、これからの業務に活かしていきたいです。

以上、参考になれば幸いです。

Jenkins と Autify を連携させた話

CI/CD テスト 改善

こんにちは。TSFエンジニアリングチームの小松原です。

TeamSpirit では、スモークテストをAutifyでテストしています。

今回は、開発の最新資材をJenkinsでデプロイしてAutifyで動かす仕組み作りを自分が担当したのでご紹介します。

事前準備

Autify のアクセストークン を取得しておきます。

Jenkins Job の設定

大まかな流れは以下のようにJekins Job を設定して動かしています。

Jenkis Job 設定イメージ

  1. Jenkins でデプロイしたい Git ブランチを Pull します。
  2. Pull した資材をテスト環境にデプロイします。
  3. 以下の Autify との 連携Shell で Autify API を叩き、完了までポーリングします。

Autify との 連携Shell について

この Shell を動かすに必要なパラメーターは以下の通りです。

# Resutl HTML Template
function getTestResultToHtml(){

mkdir -p "${WORKSPACE}"/test_result

cat <<EOF > "${WORKSPACE}"/test_result/index.html 
    <!DOCTYPE html>
    <html lang="ja">
      <head>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <title>Autify Test $2 Result</title>
      </head>
      <body>
        <div class="description">
          <h2><a href=$1>Autify Test $2 Result</a></h2>
          <dl>
            <dt>Status</dt><dd>$3</dd>
            <dt>Review needed</dt><dd>$4</dd>
            <dt>Finished</dt><dd>$5</dd>
          </dl>
        </div>
        <div>
          <h2>Raw Test Result</h2>
          <pre><code>$6</code></pre>
        </div>
      </body>
    </html>
EOF
}


# Run a test plan on Autify
execute_response=$(\
  curl -XPOST -H "Authorization: Bearer ${AUTIFY_API_ACCESS_TOKEN}" \
  https://app.autify.com/api/v1/schedules/${AUTIFY_TEST_PLAN_ID} \
)

# Get test plan result ID to get a URL
test_plan_result_id=$(echo ${execute_response} | jq -r .data.id) 

# Build a result URL
test_plan_result_url="https://app.autify.com/projects/${AUTIFY_PROJECT_ID}/results/${test_plan_result_id}"
echo ${test_plan_result_url}

# Test Result Status Response Polling
while true
do
  test_result=$(\
    curl -X 'GET' \
       "https://app.autify.com/api/v1/projects/${AUTIFY_PROJECT_ID}/results/${test_plan_result_id}" \
       -H 'accept: application/json' \
       -H "Authorization: Bearer ${AUTIFY_API_ACCESS_TOKEN}"\
  )
  
  result_status=$(echo ${test_result} | jq -r .status)
  
  printf "progress status : ${result_status}"
  
  # Check Test Status
  if [ "$result_status" = "passed" ] || [ "$result_status" = "failed" ] || [ "$result_status" = "skipped" ] || [ "$result_status" = "canceled" ]; then
    # End Test
    printf "end polling status : ${result_status}\n"
    printf "$(echo ${test_result} | jq -r .)"
    
    getTestResultToHtml ${test_plan_result_url} $(echo ${test_result} | jq -r .id) ${result_status} $(echo ${test_result} | jq -r .review_needed) $(echo ${test_result} | jq -r .finished_at) "$(echo ${test_result} | jq -r .)"
    break;
  fi
  
  sleep ${POLLING_INTERVAL};
done

ビルド成果物

上記のShellの実行結果は以下のようなイメージで出力されます(一部加工しています)。

感想

Autify APIを試せるページがあるので、実装時に助かりました。 あとは、Autify のデータ機能を外部から柔軟に置換できたらと感じました。

苦労した箇所は、Shell スクリプトの if の条件文の箇所です。[ 条件文 ] のように [ の後に半角スペースが必要なことに気づかず苦労しました。

今後の展望

将来的に Autify CLI と Jenkins の連携とあるので、リリースされたら試してみたいです。

テスコンU-30にエントリーした話

QA テスト イベント

初めまして。TeamSprit EXのQAエンジニアの田中です。
今回は、企業チームとしてテスコンU-30クラスにエントリーし、予選成果物を提出した所までで思ったことを書いていきます。

皆さんは、テスコンをご存知でしょうか？
私は正直、QAエンジニアの仕事に就いてからこの存在を知りました。
過去にもテスト業務はやっていましたが、webページの体裁やJavaScriptの動作確認といったテストしかやったことの無かった私にとっては未知なる世界そのものでした。

テスコンについて

テスト設計コンテスト（通称テスコン）とは、NPO法人ソフトウェアテスト技術振興協会が主催する、ソフトウェアテストの技術の向上と促進の機会を提供する場として開催されているコンテストのことです。
テスコンの目的は下記の通りです。（公式サイトより引用）

  • ソフトウェアテストを分析設計から行うことを周知し、ソフトウェアテストエンジニアに対する教育の機会を提供する
  • コンテストという形式をとることにより、ソフトウェアテストが創造的な作業であり、楽しいということを経験してもらい、若年層及び初級テストエンジニアからベテランテストエンジニアまでテストへの興味を高める
  • ソフトウェアテスト業界における技術開発を競技を通じ、促進する

コンテストには、OPENクラスとU-30クラスがあり、U-30クラスは30歳以下の方に限定されています。
OPENクラスは各地域予選を行い、優秀と認められたチームが決勝戦へ出場する権利を得ます。U-30クラスは書類による予選を行い、優秀と認められたチームが決勝戦へ出場する権利を得ます。
それぞれ指定のテストベースに対するテスト設計を行い、その優劣を競います。

エントリーに至った経緯

下記2点の経験を積むことができると、マネージャーからテスコンの紹介がありました。

  • テスト計画・テスト分析・テストアーキテクチャ設計など、若手メンバーが担当する機会が少ない領域の実戦経験
  • 若手メンバーのプロジェクト運営の経験

丁度チームスピリットのQAエンジニアで、30歳以下で入社歴が浅く、品質保証の知識・テスト経験も浅いメンバーが4人いたため、企業チームとしてU-30クラスにエントリーすることにしました。

チームメンバーについて

たちばなさん
　テスト経験：未経験（入社してからQAエンジニアに）。
　前職ではSalesforceの導入支援をしていた。コードを書いた経験もある。
　意気込み：実践的なところを頑張りたい。

みきさん
　テスト経験：前職新卒で入ってテストをやっていた（約3年）。
　意気込み：ちゃんとしたプロセスに沿ったテストはやったことがないので、やりきりたい。

かわにしさん
　テスト経験：未経験（入社してからQAエンジニアに）。
　前職ではSaaSの開発者だった。Web開発の開発者テストは経験あり。
　意気込み：ちゃんとしたプロセスを経験して、実務に当てはめられる力をつけたい。 

私
　テスト経験：未経験に等しい（入社してからQAエンジニアに）。
　前職はWebサイトの保守運用。画面系のテストは少ししていた。 
　意気込み：テストプロセスを経験したことが無く、テストの質を高める経験をして実務に活かせるよう色々チャレンジしたい。 

このように、入社時期と年齢が近いこと以外、バラバラな経歴を持つ4人でチームを組みました。

実施したこと

テスコンに臨むにあたり、私たちは下記のコンセプトを立てました。

  • テスコンを通し、テストプロセスを理解する
  • 得た知識を実際の業務に活かす

このコンセプトのもと、私たちは予選成果物作成に取り掛かりました。
予選の作業では、指定のテストベースに対して下記の基本的なテストプロセスを実施しました。

  • テスト計画
  • テスト要求分析
  • テストアーキテクチャ設計
  • テスト詳細設計
  • テスト実装

成果物作成をする中で、難しかったこと

進捗管理の課題

  • 初めてのことが多く、経験がないことで見積もりが緩くなってしまった。
    見積もりが上手くできない事で予定通りの進行が出来なくなり、スケジュール管理がうまくできなかった。

→ 進捗管理を見直し、分かりやすい形で可視化することで、作業が終わるかどうかを見通せるようになった。作業のアサインについて、スケジュールだけを見て割り振るのではなく、負荷も含めて作業のアサインは検討した方が良いと感じた。

PFDに色付けをして、進捗を可視化。

コミュニケーションの課題

  • コミュニケーションの場が最初のうちはミーティングのみだったため、進捗などがリアルタイムで把握することができなかった。

→ ミーティングの場だけでなく、チャットツールやドキュメント内でのコメント機能を活用することで、コミュニケーションが充実した。


テストプロセスに関する知識の不足

  • なぜそうした方がいいか、説明できるまで理解できていないと分かった。
  • モヤモヤ感を抱いたまま作業を進めることになり、チーム内の指針の認識にズレが生じる事があった。

→ 事前に引き出し（知識）を多く持っておくようにする。 説明できるか観点で復習する。


テストプロセスだけでなく、プロジェクト運営についても課題が多く、テスコンを通して様々な経験を得ることができました。
成果物作成中はなかなか課題に対しての悩みを解消しきれず、認識のズレが生じて成果物の見直しも発生し、ギリギリのスケジュールになってしまいました。

この活動で得た、業務に活かせそうなこと

作業やMTG開始前の入念な準備

  • ドキュメントの管理の認識を合わせておくと、作業が円滑に進められる。
  • MTG前に資料を準備し、話したいことを決めておくと、簡潔に共有がする事ができ円滑に進められる。

→ 今後、自分が業務でプロジェクトを運営する立場になった時に、どんな準備があると良いか知ることができた。


テスト観点の出し方、テスト設計の仕方

  • 普段の業務などを参考にしていたが、テスト対象が変わると大きく変わるということが分かった。
  • 今回、テスト観点についてよく議論をした。
  • 普段の業務で行なっている、アジャイル開発でのテストプロセスとの違いを感じた。

→ 今後はテスト観点をより多面的に出せるようになるだろう。さらに、一般的なテストプロセスでアジャイルでも必要なところ・逆に優先度が落ちるところ、についても考えていきたい。


テスト計画やテストアーキテクチャ設計の実戦経験

  • 普段の業務で経験していないため難しく、よく議論をした。
  • 今回できなかったことも多いが、今まで考える機会もなかったことを多く考えて調べた。

→ 今後の業務で、ヒントとなりそうな考え方に多く出会うことができた。

感想

初めてテスコンにエントリーしてみて、予選成果物一式を無事に提出できた事については喜ばしい事ですが、慣れない所が多々あり余裕のある進行ができたとは言えず、自分たちに課題が多くあることも実感しました。
私はこのテスコンを通して、改めてまだ知らなかったテスト技法や考え方といった、QAの奥深さを知ることができました。 この経験を今後のQAエンジニア人生に活かし、学び続けていこうと思います。

予選の結果はまだわかりませんが、今回企業チームとしてエントリーし、チームで成果物を作成しただけでも多くの学びがありました。
特に、テストプロセスについては実践経験を積めたことで理解が深まりました。
この経験・得た知識を実際の業務に活かしながら、これからも多くのことにチャレンジしていけるQAチームでありたいと思います。

Meety はじめました！！

こんにちは。TSFエンジニアリングチームの田中(美)です。
少し前から、SD Divisionで Meety の利用をはじめました。
meety.net Meetyとは、カジュアル面談を"もっとカジュアル"に実施するためのプラットフォームです。
面談のテーマを設けており、テーマに合ったお話を対等に話す場となっています。
例えば、「ゲームをしながら雑談」という通常の採用フローでは実施できないこともテーマとして設定できます。
meety.net 私達も、さまざまな人とお話できるチャンスがあればと思い開始しました。

そうしたところ、Meety にて弊社の特集ページを組んでいただきました！
meety.net 職種問わず様々なテーマを用意しています。
少しでも気になるテーマがあれば、お気軽にお申し込みください。
みなさまのご応募、お待ちしています！！

エントリーブログ：入社から３ヶ月間のできごと

入社ブログ

自己紹介

2022年2月1日にチームスピリットに入社しました、 開発エンジニアの小松原です。

それまでは、SIerにてJavaとSpring FWでWebシステム開発に5年ほど携わっていました。スクラムもSalesforceも全くの未経験です。

入社〜３ヶ月の間のできごと

入社日当日

入社日は会社に出社し、社用端末の設定と就業規則などの説明を受けました。

オリエンテーション

入社後１週間は、荻島代表や各Division Leaderとの個別のミーティングで、時間を掛けて会社の概要について勉強しました。 また荻島代表や各Division Leaderに直接質問できるため、各組織がどのような目的で動いているのかを理解を深める事ができました。

オンボーディング

チームスピリットでは入社から2ヶ月間はオンボーディングを実施しています。 開発エンジニアとしてチームに参画できるようになることがゴールです。

内容としては、

  • プロダクトマネージャーやスクラムマスターより製品（TeamSpirit）に関するプロダクトの紹介
  • 開発プロセスやスクラム運営に関する情報共有
  • 製品のテスト環境を構築
  • システム全体の挙動をシナリオ化しているスルーテストを実施
  • 製品の各機能概要をロールプレイングでメンバーに説明

を行いました。

オンボーディングの感想

入社後のフォローが手厚く、製品の理解から開発チームに参画するまで順調に過ごすことができました。 今回、入社からほぼ１００％リモートで作業でしたが

  • Slackを用いたコミュニケーション
  • 各チーム単位でのデイリーミーティング
  • ナビゲーターとのデイリー1on1
  • 他部署のメンバーとのマンスリー1on1

を通じて常に質問を投げやすい環境が整っていたと感じています。 そのため、Salesforce開発に未経験の私でも、無事に開発チームに参画できました。 積極的に周りのメンバーから支援いただけたので、精神的にも助かりました。

ただ、スクラムは説明だけでは理解するのが難しいと感じました。 やはり、実際にチームに加わって体感して理解できてきたという感じです。

スクラムチームへの参画〜実務の開始

入社から約２ヶ月程度経つと、開発プロジェクトのスクラムチームに参加し始めます。 私は開発エンジニアとして、TeamSpiritの新規機能開発チームに入ることになりました。 スクラムチームとしてはこのチームに参画しながら、設計、開発、試験を担当していきます。 このチームの特徴としては、モブプロを積極的に取り入れていることです。 モブプロをすることで、一人でタスクを抱え込むリスクが減り、チームとしての一体感が出ていると感じています。 世の中に自分が携わった機能が出ていき、フィードバックを得られるのでとてもやりがいがあります。

まとめ

研修期間の手厚いフォロー、メンバーの支援があり、とてもスムーズに開発チームに参画できたことに感謝しています。 今後はCI/CD周りにも興味があるので、魅力的な機能を素早く提供できるよう微力ながら尽力していきます。

Webページ性能計測自動化の改善

QA 改善 テスト

はじめに

こんにちは。TeamSpritEX開発チームQAエンジニアの長尾です。
Webページ性能計測の自動化のアップデートを行いました。
今回はその内容についてまとめました。

Webページ性能計測について

そもそもWebページ性能計測とはどのようなもの？
→実際にユーザが利用する際のWebページの表示速度を計測する。
というのが一般的かと思います

測定の方法は様々な方法がありますが、今回私が対応したものは、ブラウザにて手動で確認することも可能な以下の時間（Finishのタイム）を想定したもの。

Chromeブラウザのデベロッパーツール

データ計測のメリット

顧客満足度に直結する大事な指標となることは当然のこと、計測データを利用することによって、他の製品との性能比較、ロード時間の長さに関する課題の顕在化など、アプリケーションを開発する上で様々な目的や課題の解決のための指標として利用することが可能と考えています。

Webページ性能計測（自動化）の仕組み

私のチームでは、前述したデータの計測を自動化し、蓄積したデータをグラフ化し開発メンバーに共有しています。ここではその方法について記載します。
今回はgas-webpagetestというGoogle Apps Scriptで動作するパフォーマンス計測ツール使用しました。
また、計測対象となるテスト環境についてはJenkinsを利用し毎日Masterブランチのデプロイを実行し、各チームの修正が取り込まれる状態にしています。

公開されているリポジトリgithub.com

図解すると以下の通り

WebPageTest自動化

改善の背景

実装の仕組みについては前述したとおりですが、
実は、私がチームスピリットに入社するより以前から、既に自動化は運用され計測結果も収集している状態でした。
問題なく動いてはいましたが、運用していく中で改善課題も上がっていたため、今回私の方でその課題に対応するために改修することとなりました。
課題としては主に２点

  • Salesforceの上のパッケージ開発における開発可能な範囲に絞った性能速度の計測ができていない。
  • ユーザーの利用頻度の高いユースケースに対応したテストシナリオになっていない。（初回実行時のキャッシュ無しを想定した計測となっていた）

そのため、まずは現在の自動化の実装フローがどのようになっているのかを理解。その後対応方法を検討していきました。

どんな改修を実施したのか

結果として以下のような対応を実施。

  1. Salesforceのロード時間を除いた計測に変更
    　→Visualforceページのみ計測対象とすることで自社内で対応できる機能に絞り込んで計測することができた
  2. ページリロード時の計測に変更（キャッシュ有りの利用を想定）
    　→WebPageTestの実行スクリプトを修正し、より利用頻度の高いシチュエーションにおけるロード完了時刻の測定に絞り込むことができた

性能テスト自動化のメンテナンス作業を通して

前述した通り、私が対応し始めた段階ではある程度自動化の仕組みは構築され既に定期実行で計測する運用はされていました。
そのため、途中から運用を引き継ぐ形で対応することとなったのですが、
今まで利用したことのなかったGoogle Apps Scriptを利用した運用方法であったこともあり、
内容を理解するのはなかなか大変でした。

社内の有識者に質問攻めの状態でなんとかやりとげることができましたが、 今回一番やってよかったと思ったのは、トライアンドエラーで何度も実装したことです。
仕組みの全貌を理解できたのは、１つずつ自分で試してみて１通りの実装が終わった段階でした。
引き継ぎの段階で一通りの説明をもらい、その後少し期間が空いてからメンテを始めようと思うも時既に遅し。何をすればよいか全く分からなくなりました。
初回説明の段階で全く理解してなかったからだと思います・・・。
実際にやってもいないのに理解したつもりでいることの怖さを改めて感じるのと同時に、理解したことを実行して身につけることの重要性に気づきました。

苦労した点も多かったですが、結果的に品質基準として定めていたページ読み込み時の速度目標を改定することとなり、
弊社のパッケージ開発の目標としてより妥当な品質基準を設定できたと感じています。

解決できていない課題について

現時点の課題として具体的には以下のようなものが存在しています。

  • 複数バージョンのパッケージ製品の計測に対応していない
    　→弊社では同一製品でも複数のバージョンを提供しているため、それぞれに対応した性能テストの自動化を目指したい（現在１バージョンのみ実装）

  • 一定のタイミングで計測が停止、計測ツール（WebPageTest）の計測サーバの混雑度合いなどを考慮できていない
    　→定期実行スクリプトが稀に停止しその後計測が止まってしまうことがある

顕在化していない問題も含めるとまだまだ改善の余地があるものかと思うので、今後もこういった課題を１つずつ解決していきたいと思っています。

最後に

性能テストの目的は”ユーザがストレス無く快適に利用できる製品を作りだすこと”だと思っています。
私はQAエンジニアなので、現時点ではこの情報の抽出の部分に注力していますが、当然ながら計測しただけでは意味がないと思っています。

  • 開発エンジニアに性能評価を意識した開発を進めてもらうにはどうすればよいか
  • マーケティングの指標としてどのように活用していけるか
  • 更に効率的な性能テストの自動化の仕組みを検討（利用するツールの統一化など）

などなど、やるべきことはたくさんあると思っています。

テストを実施することが目的になりがちなQAエンジニアですが、
今回のような非機能要件の検証に関わることも、大きなやりがいの一つです。
チームスピリットでは、これ以外にも様々な技術検証を行っているので、
今後もいろいろなことに挑戦していきたいと思います。

Autifyのテストシナリオにラベルを付けて自動テストの管理を始めました

QA Autify 改善

こんにちは。TSEX開発チームの仲です。
2021年もあっという間に終わり2022年になりました。今年もよろしくお願いします。
今回は年末にリリースされたAutifyの機能であるラベル機能を利用してテストシナリオをラベル分けを行って自動テストの管理を開始しました。 autify.com

ラベル機能とは？

2021年12月22日のリリースにてテストシナリオごとに任意のラベルを追加できるようになりました。 https://autify.zendesk.com/hc/ja/articles/4411895830681-2021%E5%B9%B412%E6%9C%8822%E6%97%A5%E3%81%AE%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9

現状の背景として私たちがAutifyの導入を開始して作成したテストシナリオの総数が500シナリオ前後(不要なテストシナリオなども含まれています)あり定期実行を行っているテストシナリオや新機能のテストシナリオを確認することが難しくなっておりました。
この問題を解決するためにテストシナリオにラベル付けを行い管理・運用できるようラベル作成・運用ルールを定義しました。

どのように管理したいのか？

膨大なテストシナリオの中から何をどのように管理したいのかを考えます。

  • 何を: 定期実行や特定のタイミングで実行したいテストシナリオ
  • どのように: いつ作成されたのか・何の機能なのか・外部開発により実装された機能なのか

上記の内容から3つの観点として管理しようと考えました。

  1. リグレッションテストとして定期実行しているテストシナリオ
  2. 現在のシーズン中に開発・不具合修正された機能のテストシナリオ
  3. その他(事前準備を実行するテストなどの円滑に行うためのテストシナリオなど)テストシナリオ

運用の観点で1,3については一意のフラグを付けておけば問題ありませんが、シーズンごとに項目が増えていく2の観点については一つのラベルで運用するのは難しいと感じたため以下の3つの内容のラベルの有無で管理するように考えました。

ラベル機能のルール決めとフラグ付け

上記の観点をもとに参考用のラベル名を準備し、ラベル名の定義とラベル付けのミーティングを行いました。 その中でシーズン内に作成したテストシナリオのラベルのルールとして以下の3種類をラベルとして追加するというルール決めを行いました

  • どのシーズンで作成されたテストシナリオなのか？
  • このテストシナリオのドメインは何か？
  • ベンダー開発により実装された機能なのか？

ルール決めが完了後に、テストシナリオごとにラベル付けを開始しました。 上記のルールでテストシナリオを分類したところ8種類に分類ができたため、各分類ごとにラベル付けのメンバーを割り振り分担してラベル付けを行いました。

ラベル付け結果

ラベル付けの分担を行うことにより500件のテストシナリオの中から260件のテストシナリオにラベル付けを行いました。 また複数人でラベル付けを行うことにより、ルール決めのミーティング含め一時間以内に完了することができました。 抽出前

抽出後

注意点

注意点としてはテストシナリオに追加するラベルを大量に追加しないことを心がけております。
ラベルのルールを大量に作成すると運用時のルール確認に時間がかかってしまうことや。ラベルの存在価値が薄れてしまうことを懸念したため、テストシナリオ内に最大でも4つよりも多くラベルを設定しないように運用を行っています。
画像のようにラベル付けを行いました。

運用結果

現在ラベルの追加を行いテストシナリオの運用を開始しております。運用開始直後でもラベルを検索すれば大量のテストシナリオから指定したテストシナリオのみを抽出できるため、Autifyに新規で携わることになったユーザでも必要なテストシナリオを表示できるようになったと思います。
また他のメンバーが作成したテストシナリオのフラグからどのようなテストシナリオを追加したのかを詳細を確認せずに把握できるようになりました。その中でフラグ管理が正しく行われていないテストシナリオについても一目で確認できているため、修正依頼などを出すことも容易にできるようになっております。 将来的にはテストシナリオから過去のシーズンでどのような機能が追加され、自動テストが作成されたのかさかのぼり、過去に作成したテストシナリオを参考できるようになるのではないかと思っております。

終わりに

前回はテストシナリオの運用ルールを定義して実行して運用を開始したため、その運用ルールを参考にラベルを作成しました。
teamspirit.hatenablog.com
また各ドメインを横断して開発を行うプロジェクトも新たに追加され、テストシナリオを作成するメンバーも増えました。そのためリスト上で何のテストシナリオなのかが明確にできるように運用を行おうと考えました。 今後の課題としては現状は導入開始直後なので今後に課題や運用時に求めていたものが抽出できないという課題が出てくるとは思いますが、現状の運用方法をブラッシュアップしてゆきたいと思っております。