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

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

JenkinsでAPIテストの定期実行を始めました

QA テスト

こんにちは。TeamSprit EXのQAエンジニアの河西です。

この記事は、APIテストの取り組みに関する記事の2本目です（全3本）。

  1. JMeterによるAPIテストの実装について
  2. JenkinsによるAPIテストの定期実行について　◀︎ 今回はこちら
  3. JMeterを使ったSalesforceアプリへの負荷テストの実施について

前回は、運用できるAPIテストの実装の取り組みについてご紹介しました。
自動テストを運用するということは、定期的に実行して結果をウォッチし、開発にフィードバックできる状態にする必要があります。
その取り組みの中で、CIサーバ初心者の私が学んだことや工夫したことについて、今回は書いていきます。

なぜAPIテストを定期実行するのか？

TeamSprit EX は、複数のスクラムチームによって継続的に開発が行われています。
開発が進み、その複雑さが増してくると、改修した部分が影響して不具合が発生するリスクが高くなります。 それを早期に検知するためには、定期的なリグレッションテストの実施が重要になります。
リグレッションテストは、同じテストの実施を何度も行うため、手動テストよりも自動テストの方が向いています。

今回追加したAPIテスト以外にも、下記3点のテストを自動で定期実行しています。

  • Unitテスト
  • E2Eテスト（Autifyなど）
  • 性能テスト（Webpagetest）

このように様々なアプローチのテストを定期実行することで、リグレッションテストの範囲を広げることができ、手動テストの負荷を軽減させることができます。

どうやって定期実行するのか？

前回ご紹介した通り、APIテストはJMeterで実装しています。
JMeterを定期実行するために、CIツールを利用することにしました。ツールは、チームで使っていることもあって、 Jenkins を採用しました。

Jenkinsとは、継続的インテグレーション(CI)や継続的デリバリー(CD)、継続的デプロイメントを実現するツールです。 下記の4点の特徴があります。

  • 汎用性が高いことから大きな支持を得ている
  • 世界中のソフトウェアエンジニアによって開発された 1,800以上ものプラグインが利用可能
  • Javaが動く環境であればLinuxでもWindowsでも動作させることができる
  • プラグインが提供する機能だけでなく、スクリプトを記述することで、より柔軟に自動化を行うことができる

JenkinsでJMeterを実行するためには、下記の作業が必要です。

  1. Jenkinsが動作しているサーバーに、JMeterをインストールする
  2. サーバーで、JMeterを実行できることを確認する
  3. Jenkinsに Performanceプラグイン をインストールする
  4. Jenkinsのジョブを作成する

詳細については こちら を参考に、作業を行いました。
Jenkinsのジョブを作成したら、それを定期実行するように設定すれば、APIテストの定期実行ができるようになります。
（私たちの場合は、テスト環境へのデプロイなどと組み合わせたパイプラインを作成し、それを毎朝実行するようにしています。）

JMeter, Jenkins, Performanceプラグイン を利用することで、 実行も集計も自動化することができます。
Performanceプラグインによって、このように結果をGUIで確認することもできます。 （これはサマリーですが、サンプラーごとの集計結果も確認できます。 ）

JenkinsでJMeterを実行する際の課題

定期実行はできるようになりましたが、私たちがAPIテストを運用する上で、新たに2つの課題が生まれました。

  • 1件のエラーも逃さない仕組み
    • エラーが発生したら、Jenkinsジョブのビルドが失敗する （Slack通知は設定済み）
  • エラー時に誰でも問題を確認できる
    • ログに、エラー箇所と原因が特定できる情報を追加する

エラーをどの程度許容するかは、定期実行を検討する上で重要な指標です。私たちは今回実装したAPIテストの特性から「1件のエラーも無視できない」と定めました。
（Performanceプラグインの一般的な設定は こちら のようです。）

上記2つの課題を解決する方法は複数あると思いますが、今回は下記の改善を行いました。

① jmeter.log にエラー箇所と原因が特定できる情報を追加する
これを各サンプラーに追加しました。

② Jenkinsジョブで、APIテスト実施後に jmeter.log の内容を確認し、エラーが見つかればビルド失敗とする
※ result.jtl などのテスト結果を格納しているファイルは、Performanceプラグインを使用している場合は履歴を蓄積している必要があるため、実行毎のNGを判断するのには不向き、と判断したため jmeter.log を活用しました。

この改善により、定期実行のエラーにすぐに気付くことができ、エラー原因の特定もスムーズになりました。

定期実行の結果をウォッチして、運用する

サンプラーごとの結果は、Jenkinsの「Performance Report」から、このように確認することができます。

ざっくりと結果を見る分にはこれで十分ですが、結果を分析したりするには、前回実行時との差分などの情報が含まれているため、少し不便です。
そのため私たちは、Jenkins上のレポートとは別に、定期的にレポートを作成してチームに共有しています。 その方法は、下記の通りです。

  1. 定期実行の結果が出力されているファイル（result.jtlなど）をダウンロードする
  2. ダウンロードしたファイルを、JMeterの「統計レポート」というリスナーで参照する
  3. 出力された結果をコピーし、Excelファイルに貼り付ける

少し手間ですが、こうしてExcelファイルにすることで、ソートやマークアップがしやすくなります。
チームにはこのレポートと、レポートの見方を共有しています。必要に応じて、各自が使いやすいように加工して利用してもらっています。

ここまで大変なことも多くありましたが、こうしてAPIテストの運用を確立できました。

最後に

今まであまり考えていなかった「テストを運用する」ということを、深く考える機会となりました。
何の為にどのように運用するかによって、実装や設定は異なります。 そのため、インターネット上の知見だけでは解決しないこともあり、試行錯誤しました。

現在、運用しているAPIテストからバグは検出されていません。 だからといって無意味ではなく、「不具合が発生していない」という結果を上げられていると思っています。
また、副産物として「APIレスポンスタイムの調査」などに使っていただくこともあるため、お役には立てているのかな、と感じています。

次回は、JMeterでSalesforceアプリへの負荷テストを実施したことについてご紹介します！

teamspirit.hatenablog.com

JMeterでAPIテストの実装を始めました

QA テスト

初めまして！TeamSprit EXのQAエンジニアの河西です。

昨年9月に入社し、APIテストの実装や、負荷テストの実施に取り組んでいます。
その中で多くの試行錯誤があったため、そのことについて全3本の記事でご紹介したいと思います。

  1. JMeterによるAPIテストの実装について　◀︎ 今回はこちら
  2. JenkinsによるAPIテストの定期実行について
  3. JMeterを使ったSalesforceアプリへの負荷テストの実施について

既にAPIテストは少し作られていましたが運用されていなかったため、既存のAPIテストを参考にし、運用できるAPIテストの実装を始めました。
その取り組みの中で、自動テスト実装初心者の私が学んだことや工夫したことについて、今回は書いていきます。

なぜAPIテストを実施するのか？

APIはUIと比較して作りが単純であるため、テスト資産のメンテナンスの容易さも含め、自動化に向いています。
UIテストよりも変更が生じにくく一貫性があるため、既に作成したテスト資産を長期間にわたって利用（運用）しやすいという利点があります。

さらに、性能テストなどと組み合わせることで、製品の性能におけるボトルネックを発見しやすいという利点もあります。

どうやって実装するのか？

ツールは、 JMeter を採用しました。
JMeterは、Javaアプリケーションのオープンソースの負荷検証ツールで、ブラウザではなくプロトコルレベルで動作します。 サーバに対して指定した量のリクエストを送り、そのレスポンスを受けることで、パフォーマンス計測することができます。

今回は、リクエスト量を最小にすることでAPIテストとして利用します。
JMeterで作成したAPIテストは、リクエスト量を調整することで負荷テストに応用することができます。

JMeterの実装は、このようなJMXファイルを作成します。
こちらは手動でコーディングもできますが、JMeterではGUIが用意されているため、基本的にはGUIで実装することをオススメします。

GUIはわかりやすく、作成しやすいと感じました。一部コーディングが必要ですが、GUIで作成できるのはテスト自動化のハードルを下げられます。
GUIで実装したものが、JMXファイルに書き出されます。そのため、Gitによるコード管理も可能です。ちなみに、コピペや文字列置換などはコードを直接編集した方が早いです。

APIテスト実装における課題

私は、APIテストを実装するのも、JMeterを使うのも初めてでした。
最初は苦戦しましたが、既存のAPIテストとAPI仕様書を見ながら、実装して実行して、とやっている内に理解できました。 API仕様書がしっかりと書かれていたことと、APIが複雑な作りではないことが、とても助けになりました。 （開発の皆様、いつもありがとうございます！）

どうやって実装すればいいかがわかるようになった次は、本格的にテスト計画を考え始めました。
冒頭にも書きましたが、今回実装するのは「運用できるAPIテスト」です。 既存のAPIテストが運用できなかった課題を洗い出し、3つの改善に気付きました。

  • 「テスト実装しづらいAPI」が無い状態にする
  • 定期実行できるものにする
  • テスト環境に依存しないものにする
    • ログインに使うテストデータの部分だけを書き換えれば、どの環境でもテスト実行できるものが理想

これらの課題を解決するために、APIテストをシナリオテストの形で実装することにしました。 （既存のAPIテストは、コンポーネントテストの形でした。）
APIを理解して、まとめられるものはシナリオテストで実装することで、カバレッジの管理もしやすくなります。 また、データを作成して削除する、という流れにしてAPIテストの実行終了時にデータが無い状態にすることで、定期実行の自動化も容易になります。

シナリオテストのイメージ

APIには、リクエストにパラメータが必要なものがあります。
例えば、データを削除するAPIには、「何を削除するか」というデータを指定するパラメータが必要な場合があります。 その際に必要なパラメータを固定値にしてしまうと、繰り返し実行できない・他の環境で実行できない、APIテストになる可能性があります。 この場合においても、シナリオテストにすることで解決できます。

  1. データ作成
  2. データ参照・取得
    • PostProcessorで「今登録したデータ」を取り出して、次のリクエストのパラメータで使えるようにする
  3. データ削除（対象を指定する）

この流れで実装することで、テスト実行ごとに削除したいデータを決めることができます。
これはAPIがどのような作りになっているかにもよりますが、私たちの場合はこの流れでテスト実装するのが一番スマートでした。 （こういったシナリオを考える上でも、API仕様書は重要です。開発の皆様、いつもありがとうございます！）

属人化問題と向き合う

シナリオテストを設計することで、あとは設計通りに実装すればカバレッジが上がっていく、という状態になります。 既存のAPIテストは、1人の方が実装されてそこからアップデートされていませんでした。
テスト自動化は属人化しがち、という話もよく聞くため、今回は早い段階から実装を分担することにしました。 （こういった分担をするためにも、Gitで管理ができるのは有難いです。）
属人化しないために行ったことは、下記の3点です。

  • 共有資料を作成する
    • APIテストやJMeterについてまとめた資料
    • 実装方法についてまとめた資料（動画も入れました）
  • 資料を基に、ナレッジ共有会を行う
    • 日本のQAチームだけでなく、シンガポールのチームにも共有 
    • 受けた質問を基に、資料をアップデート
  • 実装を分担して行う
    • モブプロやPRレビューなどをやってみる

Gitの操作に慣れていない方も居たため、そこもサポートしました。
最初はモブプロが必要でしたが、今はサポート無しで、PRを出してもらえる状態になりました。

結果として、現在は私以外に3名程がAPIテストを実装できます。 大変ではありますが、テスト自動化をする時は早い段階で属人化を解消しておくことで、テストの拡充がスピーディに行えると感じました。
各スクラムチームに属しているQAメンバーもAPIテストを実装できるため、まだ実現できてはいませんが、開発のスピードに合わせてAPIテストを拡充していくことも可能な体制になりました。

次の課題は、命名規則やコメントの付け方などのコーディング規約だと思っています。 このあたりはまだルール化はしていませんが、「誰でもメンテナンスできるように」という方針でPRレビューを行なっています。

最後に

APIテストができると、テストデータを作る際にも役立ちます。新しいものを導入することは大変ですが、得られるものはとても多いと感じました。
私はQA歴も浅く、APIテストの実装も初めてでしたが、任せていただけたことでとてもスキルアップできたと感じています。

次回は、JenkinsでAPIテストの定期実行を始めたことについてご紹介します！

teamspirit.hatenablog.com

【イベントレポート】Autify community meetup QAチームのオンボーディング事情

こんにちは！エンジニリングマネージャの生井(id:riririusei99)です。
今回は、7月6日に行われたAutify Communityの中でチームスピリットから橘さんが登壇しましたのでイベントレポートを書きます。

 

autifyjapan.connpass.com

 

Autify community meetup とは？

Autify community meetupは、Autifyユーザー = Autifier（オーティファイアー）のためのコミュニティ「Autifier Community」が運営する、QAやテスト自動化をテーマにしたミートアップです。
サービスや製品の品質管理に携わっているみなさんに向けた情報をカジュアルに共有していきます。
Autifyのご使用経験がない方のご参加も大歓迎です。

Autifyは自動テストをノーコードで作成できるツールなので、QAエンジニアや開発者がテストのことをより深く理解することで、もっともっとAutifyを活用できる！

…そんな背景からQAやテスト自動化に関する勉強会を開いています。（と思っています。）

 

最近は品質保証・テストに関する勉強も盛んに開かれており、１人目のQAの事例発表や勉強会のテーマとして良く取り上げられるテーマだと思います。

今回のイベントはそこからから少し進んだQAチームの次なる大仕事、２人目以降のメンバーの受け入れに焦点を当てた「オンボーディング」というテーマでイベントを開催されました。

 

今回Autify Communityのメンバーとしてイベントのネタ出し要員としても企画のタイミングで参加しています！

私のコアメンバーの活動の軌跡はこちらから読めます。

Autifyコアメンバー活動やってみました！ - riririusei99’s blog

 

パネルディスカッション

参加者は橘さんの他に株式会社レコチョクさんからもオンボーディングを受けた側として参加、モデレータのAutifyの早川さんが元１人目のQAなのでオンボーディングした側という３人で進行していきました。

 

パネルディスカッションの様子

パネルディスカッションの中ではオンボーディングに対する「期間・内容」「それぞれ工夫している部分」「これがあって良かった」などをメインに話し、その中で気になった部分を深堀りするという形式で進んでいきました。

 
チームスピリットのオンボーディングの期間について

パネルディスカッションの話題でオンボーディング期間について補足しておくと「チームスピリットのオンボーディングは２ヶ月」という話がありましたが、通常は３ヶ月です。

チームスピリットのオンボーディングはざっくり分けると３つに分けられます。

  • 全社員共通オンボーディング（製品紹介、社内ルール等）
  • 開発者向けオンボーディング（製品テスト、環境構築）
  • Salesforce知識をつけるオンボーディング（Trailhead）

橘さんの場合、Salesforceの知識がとてもある人だったので３つ目が免除になりましたが、通常はこのTrailheadが非常に大変です。

私も入社した時はSalesforceは初めての状態だったので、とても時間がかかったことを今でも思い出します。

（…今も調べ物をする時にTrailheadを見るのがあるんですが、調べたい内容のTrailが既に履修済みになってたりするんですよね。）

 

オンボーディングの詳しい内容は他のメンバーもブログに残してくれていますので、よければご覧ください。

 

teamspirit.hatenablog.com

 

teamspirit.hatenablog.com

 

QAのスキルを身につけるために行なっている教育や勉強方法について

スキルを身につけるための勉強方法の中でISTQB・JSTQBの資格受験やシラバスを読むということについても言及されました。

資格取得についてはこちらもブログ記事がありますので、この機会に確認してみてください。

teamspirit.hatenablog.com

 

teamspirit.hatenablog.com

 

ISTQB・JSTQBの知識体系を大事にしていることについてですが、会社から見ればメンバーの立ち上がりがしやすく、メンバーからは幅広い場所で使えるスキルを取得することで個人のキャリアにもプラスに働くため双方にとって良いことだと考えています。

資格取得について厳格なルールは存在していませんが、勉強方法などについて聞かれた際は私もシラバスを読むのを提案したりします。

 

テストアナリスト試験の前は有志で勉強会などもやっています。

teamspirit.hatenablog.com

 

そういった活動の成果として、現在は社内でAdvanced Level保持者は8人いて、TA＆TM両方を持ってるメンバーは4人所属しています。

 

終わりに

登壇してくれた橘さんは質問に対しても丁寧に対応しチームスピリットでの経験を通してとても成長しているんだなぁと感じました。

入社してから既にブログも複数書いて、今回の登壇のオファーも快諾していただき本当に感謝です。

 

そしてイベントの中で言及されたテストコンテストですがチームスピリットは企業チームとして出場していますので、よければこちらもご覧ください。

 

teamspirit.hatenablog.com

 

以上、イベントレポートでした！

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 職種問わず様々なテーマを用意しています。
少しでも気になるテーマがあれば、お気軽にお申し込みください。
みなさまのご応募、お待ちしています！！