パルカワ2

最近はFlutterをやっています

開発×テスト LT会 - vol.2でソフトウェアエンジニアが品質保証を学んでわかったことを発表した

speakerdeck.com

約1年ぶりの勉強会の登壇だったので緊張した。毎回緊張したって言ってる。主催者の人たちが話している時に頷いてくれていたのが見れたので話しやすかったです。ありがとうございました!

発表した内容は、ここ最近学んでいることなので大体このブログに書いてることをまとめたみたいな感じになった。品質保証というのをどう伝えるのかを結構直前まで悩んでいたんだけど発表は多分好評だったので良かったです。

そういえば他の登壇者の人たちが会社採用スライドみたいなのを出してなかったので、僕も出さなかったんだけど絶賛採用中なので品質の作り込みなどに興味があるQAエンジニア、ソフトウェアエンジニア、SETはぜひご連絡ください

jobs.10x.co.jp

他にも色々喋れることはあるので、発表していきたいという気持ちだけはある。

新居の鳩襲来問題 2

hisaichi5518.hatenablog.jp

前回は、ベランダの一部にテグスを貼って忌避剤で鳩を撃退するという形を取った。最初は効果はあったのだけど、一ヶ月経った今もまだ鳩は来ている。テグスを張っていないところには忌避剤を振りまいているのだけどそこにも止まったりするようになってきている。なのでベランダ全体にテグスを張ることにした。

前回は、ミツギロン 鳥よけ テグスセット ベランダ 手すり 侵入阻止 10m 簡単設置 取り外し簡単 鳥獣被害対策 ハットラップ EG-51 1セットを買ったのだけど以下のような部分が不満だった。

  • 見た目が悪い。支柱部分が黒いので目立つ
  • テグスが張りにくい
  • テンション調整がしにくい
  • スリーブの力が弱い。風が強いと外れてることがあったのでマスキングテープで止めていた。見た目が悪い

テグスの効果がわからなくてとりあえず1000円くらいのやつを選んだのでまあ値段相応ですねという感じ。

これらをどうにかしたかったので色々探していたらハトワイヤーというものを見つけた。今回はハトワイヤーで揃えた。

ベランダなどの鳩よけ・着地防止に ハトワイヤー | 鳩よけ・鳥害対策なら株式会社コーユー

  • ハトワイヤー 標準ベース支柱 * 3
  • ワンタッチスプリング * 4
  • ステンレスバンド160 * 3
  • ステンレスワイヤー(φ0.72) 20m巻 * 1

支柱を何本買えばいいのかみたいな割り付けはここで見れる。

ハトワイヤーの施工方法 | 鳩よけ・鳥害対策なら株式会社コーユー

嬉しいところは以下。前回の不満を取り除ける。

  • ワンタッチスプリングを使えばカシメ作業が不要でテグスを素早く綺麗に張れる。テンション調整も出来る最高
  • ステンレスワイヤー、支柱があんまり目立たない

朝起きて朝日を浴びるついでにベランダに出ている。前はテグスを見て汚え〜と思ってたのだけど今は綺麗じゃんとなるので体験が良い。

デメリットとしては、以下のようなことがあった。

  • 金切鋏みたいな強いニッパーがないとステンレスバンドを切るときに苦労する。僕はプラモ用のニッパーでやったので苦労した
    • 強いニッパー・ハンマー・レンチが家にない場合、気合が必要。買ったほうがいい
  • ステンレスバンドをよくわからないまま適当に触った結果元に戻せなくなってしまった+長さも足りていないことに気づいたので3本買い直した。動画で向きなどを見てから触ったほうがいい+長さは余裕を持って長めのものを買うと良い
  • 値段が高い

www.youtube.com

鳩を撃退出来ているか動画を撮っているのだけどちゃんと鳩も撃退出来ている。良かった。

仕様書は必要か?

ここでいう仕様書とは、仕様(=システムにおける検証可能な振る舞い)が記載されたドキュメントである。

社会人として10年くらいソフトウェアエンジニアをやってきて、今まで関わってきたサービスでいわゆる仕様書を書いたことがない気がする。プロダクトマネージャーやデザイナーたちと顧客からの要求を元に「こういう感じで作りましょう」という話をして実際に作っていくし、そこで話した内容とかは議事録とかに残ってるかもしれないが「はい、これが仕様書です」って渡されたこともない気がする。

仕様書は書いてこなかったが自動テストは書いてきた。ソフトウェアのテストを書けば”システムにおける検証可能な振る舞い”がテストに記載されるわけだし、仕様とはシステムにおける検証可能な振る舞いであるはずで自動テストがあれば仕様を記載する仕様書なるものは不要であると思っていた。

自動テストを仕様書とするのでは不十分?

先に書いた通り、仕様が書かれるのは自動テストで十分であると思っていたのだが品質やソフトウェアテストなどについて学んでいると品質の作り込みのために以下のようなことを満たしたいと思えてきた。

  • 早い段階での仕様の定義とレビューが出来ること
  • すでに実装された仕様がいつでも誰でも把握できること

これらを満たすには、エンジニア以外を含む開発に関わるメンバーが仕様を定義出来て、理解もできる形で記載されている必要があると思った。

つまり、自動テストのようにプログラムで仕様が書かれているとプログラムを書ける人しか書けないしプログラムを理解出来る人にしか理解出来ない*1。実装を理解していないとどこに仕様が記載されているかも把握出来ない。これだと早い段階での定義やレビューもいつでも誰でも仕様を把握することも満たすことは出来ない。

なので、仕様書と自動テストは分離されているべきではないかと考えた。

どのような仕様書がよいのか?

いま必要な仕様書は、開発に関わるメンバーが仕様を定義出来て理解も出来る仕様書である。

これらを満たすのは、ある程度ルールが定まった自然言語で記載された仕様書だと思った。例えば、仕様書を日本語で書くとすると日本語が理解して書ける人間は当然理解出来るし当然書ける。

逆にデメリットは自然言語は自由なので曖昧になりがちだと思う。それを防ぐためにルールを作ると良さそうだと思っているが自分はある程度こうすればいいなというのは見えているもののまだ模索中である。

仕様書と自動テストを分けた場合の課題とは?

仕様書と自動テストを分離すると更新する場所が増えるのが問題になる。仕様書を更新しただけでは自動テストは更新されないし、自動テストを更新しただけでは仕様書は更新されない。

それを防ぐのに仕様書に記載された情報を使って自動テストを実行する仕組みであるGuageやCucumberを使うとよいと思う。個人的には、Markdown-likeなsyntaxで記載出来るGuageがいい。まぁDartのRunnerがないので僕らは自前で頑張る必要があるんですが………。

gauge.org

追記:DartのGherkinパッケージには、Runnerもあるみたいなのでそれを利用するとよさそう。

まとめ

品質を作り込むには仕様書は必要だと思う。しかし仕様書と自動テストを分けると更新する場所が2箇所になってだるい問題が出てくる。なのでGuageなどを使うとよいと思う。

*1:実行すれば理解出来る形にアウトプットされるかもしれないが、実行しないといけない

ソフトウェア要求と仕様: 実践,原理,偏見の辞典 を読んだ

そうだねって内容でありつつも例え話が多くて自分にはあまりシックリ来なかった。

一汁一菜でよいという提案を読んだ

つくりおき.jpというサービスを利用していたのだけど、なんだか一日が楽しくない。味はかなり気に入っていて美味しいのだけど、リモートワークで毎日朝昼夜とすでに決まっているご飯から選んで食べるのがなかなかストレスに感じているのかもしれないと思えてきた。

なので自炊をしようかな〜でもめんどくせ〜という話をしたら一汁一菜でよいという提案を勧められた。

本の内容は、タイトルそのままで一汁一菜でよいという提案をされる。一汁一菜って言っても一菜(漬物)すらなくてもいいという提案なんだけど、読んでみて自分の中でいろいろな囚われがあったなと気づいた。例えば、一汁三菜とまではいかなくても主菜と副菜1品くらいは用意しなきゃ!とか美味しいものを作らなきゃ!とかレシピ見ないと美味しいものは作れない!とか自分が無意識に決めつけていたなと思った。

失敗してまずくてもいいし、日常的に何品も作るとかそこまで頑張る必要はないなと思った。1週間ほど経ったけど、毎日朝昼夜全部自炊してる。まぁ、朝はトースト焼くくらいだけど。

自分の中で特に衝撃的だったのは、味噌汁って自由なんだ!!!って気づいたことで、何いれてもいいし使うもので結構彩りも綺麗にできる。自分の中で料理は彩りが綺麗に出来ると満足度が高い。

Docusaurusを動かしてみた

docusaurus.io

動機

チームのストック型のレビューが必要なドキュメント(手順書, 仕様書など)をGitHubで管理をするならどういうのがあるのか気になったので、OSSでよく使われてそうなDocusaurusを試してみた。名前かわいい

下調べ

Docusaurusの強みは、MDXが使えたりAlgoliaの検索が使えたり翻訳やバージョニングに対応してたりするのが強み。ただチームのストック型のドキュメントで考えると翻訳やバージョニングは不要かなと思う。OSSだと便利そう。

特にAlgoliaの検索が気になっていて、Docusaurusで作られているJestの日本語ドキュメントで試したところ良さそうだった。ただちょっと補完したときにEnterを押すとドキュメント選択したことになってしまうのでバグってそうだけどいざとなったらOSSなので自分で頑張れる。

ただAlgoliaのDocSearchがオープンなドキュメントを対象としているので、IPでアクセスを制限しているプライベートなドキュメントはOSSになっているdocsearch-scraperを使って自分でindexしてあげる必要がある。しかしログインが必要なプライベートページには対応していないっぽい。例えばGitHub PagesでprivateにしているとGitHubのログインが必要になるはずなのでダメそう。

しかもクローラーOSS自体も2週間ほど前に新しいDocSearchがリリースされたことで非推奨になってしまった。まだ使えるとはいえ新しいDocSearchの仕様が変わったりしたら困るし、自前で頑張ればいいけどまあ…めんどくさいよね…

Migrating from legacy | DocSearch by Algolia

動かした

まあ、一応やってみるかということでやってみた。

以下を実行してprivate repoにpushしてNetlifyにデプロイした。すぐできる。Deploy to Netlifyもあったけどエラーになった。あとNetlifyは認証を使うにはお金がかかるらしいので試していない。

npx @docusaurus/init@latest init website classic

肝心のAlgoliaは、Netlifyと連携していてAlgolia Crawlerがまだ使えない人でもAlgolia Crawlerを使える。しかもpushするたびクロールしてくれる。

Quickstart for Using Algolia on Netlify

ただsitemap.xmlに記載されているURLが、/docs/tutorial-extras/manage-docs-versions/docs/tutorial-extras/manage-docs-versions/ にリダイレクトされてIgnoreされる。

しかし、sitemapに記載されている /docs/tutorial-extras/manage-docs-versions を優先するのでリダイレクトされたあとのURLもignoreされるという悲しいことが起きてしまう。

f:id:hisaichi5518:20220215184234p:plain
ドキュメントの大半がIgnoreされている

これをどうにかしたかったけどsitemap生成するプラグインも設定がないようなので諦めた。

所感

結構期待して調べてたけど、まあサクッとはいかんなという感じだった。OSSには良さそう。

チームが品質を作り込むために必要なこととは

ここ数ヶ月、品質やソフトウェアテストについて学んできた。本を読んだり入社予定のSET(業務委託中)と話したりしていて、学ぶ前の自分は品質保証を間違えて理解していたのだなと思うので共有する。

テストは品質を保証しない

2ヶ月くらい前の自分の中では、品質保証とは以下の図にあるテストの部分が品質保証にあたり、リリース前にテストすることで品質は保証される!と思っていた。

f:id:hisaichi5518:20220213024708p:plain
雑な開発ライフサイクル

しかし、たくさんテストをしてたくさんバグを発見したとしても、バグを修正せずにリリースされれば品質を保証したとは言えないし、見つけたバグをすべて修正したとしてもプロダクトにバグがないことの証明にはならないので完全に品質を保証することは出来ない。

テストは、欠陥*1に気付く手助けをしてくれてそれはリスク軽減にもなるが、根本的に欠陥を防ぐものではないし欠陥がないことを証明するものでもない。

品質保証とはなにか?

品質保証とは、開発チーム*2が「このプロダクトは品質が高い」と言える状態にすることだと思っていた。では、開発チームはどうやって「このプロダクトは品質が高い」と判断するのか?

品質とはを語るとき「品質は誰かにとっての価値である」というワインバーグの言葉がよく引用されている。プロダクトの品質において"誰か"とは顧客*3で"品質とは顧客にとっての価値である"と言える。

つまり、プロダクトの品質が顧客にとって高いかどうかを判断出来るのは顧客だけであって開発チームではない。なので開発チームだけで「このプロダクトは品質が高い!」と主張することは出来ないのではないかと思う。

Agile Testing Condensedを読んでいると「チームで品質を作り込む」「チームで品質に責任を持つ」という言葉が出てくる。品質保証とは、チームが品質を作り込み品質に責任を持つことであると自分の中では理解した。

ちなみにこのチームのメンバーは、エンジニア・デザイナー・PdMだけではない。テスターもCSもビジネスチームもパートナー企業もチームメンバーである。またQAエンジニアは、品質を作り込み責任を持つ人ではなくチームに対して品質を作り込むように促し同様に品質に責任を持つように促す人と僕は認識している。

品質を作り込む開発ライフサイクル

ではチームで品質を作り込むには、チーム全員で実装したものをテストするのがよいのか?といえばそうではない。実装したものをテストするにはテストするまで時間がかかるし、バグを見つけても修正するのに時間がかかる。時間がかかるということは、顧客に価値が届くまで遅くなってしまうし開発チームのリソースも奪い取りアジリティがあるとは言えない。またリリース後にバグの検出が出来ておらずそのまま放置されていたりしたら顧客にとっての価値を作り込めているとは言えない。

なので、リリース前にテストを行うのではなく開発ライフサイクル自体が品質を作り込む形になっている必要がある。

チーム全員が各ステージで"テスト"をする

品質を作り込む開発ライフサイクルは、チーム全員が各ステージ(要件定義・設計・実装・リリース等)でテストを行う。

テストを行うといってもテストケースを作ってテストすることだけがテストではない。そのステージでの成果物たちに対してレビューを行い質問などをすることもテストである。このテストをステージごとに繰り返す事でアジリティを持って品質を作り込む事が出来る。

最近の自分の例で言うと自分が実装する時に与えられた要求を頭の中で整理してそのままコードを書いてテストを書くのではなく、一旦実装しようと思っているものを仕様として箇条書きにしてパートナー企業に共有した*4。それに対してパートナー企業からフィードバックや質問が来るので、それに答えたり参考にすることで仕様のバグを見つけることが出来た。このパートナー企業がしてくれた質問やフィードバックもテストであり、実装前だがテストを行ってチームで品質を作り込んだと言える。

Holistic testing

品質を作り込む開発ライフサイクルについて書いていたが、アジャイル・テスティングを提唱したJanet Gregoryさんはチーム全員が各ステージでテストをすることをHolistic testingと呼んでいる。

f:id:hisaichi5518:20220211194443j:plain
Holistic testing

引用元: Testing from a holistic point of view - DragonFire Inc.

Holistic testingでは、テストが明確にステージとして定義されておらず、各ステージの中でテストが行われる。テストステージがなくなったことで、手動テストが完全になくなるのかと言えばそうではない。Buildステージでテストするだけである。

ちなみにもともとは継続的テストと言っていたっぽい。ただ継続的テストは人によって定義が違いそうでややこしいので個人的にはHolistic testingと呼ぶのがよい気がする。

まとめ

品質保証とはなにか自分の中で整理をしていたら、チームが品質を作り込み品質に責任を持つことが重要であると理解できた。そのためには、チーム全員が各ステージでテストを行う開発ライフサイクルである必要がある。

ちなみにプロセス品質というのもある。ここでは特に対象としてあげていないがプロダクト品質と同様にチームで作り込むことが重要な品質である。

関連

シェア用の画像 f:id:hisaichi5518:20220214093410p:plain

*1:いわゆるシステムのバグだけではなく、仕様バグや仕様の考慮漏れなども含む

*2:QAチームではない

*3:ここではプロダクトのユーザー

*4:共有はパートナー企業とやり取りしてる同僚がいい感じにやってくれたのだがとても助かった