雑文発散
2002-05-25 土曜日に寝て土曜日に起きる
▼ なにはともあれ、
読まれていないと思ってるのは間違ってるし、そんな風に思われてると思ってるのも間違ってるね。
▼ 朝帰り朝寝て朝起きた
徹夜カフェして、朝帰り。う゛〜って感じで寝たが、本日14:00より大阪行きの打ち合わせがあるために、11:30くらいに起きる。起きた直後に、何故か関心空間の未読処理を始めてしまい、気が付けば12:10過ぎ。慌ててシャワーを浴びて、家を出たのが12:40。待ち合わせ場所の渋谷の山下書店前に着いたのが13:50頃。「なんだ、door2door で1時間ちょいじゃん。ウチって意外と都会ね」と思いつつ待ち人を開始。いつまでたっても ohsamu が来ないと思ってたら、爆睡してた模様。疲れがたまってたんだね。
▼ 大阪散歩打ち合わせ的
場所はアンテナカフェ。初めて行ったけど、土曜のあの時間にあの空き具合いはいい感じ。潰れない程度に儲かってもらって、ずっとこんな感じの空間でいて欲しいな、とか思ったり。大阪散歩の方は、「朝はなに食べる？」「昼は？」「たこ焼きは最低○回（忘れた）」とか食い物系の話が多かったような。最終的に、散歩部的には画期的なほど予定が埋まった。
▼ 今日と明日だけらしい
東京タワーが青かった。
▼ テストミスったか？
届くべきメールが届いてないのでヤバイと思ったけど、ドメイン指定受信の設定をしていなかったからということにしたい。これって、本番でも注意が必要な点だな。どのアドレスからメールが届くのか、明示させるようにしよう。
▼ メガネナイト
コンタクトの調子がすこぶる悪いので、ただいまメガネナイト中。普段使ってない＆コンタクトよりかなり度数を低くしているので、感覚が全然違う。
2003-05-25 赤毛のアン絵皿はいらないなぁ、日曜日
▼ 昼ごはん
マッサージ帰りのワタが立ち寄り、お堂で一緒に昼ごはん。
▼ 買い物
活け花会と入れ替わりにワタと買い物へ。AssistOnで、CRUMPLER Wack-o-phoneを買った。あ、ケータイケースも買おうと思ってたのに忘れた。。。
後は、ユニクロで例のドライメッシュＴを買った。
▼ 夜ごはん
ワタも一緒にお堂に戻ってよきゅん特製カレーの夜ごはん。口当たりは良いけど、後から辛さがやってくる。作った本人は「今回は辛くない」と言っていたけど、お腹の中が辛かった（笑）
2004-05-25
▼ [雑] XL
今日はこないだ買ったばかりのシャツを着て来た。さっき、考え事をしながら腕を組んだ時、右手にガサガサっという妙な感触が。。。
うわ、なんじゃ！？と思って調べたら、左胸ポケットの下あたりに「XL」とサイズ表記されたシールが貼られたままだった。。。縦10cm・横3cmくらいの半透明シールなので、パッと見では目立たない。今朝すれ違った人でも気付いた人はいないに違いない、いや、そうに決まってる！
▼ [雑] 脱がずにトイレができるファスナー付き袴（はかま）飛鳥
えー、僕は袴をはいたことが無いのでアレなんだけど、やっぱり不便なもの？ 「告知で広まることにより定番となる可能性は大きい」ということだけど、これが本当に画期的なものか、経験者の意見を聞きたいところ。
それにしても「ファスナーを開いたところ」の画像はちょっとなぁ（笑）
2014-05-25
▼ [旅][車] パンダリーノ #1
パンダリーノ2014当日。会場最寄り（？）のホテル「nanvan 浜名湖」からだと近くて便利。
快晴ではなかったものの、それなりに日差しもあったので、会場入りしたところでさっそくサンシェードを展開。
会場内をウロウロしていたら、パンダにパンダをぶら下げていた人がいた！ これかわいい！ どこで手に入るのか聞きたかったけど、オーナーらしき人が近くにいなかったので聞けず。。。
会場内に出店していたカレーの大原屋さんのカレー食べたり、クイズラリーに参加したり、玉入れに参加したり、ぼけーっと昼寝したりしつつ、終了時間が近づき、クイズラリーの正解者（100%正解だったらしい）から、抽選で賞品があたるコーナー。
今回は、パンダ用のオイル4リットルが当たった！
まだオイル交換を自分でやったことない＆設備もないので、ディーラーかタイヤ交換の際にオイル持ち込みで交換対応してくれるか聞いてみようかな、というところ。
最後に、会場内で唯一だった同色パンダ２と並べて記念撮影。
向こうも同色と会ったのは初めて！と行っていたので、希少種なのかも？
2015-05-25
▼ [雑] Testing Casual Talks #2 へ参加してきた
Testing Casual Talks #2 へ参加してきた。前回（初回）は2年前くらいに開催されていたそうだ。その時は行っていないので、気付かなかったんかなー。
mruby のテスト方法についての試行錯誤
GMO ペパボで ngx_mruby の記述をテストするために実行してきた内容のお話。
まだ自分では Nginx の config が複雑怪奇になるところまでは書いていないのだけど、設定を mruby で書いて、しかもそれをテストできるという状態はとても気持ち良さそう。
いまやサーバ構築はテストできるし、アプリケーションももちろんテストできる。ただ、その間にあるミドルウェアに関しては、テストすることがうまくできていないという言葉を聞いて、そういう視点では考えたことなかったなーと、目からウロコ。
最近また少し自分でも Chef のレシピを書くようになった（Elasticsearch とか！）けど、そこで作ったサーバの動作テストは、たしかにポチポチと手動でやっているなぁ。curl -X 'http://localhost:9200/_cat/nodes' とか cat API を叩いたりして。
LTの「Casualにインフラテストへ入門した話」でもその辺の話題は出てきていて、Infrataster で振る舞いテストする話があった。
サーバ構築、アプリケーション開発でのテストについては知識も経験も多少はあるので、今度はミドルウェア領域のテストも試してみたい気持ちになった。
あと、GMO ペパボでは各種エンジニアを募集しているそうだ。
スクラム開発において、テストメンバー(非開発者)の関わり方を模索してみた
スクラムチームに QA が入るという話。以前の職場では、同じように開発段階から QA チームが入る体制を作った経験があったので興味深かった（ただし、そのときはスクラムで動いていたわけじゃない）。
8週間のプロジェクトをプロダクトオーナーが1名、スクラムマスターが1名、開発エンジニアが3名、QA エンジニアが1名というチームでスクラムを回したそうだ。社内でのスクラム事例2つ目で、スクラムマスター以外は初めてのスクラムということで、だいぶチャレンジングな様子。でも、そういう活動をしていくのは良いよなぁ。
さらにこのスクラムでチャレンジしたのが、開発チームの中に QA エンジニアを組み込んだことで、従来のウォーターフォール的 QA ではなく、アジャイル的 QA を実施してみたそうだ。その結果、仕様策定時の考慮漏れや矛盾点が QA から指摘することができ、早い段階での問題解決に繋がったメリットがあったとか。
一方でうまく行かなかった点として、スプリントで完了させる予定の機能のテストが、そのスプリント内に収まらない（終わらない）状態になってしまったそうだ。開発エンジニア3名の進行と、QA エンジニア1名の進行だと、そのスピードに差異が出てくることまでうまく考慮しきれていなかった可能性を言っていた気がする。
KPT での良かったところは、やはりスプリント内に QA プロセスが入ることで早期の問題解決ができるのが良かったとのこと。うまくいかなかったところは、先ほどの期間的な問題もあり、正常系テストが中心になり、異常系テストまで辿り着かなかった点があったそうだ。あとは、この機能とこの機能は一緒にやった方がいいみたいな待ちが発生してしまったりだとか。
今後は、テストのやり方を改善し、ユーザーストーリーごとのテストで待ちを解消したり、問題点のフィードバックを更に早くすることを試してみたいと言っていた。
前職で QA チーム作ったり、現職でスクラム初心者をしてたりするので、なんか親近感の湧くお話だった。
あと、ガイアックスでは、QA エンジニアを募集しているそうだ。
大規模 Web サービスのブラウザテスト自動化・並列化
ブラウザテストなので、Selenium の話かな？と思ったら Selenium の話だった。
DeNA には SWET (SoftWare Engineer in Test) というチームがあり、ゲームプラットフォームの品質保証や向上、また、開発のテスト環境の向上などを行なっているそうだ。今回は、その SWET が NBPF (Next Browser PlatForm) という次世代ブラウザゲームプラットフォームへのブラウザ自動テスト環境を構築・運用してきた話。
Selenium WebDriver と Ruby / RSpec / Capybara、そして Jenkins を組み合わせて自動テスト環境を構築したそうだ。
ブラウザ自動テストを作成することで、基本的なテストケースは自動化し、人間がやならなければならないテストに工数を割くことができるようになる。そこが大きなメリット。従来の機能は自動テストで済ませ、新機能や UI/UX などの検証に注力できる。
ただし、ブラウザ自動テストは遅い。遅いからと言って、テストの削減をするのは本末転倒なので、並列化によるスピードアップを図るという話。
並列化のパターンとしていくつかあげていた。
- テスト実行ノードごとに専用のアプリ稼働サーバのを立てる
- 実環境にテスト実行ノードごとのテスト専用データを（手で？）入れてそれを使う
- 実環境にテスト実行ノードごとのテスト専用データをデータ投入用のAPIを使ってそれを使う
- ユーザーが実際に使う UI を操作して、テストデータを作る
1 だと完全に環境が分けられるので並列化は楽なのだが、環境依存の問題に気が付きにくいのだとか。例えばロードバランサの有無による動作の違いとか、ドメイン名、本番データでしか発生しない何か、など。
2 の場合は、環境の違いは発生しないメリットがあるし、データをテスト実行ノードごとに分けているので、並列化もしやすい。ただ、このやり方は仕様変更に弱いとか。仕様変更の度に手作業でテストデータを追従させないといけない。また、本番環境を手で触るのも怖い。
3 の場合は、環境の違いも仕様変更への追従も問題が無いのだけど、大規模なサービスなので、そういった API が存在しないシステムもあり、「そのシステムへ API を作成する」となると、それはそれで工数がかかってしまい、なかなか進まない。
ということで、現状は（API がない場合には？） 4 を選択しているそうだ。ユーザーが使う UI を Selenium WebDriver で操作して、例えばアカウントを作ったりしているそうだ。テスト実行ノードごとにこれを行えば、それぞれ別のアカウントになるので、並列化によるバッティングも起きない。
これらの方法を使ってブラウザ自動テストを 8 並列とし、これまで 2.5 時間かかっていたテストが 0.5 時間で終わるようになったそうだ。
とはいえ、ブラウザ自動テストはテストが不安定なので、地道に改善しているそうだ。「いつもテストが落ちている」状態だと本当にヤバイ問題で落ちた時に気付かなくなるおそれがあるため。
また、そういう状態を避けるために「不安定なテスト」を把握する工夫をしているそうだ。テスト結果を収集する API を作り、「よく落ちるテスト」や「突然落ちるようになったテスト」などを検出し、その検出結果を Slack へ流している。「この通知が来たらヤバイ」という文化を作って対応されているとのこと。
また、各ノード・各テストの実行時間もプロットしていて、テスト実行計画の最適化にも取り組んでいるのだそうだ。あるノードは実行時間が長く、別のノードはさっさと終わっているという状態だと、遊んでいるノードがもったいない。そういう場合は、各ノードで行うテストケースの割り当てを変更し、「最も短い時間で全テストが終了する」という状態へ持っていくそうだ。
今後の課題としては、そういう「テスト実行計画の最適化の自動化」を目指したり、先ほどの 3 にあった API の拡充なども考えているとのこと。
Selenium 1 のころの大変さは知っているので、Selenium 2 (WebDriver) でもそこは変わらんのだなという思いもあれば、こういうやり方ができるのは良いなぁと思った。
あと、DeNA では各種エンジニアを募集しているそうだ。
LT
ECサービスの負荷テストの裏側
負荷テストのツール「Gatling」を使ってみて、足りなかった機能を自分たちで作ってみた、という話。
負荷テストはできるものの、そのレポートには自分たちが欲しかった機能が足りなかったそうだ。Gatling のレポートにはリクエストの成否や最大・最小・平均などの数値がでるが、自分たちとしては、データのばらつきやノイズなども見たかったし、時系列データが見たかった。リクエストの開始時間と処理時間の相関なども。
どうしたかというと、Gatling のログに simulation.log というのがあるのを発見し、そのログをパースして Google Spreadsheet へブチ込んでグラフ化したとのこと。1万行くらいのデータをブチ込んでも、遅くはなるものの、しっかり動作するので大丈夫だとか（笑）
そうやってグラフかすることで、リクエストの最小値が出ているのは、実は負荷テスト終了間際で、サーバへの負荷が減ってきたからその数値が出ているんだということが分かったそうだ。つまり、本当の意味での最小値かどうかは疑わしい結果だったということか。
こういう視点は重要だなぁ。
継続的Webセキュリティテスト
オレの中ではお馴染みの VAddy の紹介とか。
Web アプリケーションの動作テストは行うけど、忘れがちなのが Web セキュリティテスト。それを解消するには、例えば OWASP ZAP を使ってみると良い。こういうことをやらずにリリース直前の脆弱性診断で問題が見つかったりすると、阿鼻叫喚の世界になるので避けたい。
理想としては、開発段階から継続的にセキュリティテストができると良いはず。ただ、既存のツールだと CI のフローに載せるのが大変だったりするので、VAddy を作ったという話。
CI 連携できるように WebAPI を作ってあり、リポジトリに push すれば自動的にセキュリティテストが走る。
その検査エンジンは独自開発をしており、例えば「これが CSRF トークンだろう」などと自動で発見するような仕組みを加えているそうだ。
こういうの組み込んでいきたいけどなー。クローズド環境が大好きな会社だと、なかなか外のサービスを使えないというジレンマがある。
Casualにインフラテストへ入門した話
Chef で環境構築をしていたが、割と変更もあって、VM を作りなおしたりしていると大変な世界になってきたので、Test Kitchen と Serverspec を使ったテスト環境を用意したという話。
最新の Chef Development Kit を使えば、Test Kitchen も Serverspec も同時に入るので便利になったそうだ。（というか、オレもこれを聞いてインストールした）
これで手元でのテストがやりやすくなり、改善のスピードがアップ。
さらに Infrataster を使って、サーバ構築後の動作テストも利用し始めた。今までは、例えば nginx の設定をしたあとでブラウザを手動でポチポチやってテストしていたところの自動化をしたとか。
これで動作テストまでローカル環境でできるようになったので、設定変更によるデグレ防止ができ、安心感が増したそうだ。なので、みんな使おうよ、という話。
オレも使ってみたいので、今度教えてもらおう（同僚だとこういうところが便利）
カジュアルなテスト&仕様書として JSON+node requestのご提案
API の開発において、JSON でテスト 兼 仕様を記載することで、楽をしちゃおうという話。node の request モジュールの仕様で書くことにより、こういうデータを送信したらこういうレスポンスが返るというのを記述するそうだ。
複数の JSON ファイルを作り、それぞれにリクエスト／レスポンスを記載し、そのファイル群をテストランナーが回していく感じ。
そういうファイルを機能追加の pull request に含めたり、バグ報告の Issue に JSON ファイルを含めることで開発時のやりとりも楽になる。
これは外部仕様に関するテストなので、テスト書き過ぎ問題は避けられるという話だけど、世の中でテスト書き過ぎな状態ってどのくらいあるのかなーという疑問も湧いたりした。
でも、確かにカジュアルな開発（特に API 開発）だと、こういうやり方はアリだなーと思った。
ということで、ひさびさにまともにイベントのまとめというか感想みたいなものを書いた。いや、いろんな方面の「テスト」が含まれていて多様性のある面白いイベントでした。みなさんありがとうございました。
▽ shachi [おおお。ファスナー付きのズボンに馴れきった最近の人にとっては画期的かと。すばらしい。]
▽ あや [ファスナー付き袴は私たち女性には待ち望んでいた物かもしれません。まだ使ってはいませんが何となくわかります。買い換えの..]
▽ 栄之真 [時代劇の俳優、結婚式などの袴などもファスナーがついていたら良いんじゃないかな? 将来的にはグッドだと思う。 袴のす..]