# タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、旧エンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることをお話しします。 毎日、お昼の12時30分に配信しています。 ゲストの方や、リツナーのあなたと、 テストや品質の世界を広げていきます。 # Androidテストのツラミ… こんにちは。Qエンジニアのさみひです。 今回はゲストトークということで、 Androidテストのつらみについて話していこうと思います。 今回のゲストはAndroidエンジニアのおはぎさんです。 よろしくお願いします。 ということで、まず最初に簡単に自己紹介をお願いします。 はい。おはぎと申します。 さみひさんと同じVoicyという会社でAndroidエンジニアとして働いています。 よろしくお願いします。 おはぎさんもVoicyチャンネルをやっていますよね。 はい。 ちょっと便乗している感じになりますけど、 おはぎのたなごたラジオというめちゃくちゃ緩い放送をやっているので、 よろしければ聞いてみてください。 この放送の概要欄にリンクがありますので、そこから見てください。 ということで、やっぱりAndroidテストのつらみといえば、 端末が多すぎる問題が一番最初かなと出てくるかなと思っていて、 端末によって動きが違う?変わってきちゃう?表示が変わってくるんですかね? そうですね。 基本的なアプリの動きとかは基本的には同じなんですけど、 例えばアプリの上の部分とか、電池の見え方とか微妙に違ったりとか分かりやすいかなと思うんですけど、 あと下の方もピクセルとかだと結構iPhoneに近いような見た目。 ちょっと黒い棒があるみたいな感じ。 それボタンに切り替えれば設定できるんですけど、 他のOSとちょっと違ったりとか、アプリはそれくらい。 アプリの外が結構違ったりしていて、数値の見え方とか、 あとフォームのアプリの並び方とか、 フォーム画面、OSも多分iOSも一緒なんですけど、 アプリのアイコンがたくさん並んでいるところがあるじゃないですか。 そこがちょっと違ったりとかですね。 それは結構違ったりするかもしれないです。 アプリの設定とかたまに開かなくちゃいけないことあると思うんですけど、 それもOSというか、ピクセルとサムズのギャラクシーとかだと全然違ったりとかするので、 結構バリエーションもあるかもしれないですね。 iOSだと基本的にアップルが作っているiPhoneとかiPadとか、 基本iPhone、iPhoneの中で種類がいくつかあるけどっていうので、 基本の見た目とかある程度揃っているんだけれど、 Androidの場合は端末を作っているメーカーが結構いろいろなバリエーションがあるから、 その会社によってマイクスペリアとかサムズの携帯とかで挙動が変わってくる。 挙動が、さっき言ったような違いが出てくるということなんですよね。 そうですね。 一言でAndroidってまとめちゃいけないですかね。 まとめても大丈夫だと思いますけどね。 本来は良さそう。 本来は良さそう。 ただ結構最近の面見れると、オルダブル端末。 折れるやつですね。 あれはちょっとしんどくって、今までだとダークモードとかオンにするとちょっと壊れるとかっていうやつがあったんですけど、 正直それがやったら許容できなくもないじゃないですか。 表示の問題というか。 極論タスク切りすら戻るし、そんなに頻度も多くないはずなんで許せそうな気がするんですけど、 オルダブル端末の場合、盛り畳みでそれと同じような構成変更っていうんですけど、 構成変更かな。 英語でコンフィギュエーションチェンジって言うんですけど、 それがパカパカすると起きるんで、そのためにレイヤード壊れるとかあるのが、 本来壊れない実装すべきなんですけど、ここ最近のつらみだなって思ってます。 折り畳んだり開いたりするタイミングで構成、画面のサイズみたいなところ、 サイズっていうかレイヤードとかが変わるからそれに応じて画面を表示させないといけないんだけど、 そこが難しいというか、きりパカパカするとおかしくなるんですよ。 画面の表示自体はあんま壊れないはずなんですけど、 データをどう保持しておくかみたいなので、 それでなくなっちゃうデータの持ち方で書かれたりすることも結構あって、 それがつらみですね。 たぶんそのつらみはどんどん増してきそうな雰囲気を感じてます。 またいろんな端末があるからどうですか? それもそうなんですけど、 たぶんGoogle的にはタブレットみたいなやつも使ってほしいんだろうなって雰囲気を感じていて、 できるだけ自由な画面のサイズとかで開いてほしい。 今もAndroidでアイコン長押しとかすると実は画面分割ができて、 一つの画面上で二つ開けたりするんですけど、 あれも画面のサイズ変えるたびに構成変更が起きるので、 あんまり大きい声じゃ言えないですけど、 世の中のアプリは結構それで壊れたりするものもあったりします。 壊れるっていうのはさっき言ったみたいなデータが保持されてたのが保持されてなかったりとか。 なくなったりとかクラッシュしたりとかも。 ああそうなんですね。 確かにオットのがAndroidで確かに画面分割とかしてやってたんで、 それでボイスのアプリとか開けるとどうなるんだろうってちょっと怖いですね。 怖いですね。 最大ボイスの場合結構画面がしかし触れるというよりは、 放置していくことが多い気がするんで、 そこはもし動画見るアプリとかでちょっと上で動画開きっぱなしとかにしたいとかっていうやつだったらちょっとしんどいですけど、 幸いそういう使い方もしないと思うんで、 そこはバックグラウンドで使ってくださいっていう感じですね。 ありがとうございます。 ちょっと切り替えがいいのでチャプター切り替えます。 # 続き 次のつらみに行こうかなと思います。 個人的にはですね、最近の社内のAndroidユーザーの人がすごく減っちゃってて。 減っちゃったんですね。 減ってる感じしません? 減ったというか、いないって感じですね。 なので、ちょっと不具合じゃないとか、新しい機能のドックフルーティングとか、社員だけ使えるようにしてたりするじゃないですか。 その中でフィードバックが少なかったりっていうのが、つらみ。 そうですね。今もちょうど新しい機能をゴリゴリ作っている最中で、 結構社員に機能公開してドックフルーティングしてもらったりとかやってるんですけど、 iOSは結構バグ報告というか、これどうなの?みたいな質問が結構上がってきたりするんですけど、 Androidはあんまり上がってはなくて、 かといって、じゃあAndroidはバグがないのかっていうと、全くそんな気はしなくて、 むしろ不安が募ってくるみたいな。 私もiPhoneなんで、そうなんですよ。 会社に検証端末あるから、それでネットワークだけあれば使えるんですけど、 あれかな、モバイルWi-Fiみたいなのをつないでおけば、 通勤中とかでも聞いたりとかできるのかなとか思いつつ、そうなんですよ。 ちょっとしたプチプチつらみですから。 あとは次行きます。OSのバージャンプとか、ライブラリのバージャンプの時にどこまでテストするのか問題ですよね。 これ難しいですよね。 結局端末応水問題につながるのかなという感じです。 Webアプリでも、iOSとかOSとかでも結局あって、OSのバージャンプとかライブラリのバージャンプあって、 基本的にはこの辺が変わります。 その変更ないのを見て、あと修正、今回こういう修正を加えたからこの辺影響ありそうですっていうので、 影響ありそうな機能のテスト、リグレーションテストと、 あと場合によってはもうちょっと全体的な基本機能確認するっていうテストをやるっていうのが、 そのプラスが大体こういうバージャンプ系ってやってるんですけど、 Androidの場合だとやっぱり端末応水問題と絡んで、 特に何でしたっけ、エッジとエッジみたいなその画面の端っこの表示の仕方というか、 サイズ表示の仕方とかで差分があるから全部拾い切れない、 不甲斐は全然拾い切れないっていうのが問題なんです。 どうですか、Androidの開発目線で。 Android、Android限らずOSとかライブラリバージャンプは大変だなっていうのはあるんですけど、 うーん、そうですね。 開発者目線で貫いてありますか。 よくあるのって言うと1個バージョン上がるだけだと結構サポート手厚いというか、 ここ変わったんでのダメを見ればOKなんですけど、 2つ3つ積み重なっていくと、 動かなくなっちゃうというかビルドできなくなっちゃうとか結構あるので、 1個1個上げていくとこれは今後なくなるので消してくださいとかあるんですけど、 一気に上げると名前とかも変わってて、 これ同じものに相当するのは何なんだろうとか調べなくちゃいけない。 それが結構しんどいはしんどいですけど、 じゃあちょっとずつアップデートしていくってなかなか難しいですね。 1個しないっていうのが選択肢になることあると思うんですけど、 アップデートしない。 アップデートしないっていうのは選択肢になるかもしれないですけど、 我々のiOSもそうなんですけど、 基本的にはストアにばら撒いてもらわなくちゃいけないっていうのがあって、 ストアがばら撒きたくないって思われちゃったらもう終わりなんですね。 結構ばら撒くというか配布する要件として、 最新のライブラリー使ってくださいみたいなのが年単位とかで降ってくるので、 本当に常に最新をできるだけ追っかけていかないと、 しんどいなって思いますね。 なるほど。 で、こまめに上げるってなると、 じゃあリグレッションテストどうするんだみたいな話になったりもして、 そことコースターとの兼ね合いみたいなところもありますよね。 あとこの間の勉強会、 APIUMの勉強会とアンドロイドかけるテスト設計みたいな勉強会行ったんですけど、 その中でどっかの会社さんは結構ライブラリーとかこまめにアップデートしてるって話がしてた。 あれはアンドロイドかけるテスト設計なんですかね。 あれは本当にすごいなって思ったりとか。 署名出してるかわかんないですけど、 某企業では、 企業であるってことは言っちゃいますけど、 某企業では、 コトリンとかも今我々使ってるものはそんな新しくないんですけど、 最新のステイブルどころかアルファ版とかも使ってるし、 本当キャッチアップ力がすごいなって思いますね。 アルファ版とかだと自分たちがやり方が悪いんじゃないか以上に、 そのライブラリーとかちゃんと動くんだっけとかも一個疑う論点になってくるんで、 難易度高いなと。 そうですね。アルファ版だとちゃんと動かなくてもごめんねってヘペロみたいな。 アルファ版だし。 それを使うのも確かに勇気とリスクをもんでって感じですかね。 あとどうしようかな、最後一個言うか言わないか迷った。 あと3分しかないから。 去年のキャプチャーを自動化してどんどんキャプチャー撮ってて、 キャプチャーを比較するのを自作した、APIUMを使って自作したって話があって、 あれもすごいなと思ったんですけど、なかなか実用は難しそう。 どうなんですかね、APIUMが既に運用されてる環境だったら、 ついでにやるのにはすごく良さそうだなって思ったんですけど、 それをやるためにAPIUMから組みますかって言うとちょっとコストかなって思いました。 あんまり比較する機会もそんなにないんじゃないかなって思ったんですよね。 頻度で言うとやりたいのってバージャンプ、ライブラリとかのバージャンプの時に大きく崩れてないかっていうのを見たいとは思うけど、 それの頻度と準備するコストっていうところを比較すると確かに見合わないかもしれないですね。 あとはこっそりリファクタリングとかもしたりしてるんですけど、画面。 その場合は自分でスクショ撮って普通に比較、目元で比較しちゃってます。 画面数とかにもよるかもしれないですね。めちゃくちゃ多いのかそうじゃないのかっていうところでも。 ありがとうございます。 ということで今回はアンドロイドテストの辛みについてちょっとお話をしました。 何かありますか? 何か周辺の一言。何も考えてなかった。 自分のチャンネルでもアンドロイドの話まだあんまりできてないので、これからはちょっとずつでもしていこうかなと思ってます。 ぜひ聞いてみてください。 楽しみにしてます。 では今日はここまでです。 ありがとうございました。 # #176のコメント返し😍 コメント開始のコーナーです。今回は176話目のコメントを開始します。 1週間前の176話目では、やったことがないタスクの構成を見積もるコツについてお話をしました。 コメントは2件いただいております。 けんけんさんと、あとひょうじがこななしのぼんべいさんになっているんですけど、 こういうもつやさんですね。コメントありがとうございます。もつやさんは初コメですね。パフパフ。初コメおめでとうございます。 けんけんさんも久しぶりのコメントありがとうございます。 ということで、まず1件目けんけんさんからいきますね。 読むだと不確実性を含んだ見積もりの場合、考数だけが一人歩き言っちゃうと偉い目にあいますよね。 前提条件や考数算出のロジックよりしっかり伝えなきゃです。 というコメントいただいております。ありがとうございます。 そうですよね。特にやったことないこととか、新しい機能を作るときとかもそうですけど、 結構このくらいでいけるでしょうと思ったら全然足りなかったりとか、 なんか逆っていうのはあんまりないのかな。基本的にやっぱり足りないとか、 想定が見積もりが甘かったとか、考慮が漏れているものがいっぱいあったとか、 後からこれもやらなきゃ、これもやらなきゃっていうのが出てきて、 どんどん考数が膨れ上がるっていう方が、膨れ上がっていくっていうのが多いかなとは思いますけれど。 でも、何ですかね、やっぱり段階的に見積もりって1回だけじゃなくて、 順々にっていうのかな、またやっていかないと、 その不確実性が減ってきたタイミングでも1回見積もりをし直して、 どんどん見積もりの精度を上げていくっていうやり方しかないのかなっていうのは、 最近もやもやと考えていたりします。ありがとうございます。 2件目がいもつよさんですね。 本当に偶然ですね、見積もりに対する考え方が近くてよかったですとコメントいただいております。 最初、七代のこんべいさんだったんで、 これはどなたの方が言ってくださったんだろう、リスナーさんの方かなと思っていたんですけど、 まさかのいもつよさんご本人からコメントをいただいていたということで、嬉しかったです。 本当に全然違うことを言っていたら気まずかったかもしれないし、 それはまたそれで違う視点で面白かったかもしれないし、ちょっと分からないですけど、 私は考え方が似ていてとても安心しましたというのが私の感想です。 ということで、コメント開始でした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はですね、有名な本ですね。 ソフトウェアテスト293の鉄則を久しぶりにパラパラと今読んでいるところでして、 その中の一つ鉄則001番、プロジェクトの行く手をたらせについてお話をします。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと思った方はぜひ、 画面右下、ハートマークでいいねを押していただけるとめちゃくちゃ励みになります。 そしてコメントをぜひお待ちしております。 感想を学んだこと、これやってみよう、こういうやり方もあるよ、こう違うんじゃないなどなど、 いろんな角度からのご意見お待ちしております。 それではまた明日お会いしましょう。ごきげんよう。