こんにちは、R-Hack編集室です。
この頃日が出ている時間が長くなりましたね。
朝起きてカーテンを開けると明るく日が伸びてきてな、夏が近いなと感じています。
コマーステックでは、最近QA向けのTechイベントを行いました。去年から始まったイベントで今回は2回目で、今回はオンライン開催でした。
合計132名の方にお申し込みいただき、同時接続数は114名、またセッション中20個の質問を頂きました。
ありがとうございました。
テーマ
今回のテーマですが、 ソフトウェアライフサイクルSTLC上で生まれた様々なデータを ソフトウェア開発ライフサイクルSDLCに活かすというのを テーマとしました。 我々は日々STLCを通して膨大なデータを貯めています。 今回はそれらを通して下記のお話させていただきました。
1.データを解析しプロセス改善につかった事例
2.データのスナップショットを使って自動化の効率を改善した話
3.データをテストマネージメント、レポートに活用した事例
4.自動化の結果データを自動化実行に使った話
5.上記のデータをどのように作って管理しているか
それでは、発表資料と、頂いたご質問を順番にご紹介させていただきます。
Session#1:
[Case study] Utilize STLC data for Process Improvement by Rajat Dayma
Q1; QAの勘違い(INVALID)の具体的な例を交えて教えてもらえますか？
A1: INVALIDは純粋にQAが誤解していたことを表しています。例えば仕様には赤いボタンと書いてあるところを読み間違えて青いボタンと理解して間違えてバグと検知された場合を想定しています。
Q2: プロジェクトには、いくつのテスト環境がありますか？
A2: プロジェクトごとに複数の環境を用意しています。
OKであればそのソースコードを本番環境にリリースします。
Q3: チームごとに違う分析をしているのでしょうか？それとも楽天全体で分析しているのでしょうか？
A3: SQAサービスでは、楽天全体ではなくプロジェクトに基づいてデータを分析しています。
Q4: テストの終了基準はありますか？
A4: はい、STLCに基づいて、R1とR2の実行結果に基づいています。例えば、R1でインシデントがなかった場合はR2を実行しません。
Q5:47ページを見せてもらえますか？目標はどのように設定していますか？
A5: 論理的には2つの根本原因がありました。
そしてそれぞれ18%づつ影響していると考えました
36% = 18%+18%.
そして、そのうちの1つは100％の自信を持って削減できると想定しました。
つまり、18%から0%になるわけです。
しかし、もう一つは自信がないので、これまでの経験から、目標を半分の削減に設定しました。
18% -> 9%
なので
9% = 0% + 9%
が答えです。
しかし、ソリューションを導入した結果、2.38%まで達成することができました。
Session#2: Snapshot Regression Testースナップショットを用いたリグレッション自動テスト by Satoru Awasawa
Q1: マニュアルテストは１回もしくは２回のテストを想定されていると思いますが、自動テストは複数回のテスト実行を想定しないといけません、単純にマニュアルテストをレコーディングするというもの以外で追加で自動化用にデータを作らないといけないケースはありませんか？
A1: この自動化テストフレームワークに限って言えば、データを用意する必要はまったくありません。
Q2: 時間的な依存性があるようなresponse、例えば午前中や午後などで変わるようなテストの場合もsnapshotは有効なのでしょうか？
A2: はい、時間的な制約はないので問題御座いません（但しシステム環境変数やサーバータイムをとっている箇所は工夫が必要です）
Q3: テストをどういう単位でながしてますか？一日一回、プロジェクト毎、pull request毎
A3: BranchにPushされるタイミングで以下の順で実施されます
1：Build
2：単体テスト（Front、API）
3：Deploy
4：結合テスト（SnapShotRegressionTest）
Q4: Native appも対応してますか？
A4: はい、基本的にPlatformに依らないので大丈夫です！
Q5: 楽天トラベルほどの規模であればデータセットはかなりの大容量になると思いますが、Snapshotを取ったり復元するのにどれくらいの時間がかかるのでしょうか？
A5: テスト用のデータをきちっと管理することで十数分に抑えています。将来的にはこれを1分以内に縮めたいので、一緒に考えてくれる人募集中です！
Q6: 自動採番やシステム日付がレスポンスに含まれる場合に、アサーションに差分は出ないのでしょうか？
A6:工夫は必要ですが、テストフレーム側だけで考えるのではなくアプリ側も合わせて考えることで対応できない問題はないと思っています。
Q7: フレームワークをOSSとして公開する予定はありますか？
A7: OSS化にはいろいろな問題がありますが、一緒に解決してくれる方募集中です！
Q8: データはSnapshot時から変わっていく（例えばカラムが追加されるなど）ものですが、そのデータの保守はどうやっていくんでしょうか？
A8: DBのスキーマ変更等がある場合、Snapshotのデータを洗い替えする仕組みを作りました。
Session#3: Marketplace QA Introduction by Toshinori Serata
Q1: ワーディングの認識に問題あるということなのですがISTQB用語にそろえるとか、なにか工夫はありましたか？
A1: ISTQBの用語に沿うといった世の中のQAとしての標準をいしきしつつ、ISTQBそのものを知らないような人でもわかる内容にカスタマイズすることで伝わるように工夫しています
Q2: 開発とQAのしごとの棲み分けはどうしていますか？
A2: 現在は、Class/Methodといった単位での品質確認は開発、Shopper/Merchant視点での品質確認はQAとなっています。ただし、SWのV字モデルにもあるように、その間にある仕様やシステムに対応するQAはグレーです。ここを開発、QAの実力にあわせて機能ごとに整理していくことを考えています。
Q3: 開発とQAの線引きについて、何を最終ゴールとされているでしょうか？リリーススピード？コスト？品質向上？などなど
A3: ゴールとしてはすべてにかかわるが、QCDのバランスを変える話なので、順番があると考えています。現状はQCDのDによっていると考えているが、整理がすすむことでCostが見直される。さらに本来やるべきこと、機能横断で共通でできることがみえてくることで品質があがると考えてます。
Q4: 25名社員で25名PSさんというのは、全てが市場チームなのですか。両者の棲み分けはどのようになっていますでしょうか。
A4: 25名すべてが市場のチームではないです。
本日紹介した市場のスコープを担当している社員は3名でPSさんのほうが多い形となり、PSさんには実行チームとのブリッジなどを担当していただいてます。テストマネージメント改善活動を推進していくうえで社員が必要と考えています。
Q5: 日本市場とグローバル向け市場、両方ともこのチームで対応しているのでしょうか
A5: 日本向け、日本とGlobal共通なものを担当しています。Global向けの部分は同じSectionないのとなりのグループにて担当しています。
LT#1: SQA Best Practices: A Practical Example by Rosana Sanchis
LT#2: Improve test automation operation by Sadaaki Emura
Q1: 再実行可能な（冪等な）テストかどうかは考慮して再実行されるのでしょうか？
A1: 再実行可能かの判別なく、再実行しています。基本的に、再実行繰り返しできる前提でスクリプトを組んでいるからです。当然、出来ないものも一部ありますが、一部のために、その条件を満たす仕組みを組み込むことの工数メリットが大きくないため、いまは組み込んでいません。
Q2: 500 エラーなどはテスト自動化でよくある悩みですが、テスト環境そのものの改善は試みなかったのでしょうか。
A2: 組織の説明であったとおり、開発とQAの組織は独立して存在しています。テスト環境は開発が責任を持っています。当然、開発へのリクエストを出し、開発も対応しています。。ただし、QA主体でできないのが現状です
それでは、みなさん第三回もお楽しみに!
VIDEO
動画が見れない方はこちらをクリックしてください
告知
7月16日（木）に
Rakuten Commerce Tech PDM Online Night を開催します！！
