とてか02 に来たのでメモ

とてか02 に来たのでメモ。

とちぎテストの会議とは

2010年に行われた「とちぎテストの会議（連番なし）」（通称とてか）は、
id:yoshioriのデブサミでの講演を発端としたTDD周辺の一連の炎上を受けて開
催されました。とてかはTDDとはなにか？について議論しあう、重い場と強いメッ
セージを提供しました。那須から流行のお祭りに参加する、ハレの日。
2012年、とちぎテストの会議02のコンセプトは「日常、いつもの、ふつう盛り
x2、小盛りx1」です。

ということだそうです。

お題目はすっきりしてますね。

基調講演「テストコンサルの日常」秋山浩一 (富士ゼロックス (株) SS開発本部)
ソフトウエア開発ライブ
テストのレシピ
ワールド・カフェ
クロージング

場所

東那須塩原公民館でした。

東北新幹線で那須塩原へ、さくっと。
結構多数の人が乗り降りしていた感。

駅前に結構何もなくて、、、地元感がありますね。

オープニング

Tweet 禁止などの諸注意。
日常の様子を発表される方がおられるから、という配慮だそうです。
(ということは blog もダメなのでは…)

プロジェクタは 2 台構成でした。準備いいなぁ。

基調講演

@akiyama924 さん。
ソフトウェアテスト技法ドリルの著者の方。

「ソフトウェアテスト技法ドリルを読んでいない人挙手」→じゃあこれあげる、という驚きの導入。

SQiP研究会 (http://juse-sqip.jp) で縁あって咳さんから呼ばれました、と。

「コンサルタントは事実を元に語らなければならない」ということで、ご自身の時間別ツイート数を分析w

なんでもかんでも HAYST 法、という時期の経験から得られた、コンサルティングの NG/OK といった話をされていました。

いろんな分野の会社から呼ばれるし、都度異なる課題があるので面白い。

QA

コンサルティングとして呼ばれる契機？
- 経営課題レベルで切迫したプロジェクトで呼ばれることもあります
- どのフェーズで入ってもあんまり変わらないですね

解決できない問題はどうするものなのか？
- 解決できる人を連れてくる。ハードの人、ソフトの人。

ソフトウエア開発ライブ

咳さん、佐々木さんによる

JaSST のテスティングライブ
- 正直めんどくさい。
TDDBC のデモ
- 見てるだけ

今回は、仕様変更を入れながらプログラム (メイヤーズの三角形判定) を書くので、楽しみましょう。
- 「こういうテストケースがいるんじゃない？」というのをみなさんにお願いします

入力された整数が、三角形かどうかを判定する
- 0 を入れる
- 負数を入れる
- 少数を入れる
- "07" を入れる
入力された整数を計算して、三角形かどうかを判定する
- "\t2" を入れる
- "8 " を入れる
- " 8" を入れる
- "三角形でない"の例 (1,2,3)
- なんかすっごい大きい数
  - Ruby/Smalltalk といった Bignum を実装してるプログラミング言語であれば、普通テストしない (よね ?)
  - だけどそれを格納するストレージは ?
辺の長さを調べて、「二等辺三角形」「正三角形」「三角形」を判定する
- ちょっとかっこいい実装をお見せします
- 「三角形判定アプリを誰がどう使うのか分からないのがもやっとする」
- 2.0 は 2 とみなすのか、とか
- 漢数字ェ
- Integer と同じパースをするものになってるけど、カスタマイズするべきかもね

プログラムを書いてるときにテストも書いてることが多い。
実装が分かってるので、ブラックボックスでやるときは気にするような観点をばっさり捨てたりする。
最初の頃からテスターが一緒にやってるので、前半の段階で外部仕様として制限するとか、そんなことをしています。

QA

TDD だとどうなのよ
- (id:t-wada) すぐに実装するので、ホワイトボックスに近いものになる。咳さんの考えとだいたい同じ

レシピ

発表者皆が咳さんと同じスタイル (中間チェックポイント入れるやつ) でした。
toRuby の特徴 ?

おいしくなかったレシピ (ソフトウェア通信簿)

なかうちさん。

前振り
- toRuby 所属、実行委員長係
- システムの科学
和田卓人のテスト駆動開発講座
- フラクタルな図が好き
- 若干コンフィデンシャル

ソフトウェア通信簿
- コードがどのくらい使えるかを自己評価したもの
- 試作ソフトの出来栄えを数値化
  - 技術リスク、ソフトウェア検査結果、パフォーマンス評価とか

知らないものにはコミットできない
- 自分で書いたコードじゃないと…評価って何？

通信簿パターン
- 「通信簿」も「ソフトウェアを使ってもらう」も同じ形をしていることに気付いた
- 前者は後者を解消するものではなかった

QA
- 今の通信簿の 3 つの項目 (品質レベル) はどんなもの？
  - 開発サイドと同意してるもの
  - どんな当たり前バグがあるとか、どんな機能を諦めてるとか

研究開発だけを目的にするチームを作るのは駄目だ、というような議論をしたなぁ。

ワンプレートテスト

ゆりてぃさん。

TEF 道ワークショップの課題「スーパーマリオの状態遷移」
- みなさんが書いてるもの→難しい
- 会社の研修で書いてもらったもの…→難しい

ワンプレートテスト
- テストの関心ごとを 1 枚の紙に入れる
- 階層ごとの状態遷移図にいろいろ盛り込んでいく
- UML の状態遷移図と同じ?
- 入力から考えていくと困りそう

1 枚に全部書く
- 俯瞰できる、スコープを明らかに
- CFD よりもシンプル

メリット
- 全部でどれくらい、が見える
- 書くときに何をテストするかを意識しやすい

普通にオブジェクトの状態遷移として考えてることだなって思った。

ふつう、というか、ポケモン

ネットワークインフラエンジニアとして、サイトマップ網羅テストが必要になった話。

サイトマップ網羅テスト
- サイトマップのリンクを全て開く
- ちゃんと表示されるかを確認するというテストを作ってみた

おいしくなかった
- インフラ観点で他に見るべきものが
  - メール送受信、ログ、セキュリティ診断、監視、、、

探索的テスト

恋愛系テストエンジニア

持ってない人挙手→買ってください

用語としての探索的テスト
- あるテストを実施し、その結果をベースにして次のどのようなテストを行えばよいか考える
- 非常にレベルの高いテスト

テスト活動と探索的テスト
- W 字モデルっぽいプロセス
- テストは、チームの皆で考える
  - 全体像は徐々に出来上がる

わたしの探索的テスト
- 序盤 (+もや)
  - テストケースはなし
  - チームの心配事などを重点的に
- 中盤 (+もや)
  - 設計したテストケースを使う
  - テストケースに無いこともやる
  - テストケースの設計にフィードバックするサイクル
- 終盤 (+もや)
  - ユーザ観点のテスト
  - 開発中に発生した問題についてもテスト

もやもやが無くならない…
- 受けいれる (スピリチュアル系)
- 認めてもらう (依存系)
- テストケース設計と同じサイクルを回す
  - テストケースがある場合もやもやしない
  - →自分で考えてるからもやもやが残る？
  - 言葉の定義にないけど、一人でやらないといけないと考えていた
- ペア探索的テスト

経験の不足を補う工夫を！