社内勉強会で自分の番だったので、テストに関して発表した。今いるチームでは単体テスト及び一部の UI テスト (AndroidTest) は書くものの、なんで書くのかという観点が暗黙知のようで、そんなに言語化されていなかったのでひたすら言語化した。
高速な価値提供のための保守性を担保するための一要素であること、運用の複雑さを軽減するために Android アプリでは様々なアーキテクチャが導入されているが、各レイヤーにおける責務がきちんと働いているかを担保することで改修を容易にする、テストコードは過度な共通化を避けてシンプルにする、テストケースはドキュメントとしても機能する、みたいなのを詰め込んだ。なので極論運用が発生しなければテスト意識せずにがーっと設計してアプリケーションコード書くかもなと思いつつ、果たして今後今の時代にそんな機会があるのか。
UI のテストに関しては運用と安定性のコストが〜みたいなのも最近は VRT だったり、MagicPod のような自動テストサービスの導入により格段に運用コストは減っている (お金以外)。ただ現状は QA チーム内で改善が進められている状態で、もう少しリグレッションテストや機能テストの前の段階に低コストで持ってこれないかなと考えている。品質保証は巡り巡って結局自分にふりかかるので、ソフトウェアエンジニア側からのアプローチもしたいものの片手間ではできないので困っている。