ソフトウェアテストの原則ワークショップ

event

社内セミナーに参加。ソフトウェアテストに関するコンサル会社より講師を招いて30人ほどで受講。内容は受講資料読めばいいだけの話なので、気になったことと、質問したこと、これからやろうと思うことを列挙

■気になったこと

  • インド/ＵＳではテスト専門チームがいるのは知ってたけど、要求開発の段階からテストチームが参画することもあるらしい。その場合高いスキルが必要なので限られた人しか入れないようだが　⇒　これはいい。日本では相当難しそうだが、役割名を変えればいけるな
  • ソフトウェアの開発は一連の変換作業（要件⇒仕様⇒設計⇒コーディング）で変換作業の過程で損失が発生
  • システムの誤りは、顧客の要求、技術者の理解、設計、実装にギャップがあることから生じる。ギャップを埋めるのが「テスト」　⇒　この説明の仕方は分かりやすい。伝言ゲームによる損失ね
  • 効果的なテストをするには、顧客にとって重要度が高いものから行うのがよい　⇒　こんなんAgileなら普通なのに。改めて言うことなのか。こういうことって
  • 品質とは「ユーザーの要求を満たすこと」で仕様を満たすことではない。また全ての「〜性」の集積。（機能性/使用性/拡張性/信頼性etc)　⇒　その通りだけど見失いがち
  • 循環的複雑度は20〜30が適切、50だと分割対象、100だとメンテ不可能が大体の目安
  • 結合テストは、モジュール間のI/Fをテストするもの　⇒　Stub/Driverが必要。細かくやれば後が楽だが、時間がかかるからトレードオフだろう。
  • テストチームには「想像力」が必要。テストチームの教育に想像力を伸ばすカリキュラムがあるもよう。小説の一部を抜き出して前後を書かせるとかいうのもあるらしい。
  • テストツールは、効果ではなく「効率」を向上　⇒　これも当たり前だけど、忘れがち。出来ている気になってしまう

■質問したこと

  • テスト計画はIEEE829を参考に項目が列挙されていた。IEEEはよく失敗すると聞いたが？　⇒　計画を見直さないからだとの回答。ある程度、インクリメンタルにして振り返りを行い計画を補正していかないから失敗するだけであって、IEEEは良い手段の一つだといっていた。本にも同じようなこと書いてあったけど、国は関係なく同じなのね。ただ日本には明確な基準がなくIEEEを参考程度に使っているところが多いとのこと
  • 今のプロジェクトではスモークテストに時間がかかっているが、どうしたらよいか　⇒　リグレッションと混合している可能性がある
  • テストコードは何で保証しているか？　⇒　レビュー。やっぱりそれしかないのか。うちはペアプロ基本、たまにレビューでいいや。
  • 受け入れテストのツール化はどうしているか？　⇒　顧客にも提案している
  • GUIテストの自動化はどうか？　⇒　あまり薦めていない。変更が最も入りやすいところなので、チェックシートなどで統一を図り手動が多い


■やろうと思ったこと

  • 今のプロジェクトのカバレッジでは、SC/BC/MCC/PCのどれを使っての計測か調べる ⇒ 調査結果はこちら
  • AllTestを流す時に、Explicitを自動的に外して、なんらかテストできる単位でやれる方法を検討
  • メモリリーク検出ツール。使ったことないから一度試す⇒C#用はないもよう。そもそもリークしないから。その代わりどのモジュールが最大どれくらい使っているかなどを計測

■雑感

  • スモークテストの定義をすること。ビルドの受け入れでこれがこう動いたらOKというのを、今職人の勘でやっている（GUI部分の修正の場合）、修正した人、もしくはテスターが定義しておけばいい気がする。自動化いけないかなー。UIは難しいんだよな。
  • GUIテストの自動化って、最初から想定と結果作って、スクリプト仕込んでってやるから難しいと思う。一緒にデータも見るし、結果も見るし。だから全部OKで結合テストが通った状態で記録だけしておくだけで、スモークテストに使ったり、受け入れに使えると思うんだけど、それだけの目的に使うには導入コストが高すぎるのかな。うーん
  • テスト専門チームって絶対良いと思う。日本にその文化がないのはどうしてか。これは考えたけど分からなかった