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.
   

   View Slide

2. What is QA?
   

   View Slide

3. QA = Quality Assurance
   

   View Slide

4. 本日のゴール
   その１　品質は作り込むもの
   その２　テスト技法を学ぶ
   

   View Slide

5. QAを知る
   

   View Slide

6. 品質保証ってなんだ
   QAを知る
   

   View Slide

7. 料理 味見
   by 作った人
   QAを知る
   

   View Slide

8. 自転車
   （組み立て前）
   試乗
   by 組み立てた人
   QAを知る
   

   View Slide

9. ソフトウェア
   （リリース前）
   動作検証（テスト）
   by 開発した人？
   QAを知る
   

   View Slide

10. ソフトウェア
    （リリース前）
    動作検証（テスト）
    by 開発した人
    など
    QAを知る
    これだけ、ではないんです！
    

    View Slide

11. 品質保証とは
    対象物が誰か（≒ユーザー）
    にとって一定の価値がある、
    ということを保証すること
    QAを知る
    

    View Slide

12. 「一定の価値」とは？
    QAを知る
    

    View Slide

13. ● 美味しさ
    ● 辛さ
    ● 具の多さ
    ● 米の銘柄
    ● トッピングの種類
    ● 福神漬け有り／無し
    ● 走りやすさ
    ● ブレーキの効き
    ● 耐久度／耐荷重
    ● デザイン性
    ● カスタマイズ性
    ● 電動サポート有り／
    無し
    ● 機能の充実
    ● 使いやすさ
    ● サポートの手厚さ
    ● 導入のしやすさ
    ● 障害の少なさ
    ● 時間効率化
    ちょっと待った！！！
    何か疑問に感じませんか？
    QAを知る
    

    View Slide

14. ● 美味しさ
    ● 辛さ
    ● 具の多さ
    ● 米の銘柄
    ● トッピングの種類
    ● 福神漬け有り／無し
    ● 走りやすさ
    ● ブレーキの効き
    ● 耐久度／耐荷重
    ● デザイン性
    ● カスタマイズ性
    ● 電動サポート有り／
    無し
    ● 機能の充実
    ● 使いやすさ
    ● サポートの手厚さ
    ● 導入のしやすさ
    ● 障害の少なさ
    ● 時間効率化
    主観的で、指標として曖昧では？
    ユーザーはどこに消えた？
    QAを知る
    

    View Slide

15. QAを知る
    製品品質 利用時の品質
    ※「JIS X 25010」で定義
    製品そのものが持っている品質 人がその製品を利用したときに「受け取る」、
    または「感じる」品質
    ソフトウェアの品質
    今日のテーマ
    

    View Slide

16. QA今昔
    

    View Slide

17. ジャパン・クオリティ
    QA今昔
    

    View Slide

18. QA今昔
    メイド・イン・ジャパン
    粗悪品
    安くてすぐ壊れる
    1950年代初期まで
    安かろう、悪かろう
    

    View Slide

19. QA今昔
    デミング博士
    ※画像はイメージです
    第二次世界大戦敗戦後、通信状況改善のため、アメリカ軍が
    品質管理技術者を招致。これが日本における品質管理の始ま
    りといわれている。
    アメリカのデミング博士が来日。統計的品質管理
    （SQC：Statistical Quality Control）の講演を行い、管理
    サイクルPDCAの概念を強調。
    日本的全社的品質管理（TQC：Total Quality Control）の
    発展。
    第二次石油危機による問題に対し、経営層から現場、組織で
    の問題解決の観点から、TQCが加速。方針管理の重要性が
    高まった。
    1946年
    1950年代
    1960年代
    1970年代
    日本製品の品質を
    よくしたいなぁ・・・
    

    View Slide

20. QA今昔
    メイド・イン・ジャパン
    世界レベルの高品質
    日本の品質管理、ものづくりその
    ものに関心が向けられるように
    ※製造業のお話
    1979年
    著エズラ・ヴォーゲル
    

    View Slide

21. QA今昔
    あれから40年、製造業は品質を
    保ったまま走り続けている🚗
    

    View Slide

22. ソフトウェア・クオリティ
    QA今昔
    

    View Slide

23. 開発手法の歴史と品質保証
    QA今昔
    1950~1960年代 1970~1980年代 1990~2000年代 2010年〜イマ！！
    

    View Slide

24. 1950~1960年代
    EDSAC（Electronic Delay Storage Automatic
    Calculator）
    System/360
    開発手法
    ● スーパーエンジニア（とにかくすご
    い人）が1万行のAppを2日で書く
    ● うまくいかなかったら初めから書き
    直すの繰り返し
    ● 完全属人化
    

    View Slide

25. 1961年　NASAに協力したマーガレット・ハミルトンが
    「ソフトウェア工学」という言葉を生んだ。
    このソフトウェア工学に品質保証の概念が組み込まれた。
    ● 全てのコンポーネントでのデバッグ（デバッグ）
    ● コンポーネント単位でのテスト（単体テスト）
    ● 結合テスト
    1950~1960年代
    1969年7月打ち上げ
    品質保証のはじまり
    

    View Slide

26. プログラム品質の見える化
    1950~1960年代
    1968年
    ● Rubey & Hartwickがプログラムの
    品質と評価方法に関する最初の論文
    を発表
    ● プログラムコードの「属性」と「メ
    トリクス」を定義
    ※参照
    導入部
    ソフトウェア品質に対するアプローチはブ
    ラックボックスなのが一般的だが、ユーザー
    は製品の品質を知りたい、目で見たいと思っ
    ている。宇宙航空機器は高精度な機能、か
    つ、あらゆる変更に対応しなければならな
    い。これは他ソフトウェア分野にも適用でき
    るのではないだろうか。
    

    View Slide

27. 開発手法の歴史と品質保証
    QA今昔
    1950~1960年代 1970~1980年代 1990~2000年代 2010年〜イマ！！
    

    View Slide

28. 1970~1980年代
    Apple I
    IBM PC
    PC用OSの普及 開発手法
    ウォーターフォールモデルの登場
    【メリット】
    各工程が分かれていることにより、進捗管理や見積もりがし
    やすい。段階的に開発が進められる。
    【デメリット】
    後工程で仕様変更があった際、多大なコストがかかる。後工
    程で大きな問題が出てくる可能性が高い。（謎）
    

    View Slide

29. テストの体系化
    1970~1980年代
    テストレベル
    工程がはっきり分かれ
    るのでテストの分業化
    も進んだ。
    

    View Slide

30. 品質モデルの体系化
    1970~1980年代
    1973年
    Boehmらの品質モデル
    ● 品質を評価するための観点を初めて
    階層化して表現
    1977年
    McCallらの品質モデル
    ● 過去の論文で提案された品質要因を
    集約、整理して体系化
    ● 品質をファクタ、クライテリア、お
    よびメトリクスの三階層構造で表現
    

    View Slide

31. 開発手法の歴史と品質保証
    QA今昔
    1950~1960年代 1970~1980年代 1990~2000年代 2010年〜イマ！！
    

    View Slide

32. 1990~2000年代
    インターネットと接続機器の普及
    開発手法
    ※登場は2001年
    【メリット】
    要求要件の変更などの不確実性に対応しやすい。リリースま
    でのサイクルがウォーターフォールに比べて短い（小さく失
    敗できる）
    【デメリット】
    プロジェクト全体を俯瞰しにくい。
    

    View Slide

33. UIテストの自動化
    1990~2000年代
    2004年
    Selenium の登場
    ● アプリケーションのUIや、
    JavaScriptのテストを自動化する
    目的で開発された
    ● キャプチャリプレイ機能を搭載
    し、コーディングの知識がなくて
    も自動テストを作成することが可
    能
    自動化が進んだ理由
    開発手法のブラッシュアップに伴い、工程の
    最後に配置されるテストがボトルネックにな
    る事例が多くなってきた。
    人的コスト削減、開発フローのさらなる効率
    化を求めて自動テストの導入が進んだ。
    開発終わってる
    のにテスト長く
    ね？
    

    View Slide

34. 品質モデルの標準化
    1990~2000年代
    1991年
    ● 国際標準（ISO）として出版
    ● 「外部および内部品質」「利用時
    の品質」の二つのモデルを規定
    ISO標準の目的
    ● 安全で信頼性が高く、質の高い製品や
    サービスの創出
    ● 不良品の生産防止、生産性の向上
    ● 異なる市場の製品を直接比較可能に。企
    業の新市場への参入容易度を高め、公正
    な基準による世界貿易の発展を支援
    ● 製品・消費者・エンドユーザーを保護
    し、認定製品が国際的に設定された最低
    限の基準に適合していることを保証
    

    View Slide

35. 品質モデルの標準化
    1990~2000年代
    製品品質 利用時の品質
    ※最新（2011年版）がこちら
    製品そのものが持っている品質 人がその製品を利用したときに「受け取る」、
    または「感じる」品質
    

    View Slide

36. 開発手法の歴史と品質保証
    QA今昔
    1950~1960年代 1970~1980年代 1990~2000年代
    2010年〜イ
    マ！！
    

    View Slide

37. Money Forwardをさがせ！
    2010年〜イマ！！
    

    View Slide

38. 開発手法　→　仕組み化
    →
    DevOps with Agile
    DevOpsの思想
    ・開発チームと運用チーム
    で分かれていた作業を統合　
    →　作業分担によるサイロ
    化を防ぐ
    ・ツールを使った自動化
    （CI／CDの普及）
    　→　システムの信頼性の
    向上、トイルの解消
    2010年〜イマ！！
    

    View Slide

39. テストはどこでも化
    2010年〜イマ！！
    

    View Slide

40. 品質もどこでも化
    2010年〜イマ！！
    

    View Slide

41. 閑話休題
    参照：アジャイルQAに求められるプロセス全体を俯瞰する「ホリ
    スティックテスティング」とは何か？（翻訳 ）
    

    View Slide

42. ソフトウェア開発、進化中
    【全部ひとりだった時代】
    テスト（この頃はデバッグがメイン）
    までもちろん全部ひとり
    【ウォーターフォール時代】
    テスト工程の分業化が進み
    テストのみ行う職種が爆誕
    （テスターさん）
    【DevOps時代】
    分業するよりもONEチームで
    やった方がはやい・うまい・やすい
    アジリティとの戦いが
    始まる
    イマ！！
    

    View Slide

43. 閑話休題
    ソフトウェア開発の難しさ
    フレデリック・
    ブルックス氏
    ２　プログラムは、規模が大きい
    　　1人乗りのボートは簡単に作れても、1000人乗りの船は難しい。
    　　３　プログラムは、簡単に変更できる
    　　　　形のある製品の開発では、後で変更ができない。
    　　　　　　ソフトウェアは変更が容易で物質的コストもかからない。
    １　ソフトウェアは、目に見えない
    　　手で触れない、大きさ、重さもない。よって全体像を簡単に把握できない。
    　　　開発の難しさも実感できない。
    　　４　制約となるものが少なく、自由に作れる
    　　　　重力、磁力、電流などの法則に束縛されないため、
    　　　　　　動くソフトウェア＝正解となる。（芸術の世界）
    

    View Slide

44. 品質特性とBugとの戦い
    

    View Slide

45. 品質特性とは
    「 要求事項に関連する製品、プロセス又はシステムに本来備わっている特性」
    1. “本来備わっている”とは、そのものが存在している限り、もっている特性を意味す
    る。
    2. 製品、プロセス又はシステムに付与された特性（例:製品の価格，製品の所有者）は、
    その製品，プロセス又はシステムの品質特性ではない。
    3. 品質工学では、システムの機能を確保するために必要とされ、仕様で規定される特
    性。
    品質特性とBugとの戦い
    

    View Slide

46. 製品品質 利用時の品質
    製品そのものが持っている品質 人がその製品を利用したときに「受け取る」、
    または「感じる」品質
    品質特性とBugとの戦い
    

    View Slide

47. 品質特性
    品質副特性
    品質特性とBugとの戦い
    

    View Slide

48. 品質特性
    品質副特性
    品質特性とBugとの戦い
    

    View Slide

49. 機能適合性
    functional suitability
    明示された状況下でシステムを使用すると
    き、明示的ニーズ及び暗黙のニーズを満足
    させる機能を製品又はシステムが提供する
    度合い。
    ※機能仕様にではなく，機能が明示的ニー
    ズ及び暗黙のニーズを満足させるかどう
    か。
    保守性
    maintainability
    意図した保守者によって、製品又はシステ
    ムが修正することができる有効性及び効率
    性の度合い。
    品質特性とBugとの戦い
    

    View Slide

50. 品質特性とBugとの戦い
    Bug🐞って何だと思いますか？
    

    View Slide

51. 品質特性とBugとの戦い
    

    View Slide

52. 品質特性とBugとの戦い
    

    View Slide

53. 品質特性とBugとの戦い
    

    View Slide

54. 品質特性とBugとの戦い
    Bugを見つけるには
    どこに着目する？👀
    

    View Slide

55. 品質特性とBugとの戦い
    Bugを見つけるには
    

    View Slide

56. 品質特性とBugとの戦い
    Bugを見つけるには
    静的テスト（レビューや静的解析）、
    動的テストを通して見つける
    

    View Slide

57. 品質特性とBugとの戦い
    Bugを防ぐには
    どこに着目する？👀
    

    View Slide

58. 品質特性とBugとの戦い
    Bugを防ぐには
    

    View Slide

59. 品質特性とBugとの戦い
    ● 欠陥の素になった根本原因を探し対策を打つ
    ● ドメイン知識不足・コードの変更容易性の低下
    ・業務過多による疲労などさまざま
    Bugを防ぐには
    

    View Slide

60. 閑話休題
    DevOpsバグフィルター
    ● 最上段の・はBugの卵
    ● Unit（単体テスト）・Integration（結合テ
    スト）・End to End（E2Eテスト）Alerting
    （アラート）・Monitoring（モニタリング）
    ・Logging（ログ）の層をもつ
    ● 上三段の層について、
    ○ 上段にいくほど網目が細かい＝テスト
    の数は多い
    ○ 下段にいくほど網目が荒い＝テストの
    数は少ない
    ● 下三段の層について、
    ○ その逆
    ● Bugは時間経過と共に育つ
    

    View Slide

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
    　
    　※その他の参考資料についてはスライド内に記載
    

    View Slide

62. Meety や Twitterでぜひお話ししましょう🐥
    

    View Slide