見出し画像

LINE Developer Meetup #39に行ってきた

LINE Developer Meetup #39 Testing &Engineering

開催日:2018/06/27 19:00~21:00
場所:LINE株式会社

LINEでは非常に多くのプロダクト・アプリをリリースしていますが、その厳しい品質管理のために、開発テストの責務を負っているエンジニアの存在が欠かせません。ここでは、LINEにおけるテスト自動化の事例と、SET(Software Engineer in Test)という社内のポジションの果たす重要な役割についてご紹介いたします。

さらにゲストスピーカーとして、ソフトウェアテストの世界の第一人者として精力的に研究・教育活動を行っておられる、電気通信大学の西康晴さまをお招きしました。

セッション一覧

・イマドキのソフトウェアのテストやQAの考え方
  - 講演者:西 康晴 @YasuharuNishi
  - 所属:電気通信大学
・LINEのUI自動テスト事例
  - 講演者:大園 博昭
  - 所属:LINE Fukuoka
・An Agile Way As an SET at LINE
  - 講演者:伊藤 宏幸
  - 所属:LINE

イマドキのソフトウェアのテストやQAの考え方

昭和の会社と今時の会社の違い
昭和の会社は何でもかんでも労働でなんとかしようとするため、指数関数的にスケールアップするため、ある一定の場所で何もできなくなってしまう。そう、昭和の会社のQAは無理ゲーで重課金状態である。しかし、今時の会社は脳みそをスケールアウトさせるため、ずーっとスケールすることが出来る。

昭和の会社の問題
昭和の会社の共通点は脳みそのパラダイムが古く、新しいキーワードにすぐ飛びつくが失敗する。そのため、QAなども自動化すれば大丈夫だろうと考える。個々の取り組みをコード化をやればやった分だけ成功するかもしれないが、結局は根付かない。なぜなら、考え方が昭和であるから。重課金して、クリアした感覚になっているだけである。

何を売っているかをエンジニアは考えていることが多いが、会社は分かっていないので、部長や課長が技術を把握する必要がある。今時の会社では、何を作ればいいのかを分かっていて、どういう風に作るか分かっているため、放置しとけば勝手にいいものが生まれるため、アジャイルがうまくいく。

ソフトウェア開発を計る論文は色々あるが、結局昔からソフトウェアは計れないものである。無理ゲーを数値化させるのは無理。今時の会社は無理なものは無理という考え方だが、昭和の会社では、無理なものを通すのがお前の仕事だと考え、残業などの労働で解決しようとする。

昭和の会社では、自動化するためにはりん議などに時間がかかってしまうため、簡単な人を雇うという手段を取ってしまい、機械化を嫌う。だからと言って、自動化をしまくれば良いというわけではない。自動化が楽しくなってしまい自動化ハイに陥ってしまうことがあるため、ちゃんとなんのためにやっているのかを考える必要がある。

まとめ
脳みそのスケールアウトするには、最低でも1年以上かかる。会社の中にはいっぱいある昭和を1つ1つ潰して、理解・納得・共感してもらい、行動に移してもらうことが重要であり、これが品質保証の仕事である。現在の日本はオフショア先だと思っている某アジアのQAに負けているので頑張ろう。品質保証やテストは相手が人間なため開発より楽しく、組織を賢くするためにはあらゆることをする最高にやりがいのあるクリエイティブな仕事である!


LINEのUI自動テスト事例

LINEの自動化
LINEではQAチームはいたが、1年半前に自動化専門チームが立ち上がった。Browser, iOS App, Android AppのE2E UIテストが主で、ツールとしてはJUnit, Maven, Spring, Selenium, Selenide, Jenkins/CircleCI, Appiumを利用していて、情報が多いためJavaを使用している。

テスト自動化してよかったこと
pushした時点でテストが始まり、次の日には結果がわかるため手戻りが少なくなった。直近3ヶ月は自動化テストの方が手動より多くのバグを見つけてくれる。

テスト自動化して悪かったこと
人的コストを減らして欲しいということが始まりだったが、今の所は解決できておらず、結局自動化テストを作るためには人員が必要になってしまうため、UIテストを増やしてもメンテナンスコストが増えてしまう。


An Agile Way As an SET at LINE

SETとしてやったこと
まず最初に、仮説設定と検証の繰り返しによる施策の発見と分析を行い、CIと静的コード解析でテスト対象システムを解析した。その後、障害報告はヒントの山なため、障害報告の分析を行い、関係者からの情報収拾を行い、困っている人と話して見える化を行った。

自動化テストを活用して、システムを把握
wikiやドキュメントは間違っているもので、動いているものが正義である。なのでXUnit Test Patternsを利用して、プロダクトを知るためにテスト自動化をするのもあり。

所感

LINE Developer Meetupは2回目の参加だったのですが、今回は人数が多く、遅刻してしまっため、椅子のみの席だったので腰は痛かったです笑。最初に飲み物は出るのですが、食事は懇親会の時のみという感じです。2回連続で懇談会には参加しなかったので、懇談会の雰囲気はわかりませんが、懇談会に参加せずに帰宅しても大丈夫な雰囲気です。

昭和の会社に勤めていて、テストの研究をしていた僕からすると、西 康晴さんのお話はとても面白かったです。大学の授業の良いところとIT系の勉強会のいいところが合わさったような発表でした。

宣伝

ITエンジニア向けの勉強会での記事を投稿しています。
興味がある方はnoteアカウトをフォローして頂けると嬉しいです。
Twitterもよろしくお願いします。@TTrpbm

最後まで見て頂きありがとうございます! フォローやサポートして頂けると、励みになります。