以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P…
以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P…
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
単体テスト 結合テスト システムテスト（機能テスト、負荷テスト、ボリュームテスト、セキュリティテスト、リグレッションテストetc) 受け入れテスト（シナリオテスト） 運用テスト 現場（案件）によっては、「開発エンジニア」 が一連のテストしたり、また 「QAエンジニア」 がテストしたりと異なります。 私の意見としては、 「開発エンジニア」 「QAエンジニア」 双方が確認すべきではないかと。 単体テストの実施は、開発者が担当します。 また、結合テスト（Integration Test）以降のテストはQAエンジニア、もしくはQAテスターが担当する。 単体テストのルールや網羅性は開発とQAが一緒に考えることが品質を良くする上で大事です。 お互いテストの意義というものを見直すこともできます。 また、詳細仕様を把握しているPM、Pdmや開発者。テスト設計やテストの種類を知っているテスト担当者が協力しあ
AWSにおける形式手法の記事（https://lamport.azurewebsites.net/tla/formal-methods-amazon.pdf）を読んだ。特に重要だと思われる示唆を3つあげると以下の通り。 産業界では長年形式手法は多大な工数をかけて比較的容易なコードの断片を検証するというイメージがあったが、これはまったくの誤り。現実の問題に適用可能である アマゾンでは10の現実のシステムに適用して、すべてで効果が得られた。難解なバグの発見したり、正当性を犠牲にすることなく確信を持って最適化を施せた 7つのチームでTLA+を使用。エンジニアは2−3週間で学習することができる 以下は、読んでいる途中で書きだした要点。 AWSでは2011年以降形式仕様とモデル検査を使用している 複雑な分散システムを検証するにあたって、従来の手法 ― 設計レビュー、コードレビュー、静的解析、ストレス
本記事では、書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」のポイントを抽出する。ただ、削った部分も多いので、ぜひ書籍を購入してほしい。 第1部 イントロダクション ソフトウェアを「一度だけ」動かすのは、それほど難しいことではない。正しくするのは難しい。 ソフトウェアを正しくすると、不思議なことが起こる。開発や保守に必要な人材はわずかで済む。変更は簡単で迅速になる。欠陥の数は少なく、ほとんど出てこなくなる。労力は最小に抑えられ、機能性と柔軟性は最大になる。 「あとでクリーンにすればいいよ。先に市場に出さなければ！」ソフトウェア開発者たちはそう言ってごまかす。だが、あとでクリーンにすることはない。短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い。早く進む唯一の方法は、うまく進むことである。 すべてのソフトウェアシステムは、2
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
パフォーマンス分析のメソドロジーとは、システムやアプリケーションのパフォーマンスを分析する際に準拠できる手法です。メソドロジーを手がかりとして作業に着手できますし、根本原因やその他の要因の発見に役立ちます。異なる種類の問題を解決するのには、それぞれに適したメソドロジーがあります。目的を達成するまでに何度か方法を変えて試してみるといいかもしれません。 メソドロジーを使わない分析は手探りの探索になり、ある問題に対する手がかりが見つかるまで（もしあればですが）ずっと場当たり的にメトリクスを分析することになってしまいます。 このサイトでは以下のメソドロジーについて詳しい資料を公開しています。 USE（Utilization Saturation and Errors）メソッド ：リソースのボトルネックを見つける TSA（Thread State Analysis：スレッドステート分析）メソッド ：
今日話さないこと JavaScriptの基礎知識、jQueryの導入 気持ちいいUIやUXがうんちゃら CanvasやWebGLを使ったリッチでイケてるゲームの作り方
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
