「システム運用アンチパターン」を読んだ
最近、
ソフトウェアの品質のみを業務の対象と捉えるのはQAエンジニアの活動として不十分ではないか。運用やオペレーションまで含めた組織のプロセス改善を考えなければ、、
という謎の使命感に囚われていたため、オライリーの「システム運用アンチパターン」を読んだ。
結論から言うと、「そうだよね、システムを運用しだすとこういう課題出てくるよね」と身に覚えのあるトピックがうまく言語化されており非常に面白かった。
また、タスクの自動化や可視化、文化の作り方や情報の取り扱い方など、具体的な解決策も挙げられていてウンウンと頷きながら読むことができた。
身近な話だと、QA業務においてもタスクの自動化は重要で、例えばテストデータの作成に毎度毎度複数日費やしていたり、開発環境-テスト環境-本番環境がいつの間にかそれぞれ異なる設定になっていたりすることがある（このような場合、テストの結果を信頼できないため再実行する羽目になる）。僕もこのような課題に対してスクリプトを書いて解決してきた経験があるので他人事とは思えない内容であった。
本書で特に興味深かったのは「大きなインシデントが発生して組織にトラウマが生まれたときどう解決するか」というトピックで、よくある解決策として「承認プロセスを追加する」というアイデアが採用されるが、これはDevOps的には悪手で、何故かというと、特定の人物に業務と責任が偏るし、承認プロセスの追加により生産性の低下やリリース頻度の低下を招いてしまうからというものであった（例えば、タスク自体は60分で完了するはずなのに、特定の承認プロセスを挟むせいで2-3日間手が止まってしまうことがある）。
全体を通すと、マインドセットの持ち方やコミュニケーションの取り方、課題への向き合い方など、心や意志にだいぶページを割いていたのが印象的だった。とてもよい読書体験ができた気がする。
ムーブメントを起こすときに大事に持していること
まずは、とにかく自分がハチャメチャに楽しんで行動すること。そして、楽しんでいる様子をパブリックに公開すること。すると、そのうち誰かが興味を持って僕の様子を眺めたり話しかけたりするようになる。そして、同じような行動をする最初の人が現れる。継続して行動し続けていると、僕たちの行動に興味を持った人が徐々に増えていく。
このトークを初めて観たのが10年ほど前で、それ以来、新しいムーブメントを起こしたいときには思い出すようにしている。
（ビジネス的に）品質の良いソフトウェア
品質の良いソフトウェアってなんだろうと考えていて、想いを一瞬で忘れてしまい、ようやく思い出したので書いておく。
僕は職業QAエンジニアだからビジネスコンテキストで考えるけど、いま一言で表現するなら「より少ないコストでより多くの利益をもたらすソフトウェア」かなと考えている。
バグが少ないとか、当たり前の価値を備えているとか、魅力的な価値を持っているとか、保守が容易であるとか、堅牢であるとか、運用が容易であるとか、いろんな観点がある（し、それで良い）と思うんだけど、ビジネス的にはまず売上をあげることが大事で、となると「コスパの良さ」はソフトウェア開発における品質のいち観点として無視できない要素なんじゃないかと思う。
「売上をあげていて合法で、マナーを守っているなら、バグがあってもいいし、当たり前の価値がなくても良いし、魅力的な価値がなくてもよい」という考え方はあってよい気がしている。実際、（名前は挙げないでおくが）バグがあり、特に魅力的（or当たり前）な価値が見当たらなくても、広く認知され利用されているソフトウェアを幾つか知っている（このような状況が発生するのは、ビジネスの仕組みが優れているからだとも考えている）。利用者は、しばしば文句を言いつつも、なんだかんだそれらのソフトウェアを使うことを辞めない。なんなら、「またバグが出たよ～～ｗ」と話のネタにさえしていることもある。すごいことだと思う。
もちろん、バグは少ない方がいいに決まっているし、当然のように期待される機能は実装されているべきだし、可能な限り魅力的な価値を提供した方が良いに決まっている。ソフトウェアだけを見るならそうあるべきだと思う。しかし、開発コストと売上とのコスパ、ビジネスとソフトウェアの融合を考えたときに、最適解となるバランスは何か？優先するべきもの/切り捨てても良い要素は何か？を考えると幸せになる人が増えるんだろうなと思った。
「品質文化」とは言うけれど
個人開発やってると、正直、「動くものを作るのに精一杯で品質のこと考えている余裕がない」と思うことが頻繁にある。
QA界隈では「開発チーム（実装担当者やPdM、デザイナー等ステークホルダー）に対して品質を意識する文化を築いていこう」的なムーブメントがあるように思うんだが、これって彼らにとっては結構な負担じゃないか、などと想像したりする。
僕のソフトウェア開発スキルが弱いだけかもしれないが、僕がQA以外のステークホルダーだったら「いや趣旨は分かるんですが実際問題こっちも余裕なくてですね、、」と言いたくなりそうな気がしている。
各企業のテックブログなんか読んでいると、「開発者が品質を意識してくれるようになりました」「E2EテストやAPIテストを実装してくれるようになりました」みたいな記事が散見されるんだけど、これって開発者の（品質を意識することにより増幅した）負荷をどれくらい考慮したものなんだろう、気づけているのかな、どうやって負荷を増やさずに品質文化を醸成しているんだろう、果たして？？なんて疑ってみたりもする。
上記はあくまで個人開発をやっている中での感想だが、チームでアジャイル開発をやるとなると２-3週間毎に実装開始～リリースまで到達しなくちゃいけなくて、自動テストはおろか、コーナーケースや異常系を考慮しながら実装するのも大変に困難ではないかと思う。
- 仕様やアーキテクチャを検討している段階で不具合/違和感に気づけたら良いよね
- コーナーケースや不具合発生時のインパクトを考慮しながら実装できたら良いよね
- 不具合の検出は早ければ早いほど修正コストが低くなるから、テスト環境にデプロイする前に実装担当者側で最低限テストしたほうが良いよね
いずれも正論だと思う。しかし、じゃあ実践できるの？と問われたらかなり厳しいんじゃないだろうか。もし僕が、切羽詰まった（例えばスプリント後半の）段階でこれを言われたら
そうですよね、全くもってあなた方が正しいです。それでは、次回から2-3スプリントほどで良いので実践していただけますか？口を動かさなくて結構です、頭と手を動かしてやって見せてください。私のロールモデルになってください。
などと噛み付いてしまうかもしれない。
もちろん私は、QA側の発言に敵意がない（むしろチーム/会社に寄り添った意図での振る舞いである）ことは知っている。ステークホルダーも特に反論しようとは思わないだろう。そのうえで、品質文化について言及したりそれを浸透させようという行動を起こすときには慎重になったほうが良いんだろうなと思う。例えば、開発者が意識せずともある程度の品質が自動的に担保されるような環境をQA側で提供しながら対話を進めると良いかもしれない。ビジネスをやっている以上、品質は間違いなく大事で、それは皆分かっている。分かっていながら実現が困難であるという状況を起点として歩んでいけると良いのではないかと思う。
脳死でテストケースを減らす知恵（Amazon Cognito編）
Webサービスのユーザー管理と認証をAmazon Cognitoで行う場合は、パスワード設定の制約（最小文字数やパスワード要件）をコンソールから設定できる。
Webサービスをテストする際にはアカウント作成周りのテストケースが地味に多くなりがちなんだけど（2バイト文字とかメールアドレスまわりとかパスワードの組み合わせとか文字数とか）、ここの設定を確認すれば数件の正常系と異常系をテストするだけで済みそうだなと思った次第。少なくともコンソール側で設定した部分の品質についてはAWS側が保証してくれているわけだからね。
全然関係ない話題になるけど、AmazonやMicrosoftがサーバー周りの設定や開発を便利にするクラウドサービスを普及して市民権を得ている現在、ソフトウェアの開発工数見積ってどうやればいいんだろうとか考えるなどした。
Bridging the Communication Gap: Specification by Example and Agile Acceptance Testingを読んだ
Listed below are essense of the book:
- Basically It's unrealistic to understand all details of specification instantly
- According to researches on US army, only 34% of commands are completely executed. Other commands are missed or misunderstood. Same things frequently happens on software development project. But if we understand the background of the commands, then the percentage should be raised.
- Creating black-box test cases on requirement phase is one of the best practices to avoid communication gaps between stakeholders. This is because requirements and black-box test have similer idea: how the system should work.
- As formality increases, tests and requirements become indistinguishable. At the limit, tests and requirements are equivalent
- Concrete realistic examples give us much better way to explain how things really work than requirements. Test scripts that are produced to verify the system are also examples of how system behaves. Examples, requirements and tests are essentially tied up together in a loop.
- A key lesson to take this and apply in software development is that understanding business reasons behind technical requests is crucial for buildng shared understanding of the domain. Original intent is one of the most important things that a customer or business analyst should pass on to the developers and testers.
- Understanding why something is required, instead of just blindly following instructions, is definitely one of the key factors for improving the chances of success in a software project. This is why it is crucial to communicate the reasons behind technical requests and business decisions. Don't be afraid of ask 'why' if you do not understand a requirement or if you find it strange
- idea of agile acceptance testing:
- Use real-world examples to build a shared understanding of the domain
- Select a set of these examples to be a specification and an acceptance test suite
- Automate the verification of acceptance tests
- Focus the software development effort on the acceptance tests
- Use the set of acceptance tests to facilitate the discussion about future change requests, effectively going back to step 1 for a new cycle of development
- Agile acceptance testing is derived from Test-Driven Development, not from User Acceptance Testing.
- Because all the stakeholders have different points of view, it is good to have discussion on business problems together. This helps us to find new opportunities.
- Just writing realistic examples as specification is not enough, because each stakeholders have different point of view and then communication gap will happen. This is why specification workshop is required.
- Process of creating examples is more important than examples itselves, because lots of discussions happen during the process, and then stakeholders reach common understanding on the speicifcation
- Use ubiquitous language. One major reason why communication gaps happen is that because business-side and tech-side use their own jargons
- Specification workshop can be used not only making common understanding but also finding out potential issues
- Software Developers usually have to implement 500+ pages of specification into source code. It means that if the specification include cunclear expreccion, then something important should be overlooked. That's why concrete example is required
- Agile acceptance testing can also be used as a metrics of software development progress. The more acceptance tests become green, the more the software provides values to cusotomers
- We should take care that acceptance test is are NOT dead or set in stone. They can be changed/updated as the time goes by
ノーコード・ローコードテストツールに求めているもの
（注意：私は本記事執筆時点でノーコード・ローコードテストツールを使用した経験が殆どなく、本記事には偏見と主観が強く入っています）
ノーコード・ローコードで自動テストを作成するサービスを眺めていて思うのは、サービスが終了したらユーザーは詰むんじゃないかということ。作成・メンテナンスしたテストケースが消えてしまうし、実行することもできなくなってしまう。
また、自動テストの実装自体はコーディングするより楽かもしれないが、テストケースを長期的にメンテナンスするときのコストを考えたときに果たしてコスパが良いのか悪いのか大変気になっている（そういえばヒーリング機能の効果ってどれくらい大きいんだろう）。
例えばテスト管理サービスのTestRailには、テストケースのインポート/エクスポート機能が実装されている：
こんな感じで、作成した自動テストをサービスに依存しないソースコードとしてインポートしたりエクスポートしたりする機能があればサービス終了を心配せずに済むし、細かい部分の実装やメンテナンスもコードベースで行えるので何かと便利そうだと思う（ついでにGitと連携してバージョン管理してくれるともっと嬉しい）。また、他の類似サービスに乗り換えるときにも便利そう（サービスを提供する側としては嬉しくないだろうけれども）。
2023/5時点では、MagicPodとAutifyには自動テストのインポート/エクスポート機能は実装されていないっぽい：
一方mablには、（制約やや強めだが）ブラウザテストのエクスポート機能が実装されている。また、APIテストはPostman-mabl間でインポート/エクスポートができるらしい。
個人的な価値観としては特定のベンダーに依存するのはリスキーだなと感じるので、こういった機能が実装されるとツールを導入する心理的ハードルがグッと低くなるなと思った。各社のツールに実装されている機能はどれも魅力的なので、（勝手に）とても期待している。
