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

Spring Bootcamp(新卒研修) 2022 QA研修 座学

honamin
September 14, 2022

Spring Bootcamp(新卒研修) 2022 QA研修 座学

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

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

ご指摘感謝です…!

honamin

September 14, 2022
Tweet

More Decks by honamin

Other Decks in Technology

Transcript

  1. Spring Bootcamp 2022
    QA研修
    2022/5/13 Fri.

    View full-size slide

  2. QA = Quality Assurance

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  6. 自転車
    (組み立て前)
    試乗
    by 組み立てた人
    QAを知る

    View full-size slide

  7. ソフトウェア
    (リリース前)
    動作検証(テスト)
    by 開発した人?
    QAを知る

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  10. 「一定の価値」とは?
    QAを知る

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  30. UIテストの自動化
    1990~2000年代
    2004年
    Selenium の登場
    ● アプリケーションのUIや、
    JavaScriptのテストを自動化する
    目的で開発された
    ● キャプチャリプレイ機能を搭載
    し、コーディングの知識がなくて
    も自動テストを作成することが可

    自動化が進んだ理由
    開発手法のブラッシュアップに伴い、工程の
    最後に配置されるテストがボトルネックにな
    る事例が多くなってきた。
    人的コスト削減、開発フローのさらなる効率
    化を求めて自動テストの導入が進んだ。
    開発終わってる
    のにテスト長く
    ね?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  34. Money Forwardをさがせ!
    2010年〜イマ!!

    View full-size slide

  35. 開発手法 → 仕組み化

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

    View full-size slide

  36. テストはどこでも化
    2010年〜イマ!!

    View full-size slide

  37. 品質もどこでも化
    2010年〜イマ!!

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  58. 参考資料:
    ◆システム及びソフトウェア製品の品質要求及び評価(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 full-size slide

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

    View full-size slide