WACATE 2015 冬
WACATEというソフトウェアテストの泊まり込みワークショップに参加してきました。
年に2回開催されていて、夏は1つのテーマ、冬は幅広いテーマで行われています。
今回は、冬なのでソフトウェアテストに関する幅広いテーマでのワークショップでした。
私はWACATEには初参加でしたが、参加人数は60人くらいで、20人くらいが初参加だったと思います。
ポジションペーパーセッション
WACATEには、参加の前にA4用紙1枚くらいの自分のPRなどを記載したポジションペーパーというを提出します。
そのポジションペーパーを使用して自分の自己紹介を3分くらい行います。
一つの席は6人くらいのチームになっていて、チームを変えて2回行います。
自分は自己紹介は苦手で、さらにポジションペーパーにも大したことを書いていなかったので大変でした。。
改めて自分のPRやしゃべるということを訓練しないとなぁと感じました。。
私の「テスト」、あなたの「テスト」
前回のWACATEでベストポジションペーパー賞を取得した浦山さんのセッションです。
自分にとってソフトウェアテストとは何かということを、マインドマップで考えようというセッションです。
スライドのようにマインドマップをどんどん広げていけたら良いんですが、実際にやってみるとなかなか難しいです。
マインドマップも訓練が必要かなぁと思いました。
マインドマップを作成した後は、チーム内で見せ合います。
人それぞれソフトウェアテストとの関わり方や、ソフトウェアテストについての考え方が違っていて面白かったです。
突撃となりのテスト計画 〜こんなときお隣さんはどうしてる?〜
テスト計画についてのセッションです。
それぞれがテストについて悩みを共有し、その悩みはテスト計画を立てるときに実際は決めなくてはいけないことだったのではないかなどの解決策を、話し合っていくワークショップでした。
実際にワークショップを通してテスト計画で決めることなどを学べたため、良い勉強になったと思います。
作業内容を明確にするために、テスト計画の段階でしっかり決めておくことを身につけておかないといけないと感じました。
わりとディープ?同値分割↔境界値分析
同値分割、境界値分析、ドメイン分析についてのセッションです。
同値分割、境界値分析は知識としては知っているけど、実際にテストできているかと言われるとかなり怪しいです。
ドメイン分析も学習したことは有るはずなのですが、全然理解していなかったことを再認識しました。
まだ完璧に理解はできていないので、複雑な仕様書と出くわす前に使用できるように身につけておきたいと思いました。
TPI NEXTで自分たちのテストを評価しよう
ソフトウェアテストのプロジェクト成熟度を測定するTPI NEXTに関するセッションです。
TPI NEXTのメトリクスの説明と、実際に「欠陥検出」のキーエリアを見てみようという内容でした。
自分のプロジェクトを想定して1項目だけでもやってみて、とても分かりやすい内容になっていました。
夜の分科会
夜はそれぞれのテーマに添って飲みなが語り合います。
泊まり込みなので、半分これがメインイベントなのかなと思います。
私は、ソフトウェアテスト初心者が今の悩みについて話し合うというテーマのところにいました。
仕事の悩みを社外の人に話すことはあまりない機会なので、悩みを何でも共有できる場所は貴重だと思います。
とても楽しかったです。
英語なんてこわくない~英語ドキュメントを読んでみよう
英語のドキュメントを読む時は、中学の勉強を思い出して恐れず英語を読もうというセッション。
中学の時に教わった事だけど、実際には忘れていて、そういえばそんな事も習ったなぁという良い思い出しになりました。
60分でわかった気になるISO29119
ソフトウェアテストの規格である ISO/IEC/IEEE 29119 についての紹介と解説です。
ISO/IEC/IEEE 29119 については、反対の声なども挙がっているという紹介内容でした。
ソフトウェアテストの規格について全くの知識がなかったため、勉強したいなぁと思います。
探索的テストはじめの一歩
探索的テストの位置づけの説明と、探索的テストを実際にやってみるというセッション内容でした。
演習は、実際にウェブページが用意されていて、バグを見つけていくというかなり凝った内容でした。
質問されない資料にするための4ステップ
スライドには、具体的な思考法の名前は出てきていませんが、TOCfEのCLRという思考法らしいです。
論理的に物事を考えるということは大切だと思うので、自分でも勉強しなきゃなぁと思いました。
ソフトウェアテストの最新動向の学び方
ソフトウェアテストの歴史と、今のソフトウェアテスト、ソフトウェアテストの最近動向の学び方についての紹介でした。
ソフトウェアテスト年表というまとめ資料が配られたのですが、昔から今の開発技法、テスト技法、テストツールなどが紹介されていてとても面白いなぁと思いました。
2日間のハードなワークショップでしたが、参加してみてとても楽しかったです。
次も参加できたら参加したいと思います。
システムテスト自動化カンファレンス 2015
システムテスト自動化カンファレンス 2015 に参加してきました。
テスト自動化のスキルを考えよう!
~テスト自動化エンジニアに求められるスキル、期待される役割~
ISTQB Expert レベルの Test Automationのシラバスの解説など。
テストエンジニアのスキルの指標としてTest.SSFというものがあるが、
自動化テストエンジニアとしてのスキルの指標となるAutomation test.ssfを作成しているという話。
Test.SSF の代わりになるようなものでなく、自動化テストの部分だけを取り出した補完するものみたいな感じなのかなと思った。
自動家は見た~自動化の現場の真実~
自動化を適用していた現場で、お客の担当者が変わり上手く行かなくなったという話。
じゃあ、あの時どうすればよかったのか?という話を現場視点とマネージャ視点からの意見で深めるという内容。
色々な立場があって、色々な意見があるんだなぁと思った。
自動化の必要性を説明しないと分かってもらえないのは当たり前といえば当たり前の事なんだけど、それを自分が出来るかと言ったらできないだろうなぁ。。
広告システム刷新よもやま話
- テストが当たり前となるまでにやったこと
Yahoo Japanで、広告のレガシーシステムがPerl(?)で作られていて、メンテするのにも時間が掛かるし、なんで動くのかわからないけど、型推論などでなんとなく動いていて「コイツ、動くぞ・・・。」状態のシステムを一からJavaで作りなおしたという話。
まず、一から作りなおして良いということを上の人が判断してくれる環境が羨ましいなと思った。
あと、内容に関してはJavaの開発の話なので、自動化カンファレンスというよりはJJUG CCC的な内容だった。
楽天で、CI,CDをどうしているかという話。
寸劇が面白くてイメージが強かったせいか、資料見返してもあまり内容が思い出せない。。
仕様変更した箇所はしっかり記録を残しておいて、後で見返して変更点と変更した理由が終えるようにしておくことが大切。
テストは頻繁に行って、ソースコードの作成からあまり時間をかけないでフィードバッグを得ることが大切。そのために、頻繁にコミット、すぐにテスト、ビルドを行うことが大切。
フィードバッグを早く得るためには、すぐにテスト環境を作成できるChefやDockerなどのツールの導入も必要。手動でインフラ構築をしていて、結果が1週間後とかでは遅い。
品質の悪いテストを頻繁に実行しても仕方がないので、テストコードは汎用性も考えたりして、リファクタリングを行う。
とかそんな感じだったかな。。。
キーワード駆動によるシステムテストの自動化について
キーワード駆動テストの話。
疲れがが出て眠くなってしまっていたので、あんまり理解出来ていません。
入力のバリエーションが変わっても出力が変わらない可能性があるなら、入力の変更でテストが出来るようするため、入力を外部ファイルにするというのがキーワード駆動開発なのかな?
他には、後でテスト出来るようにアーキテクチャを考えるのが大切とか。
Testing Tools for Mobile App
クックパッドでスマートフォンアプリのテストなどをどうしているかという話。
1年から1年半くらいで破壊的アップロードがあるとか、大変そうだなぁと思った。
クックパッドにテストエンジニアとして入って、社内の意識を変えているというのはすごいと思った。