いろいろ書いてますが、筆者は開発現場で働いたことがないので知識として知っていることです。
間違い・不足点がありましたらお知らせください。
上流工程
要件定義など上流工程で役立つ記事がITproで多く公開されています。
要件定義フェーズ
UMLを使う
UMLはソフトウェアの動作（仕様）をビジュアル化するための記述方法のルールの体系です。
UMLの作成には次のサイトが参考になります。
- UML超入門 第2章：UMLの種類とそれぞれの書き方を解説しています
UMLを書くためのツール
UMLを書くには有料ソフトではMicrosoft Visual Studioがおすすめです。
数々のシンボルが揃っており、UMLだけでなくネットワーク図なども書けるのでなおさらです。
無料ソフトではastah* communityなどがあります。
UML小ネタ
シーケンス図・フローチャート図はJavascriptを利用して書くことができます（驚）
- js-sequence-diagrams: http://bramp.github.io/js-sequence-diagrams/
- flowchart.js: http://adrai.github.io/flowchart.js/
Stackeditのベータ版ではmarkdownの編集画面から同様にして作成できるので試してみては？
テストフェーズ
テストケース作成のアプローチ
テストの種類として、ホワイトボックステストとブラックボックステストがあります。
ホワイトボックステストはテスト実施者が対象コードを把握しているという前提で実施するものです。具体的には条件分岐を網羅するような入力を複数与えたり、メモリ確保の妥当性を検証するような入力を与えたりします。ホワイトボックステストは単体テストなど対象のコードが小さいときに有効な方法です。
ブラックボックステストはテスト実施者が対象コードを把握していない前提で実施するものです。コードを把握しない代わりに仕様書を参照しながらテストケースを設計します。具体的には、同値分割した上で境界値に着目して入力を与えたり（境界値テスト）、ユーザーの使用状況を想定してテストケースをつくったり（ユースケーステスト）します。以下の文書ではもっと具体的に、多くの項目について扱っています。
（※上の説明はこの文書を参考にしています）
ソフトウェア品質分析
通常では信頼度成長曲線と呼ばれるグラフを作成します。これはテスト項目の消化数（消化とは当該テストが仕様に従って実行されたことを意味する）とバグの検出数を並べて書くものです。予想値と実際の値の動きを比較してバグの残存状況について分析することができます。基本的にテストが順調に消化でき、バグの検出数が横ばいになったときバグを除去できたと推定できます。しかし、テストの質やバグの検出数の増加曲線によっては一概にそうとはいえない場合があり要注意です。
信頼度成長曲線の分析では次のサイトが参考になります。