[B! design][test] Makotsのブックマーク

テストコードを書き始める前に考えるべきテストの話（2021年版） #scrumosaka / scrum_fest_osaka_2021

以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。【発表資料中のURL】 P…

Makots 2021/06/28

リンク

質とスピード / Quality and Speed

質とスピード初演: 2019/10/31 @ EOF2019

Makots 2019/11/01

良い。会社の全員で音読したい。

リンク

現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ

この文章の背景についてこの文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0）で再公開いたしました。旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。目次この文章の背景について目次出

Makots 2019/09/30

リンク

テスト仕様書 - Qiita

単体テスト結合テストシステムテスト（機能テスト、負荷テスト、ボリュームテスト、セキュリティテスト、リグレッションテストetc) 受け入れテスト（シナリオテスト）運用テスト現場（案件）によっては、「開発エンジニア」が一連のテストしたり、また「QAエンジニア」がテストしたりと異なります。私の意見としては、「開発エンジニア」「QAエンジニア」双方が確認すべきではないかと。単体テストの実施は、開発者が担当します。また、結合テスト（Integration Test）以降のテストはQAエンジニア、もしくはQAテスターが担当する。単体テストのルールや網羅性は開発とQAが一緒に考えることが品質を良くする上で大事です。お互いテストの意義というものを見直すこともできます。また、詳細仕様を把握しているPM、Pdmや開発者。テスト設計やテストの種類を知っているテスト担当者が協力しあ

Makots 2019/07/22

リンク

AWSにおける形式手法 - masateruk’s blog

AWSにおける形式手法の記事（https://lamport.azurewebsites.net/tla/formal-methods-amazon.pdf）を読んだ。特に重要だと思われる示唆を3つあげると以下の通り。産業界では長年形式手法は多大な工数をかけて比較的容易なコードの断片を検証するというイメージがあったが、これはまったくの誤り。現実の問題に適用可能であるアマゾンでは10の現実のシステムに適用して、すべてで効果が得られた。難解なバグの発見したり、正当性を犠牲にすることなく確信を持って最適化を施せた 7つのチームでTLA+を使用。エンジニアは2−3週間で学習することができる以下は、読んでいる途中で書きだした要点。 AWSでは2011年以降形式仕様とモデル検査を使用している複雑な分散システムを検証するにあたって、従来の手法 ― 設計レビュー、コードレビュー、静的解析、ストレス

Makots 2018/10/24

リンク

書籍「Clean Architecture」が最高すぎたのでエッセンスをまとめてみた

本記事では、書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」のポイントを抽出する。ただ、削った部分も多いので、ぜひ書籍を購入してほしい。第1部　イントロダクションソフトウェアを「一度だけ」動かすのは、それほど難しいことではない。正しくするのは難しい。ソフトウェアを正しくすると、不思議なことが起こる。開発や保守に必要な人材はわずかで済む。変更は簡単で迅速になる。欠陥の数は少なく、ほとんど出てこなくなる。労力は最小に抑えられ、機能性と柔軟性は最大になる。「あとでクリーンにすればいいよ。先に市場に出さなければ！」ソフトウェア開発者たちはそう言ってごまかす。だが、あとでクリーンにすることはない。短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い。早く進む唯一の方法は、うまく進むことである。すべてのソフトウェアシステムは、2

Makots 2018/08/13

リンク

QAアーキテクチャの設計による�説明責任の高いテスト・品質保証

1. © NISHI, Yasuharu QAアーキテクチャの設計による説明責任の高いテスト・品質保証 Vector Testing User Day 2016/10/24（月）電気通信大学大学院情報理工学研究科情報学専攻経営・社会情報学プログラム西康晴（Yasuharu.Nishi@uec.ac.jp） 2. © NISHI, Yasuharu2 Profile Assistant professor: the University of Electro-Communications, Tokyo, Japan General chair: IEEE International Conference on Software Testing 2017 Tokyo (ICST 2017 Tokyo) 2017/3にGoogleからテスト自動化の基調講演/NASA&ESA&JAX

Makots 2016/10/24

リンク

パフォーマンス分析の方法論23選 | POSTD

パフォーマンス分析のメソドロジーとは、システムやアプリケーションのパフォーマンスを分析する際に準拠できる手法です。メソドロジーを手がかりとして作業に着手できますし、根本原因やその他の要因の発見に役立ちます。異なる種類の問題を解決するのには、それぞれに適したメソドロジーがあります。目的を達成するまでに何度か方法を変えて試してみるといいかもしれません。メソドロジーを使わない分析は手探りの探索になり、ある問題に対する手がかりが見つかるまで（もしあればですが）ずっと場当たり的にメトリクスを分析することになってしまいます。このサイトでは以下のメソドロジーについて詳しい資料を公開しています。 USE（Utilization Saturation and Errors）メソッド：リソースのボトルネックを見つける TSA（Thread State Analysis：スレッドステート分析）メソッド：