おまぬけ活動日誌

● 水沢の駅で、朝ご飯どうしようかなあ、と思いつつきっぷを買おうとしたら、もう発車だから証明書もらってはよ乗って、一ノ関で買ってください、と。ありがとうでも朝ご飯…は一ノ関で食べるかw

● 雪は降っていないけれど、外は霧で真っ白。冬だなあ。寒い地域の電車のドアは自分で開けて閉めるべし。

● 人気の定番ずんだジェラートうまうま。枝豆は手にはいるんだからまいんちゃんに従って自分でつくってみないとなやっぱり。

● やまびこさん電源くれるすごい（翌日のやまびこさんはくれませんでした）

● 音声Skypeの会議が必要になってネットカフェにもぐりこむ。現代人みたいだ！

● 会議後ロフトうろうろ。楽しいねえ。ずんだあんみつもいただきましたよ!

● ソフトウェアテスト勉強会～JaSST'13東京報告会～ #sendaitest にお邪魔しました

下記は報告会に参加した僕の個人的なメモです。 誤りなどは僕によるものです。何でもツッコミよろしくお願いします。

JaSSTはJapan Symposium on Software Testingのことなのだそうです。

• 「エクセルは人生です」
• 「エクセルでやってることは全て自社ツールとしてサーバにコミットしてみんなが見られるようにする」

Challenges in Software Testing

ねもとさんによる、上記プレゼンテーションの報告です。

テスティングについてここ何年かの間に変わったこと

• 尊敬されるようになった/技術が認められるようになった
• テスト関連の本が1冊から数百冊になった
• テスターに専門性が求められるようになった
• 人手でやっていたテストがCIに

変わらないもの

• マネージャーはテストのことを理解していない
• ツールは銀の弾丸だと思われている
• 過去から学ぼうとしない

バグの出ないテストはいいテストなのでしょうか？

• 過去の経験からこれだけの数のバグが出るはずだ、と言うがそれで良いのか？
• テストでいくら多くのバグが発見できたとしてもリリースした後にバグが出てしまうと良くない→Defect Detection Percentage

Defect Detection Percentage

Defects found by this testing/Total defects incudeing those found afterwards

重要なのは正確性よりも一貫性

• システムテスト/結合テスト/受け入れテストのどこまで入れるか
• 小さいプロジェクト(不具合の件数が少ない場合)にはDDPに誤差がおおきい

DDPはリリース直後には100%で、時間がたつにつれて低くなり漸近的にある値に近づく 。

自動化の意味

「回帰テストを自動化して週末もずっと動かしているが、バグが見つからない」テストを止めた方が良いか？止めない方が良いか？ →止めない方が良い。環境が変わったりしてこけたりする。コードの編集前に走らせて動くことを確認しておいた方が良い。

• 自動化した回帰テストはバグを見つけるためのものではない - 自動化がバグを見つけるのではなくテストがバグを見つける
  • 環境でこけたり
  • 自動化は人手を省くためのもの
• ツールがあるからといってテスターがいらなくなるわけではない
• 全て自動化できるわけではない

バグを見つけやすいのは回帰テストではなくて探索的テスト。 探索的テストは自動化しにくい。 いまいちなテストを自動化する前に、いまいちなテストを良いテストにするべき。

ユニットテスト

ユニットテストは品質を保証できるか？

TDD開発者

ユニットテストは品質を保証するものではなく開発者が安心して作業をすすめるためにするもの。漏れがある

品質保証の人

メソッドレベルで品質を保証するもの

テスト設計コンテスト

お題が電気ポット

• 安全性や使い勝手を重視しているチームが多かった
• 自分たちの会社の問題を意識しているチームがあった
• 普通の参加者にはわかりにくいのでは
• 架空の仕様ため本当にバグを抑えられるのかわからなかった

参加者としての感想

いちからテスト設計をするのは大変だった ソースコードがないのでブラックボックステスト(システムテスト)しかできない。コード的にあやしいところを叩くことはできない
• 開発者にわかるあやしい匂いがわからない

Wモデル導入の手引き

うめつさんによるまとめの発表でした。

左が開発、右がQAだと対立構造。 Wモデルでは、上流工程にテスト技術者が参画することによって、 左側の斜面の右にそれぞれ対応する作業項目が導入される。

仕様が決まってないのにテストを書き始められない→失敗

じゃあWモデルの導入の目的は？

• 短納期 (海外)
• 品質向上 (国内)

ポイント - 品質向上のためのWモデル

• プロセス設計をWモデルを考慮しておこなう
  • どのアクティビティ(工程)をいつやるのか買いていく
  • 単純に前だおしするだけではだめ
• 必要なドキュメント設計をする
• 必要な教育をする

テスティングのグローバル最新事情

コグニザントジャパン株式会社(米国) - テストサービス部門 23500人在籍、取引先は銀行金融が主

• 2000-2005 800名 作業ベースのサービス
• 2006-2008 12000名 包括的なサービス
• 2008-2011 20000名 クオリティエンジニアリング
• 2012- 23500名 オンデマンドのテストサービス

テスト作業全体を請負、高品質化 - テストの

• 管理
• 戦略
• 計画設計
• 実行

マネージドテストセンター

• 一部請負
  • 高コスト低品質になりがち
• プロセス標準化
  • 効率化、品質向上
• テストセンター
  • 全部を見て必要なもの不要なものを分ける

ソフトウェアテスト

• 欠陥検出→欠陥防止
• 100%カバレッジ→直行表、スマートテスト手法 MCDC (Modify Condition Decision Coverage)、RBT (要求に基づくテスト)
• オンサイト・オフショア (TaaS)

品質保証のために

• クオリティ エンジニアリング
  • シフトレフト
    • 早期のバグ発見
  • 工程間にクオリティゲートを設けて流出を防止
  • 自社メトリクスを定義し品質保証
• Testing as a Servivce (TaaS)
  • オンデマンド
  • クラウドベース
• エンドツーエンドオートメーション
  • テストライフサイクル全般を通して一体化
  • 業務プロセスに沿って徹底した自動化

探索的テスト入門

ねもとさんによる参加報告です。

テスト技法のポジショニング

探索的テストは技法ではなくスタイル。

アジャイルソフトウェア開発宣言:包括的なドキュメントよりも動くソフトウェアを →包括的なドキュメントよりもテストの実施を

探索的テストのOK/NG基準

人依存 - 信頼できスキルのある人がやっておっけーといえばおっけー。属人化。「アートだからね」

ざっくり

• 機能性
  • 各々の主機能がテストさユーザーが望む操作ができアウトプットが 正しければおっけー
  • 不正なオペレーションのあとに正常に動作すればおっけー
• 安定性
  • ソフトがOSを不安定にしない
  • ハングアップしない、クラッシュしない、データ損失しない
  • …

実際にどうやって？

• 目的を明確に
• 機能を明確に
• 弱いエリアを叩く
  • 致命的なバグを出さない
  • 機能の端から順にテストするのではなくユーザーに近いところから
  • 実際に触ってみて危険なところを察知する
• テストの実施記録をとる
• …

利点

• 投資効果が高い
• 早くバグをみつけられる
• 沢山バグをみつけられる
• アジャイルと親和性が高い

欠点

• 理論的ではない

探索的テストの注意点

• 100%頼ってはいけない
  • 自動化テストやスクリプトテストと組み合わせる
• トレーニングが必要
  • 誰でもできる手順書をつくるわけではない
• 非機能よりも機能へのアプローチが強い
• 見つけた不具合を分析できる必要がある
  • 経験値の蓄積のために

● ビアバッシュも楽しかった

• ニセコのオーストラリア驚き情報
• アパレル業界に探索的テスト？

● 体力が減ってきたところでビアバッシュを早退。楽しかったです。ありがとうございました。また来られるといいなあ。雪がちらつく中をホテルに帰投。