Submit Search
QA teamを組成した話
0 likes
533 views
Akira Miki
Shinjuku.rb #56 on Dec 20, 2017
Technology
Related topics:
Distributed Computing
Read more
1 of 43
Download now
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
More Related Content
PPTX
今さらアジャイル巡業In福岡LT「社内勉強会の運営をアジャイルにやってみた」
kei eguchi
PDF
システム開発を世界中に発注するクラウドソーシング「Crabits」
Arihiro Nagasaka
PPTX
5分で武装 ~QnA Maker編~
Takashi Ushigami
PDF
Serverless LT 20201202
ssuserebdd2a
PPTX
千年繁栄する法
Ashitaba YOSHIOKA
PDF
ドメイン駆動設計(DDD)導入判定チェックシート
Takuya Kawabe
PDF
実践DevOps!SonicGarden流Herokuガチ運用術!SonicGarden Study #09
Masahiro Nishimi
PDF
年間数千のプロジェクトといろいろなクライアントの狭間で~WebSig会議 vol.34「Webディレクター必見!プロジェクトを成功に導く、オンラインツール...
WebSig24/7
今さらアジャイル巡業In福岡LT「社内勉強会の運営をアジャイルにやってみた」
kei eguchi
システム開発を世界中に発注するクラウドソーシング「Crabits」
Arihiro Nagasaka
5分で武装 ~QnA Maker編~
Takashi Ushigami
Serverless LT 20201202
ssuserebdd2a
千年繁栄する法
Ashitaba YOSHIOKA
ドメイン駆動設計(DDD)導入判定チェックシート
Takuya Kawabe
実践DevOps!SonicGarden流Herokuガチ運用術!SonicGarden Study #09
Masahiro Nishimi
年間数千のプロジェクトといろいろなクライアントの狭間で~WebSig会議 vol.34「Webディレクター必見!プロジェクトを成功に導く、オンラインツール...
WebSig24/7
What's hot
(20)
PDF
No020-01-suc3rum-20101129
Sukusuku Scrum
PDF
アジャイル開発への組織の理解を得るために
teyamagu
PPTX
リリースを支える負荷測定
gree_tech
PDF
塹壕より、かんばんとリーン - デブサミ2013関西 @devsumi #kansumiA5
Dai FUJIHARA
PDF
アジャイルの今とこれから-Agile conference2012参加報告-技術動向編
Hiroyuki Ito
PPTX
Agile Japan2016 Kanban
Atsushi Suzuki
PPTX
プランニングポーカーのすすめ
sugimoto1022
PDF
新規システムUI開発で設計失敗したけどいい感じにリファクタリングできた話
KentaEndoh
PDF
20160517 jaws ug osaka-no.14_disscussion
Daiki Mori
PDF
Agile_samurai_kpt2015_06_21_pub
Takeshi Arai
PDF
All about 開発本部infra部 TASKs
gree_tech
PPTX
僕らのおれおれメトリクス / We Metrics Our Own Way!
Yasui Tsutomu
PDF
DDDのすすめ
Ryo Amano
PPTX
チーム運用で苦労した話_20160629
kohei noguchi
PDF
XP開発におけるUIテスト - Bonfire iOS#4
Shinichiro Yamashita
PDF
アプリケーション開発目線から考える テストの書き方について
bitbank, Inc. Tokyo, Japan
PPTX
分散開発チームによるAgile開発実践 ~いろいろハマった!よかった
Makoto Iguchi
PDF
良きモノの提供に向けた協働 - 開発とテストが一体となったソフトウェア開発 -
teyamagu
PDF
開発とテストが一体となったソフトウェア開発
Yahoo!デベロッパーネットワーク
PPTX
フロリダより愛をこめて
Hiroyuki Ito
No020-01-suc3rum-20101129
Sukusuku Scrum
アジャイル開発への組織の理解を得るために
teyamagu
リリースを支える負荷測定
gree_tech
塹壕より、かんばんとリーン - デブサミ2013関西 @devsumi #kansumiA5
Dai FUJIHARA
アジャイルの今とこれから-Agile conference2012参加報告-技術動向編
Hiroyuki Ito
Agile Japan2016 Kanban
Atsushi Suzuki
プランニングポーカーのすすめ
sugimoto1022
新規システムUI開発で設計失敗したけどいい感じにリファクタリングできた話
KentaEndoh
20160517 jaws ug osaka-no.14_disscussion
Daiki Mori
Agile_samurai_kpt2015_06_21_pub
Takeshi Arai
All about 開発本部infra部 TASKs
gree_tech
僕らのおれおれメトリクス / We Metrics Our Own Way!
Yasui Tsutomu
DDDのすすめ
Ryo Amano
チーム運用で苦労した話_20160629
kohei noguchi
XP開発におけるUIテスト - Bonfire iOS#4
Shinichiro Yamashita
アプリケーション開発目線から考える テストの書き方について
bitbank, Inc. Tokyo, Japan
分散開発チームによるAgile開発実践 ~いろいろハマった!よかった
Makoto Iguchi
良きモノの提供に向けた協働 - 開発とテストが一体となったソフトウェア開発 -
teyamagu
開発とテストが一体となったソフトウェア開発
Yahoo!デベロッパーネットワーク
フロリダより愛をこめて
Hiroyuki Ito
Ad
Similar to QA teamを組成した話
(20)
PDF
地図を捨ててコンパスを頼りに進め
Rakuten Group, Inc.
PDF
地図を捨ててコンパスを頼りに進め
Dai FUJIHARA
PDF
PHPアプリの品質を(ある程度)保つために出来る事 〜組織編〜
Katsuhiro Miura
PDF
CEDEC2015講演 チーム開発をスムーズにするために
Takafumi Ikeda
PDF
SpotBugs(FindBugs)による 大規模ERPのコード品質改善
Works Applications
PDF
ソフトウェア開発の現場風景
Koichi ITO
PDF
アジャイルマネジメントとは?
Kiro Harada
PDF
データファースト開発
Katsunori Kanda
PDF
TechRacho: 技術情報発信から広げるエンジニア発のコミュニケーション文化作り
Masato Mori
PPTX
チームトポロジーから学び、 データプラットフォーム組織を考え直した話.pptx
Rakuten Commerce Tech (Rakuten Group, Inc.)
PDF
今、おさえておきたい DevOps
智治 長沢
PPTX
20170221 cnet live講演資料
Retrieva inc.
PDF
俺のローカル開発環境 - MTDDC Meetup NAGOYA 2014
taiju higashi
PDF
自社開発プロダクト ALL-IN で行っている単体テストのパフォーマンスチューニングTips
Shou Takenaka
PDF
20141003 webマーケティングエンジニアリング
Innova Inc.
PDF
GCSアジャイル開発を使ったゲームの作り方
Hiroyuki Tanaka
PDF
Dockerizeして 大変だった話、幸せになった話
Akira Miki
PDF
作る人から作りながら運用する人になっていく
Ryo Mitoma
PDF
チームにRedmineを適用せよ! #RxTstudy
Dai FUJIHARA
PDF
ディープラーニング最近の発展とビジネス応用への課題
Kenta Oono
地図を捨ててコンパスを頼りに進め
Rakuten Group, Inc.
地図を捨ててコンパスを頼りに進め
Dai FUJIHARA
PHPアプリの品質を(ある程度)保つために出来る事 〜組織編〜
Katsuhiro Miura
CEDEC2015講演 チーム開発をスムーズにするために
Takafumi Ikeda
SpotBugs(FindBugs)による 大規模ERPのコード品質改善
Works Applications
ソフトウェア開発の現場風景
Koichi ITO
アジャイルマネジメントとは?
Kiro Harada
データファースト開発
Katsunori Kanda
TechRacho: 技術情報発信から広げるエンジニア発のコミュニケーション文化作り
Masato Mori
チームトポロジーから学び、 データプラットフォーム組織を考え直した話.pptx
Rakuten Commerce Tech (Rakuten Group, Inc.)
今、おさえておきたい DevOps
智治 長沢
20170221 cnet live講演資料
Retrieva inc.
俺のローカル開発環境 - MTDDC Meetup NAGOYA 2014
taiju higashi
自社開発プロダクト ALL-IN で行っている単体テストのパフォーマンスチューニングTips
Shou Takenaka
20141003 webマーケティングエンジニアリング
Innova Inc.
GCSアジャイル開発を使ったゲームの作り方
Hiroyuki Tanaka
Dockerizeして 大変だった話、幸せになった話
Akira Miki
作る人から作りながら運用する人になっていく
Ryo Mitoma
チームにRedmineを適用せよ! #RxTstudy
Dai FUJIHARA
ディープラーニング最近の発展とビジネス応用への課題
Kenta Oono
Ad
More from Akira Miki
(10)
PDF
performance hack 101
Akira Miki
PDF
The bottleneck is you
Akira Miki
PDF
background jobで 気をつけないといかんところ
Akira Miki
PDF
今だから言えるやらないほうが良かったこと
Akira Miki
PDF
AWS Auroraよもやま話
Akira Miki
PDF
1秒でも早くAutoScale
Akira Miki
PDF
決済って悩むことが多い
Akira Miki
PDF
rails + serverengineで お手軽daemon
Akira Miki
PDF
what is_the_best_way_of_method_swizzling
Akira Miki
PDF
Microserviceなんて最初からやるもんじゃ無かった
Akira Miki
performance hack 101
Akira Miki
The bottleneck is you
Akira Miki
background jobで 気をつけないといかんところ
Akira Miki
今だから言えるやらないほうが良かったこと
Akira Miki
AWS Auroraよもやま話
Akira Miki
1秒でも早くAutoScale
Akira Miki
決済って悩むことが多い
Akira Miki
rails + serverengineで お手軽daemon
Akira Miki
what is_the_best_way_of_method_swizzling
Akira Miki
Microserviceなんて最初からやるもんじゃ無かった
Akira Miki
QA teamを組成した話
1.
QAチームを組成した話 @threetreeslight Repro Inc. Shinjuku.rb #56 Dec
20, 2017
2.
@treetreeslight At Repro Inc Organize -
Shinjuku.rb (最近出れずにすいませんでした 🙏 )
3.
What s Repro?
4.
アプリ用マーケティングツール
5.
なんで使うの辞めたの?
6.
対策をサクッと打てる
7.
• 4桁万DAU • 2桁億のプッシュを毎月配信
8.
とりあえずReproいれとこ をグローバルで目指してます
9.
はじめます
10.
みなさんは十分に テストコードは書かれている と思いますので
11.
今日話すこと・話さないこと • 話すこと • デバッグを通したQAチームの組成理由 •
機能テスト・システムテスト • 話さないこと • 単体・コンポーネント・結合テストの技法
12.
当時
13.
痛いバグが月23本 • 開発 • 求められる新機能追加・改善 •
増えるユーザーに耐えるスループット • 柔軟な分析・速やかな施策実行を支え るための複雑な分散システム •
14.
あれ??辛くね?
15.
精神的に来る • B2Bでバグによる機会損失・損失は厳禁。 ほんとヤバイ • じゃぁテスト拡充!っていうけど、複雑 な分散システムを試験する仕組み作りは 超☆大☆変 •
そうすると各種ミドルウェアとその設定 からアプリケーションの仕組みまで網羅 的に理解していないといけない
16.
いくら時間あっても足りない?
17.
現実解としてのテストチーム • テストチームの定義の中でも品質保証 (QA)が目的に組成 • リリースに際し、
バグを発見 するため の中間層 • 主にデバッグによる機能テスト・システ ムテストを実施
18.
Boris Beizer先生曰く > ソフトウェア費用の中で最も大きな割合を占め るのは、もちろんバグ費用である。そうするとソ フトウェアの品質保証の第1目標はバグの作り込 みの防止である。 >
… > われわれの努力にも関わらず、われわれが人間 であるがためにバグは存在する。テストの第1の 目的であるバグの未然防止がうまくいかないので あれば、バグの発見という第2の目的に向かって 努力しなければいけないことになる。
19.
われわれが人間であるがため にバグは存在する
20.
バグの発見 に向かって努力 しなければいけない
21.
概ね方向性は良さそう
22.
メンバーに求められるスキル
23.
Cem Kaner先生によると • 真のQAグループはすごい技術をもっていなくてはいけな い、という点に注意しておくこと。 •
分析や設計、実装、プロジェクト管理、ドキュメント作 成などに渡って有能である必要がある。 • そうでなければ信頼されないものだ。
24.
Cem Kaner先生によると • 誠実さ、そして品質に対する責任 感 •
理論よりも経験を元に根拠を身 につける能力 • 学歴が高く、心理学なども含め、 科学的に考える訓練を受けている (CSより大事) • プログラミングの経験 • コンピューターやソフトウェア の豊富な利用経験 • 組み合わせ論についての知識 • 優れたコミュニケーション能力や 高い文章知識 • バグの上手な推測 • 抽象化を素早くできる • パズルが得意なこと • 効率という概念を持っていること • 同時に多くの仕事をこなせること • スケジュールをきちんと立てられ ること • 注意深く、忍耐強く、細部までき ちんと観察できること • 他人の気持ちがわかること • 仕様書の読み書きができること
25.
Boris Beizer先生によると • テスト担当者はプログラムの設計者と同レベルの知識が 必要となり、実際問題としてプログラムの設計者でない とテスト設計は難しい。 •
テストをするには、建設的な精神分裂状態が必要で、プ ログラムの設計者とテスト担当者の2つの役割を明確に 区分しなければいけない。 • テスト担当者のとるべき態度としては懐疑的、非妥協的、 非友好的で、かつ、プログラマが開発したソフトウェア を完全に破壊したい衝動にかられることが必要である。
26.
そんな人採用できるかい!!
27.
ましてデバッグやりたい人なん てそんないるかいな!
28.
育てる前提で プロセスとチームを作る
29.
開発プロセスを整理 • リリース頻度を週に2回(火曜・木曜)に下げ、 QA時間の確保 • 新機能開発する際は、要件定義時にQA managerがテスト設計を実施 •
開発段階で特定featureをQAする feature QA serviceを社内に提供 •
30.
毎QAプロセス • QA Prepare •
QA managerが実施 • QA check-in • memberの理解を深める • Debug • 機能を網羅的に触る探索テスト • PRごとに構造テスト • QA check-out • QA内容の振り返り • 開発/QAプロセスの改善
31.
開発者と意識を揃える バグが多く残っていると認識する、バグを称え る。誤報を責めない。 心理学の実験結果 • バグが多く残っていると思ったり、バグを見つけると褒められ たり報酬があると、誤報を混じるが、多数のバグを見つけられ る • プログラムが正しく動くと思いこんだり、バグを見つけると誰 かに言われたり、誤報は罰せられる場合、本物の不具合をいく つも見落としてしまう。
32.
チーム • アルバイトで、エンジニアになりたい人を募集 し組織 member(part-time) QA manager
(私が兼務)
33.
育成 • 独学で自走できる育成プログラムの構築 • 生産性向上のために徹底的にツールに慣れる •
ドキュメンテーション能力、ロジカルシンキングを徹底的 に叩き込む • 初めて学ぶソフトウェアのテスト技法でブラックボックス テストについて学ぶ • webの基礎知識を身につける • プログラマーとしてのスペシャリティを身に付ける • iOS, Androidから好きなものを選び、ReproでのQAに 特化したアプリ作成 • 並行してテストについてのスペシャリティを身につける • Boris BeizerとCem Kanerの書籍を何度も読む
34.
育成プログラムを乗り越える or Die
35.
生き残った メンバーの強さたるや!!
36.
最近では サービスのQAにとどまらず
37.
会社全体へのサービス提供 • ツールの品質担保(<ー今まで話したこと) • ツールの定期リリースに対応したテスト •
開発者向けのon-demandの機能テストの提供 • お客様対応への品質の担保 • テクニカルサポートが回答に資する社内ドキュメント作成 • お客様が参照する社外ドキュメント作成 • 社内メンバーの理解品質の担保 • QAを通してReproのサービスおよび組織理解を深める Bootcampプログラムを社内に提供
38.
ソフトウェアテストと その組織論について詳しくは
39.
以下の書籍がおすすめ • カジュアルに読める順 • 初めて学ぶソフトウェアのテスト技法 •
ソフトウェアテスト293の鉄則 • 基礎から学ぶソフトウェアテスト • ソフトウェアテスト技法 • 実践的プログラミングテスト入門
40.
そんな素敵な環境で 切磋琢磨したいアナタに
41.
WE ARE HIRING
NOW!!! https://repro.io/careers/
42.
Appendix
43.
QAチームが品質を保証するのか? No • 「私の仕事は納期までに製品を仕上げることであって、 品質を確保することはQAの仕事だ」となってしまう。 • 品質の責任を経営陣以外の部門に集約すると失敗する。 •
会社全体、特に経営陣が、品質に責任を持たなくてはい けない。 By Cem Kaner
Download