ウノウラボ Unoh Labs: Web Application Testing cheatsheet
こんにちは！ やまもと＠テスト番長です。 先日マサトさんに教えてもらったのですが、 こんなウェブアプリケーション用のチェックシートがあるそうです。 SECGURU: Web Application Testing cheatsheet なかなか面白いので、軽く日本語にしてみました。（Special thanks to: ジュンヤさん） ※間違ってたらごめんなさい。 1. アプリケーション名とバージョン 2. コンポーネント名 3. 通信プロトコル SSLならばバージョンと暗号方式 4. パラメーターのチェックリスト URLリクエスト URLエンコーディング クエリストリング ヘッダー クッキー フォーム フォーム（Hidden） クライアントサイドのヴァリデーションチェック 使用していない余計なパラメータの存在 文字列長の最大/最小値 連結したコマンド（Concatenate
テストの役割=進捗管理＋設計戦略：An Agile Way：オルタナティブ・ブログ
「EoM=EoC+EoT」を鍵概念として、良い設計とは何か、よいプロセスとは何か、を再定義しようとしている。今回は、テストの役割について再考する。 テストは設計とプロセスの両方の基本単位だ。まず、テストと進捗管理の話をしたい（テストとドキュメントの話、テストとコミュニケーションの話、テストと開発リズムの話、などと続く予定）。 みなさんは、進捗指標として何を使っているだろうか？「工程ごとに違うが、成果物の完成に対する到達度だ」という答えが一般的だと思う。しかし、「設計書９０％完成という報告が２週間続いている」というような進捗会議に参加したことはない？ （きっとあるはずだ。） ぼくが考える進捗管理の基本は、 の3点だ。先に述べた「設計書のページ数」という単位は、３つの条件をどれも満たしていない。すべての設計書を否定するつもりはないが、設計書は内部の中間生産物であることが多いし、１００％終了とい
J2EE勉強会での発表資料を公開します - t-wadaの日記
id:takubonさんからいただいたコメントに触発されてちょっと書いてみます。 リリースを行う際に利用者に公開したインターフェイスが「公布済みインターフェイス(published interface)」になります。短い期間のイテレーションを繰り返してチーム間で結合を繰り返していく場合には、利用者は他のチームとなります。イテレーションの期間に応じて不完全な形でインターフェイスを公布する機会があるかもしれませんし、実際に機能を制限してリリースを行ったりもします。 短い期間で反復開発しているということは、インターフェイスを公布する機会が増えるということです。公布する機会が増えれば、リファクタリングの範囲が公布済みインターフェイスに引っかかる確率も増えます。すると、公布済みインターフェイスの変更はリファクタリングの枠を越えて「仕様変更」となってしまうことが多くなってしまいます。 これがイテレーシ
[結] 2005年8月 - 結城浩の日記 - テストが困難な性質
目次 2005年8月31日 - Perl版の「メモ化(memoization), 再帰関数定義関数, 最小不動点」 / スマトラ沖地震・津波 / 2005年8月30日 - Windowsで、手早くPerl6で遊ぶ / 他の人から学べない「何か」 / 2005年8月29日 - ミルズの外科手術チーム / 2005年8月27日 - POPFile / 2005年8月26日 - 今日も仕事 / 2005年8月25日 - 今日も仕事 / 2005年8月24日 - 今日も仕事 / 人月はなぜ神話か / 2005年8月23日 - 説明文を書く2つのフェーズ / 秋は勉強の季節 / 2005年8月22日 - 仕事 / プログラマのダイエット / 2005年8月21日 - ジェネリクス・クイズ(2) / 2005年8月19日 - ジェネリクス・クイズ(1) / テストが困難な性質 / 2005年8月18日
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
