![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2024-03-30T12:22:57+09:00","default:irrp","irrp") #author("2024-04-09T11:22:13+09:00","default:irrp","irrp") →脆弱性関連 →CI/CD →テストツール #contents *サブトピック [#bc370706] -テスト一般 -インシデント管理ツール -テストツール -NUnitまとめ -テスト関連ドキュメント作成 *技術的負債／リファクタリング [#i0a57b4f] -[[大規模なアジャイル開発の現場と技術負債 / Technical Debt - Speaker Deck>https://speakerdeck.com/yoshiitaka/technical-debt]] 2024.3 -[[リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog>https://tech-blog.monotaro.com/entry/2023/11/28/090000]] 2023.11 -[[ソフトウェアの内部品質に生じる様々な問題は組織設計にその原因があることも多い / Internal Quality Issues Caused by Organizational Design - Speaker Deck>https://speakerdeck.com/mtx2s/internal-quality-issues-caused-by-organizational-design]] 2023.11 -[[負債と言わないことが負債と向き合うこと - Speaker Deck>https://speakerdeck.com/kenchan/fu-zhai-toyan-wanaikotogafu-zhai-toxiang-kihe-ukoto]] 2023.11 -[[糞コードは直すな。 - Qiita>https://qiita.com/kotauchisunsun/items/d03c1e6936ffb250e4a1]] 2023.5 --[[【Qiita】糞コードは直すな！ぶっ壊せ！ - Qiita>https://qiita.com/mogamoga1337/items/0add694958159b310e27]] 2023.9 -[[ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す - Google スライド>https://docs.google.com/presentation/d/1hDY2pb-nYVSLr0HrtQ4EVyrDU4QGgwp4-VRG-Rf26DA/edit#slide=id.p]] 2023.5 -[[技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - Speaker Deck>https://speakerdeck.com/mtx2s/technical-debt-and-developer-experience]] 2022.12 -[[業務委託テックリードと技術的負債 - LIVESENSE ENGINEER BLOG>https://made.livesense.co.jp/entry/2022/09/16/083000]] 2022.9 -[[「技術的負債」への処方箋と「２つのDX」 - Qiita>https://qiita.com/hirokidaichi/items/64b444a89410190d965f]] 2021.11 -[[技術的負債を減らす>http://alpha.mixi.co.jp/2012/11546/]] 2012.12.6 *テスト手法 [#w93a9680] -[[「コンパイル時のユニットテスト」導入するとユニットテストを 書かなくてよくなるのか？ - Speaker Deck>https://speakerdeck.com/tomohisa/konpairushi-noyunitutotesuto-dao-ru-surutoyunitutotesutowo-shu-kanakuteyokunarunoka]] 2024.3 -[[privateメソッドのテストって書かない方がいいんだっけ？ - Speaker Deck>https://speakerdeck.com/asumikam/private-methods-test]] 2024.3 -[[プロパティベーステストをやってみよう #TypeScript - Qiita>https://qiita.com/kiwa-y/items/354744ef7393d07a8928]] 2023.12 -[[Storybookを書くだけでリグレッションテストが 実行される世界へようこそ - Speaker Deck>https://speakerdeck.com/kubotak/storybookwoshu-kudakederiguretusiyontesutoga-shi-xing-sarerushi-jie-heyoukoso]] 2023.10 -[[雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try>https://blog.jnito.com/entry/2023/02/16/171810]] 2023.2 -[[【入門】フロントエンドのテスト手法まとめ - Qiita>https://qiita.com/SMAC/items/7cf6b24bed318dab5715]] 2022.7 --Static Test --Unit Test --Integration Test --End to End Test -[[現場で使うためのオールペア法、直交法の基本>http://www.atmarkit.co.jp/ait/articles/1506/11/news013.html]] 2015.6.11 -[[結合テストと総合テスト>http://www.thinkit.co.jp/free/project/4/7/1.html]] --ソフトウェアの開発におけるテスト作業は、「テスト計画」「テスト設計」「テスト実施」「テスト管理」という4つのプロセスで構成されます -[[ファズ・テスト>http://www-06.ibm.com/jp/developerworks/java/library/j-fuzztest.shtml]] --入力データの一部をランダムに書き換え、どのようなエラーが起きるかチェックする技法 ** E2E(End to End)テスト [#j90a9fd8] →スクレイピング →テストツール -[[テストを自動化するのをやめ、自動テストを作ろう - Speaker Deck>https://speakerdeck.com/tsuemura/tesutowozi-dong-hua-surufalsewoyame-zi-dong-tesutowozuo-rou]] 2023.11 -[[PlaywrightのVSCode拡張を使って効率的にテストを書く>https://zenn.dev/cybozu_frontend/articles/6c2a54196f056d]] 2023.10 -[[E2Eテスト自動化ツールの最新トレンド──Playwright？ ノーコード？ Seleniumから多極化の時代へ！ (1/3)|CodeZine（コードジン）>https://codezine.jp/article/detail/18289]] 2023.9 -[[E2Eテスト自動化変遷 〜ノーコードからCypress、そしてPlaywrightへ〜 - estie inside blog>https://www.estie.jp/blog/entry/2023/09/19/133816]] 2023.9 -[[【E2Eテスト】ページオブジェクトモデルを使ったらメンテ地獄から解放された話 - RAKUS Developers Blog | ラクス エンジニアブログ>https://tech-blog.rakus.co.jp/entry/20230523/e2etest]] 2023.5 -[[ChatGPT（GPT-4）にE2E自動テストを書かせてみた - Qiita>https://qiita.com/YoshikiIto/items/abc12c96248fc0d4afb6]] 2023.3 -[[E2Eテスト(インテグレーションテスト)の利点と不利点 - Qiita>https://qiita.com/NAKKA-K/items/58d6b8476a3717179bda]] 2022.5 -[[E2EテストにAutifyを使っている理由、そしてE2Eテストで大事にしていること - Kaizen Platform 開発者ブログ>https://developer.kaizenplatform.com/entry/ban/2021-04-25/]] 2022.4 **カオスエンジニアリング [#s38d0a01] -[[WindowsにGremlinをインストールして攻撃を実行してみる | DevelopersIO>https://dev.classmethod.jp/articles/how-to-install-and-run-gremlin-on-windows/]] 2021.11 -[[Gremlinのシナリオを使ってTLS/SSL証明書の有効期限をテストしてみる。 | DevelopersIO>https://dev.classmethod.jp/articles/test-tls-certificate-expiration-by-gremlin/]] 2021.11 -[[Chaos Engineering on Frontend ~フロントエンドにカオス性を注入して信頼性を向上させよう~ - Qiita>https://qiita.com/G-awa/items/9dc13c2db99cc85705bf]] 2021.11 -[[カオスエンジニアリングと聞いてカオスになった人必見 - Qiita>https://qiita.com/naokiiiii/items/de20997a70922c01f754]] 2018 --カオスエンジニアリングとは、全世界に動画配信サービスを提供するNetflixが導入したことで注目されるようになった手法で、「本番稼働中のサービスにあえて擬似的な障害を起こすことで、実際の障害にもちゃんと耐えられるようにしよう」という取り組みです。 *カバレッジ [#e8d18d14] -[[カバレッジの種類〜C0・C1・C2・MCC〜 - NRIネットコムBlog>https://tech.nri-net.com/entry/coverage_c0_c1_c2_mcc]] 2023.11 -[["テストカバレッジ強制ギプス" 導入 - Qiita>https://qiita.com/nrnrk/items/41d6d900c9688b9b4de2]] 2021.12 -[[テストカバレッジ100%を追求しても品質は高くならない理由と推奨されるカバレッジの目標値について>https://qiita.com/bremen/items/d02eb38e790b93f44728]] 2018.3 --『カバレッジが高ければ、品質が高い』は誤った論理であり、正しくは 『「カバレッジが高い」かつ「テストケースの品質が高い」ならば、「コードの品質が高い」』 である。 --いくらカバレッジが高くても、 テストケースの品質が悪ければ、バグが潜在している可能性を低くすることはできない。 --カバレッジを100%に近づければ近づけるほど、バグ検出の費用対効果は低下する。 --クリティカルなコードではない限り、カバレッジ（C0 / C1）の目標値は 85%程度 に設定すべきである。 -[[NTTデータとの決闘シリーズ第二幕 - ひがやすを技術ブログ>https://higayasuo.hatenablog.com/entry/20080828/1219901392]] 2008 --カバレッジは、参考程度に見るのはいいけど、数値目標を立てて管理に使い始めると弊害が増える。 --問題なのは、バグ密度ですよ。いまどき、「これくらいの行数なら、これくらいのバグが含まれているはずだから、その数に足らない場合はテストが足りない」なんて管理はないでしょう。「バグの数が少なかったら、無理やりバグを仕込んで数を増やす」なんて意味のない行動を引き起こすことになる。 --ユーザの立場からすると、仕様書どおりに動いていることが品質が高いということではない。多少のバグがあっても、実際に使うエンドユーザが機能に魅力があると感じて、ビジネスとして成功することが、品質の高さにつながる。 *品質管理一般 [#n0b8e3d8] -[[「紙」に印刷すると間違いに気づく理由 | リコー経済社会研究所 | リコーグループ 企業・IR | リコー>https://blogs.ricoh.co.jp/RISB/new_virus/post_604.html]] 2024.3 -[[一部で見られる品質保証部門の老害化。そして老害化した品質保証は品質を悪化させる - 千里霧中>https://goyoki.hatenablog.com/entry/2024/01/10/225015]] 2024.1 -[[ソフトウェアの内部品質に生じる様々な問題は組織設計にその原因があることも多い / Internal Quality Issues Caused by Organizational Design - Speaker Deck>https://speakerdeck.com/mtx2s/internal-quality-issues-caused-by-organizational-design]] 2023.11 -[[ポストモーテムの基礎知識と最新事例 / Fundamentals of Postmortem - Speaker Deck>https://speakerdeck.com/isaoshimizu/fundamentals-of-postmortem]] 2023.10 -[[品質保証者の憂鬱「そこのあなた、無闇にメトリクスを増やしていませんか？」 | 豆蔵デベロッパーサイト>https://developer.mamezou-tech.com/blogs/2023/08/03/melancholy-of-qaer-07/]] 2023.8 -[[ダブルチェックの有効性を再考する>https://kouseikyoku.mhlw.go.jp/shikoku/kenko_fukushi/000085434.pdf]] 2018 -[[つよつよエンジニアの成果物にある5つの特徴 - Qiita>https://qiita.com/lazy-kz/items/727299cae893ab3442a0]] 2023.8 -[[「QAって何をする人？」〜上流工程におけるQAの役割とその重要性〜 - エムスリーテックブログ>https://www.m3tech.blog/entry/2023/07/19/170000]] 2023.7 -[[きれいなコードを書けという話について - Software Transactional Memo>https://kumagi.hatenablog.com/entry/write-beautiful-code]] 2023.7 -[[アメリカの職場ではなぜドキュメントも無いのに人が去っても問題ないのだろう？｜牛尾 剛>https://note.com/simplearchitect/n/n3b83d966ed19]] 2023.5 -[[コード品質はやはりビジネスに影響を与える - mtx2s’s blog>https://mtx2s.hatenablog.com/entry/2023/04/26/230917]] 2023.4 -[[ポストモーテムはじめました - Speaker Deck>https://speakerdeck.com/nwiizo/posutomotemuhazimemasita]] 2023.2 -[[試験工程管理の概論 – サイゼントの技術ブログ>https://cyzennt.co.jp/blog/2022/12/19/%e8%a9%a6%e9%a8%93%e5%b7%a5%e7%a8%8b%e7%ae%a1%e7%90%86%e3%81%ae%e6%a6%82%e8%ab%96/]] 2022.12 -[[質とスピード（AWS Dev Day 2023 Tokyo 特別編、質疑応答用資料付き） / Quality and Speed AWS Dev Day 2023 Tokyo Edition - Speaker Deck>https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition]] 2023.6 -[[質とスピード（2022春版、質疑応答用資料付き） / Quality and Speed 2022 Spring Edition - Speaker Deck>https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition]] 2022.9 --品質と開発スピードはトレードオフではない、という話 -[[変更管理、その正体と対策：意外と知らない構成管理の正体（3） - ITmedia エンタープライズ>https://www.itmedia.co.jp/im/articles/0411/19/news108.html]] 2004 -[[エンジニアなら知っておきたい障害報告&再発防止策の考え方>https://qiita.com/hirokidaichi/items/f9f4549c88aaf8b38bda]] 2018 --障害報告は始末書や反省文ではない --「起きた現象」の内容ではなくて、「原因やバグが発生しているモジュール名」などを書いてしまいがち --3段階くらいに再発防止策を検討 ---直接原因 ： その不具合が発生した直接的原因 ---間接原因 ： その不具合に至るまでの間接的な原因 ---本当の理由： なぜ、このようなパターンの障害が発生したか -[[ソフトウェア品質最前線>http://techon.nikkeibp.co.jp/embedded/2006mook/]] -[[品質表展開（QFD）とは>http://www.i-juse.co.jp/statistics/product/func/process/qfd.html]] -[[<論文>情報システム開発における品質管理の一考察 : テスト工程におけるソフト品質向上手法の改善>http://ci.nii.ac.jp/naid/110000040949]] -[[表面の現象で対策を打ってはいけない>http://itpro.nikkeibp.co.jp/article/COLUMN/20080702/310037/]] 2008.7.25 -[[ソフトウェア品質最前線:http://techon.nikkeibp.co.jp/embedded/2006mook/]] *コードレビュー／リーダブルコード [#l9ef11db] →コーディング規約については言語・開発環境へ →コード解析についてはソース解析／オープンソースへ -[[O'Reilly Japan - ルールズ・オブ・プログラミング>https://www.oreilly.co.jp//books/9784814400416/]] 2024.4 -[[良いソフトウェアとコードレビュー / Good software and code review - Speaker Deck>https://speakerdeck.com/atty303/liang-isohutoueatokodorebiyu]] 2024.1 -[[コードレビューの思想や心構え #コードレビュー - Qiita>https://qiita.com/nash_efp/items/b01f341ebc2e991a32ac]] 2023.12 -[[特に個人開発者向け！CodeRabbit(自動レビューツール)を使えばコードの健康まで得られることに気づいた話>https://zenn.dev/binnmti/articles/7e3690ebe80951]] 2023.11 -[[もう初回コードレビューはAIに任せる時代になった - CodeRabbit ->https://zenn.dev/minedia/articles/7928ef7545b393]] 2023.11 -[[コードレビューについて - ROBOT PAYMENT TECH-BLOG>https://tech.robotpayment.co.jp/entry/2023/11/09/070000]] 2023.11 -[[保守性の高いソフトウェア開発のTips集>https://zenn.dev/riku/books/36d9873ee1c0e6]] 2021 -[[もう初回コードレビューはAIに任せる時代になった - CodeRabbit ->https://zenn.dev/minedia/articles/7928ef7545b393]] 2023.10 -[[長くなりがちだったコードレビューを改善した話 - 弁護士ドットコム株式会社 Creators’ blog>https://creators.bengo4.com/entry/2023/09/08/083000]] 2023.9 -[[リーダブルコードを読んで重要だと感じたルールを抜粋 - Qiita>https://qiita.com/app_js/items/2176cfad20d4d86a2398]] 2023.8 -[[チーム開発の生産性が向上する良いコードの書き方：強いエンジニアになるための思考法 - Qiita>https://qiita.com/elipmoc101/items/0a1ad96820520babc86a]] 2023.8 -[[「読みやすいコードのガイドライン―持続可能なソフトウェア開発のために」を読んだ！ - mochikoAsTechのdig日記>https://mochikoastech.hatenablog.com/entry/2022/11/27/212739]] 2022.11 -[[コードレビューについて>http://blog.livedoor.jp/lalha/archives/50495777.html]] 2014 -[[コードレビュー 開発者ガイド | eng-practices>https://shuuji3.xyz/eng-practices/review/]] 2019 --Google's Engineering Practices Documentation Japanese Translation --[[コードレビューの方法 | eng-practices>https://shuuji3.xyz/eng-practices/review/reviewer/]] レビュアー向けドキュメント --[[CL の作者がコードレビューを乗り切るためのガイド | eng-practices>https://shuuji3.xyz/eng-practices/review/developer/]] レビュイー向けドキュメント -[[コードレビューしませんか？メリット・デメリットを解説 - Qiita>https://qiita.com/ushi_osushi/items/91498bd4cad88d7cd1c0]] 2022.3 -[[コードレビューで嫌われる人の特徴7選 - Qiita>https://qiita.com/emjo1804/items/48f6e78237a04684ab38]] 2022.3 -[[レビューで大量の指摘をして大きな手戻りを発生させた原因はレビューアの私にあった>https://qiita.com/kojimadev/items/e12784e6764f1b60e73c]] 2021.4 -[[コードレビューについて>http://d.hatena.ne.jp/camlspotter/20120814/1344919762]] 2012.8.14 -[[ソフトウェアレビューが成功する進行役の6条件>http://www.atmarkit.co.jp/im/carc/serial/review/04/01.html]] 2010.4.14 --レビューアがエラー発見に集中できているか --レビューアがエラー発見の手掛かりを得られているか --遠慮して発言していないレビューアがいないか --適切なエラー指摘がなされているか --進行のペース（時間配分）は適切か --作成者は指摘を受け入れているか * 静的解析/コードメトリック/コードメトリクス [#g87b8132] -[[従来とアジャイルで、品質メトリクスには本質的な違いがあるのではないか - ソフトウェアの品質を学びまくる2.0>https://www.kzsuzuki.com/entry/2023/05/02/183727]] 2023.5 -[[McCabe を使って Python コードの複雑度をチェックしよう！ - サーバーワークスエンジニアブログ>https://blog.serverworks.co.jp/python-mccabe]] 2022.9 -[[コードメトリクスを計測・可視化する - ペパボテックブログ>https://tech.pepabo.com/2022/04/25/code-metrics-dashboard/]] 2022.4 -[[コード メトリック - サイクロマティック複雑度 - Visual Studio (Windows) | Microsoft Docs>https://docs.microsoft.com/ja-jp/visualstudio/code-quality/code-metrics-cyclomatic-complexity?view=vs-2019]] 2019 --循環複雑度 -[[【AWS Black Belt Online Seminar】Amazon CodeGuru - YouTube>https://www.youtube.com/watch?v=OF-NfrcgR-o]] 2021 -[[Amazon CodeGuruを用いて悪しきコードを撲滅したい - Qiita>https://qiita.com/yym_06/items/b32df05136b9c8bd9be8]] 2021.10
