Rakuten Commerce QA Night#1 のこと
2019/04/24。仕事終わりに二子玉川まで行き、こちらに参加させてもらった。
Automation Testing for Leisure Service
エンジニア時代のテスト自動化の（苦い）経験をふまえ、QAとして心がけたことを発表されていた。うまくいかなかった→ではどうすれば？という思考の流れがよくわかり、とても参考になった。
- 気をつけたこと。自動化のスコープ、目的の明確化、保守・運用設計。
- テストのマトリクスをつくって自動化しない部分の明記、CI条件などを共有。
- チームにあったツール選定を心がけた。
ここからは質疑での話。
- ツールはある程度絞ってメンバーにさわってもらい選定。Ranorexを利用している。
- チーム立ち上げから自動かまでは、数日かからず。
- Jenkinsは3分くらいで終わるジョブが150ほど。
- プロセスはウォーターフォールっぽくやっている。
Test Automation at Rakuten Travel
Testcase generationの部分、graphmlを知らなかったのでどういう理屈でテストケースが生成されるのかちょっとついていけなかった…。
Rakuten QA group and Automation team
ISTQB（JSTQB）によってQAの共通言語を得ることができる。って手元のメモに書いてあったけど、この時の自分は何を思っていたのか。
Rakuten QA Group Introduction & Best Practices
WebエンジニアからQAになった方のお話。 3つの視点でベストプラクティスを紹介されていた。
可視化 Visualization
- JIRA Kanban＋ホワイトボード
- 日々の朝礼
文書化 Documentation
- 機能・サービス関係図
- テスト観点表
- テスト実施ルール
- 英語で書く
- Prj終了時に1, 2日かけて分析しながらノウハウを残す
- ノウハウは整理、更新をしてアクセスしてもらえるようにする
コミュニケーション Communication
- 「しっかりテストする」とは
- テストはバグがあることの証明。ないことの証明はできない。
- Shift left（上流工程から関わる）。開発部門へイチャモンをつけるのではなく情報提供するような立場で接する。貢献する。
- 開発とQAの違い。QAはたとえばデート前にチャック空いているよ、を行ってあげる人。QAの仕事をバグ出しとしてしまうと開発部門との関係が良くなっていかない。
- QAの仕事は手抜きできてしまいやすいからこそ、日頃の声かけが信頼関係につながっていく。
思ったこと
- QAの果たすべき役割、目的を明確にして仕事に臨んでいることがよくわかった。
- Shift left。かっこいい言い方なので使っていこう。ちなみにQAの工数でやるんだろうか。開発チームに取り込まれてなあなあにならないよう距離感大事かもしれない。ノウハウを提供する立場、というのはほどよい距離感な気がする。
- 楽天の社会的な影響力も増してきているなかで、各サービスにおけるスピード／品質へのバランスも変化してきているよう。
- 英語のプレゼン聞けるのすんごい貴重。ありがたいです。
- 英語の聞き取りはまあまあできたけど、ほんと聞くだけになってしまった。聞きながらあれこれ考えたりできない。
- 日本語ネイティブの人の話す英語プレゼンも聞きたい。
