Londonでは、夜中の3時頃に目が覚めてしまい、朝食前まで仕事をしてしまうという残念な時差ボケを食らい、日本に帰ってきたら帰ってきたで、今度は夜から朝方まで悶々と眠れない、でも夕方まで常時眠い、という、時差ボケを食らう、という。そんなこんなで時差ボケの中、ちょうどLondonでエイプリルフールを迎え、その夜中?明け方?に官房長官がドヤってたのが天下のBBCに流れてました。BBCそれでも一週間仕事でなんとか戻してきました。書こうかと思いまして。Sessionという形でいくつか小ネタを会場隅の登壇ステージでやっていました。Prismの社員の発信で、中にはここでお知らせしたいものがあるのでご紹介します。文字通り、このシリーズと同じ内容。イギリス本国のコンサルタントも同じこと言ってたよ、ということです。二日目の朝8:00からやるかなー。時差ボケだから行けるけど。ここでは、サマリーだけお伝えします。(つまり、一気に大量のページやオブジェクトを作り切って、単体テストを纏めて行う、というのではなく、作っては都度テストし、テスト完了したらしたら次のページ、オブジェクトを作る、というように小さな単位でAgileに近い感覚で構築を行いなさい、ということです)確実性・信頼性を上げる為に、開発途中では同じデータでのテストを繰り返しなさい動きに矛盾が無いことを証明する為に、違うデータセットでのテストも必ず行いなさい回復性があること検証するように、不正なデータを用いてテストしなさい(どんなテストデータを用意するか、は結構重要です。行うスケルトンでテストしなさい1つのサブページを作ったら、テストを実施して、実施しきって、次のサブページの開発に移りなさい(これは、一度に一気に作り切ってからやおらテストするのではなく、一つのシンプルな機能ごとに作ってはテストし、を繰り返すようにせよ、ということです。これにより、エラーが発生したら、エラー発生個所は、直前に作ったところに限定できるはずなので、問題の特定と修正が効率的に行えます。一気に作り切ってから、テストを一気通貫で行うと、最初にエラーが発生した際に、さて、どこでエラーが発生したのかね、と探しに行かなくてはなりません。場合によっては、途中でブレークさせたり、終了させたりしながら、問題個所を探すことになります。そのエラーが解消できてもう一回流したら、次はその直後のところでまたすぐエラーが。今日はもう寝よう、となります。)ハッピーパスはもちろん、アンハッピーパスもそうですし、想定外のエラーがそこかしこで発生することを想像してテストシナリオを考えなさいどのシナリオはテストしたのかをしっかりと記録して、逆に、テストしていないシナリオ、想定外のシナリオを見つけ出すようにこころがけなさい(回復性を究めて、想定外のエラーでプロセスがTerminateしないよう、業務が続けられるように、ハンドリングを入れましょう)【まとめ】かれらの朝は早い。ベストプラクティスは、万国共通。