「【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践」を読んだ

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

最近他チームの手伝いでテスト作ったりしてるんだけど、今一度テストってどうやるんだけっけ？と思い購入。月一で書籍購入を会社でやってくれるのは本当にありがたい。

同値テスト、境界値、組み合わせテストなど、個々のテストについて作成の仕方を解説したり、もっと大枠の話としてテスト計画やテストの設計をどうしていくかなどが網羅的に書かれているなと感じた。内容的には知っていることも多く、忘れていたことをちゃんと呼び覚ましてくれたというところが大きいが、初めてテストに携わる人なんかはこれを読んで勉強するのも良いかと思う。特に組み合わせテストでのテスト項目の削減方法はきっちり知っておくといい。全ての組み合わせでテストするのは到底現実的でないので、いい落とし所を作るためにどうするか学べる。またこういうところはTDDやるときに、仕様からどういう値がありうるかなとか考えるときに役立つかな。

ただ記載のある内容は基本的に真面目にウォーターフォール開発でのテストを念頭に置いてるものなので、テスト計画のところはまあそういうこともあるよねぐらいの感覚で読んでおいたほうがいいかもしれない。現実的には無理くりやらないといけないこともあったりするのだ……うっ頭が……とはいえ、前々職で作っていたテストドキュメントなどはこういうのを元にして作ってるんだなという気づきがあった。以前読んだメルカリでのテスト管理ツールの選定に出てきたツールたちもこの辺りを念頭においたりしてるのだろうか。

tech.mercari.com

あと、アジャイル的にやっているところとかだと、本に書いてあるように設計書が細かく分かれているとかない場合もあるから、そういうときにどうなるかなーというのは気になる。もちろんソフトウェアが満たさなければならない要求があるのだから、それをチェックするためのテストがあればいいのだけど必ずしも本書通りの形にはならなそう。継続したテスト、テストの自動化、などなど最近話題のところもあるけど、本書では範囲に入っていない。以下のリンクのように探索的テストが必要な場合もあるだろう。

codezine.jp

ただテストする上での知識として何が必要かは、必要十分に詰まっていたと思う。割とさっくり読めるのでテストの手始めに読むのが良いと思った。

月曜日は用事があって出町枡方商店街の黒板を撮る

ひさびさに通った

そっかーたまこあったかー。

でっかい黒板が見当たらなくなったので、片付けたんかな。

ネタバレになりそうな気もするゴジラ キングオブモンスターズ感想

godzilla-movie.jp

うまいこと時間が調整できたので、初日にさっさと見てきた。予告やちらほら流れてくるvsシリーズっぽいというお話に少し胸を踊らせて、19時からの回に。

結論からいうと、これは売れそうだなぁと思った。ハリウッドが作った大娯楽映画。派手なシーンも多く、あのキングギドラやラドン、モスラがこれでもかと動きまくって見せ場も多い。音楽も伊福部昭のあのテーマを盛り込みつつ、面白い仕上がり。監督自身がおそらくほとんどのゴジラ映画は見てるんだろうなぁと思えるオマージュの数々、特撮好きがこぞってどれが元ネタか探そうとするだろう。話のネタとしては申し分ない。これを見るにあたって予習はいらないと思うが、もし数々のオマージュが何かを知っておきたいのであれば、この辺を最低限押さえておくといいんじゃないだろうか。

ゴジラ

ゴジラVSデストロイア

ゴジラVSメカゴジラ

三大怪獣 地球最大の決戦

怪獣大戦争

怪獣総進撃

空の大怪獣　ラドン

モスラ（1961）

ストーリーもまあこういう荒唐無稽さというのは頭を空っぽにしてみる映画としては気にしなくてもいい、と振り切った感じになってるので気にしない人は気にしなさそう。マッドサイエンティストっぽい人たちはそれこそ初代の芹沢博士とか、メカゴジラの逆襲の真船博士とかもいたわけだし、復讐に燃える人と言えばvsスペースゴジラの結城さん*1とかもいたりあまり気にならず。

オルカの扱いなんかは怪獣総進撃の怪獣ランドとか怪獣大戦争のあれとかに近いのかなーとか。それこそ各地に怪獣が出現して暴れ出すというところなんかは、まんま怪獣総進撃でキラアク星人に操られた怪獣が世界各地に現れて破壊を尽くすというところに他ならず。そういや声に反応するネタだと84年のゴジラもそんなんだったなーとか。流石にモナークと環境テロリストそれぞれのザルさはなんなんだろうと思ったりしましたが、モナークがヘリで基地に着陸するところとか、完全にvsメカゴジラだしそういうメカ描写も面白いところはあった。もっとやるなら東宝特撮らしくメーサーとかああいうの出してくれてもいいのよ。

関西に住まうvsシリーズドンピシャ世代としてはエンディングのGodzillaのカバーに嬉しくもあったりした。

読売TV「ゴジラ復活作戦第2号」タイトル

読売ＴＶ「ゴジラ復活作戦」タイトル

vsシリーズっぽいというは確かにそうかと思える。2014年のギャレゴジやシン・ゴジラとは違う手触りでエンタメとしてのゴジラ映画であり、昭和のシリーズやvsシリーズに近い。いわゆる怪獣プロレスを求めている層だとドンピシャなんじゃないだろうか。

---

とかつらつら書いてきたけど、個人的には、最後まで映画にのれなかった。自分自身vsシリーズドンピシャで、昭和シリーズも全部見てきた。要素要素で見ると好きなものもたくさんあり、そういう細かいところをつつく楽しみ方もできてたし、南極でのギドラ登場〜ゴジラとのバトルシーンやラドンのソニックブームなんかもすごかった。

そう映像はすごいものがあった。

すごかったけど、なんか自分にはグッと来なかった。

何がしっくりきてないんだろう？ 見終わってから考えてみたのだが、映画として没入しずらい構成に感じた。序盤の方はそうでもなかったのだが、南極のバトルあたりから全体的な流れを感じずとりあえず見せたいシーンを繋げまくったという印象が残っている。また人が足元にいる中、怪獣たちのバトルが繰り広げられる箇所がやたらと多かった。おそらく物事がシームレスに繋がってるということなんだろうけど、怪獣の取っ組み合いをちゃんと見たいのに度々視点が人の方にいってしまうので、途中で意識が途切れてしまった。あとやたらカメラが近いので、もうちょっと空間を持たせて作ってほしかった。

役者さんたちもいいキャラしてるなーというのが多くていいんだけど、結構な脱落者が出てしまって色々もったいないなーと思ってしまう。そこらへん文化の違いなのかもしれないけど、芹沢博士の重みが薄らいでしまってなんだかなーという気持ちです。

結局のところ、映画としての緩急を感じられなかったのが、自分がのれなかったところなのかなと思う。良くも悪くもずっと高カロリーの油物が立て続けにくる映画。そこに自分はさっぱりとしたサラダ類などがほしかった。そんな気持ちです。

---

ただ来年にはコングとのマッチが控えていて、果たしてどうなるのかという期待は今から持っている。実際に今回のゴジラはかなり評判いいみたいだし、今後も作られていくことになるかもしれない。そうやって火を絶やさないようにはしてほしいと思う。多分見にいっている。

*1:のちにシン・ゴジラで官房長官

二週間ぶりにまた風邪ひきそう

昨日人混み行ったのがあかんかったか……悲しみ。念を飛ばしておく。

【第3類医薬品】南天のど飴U 54錠

THE IDOLM@STER MILLION THE@TER GENERATION 04 (特典なし)

エンジニアのためのデザイン思考入門 を読んだ

エンジニアのためのデザイン思考入門

会社の行き帰りにちまちま読んでいて、またまただいぶ時間がかかった。

デザイン思考ってなんぞやというところから、適当に買ってみたのだが結構面白い話が読めてよかった。東工大でのデザイン思考を実地で学ぶための授業、東工大生のみならず別大学の学生や企業もごちゃ混ぜのワークショップ。そこでの環境づくりや運営方法、ワークショップを進めていくための方法、実際に授業を受けた人のコラムなど、WhyからHow to、感想まで書かれてる。

ユーザーインタビューを通じて共感し、ユーザー自身が気がついてないニーズを見つけていく。繰り返しのプロトタイプ作りでフィードバックをもらい、煮詰めていくというところは割とソフトウェア開発でも聞く話であるので、そうよねとすんなり納得できた。環境づくりにしても、すぐに試せるような場所にしたり雑談できたりと大事にされていることである。

何より多様性やデザイン思考が根底となる文化が大事、共通言語を持つこと、チームメンバーへの信頼感があるようにしていかなければならない点などは、アジャイルやDevOpsなどでも共通する話であるなと思いながら読んでいた。*1実際に文中にアジャイルやソフトウェア開発でのプロセスに言及されているので、そういったものも参照されてるのだろう。

raydive.hatenablog.jp

raydive.hatenablog.jp

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

Effective DevOps ―4本柱による持続可能な組織文化の育て方

DDDなんかでもユビキタス言語をドメインエキスパートとの共通言語としたり、Event Stormingで多数の視点からイベント・コマンドを洗い出すなどの話もあったりする。

raydive.hatenablog.jp

raydive.hatenablog.jp

こういうのはやはり問題解決のためになにをすべきかを考えていくと、自然と似通っていくのかな。

閑話休題。

一方でデザイン思考のみだと、気づいてないニーズとはいえ、根っこの部分は他者に依存しているので全く新しい発想にまでたどり着くのが難しいのかなと感じた。*2コラムにてデザイン思考と合わせてクリティカルデザインという思考についても触れられており、新しい発想に繋がるように思える。

まあそんな感じで、話題の共通点を色々見つけることができて面白かったです。

エンジニアのためのデザイン思考入門

エンジニアのためのデザイン思考入門 [ 東京工業大学エンジニアリングデザインプロジェクト ]

エンジニアのためのデザイン思考入門【電子書籍】[ 角征典 ]

*1:Effective Devopsまだ全部読みきれてない

*2:誰も思いつかない発想を自分が発想するという前提自体が間違ってるのかもしれないが

Mistel BAROCCO MD650Lを自宅用に導入した

Mistel BAROCCO MD650L 分離式 メカニカルキーボード 英語配列 Cherry ML Switch ML1A 採用 アイボリー/グレー MD650L-LUSMGAB1

以前にKinesis Freestyle2を導入して、分割キーボードいいなーとなっていたのだがやはり机のサイズに比べてかなり大きいことが問題で。

raydive.hatenablog.jp

本を広げたりすることを考えるとやっぱりサイズ的には小さい方がいいよなーと、Mistel BAROCCO MD600もチェックし社内で使ってる人に触らせてもらったりしたが、キーボードの高さが微妙。

MiSTEL BAROCCO MD600 分離式 メカニカルキーボード RGBバックライトモデル 英語配列 62キー CHERRY 青軸 ホワイト MD600-CUSPDWWT1

Mistel Barocco Ergonomic Split PBT RGB Mechanical Keyboard with Cherry MX Nature Switches,Black [並行輸入品]

パームレストつければいいのだけど、机のスペースを空けたいのでどうするかしばらく悩んでいたのだけど、ロープロファイルなスイッチを使ったMD650Lがいつの間にかAmazonに売ってるのを発見して思わず買ってしまった。

この文章もMD650Lで書いているのだけど、腕が机で支えられる上に肩をすぼめなくてすむのでとてもいい。姿勢が悪いところはあるので、なるべく背筋を伸ばしてやっているが若干肩の張りがましになったかなぁと思う。何よりスペースが空くので、本を広げたりしながらキーボードを打つことができるのはほんとありがたい。めっちゃいいです。

Domain modelling made functional Chapter3を読む

raydive.hatenablog.jp

続き。

Chapter 3 A Functional Architecture

この章からドメインをソフトウェアアーキテクチャに変換していくところに入る。その前にソフトウェアアーキテクチャ自身もドメインだよねと、用語を定義するためにC4モデルを導入する。C4モデルの自分の理解としてはこんな感じ。

本の例だと、境界付けられたコンテキストとして今着目しているOrder-Taking ContextをDeployableなContainerとして話を進めている。*1境界付けられたコンテキスト間のやり取りにDTOやキューを導入したり、またコンテキスト間の決め事に三パターンあげている。

• Shared Kernel
• Customer/Supplier (Downstream contextが基準作って、upstreamがそれに乗っ取る)
• Conformist (Upstream contextが提供しているものに、downstreamが合わせる)

このコンテキスト間の決め事はエリック・エヴァンスのドメイン駆動設計にも書かれてるが、この本のまとめが端的なので読みやすいかもしれない。外部システムとのやりとりには腐敗防止層もでてくる。ここまではよくあるDDDだが、52ページの"Avoid Domain Events within a Bounded Context"でFunctionalなデザインについて述べられる。さらにはオニオンアーキテクチャまで発展するのだが、この辺り伝統的なレイヤー化アーキテクチャとの比較になっているので、Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)とか読んでると納得度は高そうに思える。

raydive.hatenablog.jp

次の章からF#を使ったFunctionalなアプローチが始まるようなので、楽しみにしておこう。

ひとまずこの辺まで。

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# (English Edition)

Domain Modeling Made FunctionalTackle Software Complexity with Domain-Driven Design and F#【電子書籍】[ Scott Wlaschin ]

*1:前の章でマイクロサービスはちょっと……みたいな論調だったけど、ちょっとそれっぽい気もする。もっと筆者が想定しているよりも粒度が細かいのだろうか？