先週2015年開催のソフトウエアシンポジウムに行ってきました。
今年は、別ポストやめっててうちのブログ大臣に言われたので、まとめて報告します。
基調講演：H1:How To Get What You Want From Testing
今年は、20年以上に渡りソフトウェアに関するテスト、開発、マネジメント、および執筆活動を行なってきた世界的なテストエンジニアでコンサルタント、そしてトレーナーのMichael Boltonさんがいらっしゃって以下のようなことを講演ではなされていました。
・テストが退屈していると感じているなら、、、
重要な作業ではないことをしている、
テストがつまらないと感じるのは、きっとやり方が間違っている
・テストというのは、知るべきことと、
・テスターの精神状態が、クライアントと同じかどうか。
・テストを増やすことがリグレッションの解決にはならない
・製品出荷は、バグの数ではなく、ストーリーで決める
プロダクトオーナー「この製品は、どんな課題を解決するのか、
・人々がソフトウェアに対して感情（イライラしたり、怒ったり）
・
・大事なことは数字だけでは分からず、
・ソフトウェアテストは、「Check」と「
・多くの問題解決は経験と試行錯誤（heuristic）
チェックすることとテストすることは別である
チェックとは
こうなるべきというのを確認、評価すること
これはheuristicではない。
コンピュータは人間がほしいものがわからないし、学習もしない
チェックがすべて合格ならOKか？
テストとは
社会的目的や暗黙値といった困難な事を評価しないといけない
heuristicによって行われる、創造的な作業
・テストの目的はほかの人に対してリスクを知ってもらうこと
製品の状態はどうなのか
どうやってテストをしたのか
テストしてないのはどこか？
これらのリリース判断の材料として提供する
・開発とテスターは近くにいてお互いに学ぶ必要がある
しかし、遠くから見たほうが見える問題もある。
C2：テストコードクリニック
Selenium Degign Patterns and Best Practicesが2015年8月に翻訳発売されるようです。
この本の中で紹介されている様々な手法の概要の説明と実際にデザ
スライドが公開されていますのでパターンについての説明は省きますが、
自動化とテスト要件の管理をどうするかが課題とおっしゃっていた
テスト要件をTestLinkでひもづけたりはしたことがあるそ
エクセルとかで管理すると、
Cucumberも少量で簡単なケースならいいですが
B2:解決！テストアーキテクチャ設計
実際に使用されたテストケースや設計を改善していくというところから、テスト設計に必要なものは何か？というセッションでした。
まじめに設計するとドキュメントも多くてレビューも難しいので、何かツールを使わないと収集つかなくなる。（ゆもつよメソッドはエクセルでうまく集計していました）
テストの設計が難しいのは、テストの対象をうまくモデル化させたり関連付けるのが難しい。ゆえにテスト目的がわからなくなったりレビューが難しくなったりする。
いいフレームワークや、いいツールを求めるより先に現在のプロセスのどこに問題があるかを正しく見極め、そこから手をつける。
スプレッドシート管理の場合、分析はできていてもその表現がうまくいっていないというのはありそうで、結果間違ったものが出来上がりそうな気がしました。
F4：アジャイル開発成功の鍵となるQA・
1グループ5人でアジャイル開発について話し合うセッションでした。
アジャイル開発はじめるために、何が問題で何が課題なのか、をみんなでディスカッションしました。
自分の参加したグループは、ウォーターホールとアジャイルを使うテストエンジニア、あと3人はアジャイル開発やってみたい勉強中の方でした。
そこでみんなが感じていたのは、以下でした。
・アジャイル開発って何がいいの？
・2週間って言われているけど、本当にそれで終了するの？
・終了基準て設けられるの？
・開発して、テストして、はい終わりで終わってる感じがするけど、それでいいの？
もし、チーム内にテストエンジニアを入れて開発することになったときの不安要素は何か？
・資料がほしいといわれそう
・何か用意しなくてはいけないような、手間が増える気がする
アジャイル開発で一番大切なのは、お互いがお互いに学べることができるということをお互いが理解することだと思いました。
Web のテスト/ウェブよ~ウェブウェブ
WEB系企業のテスト業務などについてのディスカッション。
WEB系企業のQAは、CustomerSupportから由来するケースが多いことに驚きました。
C社のように、WEBアプリだけならデプロイして問題だったらすぐに前の状態に戻せるのは非常に魅力的に感じました。
A社
大規模ウォーターフォール（QAのセクショナリズム）
スクラム（コストが高くなる）
以前は全チームにQAを入れていた
赤字に陥ったときに、QAチームを分離 → 開発者が自律的にQAをやるようになった
QAが別チームになって、QAのリクエストが捌けない
一部のチームのみQAを入れる
現在は、小さい改善を積み重ねていくという開発スタイル
今、スクラムマスターが少ないのが問題
CS（QA）は、開発者ではなく、企画者と話をしていた。
開発者と対話するためにCSの中でQAを採用した。
B社
開発者数百人に対して、QAは7人（少ない）
反復型・価値駆動
kickoff時にQAが入る。
→ QAテストが必要か有無を検討している
メンバーごとに得意分野が違う
問題：開発チームに障害が多く、障害を捌けない
→ 過去の障害パターン分析
→ 回帰テストの自動化
開発チーム：テストは自分でやるものだ。必要があれば、最後にQAがテストする
QAは、探索テストが中心
高品質なサービス = 魔法のような体験
C社
事業部（各サービスの開発チーム）と技術基盤・インフラ（横断的な部署）がある
・Development
・Source code Review
・Continuous Integration
・Production Test
・Production
Deployして失敗したら、すぐにロールバックできる環境としている
なので、QAはいらない。
iOSアプリ、1週間検証する必要がある
WEBアプリのようにはいかない
だから、QAが必要
→ QAは、2014/1 までゼロ
まだ1年1ヶ月
モバイルアプリは、リリース後に戻すことができない
なので、開発体制を変える必要があった
ユーザーファースト 隣の人を幸せにできますか？
<課題>
・拡散と並行
世界に広がっている。世界に拡散した開発者をどう組織化して進めていくべきか
- 組織・人員・国内外
D社
テストエンジニアリングによって、テストコストを下げる
自動化では手間のかかるテストを実現する
2011年8月にCustomer SupportからQAができた
<課題>
WEBやゲームの領域でも品質保証を魅力的な職種として確立したい
ディスカッション時に出たコメント
みんな面倒なことが多くて辛いことが多い
だれもやらない仕事を振られたり、人が足りなかったり...
テストエンジニアの採用どうやっている？
非常に難しい...募集かけてもこない
高い給料出せば来るとは思うが...
