私の管轄しているプロジェクトではないのだが、別プロジェクトが火を吹いている。
なんでもお客様からの品質に関する要望に対して提出している書類が思うように理解されないというものだった。

最初からプロジェクトがつつがなく進行している場合は問題がないのだが、数度問題が発覚するとお客様側の担当者としても黙ってはおれず、チェックが厳しくなる。
ただ単にチェックが厳しくなっているだけならばそれほど問題ではないのだが、ソフトウェアに対する品質管理を担当したことがないお客様がチェックを厳しくしようとするのが結構問題なのだ。

まず、言葉が通じない。
一通り書類を書いたところで、言葉の定義を一つずつ教えていかないとその文書を読むことが出来ていない。普通なら「こんな感じかな～？」っていうニュアンスで乗り切るのだが、”疑いの目で品質チェックをしようとしている”お客様としてはそうはいかない。
もちろん、書き方の問題もある。一言”モジュールテスト”だとか”ユニットテスト”だとか言っても、ソフトウェア業界ですら会社によって言葉が何を指すのかがバラバラな状態であることをよく聞く。
このあたりは、いわゆる製造業だとかその他産業との歴史の差が出ているのかもしれない。ソフトウェアの品質管理においての業界標準となりえるとすれば、国際的にはISTQB規格。日本ではJSTQBになるのだろうか

JSTQB
http://jstqb.jp/

しかし、”ユニット”の定義に関して明確になっているわけでは無いんじゃないだろうか？正直なところJSTQBとろうと思ったことないから分からないのだが…。
ただ、いわゆる目に見える機械の”部品”と、ソフトウェアのプログラム上の”部品”とでは実際に手にすることが出来ない分、考え方を変えていかないといけない。

もっとも、お客様にそこまで疑問視されるようなところまでいっている時点で問題なんだけどね。
ただ、ソフトウェアの場合は目に見えないものであるがゆえに、別業界の人に説明する時、言葉に関しては最新の注意を払わないと余計なコストをひたすらにかけることになってしまうなぁ、と思った。
ただ…気をつけないとって言ったところで、自分がその矢面に立たされた時に乗り切れるだろうか？ちょっと考えてしまうなぁ

あれこれと試行錯誤しながら、IEのツールバーを作成して、そこからIHTMLDocumentClass等を駆使してページの操作が行えることは何とかできた。ActiveXコントロールに対する捜査はまだ試してはいないけど、できないことはないだろうと思う。ただ・・・
考えてみると、Webアプリケーションの場合機能が分かれた時に別ウィンドウを立ち上げることがよくある。。。と思う。少なくとも私がテストしたいアプリケーションはそうだ。
この場合、IE8では特に別のIEインスタンスが起動してしまうためにそちらに対しての操作がうまくいかない。うーん、これはちょっとハードルが高そうだ。

ウィンドウをオープンさせるイベントをフックさせて新規のウィンドウではなく、フレームわけした場所にそのウィンドウをオープンさせることができれば何とかできるかもしれないが、そこからもウィンドウを開くといくつフレームを用意するんだー！って話になってしまう
結局、IEとは別の場所から制御するしかないのか。。。しかし、そうすると操作できることに限界が来てしまいそうだ。。。
あああああ

もう寝る

WebApplicationをテストするのに、あれこれとやり方を探している。
最初、PowerShellでIEを操作することでゴリゴリとやってみようかと思ったんだけど、テストしたいアプリケーションが古い作りをしている＆ActiveX満載な状態なので、PowerShell上からどう操作していいのかがわからなくなった。
VBAではSendKeysを駆使してActiveXコントロールのボタンを押す事が出来るんだけど、PowerShellからのやり方がよくわからなかったのだ。多分、PowerShellからでもC#を呼び出せるのだからキーを呼び出す事は出来ると思うんだけどなぁ。
既に画面に対する定義情報はあるので、それを元にスクリプトを作成。それを読み込ませることで実現したい。

色々と考えてみたのだが、外部からあれこれするのではなくIEに組み込む事は出来ないだろうか？例えば、ツールバーのようなものを作って、そこに対してスクリプトファイルを読み込ませてテストを実行させる…なんて事が出来ればIEのバージョンが変わっても楽に移行テストが出来ていいんじゃないか？？
残念ながら実現するには技術が足りない！ってことで他力本願で調べていたらこんなものが見つかった

WebTester in C# (CodeProject)
http://www.codeproject.com/KB/cs/webtester_in_c_.aspx

すべてではないけど、かなりの私の要望を満たしていると思われる。ここまで出来ているのであれば、見よう見まねでいじる事が出来るのではないか？C#に関しては素人もいいところだが、いい加減覚えたいところではあるのでこれを機にいじってみよう！
と、思ってダウンロードしてみたがリンクのエラーが出まくった上に必死こいて直したらツールバーじゃなかった！
ううむ。

そもそも発送が間違っているのだろうか・・・・
やはりC#を勉強してPowerShellから実行か…。

今日はTEFの勉強会で「現場で使えるソフトウェア（Java編）」の著者である町田さんによる本の解説付き勉強会でした。本そのものに関しては前のエントリで書いたので割愛。

テストに関してはいろいろと考えなければいけない。自分自身に関しても、私の所属するチーム全体に関しても。

それにしてもこういった勉強会は面白い。勉強会なので、知識や技術的な勉強になるのはもちろんのことなのだが、それ以上にいろいろな人に会えることは面白いし勉強になる。私自身、大学を卒業してずっと今の会社に居続けているのであまり外の世界というものを知らない。そういう環境にいると、自分がどれほどのものかわからないし、取り残されてしまうのではないかという感じがする。何よりも視野が狭くなる。自分の現在の仕事の関係上、なかなか時間をとることは難しいのではあるが、今日のような機会を有効に活用して自分に生かしていきたい。

出来うることならば、情報を提供するくらいの力を持ちたいものではあるが。

少し縁があってTEFに参加させていただいています。いや、縁っていうか、参加したいって言って参加しているだけですが

Testing Engineer’s Forum
http://www.swtest.jp/forum.html

ソフトウェア開発を行っていて、自分のテストに対する認識だとか考え方に関して不足を感じていました。その状態を打破しようと参加させていただき、勉強会も時々出させていただいてます。近くでやったときだけですが。。。

そちらのMLにてちょっと話題になっていたので手に取ってみました。ちなみに私自身はJavaでの開発経験はありませんが、Javaという言語に関係なくソフトウェアテストの基本的な教科書として読みやすいものでした。

うん、これはなかなか良書だ。会社の仲間にも広めないといけませんな。

現場で使えるソフトウェアテスト Java編

• 作者: 飯山教史,町田欣史,高橋和也,小堀一雄
• 出版社/メーカー: 翔泳社
• 発売日: 2008/03/20
• メディア: 大型本
• 購入: 7人 クリック: 141回
• この商品を含むブログ (17件) を見る

先日、機会あってソフトウェアに対するテストを専門に考えるコミュニティの
勉強会に参加させていただきました。

Software Testing Forum (TEF)
http://www.swtest.jp/forum.html

私は大学を卒業して以来ずっと今の会社にいるので、他の会社の実情は分かりません。でも今の会社でのテストに対する意識の低さは最近ようやくわかるようになりました。かくいう私も、テストに対しての意識は大変低いものでした。

会社という組織に対して、というと大げさですがまずは私の意識を変える必要がある。と思い参加したのですが、思った以上に奥が深くて驚いています。

いわゆる”テストエンジニア”を生業としている集団。そもそものテストに対する意識が低かった私としては勉強会に参加させていただいたものの、テスト手法の話になってしまうとチンプンカンプン。いやー厳しい。

でも、とても勉強になるし面白いです。自分の知らなかった世界を知るというのは。実情を言ってしまうと、私の頭は開発手法を勉強することで結構キャパがあふれてきてしまってい、どこまで食らいついていけるのかが疑問ですが食らいつけるだけ食らいついていきたいと思っています。

がんばれ！俺！

いちばんやさしいソフトウェアテストを読んだ

いちばんやさしいソフトウェアテストの本 (技評SE新書 19) (技評SE新書)

posted with amazlet at 09.02.10

石原 一宏 布施 昌弘
技術評論社
売り上げランキング: 14416

Amazon.co.jp で詳細を見る

ソフトウェアを開発するうえでテストというものは必要不可欠な話である。ただ、ソフトウェアのテストエンジニアや品質管理者というものを目指す！という話をあまり聞いた事がない。これは私が聞いた事がないだけの話かもしれない。
本書はその現状を打破するために作られた本ではないかと思う。
テスト工程は、あくまでテストする対象となる機能。ここで言うとプログラムがない限りは実際のテストは出来ない。もちろん、仕様上の不備・不具合を指摘したりそれに合わせてテスト計画を練る事もとても重要な作業だ。ただ、肝心の開発が予定通り進む事は稀で往々にして遅れが発生する。その時に削られるのはまっさきにテスト工数がやり玉にあげられる。
バグを見つけたら見つけたで開発側からは裏切り者扱いされたりもするかもしれない。もちろん、バグを見つけたという事は間違いなく評価されるべき事で、そのままプログラムが世に出た時の被害を考えれば素晴らしい事。ただ、納期が迫ってただでさえ遅れが発生している開発担当者の感情的な心根としてそういう発想につながってしまう事もあるだろう。
本書でも第６章で涙ぐましい対策が語られている

常に挨拶と礼節を心がけ、開発者とチームメンバーとよりよい関係を目指します！
（中略）
そこで、テストエンジニアは常に開発者と良好な信頼関係を保ち気軽に話ができるようになっておく必要があります。（P126）

開発側に属する私としては色々と頭を下げたくなる内容だ。
これからのソフトウェア開発を考えると品質というものはより求められ、それに比例するかのようにテストエンジニアの価値というものはどんどん上がっていくだろう。
本書がそのきっかけとなってくれる事を願う。

ただ、本書は対象とする読者をどこに置いているのだろうか？実際に開発に携わっている人間にとっては本書は優しすぎる。そうなると、対象読者はだれになるのだろうか？
第１章は優しいものの、その後はV字モデルの説明、W字モデル。名前だけならAllPairsや直交表も出てくる。
うーん、対象は学生なのかな？