テスト／品質系エンジニアが身に付けておくと得をする7つの技術
「Software Test & Quality Advent Calendar 2011」の初日エントリーとして、書きます！
テスト／品質系のエンジニアも、今や、テストや品質のことだけを知っているだけでは、幸せにはなれない時代となってきています。
プログラムは書けなくても、身に付けておくと良いと思っている技術をまとめてみました。
※注
今回記述した内容は、以下のような私のドメインに偏ったモノになっています。
- ミッションクリティカル／エンタープライズ系
- Java／.NET
他のドメインでは異なる部分や他の標準的なツールがあれば、コメントを頂ければと思います。
バージョン管理／課題管理
今や、必須のスキルと言えるでしょう。
バージョン管理（SCM／VCS／DVCS）としては、
- 集中型のSubversion（SVN）
- 分散型のGit／Mercurial
などが有名ですね。
分散型の場合は、各エンジニアが自分のリポジトリで作業可能ですが、最終的にはバージョン管理のマスター的な存在が必要になるので、開発者以外でブランチ／マージもできる人がいると、心強いですね。
また、課題管理（ITS）も、バージョン管理とセットで利用できるとうれしい。
Trac／Redmineあたりが有名ですが、基本的な概念に大きな差はないので、
- バージョン管理との連携
- チケットのカスタマイズ
- チケットのレポーティング
などができると良い。
ビルド
Javaでは、AntやMaven、.NETでは、NAntやMSBuildを良く使います。
テスト／品質系の方では、自分が思っているよりも、上記ツールのビルドスクリプトの作成方法を知らない方が多いのですが、ビルドぐらいはできないと、テストやリリースの効率が悪いです。
「ビルド＝コンパイル」ではなく、アプリケーションを動作させるためのパッケージングまで、自動ビルドできるようにしておくことが重要。
CI（継続的インテグレーション）
上記、バージョン管理／課題管理＋ビルドができれば、CIの世界は目の前。
ビルド、メトリクスの取得、xUnitテストなどが自動で行えるようになります。
これまでいろいろ経験した中で思うことは、実は、上記に挙げた部分は、自動化しておかないと続かず、問題が発生しても放置されてしまいます。
だから、CIが重要。
ツールとしては、Jenkinsが素晴らしく使いやすい。
最近、「Jenkins実践入門」も出版されたので、これから始める人も良い機会ではないでしょうか。
スクリプト言語
プログラムは書けなくても、とは言いましたが、スクリプト言語は使えるようになっておくと、仕事も効率的になります。
Windowsバッチ／WSH／PowerShell／UNIXシェルといったプリミティブなモノから、アプリまで開発できるようなGroovy／Ruby／Pythonなどの高機能なモノまであります。
何かひとつでも使えるようになっておくと、仕事の効率が大分上がります。
自動試験
世の中、まだまだ人海戦術でテストを行っている状況が多々ありますが、自動化できるところを増やして、より創造的な仕事をしたいですね。
私のおすすめは以下。
これだけでも使い方を知っていれば、自動化で対応できる範囲が広がります。
仮想化・クラウド
テスト環境を構築するって、大変ですよね？
最近のシステムは、構成も複雑になっているので、テスト環境を構築するだけで、かなりの工数がかかることがあります。
仮想化として、VMWare vSphereやMirosoft Hyper-V、Oracle VirtualBoxなどを知っておくと、環境の複製やバックアップ、切り戻しなどが簡単に行えるようになります。
私の場合、基本的にテスト環境は仮想化で構築するようにしています（もちろん、実機としての評価が必要な場合は、その限りではないですけど）。
また、仮想化だけでなく、場合によってはクラウドのサービスをを利用するのも手です。
サーバをレンタルするよりも、クラウドのサービスを利用した方が、手間もコストも減るケースもあると思います。
分散拠点でテストを実施する場合も、利用効果は高いと思います。
Excel
最後は、なんだかんだ言ってもExcelは必須だと思います。
（といっても、バグなどの管理は課題管理のツール使ってくださいね）
COUNTIF、SUMIF、VLOOKUPなどの集計関数や、ピボットテーブルは、当たり前。
SUMPRODUCT、INDEX、OFFSET関数、配列数式あたりまで使える人は強者。
さらに、マクロなどで、データの取り込み・加工から、集計・グラフ化まで行える人は最強ですね。
最後に
思っていたより長くなってしまいました。
「QC7つ道具」を意識して、「7つの技術」を挙げたのが間違いだったか...
と、ここまで書いてみて「Software Test & Quality Advent Calendar 2011」と言いつつも、直接テストに関係していない内容になっているかもw
テーマは自由、ということで、この後続く方のエントリーもお楽しみに！
＃まだまだ参加人数少なく、これでは12/25までもたないので、
＃このエントリー見てくださった方も、一緒に Advent Calendar やりませんか？
分散リアルタイム処理フレームワーク Storm（その2）
今回は、Stormの構成要素について見てます。
Stormのコンセプトとしては、以下の要素が登場します。
- Streams
- Spouts
- Bolts
- Topologies
それぞれ、以下のようなモノを指しています。
Streams
Streamとは、途切れずに連続するTuple（タプル：処理するメッセージを保持するStormのデータ構造）を意味します。
Spouts
Spoutは、Streamのソースとなるものであり、Tupleを送り出すことが役割です。
Twitter APIで、メッセージを読み込む部分などがそれに該当します。
backtype.storm.spout.ISpout インタフェースを実装します。
Bolts
Boltは、Streamの変換処理を行います。単一、または、複数のStreamからTupleを受信し、加工した上で、新たなStreamにメッセージを送信します。
関数処理、フィルタ、Aggregation、Join、DBとの処理などを行うことになります。
backtype.storm.topology.IBasicBolt インタフェースを実装します。
Topologies
Topologyは、Spout、Boltからなるネットワーク構造を示します。
こうして見てみると、非常にシンプルな構成ですね。
Boltの処理などは、実案件ではもっと複雑になると思いますが、複数のノードで連携できるため、
機能も分けやすく、スケーラビリティも確保しやすいと思います。
Stormでは、SpoutとBoltの処理を実装すれば、リアルタイムに処理を行うことが、簡単に実現できるようになるはずです。
以下の内容を見ると、より詳細が分かります。
分散リアルタイム処理フレームワーク Storm（その1）
少し前になりますが、2011/09/19に、Twitterから、分散リアルタイム処理フレームワーク「Storm」がオープンソース化されて公開されました。
最近は、Hadoopの効果により、BigDataへの注目度が高まっていますが、Hadoopが領分とするバッチ処理から、よりリアルタイム処理へのニーズが高まってきているように思います。
Stormは、BigDataに対してリアルタイムの処理を可能にするフレームワーク。
Hadoopと比較されることがありますが、個人的には、それぞれ用途が違うと思っているので、比較することにあまり意味はなく、特性に応じて使い分けることが重要だと思います。
Stormの特性は、以下のような点。
- 非常に広範囲のユースケース
- メッセージ処理、ストリーム処理、データストリーム上の継続的なクエリ実行・クライアントへの結果配信、同時並行で行う対話形式での検索回答（分散RPC）など、様々な処理をサポートする。
- 拡張性
- 水平方向にスケーラブル。計算は複数のスレッド、プロセス、サーバーを使って並列に行われる。
- データ損失が無いことの保証
- 各メッセージ（イベント）は少なくと1度は処理されることを保証する（S4などと異なる点）。
- 堅牢性
- 面倒な管理を必要としない。
- フォールトトレラント（無停止運用）
- ワーカープロセスとノード故障を管理していて、障害が発生した場合、自動でタスクの再割当てを行う。
- プログラミング言語を選ばない
Stormは、Twitterのバッググラウンドとして利用されているようですが、フレームワーク自体は、Twitterの処理に依存するものではなく、広く応用できるモノです。
まだまだ情報も少なく、インストールするだけでも大変な面はありますが、今後の動向が楽しみでもあります。
Advanced Tech Night No.2 「ジャバラーが知っておくべき最近の開発言語のこと」
第2回『Advanced Tech Night』を開催します！
今回のテーマは 『ジャバラーが知っておくべき最近の開発言語のこと』
リリース直前の「Java SE 7」、最近注目度が高まっている「Scala」など、最近の開発言語動向に関したセッションをお届けします。
なお、若干スピーカー枠に時間がありますので、自分も発表したい！
という方は、ぜひご連絡ください！
（Java系でなくとも構いません）
Lightning Talksとしての発表でもOKです。
申し込みはこちら↓から
http://atnd.org/events/17313
FindBugsの「Experimental」というBugCategory知ってるか？
以前、
という記事を書いたのですが、そのときから大分バージョンも変わりましたね。
最近、同僚に聞かれたところから、調べてみて知ったのですが、BugCategoryに、
EXPERIMENTAL
なるモノがあるじゃないですか!?
これは、まだ試験的な扱い、というバグ分類らしいですね。
2011/06/21時点の最新版である、Ver.1.3.9では、以下の2つのルールが存在しています。
- Potential lost logger changes due to weak reference in OpenJDK
- Method may fail to clean up stream or resource
ただ、FindBugsのツールによっては、エラーとして出力されないようなので、注意が必要です。
MavenのFindBugsプラグインでは、エラーとしてはレポートに出力されていませんでした（なので、これまで気付かず...）。
