はじめに

こんにちは。福岡工業大学3年の嵩原ひびきです！QAエンジニアインターン生としてLINE Fukuoka株式会社に2ヶ月間お世話になり、ノンコーディングツールを活用したテスト自動化について勉強させていただきました。この記事では、期間中に学んだ内容について紹介していきたいと思います。

QA Engineering室(以下QAE室)について

私は今回、QAE室という組織にお世話になりました。QAE室ではインターン受け入れの前例がなく、今回が初めてとのことでした。（受け入れありがとうございます！）

QAE室は2020年にLINE Fukuoka内に設立された組織で、テストのみならず、要件定義・設計／開発なども含めた開発プロセス全体に関与して品質保証や改善業務に取り組んでいることが特徴です。

なにをやったのか

LINE社内向けの認証認可プラットフォームの開発プロジェクトに参画し、ノンコーディングツールであるMagicPodを用いてテストの実装・実施を行いました。

MagicPodとは

昨今普及しているノンコーディングテスト自動化ツールの一種で、非エンジニアでも使える直感的なデザインが特徴です。LINE株式会社はMagicPodをエンタープライズ契約しており、様々なプロジェクトで活用されていました。

参画時のプロジェクト状況

ローンチに向けて、開発・テストが行われている最中でした。
テストは開発チームとQAチームでテストレベル（単体テスト、結合テスト、システムテスト）ごとに分担し、QAチームは主にシステムテストを担当していました。そのシステムテストの中でさらに「１画面ずつ単独で操作する各画面ごとのテスト」と「複数画面をシナリオに沿って操作するユーザシナリオテスト」の2段階に分けてテストを実施している状態でした。

テストのやり方と仕組み

このプロジェクトでは「スクラム開発であるため、新規・改修機能が毎週のように開発環境にリリースされ頻繁にリグレッションテストが必要なこと」と「社内システムであるため、将来的に少ない人数で広い範囲を保守していく可能性があること」の2点を踏まえ、テストを自動化していました。さらに、開発生産性や品質向上を狙いとして「手動テストを可能な限りゼロにしてテストを自動化する」というのが基本方針でした。（この辺りはLINEとヤフーの合同技術カンファレンスであるTech-Verseで私のメンターさんが発表されてますので、詳しくはそちらをご覧ください。開発生産性や品質向上を目指してE2Eテストをとことん自動化したら得られたもの）

作成した自動テストは以下のような仕組みを通して実行されています。

① Jenkinsによる定期実行イベント
② HarborからDockerイメージをダウンロード
③ GitHubからMagic Pod設定ファイルのダウンロード
④ ②でダウンロードしたDockerイメージを元に実行環境作成
⑤ テスト実行
⑥ テスト結果ファイル取得
⑦ ⑥のテスト結果ファイルを元にTestRailに結果を連携
⑧ Slack通知

私が参画した時点では既に各画面ごとのテストが完了しており、作成した600ケース以上のテストは既にMagicPodによって定期実行されていました。そのため、今回は未着手であったユーザシナリオテストを担当させていただきました！

▲ 実際に運用している様子

作業内容

担当プロダクト・ツールの理解

シナリオテストの実装をすることになったものの、担当プロダクトの仕様やMagicPodについては全く知見がない状態でした。そのため、QAチームの新規参加者向けに用意された以下のようなOnboarding資料を使いながら理解を深めました。

・テスト対象システムの設計書

・テスト実装方針（「テストケースの粒度」や「アサーションすべき対象」などの基準をまとめたもの）

・上記のテスト実装方針に沿って作られたテストケース

また、私が別の企業で業務をした際には全ケース手動でテストを実施していたため、自動テストの練習問題などを使用することでMagicPodの使い方を学びました。

キャッチアップを実施したことで、以下の側面でMagicPodの良さを感じました。

実装済テストケースを実行させることで、具体的にどのように画面が利用されるか確認できる　→ より短い時間でプロダクトの仕様を理解することにつながる

前述した通り、私のプロジェクト参画時には既に600ケース以上のテストが実装・運用されていました。そのため、仕様書を見てイメージが掴みにくいところがあっても、実際のテストケースを実行することで疑問点の解消に繋がりました。

テスト実装

キャッチアップを2日程度実施した後、さっそくシナリオテストの作成に取り掛かりました。テスト実装では、社内に存在していた利用者向けのドキュメントを参考にしながら、「想定されるユースケースを問題なく実行できるか」という観点に基づいてテストを作成しました。テスト実装ではMagicPodに対して以下のようなメリットを感じました。

参考にできるテストケースが存在することで「テストケースの粒度」や「どのくらいの頻度でアサーションするか」などが把握しやすい

テストケースの作成において、人による違いが出やすいのが上記の2点です。今回は”進行中プロジェクトへ途中参加”ということと、”作ったテストケースは今後も残る”という2点も相まって、作成したテストケースに自信が持てない状態でした。そのような状況に対してOnborading資料に記述した「テスト実装方針」とそれに沿って作られた多くの実装済みのテストケースを参照することができたので、新規参入者でも同じ粒度、アサーションの頻度を揃えることができました。

また、私が今まで経験してきた開発現場は「QAチームが存在していない＆テストは出来る人がやる」「QAチームは存在している＆全て手動実装」という2つのパターンに分かれていました。前者の場合はテストに関する情報が属人化してしまいますし、状況によってはテストの実行まで行えないこともありました。後者は、同じQAチームでも人によってテスト手順の書き方が異なる場合があり、テスト実行者が混乱することがあります。今回のようにツールが導入されていると、作成者によって粒度は異なることがあっても、手順の書き方で差異が生まれることはありません。このような面で、QAチームがテスト手順を全て書き出すのではなく、あえてツールを使用してテスト作成をするメリットを強く感じました。

さらにMagicPodは、同じ処理の流れを「共有ステップ化」することで複数のテストケースからその共有ステップを利用することができます（例 ログインの一連の処理を共有ステップ化し、各テストケースで利用する）

私の参画時には、既に各画面の主要な処理に対する共有ステップが実装済みだったため、シナリオテストの実装を効率的に行うことができました。今回携わったプロジェクトは認証認可プラットフォームということもあり、1テストケースで利用する申請・承認のステップが非常に多かったのですが、同じ手順を1つのステップとしてまとめることでテストケースの短縮や、テストケースの理解を容易にすることに繋がりました。

▲ 共有ステップなし（左）／ 共有ステップあり（右）

テストレビュー

作成後はメンターさんにレビューをお願いし、「客観的に見た時に分かりにくい部分」や、「シナリオテストの流れとして不自然な部分」を指摘してもらいました。今までの開発現場では、担当プロダクトに対して「1人でテストケースを1から作成する」ことがほとんどだったため、プロダクトに対して「複数人でテストケースを作成する」という環境は初めてでした。そのためインターンでは、テストの粒度を合わせることや、既存のテストケースを参考にすることを意識して実装しました。メンターさんにレビューしてもらうことで、自分と認識がズレているところであったり、冗長になっている部分をその都度見つめ直すことができました。

自動テストはどのように活用されていたか

1．定期実行による不具合の早期発見

前述したように、このQAチームではスクリプトテストを全てMagic Podで作成しており、テストを1日1回定期実行しています。そのおかげで、不具合を迅速に発見することが可能です。実際に私が参画してからも、不具合を当日検知して開発チームへ報告している場面がありました。また、不具合が発生していない場合でも「テストした箇所が問題なく稼働しているなによりの証拠」になり、安心感へと繋がります。

2．仕様理解の補助

プロダクト理解の部分でも触れましたが、自動テストの動きを見ることでプロダクトの理解を深めることができます。ほとんどの場合、新規参画者が仕様を把握しようとすると「仕様書を読み解く」「手動テストの手順に沿って画面を操作する」といった手段が存在します。これらのドキュメントがどこまで丁寧に整備されているかによりますが、「仕様書を読み解く」という手段では利用しているイメージを掴みにくかったり、「手動テストの手順に沿って画面を操作する」という手段では、暗黙知が存在していたりと、新規参画者にとって少し把握が難しいことがあります。しかし、MagicPodの自動テストが存在すると「画面操作手順が具体的に記述されている（＝暗黙知が無く具体的）」かつ「非エンジニアでも理解しやすい」ため、仕様理解の補助をすることができます。もちろん仕様書や手動の確認やダメ！という訳ではありませんが、もし今回のプロジェクトで自動テストが存在していなかったら、さらに仕様理解に時間が必要だったと断言することができます。

「定期実行による不具合の早期発見」は、知識は持ち合わせていても実感する機会がなかったため、今回改めて利点だと感じることができました。また「仕様理解の補助」に関しては、インターンに来て初めて知った活用方法でした！

自動テストを継続して行うために大事な3箇条

今回のインターンに参加するまで自動テストの経験ゼロという状態ではありましたが、そんな立場から感じた「自動テストを継続して行うために大事なこと」について、3つ挙げたいと思います。

チーム内で実装ルールの認識を合わせておこう！

自動化することで暗黙知は無くなるものの、”どの単位でテストケースを作るか”・”どういった部分をアサーションするか”などは作る人によって全く考えが違うと思います。そのため、「テストケースの粒度」「どのくらいの頻度でアサーションするか」などは最低限チーム内で認識を合わせられることが大事だと思います。今回私が参画したプロジェクトでは、それらの基準が社内Wikiにまとめられていたことで、既存のテストケースと同じような粒度で新規テストケースを作成することができました。認識を合わせるだけでなく、それをいつでも確認できる状態にしておくことが大事です。

作ったテストは毎日実行しよう！

テスト自動化のメリットはやはり「定期実行による不具合の早期発見」ですよね！リグレッションテストなどの部分はこれらを活用したいので、作ったテストは定期実行に組み込みましょう。これには「毎日実行することで修正が必要なテストに気付ける」というメリットもあります。自動テストがエラーになる理由は、画面の不具合だけではありません。「画面の仕様が変わったけど、テストの修正をし忘れた」などもその一部。定期実行していない場合、「テストケースの修正が必要なことに気付かず、腐ったテストケースが増える」といったことも想定されます。トライアンドエラーを繰り返すためにも、作ったテストを定期実行することが必要です。

全体的な仕組みをデザインしよう！

最後に、全体的な仕組みをデザインする部分です。全体的な仕組みとは「テストのやり方と仕組み」で紹介させていただいたようなJenkinsやDockerなどを使った自動テストを運用するための仕組みのことです。これらの仕組みがない場合、以下のような状況となり自動テストのメリットが低下すると思います。

• 毎日人手で自動テストを実行する必要がある
• 直列実行のためテストに時間がかかる
• テストが成功したか・失敗したか確認する必要がある

それに対して紹介したJenkins,Docker,Slack連携などを使った仕組みがあったことで、以下のようなことが実現されていました。

• 毎日自動で実行してくれる
• 並列実行のため直列実行と比較して実行時間が10分の1以下に短縮
• テスト失敗時にSlackで通知してくれる

今回のインターンはそれほど長い期間ではなかったため、私の業務内容としては「MagicPodを用いたテストケースの作成」が中心となりましたが、作成した自動テストをフル活用するためには、テスト対象のプロダクトや社内インフラ、ツールなどを加味して全体的な仕組み（定期実行・並列実行・結果通知など）をデザインすることが大事だと学びました。

おわりに

今回のインターンに挑戦するまでは、自動テストというものに対して”導入が難しい”・”痒い所に手が届かない”・”壊れやすい”という3つの消極的なイメージを抱いていました。しかし、MagicPodを使用して実装していく中で、とても簡単に幅広いテストが作成できることを強く実感しました。また、自動テストは作ったら終わりという訳ではなく、それを定期的に利用することが一番重要であることも同時に学ぶことができました。学生という立場だと、普段の開発でここまで大規模にテストすることは難しいかもしれませんが、今回学んだことは他の現場でも何かしら流用できると感じています。開発業務でも最初は実装ルールの認識合わせが必要ですよね。(命名規則とか、どの粒度でコミットするとか、ブランチを切るタイミングとか...)

今回の内容を実践する機会は減ってしまうかもしれませんが、「チームで認識を合わせる」「作成したものを放置しない」「作った後の仕組み化を考える」という3つとして考えてみると、他の現場でも活かせる内容だと感じています。

「インターンとして期限がきたからそこで終わり」ではなく、今後も様々な知識に触れることで今回の学びを深めていきたいです！

最後になりましたが、インターン生受け入れの前例がない中で貴重な機会を作ってくださったQAE室のみなさん、本当にありがとうございました。最後までやり切ることができたのは、メンターの方を始めとした多くの社員さんの協力があったからだと思います。

この期間を通して、QAエンジニアという職業に対してのイメージもかなり変化しました。参加前は ”テストケースの切り出しをして、それを実装／実行する職業” というようなイメージを持っていたのですが、周りで働いている社員さんを見ると、開発知識・コミュニケーションスキル・言語化スキルなど、テストに縛られない多くの知識とスキルが必要であることを感じました。自分はまだまだ学んでおくべきことが残っている、と実感することができたため、非常に有意義な2ヶ月間でした！

短い間でしたが、本当にお世話になりました。