ヤフーでは開発迅速性と品質のバランスをどう取ってるか を読んだ
素晴らしい取り組みだと思った。
ランクの概念はよく分からなかったが、迅速性と品質に対してメトリクスを取得し、可視化し、総合的な評価ができている点は素晴らしいと思った。
また、評価に応じて改善策が打てるような仕組みを作っている点も踏み出している感があってすごい。こういうことやってみたいよなぁ。
横断的に開発プロセスを改善するって、こういうことなんだなぁ。
「自動End2Endテストを作成する基準ってありますか？」 を読んだ
同意。
加えて、自分だったら以下の観点も追加すると思う：
- 過去に発生した重大な不具合を検証するテスト
- 人手で実行するとコストのかかるテスト（手順が複雑だったり、繰り返し操作を行うものだったり）
- 顧客のニーズが強い機能のテスト（マネーパススイート）
全てをE2Eで網羅しない、というのもその通りで、ユニットテストやAPIテストで動作保証できるものであるならそのようにしたほうがテストの安定性を高められると思う。例えば、ログイン機能に対して「ログインに失敗する」テストを実装する場合を考える。ログインに失敗するパターンはいくつかあると思うのだが（存在しないID、間違ったパスワード、空欄のままログインボタン押下、等）、ログイン失敗した時に表示されるメッセージが同じであるとするならば、１パターンだけE2Eで実施して残りのパターンはAPIテストで実施する、、という戦略もあるかもしれない。
余談だが、E2Eテスト化するかどうかの基準については、以下の書籍にわかりやすくまとめられていた：
ソフトウェア工学の基礎 28 を読んだ（その２）
この書籍は、2021年12月に開催された第28回ソフトウェア工学の基礎ワークショップ （FOSE2021）の予稿集である。
「継続的インテグレーションに影響を及ぼすRinging Test Alarmsに関する実証調査」という論文を読んだ。
Ringing~~って初めて聞いたが、
CI上で同一のテストメソッドが２リビジョン以上連続して失敗している状態をRinging Test Alarms（RTA）と定義する
とのこと。
確かに、CIをやっていると、プロダクトコードにバグがはいったり、テストが古くなったり、あるいはテストのFlakyさに由来してテストが連続で失敗することはある。
本研究では、最終目的として、CIを有効に活用できていない実態とその悪影響を明らかにし、CIを用いた開発におけるガイドラインの整備やアンチパターンの作成を目指す。本稿では、その第一歩として、CI開発を妨げると考えられる”連続してテストが失敗し続けるRinging Test Alarms(RTA)”の現象及び原因について調査を行う
とのこと。
この論文では、調査対象として４つのOSSの開発履歴を分析していた。結果として、
- 全てのプロジェクトでRTAが観測された。ただし、RTAの多寡はプロジェクトによって差がある
- 80%のRTAは3リビジョン以内（日数にすると１日以内）で修正が完了している
- RTAの解消方法としては、プロダクトコードの修正、テストのスキップ（@Ignoreアノテーションの付与）、テストケースの削除などがある
といったことが挙げられていた。
今回はあくまで調査であったのだが、企業での開発でも実際にRTAは発生するし、最終目標が実現されると、僕としてもとても嬉しい。
また、現場あるあるとして「失敗しているのは知っているが修正する時間（タスク的余裕）がないので後回しにしている」という状況もあるため、失敗したテストを自動修正するアイデアがあると嬉しいと思った。
さらに、失敗した時の原因分析（≒プロダクトやテストの修正方針決め）は結構時間と体力を取られることもあるので、これを容易にする方法があると嬉しいなとも思った
。
ソフトウェア工学の基礎 28 を読んだ（その１）
この書籍は、2021年12月に開催された第28回ソフトウェア工学の基礎ワークショップ （FOSE2021）の予稿集である。
久しぶりにソフトウェア工学の論文が読みたくなったのと、最近どんな研究が行われているのか知りたくなったので購入した。
今回読んだのは「ユーザーレビューにおける地域・アプリケーション固有の苦情傾向に関する調査」という論文。
日・英・米３地域で展開しているスマホアプリに投稿されたユーザーレビューを対象に、アプリ固有、地域固有、各評価帯（例：星の数）での苦情の中身を分析したというもの。
分析結果としては
- 低評価では「機能エラー」に関する苦情を抱えたレビューが多く存在する
- 高評価になるほど「機能要求」などの提言となるレビューが増える
が地域共通の苦情の傾向として見られた、とのこと。
また、
- 日英の苦情の書き方は比較的穏当である（「魅力がない」など漠然としたレビューが多い）が、米国では具体的なコメントとその理由が明確に示される傾向があった
- アプリ共通の苦情がある一方、各アプリ固有の苦情の種類もあった
とのこと。
特に自分が面白いと思ったのは、↓↓の結果：
米国向けの場合は機能要求としてチャレンジすることが求められる傾向，日本向けには，「応答しない」や「強制終了」が発生しないように，安定性が求められる傾向があると考えられる．
地域ごとにユーザーが求める品質特性が異なるということだと思うのだが、これはアプリを複数国にまたがって展開する際に重要な情報だと思う。
あと、これは自分が研究者だったら、、という話だが、ユーザーレビューを通してソフトウェアの品質を評価する手法があったら面白いだろうなと思った。
余談だが、世界各地域におけるモバイルアプリユーザーの振る舞い(user behaviour)の違いと特徴を分析した研究としては、ちょっと昔のものだが以下の論文がオススメ（日本も分析対象に含まれている）：
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話（3D版） を読んだ
QAのキャリアを考える上で参考になりそうなことがたくさん書いてあり、非常によかった。自分のキャリアに悩んでいる方はぜひ読んでみるとよい。自分は特に、スペシャリティの融合、という考え方は今後の自分の方向性を決める上で使えそうだと思った。
ところで、SETを敢えてPEを読んだことには何か理由があったのだろうか（テスト自動化に関わらず、自動化全般を職務としているため？）。
また、内容がとてもよかっただけに、スライドのサイズが小さいのはとても悲しかった。ところどころ文字が潰れていたため、読むのを諦めてしまうページがあった。
サーバ／インフラエンジニアの基本がこれ1冊でしっかり身につく本 を読んだ
自分は昔から、DBやWebサーバーやアプリケーションサーバーやネットワークに苦手意識があったのだが、なんとか克服したいと思い購入した（それに、インフラ系の知識は覚えておいて損がない）。
読後の感想としては、（おそらく）Webサービスを構築・運用する上で必要な技術を浅く広く学ぶことができたと思う。
特に、第七章「Webサービス運用の基礎知識」は、（これまでWebサービスに関わる経験が多かったためか）共感を持ちながら読むことができてよかった。
正直な話、パッと読んでも理解できたとは言い難いが（これは自分のスペックの低さに由来するものである）、読む前よりは一歩進んだ理解ができたし、なにより興味を強めることができたので成功した読書体験だと思う。
覚えなければならないことは色々とあるのだが、自分の目下の目標としてはDockerの基本的な利用ができるようになりたい。これについては、「たった1日で基本が身に付く！Docker/Kubernetes超入門」を読んで履修しているところである：
DMMブックスにビジュアルリグレッションテストを導入してみた（iOS版） を読んだ
ビジュアルリグレッションテスト、とのこと。
自分はやったことないので興味があって読んでみる。
ビジュアルリグレッションテストって、単純に画像比較するだけだとすごく脆そう（日付、数字、広告などが変わるとすぐに失敗する）イメージあるけど、実際のところどうなんだろう。
いやー、辛い、かなり辛い、手動で画面の検証をするのは非常に辛い、以前の画面を常に覚えて変更などが発生しているかを確認するのは色々なリソースを使うし機械的に行いたい、でも機械的に行う部分はどうしてもオオゴトになりやすい、どうにかならんもんか
なるほど、こういうモチベーションで始まったのか。
画像の差分がパッと見られるの便利そう。
reg-suitとかswift-snapshot-testingとか、それ用のライブラリがあるの知らなかったから、今後参考になりそう。
ただやっぱり、画面内の日付や数字などのちょっとした要素が変化することで画像比較に失敗してしまうのではないか、、というのがどうしてもきになってしまう。
記事では特に言及されていなかったけど、実際どうだったんだろうか。プログラムには差分だけを出力させて、差分の合否は人間が、、というフローなんだろうか。
