こんにちは。今年からEC事業部QAチームの配属になったばんちゃん (@unionsep) です。
3月7日(水)と8日(木)に JaSST ソフトウェアテストシンポジウム 2018 東京 が開催されました。
QAチームのメンバーと3月7日に参加し、印象的な講演を聴講してきましたので、とても有意義な時間を過ごせました。
開催から少し経過してしまいましたが、今回は、QAチーム3人で聴講して学んだことや感じたことを、各メンバーから紹介したいと思います。
なお、レポートや講演資料は JaSST'18 Tokyo レポート にまとめられています。
A0) オープニングセッション
ライター : ばんちゃん (@unionsep)
会場である日本大学に着くと、思っていたより多くの入場者の姿を見て驚きました。
QAチームに配属されてから、品質保証や自動化などの知識を意識的に取り入れているので、昨今QAやテストエンジニアが注目されていることは知っていましたが、同じことに意義を感じている仲間がこんなにいることを嬉しく思いました。
私は事前にチケットを購入していなかったこともあり、チケット購入手続きを済ませるまでに2,30分かかってしまい、第1会場ではなくサテライト会場での聴講となりました。
オープニングセッションは実行委員の方から、開会挨拶と JaSST と ASTER の紹介がありました。
私は今回、初めての参加でしたが、 JaSST は15回目を超える歴史あるイベントなんだなと感じる反面、10年以上エンジニアとしてソフトウェアに関わって来たのに体系的に触れたことのない領域だったので、まだまだ学ぶべきことがあることを痛感しました。
A1) 基調講演 Advances in Continuous Integration Testing at Google
ライター : ばんちゃん (@unionsep)
Advances in Continuous Integration Testing @Google
オープニングセッションに続き、GoogleのJohn Miccoさんから基調講演が行われました。
Googleではほとんどの機能がテストコード化されており、そのテストは全て自動化されているそうです。
マニュアルによるテストは一切なく、1日1億回以上のオートテストを実施しているので、膨大なテストケースを機械学習などを利用し効率的に実行することで、サーバーリソースの削減につながるほどだそうです。
自動化する理由は、開発のサブミットから36時間以内にリリースするので、イテレーションの高速化を実現したいためだそうです。ただ、UI/UXに関わるテストや、実験的なテストについては、マニュアルで行っているそうです。
Googleでは SETI ( Software Engineer, Tools and Infrastructure ) というチームがあり、各開発チームにテストエンジニアが配置されます。テストレベルは各チームの成熟度や収益性によって異なるそうですが、全てのチームでテストを自動化する文化が組み込まれているそうです。質疑応答で質問されていましたが、チームによってカバレッジも違うそうです。
印象的だったのが、3人以上でプログラミングを行った場合、2人のときと比べてFlakyさが増すそうです。
昨今、モブプログラミングに焦点が当たっていますが、3人以上でプログラミングを行ったときに、不安定なテスト結果が出る割合が高くなる傾向にあるということでしょうか。
この因果関係はわかっていないそうですが、GoogleでのFlakyなテストデータを分析した結果だそうです。
関係性がわかっていない以上、複数人でプログラミングを行わない方が良いと結論付けられませんが、とても興味深いデータの紹介でした。
我々もGoogleほど高次元な事象に遭遇しているわけではないですが、テストに携わる人はFlakyなテストで困ったことはあるのではないでしょうか。
その時、コードの不具合なのか、テスト環境依存なのか、テスト設計や計画によるものなのか判断できず、原因究明に多くの人間を巻き込んでしまい時間もかかってしまいます。
そのため、Flakyなテストのノウハウや経験を知りたいし、ペパボでも測定していきたいと思いました。
Flakyなテストは、プログラミングに関わる人数が関わっている他に、QAや開発チームの特徴や属性、特性にも起因するのかなとも想像しました。
基調講演では、Googleの品質に対する取り組みに圧倒されてしまいましたが、少しでもペパボで取り入れていきたいと感じました。
A2) WEBテスト Web.JaSST ～ウェブ系QAがみんなのお悩みに全力で提案を返す会～
ライター : せっきー
この講演は、ウェブサービス開発に従事するQAのための勉強会です。
SNSや聴講者から募集した、日々抱いている悩みや課題について、若手から中堅、熟練QAがそれぞれチームを組んで、パネルディスカッション形式でアドバイスします。
現場と経験に直結した意見が双方から聞くことができました。
まずは事前に募集していた質問の中から、技術的な内容へのアドバイスです。
網羅的なテストの作成には、テンプレートを用意し漏れがちな観点を補足する他、提供したいユーザー体験を抑えること、テストケースや仕様のレビューなど、様々な観点を持つことが有効との回答。
バグ分析については、各々バグの件数や重要度、アプリのクラッシュ率などを記録しているようです。
弊チームでもGQM法を用いてテスト完了の定量的な判断に用いたり、欠陥のパターンを分析して作り込みを防止していきたいと考えています。
続いて、QAのキャリアやマネジメントについての質問も多く寄せられていました。
そもそもQAは必要なのか、開発者に対しても、マネジメント層に対しても、信頼の獲得に苦戦している現場は少なくないようです。
これまでQAは誰にでもできる単純作業と認識されがちで、今でも給料が低く設定されたり、キャリアパスが不透明であることに不安を抱いています。
これに対しては、やはり事業に貢献するしかないとの回答でした。
貢献度は職種・階級問わず評価に盛り込んでいることと思われますが、QAならではの評価軸として、プロジェクトが炎上していない状況を作っていることを評価したいとの意見もあります。
また、テスト自動化の需要の高まりに伴い、プログラミングができるQAを採用したいが難航しているという現場も多く見られます。
今あるQA資産が、外部採用に求めるスキルと経験に伴っていないなどが理由です。
したがって、社内のプロダクトエンジニアをQAエンジニアとしてチームに引き抜いてくるのですが、どこかで緊急度の高い案件が持ち上がると、すぐそちらにリソースを取られてしまう。
まだまだエンジニアがQAに専念するには難しい現状が語られました。
終了時間も迫って来たところで残り2問、当日聴講者から寄せられた質問に答えていきます。
テスト管理ツールはなにがおすすめかという質問には、やはりExcelという回答。
国内の場合、全ての機能に一定の品質求められるため、テストケースを管理するには一覧性が高いものが適しているのでしょう。
もちろん、進捗管理、不具合管理など、管理する対象によって使いやすいツールは異なります。
最後は探索テストの工数の見積もりと完了条件についてのお悩み。
探索テストをやっているうちに非機能テストに寄り過ぎてしまい、工数を圧迫するなどはありがちなパターンなので、観点とやらないことを決めておくこと、とのアドバイス。
また、探索テストに入る前に、テスト項目消化数と摘出したバグの数から、プロジェクトの問題点を分析して、テストの質とプログラムの質を確認する。
テストとデバッグに問題がないのなら、先に上げたバグ分析で欠陥のパターンを確認し、関連性や類似性のある機能に目星をつけ、工数を見積もると良いように思います。
日々の悩みは尽きませんが、以上で講演は終わりになりました。
QAチーム作りや地位の向上、テスト結果のプロジェクトへの効果的なフィードバックを通しテスト文化を根付かせることなど、自分が抱えるものと同様の悩みを聞くことができました。
提示された解決方法は、すでに実施していれば安心感が得られましたし、まだ手を付けられていない改善もひとつずつ取り組んでいきたいと思います。
A3) テクノロジーセッション テスト会社のテストリード達はどのようにテストを成功に導いているのか？
ライター : さおり
こちらはソフトウェアの検証会社・ベリサーブ社さんによるセッションです。
登壇されたパネリストの方々が、テスト成功の秘訣や意識していること、また、テストの面白いところや、良いテストエンジニアなどの質問について話していくという形式でした。
その中でも特に、パネリストの方々が揃って、テストの面白いところは狙って不具合を出せたときで、良いテストは他人が見て説明がきちんと書かれていて目的がはっきりしているテストだという点が印象的でした。 過去の経験から先に不具合を見つけられたときにはテスター冥利に尽きるとのお話には、会場内でも頷かれている方が多かったです。
そして、良いテストエンジニアについてと、開発とテストエンジニアとの関係性については、開発を小説家、テストエンジニアを編集者、利用者(ユーザー)を読者に、それぞれ例え、読者が求めるものと小説家がやりたいことの両方を理解し、ズレが生じているようならうまく指摘をしながらサポートできるのが良い編集者であること。そのために、日頃から雑談などでコミュニケーションを取ることが大事だというお話には思わず膝を叩いたほどです。
不具合報告のしやすい関係性やユーザビリティ観点からの報告提案が、スピーディな不具合改修ひいてはテストの成功につながるということを改めて実感するとともに、今後のチームづくりに大いに参考になる内容でした。
おまけ 日本大学の学食で昼食をいただいてきました
大学での開催ということで、日本大学さんの学食にお邪魔させていただきました。
3人とも、カレーが好きなのか全員カレーをいただき、とっても美味しかったです。
学食なんてとっても久しぶりだったので、学生の雰囲気を久々に感じることができ、リフレッシュできました。
まとめ
以上、 JaSST ソフトウェアテストシンポジウム 2018 東京 に参加した紹介レポートでした。
私たちは現在、今回は一緒に参加できなかったEC事業部の女神様 (@nyanyami) とともに、 JSTQB の勉強を週1回のペースで行っています。
今年、8月に試験が開催されますので、それに向けても勉強の真っ最中です。
カラーミーショップ では、これからも安心してお客様にご利用いただけるよう、QAチーム一丸となって品質向上に取り組んでいきたいと思います。