以前の開発プロセス チームを⼀体化した後 l 軽微なバグや改善が後回しになる l テストフェーズの進捗によって スケジュールを調節することが多い l MTGに参加しても効率的に関われない l 登録したバグや改善はすぐに対応する l 無理なくスムーズなテストフェーズの進⾏が可能 l 開発/QAチームがスムーズに着⼿可能 03.上流⼯程での実践内容 以前との変化
QAチームが各プロセスに関わることは⼤きな利点がある 質問「QAチームについて企画・開発チームが思っていること、助かっていることを教えてください」 l 仕様分からない時やなぜ現状の実装になっているのか教えてくれる l 企画のざっくり要件をもとに「どうあるべきなのか」想定して事前レビューをしてくれる l 想定外の使い⽅が運⽤で発⽣した際に問題なく実施できるかを検証してくれる l 全体の良いタイミングでリリース対象・スケジュールなどの調整をしてくれる テスト以外の部分で「助かっている」と感じていることも多い 03.上流⼯程での実践内容 企画・開発チームからの声
開発チームが感じたこと 04.その先にあったもの 「実装機能に対して、全員が最後まで責任を感じるようになった」 以前の開発チーム l ⾃分たちの実装、ユニットテストを終わらせることに集中 l テストフェーズのスケジュールについて関⼼が低かった 現在の開発チーム l リリースで品質を確保するためにテストスケジュールまで踏まえた 実現可能性を⼀緒に考えるようになった
「問題・課題の捉え⽅が変化した」 以前のQAチーム l 企画/開発チームに相談しても忙しいから対応してもらえないだろう l ⼿が空いたときに出来ることだけQAチーム内でやろう 現在のQAチーム l 各チームの問題は、プロジェクトメンバー全員の問題 l 全員で⽴ち向かった⽅が⾊々な解決策が⾒える QAチームが感じたこと 04.その先にあったもの JaSST Kyushuで和⽥さんの講演を受けた時の話を紹介
「質とスピード」〜ソフトウェア開発の典型的な誤解を解く〜※ l 質を犠牲にするとき犠牲にされがちなのは「内部品質(保守性)である」 →内部品質が下がるとスピードが落ちる l コードの品質を⾼く保つからこそスピードが上がり、リードタイムの短縮につながる l 質とスピードの関係はトレードオフではない ※https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition 講演内容 04.その先にあったもの
QAチームの「内部品質」ってなんだろう…︖ テストケースの品質 l 期待結果が古い l 間違った画像が載っている l 他者が⾒た時にテストステップが分かりづらい 作業の品質 l 繰り返し⾏う単純/簡単な作業を⼈⼿で対応 l ⼈⼿の対応が必要な作業でミスや勘違いが発⽣ 受講後に私が思ったこと QAチームの内部品質を上げることでリードタイムの短縮に繋がるのでは…︖ QAチームの内部品質改善を対応 04.その先にあったもの
「QA」=「テスト」というイメージの強さ l プロダクト品質を向上できる最初の⼀歩を邪魔しているかも l チームメンバーの影響＋LINE STYLE＋未経験QA Engineer 「QA Engineer」=「品質を保証する」 l ユーザー⽬線の提案、バグの検出→お仕事の⼀部 l プロダクトを作るチームの品質にも貢献できる 05.おわりに 「QA」という役割について QA Engineerが⼒を注ぐべきターゲットは開発プロセス全体
line_developers
udzura
carta_engineering
uzulla
dskst
odasho
yoshinagaiwnl
makamaka
tgalopin
kubukoz
nenonaninu
nasa9084
orgachem
robhawkes
eileencodes
paigeccino
mza
addyosmani
62gerente
nonsquared
ufuk
brettharned
eitanlees
garrettdimon
revolveconf