Upgrade to Pro — share decks privately, control downloads, hide ads and more …

とあるQAチームの立ち上げから半年〜1年のお仕事 / bizreach-qa-meetup20190718

42e71ef7600b196750285f224a094a51?s=47 isekumi
July 18, 2019

とあるQAチームの立ち上げから半年〜1年のお仕事 / bizreach-qa-meetup20190718

42e71ef7600b196750285f224a094a51?s=128

isekumi

July 18, 2019
Tweet

Transcript

  1. とあるQAチームの ⽴ち上げから半年〜1年の お仕事 2019/07/18 BizReach QA Meetup 井芹 久美⼦(Kumiko Iseri)

    1
  2. 誰︖ • 現職 QA基盤推進室に所属 • QAという肩書きは、ここ半年 • 前職では、エンタプライズ系ソフトウェア開発業務を経験(SE) • 出没先、コミュニティ

    • JaSSTʻ18 Kyushu にて ワークショップ「ワークを通してじっくり考える同値分割&境界値分析」担当 http://www.jasst.jp/symposium/jasst18kyushu/report.html • 過去、WACATE(若⼿テストエンジニア向けワークショップ)の実⾏委員として活動 https://wacate.jp/ • など 2
  3. おはなしすること 1. ⽴ち上げから半年〜1年のQAチームがやっていること • 主に、BizReachシステム向けのQA業務の話 • 事業ごとに開発の進め⽅は異なり、QA業務も事業ごとに異なります 2. QAの仕事で役⽴っていること、必要だと感じること 華やかな話はありませんw

    …が、できるだけ、実際の仕事内容が伝わるようお話したいと思います 3
  4. BizReachシステム • 転職サイト • ウェブサイト、スマホアプリでサービスを提供 • 求職者様向け、ヘッドハンター様向けなど • 画⾯の例 •

    https://www.bizreach.jp/login/ 4
  5. QA=Quality Assurance って︖ どんな仕事を思い浮かべますか︖ • テストをする︖ • ⾃動エンドツーエンドテストのテストコードを書く︖ • レビューをする︖

    • バグ収束曲線を書いたり、データの分析をする︖ 5
  6. QAチームの現在の主担当領域 • テスト • 分析、設計、実⾏を、2週間単位で実施 • エンドユーザが直接触れる範囲 • ブラックボックステスト 6

  7. 企画、 要件定義 設計 PGM テスト QAチームは、いつテストを⾏う? 少しずつ、より前の段階から 開発チームと⼀緒に テストの内容や分担を検討することが増えてきている 開発の終盤で、開発チームとは別組織としてテストをする

    7 このあたり
  8. リリースのサイクル2週間=⼤体10営業⽇/1サイクルに従う QAチームは、どんなサイクルでテストする? 8 1つ前の リリース後 n⽇⽬ ★ 1 2 3

    4 5 6 7 8 9 ★ 1 2 3 4 5 6 7 8 9 ★ 1 開発チーム QAチーム ★=リリース⽇ 設計、PGM 設計、PGM 設計、PGM テスト分析、設計 テスト実⾏ テスト分析、設計 テスト 分析、 設計 テスト実⾏ 2週間
  9. QAチームと開発チームの関係は? 独⽴ 協調 独⽴ × 柔軟 協調 × 柔軟 独⽴

    × 定型 協調 × 定型 組織は別だが、 ⼀緒にテストを検討することや データの確認など開発チームに協⼒して もらうことも。 リリース都度、 案件内容やスケジュールなどの制約にあわせて QAチームでテストケースを考える。 9 柔 軟 定 型
  10. テストだけ︖ プロダクト 10 • QAによるテスト • テストの内容や分担の相談

  11. QAチームの半年〜1年の取り組み • QAによるテスト • テストの内容や分担の相談 • 開発プロセスの整理 • リリース判定会での報告 •

    チケットの書き⽅ルール提案 • ⽤語の整備(全社向け) • 勉強会の開催 • 障害分析 プロダクト プロセス プロダクト&プロセス 11
  12. テスト以外はプロセス改善関係が多い 難しく聞こえるかもしれませんが、だいたい以下のいずれか 12 現状を ⾒える化する • 改善が必要な箇 所を特定する ⾒える化の結果 を共有する

    • どう困るか、 はっきりさせる • 関係者で同じ ⽅向を向く 課題に対応する • 課題と対応内容 が明確な場合は ここから始まる こともある
  13. 現状の⾒える化、⾒える化の結果の共有 • 課題があるところ、過去と⽐べた際の変化を確認する • e.g. リリース判定会でのテスト結果の報告 • e.g. 開発プロセスの整理、プロセスの定義の明確化 •

    企画されてからリリースされるまで、開発の流れを図⽰ • プロセスの組み替え、追加、変更が必要な箇所はないか︖ • e.g. 障害分析 • ⾒える化する途中で課題を⾒つけることもある • e.g. 分析したいデータがチャット上にしかない 13
  14. 課題に対応する • 対応は緩急をつける • 具体的に困っている⼩さめのところから着⼿ • ⽇々の⾏動で少しでも改善できそうな部分 • e.g. チケットの書き⽅のルール提案

    • 作業負荷、⼼理的負荷少なく対応できそうな部分 • e.g. 勉強会の開催 • 影響が⼤きい対応は、情報収集しながら少しずつ準備する • 実態を理解した上で対応できるように • e.g. ⽤語の整備(全社向け) 14
  15. 改めて、QAチームの現在の主担当領域 • プロダクトのテスト • 分析、設計、実⾏を、2週間単位で実施 • エンドユーザが直接触れる範囲 • ブラックボックステスト •

    プロセスの改善 • ⾒える化、共有、課題の対応 • 開発に直接関係するプロセスを中⼼に実施 15
  16. おはなしすること 1. ⽴ち上げから半年〜1年のQAチームがやっていること 2. QAの仕事で役⽴っていること、必要だと感じること 16

  17. 難しさ • 2週間でテストまで終わらせるスピード感が求められる • 仕様を聞いたその場で、 テストの規模感や想定されるリスクを話したいことがある • 答えを⾃社(⾃分たち)で決めていく • どの機能追加を、どんな優先度で対応し、どんな品質をどこまで求めるか︖

    • ⽴場や得意分野の異なる関係組織が多い • QAや、プロダクトをつくるエンジニアの組織だけではない 17
  18. 役⽴っていること、必要だと感じること • テスト、品質の基礎知識 • ⾔葉や概念を知っていると、より素早く広く考えやすくなる、説明しやすくなる • テストだけでない、周辺の技術やプロセスへの関⼼ • 品質の向上や安定化に繋がるトピックは、開発プロセスのそこかしこにある •

    テスト以外で改善する⽅法を提案した⽅がよいこともある • ⽴場の違う⼈へ説明する⼒ • 良いプロセス改善には多様なチームの⼈の協⼒が必要なことが多い 18
  19. QAの経験がない/少ない…という⽅へ 半年間の、QAとしての⽇々で感じたこと。 • 必要な品質は、プロダクトやプロジェクト次第で異なる。 知識を⾝につけることはもちろん、 品質に対して⾃分の考えを持つこと、考える癖をつけることも⼤事。 • やらされ仕事でも、 ⾃分たちで考えて周囲を巻き込み納得感を持って進める仕事でも、 1⽇を終えることができてしまう

    • QAとしてできることは、思っていたより沢⼭ある。 やりたいこと、その実現に必要なことを、具体的に考えることも⼤事。 • ときどきは肩書きにこだわらず、広く考えてみてはいかがでしょう︖ 19
  20. おはなししたこと 1. ⽴ち上げから半年〜1年のQAチームがやっていること • プロダクト、プロセス両⾯から良いものづくりにつながる取り組み 2. QAの仕事で役⽴っていること、必要だと感じること • テストや品質の知識、周辺の技術やプロセスへの関⼼、説明⼒ •

    品質について考える癖、具体的にやりたいことを考えてみるのも⼤事 華やかな話はありませんでしたが、ご参考になれば嬉しいです 20