可用性や安全性を高めつつ、ソフトウェアをシンプルにすることは不可能だ。カオスエンジニアリングから継続的検証へ（中編）。JaSST'23 Tokyo基調講演
可用性や安全性を高めつつ、ソフトウェアをシンプルにすることは不可能だ。カオスエンジニアリングから継続的検証へ（中編）。JaSST'23 Tokyo基調講演 Netflixが始めた「カオスエンジニアリング」は、現在では大規模なシステムにおける可用性向上の手法のひとつとして確立し、広く知られるようになりました。 そのカオスエンジニアリングという手法を定義したのが、元Netflixカオスエンジニアリングチームのエンジニアリングマネージャーを務めていたCasey Rosenthal（ケイシー ローゼンタール）氏です。 そのローゼンタール氏が、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2023 東京」（JaSST'23 Tokyo）の基調講演に登壇し、「Chaos Engineering to Continuous Verification」（カオスエンジニアリ
忙しい研究者のためのテストコードとドキュメントの書き方 - Qiita
はじめに 「研究用のプログラムにもテストコードやドキュメント書いたほうがいいよね。」 「分かっちゃいるけど、そんな面倒なことやってられないよ。」 という研究者あるあるを解決すべく、僕が普段実践している開発スタイルを紹介します。 この開発スタイルのすごいところは： テストやドキュメントを一切書かない場合と比べて 追加の工数がほぼゼロ。 普通にコーディングしているだけで、いつのまにかテストコードとドキュメントまでできあがっている。 実装、コメント、テスト、ドキュメントが自然に同期するので、保守しやすい。 Pythonを例に紹介しますが、コメント内にテストを書けるツールと、コメントからドキュメントを生成できるツールをもつ言語ならばどれにでも応用できるはずです。 この開発スタイルに至った背景 ソフトウェア開発において、テストコードやドキュメントを整備することでプログラムの品質が向上することは広く知
アーケードゲームを支えるデバッグ術 - SEGA TECH Blog
ブログ読者のみなさん、はじめまして。 株式会社セガのベテランプログラマー阿部です。 このエントリーではデバッグ手法のあれこれについての体験談と、デバッグをテーマに一昨年に実施されたプログラマー向け新人研修の概要をお伝えしたいと思います。 EXE ファイルのデバッグ イーサネット絡みのデバッグ 周辺機器絡みのデバッグ デバッグスキルブートキャンプ 黒子に徹する、裏方系エンジニア EXE ファイルのデバッグ 同僚が作った EXE ファイルが手元にあり、あなたはこれを Windows で起動しようとしています。 起動してみたところ何も反応がなく、しかもそれは想定外のことでした。 「何コレ、動かないんだけど」とあなたが同僚に文句を伝えると、同僚はあなたに返します。 「こっちでは動いてるよ」 困りましたね。 あなたの手元には EXE のソースコードも無ければ、Visual Studio もありません
メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita
ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも
やはり俺の「質 v.s. スピード」はまちがっている。 #eof2019 - 名前考えるの苦手
2019/10/31(金)に開催されたEngineering Organization Festival 2019 で @t_wada さんの「質とスピード」という講演を聞き、とても感銘を受けたのでメモ。 品質とスピードはトレード・オフの関係にある。どちらを優先するか？要バランスだ。 そう思っていた時期が私にもありました。 けど、そんなことはなかった！ ■追記 個人的な捉え方としては、 プロダクトを漸進的に成長させ、仮説検証ループするスピード上げようとすると、犠牲にした保守性があとで(意外とはやく1ヶ月後には)足枷になる。 保守性(テスト容易性、理解容易性、変更容易性)が低いとリードタイムが延びてスピードがどんどん落ちていくループをまわせなくなる。ってことかな、と思う。 スピードを上げようとしたのに、意外とはやくスピードが上がらなくなるジレンマ。 @t_wadaさんのスライド 素敵なグラレ
test.comやaaa.comをテストデータに使うのはやめましょうという話 – 打つか投げるか
2018/02/13追記：「サンプル用のドメインを使おう」の説明に “.example” と “.test” の使い分けについて追記しました。 Web システム開発時のテストデータを作成する時、また各種ドキュメントを書いている時など、サンプルの URL を使う場面は多いと思いますが、その時に適当なドメイン名を使うのはやめましょう、という話です。 知っている方には当たり前レベルの話ですが、意外と IT 企業のシステム開発現場等でも普通に見かけることがまだまだありますので・・・。 よく見かける例 例えば、こんなドメインの URL で開発中システムのテストデータを作っていたり、仕様書に説明が書かれていたりする場面をよく見かけませんか？ test.comaaa.comabc.comsample.comdummy.comhoge.com でも、これらのドメインって存在していて、また実際に利用されてい
【まとめ】Windowsを無料で利用する方法 - 俺より凄いやつしかいない。
はじめに Microsoftが検証用に配布しているWindowsOSをまとめました。 Windows クライアントOS Windows評価版かmodern.IEを使う方法があります。 Windows評価版 提供方法がISOに限られる。 90日間利用可能。 90日を過ぎると背景が黒色になり１時間ごとにPCがシャットダウンします。 提供されているOS Windows 10 Enterprise Windows 8.1 Enterprise Windows 8 Enterprise 提供種類 ISO - Enterprise ISO - LTSB ※LTSB（Long Term Service Branch）：機能更新を行わず、セキュリティ更新プログラム・修正プログラムのみを提供するモデル modern.IE OSやIEのバージョンごとのウェブサイトの表示検証が目的で配布されています。 90日間
TDDと相性の良いC、C++のユニットテスティングフレームワークとは - 千里霧中
これまでTDDで使えるC、C++向けのユニットテスティングフレームワークをいくつか紹介してきました。その一連の紹介の総括として、今回は、C、C++でのTDDを対象とした場合、どのようなテスティングフレームワークが望ましいのかについてまとめたいと思います。 TDD向けのテスティングフレームワークに求められる条件 TDD向けのテスティングフレームワークに求められる条件については、以前Advent Calender向けの「TDDのはじめかた #TddAdventJp - 千里霧中」の冒頭で触れさせて頂いています。少し加筆して下記に転載します。 軽快にテストを実行できる。TDDにとって、実行に1秒以上かかるテストはもう遅すぎます。そのような実害ある遅さの直接的原因になるフレームワークは避けた方が無難です。 簡潔なテストコードでテストを実装・実行できる。Assertion MethodやTest M
組み込み開発へのテスト駆動開発の導入 その２ - 千里霧中
組み込み開発へのテスト駆動開発の導入 - 千里霧中の続きです。 実機を伴うテストの問題点 では次に実機を伴うテスト環境についてですが、こちらはターゲットに似た実機環境を用意する方法と、テスト専用の機器上で動かす方法があると思います。 まず後者については、有力な候補ではないと思います。テスト用デバイスというのはパッケージソフトウェア以上に高額な価格設定がされているのが一般的な上、ターゲットと大分違う条件でテストをせざるを得ないためです。おそらくこのような環境を活用できるのは、よほど恵まれた環境か、特定製品に専業化した環境ぐらいに限られると思います。 一方前者に関しては、組み込み開発では最も一般的に行われている手段ではないかと思われます。例えば試作段階のターゲットの基盤を最低限のプロセッサが動作できるように一時的に改造して、Tera Termといった端末でファームウェアと通信したり、メモリダン
【Vue.js】いつから「フロントエンド開発でTDDができない」と錯覚していた？ - Qiita
Vue.jsのコンポーネント開発をTDDでやってみる ※ TDD (test-driven development): テスト駆動開発 ※ テスト駆動開発は文化です。チームの「状況」「納期」「スキルレベル」、その他いろんな要因が絡んできた結果、そのチームが導入するかどうか決めたらいいと思います。 ※ 例えがいいかはわかりませんが、私は「早起き」と「テスト」は同じようなものだと思っています。「早起き」は健康にいいよねって誰でも言うと思うけど、実際に万人がやっているかどうかは別じゃないですか。それと同じで「テストすること」も絶対いいことだと私は思っていますが、やるかどうかはチームの置かれている状況によって決まります。この記事は、その「テストを導入するかどうか」という意思決定の一助にでもなれればいいなと思います。 はじめに こんにちは。ぼくです。 今回はVue.jsでTODOアプリを作ってみよう
ゲームでよく見落とされるテストケースとその再現手法 - Qiita
システムの開発をしていれば、開発したものをテストすると思います。 単体テストや結合テストなど、テスト手法はいくつか存在しますが、想定していなかったケースに対してテストを行うことは難しいです。また最後はシステムテスト(実際に動かして、触ってみるテスト)を行うことになると思います。 (テスト手法などについてはこちらを参照) テストを行うには相応の時間がかかり、テストに時間をかけられない場合もあります。また、開発者以外の人がテストを行うことも多くあります。 そして、いくらテストを行っても、バグを全て発見、修正することはできませんし、実際にゲームを公開し、運用していくことで見つかるバグも多くあります。(ユーザーは基本的に開発時には想定していなかったことも行なってきますので...) 実際の開発段階では見落とだったしがちな割と特殊なテストケースを(実際に自分がデバッグするときの備忘録として残すために)
後回しにするほど除去できなくなる「仕様バグ」
バグを見つけ出すのはテスト工程を担当するエンジニアの仕事だ――。こうした考え方で、バグの発見と対応をテスト工程まで後回しにしている現場は少なくない。こんな現場にいるテストエンジニアと開発者は大変な目に遭う。テストとバグ修正を何度も繰り返し、リリース日に間に合わせるために残業続きになったりする。慌ただしさのあまりバグを見逃してしまい、本番リリース後に障害が発生したりもする。 これは仕様書のレビューを十分に行わず、バグの除去をテスト工程だけでやろうとしているからだ。バグはテスト工程で生み出されるのではなく、テストを開始する前の工程で埋め込まれる。この段階では火種のようなものだ。火種は後工程へ進む中で、やがて火が付いて大きな炎となる。そうなると、バグの修正には大きな工数がかかる。 要件定義工程における修正コストを1とした場合、設計工程での除去コストは5、テスト工程以降においては20～200にもな
テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発
これから C# 開発を始める方、あるいはチームの開発品質をあげたい リーダー・マネージャ向けに、C# の勉強方法を解説した、約２時間の研修用の資料です。Read less
アジャイルだか何だか知らないけれど、ドキュメントがないのでシステムは未完成ね
アジャイルだか何だか知らないけれど、ドキュメントがないのでシステムは未完成ね：「訴えてやる！」の前に読む IT訴訟 徹底解説（39）（3/3 ページ） ドキュメントは誰のため 「この開発がたまたま裁判になったから、裁判所がシステムを完成したと判断するためにドキュメントが必要だっただけではないのか。通常のシステム開発で、裁判を意識することはまずないし、ユーザーと話し合い、検討し、テストを行っていくのだから、要件定義書や基本設計書、テスト結果報告書など不要なのではないか。一体、誰のためにドキュメントを残すのか」――そんな読者の声が聞こえてきそうだ。 確かに開発を成功裡に終了させること「だけ」を考えれば、必要なドキュメントは、話し合いの備忘録と、保守運用に必要なマニュアル程度かもしれない。開発中に要件の齟齬（そご）などが見つかったら、かつて残したメモを見ながらまた話し合えば済むかもしれない。 し
インドの3つ星シェフの腕を見抜く2つの質問
CMMレベル5の認定を受けたインドのソフトウェア開発会社にきちんとしたモノを作ってもらうための2つの質問と4つの具体策を伝授しよう インドが大量に供給する高レベルのハイテク技術者を、日本の組み込み系ソフトウェア開発現場で活用する……。両者の思いや利害はきれいに一致しているのですが、うまく融合できている例はほとんどありません。こうなる原因や、悲劇が発生するメカニズムについては、前々回「『懐石料理』でインドの『スパイス』をうまく使う方法」、前回「幻の白いカラスを追い求め、僕らはインドにたどり着く」で説明したとおりです。 今回は、老舗の懐石料亭が、3つ星インド・レストランの花形シェフを招いて成功するにはどうすればよいかを具体的に検討していきたいと思います。 インドのソフトウェア開発会社が日本でセールスを展開する場合、殺し文句として使うのが「ウチは、CMMのレベル5の認定を受けています」でしょう（
Unity — Throw The Switch
CUnity is written in 100% pure C code. It follows ANSI standards while supporting most embedded compiler quirks. Portable Unity is equally happy running tests for an 8-bit microcontroller as it is a 64-bit processor on steroids. Expressive Unity is designed to help you make the most of your test suite. It features a rich set of assertions so you can find the perfect match for your needs HOW UNITY
Google Mock：はじめの一歩
CodeZineでgtest（Google Test）を紹介したのは4年も前のこと。ひさしぶりにgtestのGitHubを覗いてみたらgtest 1.8.0がリリースされていました。この版の以前との大きな違いは"Mockのサポート"のようです。C++でMockを提供してくれるUnit Test Frameworkはそんなに多くはなかったと記憶しています。 Google製Mockの使い心地を試してみることにしました。 『Google製のC++ Unit Test Framework「Google Test」を使ってみる』（CodeZine） google/googletest（GitHub） Mockとは Unit Testは通常低いレイヤの関数／クラスから行われます。関数f()をテストするとき、f()がg()を呼んでいるなら、まずg()をテストして正しく動いてくれることを確認してからでない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Firefox/Geckoの開発環境 —20年続いているOSSプロジェクトの現在—
CUnitによるテスト駆動開発
