こんにちは、QAエンジニアの@tyngwです。
下記の記事では、スタディサプリ for SCHOOLのFlutterリプレースプロジェクトについて紹介しました。
Flutterは単一のコードベースでマルチプラットフォームに対応するアプリを開発できるフレームワークです。この特性により、以下のような課題を解決する手段として選定されました。
テストにおいても、単一コードベースの特性を活かし効率化を図ることが可能ですが、注意すべき点も存在します。この記事では、リプレースプロジェクトにおけるテストの進め方と、そこで得られた気づきについて紹介します。
リプレースの流れ
Flutterへのリプレースは、次の順序で進められました。
私がプロジェクトにジョインしたのは、iOSリプレースに着手するタイミングでした。iOSリプレースのテストを検討するにあたり、まずはAndroidリプレース時のテスト内容や不具合傾向を把握する必要がありました。 そこではじめにAndroidリプレースの不具合分析と、テスト成果物のリバースモデリングに取り組みました。
Androidリプレースの不具合分析とテスト成果物のリバースモデリング
Flutterの単一コードベースの特性を踏まえると、ビジネスロジックはプラットフォーム間で差分がないことが期待されます。 一方で、Androidリプレース時の不具合の傾向を見ると、Flutter化以前のバージョン（Androidネイティブ）との仕様差分が複数検知されていました。このことから、ドキュメントに仕様として明示されていない部分が存在することが明らかになったのです。
そのため、iOSについても同様に仕様として明示されていない部分が実装から漏れる可能性があったので、iOSでもFlutter化以前のバージョン（iOSネイティブ）との比較検証が必要であると考えました。
また、Androidリプレース時のテスト成果物のリバースモデリングを実施した結果、明示されている要件の一部がテストケースに反映されていないことが判明しました。
そのまま流用した場合、こういった問題に気づくことは難しいでしょう。しかし、リバースモデリングを行うことで、本来テストが必要な要件の漏れを明らかにすることができました。
iOSリプレースにおけるテストの考慮事項と優先度
リプレースプロジェクトは、負債解消枠で進める必要がありました。そのため、ある程度の期間を見込んで計画的にテストを進める必要がありました。
そこで、前述した不具合分析結果やリバースモデリングの結果、そしてFlutterの特性を考慮した上でテストの優先度を決定しました。
具体的には、以下のような内容を優先的にテストすることにしました。
- 各OS固有の実装や、OSに依存する機能
- 文字入力の操作や、選択フォーム、カレンダなどユーザからの入力操作を伴う部分
- カメラ機能
- ファイルを開く機能
- PUSH通知
- Androidで確認が不十分だった要件を含む機能のテスト
iOSリプレースのテストで得られた気づき
iOS版リプレースプロジェクトのテストから、以下のような気づきを得ることができました。
- 条件に応じて表示を出し分ける1ふるまいについては、iOSとAndroidでの差分はなく、テストを削減できることがテスト結果からも明確になった
- Flutter化以前のバージョンにおいてiOSとAndroid間で意図しない仕様差分が発覚した
まず、1点目の条件に応じて表示を出し分ける処理については、OS固有の実装を行なっていないため、Flutterの特性を考慮しても違和感のない結果といえます。 ただし、アプリ毎にOS固有の実装をしている箇所は異なると思うので、いずれかのOSのみで確認するようにテストを削減する場合は、開発者とコミュニケーションを取りながら進めるのが良いと思います。
2点目のiOSとAndroid間で発覚した仕様差分についてはFlutter固有の話ではありませんが、iOSとAndroidで個々に開発をしていた場合、UIコンポーネントの挙動などで意図せず差分が発生してしまうこともあるので、注意して確認する必要があるポイントだと思いました。 これは、Flutterに統一される過程で「比較する」という視点が生まれることで、気づけたことだと思います。
Webリプレースにおけるテストの考慮事項と優先度
Web版においては、モバイル版と比較すると実装されていない機能が多い状況でした。Flutter Webへのリプレースはそういった差分を解消して共通の体験をユーザに届ける目的がありました。
また、iOS/Androidのリプレースにおいて、すでにビジネスロジックのテストは実施済みで、プラットフォーム毎の差分が発生する可能性は低かったです。そのため、Web版のリプレースにおけるテストは、主に次の内容を優先的に実施することにしました。
Webリプレースのテストで得られた気づき
blog.studysapuri.jp 上記の記事でも述べられている通り、Flutter Webではフォントやアイコンの表示に関する問題が頻繁に発生していました。 また、モバイルブラウザ、とくにiOS/SafariにおいてはOSバージョンによっても表示が異なる事象が発生していました。そのため、Flutter WebのテストではOSバージョンを考慮する必要があることが学びでした。
おわりに
過去の不具合情報を活用したり、Flutterの特性を考慮することで、リスクの高い部分を優先的にテストするためのアプローチをご紹介しました。 Flutterへのリプレースを検討されている方、そのテストを担当される方にとって、少しでも参考になれば幸いです。
English Version 2
Hello. This is @tyngw as a QA engineer. The following blog describes the Flutter replacement project for “スタディサプリ for SCHOOL”.
Flutter is a framework which develops applications supporting multiple platforms. Considering the benefit, we chose this framework to resolve the following issues:
- Hiring mobile engineers is not that easy
- Difficulty to absorb gaps in specification between iOS and Android
Since the application uses a single codebase, the number of test cases can be optimized. However, there are still several considerations to keep in mind. In this article, we’ll walk you through how we approached testing the project and share key realizations we had along the way.
Flow of the Replacement
The flow of the replacement is as follows;
The timing that I joined was when the replacement of the iOS application was on going. To create test plans and cases, I had to know how the Android application was tested, its defects found, and their trend. So I started with the defect analysis as well as reverse modeling of the test artifacts.
Defect Analysis for the Android Application and Reverse Modeling of the Test Artifacts
Since Flutter is a single code base framework supporting multiple platforms, business logic of the applications shouldn’t have any difference for each platform. But when I saw the trend of the defects, there were some discrepancies in the specs between the previous version of the Android native application and the one with Flutter. This shows that there are some implicit specifications which are not written in any documentation. So, since there’s a risk that the same implicit specification may be missed for the iOS application as well, I considered that comparison in behavior between the previous iOS application and the new version with Flutter is necessary. Plus, as a result of the reverse modeling for test artifacts created in the Android application replacement project, I found that even some explicit requirements were not included in the test case. But this could be found by reverse modeling. If this insufficient test case document was used for the other project without the reverse modeling, the defects in the test document couldn’t have been detected.
What Should Be Considered and Priority for the iOS Application Replacement
We had to consider the technical debt remediation budget, so we anticipated that it would take a significant amount of time and require a well-structured plan. We prioritized testing based on the results of defect analysis, reverse modeling, and the characteristics of Flutter. In detail, we put priority on the following items.
- OS specific implementations and OS dependent features
- Components were user will operate e.g. text areas, select boxes, calendars
- Camera features
- Features which handle files
- Push notifications
- Test against the features which were not tested for the Android application
Realizations During the iOS Application Replacement Project in Test
I realized the following items during iOS application replacement project in test: - There are no discrepancies between iOS and Android in behavior which returns results to users according to the users’ input1. So we can reduce test cost by the test result. - There are some gaps in specification between the previous Android v.s. the new iOS and Android.
For the first one, it’s not weird because no OS specific implementation was made. But if there’s any, it has to be tested so if you want to limit test target OSes, you should carefully communicate with developers to confirm this. For the second one, they are not Flutter specific findings but if the developers who develop the previous Android application and the ones who develop the new iOS application are different, discrepancies in UI component behavior can be implemented. So it has to thoroughly be tested. This defect could be detected because we could realize that we have to compare the behavior between the previous and new applications during the Flutter migration project.
Test View Points and the Priority for the Web Application Replacement
For the web version, it had far less features implemented than mobile versions. So during the migration, we had to implement the missing features to improve user experience. And, since all the business logics were tested during iOS/Android replacement, there was less possibility that interoperability issues happened. So, the following items were prioritized for the web version.
- Browser specific operation
- Visit URL by putting URL directly to the address bar
- Back and forward buttons operations
- Cross-browser/device (Interoperability) test
- Comparison in behavior with mobile versions
Realizations for Web Application Replacement
As described in the article above, many issues happened related to icons and photos on the Flutter web version. And some issues on mobile browsers, specially on iOS/Safari occurred depending on the versions. So the combinations with OS versions have to be considered as well.
Conclusion
In this article, I explained some test approaches like referring to test artifacts from the previous test projects and prioritizing high risk areas considering characteristics of Flutter. I hope this would be informative for any test engineer who’s in charge of any Flutter replacement project.
以下，是这篇博客的中文版本 2
大家好，我是QA工程师@tyngw。
在下面的文章中，介绍了Study Sapuri for SCHOOL的Flutter迁移项目。
Flutter是一个可以用单一代码库来开发多平台应用的框架。由于这一特性，它被用作以下问题的解决方案：
在测试中，也可以利用这一个单一代码库的特性来提高效率，但也存在需要注意的地方。本文将介绍这个迁移项目中的测试方法及获得的发现。
迁移的流程
Flutter的迁移按以下顺序进行：
我加入项目时，正是开始iOS迁移的时候。为了讨论iOS迁移所需要的测试，首先需要了解Android迁移时的测试内容和Bug的趋势。 因此，首先进行了Android迁移的Bug分析和测试成果的逆向建模。
Android迁移的Bug分析和测试成果的逆向建模
考虑到Flutter的单一代码库特性，业务逻辑在不同平台间应该没有差异。 然而，查看Android迁移时的Bug趋势，发现了多个与Flutter化之前版本（Android Native）的式样差异。这表明，实际存在着文档中未明确的部分式样。
因此，iOS也可能存在未明确为式样的部分，然后这部分没有被搭载的可能性，因此我们认为有必要对iOS进行与Flutter化之前版本（iOS Native）的比较测试。
此外，通过对Android迁移时的测试成果进行逆向建模，发现部分明确的需求未反映在测试用例中。
如果直接沿用的话，很难发现这些问题。然而，通过进行逆向建模，可以发现本应进行测试的需求的遗漏。
iOS迁移测试相关的考虑事项和优先级
迁移项目需要同时解决一些已有的问题。因此，需要在一定的时间内，有计划性地推进测试。
因此，基于前述的Bug分析和逆向建模结果，并且考虑Flutter的特性，我们决定了测试的优先级。
具体来说，优先进行以下内容的测试：
- 各OS特有的实现或依赖于OS的功能
- 用户输入操作相关的部分，如文字输入操作、选择表单、日历等
- 相机功能
- 打开文件的功能
- PUSH通知
- 在Android测试中，测试不充分的部分功能测试
iOS迁移测试的收获
iOS版迁移项目测试中有以下的收获：
首先，根据不同条件显示不同内容的动作，由于没有进行OS特有的开发，考虑到Flutter的特性，这是可以理解的结果。 不过，由于每个应用在OS特有的实现上有所不同，如果想仅在某个OS上进行测试，以减少测试量时，需要与开发者沟通或根据测试结果进行判断。
第二点关于iOS和Android之间发现的式样差异，这不是Flutter特有的问题，但在iOS和Android分别开发时，UI组件的行为等可能会产生差异，因此需要注意确认。 这是在统一迁移到Flutter的过程中，通过"对比"iOS和Android而注意到的问题。
Web迁移测试相关的考虑事项和优先级
在原本的Web版上，与移动版相比，未实现的功能较多。Flutter Web的迁移旨在消除这些差异，为用户提供统一的体验。
此外，在iOS/Android的迁移中，业务逻辑的测试已经完成，平台间发生差异的可能性较低。因此，Web版迁移的测试中对以下内容进行了优先测试：
- 浏览器特有的操作
- 直接跳转URL
- 浏览器后退、前进等操作
- 跨浏览器、跨设备测试
- 与移动版的功能差异确认
Web迁移测试的收获
blog.studysapuri.jp 如这篇Blog所述、Flutter Web中频繁出现字体和图标显示问题。 此外，在移动浏览器，特别是iOS/Safari中，OS版本不同也会导致显示不同的现象。因此，Flutter Web的测试需要考虑OS版本。
结束语
我们介绍了，通过利用过去的Bug信息和考虑Flutter的特性，来对高风险部分进行优先测试的方法。 希望对考虑迁移到Flutter的人和负责测试的人能有所帮助。
- たとえば、クライアントアプリからサーバサイドにAPIリクエストを行い、返却された結果に基づいて表示を切り替えるふるまい / e.g. Behavior which switches UI shown according to response from API by request from client application. / 例如，从客户端应用向服务器端发送API请求，并根据返回的结果切换显示的行为↩
- 翻訳版は同僚のQAエンジニアに実施してもらいました。この場を借りてお礼申し上げます。 / My colleagues, QA engineers, translated this blog for me. I would like to express my appreciation for their support. / 我的同事，一位质量保证工程师，帮我翻译了这篇博客。感谢他们的支持。↩
