InfoQ ホームページ テスト に関するすべてのコンテンツ
-
MicrosoftのHTML5準拠テストの結果にGoogle、Mozilla、Operaが異議を表明[追記あり]
Microsoftは8つのカテゴリに分類される192項目のテストの結果を発表した。これらはHTML5、SVG 1.1、CSS3、そして DOM Level 2&3についてのテストで、テスト結果を見るとIE9のプレビュー版はすべてのテストに合格している。一方で、Chrome、Firefox、Opera、そしてSafariのテスト結果はカテゴリごとに濃淡がある。この結果だけ見るとIE9が最も正確にW3C標準に準拠したブラウザということになるが、GoogleとMozillaとOperaはこの結果に異議を表明している。
-
アジャイルテストで挑戦
Gerald Ford 国際空港に、駐車料金計算機があり、 Matt Heusser氏は、それにひどいバグがあるのに気がついた。そこで彼は、世界中のテスターに、挑戦状を送った：ParcCalcに存在するバグを見つけて欲しい。それに答えたのは、James Bach氏、Selena Delesie氏など多数いた。
-
MacRuby 0.6が GCD、スレッドの改善、高速なデバッガ、AOTをサポート。
MacRuby 0.6が今、入手可能になり、デバッグ機能と非常に改善されたGrand Central Dispatch (GCD)をサポートした。たくさんのコア機能がオーバーホールされた。その中には、新しい Stringの実装やOnigurumaに替わる新しいスレッドセーフな正規表現ライブラリがある。今や、MacRubyはCocoa 開発環境で安定したものになった、と考えられる。
-
繰り返しタスクはアジャイルの臭い？
ストーリーを水平方向のタスクに分割することは「アジャイルの臭い」か？これはスクラム/アジャイル計画会議によく見られ、チームの顧客価値へのフォーカスを損なう悪習なのか？代わりに提案されているのはどんなことなのか？
-
InfoQ.comのデータベース更新: ほとんど成功、少し失敗
この程、InfoQ.comはこのサイトを始めてから使用していたバックエンドのデータベースを刷新した。しかし、すべて計画通りに事が運んだわけではなかった。ほとんどの移行作業は滞りなく進んだが、いくつかの予期していなかった問題(現在は解決済み)に直面した。この記事では、私たちがどんな計画をして、何が成功し何がうまくいかなかったのか、そして直面した問題をどのように検知し解消したのかを詳しく論じたい。
-
Jim Shore氏、自動受け入れテストは正しい手段ではないと語る
一般的に認められたアジャイルの文献のほとんどが、ユーザのニーズをとらえる最善の方法は、受け入れテストにエンコードされたサンプル、すなわち「自動受け入れテスト」であると教えている。だが、思想的リーダーであるJim Shore氏はそうではないだろうと言う。その一方で、彼に異を唱える人たちもいる。
-
Visual Studio 2010のカスタムコード分析
マイクロソフトのコード分析ツールであるFxCopは、数年にわたって、カスタムコード分析ルールの作成をすることができると提案し続けているが経験は芳しくない。 VS2010バージョンでは、いくつかの改善とよりよい統合シナリオを提案しているが、いくつかの根本的な問題が残っている。
-
一時的なコードと継続的に使うコード、そしてその間にあるすべてのコード
よくテストされリファクタリングされた長く使われるコードがある一方で、数日で捨てられることを前提にして書かれるコードもある。そしてこの両極の間に巨大なグレーゾーンが横たわっている。このグレーゾーンに属するコードはいつか削除されるという想定の元に書かれているが、決して消されることがない。
-
Spring.NET 1.3: VS.NET ソリューションテンプレート MSTest サポート，そして Spring Integration.NET
Spring.NET フレームワーク の新バージョンである version 1.3 が先頃リリースされた。InfoQ ではプロジェクトの創設者でリーダでもある Mark Pollack 氏に，同プロジェクトの詳細と今回導入された新機能，そして新プロジェクト Spｒing Integration.NET の詳細などを聞いた。
-
.NET Reflectorが商用に
Reflectorは多くの.NET開発者にとって必須であろう。サードパーティ製ライブラリのデバッグや言語間の翻訳、単純に自分で作ったコンパイル済みコードを見てみるといった用途で、Reflectorは不可欠なツールとなった。さらに、これまでは、Reflectorもそのアドインもフリーソフトとして使うことができた。
-
リーン＋リアルオプション＝複雑さとリスクの低減
リアルオプションとは、金融オプション数学に基づく意思決定プロセスである。これは通称「白本」とよばれるExtreme Progamming Explainedにおいて、Kent Beck氏が1999年に言及しているものだ。近年ではアジャイル主義者たちがリアルオプションがアジャイルとどのように交わるのかについて調査してきた。現在はChris Matts氏とOlav Maasson氏が、特にリーンソフトウェアコミュニティに対して発言している。リアルオプションを採用することでリーン開発が改善するというのだ。
-
安定化スプリント - 必要悪か、それとも純粋な無駄か？
安定化スプリント（"Stabilization Sprint"）とは、製品をリリースする前、通常の開発サイクルの最後に付け加えられる付加的なスプリントである。名前が示している通り、このスプリントは通常プロダクトを最後にもう一度叩き、最後のバグを出すためのものである。これはアジャイルに属するものなのか？それとも「完了」すれば充分なのか？
-
あなたがやっているのはテスティングかチェッキングか？
ソフトウェアテスティングとは、ステークホルダにテスト中の製品やサービスの品質に関する情報を提供するために実施する、経験的調査のことだ。しかし、この定義では、テスティングとチェッキングの微妙な違いを生む「知恵」については語られていない。Michael Bolton氏は、これら2つの違いと、その違いがある理由について語った。
-
メンテナンス可能な自動受け入れテスト
自動テストはすぐに辻褄が合わなくなってしまい、メンテナンスするのが大変だ。従って企業もテストを自動化したがらない、とDale Emery氏は言う。氏は、最近公開したペーパーにテスト自動化に関わる共通の問題を回避するための実践的な方法を記している。これは、典型的な自動化コードから始めて、より強力でメンテナンスしやすいコードに育てていく方法だ。
-
進捗の思わしくない Code Contracts
Code Contracts の製品開発利用への展開が進んでいない。当初からあった数多くの技術的目標は今も有効だが，目前にある問題や障害のために，現在の形式での実現は遠からず断念せざるを得なくなる。