技術関連の覚書

案件でやったり自宅で試したことの覚書

ソフトウェアテスト・品質勉強会

【初心者向け】ソフトウェアテスト・品質勉強会 Ver3.4【いまさら聞けないテスト・品質の基礎】 - connpass

こちらに夫婦で参加してきました。

テストとは何か?品質とは何か?やところどころ空欄のある資料を考えて、時々隣の人と話し合いながら意見を交わし合うものでした。

普段、開発者目線でテスト項目や手順を考えていて、新鮮だったのが 開発者のテストは動くことを確認するテストで品質担当者のテストはどうやったら壊れるかを考える。

異常系のテストってどうやっておかしくするか、つまり壊すかということならばそこからの発送は理にかなってる気がします。

その他に、ドキュメントについて 何人かで見て、おかしなところに気づけばそこにバグはなくなるということ。

例題にあった パスワードを④文字以上、⑫文字以内の英数字で、③分以内に④回間違えたら⑤分ロックがかかる。

このようなドキュメントが会ったとした場合、レビューしたときに 英数字が大文字小文字の区別があるのか パスワードを入力する際にマスクはするのか パスワードを間違えたときにどのようなメッセージ、またはエラー画面に遷移するのか など、色々な疑問が出てくる これらが仕様として追加され、想定されたテストケースとして反映されるけど、ここにはバグは存在しなくなるはずです。

そして、テストケースは考えていけば無限に出てきます。 だから、必要なテストに絞り込むことが必要。 この絞り込みは、境界値、0やnull血などの特異点で絞り込めます。

他に、状態遷移図、状態遷移表の併用で漏れを防ぐなどが紹介されていました。

テストというのは決して単純な作業(スクショ貼り作業)ではなく設計と同等に大事で頭を使う仕事であるということを再認識させてくれる話でした。

クラウド化について思うこと

最近AWSへの移行という案件を診て思うことがいくつかあるので書きたいと思います。

よくある移行はオンプレからクラウドに移行したいというパターンが多いと思います。

そんなときに起こりがちなことをいくつかまとめてみたいと思います。

手作業でインスタンス構築

試しに作ってみるときなどは特に構わないと思いますが、構成を管理するにはCloudFormationなどで管理するほうが良いと思います。 yaml慣れしてない人などには最初とっつきにくいかもしれませんが、一度作ればほんの少し変えるだけでサーバーを変更できるのでものすごく楽になります。

マネージドサービスを使わない

オンプレの構成をそのまま活かしたいという意図で同じような構成を再現したいということでEC2インスタンスへ今まで作っていた構成(APサーバやDBサーバなど)をそのまま持っていきたいということでマネージドサービスを使わない選択をする場合があります。 DBサーバのバージョンを合わせたいなども1つの要因かと思います。

その結果 監視ログなどを自前で作り込む必要がある OSなどのパッチ当て作業が必要になる OSのアップデートのためにDB移行をする必要があるなど今までと同じ手間をかけることになります

しかし、今までよりもサーバーの変更やOSの入れ替えは早くなることにはなるのでそんな運用に満足してしまってるところも少なくないようです。

ただ、マネージドサービスを使ったときにどれだけ楽になるかは実際使わないとわかってもらえないので色々な成功例を調べて説得するしかなさそうです。

インスタンス内でDockerを使う

これについては微妙なところだと思います。

CloduFormationですべて管理できればDockerを使わなくても良さそうな気がします。

しかし、docker-composeやansibleなどを駆使して様々な設定をしているサーバー資産を簡単には手放せないとも思います。

まとめると、オンプレ運用とクラウドの運用は別物という考え方は必要なので、クラウドの特性をよく調べてから構成を考えようということでしょうか

パワポカラオケに行ってきた

今回は技術的なことというよりはプレゼンのこと。 それも、かなり遊びの要素が多いものでした。

パワポカラオケとは

ランダムで選ばれた人がランダムで選ばれたお題についてランダムに出てくる画像を見てプレゼンする大会です。 一人の持ち時間は3分で画像は5枚、次に何が出てくるかもわかりません。 あと、次に行くと前の画像にも戻れません。 更に、画像の切り替えは合図で変えてもらうのですが、酔ってるためフェザータッチで勝手に次の画面に行くこともありますw

そして、いきなりこんな画像が出てきたりします。

プレゼン画像の例
プレゼン画像の例

お題もそのときに決まるので頭をフル回転させて話をでっち上げる能力が求められます。

こういう大会も楽しくて良いです。

業界あるあるBarでisaaxについて話してきた

昨日ここで話してきました。

内容は、isaaxの紹介ということでどんなことができるのかを話してきましたが、今回は自分の好きな宇宙開発の話をもとに構成してみました。

isaaxはIoT機器に一斉にアプリをデプロイすることができ、登録している機器のオンライン・オフラインの状態を管理できるサービスです。

IoT機器と言っても色々あるので、今回は宇宙探査機の話で架空の話をしてきました。

その話を作るきっかけになったのは、今年11月15日、燃料切れのため動作不能となった宇宙望遠鏡ケプラーの話を入れてみたかったことでした。

この望遠鏡の名前の元になった天文学者ケプラーも388年前、ちょうどこの日に亡くなっています。

偶然にしてもできすぎる!

ということでこの話を入れたかったのですが、残念ながら燃料切れ(電池切れ)の機器の管理はできても修復まではできません。

でも、この機能を使えそうな内容をいろいろ考えてみると、複数で組み合わせて動く人工衛星GPS衛星や中継衛星)があります。

あとは、何があるかというとこんな計画がありました。

簡単に言うと太陽系に一番近い恒星、アルファケンタウリの恒星系にある惑星プロキシマbへ向けて大量の宇宙ヨットを送る計画です。

簡単に書きましたが、距離は4光年、ここに到達するためには光の速度でも4年かかります。

探査機の速度もそれなりの速度がないと到達するまでにかなりの時間がかかります。

そのへんの技術はまたあとで。

ラズパイで監視カメラ

isaaxug.connpass.com

ここは今スタッフとして参加しています。

今回は人数も多く、ある程度ハンズオンに参加できる余裕があったのですが、ネットワークのトラブルで繋がらなかったりして断念。

これは、週末作るということにします。

今回書いてるものの元ネタはここからいただきました。

初心者回は毎回同じ内容でisaaxを体験してもらうことが目的ですが、今回は中級社会なのでその応用編として実際にテーマに沿って何かを作る回です。 テーマは与えられたものですが、それを持ち帰って応用して何かを作るのもOK、できた成果物をLTで語ることもできます。

楽しくやってるので遊びに来てくださいと宣伝も兼ねてます。

もくもく執筆会に行ってきた

techbook-meetup.connpass.com

ここで、書いてきました。 技術書典で書こうと言う気になった話の続きになるけど、やっぱり一人では進まない。 何しろ書いたことがないのでどう書いたらいいのかとか色々と考えてしまう。

考え過ぎで言葉に詰まる自分の不器用さが嫌い でも妙に器用に立ち振る舞う自分はそれ以上に嫌い

なので、動き出すまでに時間がかかる。

周りに書いてる人がいればなんか書く気になれるかなと言う思いもあって参加してきました。

それに、最後に全員進捗報告をするので、何もできてませんというわけにはいかない。

そのおかげで書き出すことができました。

技術書典5に行ってきた

techbookfest.org

今回1万人を超えてめちゃめちゃ混んでましたが、今回も買いすぎるくらい買ってしまいました。

ただ、今回は買い物以上に非公式の打ち上げで話したことが自分にとってありがたすぎる話だった。

技術書典の打ち上げですが、私自身は出展者ではなく一般参加者でした。 それどころか、つい数年前まで本を書くような人に知り合いもいませんでした。

前回の打ち上げで、今回は一般参加だけど次回は書きたい人になっていました。

しかし、それから半年、結果的に書くテーマも決まらず、何もできず申込みもしてませんでした。

そんな話を聞いて色々とアドバイスしてくれたのがシス管系女子の著者のpiroさんでした。

とにかく土俵に上がってみよう、どんなものでも欲しがる人はいる。 そんなことをほぼ打ち上げの最中ずっと話してくれました。

他にもわかばちゃんと学ぶシリーズの湊川あいさんも最初に書いたときの気持ちなど色々と話してくれました。

こんな人たちからアドバイスいただいて書かなかったら申し訳ない。 プレッシャーになってもいいけどそう思うことも原動力になるならいいかな。

system-admin-girl.com

webdesign-manga.com