バグ根絶部隊の編成方法
テストというのは、その確認する個所のプログラミングを行った
人間が自分でやるべきか？
そう聞かれたら僕だったら
「やったほうがいいし、やらないほうがいいでしょう」と答えます。
一体どっちやねんっていう答えですが。
プロジェクトによって呼び名が違うと思いますが
テストには大きく分けると二種類あります。
単体テスト：モジュール(各機能)内の処理に閉じたテスト
結合テスト：システムとしての機能確認を行うテスト
前者は主にプログラムレベルの確認になるため、
実際にプログラミングを行った人間がやるべきでしょう。
自分のプログラムは自分が一番知っているはずだからです。
というか知っていなくてはダメです。
またプログラミングレベルまで落とされた成果物は粒度が細かすぎて、
他の人間にそのテストを引き継いでしまうと
「ここはどういう処理になってるの？」というコミュニケーションが
発生しやすくなります。
喋っている暇があったらプログラムを動かしましょう。
っていう話です。
むしろ、プログラミングを行った人間とは別の人間がやるべきなのは
結合テストの方です。
結合テストでは要求仕様どおりにシステムが動いているか、
という観点で主に行うので、専門のテスターにやらせるほうがいいと思います。
その専門のテスターにはサディスティックな人間を選抜すべき、
ってのが僕の持論ですが。。。
もし要求仕様とのアンマッチが生じた機能があった場合、そこを作った人間は
既に「そこはそういうもんなんだ！」という偏見に凝り固まっているため、
わざわざ自分で作った機能にケチをつけたりしないのが常です。
また無意識的に問題をもみ消してしまう場合もあります。
人間っていうのはそういうものです。
このようにバグを根絶する部隊をどうやって編成するかという、人の体制面も
考慮することも品質の向上に結びついていくのではないかと思います。
バグも人が作り出すものですからね。
バグシリーズの第2回はここまでです。
次回はあるかどうか分かりませんが、もし書くとしたら
バグを見つけたらどうするか？ということをテーマとしたいと思います。
バグはテストで見つけよう
バグというのはテスト期間中はバグでしかありませんが、
そのまま見つけられずに納品後まで過ぎると爆弾へと変化します。
そこでバグの見つけ方についてちょっと考えてみました。
最近バグネタばっかりでまたかよっって感じですが、
ちょっとここで突き詰めて考えてみたいので、３回ぐらいかけて
バグの見つけ方について書いてみたいとおもいます。
第１回「バグはテストで見つけよう」
■ バグを予防するという考え方
バグを見つける最も有効な方法とは何か？
それはバグを探しても見つからないようにすること、
すなわちバグを予防すればいいのです。
･･･と口で言うのは簡単です。
そういう有効な方法があればいいのですが、残念ながら自分はまだ発見していません。
バグは予防するものというより、むしろ出るものと考えたほうが良いように思います。
バグというのはプログラミング上、システム上の不具合ですが
突き詰めて考えると本質は「開発者の手ミスや認識誤り」であることが分かります。
システムを開発するのが人間である以上、ミスは避けられません。
そしてバグを作り出すのも人間ですから。
■ 卓上の理論よりも実践すべし
今まで何個ものバグを見てきましたが、
だいたいゴミ領域を参照したとか初期化漏れだとかいったコーディングレベルでのバグと
モジュール間のインターフェース認識誤りがほとんどです。
バグの予防法として注目を浴びているものの一つに「レビュー」があります。
残念ながらコーディングレベルでのバグはレビューで見つけるのは困難です。
プログラムレベルまで落とされたものは粒度が細かすぎて
レビュアーが指摘をしにくいからです。
それに内部処理が正常に動くかということにとらわれがちで、
他モジュールが提供するインターフェースの詳細まではあまり目が行かないものです。
要求仕様検討や機能設計段階のレビューは大いにやるべきだと思いますが、
内部処理の設計に入りコーディングを行ったら、
レビューよりも実際に作ったプログラムを動かしてテストすることに時間を割くべきです。
プログラムというのは実際に動かすまでは、どんな動きをするか分からないのですから。
最近は上流工程ばかり脚光を浴びて
テストというのはこの業界ではあまり注目されていませんが、
ITが更に人間社会のあらゆる場面に浸透していくと予想される21世紀では、
システムは創造的であると同時に堅牢であることが求められるでしょう。
システムの異常動作は人間の生活に多大な影響を及ぼすでしょうからね。
そういうわけでやっぱりバグをはテストで徹底的に洗い出すものという
当たり前の結論に至りました。
では、バグの見つけ方第2回ではそのテストのやりかたを
主に人の体制の面から考えていこうと思います。
1ヵ月後の自分
今週はとてもつらかった。
例のバグ
が原因で、僕が所属するグループが作った全ソースを見直し、
その合間に数百項目の試験を消化しました.。
土日は休むものなんていう常識は、
うちのプロジェクトではすでに非常識になっています。
金曜の夜なのに、「じゃあ、また明日ね。」なんて平然と
言われてしまうくらいですから。
しかし、来週からはもっとつらい。
数千項目の試験というエベレストを越えなければなりませんから。
仕事で多忙なんて言葉を使ってもまだ程度を表現しきれないくらいに
ド忙しい日々を送ると人はどう変わるか？
変化には二種類あるそうです。
心が浄化される人と心が荒廃する人。
1ヵ月後、自分はどちらの人間になっているのでしょうか。。。
バグの修正がバグを生む
かつて出したバグがあります。
修正パッチを当てて「解決済み」という風に顧客に説明したのですが、
なんと今になって解決したどころかそのパッチを当てたせいで
更に別のバグが発生していたことが判明しました。
しかも。。。それ、自分がコーディングした部分です。。。
かなりヤバイです。
コーディングした後にテスターに引き継いで、
そのテスターも見逃してしまったのですが、元は自分が書いた部分です。
それ相応の責任をとることになるでしょうね。汗
バグの修正後確認を行うと、「バグが治っているかどうか」ということだけに
心が奪われがちですが、バグを修正することによって生じうる
二次的問題にも同程度に目を向けなければダメですね。
既存部分の調査と調査結果のレビュー、そして確認テストは徹底的に行うこと。
バグが発生した関数、それに関連ある関数のルートは全て通すくらいの
再テストは絶対にやるべき。
今回は時間がとれずレビューがまともにできなかったことと、
調査範囲が狭すぎたことが原因で、二次的なバグを呼んでしまいました。
バグ修正の二次的影響というはバグ発生個所の前後だけでなく、
意外なところで出たりします。
身をもってバグの恐ろしさというものを体験してる２３歳でした。
しばらく休みがなさそうです。。。
実装させてくれ
システム統合テストっていう最終フェーズです。
今日、その統合テストの副責任者にならないか？
というオファーをマネージャーから受けました。
･･･そんなにうちのプロジェクトは人手不足なのかよ。。
っていうのが正直な感想です。
うちのプロジェクトは自社社員が１，２割程度であとは皆派遣の方なので
若造にも管理系の仕事が回ってきます。
とはいっても１年目でシステム統合テストの管理はやりすぎかな。。。と。
ここ２ヶ月くらい開発グループから外れてテストに掛かりっきりだったので
全く「エンジニアリング」してません。
しかも、統合テストに関わるともうすぐ始まる次期開発に
最初から関われないし。
このまま行くとマネージャーの投げた網に引っ掛かって、
管理系の補佐業務が主体になっていきそうな気が。。。
プロジェクトマネージャーを目指すとblogで書いてはいるものの
やはりエンジニアである限り実装願望は抑えられません。
管理もやりながら技術も極める。。。 そんな道はないものでしょうか。。
枯れた技術者にならないかという不安
開発で使っている技術はいわゆる一昔前のものです。
支援ツールを除いて、システムそのものの開発言語は全てC言語ですし、
フレームワークやオープンソースといったものは一切使っていません。
設計技法も未だにフローチャートが主流だし、IBMのOS/360が
開発された頃から使われているスナップショットやメモリのダンプ
なんていう手法にもかなり頼っていたりします。
（C言語には例外処理なんてものはないですから。。）
これは古き良き技術は枯れても消え去りはしないということの
証明にはなりますが、時代の流れに明らかに逆行しています。
こんな状況ではそのうち時代に取り残された技術者にならないだろうか、とか。。
最近ちょっと不安が絶えません。
ただ時代とか流行のせいにするんでなくて、最後は自分次第なのかなぁと。
かつてCOBOLプログラマーだった人も、デカイプログラム組んでた
経験を生かして大規模システムの構築に今でも関わっている
ことが結構あるそうですし。
結局はどんな技術を使っているかってよりは、
業務経験から何を学んでいるか、ってことが大事な気がします。
と思って、自分をなぐさめてみました。
試験工程について考える４ － テスターがナチスの親衛隊になるとき
■ 試験工程とホロコースト
皆さんは、「夜と霧」 という本を読まれたことがありますか？
ナチス・ドイツ時代の強制収容所について書かれた本です。
強制収容所に入れられた囚人達は、名前も地位も家族も、
自身の個性も全て失い、番号で呼ばれるようになります。
やがて囚人の数が雪だるま式に増えるにしたがって、
看守の囚人達に対する扱いは劣悪になっていきます。
そして最終的には「虐殺の対象」としてしか見られなくなっていくのです。
莫大な数の項目を担当したテスターと試験項目の関係もそれと同じです。
テスターにとって項目一つ一つに特性なんてないのです。
項目は全て「消化すべき項目の群れ」として扱われます。
当然こんな状況ではログの確認漏れやミスも起こります。
なぜこんなことになってしまうかって？
試験項目には数が莫大であるだけでなく、
全てに「消化期限」が設けられているからです。
項目数が莫大であるために、いつまでにこれだけ消化しますよ
という計画をあらかじめ顧客に見せなければいけないわけです。
このような状況になると、
「期限までにいっぱい項目を消化することが良いことだ！」と
勘違いするテスターが必ず出てきます。
似ていませんか？ この構図。
「バグを検出する」という本分を忘れたテスターと
「囚人を社会復帰させる」という本分を忘れた看守。
「意味の無い試験項目を挙げる」
「罪の無い人々を強制収容所に入れる」
という観点からも似ていますね。
■ テスターは管理者の鏡？
テスターが「ホロコースト」を行うようになるのは、
むしろ管理者に原因があるのかもしれません。
僕も最近プロジェクトの中の一グループの試験管理担当になりましたが、
偉そうにこんな記事を書いている自分でさえ「進捗の鬼」に
なってしまう時がしばしばあります。
「このテストの進捗はどうなってるんですか？？？」
とか
「いつまでに絶対終わらせてね！ 休日出勤も覚悟で。」とか。
言った数分後に「あー、オレってなんかイヤな奴。。。」って思ったり。
管理的な立場にある人は、やたらと進捗を管理したがります。
管理者は自分が受け持つところの進捗を把握する義務が
あるので仕方ないのですが、進捗が「目的化」したとき悲劇が
起こりうることも忘れてはなりません。
とくに試験工程では。
試験は「スピードより品質」です。
この二つのワードが逆転してしまわないためにも、
まずは項目を挙げる時点でふるいを掛けるシステム作りを
やるべきでしょう。
試験工程いついて考える３ － 下手な弾も数うちゃ当たる？
何回か前の記事で書きましたが、通信系のソフトウェアというのは
公共性が非常に高いためとにかく試験をたくさんやります。
だいたい開発期間の70％から75％が試験工程に費やされます。
項目数もそれだけ多い。
項目をやればやるほど「これだけやれば品質も大丈夫でしょう？」
的なことを顧客に言えるわけです。
でも実態はというと、まあ、やっといても損はないだろうという
レベルで挙げられた試験項目がかなりあったりします。
下手な弾も数うちゃ当たるっていう。
このような状況になると、項目数をたくさんやればやるほど
逆に品質の低下に結びつくのではないだろうかと
懐疑せずにはいられません。
こういうことを言うと
「試験に無駄な項目なんてない！ とにかくやるんだ！！」
などと顔を真っ赤にして頭に角を生やす方がいるのですが、
闇雲な試験項目の挙げ方が品質の低下をもたらしている証拠があります。
■ 弾は当たっていなかった
試験工程は
単体テスト → 結合テスト → システム統合テスト →顧客立会いテスト
というフェーズに分かれます。
最後のテストは名前通り顧客の立会いのもと行われますので、
このフェーズではバグは出しては「いけない」ことになっています。
（単体と結合と統合でバグは全て見つかるはずでず。）
でもバグは「出ます」。毎回。
顧客立会いテストでバグが出ると下手な弾も数うちゃ当たる派の人々は、
項目のあげ忘れのせいにしがちですが、実際はそうでありません。
原因の大半は、これまで消化したはずの試験のログ確認漏れ、
つまり「これまでの試験で何やってたんじゃ！」っていう話です。
では、これまでの試験で実際何が起こっていたのでしょうか？
「試験工程について考える４」に続く＞
コミュニケーションしないことの大切さ
休日出勤ってのは意外と仕事がはかどります。
なぜか？
人が少ないからです。平日の労働時間よりも。
平日のオフィスの喧騒と言えば全くたまったものではありません。
笑い声や怒鳴り声、集中力を削ぐような会話が聞こえてきたり。
話しかけられることの半分は、どーでもいいヨタ話だったり、
自分で調べれば分かるだろう？ という内容だったりします。
これほど「チームワーク」だとか「コミュニケーション」の
重要性がこの業界で説かれるご時世です。
そういう話にも応答を返さないと
「コミュニケーション能力がない奴」という
レッテルを貼られかねません。
そして何より真横や斜め前から絶えず人の顔が
視線に入ってくる環境で、
周りの存在を気にしないで仕事に打ち込める時間が
どれほどあるというのでしょうか。
ソフトウェア開発プロジェクトではメンバー同士の
認識の相違が後々重大な結果をもたらすことになる場合があるので、
コミュニケーションは確かに大切です。
しかし、それは主にミーティングやレビューでのことであって
恒常的にそれを求めることはやめるべきです。
そしてプロジェクトやチームを一つにまとめる
コミュニケーターの役割を担う人は必要ですが、
全員がそうである必要はありません。
むしろ、そういう人は少数の方がいい。
SEという仕事は他のどんな職業よりも
「集中力」が求められます。
もう少し「コミュニケーションしないことの大切さ」が
説かれてもいいのではないでしょうか。
私はイコールの意味を知っている
「私は=(イコール)の意味を知っている」
研修中に講師から教えてもらった言葉です。
かつてその講師の知り合いが中途採用の面接で
いきなり何の脈拍もなく面接官にこう聞かれたそうです。
「イコールの意味を教えてください。」
そのとき彼は戸惑うことなく即座にこう答えたそうです。
「私はイコールの意味を知っています。
代入を意味する。
左辺に右辺の値を代入する。
左辺と右辺の型は等しくなくてはいけない。」
と。
その一言で彼は面接を受けた企業に合格しました。
とても基本的なことなのですが、突発的にもその答えが出てくるのは
土台のしっかりしたベテラン・エンジニアである証拠でしょう。
「私はイコールの意味を知っている。」
正々堂々と自信を持ってこんなことが言えるエンジニアになりたいものです。