おまぬけ活動日誌

● 足し算と引き算はむずかしい

…と2月16日分を書いてから考えてみたら、まだこちらは15日でないの。時差の設定の正負を間違えておりました。しもた。

というわけで、はじめまして〜。まず2月16日分から見てくださいまし〜。

● Xのカーソルをでかくする

公開。よろしくです。

● 詳細を書いちゃっていいのやら迷うので控えておくけれど、どうもありがとうございました。無事家にたどりつきました。

● Windowsをひっくりかえす

出かけていると妻から電話。ずんこがいぢっているうちにWindows XPの画面が上下左右ひっくりかえっちゃったとのこと。（CRTを逆さまに置けば正常に見える。）

画面のプロパティを見ても治らないし、制限付きユーザーでログオンしている時に起きたらしく、コントロールパネル／システムから見るデバイスドライバの設定なんて開くことすらできない。

Google先生に聞いてみると、左Ctrl+Alt+↓で逆さまになるのだそうな。すごい裏わざ発見ずんこ。

● ずんこと早寝をしたので早起きした

リンク元強化プラグインを検索入り月別キャッシュにしたのでこの日誌で試してみる。安定して動いてくれるようだったら設定インターフェースを作ってcommitしよう。

● [memo] gnome-control-centerに使われるアイコンは少なくともhicolor-icon-themeにはある

うまく動いてるマシンでstraceしてやっとみつけた。

xfce-setting-showの方はまだわからない。

(追記)xfce-settings-showもXを再起動したら期待通りのアイコンが見られた。これもhicolor-icon-themeが必要だったのだろう。

● [memo] rxvtはapp-defaultsを見ていない

Momongaのtrunk。rxvtの日本語フォントがきたない。~/.Xdefaultsにapp-defatulsのフォントの設定をコピーしてとりあえず解決。

● 肩の荷を無理矢理降ろす

吉とでるか凶とでるか…それほどひどいはなしでも無いけれど。

● このサイトがまた見えなくなっていました。今度はハードディスク障害が原因だったようです。ご迷惑をおかけしました。

● F-22「ラプター」、嘉手納基地への飛行の途中でハワイに帰還・搭載電子機器に障害が発生 (Technobahn)

沖縄に配備されるF-22が、ハワイから沖縄に向かう途中「コンピューターのソフトウェアに障害が発生」して「引き返していた」とのこと。

きっとあれだよ、日付変更線を越えらなかったんだよ…んなはずあるかい。

(2月26日追記) slashdot.jpには同じことを考える人も…ほんとかなあ。

● Picasaウェブアルバムを使ってみる

PicasaウェブアルバムはGoogleの画像ファイル閲覧サービス。友達が撮った写真を見せてもらうのに利用した。いい写真ばかりでよかった…のだけれど、ウェブアルバムとしての機能はイマイチなように感じた。

せっかくなので、後で似たもの(もちろんこんなに高機能である必要はない)を作る時のために初めて使った感覚を記録しておく。まず、URLがわかりにくい。上でリンクを貼ろうとしたのだけれど、PicasaというアプリケーションのURLはあっても、PicasaウェブアルバムというサービスのURLは簡単にはみつけられなかった。(友達からもらったURLは、そのアルバムのためのURLのようだった。) 次に、反応速度が遅く感じられる。アルバムを開くと、いかにもAJAXです、という感じでもっさりと縮小サイズの写真が表示されていくのだけれど、ある枚数以降の写真は灰色のままだった (Momonga 2/firefox-1.0.6-2m。Windows XP SP2/Firefox 2.0.0.1では期待通りに表示された)。さらに、タブを作って閲覧することができない。写真を何枚かピックアップして見比べたかったのだけれど、いちいちクリックしてもっさりと大きい写真が表示されるのを待つことはできなかった。また、中クリックや右クリックで新しいタブで開くという動作をさせることはできなかった。写真そのもののURLがわからない。気に入った写真を家族にメールで知らせたかったのだが、大きい写真が表示されている時には「authkey」というクエリのついたURLになっていて、写真によってこのクエリの値が異なる。このURLで家族も同じ写真を見ることができるのか直感的にわからなかった。

というわけで、直感的なURLと、アプリケーション側ではなくブラウザ側で統一されたユーザーインターフェスは僕にとっては大事なんだなあ、とわかった次第。

しかしWeb2.0用のオープンソースライセンスが普及すれば自分でユーザインターフェースをいじれるようになるのかなあ…。よくわからない。

● 水沢の駅で、朝ご飯どうしようかなあ、と思いつつきっぷを買おうとしたら、もう発車だから証明書もらってはよ乗って、一ノ関で買ってください、と。ありがとうでも朝ご飯…は一ノ関で食べるかw

● 雪は降っていないけれど、外は霧で真っ白。冬だなあ。寒い地域の電車のドアは自分で開けて閉めるべし。

● 人気の定番ずんだジェラートうまうま。枝豆は手にはいるんだからまいんちゃんに従って自分でつくってみないとなやっぱり。

● やまびこさん電源くれるすごい（翌日のやまびこさんはくれませんでした）

● 音声Skypeの会議が必要になってネットカフェにもぐりこむ。現代人みたいだ！

● 会議後ロフトうろうろ。楽しいねえ。ずんだあんみつもいただきましたよ!

● ソフトウェアテスト勉強会～JaSST'13東京報告会～ #sendaitest にお邪魔しました

下記は報告会に参加した僕の個人的なメモです。 誤りなどは僕によるものです。何でもツッコミよろしくお願いします。

JaSSTはJapan Symposium on Software Testingのことなのだそうです。

• 「エクセルは人生です」
• 「エクセルでやってることは全て自社ツールとしてサーバにコミットしてみんなが見られるようにする」

Challenges in Software Testing

ねもとさんによる、上記プレゼンテーションの報告です。

テスティングについてここ何年かの間に変わったこと

• 尊敬されるようになった/技術が認められるようになった
• テスト関連の本が1冊から数百冊になった
• テスターに専門性が求められるようになった
• 人手でやっていたテストがCIに

変わらないもの

• マネージャーはテストのことを理解していない
• ツールは銀の弾丸だと思われている
• 過去から学ぼうとしない

バグの出ないテストはいいテストなのでしょうか？

• 過去の経験からこれだけの数のバグが出るはずだ、と言うがそれで良いのか？
• テストでいくら多くのバグが発見できたとしてもリリースした後にバグが出てしまうと良くない→Defect Detection Percentage

Defect Detection Percentage

Defects found by this testing/Total defects incudeing those found afterwards

重要なのは正確性よりも一貫性

• システムテスト/結合テスト/受け入れテストのどこまで入れるか
• 小さいプロジェクト(不具合の件数が少ない場合)にはDDPに誤差がおおきい

DDPはリリース直後には100%で、時間がたつにつれて低くなり漸近的にある値に近づく 。

自動化の意味

「回帰テストを自動化して週末もずっと動かしているが、バグが見つからない」テストを止めた方が良いか？止めない方が良いか？ →止めない方が良い。環境が変わったりしてこけたりする。コードの編集前に走らせて動くことを確認しておいた方が良い。

• 自動化した回帰テストはバグを見つけるためのものではない - 自動化がバグを見つけるのではなくテストがバグを見つける
  • 環境でこけたり
  • 自動化は人手を省くためのもの
• ツールがあるからといってテスターがいらなくなるわけではない
• 全て自動化できるわけではない

バグを見つけやすいのは回帰テストではなくて探索的テスト。 探索的テストは自動化しにくい。 いまいちなテストを自動化する前に、いまいちなテストを良いテストにするべき。

ユニットテスト

ユニットテストは品質を保証できるか？

TDD開発者

ユニットテストは品質を保証するものではなく開発者が安心して作業をすすめるためにするもの。漏れがある

品質保証の人

メソッドレベルで品質を保証するもの

テスト設計コンテスト

お題が電気ポット

• 安全性や使い勝手を重視しているチームが多かった
• 自分たちの会社の問題を意識しているチームがあった
• 普通の参加者にはわかりにくいのでは
• 架空の仕様ため本当にバグを抑えられるのかわからなかった

参加者としての感想

いちからテスト設計をするのは大変だった ソースコードがないのでブラックボックステスト(システムテスト)しかできない。コード的にあやしいところを叩くことはできない
• 開発者にわかるあやしい匂いがわからない

Wモデル導入の手引き

うめつさんによるまとめの発表でした。

左が開発、右がQAだと対立構造。 Wモデルでは、上流工程にテスト技術者が参画することによって、 左側の斜面の右にそれぞれ対応する作業項目が導入される。

仕様が決まってないのにテストを書き始められない→失敗

じゃあWモデルの導入の目的は？

• 短納期 (海外)
• 品質向上 (国内)

ポイント - 品質向上のためのWモデル

• プロセス設計をWモデルを考慮しておこなう
  • どのアクティビティ(工程)をいつやるのか買いていく
  • 単純に前だおしするだけではだめ
• 必要なドキュメント設計をする
• 必要な教育をする

テスティングのグローバル最新事情

コグニザントジャパン株式会社(米国) - テストサービス部門 23500人在籍、取引先は銀行金融が主

• 2000-2005 800名 作業ベースのサービス
• 2006-2008 12000名 包括的なサービス
• 2008-2011 20000名 クオリティエンジニアリング
• 2012- 23500名 オンデマンドのテストサービス

テスト作業全体を請負、高品質化 - テストの

• 管理
• 戦略
• 計画設計
• 実行

マネージドテストセンター

• 一部請負
  • 高コスト低品質になりがち
• プロセス標準化
  • 効率化、品質向上
• テストセンター
  • 全部を見て必要なもの不要なものを分ける

ソフトウェアテスト

• 欠陥検出→欠陥防止
• 100%カバレッジ→直行表、スマートテスト手法 MCDC (Modify Condition Decision Coverage)、RBT (要求に基づくテスト)
• オンサイト・オフショア (TaaS)

品質保証のために

• クオリティ エンジニアリング
  • シフトレフト
    • 早期のバグ発見
  • 工程間にクオリティゲートを設けて流出を防止
  • 自社メトリクスを定義し品質保証
• Testing as a Servivce (TaaS)
  • オンデマンド
  • クラウドベース
• エンドツーエンドオートメーション
  • テストライフサイクル全般を通して一体化
  • 業務プロセスに沿って徹底した自動化

探索的テスト入門

ねもとさんによる参加報告です。

テスト技法のポジショニング

探索的テストは技法ではなくスタイル。

アジャイルソフトウェア開発宣言:包括的なドキュメントよりも動くソフトウェアを →包括的なドキュメントよりもテストの実施を

探索的テストのOK/NG基準

人依存 - 信頼できスキルのある人がやっておっけーといえばおっけー。属人化。「アートだからね」

ざっくり

• 機能性
  • 各々の主機能がテストさユーザーが望む操作ができアウトプットが 正しければおっけー
  • 不正なオペレーションのあとに正常に動作すればおっけー
• 安定性
  • ソフトがOSを不安定にしない
  • ハングアップしない、クラッシュしない、データ損失しない
  • …

実際にどうやって？

• 目的を明確に
• 機能を明確に
• 弱いエリアを叩く
  • 致命的なバグを出さない
  • 機能の端から順にテストするのではなくユーザーに近いところから
  • 実際に触ってみて危険なところを察知する
• テストの実施記録をとる
• …

利点

• 投資効果が高い
• 早くバグをみつけられる
• 沢山バグをみつけられる
• アジャイルと親和性が高い

欠点

• 理論的ではない

探索的テストの注意点

• 100%頼ってはいけない
  • 自動化テストやスクリプトテストと組み合わせる
• トレーニングが必要
  • 誰でもできる手順書をつくるわけではない
• 非機能よりも機能へのアプローチが強い
• 見つけた不具合を分析できる必要がある
  • 経験値の蓄積のために

● ビアバッシュも楽しかった

• ニセコのオーストラリア驚き情報
• アパレル業界に探索的テスト？

● 体力が減ってきたところでビアバッシュを早退。楽しかったです。ありがとうございました。また来られるといいなあ。雪がちらつく中をホテルに帰投。