生まれたてのテストエンジニア【後編】
皆さん、こんにちわ、HOLLYです。いかがお過ごしでしょうか。
2020年最後のコラム更新になります(大晦日に更新して読む人がいるのだろうか...)。
今年はコロナ禍ということで、働き方も大きく変革した一年でした。
テレワークは私は数年前、テストチームの管理側で試したことがあるのですが、
その際はテスターの質問対応の大変さや生産性に疑問を持ち『これは流行らないだろう』と思っていたのですが、
その予想は大きく覆ることになりました。
さて、初回のコラムはついつい昔話になってしまいましたが、今回もその続きになります。
今後は時系列に捉われず、広くお話していきたいと思います。
それでは後編、師走のお時間をしばしお付き合いください。
はじめてのチームリーダー
テストエンジニアとして採用された私でしたが
ソフトウェアテストの技術は何一つ知らないまま、1週間後には東京の地に降り立っていました。
世の中はテレビ放送がアナログから地デジに移行しつつあり、バブル崩壊の足音はまだ聞こえず。
東京での住まいは、JR山手線五反田駅徒歩5分の家賃15万円のマンスリーマンション。
朝の出勤時には酔いつぶれて路上で寝ている人に頻繁に出くわす、
そんな夜の街から私のテストエンジニアのキャリアはスタートしたのでした。
初日の職場には、同日から契約が開始となるテストオペレータ要員が数十人。
大型モニターが数台、パソコンの入った未開封の箱が数十箱。
私の役割はテストオペレータ数人をまとめるサブリーダーという位置づけでした。
テストオペレータというのは、テストケースを実行する業務を主な役割としている職種を指します。
IT業界の経験の浅い人が担当することが多いです(歴の長い凄腕テストオペレータも存在します)。
当時は異業種からの転職組も多く、Officeを使ったことがないようなITスキルの低い人もいて、対処に困った記憶があります。
さて、サブリーダーとしての仕事内容は主に以下のようなものでした。
テスト設計：テストケースを作成する
不具合管理：不具合を発見した際に書く不具合報告を精査しエスカレーションする。
また、修正された不具合の確認をメンバーにお願いする
工数管理：メンバーの労働時間を管理する
テスト設計というのは、開発チームが作成した製品の仕様書や取扱説明書をベースに、
テストする内容を書き起こす工程、作業のことです。
このテスト設計には、効率的、効果的に行うための様々な技法があり、日進月歩で新たな手法が生み出されていますが、
当時はテストエンジニア自体の認知度も低く、テスト設計技法をよくわかっていないテストエンジニアも多くいました。
私もその一人で、テスト設計の重要さに気付いてないことで、基本の「き」も知らないまま、テストケースを作成することになります。
はじめてのテスト設計～だがそれなりになんとかなる
テスト設計をしたことがないとは言え、予めテストの方針が決めてあると、それなりには何とかなるものです。
当時のテスト設計は以下のようなものでした。
正常系テスト
- 機能テスト：仕様書に記載された機能の説明に「～であること」を付ける
【仕様書】リモコンの[電源]ボタンを押下すると、テレビの電源がONになる
【テストケース】リモコンの[電源]ボタンを押下すると、テレビの電源がONになること
【仕様書】視聴中、リモコンの[電源]ボタンを押下すると、テレビの電源がOFFになる
【テストケース】視聴中、リモコンの[電源]ボタンを押下すると、テレビの電源がOFFになること - 連続操作：ある動作を連続的に行う
・リモコンの[→]ボタンを連打する
・番組表にて、リモコンの[↓]ボタンを押下したままにする
⇒番組表を下にスクロールし続ける
異常系テスト
正常系動作を阻害する動作を行う。テレビが壊れず、元に戻すことができればOK。
- 電源断
・リモコンの[電源]ボタンを押下し、テレビの電源がONになるまでに電源ケーブルを抜く
・視聴中、リモコンの[電源]ボタンを押下し、テレビの電源がOFFになるまでに電源ケーブルを抜く
これらの良し悪しはともかく、何回も電源を入り切りしたり、連続で操作したりすると不具合も結構起きるもので、
それなりには評価されて味を占めたのか、しばらくはこの手法で乗り切っていました。
もちろん、このテスト設計で全てを乗り切れるはずもなく、ぶ厚い壁にぶち当たることになるのですが、
それはまたいずれの機会にお話ししたいと思います。