たかがテスター、されどテスター
現在のプロジェクトで僕はテスターをやっている。
スケジュールにも優先度B-C以下のタスクが振られるのがこのテスター業務だ。
ただそうはいってもどんなエンジニアだって、 最初はテスターや簡単な改修業務から始まったわけだし学ぶことが多いにあるのは間違いないと思う。
で今回は、何もわからないテスターにプロジェクトメンバーが求めていることに関して考えてみたい。
結論
進捗を楽観的に見積もらない
これはテスターに限らず開発全般に関して言える。
今日までにできると思う、ではなく、今の画面で残り何(テスト)ケースが残ってて、昨日まで1日○○ケース進んだから、逆算して○日で終わる、という客観的な根拠を示す。自分でやったエビデンスの結果とかかった日にちを換算して進捗をすぐに言えるようにする
これをやりさえすればあとどれくらいのスピードでやらないといけないのか、どのくらい残っているのかがわかる。成果物はかならず残しておく
ちゃんとファイル整理して、プロジェクトメンバーに成果物を要求されたときにすぐに出せるようにしておく。想定→結果→補足の順番で備考に書いて実装した方に報告する
うまくエビデンスが取れなかった場合、想定ではこうなるはずだったが結果こうなった、そして補足として自分はこう思う、という流れでプログラマに報告する。全部バグという言葉で片付けない
テスターが想像する以上にプログラマはバグという言葉に神経質な動物である。
自分(テスター)の想像の範疇を超える何か = バグ ではない。
有象無象のものからバグの温床となっている何かを見つけて(現場では「原因の洗い出し」という)提供できるとテスターとしては優秀。
その何かが見当違いで間違っているとテスター失格。
わかる範囲で正しい情報を提供できればテスター及第。
テスターにプログラムの改修まで求めていない
テスターはテスター以上でも以下でもない。
テストケースに従って動作が保証されているか検証するのがテスター業務であって、
バグ改修などはプログラマに任せてしまっていい。
それよりも結論で言ったような「報・連・相」がしっかりできて、
検証結果をプログラマへすぐにフィードバックできるテスターが優秀なテスターだと思う。
事前にできること
現場の求めるテスタースキルにもよるけど、
- SQL
- Linuxコマンド
- ローカル開発環境構築
この辺はあった方がよろし。
開発環境は現場にかなり依存度が高いので事前に現場の環境が聞けるようなら聞いておくと事前準備ができるかも。
あと
- バージョン管理ツール(Subversion, Gitとか)
この辺もあるとなおよし。
まとめ
これができれば一人前やで!