こんにちは。メルカリのAutomation & QAグループ(通称:AQA)でAutomationエンジニアをぶりぶりしている@gloriaです。現在、私は主にiOSアプリの自動化を担当しています(詳細はtadashi0713によるこちらの記事をご覧ください)。
私は先月、ロンドンで開催された「ISTQB Advanced Level – Test Automation Engineer Certification」のトレーニングコースに参加しました。
* なお、この記事は、@gloriaの原文(英語)を意訳しております。原文はこの記事の下部にありますのであわせてお楽しみください。
ISTQBとは?
この認定テストはISTQB Foundation Levelの延長線上にあるもので、ソフトウェアテストと品質保証の国際的なガイドラインを提供するものです。ISTQB認定テストは、81の国々で実施されており、6つの Foundation Level と5つの Advanced Level、さらに2つの Expert Levelがあります。この認定テストはQAエンジニアやQAマネージャ向けのものともいえますが、最近ではサイバーセキュリティ、自動化といった特別な領域で活躍する人たち向けの認定テストも増えてきています。いくつかの認定テスト(Foundation Level、Advanced – Test Manager、Advanced – Test Analyst)は日本語に翻訳されているため、日本でも同様のテストを受けられます。
今回私が受験した「ISTQB Advanced Level – Test Automation Engineer」は、2016年11月に作成されたばかりのとても新しい認定試験です。日本ではまだ受験できないため、ロンドンへと向かい、3日間のトレーニングコースを受けたあと、4日目にテストを受験しました。
トレーニングコースの教材を見ると8つの章に分かれているのがわかります。
- イントロダクション&このコースの狙い
- テスト自動化の目的
- テスト自動化における成功要因
- テスト自動化の準備
- 自動化ツールの評価と選択
- テストや自動化のしやすさを考えたソフトウェアデザイン
- テスト自動化のアーキテクチャ
- デプロイ時のリスクや不測の事態について
- パイロットプロジェクト
- デプロイ
- リスク判断とリスクの緩和戦略
- テスト自動化のレポーティングとメトリクス
- メトリクスの選択
- ロギングとレポーティング
- マニュアルテストから自動テスト環境への遷移
- 自動化の基準
- レグレッションテスト
- 新しい機能のテスト
- バグフィックスのためのテスト
- テスト実行や自動テストのメンテナンス
- テスト自動化のための継続的な改善
8つの章を見ればわかるように、このトレーニングコースでは、ソフトウェア開発やそのテストプロセスでの自動化の役割に焦点を当てています。トレーニングコースの参加者を見てみると、QA/DEVマネージャ、フリーランスの自動化エンジニア、自動化に興味のあるソフトウェアエンジニアやQAエンジニアがほとんどでした。トレーニングコースのシラバスは、マニュアルテストから自動化への遷移といったトピックをカバーしています。よって、ほとんどのテストがマニュアルで、自動テストを全く導入していない会社で働いている方にとっても、とても役立つ情報が提供されています。参加者はこのコースで紹介されるガイドラインやベストプラクティスといった知識をまず得て、スクラッチの状態から自動化をはじめることができます。さらに、自動化の導入当初から、世界基準の方法で洗練され、さらに自分たちにフィットするプロセスになっていくのです。
なぜ「ISTQB Advanced Level – Test Automation Engineer」なのか?
テスト自動化に関する認定試験は、このISTQB以外には存在しないため、このトレーニングに興味を持ちました。はじめは自動化に特化したツールの説明や自動化技術がコースで紹介されるのなかと思っていましたが、そうではなく、このコースでは自動化やチームのプロセスについて新しい考え方を学べます。私はマネージャではないのですが、メルカリはすでに広範囲で自動化を進めています。メルカリがグローバルカンパニーに発展するにつれ、同様にグローバルスタンダードなプロセスが重要になってくるはずです。
この記事では、私が学んできた内容の中で、特に印象に残った点をいくつかご紹介させていただきます。
ひとつめ: 自動化の成功要因
ISTQBでは、自動化チームの成功を導く4つの要因が紹介されています。ひとつめは、自動化チームがプロダクトチームと一緒に働くことです。これはとても重要です。自動化エンジニアは、技術スタックを最新にしたり、お互いの職務や責任を深く学んだり理解したりするために、開発者と一緒に働くべきでしょう(プロダクトコードやテストコードのレビューをお互いにするのも大切ですね)。また、自動化エンジニアはプロダクトに関係するステークホルダー、たとえばQAエンジニア、プロデューサーとも連携して作業をする必要があります。これによって、自動化によって高い優先順位の機能をカバーしたり、その機能を特定できたりするからです。
ふたつめの成功要因は、ソフトウェアのテストしやすさです。なかには、自動化しにくいソフトウェアも存在します(たとえば、UIとそのIDやラベルがダイナミックに生成され、さらにどこに配置されるかわかりにくくなっているケース)。ほかにも、自動化しやすいソフトウェアが開発されるように、開発者の近くで働く必要があります。
3つめの成功要因は、自動化チームはテスト自動化戦略をもつべきであること。そして最後の成功要因は、そのための自動化フレームワークを用意することです。テスト自動化戦略とは、自動化のコスト、リターンやリスクを正しく考えることです。そして、自動化を始める前に、プロダクトに関係するステークホルダーと自動化のスコープを決めていきます。自動化フレームワークは、トラブルシューティングに役立ち、しっかりドキュメンテーションされていて、最新の状態を保たれており、メンテナンスが容易に運用でき、十分なレポーティング機能を兼ね揃えたものが望ましいです。
ISTQBによると、成功する自動化チームは、QAエンジニアや開発者の近くで働くチームです。ソフトウェア開発のライフサイクルの観点から考えると、従来型の場合、以下のようなモデルになっていると思います。
このような従来型のソフトウェア開発のライフサイクルモデルの場合、開発者とQAエンジニアはともに近くで働く形になります。しかしながら、ISTQBのモデルの場合、自動化エンジニアは、完全に別れたライフサイクルになっており、開発者やQAエンジニアとシンクしていきます。2つのグループが一緒に働きながら、可能な限りベストなプロダクトを開発していくのです。
ふたつめ: 自動化への移行
ISTQB は自動化に関係する基礎をきちんと構築し、はじめから正しいプロセスで進めることを推奨しています。なぜなら、あとになって正しいプロセスに修正するのがとてもむずかしいからです。それゆえに、企業がマニュアルテストから自動テストに移っていく前に、企業内のQAプロセスを醸成する必要があるのです。自動化をはじめるまえに、最新のテストケース、テストデータ、リリースプロセスが必要なのです。もしQAプロセスがあいまいであったり、しっかりと決まっていない場合は、自動チームをプロジェクトに投入することにより、プロジェクトがとても乱雑な状況に陥ってしまうでしょう。
QAプロセスが自動化準備OKになった場合、自動化専用チームが組織され(メルカリのAQAもそうなっています)、自動化のスコープやレポート要件などを決定していきます。自動化ツールの選定もしなければなりません。そして、自動化チームは開発チームとともに働きながら、自動化の活動を通して、テストしやすいソフトウェアを開発していきます。最後に、自動化に関連する役割や責任も決める必要があります(たとえば、誰がテストケースをメンテナンスするのか、誰がいつ自動テストを実行するのか、誰が日々のレポートを確認するのかなど)。さらにそこから、自動化に関係するQAエンジニアにトレーニングを提供する必要もでてくるでしょう。なぜなら、ISTQBでは、自動化エンジニアに対して、QAエンジニアというよりも、開発者としてみなしており、自動化を学びたいQAエンジニアであれば、基本的なソフトウェア開発の原則(アルゴリズム、ソフトウェアアーキテクチャなど)をも学ぶ必要があるからです。ソフトウェアコードの品質に対する、自動化されたテストコードの品質も保証するためには、プログラミングスキルも必要になってきます。
自動化の未来をのぞいてみよう!
トレーニングコースでとても興味深いトピックがありました。それは、「モデルベーステスティング」と呼ばれる自動化の方法論です。この自動化のための「型」は、複雑なAIモデルやアルゴリズムによって、自動テストを自動生成するいうものです。AIが「自動的に」「自動テスト」を作るようになるのです!自動化エンジニアは、新しくテストケースを作り、機能のためにカバレッジをあげていく作業に、たくさんの時間を費やされます。しかし、AIの手助けにより、すべての作業が自動的に完了するので、自分たちの時間を調査や新しいツールの開発に使うことができるようになります。残念ながら、このアイデアは現在まだ検討段階なのですが、あと数年で自動化の中でも大きな役割を担うことになるように思います。とても楽しみですね!
おわりに
今回このトレーニングコースによって、すばらしい学びの経験を得ることができ、ヨーロッパのITプロフェッショナルとの交流もできたので、とてもうれしく思っています。
日本国内ではまだ取得できない認定テストですが、現在はアメリカ、ヨーロッパ、オーストラリアで受講可能です。そして、マネージャであれ、開発者であれ、QAエンジニア、自動化エンジニア問わず、とても役立つ内容になっています。自動化に関するグローバルな視点を学びたいと思う方であれば、このトレーニングコースは非常にお薦めです。
PS・・・テストや自動化の話をカジュアルにできるようにFacebookグループ Agile Testing, Automation and QAの現場 を作ってみました。もしご興味があれば、ぜひ遊びにきてください!
Original Text
Hello. This is @gloria, an Automation Engineer from Mercari’s Automation & Quality Assurance Group (shortened to AQA). I mostly work on automation for Mercari’s iOS app (which was summarized the other day in this great article by tadashi0713).
Last month, I went to London, UK to attend a workshop for the ISTQB Advanced Level – Test Automation Engineer certification.
What is ISTQB?
This certification is an extension of the ISTQB Foundation Level certification, which provides international guidelines for software testing and quality assurance. ISTQB certification is recognized in 81 different countries, with 6 foundation-level, 5 advanced-level, and 2 expert-level certifications. Although this certification was originally intended for QA Engineers and QA managers, they have branched out in recent years to include certifications that are of interest to professionals working in other areas such as cybersecurity and automation. Several certifications have been translated and can be taken in Japan as well, including Foundation Level, Advanced – Test Manager, and Advanced – Test Analyst.
The ISTQB Advanced Level – Test Automation Engineer certification is a fairly new certification (created in November 2016). It is not yet available in Japan so I flew to London, UK to attend a 3-day training course before taking my exam on the 4th day.
The course material was split into 8 chapters:
- Introduction and Objectives
- Purpose of Test Automation
- Success Factors in Test Automation
- Preparing for Test Automation
- Tool Evaluation and Selection
- Designing Software for Testability and Automation
- Test Automation Architecture
- Deployment Risks and Contingencies
- Pilot Projects
- Deployment
- Risk Assessment and Mitigation Strategies
- Test Automation Reporting and Metrics
- Metric Selection
- Logging and Reporting
- Transitioning Manual Testing to an Automated Environment
- Criteria for Automation
- Regression Testing
- New Feature Testing
- Bug Fix Testing
- Testing and Maintaining Automated Tests
- Continuously Improving the Test Automation
As you can see, the course mainly focuses on the role of automation within the software development and testing process. As such, the participants in the course were mostly QA/Dev managers, freelance automation engineers, and developers and QA who are interested in automation. The course syllabus covers topics like transitioning from manual testing to automation, so it is particularly useful for people who work in companies where all testing is done manually and there is no automation yet. With the knowledge gained from the course, they can begin to build their automation from scratch following the given guidelines and best practices so that their processes can be clean and fit to global standard from the beginning.
Why ISTQB Advanced – Test Automation Engineer?
Initially, this course interested me because there are no other certifications relating to test automation. Although I wish that the course focused more on teaching specific tools and technologies, this course taught a new way of thinking about automation and team processes. Even though I am not a manager and Mercari already has an extensive automation setup in place, I feel that as we become a bigger global company, it is important to make sure that our processes follow global standards as well. That was my motivation for taking this certification.
In this article, I would like to introduce a topic that particularly stood out to me among the many things that I learned.
Point 1: Success Factors of Automation
According to ISTQB, there are four factors that lead to a successful automation team. First, it is very important for the automation team to work directly with the product team itself. Automation engineers should work with developers to ensure that their technology stack is up to date and to encourage mutual learning and understanding of each other’s duties (it is even beneficial to sometimes have regular developers review automation code and vice versa). Automation engineers should also work with product stakeholders, such as QA and producers, to identify the most important, high-priority features that should be covered by automation.
Another success factor is the testability of the software. Sometimes, software is built in a way that makes it difficult to automate (for example, UI elements with dynamically-generated IDs or labels make them difficult to locate). This is another reason why automation engineers need to work closely with developers, to ensure that software is built in a way that makes it easy to automate.
Finally, the automation team should have a test automation strategy and a good automation framework. Having a test automation strategy means to properly consider automation costs, benefits, and risks, and to consult product stakeholders to determine the scope before beginning automation. A good automation framework is a framework that is easy to use and troubleshoot, well-documented, up to date, easy to maintain, and adequate in reporting.
According to ISTQB, a successful automation team is a team that works closely with both QA and developers. In terms of the software development life cycle, traditionally, it is often shown as the following model:
In this traditional model of the software development life cycle, the cycles of Development and QA are synced so that they can work closely together. However, in ISTQB’s model, Automation is shown as a separate entity with its cycle synced to the cycles of both Developers and QA. In this model, all three groups are working together to build the best product possible.
Point 2: Transitioning to Automation
ISTQB recommends laying down a good foundation and starting with the proper processes from the beginning because it is more difficult to correct processes later on. Therefore, before a company moves from all manual testing to automation, there are several points to consider. First, the company’s QA processes should be mature. Before automation begins, there needs to be a set of up-to-date test cases, test data, and release processes. If the QA processes are vague and not decided, things will become more messy by adding the additional automation team into the project.
If the QA processes are deemed as ready for automation, a separate development team dedicated to automation (just like Mercari’s Automation Team) should be created and the scope of automation, reporting requirements, and other details should be determined. Tools should be decided on, and the automation team should work with the development team to ensure that the software is easily testable through automation. Finally, the roles and responsibilities relating to automation (for example, who will maintain the test cases, who will execute the automation and when, who will look at the daily reports, etc.) need to be decided, and then training needs to be given to the QA who will be involved in automation. Because ISTQB views automation engineers as developers rather than QA, it suggests that QA who want to learn automation should also be trained in basic software engineering principles (for example, algorithms and software architecture) in addition to programming, to ensure that the quality of the automation code is on par with the quality of the software code.
Looking Towards the Future of Automation
One topic that really interested me in the course was an automation method called “model-based testing”. In this form of automation, automated tests are automatically generated using complex AI models and algorithms- in other words, we can use AI to “automate the creation of automation”. As Automation Engineers, a large part of our time is spent on creating new test cases and measuring coverage for features but with the help of AI, this can all be done automatically so that we will have more time to work on research and development of new tools instead. Unfortunately, this form of automation is still currently under research but it is expected to play a big role in the automation field within the next few years so I am looking forward to it.
Endnote
I am glad that I was able to take this certification because it was a great learning experience and I had the chance to speak with IT professionals working in Europe.
Although this certification is not yet available in Japan, it is currently available in America, Europe, and Australia, and I would highly recommend it to people who are interested in learning about the global perspective on automation. I believe this certification will be useful to managers and people who work with automation (regardless of whether they are developers, QA, or automation engineers).