JaSST'16 Tokyo 参加してきましたレポート

このエントリーをはてなブックマークに追加
こんにちは!
inomata@QAです。

去る3月8日に国内最大のソフトウェアテストシンポジウムのJaSST'16 Tokyoに行ってきました。
今回もQAが総出で参加してきましたので、レポートをまとめたいと思います。

***********

inomataレポート

基調講演

「Software Test Challenges in IoT devices  IoTデバイスにおけるソフトウェアテストの課題」

IoTにおける課題とは、例えばwebサービスと組み込みのソフトウェアがつながるようになってきた。そうすると組み込みのソフトウェアwebの問題を、webサービスは組み込みの問題を意識しないといけなくなってきた。
これらをテストしていくにはサービスとして包括的に捕らえる必要がある。手元の情報がいったいどこまで届くのかを意識しないといけない。

IoTの課題を解決に導くアプローチ
・モデルベーステスト
システムをモデル化をしてテストケースを導く。開発が作成するモデルとQAが作成するモデルの差分を取るとお互いの抜け漏れが見つけられる。また、UTPのようなツールを使うとよい。

・マスベーステスト
テストに数学的アプローチを導入したもの。例えば、互換性テストのためのAndroid端末は、全部なんてとてもできないから、統計学的なアプローチを取る。ビッグデータや解析といった領域も数学的アプローチで対応。

・探索的テスト
探索的テストはチャータがあるとやりやすいが、前述どおりwebと組み込みでは文化も観点も異なる反面、それぞれを意識しないといけないようになるので、それぞれの観点を持ち合わせる必要がある。

・標準ベース
ISO29119、やIEEE1012-2012といった標準を用いる。このあたりの標準はIoTに向けて動きがあるみたい。

そのほかIoT時代における課題
・大量データをどうするか?
今後、扱うデータは増える一方。こいつを相手にするには
 - データを分類して効果的なデータ群を作る
 - あるいはデータではなくテスト結果を分析してテストを作る

・セキュリティ・プライバシーどうする?
個人情報はどこからどこまで存在するのか?昨今騒がれる反面扱いが拡大している。

・互換性とか大丈夫?
例えばスマートフォンをもってエレベーターに載ったとき、その電波が切れるとする。するとその先のシステムでデータが落ちて何らかのエラーになる。といった話は十分考えられる。
ユーザーはヒトだけではなく、接続先のシステムでもある。

所感
IoTは領域が広がりすぎるから、いかに責任範囲を明確にして自分の領域の品質を担保していくかということと、エラーが発生したときにいかに安全に動作するかの作りこみをしていくかが重要になりそうです。
今後リスクベーステストがはやりそうです。

B2)「Web.JaSST ~ウェブ開発のテストや戦略~」

webアプリケーションのQAによるパネルディスカッション形式
ぶっちゃけトークが繰り広げられました。意訳も含めてまとめておきます。
公開できない情報は載せていません。(たぶん)

Q1.web業界でテスト戦略って乏しくない?
・メーカーのウォーターフォールプロジェクトとかに比べればそんなにカッチリしたテスト戦略はない。というか、web業界は変化が早いのでじっくり戦略を練る事はやらず、臨機応変に対応する必要があるのでこの方があっている。
・とにかくスピード重視。ただしドキュメントを作らないと属人化しやすいのはデメリット。
・チケット駆動を大切にしている。プロジェクトに関わる人はチケット上でコミュニケーションをとり、担当のタスクを順にこなしていく。とにかくチケットで情報管理&共有
・膨大なテスト戦略はないが、それぞれが最適な活動をしているといった感覚。特にテスト戦略が無いからといって困っている様子はないみたい。

Q2.テストベースが無い場合どうやってテストする?
・とにかく動作確認で期待結果を作っていく。この時点E2Eの自動テストまで作っておくと後で役に立つ。
・サービスとしての価値をテストする。仕様どおり動いても、それがユーザーに価値を届けないと意味が無いので。
・知ってる人に聞きまくる。例えば、その製品が何をしたいかは売ってるいる人が知っている。場合によっては退職した人にも話を聞いたり。
・探索的テストを実施する。社内に探索的テストの知見をまとめて活用している。

Q3.リリース前に判断や意見を求められたときどうする?
・判断できる材料を集めてリスクを伝える。
・判明しているリスクをカスタマーサポートに伝えておく。こうしてプロダクトのリスクをサポートに寄せて強気にリリースできる。サポートチームとの情報共有は大事。
・判断ができない時点できっと十分なテストをしていない。なのでリリースはしない。問題を出してやって現実を突きつける。
・リリース後に問題が起きた時の対応を決めておく。
・QAはプロジェクトの流れを止めるのではなく、プロジェクトをコントロールできる立場にある。

その他
リリースのスピードは?
・どんどん早くなっている。競合も早いリリースをしてくるので、戦うにはスピードが必要。
・リリース速度に伴い、ロールバックの仕組みは必須。

所感
弊社は今リリースのスピードが結構問題なっているのでそのあたりを質問してみたのですが、各社毎週リリースしていたり、スプリント終了ごとにリリースしたりと、すごいスピードでリリースしているとの事。さすがです。
テストのプロセスをどうこうという話より、開発プロセスの中のテストをどうするかという話が重要と感じました。

***********



hanレポート

A2) 事例発表「テストの計測」~テストを測る~ 

A2-1 「レビュー目的・観点設定の効果と課題」


・同じ内容のテストケースを2つを用意してそれぞれレビューを行ったところ、記載内容がわかりやすく、明確できれいになっているテストケース方がレビューしやすく間違いを探しやすかった。
・急で行われるレビューはアドホック状態となりがち、レビューを依頼される側で内容を把握しておらず、誤記・不明な点には気づくが、レビューアによっては指摘内容がばらばら(何を見てやればいいのか判断する余裕がなく、各自のスキルに依存される)
・役割分担ができていないため、指摘内容が重複したり、レビュー漏れが発生したりする
・レビューアが準備できていない状態で行われるレビューは有効なレビューにならない
・レビューを依頼する内容を事前に共有することで、誰がどの部分をレビューするなどの役割が決まり、レビュー対象の背景なと把握する準備など、レビューの目的・観点抽出などもっと具体化される。そのため担当領域に絞られ、重複や漏れが減る
・つまり、同じテストケースのレビューであってもレビューアが内容を把握できる時間が事前に準備できていれば、同じ時間(工数)を使っても効果的なレビューが実施できる
・レビューアの立場によっては観点が異なってくる
・製品の特徴・レビュー環境などを考慮してレビュー実施方法を採用するのも大事
・目的に合わせて適切な観点が必要になってくる
→例と挙げられたのが、amazonのようなWebサイトで‘使いやすい‘を実現したい場合にボタンをクリックしてレスポンスがすぐ帰ってきてユーザがイライラしない、サクサク動くのも該当しますよね?と言ったけど、それってパフォーマンスじゃないかと質問もあった。
パフォーマンスとして見ないといけないけど、これはこれで使いやすさの観点になるのではないかと回答。。。どっち正しい、ただパフォーマンスだと期待するレスポンス時間があってそれをクリアできるかどうかの話となるかと。。。

感想
・個人的にはテストケースを書く時にこの機能は何を実現するための作ったモノなのか、自分はそのために何を確認したいのかを明確で簡潔に書くように心かけていますが、いくら綺麗に書いたテストケースであっても、急なレビューを依頼するとレビューアは機能やテストの目的が何なのか把握することから始まるので、これは要改善だと思いましたが、なかなかそうにはいかないのが現実です。
・自分の経験則でレビューアの立場から見ると、目的と期待結果が明確じゃないテストケースは本当にわかり辛くて、やるべきのことを漏れなくやっているかが気になる。個人的に思うには相手に理解してもらえるテストケースになっていない場合にはケース漏れの可能性が高いと思いました。

A2-2 「テスト設計スキルの計測と教育効果に関する実験と考察」

・テスト設計って広範囲の意味で使われているけど、
 テストの対象と目的を明確にする→計画
 テスト対象を細かく砕いで→分析
 目的み合わせてテストケースを作成する→設計
 テストケースのテストを行う→実行
・近年ソフトウェアテストの書籍は出ている、やセミナーな・勉強会などは行われていており、そういった知識は習得できるが、スキル習得できる方法がなかなかないのが現実
・現場で先輩達がやってきたのがそもまま受け継がれているのじゃないかな。。経験のみであって適切な教育などが行われていないか。。と思われる
・実践に近いのがいいんじゃないかなと。。WAKATEとゆう1泊2日のWorkshopを開催した
・経験やテストスキルは各自それぞれ、若手の人が多い?
・何も教えず、課題を出してテストケースを作成してもらい、テストフォーマットもそれぞれ
・こうすればこるなること、条件・手順・期待結果、書き方は各自の経験によったりもする
・何も教えないで1回目→レクチャーしてから2回目→参加者間で話し合い・レクチャーしてから3回目を行った
・効果が高かったのは経験3年以下の人達だった、どこでスキルをみに付けたか詳しくわからないけど、経験のある人達はあまり効果が出てなかった、経験があるほど自分のスタイルが確立されているからかな?全体で言うと効果はみんな出てはいる
・参加者のアンケート結果によると1泊2日のWorkshopで3年間の経験値の価値がある回答は一番多かった、
・今後もどのような教育をするとどのような効果が出るかをさらに分析して,テスト技術の向上に役に立てたい

感想
・1泊2日で3年間の経験値を得られるのは凄いと思いました。
・本Workshopの結果だと経験3年あれば、そのあとはテストケースの作成スキルはあまり伸びないようですが、製品全体の品質を向上させる中でQAのテストケースを作成は一部の業務に過ぎないと思いました。

***********


kzhirataレポート

E4) ユーザビリティテスト ~UX(ユーザーエクスペリエンス)ってなんですの?~

基本は単純:ユーザにてスクを提示して、その実行過程を横で観察するだけ。 思考発話:ユーザーに思ったことを口に出しながらタスクを実行してもらうこと。

判定基準

下記3つの観点で判断する。

効果:ユーザがそのタスクを完了できるか
効率:ユーザがなるべく遠回りせずにタスクを完了できるか
満足度:ユーザがタスクを完了するまでに、不安や不満を感じないか(喜ばせることではない)
ユーザーテストとは、ユーザーに製品をレビューしてもらうことではない。 ユーザーが意見を言ってはならない。



ユーザビリティラボ
4週間
200万円
専門家の報告書 こんなことまでしなくてよい。


「これで十分」ということを積み重ねていく。

部屋の片隅で
身近な道具で(Ziggiでスマホ操作を録画)
手軽に分析(専門的な手法を駆使しなくてよい。)
タスク

各タスクを積み重ねてシナリオみたいにする。

「○○してください。」
「次に○○してください。」
(例)カメラでスマホアプリのテストをとったとき

指の動きをとりたい。
なるべくリラックスした環境でテストしてもらう。
ここから実演

折込チラシアプリで、身近なスーパーの情報を見つけてもらう。

ユーザーにインタビュー(どんな人なのか、アプリに関連する普段の週間をヒアリング)
自分で使っているデバイスを使う
タスクを提示
操作ごとにつぶやいてもらう
全体の感想をもらう(最後に☆の数を聞く、今後使うか)
このテストについての感想をもらう(ユーザテストは初めてか?など)
1人目:男子大学生 2人目:女子大学生

検証

インタビューが終わった後に、分析して、再度アプリを改善するサイクルを1回は実施すること

質問

カメラで録画したVTRを検証する方法は?自動化とかないのか? → 力技でがんばるしかない。
話してくれないユーザーがいた場合、どうすればいい? → それで問題ない。下手にインタビュアーが話しすぎないようにする。
どんな人に対して、テストを依頼すればいい → ターゲットとしているユーザー、今回のケースでは紙のちらしを見る人

***********

今回もアツいセッションが各会場で繰り広げられていました。
モチベーションがアガる良いイベントなので、行ったことの無い方はぜひ参加してみてください。テストの自動化や戦略の話題にも事欠かないので、テストエンジニアのみならず開発者やマネージャーの方も参考になると思います。

それでは!
次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...