Spring Bootcamp（新卒研修） 2022 QA研修 座学

Moneyforwardの新卒研修2022（エンジニア向け）で利用した資料です。

更新履歴
2022/9/15-------------
60Pバグフィルター
（修正前）
上段にいくほど網目が細かい＝テストの数は多い
下段にいくほど網目が荒い＝テストの数は少ない
（修正後）
上三段の層について、
　上段にいくほど網目が細かい＝テストの数は多い
　下段にいくほど網目が荒い＝テストの数は少ない
下三段の層について、
　その逆
参考文献に以下を追加
・A Practical Guide to Testing in DevOps Japanese Edition

ご指摘感謝です…！

Transcript

1. Spring Bootcamp 2022 QA研修 2022/5/13 Fri.
2. What is QA?
3. QA = Quality Assurance
4. 本日のゴール その１　品質は作り込むもの その２　テスト技法を学ぶ
5. QAを知る
6. 品質保証ってなんだ QAを知る
7. 料理 味見 by 作った人 QAを知る
8. 自転車 （組み立て前） 試乗 by 組み立てた人 QAを知る
9. ソフトウェア （リリース前） 動作検証（テスト） by 開発した人？ QAを知る
10. ソフトウェア （リリース前） 動作検証（テスト） by 開発した人 など QAを知る これだけ、ではないんです！
11. 品質保証とは 対象物が誰か（≒ユーザー） にとって一定の価値がある、 ということを保証すること QAを知る
12. 「一定の価値」とは？ QAを知る
13. • 美味しさ • 辛さ • 具の多さ • 米の銘柄 • トッピングの種類 • 福神漬け有り／無し • 走りやすさ • ブレーキの効き • 耐久度／耐荷重 • デザイン性 • カスタマイズ性 • 電動サポート有り／ 無し • 機能の充実 • 使いやすさ • サポートの手厚さ • 導入のしやすさ • 障害の少なさ • 時間効率化 ちょっと待った！！！ 何か疑問に感じませんか？ QAを知る
14. • 美味しさ • 辛さ • 具の多さ • 米の銘柄 • トッピングの種類 • 福神漬け有り／無し • 走りやすさ • ブレーキの効き • 耐久度／耐荷重 • デザイン性 • カスタマイズ性 • 電動サポート有り／ 無し • 機能の充実 • 使いやすさ • サポートの手厚さ • 導入のしやすさ • 障害の少なさ • 時間効率化 主観的で、指標として曖昧では？ ユーザーはどこに消えた？ QAを知る
15. QAを知る 製品品質 利用時の品質 ※「JIS X 25010」で定義 製品そのものが持っている品質 人がその製品を利用したときに「受け取る」、 または「感じる」品質 ソフトウェアの品質 今日のテーマ
16. QA今昔
17. ジャパン・クオリティ QA今昔
18. QA今昔 メイド・イン・ジャパン 粗悪品 安くてすぐ壊れる 1950年代初期まで 安かろう、悪かろう
19. QA今昔 デミング博士 ※画像はイメージです 第二次世界大戦敗戦後、通信状況改善のため、アメリカ軍が 品質管理技術者を招致。これが日本における品質管理の始ま りといわれている。 アメリカのデミング博士が来日。統計的品質管理 （SQC：Statistical Quality Control）の講演を行い、管理 サイクルPDCAの概念を強調。 日本的全社的品質管理（TQC：Total Quality Control）の 発展。 第二次石油危機による問題に対し、経営層から現場、組織で の問題解決の観点から、TQCが加速。方針管理の重要性が 高まった。 1946年 1950年代 1960年代 1970年代 日本製品の品質を よくしたいなぁ・・・
20. QA今昔 メイド・イン・ジャパン 世界レベルの高品質 日本の品質管理、ものづくりその ものに関心が向けられるように ※製造業のお話 1979年 著エズラ・ヴォーゲル
21. QA今昔 あれから40年、製造業は品質を 保ったまま走り続けている🚗
22. ソフトウェア・クオリティ QA今昔
23. 開発手法の歴史と品質保証 QA今昔 1950~1960年代 1970~1980年代 1990~2000年代 2010年〜イマ！！
24. 1950~1960年代 EDSAC（Electronic Delay Storage Automatic Calculator） System/360 開発手法 • スーパーエンジニア（とにかくすご い人）が1万行のAppを2日で書く • うまくいかなかったら初めから書き 直すの繰り返し • 完全属人化
25. 1961年　NASAに協力したマーガレット・ハミルトンが 「ソフトウェア工学」という言葉を生んだ。 このソフトウェア工学に品質保証の概念が組み込まれた。 • 全てのコンポーネントでのデバッグ（デバッグ） • コンポーネント単位でのテスト（単体テスト） • 結合テスト 1950~1960年代 1969年7月打ち上げ 品質保証のはじまり
26. プログラム品質の見える化 1950~1960年代 1968年 • Rubey & Hartwickがプログラムの 品質と評価方法に関する最初の論文 を発表 • プログラムコードの「属性」と「メ トリクス」を定義 ※参照 導入部 ソフトウェア品質に対するアプローチはブ ラックボックスなのが一般的だが、ユーザー は製品の品質を知りたい、目で見たいと思っ ている。宇宙航空機器は高精度な機能、か つ、あらゆる変更に対応しなければならな い。これは他ソフトウェア分野にも適用でき るのではないだろうか。
27. 開発手法の歴史と品質保証 QA今昔 1950~1960年代 1970~1980年代 1990~2000年代 2010年〜イマ！！
28. 1970~1980年代 Apple I IBM PC PC用OSの普及 開発手法 ウォーターフォールモデルの登場 【メリット】 各工程が分かれていることにより、進捗管理や見積もりがし やすい。段階的に開発が進められる。 【デメリット】 後工程で仕様変更があった際、多大なコストがかかる。後工 程で大きな問題が出てくる可能性が高い。（謎）
29. テストの体系化 1970~1980年代 テストレベル 工程がはっきり分かれ るのでテストの分業化 も進んだ。
30. 品質モデルの体系化 1970~1980年代 1973年 Boehmらの品質モデル • 品質を評価するための観点を初めて 階層化して表現 1977年 McCallらの品質モデル • 過去の論文で提案された品質要因を 集約、整理して体系化 • 品質をファクタ、クライテリア、お よびメトリクスの三階層構造で表現
31. 開発手法の歴史と品質保証 QA今昔 1950~1960年代 1970~1980年代 1990~2000年代 2010年〜イマ！！
32. 1990~2000年代 インターネットと接続機器の普及 開発手法 ※登場は2001年 【メリット】 要求要件の変更などの不確実性に対応しやすい。リリースま でのサイクルがウォーターフォールに比べて短い（小さく失 敗できる） 【デメリット】 プロジェクト全体を俯瞰しにくい。
33. UIテストの自動化 1990~2000年代 2004年 Selenium の登場 • アプリケーションのUIや、 JavaScriptのテストを自動化する 目的で開発された • キャプチャリプレイ機能を搭載 し、コーディングの知識がなくて も自動テストを作成することが可 能 自動化が進んだ理由 開発手法のブラッシュアップに伴い、工程の 最後に配置されるテストがボトルネックにな る事例が多くなってきた。 人的コスト削減、開発フローのさらなる効率 化を求めて自動テストの導入が進んだ。 開発終わってる のにテスト長く ね？
34. 品質モデルの標準化 1990~2000年代 1991年 • 国際標準（ISO）として出版 • 「外部および内部品質」「利用時 の品質」の二つのモデルを規定 ISO標準の目的 • 安全で信頼性が高く、質の高い製品や サービスの創出 • 不良品の生産防止、生産性の向上 • 異なる市場の製品を直接比較可能に。企 業の新市場への参入容易度を高め、公正 な基準による世界貿易の発展を支援 • 製品・消費者・エンドユーザーを保護 し、認定製品が国際的に設定された最低 限の基準に適合していることを保証
35. 品質モデルの標準化 1990~2000年代 製品品質 利用時の品質 ※最新（2011年版）がこちら 製品そのものが持っている品質 人がその製品を利用したときに「受け取る」、 または「感じる」品質
36. 開発手法の歴史と品質保証 QA今昔 1950~1960年代 1970~1980年代 1990~2000年代 2010年〜イ マ！！
37. Money Forwardをさがせ！ 2010年〜イマ！！
38. 開発手法　→　仕組み化 → DevOps with Agile DevOpsの思想 ・開発チームと運用チーム で分かれていた作業を統合　 →　作業分担によるサイロ 化を防ぐ ・ツールを使った自動化 （CI／CDの普及） 　→　システムの信頼性の 向上、トイルの解消 2010年〜イマ！！
39. テストはどこでも化 2010年〜イマ！！
40. 品質もどこでも化 2010年〜イマ！！
41. 閑話休題 参照：アジャイルQAに求められるプロセス全体を俯瞰する「ホリ スティックテスティング」とは何か？（翻訳 ）
42. ソフトウェア開発、進化中 【全部ひとりだった時代】 テスト（この頃はデバッグがメイン） までもちろん全部ひとり 【ウォーターフォール時代】 テスト工程の分業化が進み テストのみ行う職種が爆誕 （テスターさん） 【DevOps時代】 分業するよりもONEチームで やった方がはやい・うまい・やすい アジリティとの戦いが 始まる イマ！！
43. 閑話休題 ソフトウェア開発の難しさ フレデリック・ ブルックス氏 ２　プログラムは、規模が大きい 　　1人乗りのボートは簡単に作れても、1000人乗りの船は難しい。 　　３　プログラムは、簡単に変更できる 　　　　形のある製品の開発では、後で変更ができない。 　　　　　　ソフトウェアは変更が容易で物質的コストもかからない。 １　ソフトウェアは、目に見えない 　　手で触れない、大きさ、重さもない。よって全体像を簡単に把握できない。 　　　開発の難しさも実感できない。 　　４　制約となるものが少なく、自由に作れる 　　　　重力、磁力、電流などの法則に束縛されないため、 　　　　　　動くソフトウェア＝正解となる。（芸術の世界）
44. 品質特性とBugとの戦い
45. 品質特性とは 「 要求事項に関連する製品、プロセス又はシステムに本来備わっている特性」 1. “本来備わっている”とは、そのものが存在している限り、もっている特性を意味す る。 2. 製品、プロセス又はシステムに付与された特性（例:製品の価格，製品の所有者）は、 その製品，プロセス又はシステムの品質特性ではない。 3. 品質工学では、システムの機能を確保するために必要とされ、仕様で規定される特 性。 品質特性とBugとの戦い
46. 製品品質 利用時の品質 製品そのものが持っている品質 人がその製品を利用したときに「受け取る」、 または「感じる」品質 品質特性とBugとの戦い
47. 品質特性 品質副特性 品質特性とBugとの戦い
48. 品質特性 品質副特性 品質特性とBugとの戦い
49. 機能適合性 functional suitability 明示された状況下でシステムを使用すると き、明示的ニーズ及び暗黙のニーズを満足 させる機能を製品又はシステムが提供する 度合い。 ※機能仕様にではなく，機能が明示的ニー ズ及び暗黙のニーズを満足させるかどう か。 保守性 maintainability 意図した保守者によって、製品又はシステ ムが修正することができる有効性及び効率 性の度合い。 品質特性とBugとの戦い
50. 品質特性とBugとの戦い Bug🐞って何だと思いますか？
51. 品質特性とBugとの戦い
52. 品質特性とBugとの戦い
53. 品質特性とBugとの戦い
54. 品質特性とBugとの戦い Bugを見つけるには どこに着目する？👀
55. 品質特性とBugとの戦い Bugを見つけるには
56. 品質特性とBugとの戦い Bugを見つけるには 静的テスト（レビューや静的解析）、 動的テストを通して見つける
57. 品質特性とBugとの戦い Bugを防ぐには どこに着目する？👀
58. 品質特性とBugとの戦い Bugを防ぐには
59. 品質特性とBugとの戦い • 欠陥の素になった根本原因を探し対策を打つ • ドメイン知識不足・コードの変更容易性の低下 ・業務過多による疲労などさまざま Bugを防ぐには
60. 閑話休題 DevOpsバグフィルター • 最上段の・はBugの卵 • Unit（単体テスト）・Integration（結合テ スト）・End to End（E2Eテスト）Alerting （アラート）・Monitoring（モニタリング） ・Logging（ログ）の層をもつ • 上三段の層について、 ◦ 上段にいくほど網目が細かい＝テスト の数は多い ◦ 下段にいくほど網目が荒い＝テストの 数は少ない • 下三段の層について、 ◦ その逆 • Bugは時間経過と共に育つ
61. 参考資料： ◆システム及びソフトウェア製品の品質要求及び評価（SQuaRE） 　−システム及びソフトウェア品質モデル 　 http://kikakurui.com/x25/X25010-2013-01.html ◆品質管理の歴史（統計的品質管理からISO・TQC・TQMへ） 　https://www.sk-quality.com/quality/qc02_history.html ◆ソフトウェア品質技術の歴史を振り返る - ソフトウェア品質測定を中心に - 　https://www.slideshare.net/Bugler/ss-77998794 ◆A Practical Guide to Testing in DevOps Japanese Edition 　https://leanpub.com/testingindevops-japanese-edition 　 　※その他の参考資料についてはスライド内に記載
62. Meety や Twitterでぜひお話ししましょう🐥