2015年1月20日 (火)

第12回クリティカルソフトウェアワークショップ GSNやIV&Vケースなど

今日は「第12回クリティカルソフトウェアワークショップ (12thWOCS2)」へ。ソフトウェアシステムでの信頼性・安全性の確保に関するもの。3日間のうちの1日のみ参加。

http://www.ipa.go.jp/sec/events/20150120.html


・アシュアランスケース入門

アシュアランスケースは、テスト結果や検証結果を利用者に保証したり確信させるためのドキュメント。具体的には、GSN(D-Case)という表記があるが、説明は主としてそれで行われた。その前段として、トゥールミンの三角ロジックが紹介された。自分としてはディベートでの反駁(はんばく)などがすっきり図示化できる~と、ちょっと感心してしまった。また、アシュアランスケースの標準化作業や認証関係も話が出た。


・セーフティとセキュリティ規格の同時認証方法論について

認証にお金がかかる話も行われ、似かよった2つを同時認証した具体例、またその課題が説明された。以前からセーフティとセキュリティに限らず興味のあった範疇なんだけど、一挙に実践へ向えない色んな事情も感じた。


・ソフトウェアIV&Vの基礎

IV&V自体の説明と、GSNをベースとした「IV&Vケース」の説明があった。


・第1回IV&Vコンテスト(電子レンジ仕様編)審査評・表彰

午前中に行われたコンテストの審査評・表彰。電子レンジの要求に対する検証結果などを確信させるコンテスト。うーん分かりにくいかな...。電子レンジの検証をGNS(IV&Vケース)で書いて、それを審査するコンテスト。チーム対抗で、出場したのは5チーム(だったと思う)。なお、コンテストへの参加はチームで応募するもので、コンテスト参加者のみが午前中に受講と作業。

IV&Vケースの実践的な場と思って、個人的に期待してたもの。ただし、電子レンジの検証全てにわたるわけではなくて、2つくらいの課題に対するIV&Vケースで、自分としてはなんで微細的な視点で考えるんだろうと、少し頭の中がもやもや。

後で、IV&Vケースの説明者に聞いたけど、IV&Vケースの使い方にも色々意見はあるそうだ。俯瞰的な利用の方を好む人もいるようで、自分もそのほうが良さそうに思った。(俯瞰的に眺めた上で、今回のコンテストの2つの課題を掘り下げて記述するのは構わないだろうが。)

ちなみに、本コンテストの優勝チームの1人は少し知った人だった。さすが。


GSNは、(複数の)モデリングツールで利用できるようになっているので、徐々に広まっていくと考えられる。呼称がそのまま広まるかは分からないが、IV&Vケースを実践していく事例も出てくるかもしれない。少し頭の隅においておくつもり。


Amazonでの書籍「ソフトウェア 信頼性 安全」


1月 20, 2015 ソフトウェア, ソフトウェアテスト, 品質, 安心・安全 | | コメント (0) | トラックバック (0)

2015年1月 6日 (火)

自己免疫疾患と品証暴走

今日ちらっと見たテレビ「家庭の医学」で登場したのは、SAPHO症候群。症状的には手足の関節痛なんだけど、リウマチ症などと少し違って皮膚系の症状も現れる。SAPHO症候群が”自己免疫疾患”であることが何度か番組で言われた。(ちなみに関節リウマチも自己免疫疾患かと思う。SAPHO症候群は、NHKの「ドクターG」に登場したようだ。)

医療系の番組で時々出てくる”自己免疫疾患”。外部からの異物への反応が過剰になって、症状を引き起こすというもの。しかも厄介な事に、ある病気と思って対処療法的に治療しても良くならずに色々調べたら自己免疫疾患のほうだったというケースが少なくないような気がする。あくまでTV番組などを見ての感想だけど。なお、ふと自律神経失調症なども含まれるのかと思って調べたら、基本的には含まないが、自律神経失調症の中のいくつかを自己免疫疾患に含めるという書き方のサイトもあった。


ソフトウェアに関しては、このような病気との関係では「ソフトウェア病理学」がピンと来る。ただし、この本では”過大な文書化作業”なる項目はあるが、ソフトウェア開発での自己免疫疾患のような事項は書かれていないようだ。

ソフトウェア開発での自己免疫疾患的な現象は、バグゼロを目指す余りにいつまでたってもテスト終了を出せないとか、静的解析でのワーニングゼロを目指すなどが考えられる。市場トラブルなどでバグが見つかってその対応は必要だが、ソフトウェアでのバグゼロが可能かは議論あるところ。むしろソフトウェア工学的には、「バグがないことは証明できない」が通説だ。

単純な論理構造の場合にバグがないことは言えても、どのシステムでもそうだとは言えない。昨今のように他モジュールや他サービスの利用が進むと、全体的なバグのコントロールはもちろん、(意図した時期のリリースのような)管理さえ難しくなる。

ソフトウェア開発以外でも製品企画や製品出荷、製品製造でも似たような事は発生して、いわゆる”過剰品質”。主体が品証とは限らないけど、声高に高品質が叫ばれ、商品化などがなかなか進まない。品証や品証気取り連中の、言わば暴走。

生物が生きてくために免疫は必要だけど、過剰になると弊害が大きくなる。しかも、その弊害が大きくなると直しにくい。(過度の)過剰品質は、その組織体での問題であり、積極的に対処すべきと考える必要があろう。過剰品質の問題は以前から言われてはいるけど、小さな場合(軽い症状)ならまだ良いが、大きい場合(重篤なら)は根本的な治療が必要だし最悪その組織体がなくなることも考えた方が良い。自己免疫疾がそうであるように、外見では自己免疫疾とは気づかない事もあるから要注意。

TVで「自己免疫疾患」が出て、つい考えてしまった。

Amazonでの過剰品質

1月 6, 2015 ソフトウェア, ソフトウェアテスト, 品質 | | コメント (0) | トラックバック (0)

2014年7月22日 (火)

ICSE'14勉強会(東工大)へ

今日は、「ICSE'14勉強会」で大岡山の東工大へ。「ICSE'14勉強会」は、ICSE(イクシーと言う人が多い)2014という国際的な学会での論文を、1日でなるべく多く読むというもの。輪講というよりもラントニングトークスに近いかな。主催は情報処理学会 ソフトウェア工学研究会 国際的研究活動活性化WGで、ここ3年ほど続けている。100近い論文のうち、そのほとんどを網羅。今年は93/99で、網羅率94%と言ってた。

「ICSE'14勉強会」のサイトは以下。
http://qwik.jp/se-reading/10.html

当日などのtogetterがあって、以下。
http://togetter.com/li/696308


情報処理学会主催ではあるが、USTREAMで様子を流したり投票を行ったりしてるし、結構フランクな発表も少なくなかった。ある意味若者寄りの運営で、進行やテンポもいい。逆に結構内容的には濃厚で、昼休みや終わってからは少し頭に疲労感が残った。また、大阪、名古屋、福岡をネットで繋ぎ、東京以外にも発表者が分散している格好。ちなみに発表者は大学生が多かったけど、NTTデータやIBMなども人もいた。

なお、講堂のようなところだろうとか玄関に掲示があるだろうと、建物名はメモしたけど、階や部屋の名前をメモしてなかった。そのため、建物内をうろうろ。再度建物の入口に戻って、それでも掲示無かったら(駄目もとで)守衛所で聞くか諦めようかなと思ってた。そしたら知り合いと遭遇。部屋名も知っててラッキーだった。

また、休憩時に声をかけられ、別の知り合いにも遭遇。一応オニギリなどを事前に購入してたけど、昼食はその知り合いと学食へ向かった。食事しながら色んな話をして、懐かしかったり世の中の動きで参考になる見方なども聞けて、有意義な一時になった。


論文はソフトウェア工学全般に渡ったけど、印象的にはテスト関係が多かった気がする。投票で好評だったのがM2:Unit Test Virtualization with VMVMで、テスト関係。ちなみにM2はテストケースは減らさずに高速テストするアイデア。(ただし初期化で共通的なものはまとめてテストするというもので、結構色んなところでやってると思うのだが。) また、Mutation testingに関する発表もあった。

テーマ的には古来からあるテーマでも、モバイルやクラウドを意識した論文になってるような感じ。また、そもそも(大)昔なら、その大学や企業でのプログラムなどの分析での論文だったと思われるが、今回の多くは、オープンソースのモジュールを解析したり分析したりしていた。ある意味、題材がクラウドにあると言ったイメージ。

なお、省エネ(Webのページの配色を省エネになるように設定)やソフトウェア理解(脳波による分析)では、面白い試みもするもんだな~と思いつつ、論文としての掘り下げが少ない気がするものもあった。


蛇足だけど、東工大の大岡山は久しぶり。20数年ぶりぐらいかな。そもそも入口が開放的になってるし、ビルとかが増えたイメージ。驚いたのは、犬の散歩禁止や、大声出さないでの掲示。結構構内に書かれてあった。声の件は、学生にというよりも、構内で遊ぶ子らに対してのもの。犬も似たようなもんで、(小さな?)庶民悪。また、今回の会場のビルは、研究室に入る時は、上履き着用。エレベーターや階段からの所で仕切られてて、そこで履き替え。研究室フロアそのものがカーペットになってた。(知り合いと話したら、富士通の山本卓眞元会長の考えの影響とか言ってたけど、本当か?)


今回の勉強会は具体的に参考になりそうな考え方もポツリポツリとあって、勉強になった。都合がつけば来年も参加したいと思う。情報処理学会(を含め他の団体も)このようなイベントは実施・継続すべきと考える。やっぱ最近の動向を色んな人の目線で聞けるのは貴重だ。そうしないと(古い)教科書のコピペだけになって、進歩から遠ざかってしまう。ふとそんなことも思った。また、本催しでの網羅率に拘る事への反対意見があったけど、100%必須とかでないのなら、今の形態が良いと思う。やはりスピード感があるように思えるし、駄目そうなものでもアイデア的には面白いものがあったり、難解なら難解である旨が分かるのは良い事だ。


7月 22, 2014 ソフトウェア, ソフトウェアテスト | | コメント (0) | トラックバック (0)

2014年3月 5日 (水)

再考 メイヤーズの三角形問題

知り合いのTwitterのつぶやきで、表題の「メイヤーズの三角形問題」が取り上げられた。ある数値の組み合わせが、どんな三角形の種類なのかというもの。つぶやきでの考えが自分の考えとちょっと違ってたので、「メイヤーズの三角形問題」をもう一度考えてみた/再読してみた。

メイヤーズの三角形問題とは、書籍「ソフトウェア・テストの技法」の冒頭で取り上げられている、読者への試験みたいなもの。

Myers_1st上のAmazonのは、日本語訳の第2版。左のが日本語の初版。もう35年以上も前の出版で、言わば古典。

なお、第2版ではXPの事などが追記されてるが、本三角形問題の細部で表現などが異なっている(後述)。また、Amazonでは”マイヤーズ”となっているが、ここでは訳本内でも書かれている”メイヤーズ”の表現を用いる。

問題は、第1版ではカードから/第2版では入力ダイヤグラムから、3つの整数を読み込んで、その数字の組み合わせで不等辺三角形、二等辺三角形、正三角形のどれかを印刷/表示するプログラムに対するテストケースを書きなさいというもの。

メイヤーズが記載しているのは、13個のテストケースと、1つの予想される出力を示したかというもの。13個の中に、1つの辺がゼロになるものをテストケースに含めているかとか、1つの辺が負数のものをテストケースに含めているかというのがある。14点満点だけど、プログラマの平均得点は7.8点であるとのこと。また、「全ての可能なあやまりを見つけられると保証はしないが」と述べてて、細部は自分で考えなさいとのスタンスだ。特に14番目でのエラー時のメッセージ(細部仕様)は、各自で考えなさいと暗に示していると個人的に考える。

さて、ここから細部になるけど、12として非整数の話しがある。第1版では非整数のこととしか書いてないが、第2版では”2,5,3.5,5.5”と例示がなってる。つまり数値が4つ。多分、本当は5.5は無いのだろう。(個数が異なるテストは13にある。ただし、例示は2つ。)

Twitterので知り合いとのやり取りでは、0詰め数値のことが言われていたけど、それをテストに含めるのは良いことかもしれない。0詰め数値は、3を”03”のように表記する方法。

ちなみに、例示されてるのは”3,3,4;3,4,3;4,3,3”のような表現。";"を便宜的なデリミタと考えて、3と3と4が1つのカードに書かれているなどと読めばいいのか、デリミタなども含めて記述されてるかによるけど、それらに関するテストも気になった。つまり、先に述べた4つ書かれているケースとか、デリミタまで含めて記述さていたら、”,”の代わりにスペースだったり別記号だった時のテストなどもあった方が良さそうである。

整数でないものとして例示は少数だけど、アスキー文字なども考えられる。

再度深く読んでみると、こんなテストケースもあった方が良いのとか思い付いたから不思議なものである。そもそも第2版は、GUIによるもので、GUIに絡むテスト項目は無いように思える。疑るような視点で再読してみることをお勧めする。(もしかしたら、検討した人とか検討した発表があるかもしれない。ちょっと探してみる。)

また、ここで示されてる条件でテストを請け負えるかとか、どんなテスト計画にするかとか少し膨らませて考えるのも悪くないかと思う。あるいは示されてることをRFPとして、十分と言えるか、あるいは何が不十分かと考えたりするのも悪くない。

なお、第2版と第3版は、カード→入力ダイヤグラムや印字→表示への変化以外に、有効な数値組み合わせという表現から、意味のあるという表現に変わっている。ただしこれは訳上の変更かもしれないが。久々に版による違いなどが面白いと感じた一時でもあった。


3月 5, 2014 ソフトウェア, ソフトウェアテスト, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2013年5月22日 (水)

「テストから見えてくるグーグルのソフトウェア開発」

今日、何気に本屋さんの本棚見たら、表題の「テストから見えてくるグーグルのソフトウェア開発」が1冊置いてあった。

平積みでなかったし、以前(今思えば予約注文だったか)にAmazonとかで見た気がしたので、結構前の出版かなと思った。

ところが巻末見たら、今年の5月23日の発行。パラパラと内容を読んだら結構面白そうで、則購入。

グーグルでの初期の頃のソフトウェア開発やテストの様子、そして現在のことが具体的に書かれてる。GmailやAndroid、インドなどいくつかのグループのテストのマネージャーとのインタビューがあり、話題も多岐に渡っている。

まだ全部読んでないけど、気になった事項をメモ。

・関連する職種として、SWE(ソフトウェアエンジニア)、SET(ソフトウェアエンジニアインテスト)、TE(テストエンジニア)。

TEが開発とは別の外部テストみたいに受け取った。ただし、ドッグフーダー(リリース前の社内利用者)や早期ユーザーとの協力関係もマネジメントするとのこと。

・テストを単体テスト/統合テスト/システムテストと分けずに、Sテスト、Mテスト、Lテストと表現。Sテストは(一般的な)単体テストというか自動テスト化。Lテストはユーザー視点でのシナリオテスト中心。システム全体のテストとして、Eテストなる呼び方のテストが最近出来た/言われるようになった。

・「プロトコルバッファ言語」なるものがある。公開されており、データ構造などの定義に使われる。JavaやPythonなど実際の言語での処理が、予め用意されてる(ひな形はある)感じなのだろう。 SETは、本コードの記述をレビューする。

・Buganizaerなるバグ管理システムがある。バグ票のフィールドで必須なものはごくわずかで、定義を曖昧にし、個々のチームがそれぞれのワークフローに応じて決めることができるようにしている。

・BITE(Browser Integrated Test Environment)と呼ぶ、ブラウザに統合されたテスト環境があり、テストの実践などをブラウザとクラウドで処理する。


インタビューなどの細部を含め、自分たちでも利用できそうな考えや手法などがちりばめられている感じがするので、じっくり読んでみるつもりだ。

5月 22, 2013 ソフトウェア, ソフトウェアテスト, 品質 | | コメント (0) | トラックバック (0)

2013年3月13日 (水)

軽めの品質のために

先だってのセミナーも含めて、以前からソフトウェアに対して、軽めの品質管理やテストをどう考えたらいいか思いをめぐらしてた。技術的な考えは後日にでも記載するけど、今日は、アナロジーとして的確と思えるのを見つけた/考えついたので紹介する。

自分自身が少し体育会系なので、以下の「陸上競技ルールブック2012」。(年度でタイトル変わってるかもしれない。)

http://www.jaaf.or.jp/athlete/rule/

ここに”第3部 トラック競技”と”第9部 クロスカントリー競走”があり、さらっと対比してみると良い。そもそもページ数が、38ページと4ページ。トラック競技だとmm単位の記述。クロスカントリーはシーズンだって”冬期期間に行われるべき”とか、”魅力的な”や”おおよそ”なんていう非常に曖昧な表現などが目に付く。

自分でも正確に知らなかったけど、トラック競技での風速測定は定められてて、100m競技だとスタートから10秒間。スタート前の計測でもないし、全員ゴールまでの時間でもない。当然だけど、スタートの記載は”スターターの信号器の発射(閃光/煙)”。

クロスカントリー競走は大抵芝生の所で開催されているけど、ルールブック上は”可能な限り草で覆われた”との表現。自分が事前に想定してたよりも、遙かに記載がアバウトだった。


でソフトウェアの世界では、ここでの例の、クロスカントリーの競技のくせにトラック競技のルールブックで話す愚行を行ってるケースがあまりに多い気がする。

そもそも、競技種目に相当するユーザや必要とされる使われ方が異なるのに、つい同じ土壌(例だと陸上競技)で括ってしまう。それなりの素地(元々のメンバーの能力とか今までの信頼性)があった上で厳密な手法などを話すのならいざ知らず、より高度な技法の説明に終始することもある。せっかくクロスカントリー競技で競う/楽しもうとしてるのに、妙にトラック競技のmmの話を持ち出されて興ざめするようなシーンに近いだろうか。

背景としていろんな手法や技法を知っておくのは良い(悪くない)が、組織体内の議論やセミナーでのグループ討議のための情報では、その組織体やグループに応じた手法や技法を元に議論すべきと考える。

3月 13, 2013 ソフトウェア, ソフトウェアテスト, 品質 | | コメント (0) | トラックバック (0)

2013年3月10日 (日)

「アジャイルなテストの見積りと計画づくり」

今日は、「アジャイルなテストの見積りと計画づくり」のワークショップへの参加。イベント案内はZusaarでのイベント案内を参考にして欲しい。また、ハッシュタグは、#NagoyaTesting。ハッシュタグを利用して当日も情報のやり取りをしているので、当日の資料や題材のWebプログラム、我々グループのテスト項目や発見したバグ一覧も辿って見ることができる。

案内を目にして、しばらく経ってから申し込んだせいか、補欠になってしまった。懇親会のビアアッシュに先に申込みする格好になった。結構その時は参加希望が多かった。ところが直前になってキャンセルがあり、繰り上がりで参加できることになった。

ただし、パソコン持参とのことで急遽使用できるように準備。最近ノートPCを使ってないせいか、セキュリティパッチやディスク容量が少なくなっていたので、それらの対応を行った。7日の夜から少しづつ準備しようとしたけど、ディスク容量が少ないことで、不要なアプリを消して少しセキュリティパッチを繰り返すやり方になった。

今朝の出発前でもセキュリティパッチが動いたせいか、シャットダウンに時間がかかってる。強制電源Offしてワークショップで起動しないのは避けたかったので、そのままバッグへ。当初が補欠だったこともあり、ちょっと慌ただしい朝での準備となった。

多少はヒントになるだろうと、「アジャイルな見積りと計画づくり」もカバンに入れた。結論から言えば、この本は今回は電車の中での予習としては役に立たなかったかな。やはりというと変だけど、アジャイルのしかもテストに関する実践主体のワークショップを前にパラパラ見るような本ではない。今回のワークショップがシステムテストなりブラックボックス系のテスト主体の話だろうとのことは分かっていたので、その視点での予習にはあまり役立たなかったという意味。「実践アジャイルテスト」はホワイトボックス系のテストの話だし、自分的に実践とも少しかけ離れている感じがしてるし、、、。皆も手探りのように思える。

ちなみに、電車の中で、お受験風の親子連れが乗り込んできて、なんか問答してる。それなりに大きな声だったので、そっちに気が行ってしまった。社会の工業地帯のお勉強だった。結構暗記してる子だったけど、佐世保で有名なのが“笹かまぼこ”との返答には苦笑。そんなこともあって、予習は実質ゼロ。

少し早めに会場の最寄り駅に着いたし小腹が空いていたので、丼屋へ行ってから会場に向かった。会場はオラクルさん。(オラクルさん、会場提供を含め色々ありがとうございました。)

本来は、Zusaarでのイベントでの自分の番号をメモしておくべきだったんだけど、繰り上がりだったこともあってよく読んでおらず番号の件で少しアタフタ。係の方で調べてくれたけど。ちなみに、プレートにはTwitterアカウント名などを記載。入門証というかQRコード書かれた紙をもらって、そちらでゲートイン。

テーブルについた後は、知った人にちょっと挨拶。それにしても、周りはほとんどMac。自分のPCは、Windowsで表カバーにアップルのカラーシールを貼っているもの。無線LAN使えるとのことだったけど、昨日のうちにイーモバイルを使えるようにしたのでそちらを利用した。(自宅での悪戦苦闘の末にイーモバイルはUSB接続にしたけど。)

11時からのスタート。セッションスタートの最初に、テーブル(グループ)内で自己紹介。自分を含めて、6名。Web系の人が多かったけど、組込みとか企画系が半分という感じ。自分は、この分類ではシステム絡みの組込みかな。全体的にも、テスト系(テストが主)の人は皆無との印象。運営サイドにテスト系の人がチラホラいたけど。 

グループ内のアジャイル実践程度は、微妙にまちまちだったかな。どっちかというと暗中模索しながらやってる人が多いみたいなイメージだった。なお、この類で、趣味の話が出ると和みやすいというか、その後の作業がしやすいと実感した。趣味とその後の作業は直接関係しないけど、思考方法がある程度類推できるというか、、、。

以下、自分の感想を踏まえて様子を記載する。(ワークショップでの講演なども良かったけど、ここでは多少批判めいた記述が多くなって済みません。まっ、自分を含めての今後の参考ということで。)


その後は主催者の説明が2時間ぐらい。13時になって昼食&昼休みだった。タイムテーブルをちゃんと見てなかったし、弁当出るとは出ていたか? 一瞬、それなら丼を食べなくても良かったかなと思ったけど、13時まで続いたから丼食べてて丁度良かった。

スライドは以前30分で講演したのを利用(?)したみたいだけど、2時間でも時間が足りない雰囲気だった。足りないというか、ネタ的に色んな事が含まれてて人によっては消化不良の部分もあったかも。というのも、ソフトウェアテストでのテストレベルやテストタイプ、ISO 9126とかリスクの事にも触れており、非常に幅広い内容。

主催者によるテスト実践の話が出て、具体的で良かったと思う。ソフト開発とは別にソフトウェアテストのタスクボードを用意して進捗管理を行う方法。組み合わせテストを事例としたテスト(タスク)見積りの話も出た。ちなみにテストの複雑度を1~80としてるとかで、個人的には細かすぎるとの印象。また、話にも出たが、プロダクトオーナーの役目や開発とテスト側のやり取りでの見直しなども発生するので、ターゲットとなるソフト種や組織体の雰囲気などによって採用しやすいかが決まるように思う。

(つまり、一般化しやすい/他で利用しやすいとは言えないと感じた。なお、どんなことでも当て嵌まる話として、一般化することよりも、良さそうとの意識があるなら各自が持ち帰ってどう自分の組織体に填め込むか考えれば良い。ただし今回の件は、プロダクトオーナーや開発とテストとがあまりに密でお互いにカバーし合う状況でないと、適応が難しそうだ。そんな組織体が少ないだろうという意味。)


昼食後&昼休み後は、少しおさらいして実習へ。与えられたWebプログラムの仕様書というか概要を元に、グループでテスト計画書/テスト仕様書を作成するというもの。テスト計画書との話だったと思うけど、IEEE 829のような本来の計画書ではなくて、むしろテスト仕様書の作成だったようだ。(テスト仕様書というよりも、テストケースの集団の検討を意識しているようなので、テスト屋さんにはテストスイーツのような言葉の方が通じやすかったかも。もちろん、テスト屋さんは少なかったけど。)

Webプログラムは、作業(タスク)の追加とか変更、項目による並び替えなどが出来るもの。ただし、当初はドキュメントのみを見てテストケースを考え、テストケースを主催者・事務局に見せてOKをもらえたら、WebサービスのURLを教えてもらえるという方法。

我がグループは、最初リーダー的な人と進捗把握の人を決めた。まっ、アジャイル系とかファシリテーションの絡む実習とかでは良く行われるパターン。ただ、一応決めた(と思った)けど、明確なやり取りは無く、誰か(実質2人だったか)が残り時間を時々教えたり、リーダーはダイナミックに変わるようなイメージ。

で、ついグループ作業の最初の方で「テスト観点の説明もあったけど、テスト観点って分かりにくいんだよね~」と口火を切った。まっさらの状態でテスト項目を考えるということでは、かえってテスト観点は邪魔との考えによる。ただし形勢は不利で^.^;、2対4。4人でジャンケンをして、うち1人にこっちのサブグループに入ってもらった。

実習の前に、変更に強い/変更しやすいテスト仕様書とか、(途中からだったか)そのテストでどんなリスクが回避できるかはっきりさせた方が良いとのコメントがあった。帰宅時の電車で思ったことは後述するとして、リスクの検討は当面無視というか、シンプルなWebアプリなのでリスク検討はさほど重要でないと考えて作業した。

変更の事を言われたので、さらっと仕様を復唱して、どんな要望が出そうかを軽く検討。それで変化に強いテスト仕様にとも思ったけど、そもそも変更が具体的でなく検討も含めて我がサブグループは消化不良だったかな。(本件も思うところを後述。)

で、別のサブグループは、テスト項目をGoogleスプレッドに入れてた。こちらはポストイット。決めた時間後に「せぇの~」と見せ合いっこしたら、結構似てた。つい「あれっ、テスト観点を主体に考えると言ってたのに~」と言ってしまった。^.^; 逆に、その後は、こちらのテスト項目を追加したり、考えの相違を検討すれば良かったので作業は楽になった。GoogleスプレッドのURLをTwitterでつぶやいて、ハッシュタグ付けることで、他の人もそのスプレッドへアクセスするという方法。

実は、自分のPCではGoogleスプレッドがうまく見えなかった。ぎりぎり容量でIEは6のままにしてたせい。多少焦ったり、こんな事ならiPadを持ってきても良かったかなと思った。今回はネットサービスの利用だったので、iPadでも作業できたかなと感じた。(ただし、やはり文書作成というか文字入力や編集の手間の件があるから、iPadで実作業できたか不安だけど。)

グループ内で、変更に強くするにはとか、リスク軽減やテスト目的などを少しまとめて判定依頼へ。で判定結果は「検討不十分」。その時にリスク軽減などを言われたのかもしれないが、再検討。他に見積りなどもその時に言われたのだったか?

見積りに関しては、意見色々。そもそも積み上げ式で行くにしても、どんな技法使うかとか、それらの意見を集約させるかなども課題。プランニングポーカーみたいにしたらと(一応)言ってみたけど、反対も無かったし賛同も無し。優先順位の件とか色々用語は飛び交ったけど、うまく収束していかなかった。結局、今回の実習でテストに○○分が与えられるので、それでテストできそうかとか、それに間に合わそうとの話になった(ような、全員賛成でなかったけどその方向だった)ように感じた。

個人的には、アジャイルでのテストの見積りの話をするなら/それが重要とテスト派が言うのなら、そもそも従来のテストの人達の見積り手法を明示すべきと思う。アジャイル系というか開発系からすると、今回の簡易なWebサービス等で、テストに焦点を当てた見積りが必要か?? 開発とテストを一緒に考えて、ストーリー/ストーリーポイントを考えるのが普通だと言える。メンバー全員がそうかは不明だけど、見積りに対して消極的だったのは、テストの(厳密な)見積りの必要性そのものが理解に苦しんだからかもしれない。

それでも、リスクの検討とかテスト目的とか、それっぽい見積り結果の言い方を用意して、2回目の判定へチャレンジ。(これも、グループ内には、まだ不十分との意見もあったり、駄目なら3度目にチャレンジで良いじゃないの意見もあり。)

結果的には、実習の時間のことや、主催者のチェック担当の人の関係も(他に温情も?)あって、Webサービスの実体のURLを教えてもらった。具体的には、ハッシュタグ付きの私宛のつぶやき。(ハッシュタグで他のメンバーもそのURLを知る方法。)

2回目の判定では、ユーザーシナリオが甘いとの指摘もあった。一応テスト一覧に書いてるつもりはあったけど、グループ内で再検討。実URLを教えてもらう前後だったと思うけど、そのあたりを追加/追記や明記する格好になったと思う。

で、実URLを利用してのテスト実施。効率よくするために、グループ内でどう作業するか議論。結局、元我々サブグループの方が機能(いくつかの画面)のテスト、別のサブグループがユーザーシナリオ系をテストすることにした。我々のグループも、画面で分けたり、同一画面のテストならテスト項目の上からの人と下からの人にした。で、バグをポストイットに書いてたけど、ある人がGoogleスプレッドに入力してくれて、そちらに清書をお願いする格好になった。(それも、ハッシュタグ付きでつぶやいて、皆で情報共有。)

なお、テストしようとしたら自分のPCのIEが古いせいか、画面乱れ。ある意味バグレポート1号。^.^; 結局自分自身はテストはできず、別の人と一緒に作業することになった。

先にバグレポートって書いたけど、使用環境が明示されてないので、バグと言えるか疑問ではあった。また色々操作してたら、そもそも仕様がおかしいよなというのもいくつか出てきた。画面遷移が不自然。それらも項目によっては要望と明記したりして、リストアップした。

一応、異常値とか複数人での同時操作などもテストした。変な文字列というか特殊コード、あるいはクロスサイトスクリプティングテスト入門編みたいなテストも行った。具体的には、(手っ取り早くできた)Tabコード入力。案の定というか、おかしな挙動を発見。

最後にGoogleスプレッドでのバグ一覧を元に、皆で議論。KPT(keep, problem, try)の整理も一緒にやったように思う。もしかしたらKPTの議論は、発表後だったかもしれないけど、、、。

なんかグループの2人間で多少意見の隔たりがあって突っ込んだ意見を言い合って、どうしたんだろうと思った時もあったけど余り気にしないことにした。個人的には悪くないグループ作業。個人的な結論(システムテストとしての合否)としては、社内向けならOKと思う旨は言った。もちろん負荷試験とか、ここでできないテストは別扱い。

で、テスト結果の発表は、我々のグループになってしまった。リーダ役の人が説明して、発表の指名時に自分の名前が呼ばれてしまったし、そのせいで前へ出たらコメントを求められたので、グループ内で意見統一できてはいないけど社内利用はOKに近いと述べた。

その後に総括的な話が出て、希望者はビアアッシュへ突入。

個人的には、アジャイルとの目線では、内容が細かすぎる点が多い気もしたが、実プログラムの仕様や挙動でテストする点は非常に良かった。机上で議論してても、得られることは少ない。特に実践で役立つことが少ない。頭でっかちになるだけのことが多い。その点、今回のワークショップは、メンバーとの議論を含めて、教科書に書いてないような次元での気づきがあった。また、今回の題材になかった事項で自分なりに考えがすっきりした事項もあって、ある意味感謝。


ビアアッシュでは、乾杯や歓談の後にLT(ライトニングトークス)とか個別に質問したり質問受けたり、、、。LTでは、プログラミング言語の堅めの話やメイド衣装の超軽めの話題まで多種。まっ、アジャイルなり若い人達のコミュニティ雰囲気ムンムン。面白かった。(コミュニティには、それそれで重宝する居酒屋とか度々登場する話題などがあり、知らないコミュニティのそれらを知ったりやり取りできるとの貴重。つうか、オラクルの人と少し話したけど、コミュニティの居酒屋=実体験があると、対応なり目線が違うというのが今回の実感。まっ、人によってはたいしたこととは思わないだろうけど。)

で、歓談という状況だったので、お礼を軽く述べて、ストレートに以下を述べたりした。

1)やっぱテスト観点は分かりにくかった。

今回のメンバーや開発系の人が多いと、テスト業界的に代表的なテスト観点をいくつか述べて、このどれかで良いので考えてみてください位が良かったかと思う。ISO 9126も一つのテスト観点だろうけど、今回のような実習でほんとに役立つかは別。

さらに言えば、そもそもテスト観点って何?みたいな基本的なことを述べないと理解は難しいかもと。(と言いつつ、自分自身もうまく理解できてないというか、どうも役立つなりツールや手法に思えなかった。あくまで、すんなり自分なりの手法として役立てようという気になってないという意味。そうでないと、他の手法などもそうだけど、応用が効かないというのが持論。ただし、帰りの電車で、テスト観点に関して「そうか~」とのアイデアも出たので、掘り下げて考えるきっかけになったのは良かった。)

2)テストケースを、ばっさり削る話しもしないと、、、。

色んなテスト関連用語が出て”漏れなく”などの用語も飛び出したけど、今回のテーマのアジャイルにテストする/アジャイルなテストをするという感覚と矛盾すると言える。テストケースを削る話しもないと、なんか従来のテストの話と同じになって、聞いててメリットがなんだったか分からなくなると言える。

もちろん反論はあるだろうけど、アジャイラーの人達が本当に”漏れなく”と言われて納得するか疑問。 逆に、”漏れなく”派とそう考えないメンバーとで、(バグ発見率などを)比較するなども面白いと考える。

もちろんテストケース以外に、テストフェーズのどこかなりテストフェーズの作業/負荷分布を見直す意見を言うなどもこれに関する事項である。

他に、他グループがどれくらいバグ発見したか聞いてみたけど、一応我々の発見件数は悪くない感じだった。グループ内の話の際に、ビアアッシュで他のチームのバグ発見件数も聞いてみますねと言って、一部からは否定的な発言もあったけど。ただし、主催者側では、わざとバグを入れてたとのこと。いわゆるエラーシーディング。それは発見できなかったとのことだった。ちょっと残念。やっぱそれなりの準備をしてたんだと内心感心もした。なお、残念って書いたけど、見つからなかったことと”漏れなく”への否定的な意見とは別。どんなバグが仕組まれていたかにも依存すると言える。

(ビアアッシュなので、意見交換すると実は、、、との話もあって、自分も含めて皆さん悩んでること少なくないんだな~とは実感した。これも有意義だった理由。)


なお、LTの最後というか占めに近いところでは、テストクラスの話が出た。テストクラスと表現すべきかは??だけど。 少し酔ってきたこともあって、途中から席に座ってボーッと聞いていたけど、テストクラスの継承みたいなのをどう実装するかの話のように受け取った。そうであればニーズは分からなくはないけど、ツールに実装できても、(特にテスト系メンバーの)誰が使いこなすかも気になるところだった。まっ、本件はこっちの勘違いかもしれないので、深掘りなども当面先/実質やらないかな。


楽しい時間があっと過ぎて、お礼とか述べて解散。いやー良かった。


帰りの電車の中で、ボーッとしながら考えたのが2つ。

1)仕様追加に強いテスト計画/テスト仕様

実習の時は言ってることが理解できなかったけど、イテレーション(スプリント)への対応のことを言ってるとしたら非常に納得がいった。そうであれば、(時間の制約を除けば)演習の際に、例えば全部が3イテレーションで、第2イテレーションと第3イテレーションのテストをするようにすれば良かったかと思う。

で、仕様追加とかの表現ではなく、イテレーション(スプリント)への対応と言ってもらった方がすっきりしたと思う。演習時に仕様追加ではなく機能追加などの表現だったかも?だけど、少なくともイテレーションを意識して欲しいとの話で良かったと思う。例えば、第3イテレーションで実装されるのは、タスク情報の変更(画面追加)とかにすればいい。あくまで、イテレーション対応のことを言おうとしてたのなら。

さらに言えば、自分の中でテスト観点中心でのテスト設計が嫌なのは、これに脆いと思ってるからだろう。誰が考えても、イテレーションで追加されてくのは(ほぼ)機能。であれば、テスト区分のような事項は機能であるべきだ。少なくとも、その方がイテレーションへの対応が楽だ。

2)リスクと説明責任

演習の際に、テストでどんなリスクが低減できるか示した方が良いとの話が出たと思った。また、テストには説明責任が伴うとの話しも。ここも自分的にはすっきりしない。各テストケースでリスクを考えるのはおかしい。むしろIEEE 829の言うテスト計画書で、よりテスト全般とかその関連として明確にすべき事項である。

今回の実習のようなケースだと、「全体的なテスト計画ではリスクの検討とか説明責任に言及しますが、今回はテストケース検討なので、考えなくても良いです。(興味あれば検討してみてください。)」 みたいな表現が良かったように思う。

テスト全体とか計画レベルでリスクや説明責任を考えるのは必要だろうけど、今回の勉強はそっちではないと言える。

テスト計画なども実習での検討範疇との考えもあるだろうけど、今回のようなワークショップだとむしろ上で書いたような複数イテレーションへの対応などに時間を割いた方がメリットあると考える。


なお、上で書いた2つは、自分なりにもっと掘り下げた方が良いし、ちょっとした思いつきも出た。その意味では、実習やそれに対する(上の意見だと少し過剰とも映る)コメントも、考えるヒントになってむしろありがたかった。

色々書いたけど、実習を伴った有意義な1日だった。もし次回に同類のイベントがあるのなら是非参加したいと思う。


追記:後になって、今回のイベントの運営として、ドタキャンが多かった事が書かれたブログを見つけた。こちらは補欠から繰り上がってラッキーだったけど、運営する側からは弁当などのこともあり収支に直結する問題。勉強会のことが雑誌などで取り上げられてるけど、そんな苦労もあるとか、どう改善すべき/してるかの情報共有も必要になってるんだと実感した。

3月 10, 2013 ソフトウェア, ソフトウェアテスト | | コメント (0) | トラックバック (0)

2012年12月 7日 (金)

ソフトウェアバグとバスタブ曲線

昨日「再考 バスタブ曲線」を書いたけど、そこで少し触れた、ソフトウェアのトラブルとバスタブ曲線に関して、、、。

ソフトウェアの出荷後/リリース後のトラブル(バグ発覚)は、ソフトウェアの経年変化がないので、終盤の故障率アップは無い。出荷直後やリリース直後は、テストが不十分だったりしてバグが発覚する。そしてバグ対策されて、トラブル件数は減ってくる。

その意味では、初期辺りは、バスタブ曲線に合致する。その後は安定して利用され、故障率ゼロに推移する。それがその商品やシステムの寿命まで続く。それが、一般的と言えるかも知れない。あるいは理想。

ただし、現実は、そうならない。

1)偶発期間でも一定の故障率

某OSを含めてセキュリティパッチのことを考えると、一定の故障率が続くと考えた方がすっきりするように思える。

ただし、ひどいのは、バグが継続するケース。そもそもテスト不十分等のままでリリース。修正バージョンを出すけど、修正ミスがチラホラ、デグレード、、、、。(製品回収やサービス停止も視野に入れた)抜本的な対策が必要なケースだ。

2)スポット的な故障発生

安定して使われても、時々トラブルが発生してしまう。(当時の開発メンバーが移籍したりしていることもあり、対応が厄介なケースになることもある。)

良くあるケースとして思い付くのは、システムでのデータ量の増大、外部記憶装置の容量不足、ログの増大などがある。

バスタブ曲線に関連したものとして、部品や機器の故障へのソフトウェアの対応が不十分で、それがトラブルの引き金になる時がある。結構対応やテストをした場合でも、複合的な故障の発生への対応が不十分だったり、想定される故障順番と異なった場合の対応ができていないことがある。後者では、故障率や部品耐用年数のデータでは、Aが故障してBが故障するという想定だったのに、いきなりBが故障するケースなど。

現用/予備の切り替えでのトラブルも、この範疇かも知れない。ただし、この類のトラブルはニュースレベルで目にすることが多いので、世間一般としては設計やテストが不十分と思われかねないジャンルである。

また、運用部門が(組織変更等で)結果的に不慣れとなり、思わぬ操作をして潜在的なバグが発覚することもある。一時的な対応として操作等で回避していたものが恒常的な対策を行わなかった&回避操作をうまく伝達できていなかった事でのトラブル発生もある。


基本的な確認を行わなかったなどは論外としても、見つけにくい/見つかりにくいケースもある。ある程度のレベルの組織体でも、時々発生する。ソフトウェアやシステムの設計やテスト、そして運用では、ソフトウェアの外部が(長いスパンをかけて)経年的に変化する事への対応を検討しておくべきだ。


追記:「日経 SYSTEMS」の2011年2月号(P52)に関連しそうな図が出ていたので紹介。”ノコゴリ曲線”。

2011___systemsp108_場当たり的な改修でトラブルが継続するし、終盤で保守が困難となることを図示している。

本ブログで述べたことは、ここでのノコギリ状態で、トゲのようなスパイクとして発生すると考えればいいかもしれない。多少地震のように、小さなトラブルが兆候として発生することもあるだろうが。なお、通常ならここでの保守困難期でのトラブルは少なく、システムとしての終焉を迎えるし、それを想定するだろう。

逆に、安定期でトラブルが頻発したり、周期的であれば、改修や元々の設計がまずいかも知れないと考えるべきだろう。また保守困難期が発生するかも知れないとして、新システムへの移行などを含め、その対応を検討すべきだろう。


追記:「ソフトウェアの経年変化がないので、終盤の故障率アップは無い」って書いたけど、そのソフトウェア(あるいはシステムと言うべきか)が使用できなくなる状況は発生する。具体的には利用しているOSのサポート切れ。組み込んだオープンソースを含むモジュールが利用できなくなるケースなども該当するだろう。また特にシステムの場合、一般的にメンテナンス契約があり、ソフトウェアはその期間まで動作することになる。

それらを考えると、ソフトウェアのバスタブ曲線は、稼働率のカーブと言えなくもない。あるポイントを0%としてX軸を稼働率100%とすると、従来のバスタブ曲線のように下に凸のカーブとなる。提起メンテナンスなどがあるのなら、想定時間に対する稼働率とすれば、トラブル無しなら100%稼働を意味することになる。

12月 7, 2012 ソフトウェア, ソフトウェアテスト, 品質 | | コメント (0) | トラックバック (0)

2012年11月 7日 (水)

機能要求と非機能要件って、ソフトウェアは与り知らないはず

今日、ネットで調べ物してたら、「機能要求と非機能要件」に関して最近書かれたページも結構多いのに気が付いた。”非機能要件のテスト”で検索しても、ポツリポツリとページがある。

前から思ってたんだけど、ソフトウェアのテストや作成の作業の中で、機能要求と非機能要件を分けるのが理解できない。ちなみに自分の場合、ソフトウェアの開発やテストの議論の際は、2つを分けることの是非は本質的ではないので話として割り込むことはしない。2つを区分する話題の部分を聞き流している。


そもそも作成するソフトに、例えばクラスを別にするなどして2つを区別することはない。テストも同様だ。良くレスポンスタイムの事を非機能要件とするけど、本来の要求事項の処理なども関係しているので、レスポンスタイムを速くする対応が1,2箇所をいじって調整できるほど簡単ではないことがほとんどだ。

むしろ、機能要求をユーザーからの要求とし、非機能要件を自社の都合などと考える方がすっきりするくらいだ。非機能要件として保守性などが挙げられることが多くて、非機能要件は多少のバグならOKとの考え方もあるかもしれない。例えば、サービスマン用の表示やログにスペルミスがあったからと言って、(昨今は)出荷NGにすることは皆無だろう。

レスポンスタイムも非機能要件とすることが多いようで、その範疇に含めても良いかもしれない。ただし、レスポンスタイムは契約なりRFPに書かれることが多くなってきている。そうなると、性能を出すことは必須。トラブルシートでも重要度は高レベルになるだろう。

なので、特にテストにおいては、機能要求と非機能要件を区別する必要はないと言える。むしろ重要度なり対策優先度において、その要求なり要件がどのステークホルダーからのものかを認識できる方が重要だ。(どのステークホルダーからかが明示的にどっかに書かれているか、暗黙に運用しているかは別として。) 機能要求と非機能要件を区別するのは、メトリクス取得メンバーがバグの分布などで利用する程度に考えていた方が良いとも言える。


ただし、非機能要件について書かれている本やホームページで、どんな要件が書かれているかは知っておいて損はない。機能要求は商品やサービスのドメインやユーザごとに異なることが多いが、非機能要件はドメインなどに依存しない項目が記載されていることが少なくない。それらが仕様書に書かれていなかったりテスト項目にない場合は、バグが多かったりバグの発見が遅くなったりすることが考えられるためだ。

非機能要件を仕様書に書かれてない項目と理解する人もいるようだけど、それはおかしい。作成するソフトウェアには非機能要件を実装しておく必要があるので、そのためにはドキュメント化しておくべきだ。該当する市場や装置で、常識的なこととして仕様書に敢えて明記しないケースはあるだろうけど。ただ、昨今のようにオフショアでソフト作成させたりテストさせたりするのなら、ドキュメントに掲載しておいた方がよい。(ちなみに、ドキュメントでなくてユーザーストリーで処理する場合は、非機能要件のユーザーストーリーで処理することになり、ここでのドキュメント記載はそれを含んでのこと。)


なお、”非機能要件”は”非機能要求”と表記すべきなどの意見もあるだろうけど、ここでは広く使われていると考える”非機能要件”とした。

”非機能要件のテスト”と大括りにせず、パフォーマンステストとか保守性テストと具体的なことで議論した方が良いだろう。その方が、それぞれの分野でのテスト技法の確立や効率化に結びつく。あるいは、”仕様書未記載のテスト”として、仕様書に書かれていない事項のテストをどうすべきかの議論をすべきだろう。個人的には、よほどの常識的なこと以外は仕様書に明記すべきと考えるが。 ちょっと気になったので、記載しておく。

11月 7, 2012 ソフトウェア, ソフトウェアテスト | | コメント (0) | トラックバック (0)

2012年11月 1日 (木)

「僕がアップルで学んだこと」

数年前から、時々品質関連の人と話題としたのが、アップル製品(当時だと代表的なのはiPod)の品質に対する感覚と自社製品を含む日本製品に対する感覚の違いは何?というもの。つまり、iPodを使っていると、(時々)音飛びが起きたりする。ところが日本製品だと、多分出荷NG。この違いはなんだろうかとか、判断基準をどう考えるべきかといった話題。実際アップルの製品を使っている人が少なくなくて、どう考えるか聞いたりした。

なかなか結論は見出せなかったが、アップルでの品質保証/品質判定の方法や基準は、その後も気になっていた。

左は、数日前に購入した本。著者の松井氏は、元・米アップル社品質保証部のシニアマネージャ。

実は、2,3ヶ月前とかに、本屋で手に取って見たことはある本。当時はパラパラ捲った程度だった。ところがiOS6でのアップル地図のゴタゴタをネットニュース等で目にして、色々検索。アップルの品質などの検索で、本著者の松井氏が引っかかってきた。そして、この本に品質保証部在籍当時のことが書かれていそうだったので購入した。内情暴露ではないだろうけど、ヒントになることが分かれば良いな~位の思い。

書評などでは、社内政治への対応やアップル回復のことが書かれている。それらの記載ページが多くて、品質保証絡みは所々。ただし、キーとなりそうなことが書かれていて参考になった。

品質保証部の役割は、品質を保証することではなくて、開発プロジェクトの状態を定点観測を行うということ。[P82] テストを行ってバグ分析をし、その製品がどの程度出荷可能レベルに近づいているかを測る。

バグ修正は重要度の高いものから行い、優先順の議論に時間が費やされることもある。[P79] また意見として、過剰品質を求めていないとの記載もある。[P84]

個人的には納得だし、優先順位の議論とかは知り合いなどの自分の回りで良く聞く話で、理解しやすい/当然と考える。

なお他に、マニュアルを少なくしたり無くしたこと[P69]や収益に対する研究開発費が2.3%と低いこと[P77]、デザインでブレが無いことと細部での変更とが書かれている[P64、P78]。

ちなみに、品質保証部門を担当した時の、メンバーの惨状の様子[P109]や整理整頓に心がけたエピソード[P112]に触れている。


先頭の方で記載したiOS6でのアップル地図問題は、iOSの開発統括のスコット・フォーストール上級副社長が来年退任するとのニュースで落ち着いた感じだ。代償が大きくなった。

実情は分からないが、松井氏が退社したことで、P109に述べてあるような惨状に戻ったのかも知れないとふと思った。また松井氏自身、今回のアップル地図問題をどう考えるか、彼のブログなどを注意しているつもりだけど書かれていない。(今は)書きにくいとか、書くべきではないとの判断かも知れない。 個人的には、アップル地図を出さざる終えない事情があるように思えて、申し送り事項(例えばαバージョン扱いにするとか)として明言などで対応する方法もあったように考えるのだが、、、、。

いずれにしろ、アップルを知る上で、個人的には読んで良かったと感じた本だ。


追記:以下の松井氏とのインタビューで、アップルも出荷判定会議をやってるとか、そのリハーサルの準備をした逸話が書かれている。

http://www.cyzo.com/i/2012/07/post_11040_3.html

11月 1, 2012 ソフトウェア, ソフトウェアテスト, 出荷判定, 品質, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2012年9月11日 (火)

TMMi Version4(Release1.0)

今日何気に、ソフトウェアテストプロセスの件が気になって調査。以前TMMi Version2のことをブログに書いたけど、Version4がアップされていた。

http://www.tmmifoundation.org/html/resources.html もしくはTMMiのトップページから。

Version 4.0だけどRelease 1.0と呼称するとの意味なのか、V4.0R1.0とのことなのかはっきり分からないけど、多分前者。今回レベル5の記述も追記された。なお、Version2とかではTPIとの対比が書かれていたけど、Version 4では対比の記載無し。

今回の調査でTPIも少しじっくり調査。ちょっと古いけど、日本語訳の本もあって再読。TPIはプロジェクトの実進行にも関係するようになっているので、前もってプロセスをどう改善しようか検討するためと考えると、ギャップがあるような気がしてきた。

TMMiの方がプロセス改善での参考になるかと思ったけど、ツールとか技法の観点では、プロセスエリアでのSG(Specific Goal)にはレビューがある程度で、後は計画とか監視と、ソフトウェア開発とかプロジェクトマネジメントで良く出てくる用語になってる。ただし、各プロセスエリアでは例が書かれている。例えば、「test deliverables」(PMBOKでの日本語を当てはめると「テスト成果物」となろうか)での具体例とか、アクティビティの例などである。それらを参考にして、改善での深掘りに役立てるのが良さそうだ。

9月 11, 2012 ソフトウェアテスト | | コメント (0) | トラックバック (0)

2012年3月23日 (金)

単体テスト/コンポーネントテスト、、、、、

ソフトウェアテストでのテストレベルの用語(の統一)は気になっている事項だ。ISTQB/JSTQBでは、コンポーネントテスト、統合テスト、システムテスト、システム統合テストなどがシラバスなどに記載されている。

ところが、自分の最近目にするソフトウェアテストに関する記事や論文では、単体テストや結合テストが増えてきた気がする。(開発系では、以前からほとんど単体テストや結合テスト。)

ソフトウェアのISO化などもあり、ちょっと気になって調べたり、確認してみた。まずソフトウェアテストのISO化に関しては、以下が公式的だし、まとまっていると思う。

ISO/IEC JTC 1/SC 7/WG 26の概要 http://www.itscj.ipsj.or.jp/tutorials/tu87.html

そこでの(2)に書かれている”テストレベルを特定しない”ことから、テストレベル自体の明示も行われないような気がしてきた。あるいは、他のISO程度しかレベル分けしないと思える。

そうなると、ソフトウェアの開発なりテストのプロセスは、ISO/IEC 12207 (JIS X 0160)を踏襲すると思われる。ISO/IEC 12207では、ソフトウェア詳細設計、ソフトウェア結合、システム結合、ソフトウェア適格性確認テスト、システム適格性確認テストという用語が明言されている。他に”コードの検証”という用語もある。ちなみに、”Integration”を”結合”と訳している旨が明記されている。

そうなると、テストレベルとしては、単体テスト、結合テストが、ますます定着するように思える。

ちなみに、Googleで”単体テスト”等での検索結果件数は以下。”ユニットテスト” が多いのは、xUnitの関連だろう。

 ・”ユニットテスト”     415000件
 ・”単体テスト”       323000件
 ・”コンポーネントテスト”  14800件

JIS X 0160の頃でも、ソフトウェア開発でのプロセス用語が各社各様で統一に役立つとの記述もあったが、結局そう統一されたわけでもない。また、規格では細部を決めたり例示することを避けている感がある。組織体では、効率や品質向上にためにプロセスを細分化した呼称を用いたりするが、ISOなどはそれをフォローしていない事になる。むしろISOやJISは、ソフトウェア開発/テストのキーの部分から、より広範囲を含めたライフサイクルやプロジェクトの規格化が進んでいる気がする。

組織体で細分化したプロセス呼称を用いる場合もあろうが、企業間での統一は考えにくいと割り切った方が良さそうだ。ただし逆に、他社との情報交換の際には、用語の確認をした方が無難だろう。


個人的には、JISの規格内で単体テスト、結合テストを用語として明示して欲しい気もする。(ただし、こちらが単に知らないだけかも。) また、自分としてはコンポーネントテスト/統合テストという言い方に少し慣れていたが、今後は単体テスト/結合テストを用いることが増えると思う。

3月 23, 2012 ソフトウェア, ソフトウェアテスト, プロジェクトマネジメント | | コメント (0) | トラックバック (0)

2012年3月11日 (日)

統合テストはフォーメーション練習?

以前から頭の隅にあったのが、統合テストをどうイメージした方が良いかということ。JSTQBでのテストレベルとして、コンポーネントテスト、統合テスト、システムテスト、システム統合テストという用語がある。一般的に使われている単体テストがコンポーネントテストに、結合テストが統合テストに該当するだろう。(ただし、企業やプロジェクトで、そうとも言えないこともある。)

各モジュールのソースに対するテストとしてコンポーネントテストがあり、全体のテストとしてのシステムテストがあることはイメージしやすい。しかし、用語としての統合テストは理解していても、実際のテストでは解決すべき課題が出てくる。

例えば、Aという人なりグループがA1、A2、、、、というモジュールを設計/コーディング。Bという人なりグループがB1、B2、、、、を、Cという人なりグループがC1、C2、、、、を設計/コーディングしているとする。ここでCは、汎用的なモジュールとする。

そんな時、A1とC1やC2との結合テストを行うか? 行うとして全ての組み合わせを行うか。また、AとBに関係し合うモジュールがあったら、それも全組み合わせテストを行うか、、、、。そもそもAとかBの中での統合テストを行うかなどである。(場合によっては、AとかBの中でのテストを、統合テストと呼ぶかも組織体やプロジェクトで異なるかもしれない。)

机上では全組み合わせテストを実施すべきだろうが、実際にそのようなことは行わない。(少なくとも自分の経験では。) そうだとして、統合テストをどうイメージしたらいいかが頭に隅にあった。


で、春になって、野球のキャンプとかを目にして、スポーツに例えるのが分かりやすいような気がしてきた。つまり、コンポーネントテストは、バッティングや守備などのある意味単純な練習。システムテストは、実際の試合。そうすると、統合テストは、フォーメーションの練習かなと。

バスケットやバレーボール、あるいはサッカーなどのチーム競技でも似たようなものだろう。水泳や陸上競技だと、リレーが近いかもしれない。走/泳順に応じた練習が統合テスト。走る順番や、走者/泳者を誰にするかで組み合わせが増えてくる。

フォーメーション練習では、メンバーの組み合わせを含めて、そう全部の練習をする訳じゃない。試合が近づけば、より実践的な練習にしていくだろう。

結局統合テストも、どの組み合わせをテストするかとか、全体テスト(システムテスト)に向けてのテストを意識すべきだろう。日程との調整や、そもそも統合テストの期間見積りが重要なのは言うまでもない。統合テストのためのダミーモジュール/コンポーネント作成の手間が膨大になりすぎては本末転倒でもある。

統合テストの際に、視点として機能に着目するのがよいと考える。ソフトウェアの単純な結合というよりも、機能テストとの視点。システムテストの前段階にもなる。以前、ここのブログの「”スクラム”の原典「ラグビー方式による新製品開発競争」」でフェーズの重なりに触れたが、PMBOK4版(日本語版ではP21)でもプロジェクトマネジメント視点でのフェーズ重なりの図が示されている。コンポーネントテスト→統合テストとフェーズがばっさり区切られるよりも、2つが重なっていたり、機能実現が追加されるイメージがよいだろう。

また、スポーツの場合に基本的な練習も交えながら試合/試合前に臨む事も、対比的に参考にすべきかもしれない。つまり、必要なコンポーネントテストや統合テストを継続していくことへの意識である。(当然ながら、自動化などで効率的に行うべき。)

参考になるか分からないけど、自分では良い見方と思えている。

3月 11, 2012 ソフトウェア, ソフトウェアテスト | | コメント (0) | トラックバック (0)

2011年12月29日 (木)

ソフトウェアテストの見積り

知り合いとのやり取りで、”ソフトウェアテストの見積り”がちょっと話題になったので、メモのつもりで残しとく。そもそもソフトウェアテストの見積りって、テスト項目数がどれくらいになりそうかとかテストのための人員数がどれくらいを見積ることだが、記載されてる例が多くない。バグカーブやソフトウェア開発での見積りと比較すると、書籍や論文への登場は、がくっと減っている。

「基本から学ぶテストプロセス管理」では、11章で”テストのコンテキスト -予算、ライフサイクル、プロセスの成熟度”のケーススタディで、少しイメージしやいものが掲載されている。(ROIに関しても言及しているが、市場で発見されるバグをそこそこの数としているから、日本人には違和感はあるかも。)

他の章ではテストラボの設備などにも言及しているので、ソフトウェアテストの見積りを考える上で参考になるだろう。昨今は、C/Sシステムにしろクラウド利用のサービスにしろ、テスト環境構築をどうするかは大きな課題だし、実運用外のシステムでテストする場合はそれなりのコストが発生するので悩むところかと思う。

「テストプロセス改善」では、”7.4 見積りと計画”でキーエリアとして見積りのことを述べている。

テストケース記述での工数の考え方(ただしある意味当然)が記載されていたり、テスト自体の比率(準備、仕様化、、、)の筆者による経験値などが述べられている。

「ソフトウェアテスト見積りガイドブック―品質要件に応じた見積りとは」の方には、さらに具体的にイメージしやすい掲載もある。特に東京海上日動システムスの事例。テスト工数の全体に占める割合という概算的な数値である。ただし、まずはその数値で金額的な見積りを行うことは有効と、個人的には思う。(もちろん積み上げによる見積りとの併用が望ましいが。)

他にこの本では見積りでのパラメータが豊富に記載されている部分も多いが、具体的な数値とのペアではないのでイメージしやすいかは? 逆に、自組織でいくつかのパラメータを採用して、計測したり市場トラブルやリリース後のトラブル数などと対比することで、見積り精度の向上に役立てることはできるだろう。

ITシステムに対する受け入れテストの工数予想は、開発ベンダーによるインストールからカットオーバーまでの期間に関係する。組込みなどを含めてソフトウェアテストを請け負う企業もあり、そのような企業にとっては請負の見積り金額に関係する。ソフトウェア開発を請け負う場合でも、自テストの工数を加味する必要がある。それらを考えると、精度を高める工夫(と同時に予想との差異分析やその対応)が必要なはずだ。

IEEE829 208ではレベルテスト毎の計画という考えを入れているので、各レベルテスト毎に見積って積み上げることで見積り精度は上がっていくと思われる。レベルテスト(テストレベル)という概念を取り込み、ソフトウェアテストのためのコストを見積ったり計測することで、例えばコンポーネントテストでの自動テスト化/自動テスト拡張なども判断しやすくなると考える。

12月 29, 2011 ソフトウェアテスト, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2011年12月16日 (金)

バグカーブの理想曲線

今朝のブログに引き続き、バグカーブ関連。具体的な(理想的な)バグの累積曲線を考えてみた。

前提は、今朝と同じく以下。

・バグは均一
・ソフトの生産性(修正スピード)は一定
・テスト件数のスピードは一定

以下の数値を設定するものとする。
・全体行数(初期のソースコード行数)
・テスト密度(行辺りのテスト件数)
・単位時間(1日の最大)テスト件数
・テストに対するバグ率

ちなみに、1バグに対する修正行は、テスト相当行数*バグ件数とする。
(テスト相当行数=テスト1件に相当する行数=テスト密度の逆数) 多少乱暴な仮定かも知れないが、修正とか修正確認などを考えると、それほどかけ離れているとも思えない。

1それをエクセルにしたのが左。(次の写真を含め、ダブルクリック等で拡大できる。)

a2: =F1
b2: =IF(A2>(1/$F$2)*$F$3,$F$3,ROUNDUP(A2*$F$2,0))
c2: =ROUND($F$4*B2,0)
a3: =A2-(B2-C2)*ROUNDUP(1/$F$2,0)

a15は、3960行のテストすべき行が残っており、1日10件のテストをしたので、100行分はテスト完了。ただし、バグが2件発生したので、その対策として20行テストすべき行として追加された事を意味する。(結果的に次の日=a16では、3880行のテストすべき行が残っていることを示す。)

2終盤が左。テストすべき行数が減って、テスト件数も減る。(テスト出来る件数分テストしても良いけど)テストで見つかるバグ件数も減って、追加される修正行数も減ることになる。

横軸をテスト件数、縦軸を累積のバグ件数とすると、当初からほとんどが直線(1次曲線)となり、終盤が減衰する曲線となる。それを理想カーブとして良いかと思われる。(行数前提への意見とか色々あるかもしれないけど、行→FPなどの場合でも考え方は同じになると思う。)

なお当然だけど、回帰分析などでカーブを求める場合、何らかの数式になっている方がよい。しかも、原点から連続したものが操作も楽である。今回示したカーブが、回帰分析で使えるような関数の格好になっていればいいのだが、すぐには見つかりそうにない。(もし判明したら、連絡もらえれば幸い。) 


捕捉:カーブが求まらないか、少し考えてみた。

3こちらは、終盤でのテスト件数やバグ件数を、整数化しなかったもの。

4こちらも、テスト件数やバグ件数を整数化しなかったもの。ただし、初期の行数を調整して、終盤で一旦(テストと行数の関係で切りの良い)100行にしたもの。

2つの終盤で、整数化しないことではっきりするけど、テスト件数がバグ率による等比数列になっていく。バグ件数も、バグ率による等比数列になっていく。

なので、バグ件数は、 k*a^x の指数関数となる。kは、終盤(最大テスト件数を処理する必要のない段階)での初期の値で終盤の行数に依存する。今回のグラフの例だと1から9かな。aはバグ率。 (表の意味するxはテスト件数により離散的だけど、テスト件数をlimで1件などに考えて行けば、指数関数と考えてOKそう。)

で、指数関数とすると、バグ件数の累積=積分も指数関数のカーブになる。(積分することで係数は違ってくる。特にバグ率は少数以下なので、係数がマイナスになることで上下反転する。) 

終盤のバグ累積件数を指数関数で近似するのは悪くないだろうが、テスト開始からを指数関数で近似するのは多少無理があるかもしれない。なっ、この辺りになると、実際のデータでの近似曲線間の決定係数の比較になるだろう。

結構自分なりには、すっきりしたかな。

12月 16, 2011 ソフトウェアテスト, 品質 | | コメント (0) | トラックバック (0)

"コーダーとテスターのパラドックス"

昨日Twitterのつぶやきで、信頼度成長曲線の話しにちょっと反応。こちらは、むしろテスト件数などの理想カーブに注目すべきと思って書いたけど、元々品質を測る信頼度成長曲線に注目してたようだ。って、元々そう書いてあったと言えば、そうなんだけど、、、。

で、ふと思ってこっちに補足的なことも含めて書いとく。

まずタイトルは、「アキレスと亀」をもじったもの。”コーダー”とせずにソフト開発者としても良いかもしれないけど、語韻と開発よりも製造に近いイメージがあるので、”コーダー”。ここでの”テスター”は、第三者検証のようなコーダーや設計/開発とは別チームでの検証の人。

「アキレスと亀」って、”ゼノンのパラドックス”とか”ゼノンの逆説”の中の一つで、ウィキなどにも書かれてる。 

http://ja.wikipedia.org/wiki/%E3%82%BC%E3%83%8E%E3%83%B3%E3%81%AE%E3%83%91%E3%83%A9%E3%83%89%E3%83%83%E3%82%AF%E3%82%B9

あるところにアキレスと亀がいて、2人は徒競走をすることとなった。しかしアキレスの方が足が速いのは明らかなので亀がハンディキャップをもらって、いくらか進んだ地点(地点Aとする)からスタートすることとなった。

スタート後、アキレスが地点Aに達した時には、亀はアキレスがそこに達するまでの時間分だけ先に進んでいる(地点B)。アキレスが今度は地点Bに達したときには、亀はまたその時間分だけ先へ進む(地点C)。同様にアキレスが地点Cの時には、亀はさらにその先にいることになる。この考えはいくらでも続けることができ、結果、いつまでたってもアキレスは亀に追いつけない。

この話は、高校の数学で取り上げられるケースが多い。無限級数とか収束。ネットで検索すると分かりやすい解説もあるので、興味あればそちらを。


で、ソフトウェアテストとの関係。アリストテレスをコーダー、亀をテスターと置き換える。そして、スタート地点でのことをテスターに最初に渡すバージョンでの何行かのソフトウェア、スタート後もバグ対策で何行かソフトウェアを作成すると考える。すると、追い越せるかは、テストが完了=バグ修正の行数がゼロになるかと考えればよい。無限に続きそうに思える点が、ゼノンの逆説とも似てくる。(テストでは、スピードを一定と考えるべきじゃない点は後述。)

ちなみに、ソフトウェアでの理想的なこの類を考える時の前提としてはいくつか考えられる。

1)バグはゼロ

理想という点では分からなくもないが、非現実的。

2)バグは均一

3)ソフトの生産性(修正スピード)は一定

4)テスト件数のスピードは一定

従来の信頼度成長曲線って、3)とか4)はあまり議論せずに、バグ残件がどのカーブにフィットするかの議論が多い。残件は終盤でゼロに近いので、成長曲線の類になるのは当然だが。それはそれで価値があるが、それを理想モデルと言うべきかは疑問のあるところ。また、検証サイドとしては、4)のテスト処理がスムーズに行われない原因を探るべきなのに、(論文や記事が信頼度成長曲線に関するものがほとんどなので)残件バグのカーブの方に目が行ってしまう。そんな気がする。

ゼノンの逆説の解法で分かりやすいのは、横軸が時間で縦が距離のグラフ。ただし、ソフトウェアテストのコーダー側の場合は、縦を行数として、追加行数を考える必要がある。コーダーの生産行数(スピード)はテスト結果の反映を考えて、テスト開始(t0)から追加行数自体は次第に減衰する。t1には、t0からt1直前までに発見されたバグ対策に相当する行数を生産していることになるため。これは(理想モデルでは)等比級数でOK。ゼノンの逆説でのイメージでは、アリストテレスは疲れてきて段々スピードが遅くなるイメージ。

ソフトウェアテストのテスター側は、横軸が時間で、縦軸が件数。これは直線で良いだろう。(回帰テストのことがあるけど、処理件数という点ではスピードは一定が理想。) 等比級数(等比数列の項の総和)は求まるので、バグ率によりトータル行数も算出できる。もちろん、テストが追い抜く時期も判明する。

ここでのテスター側は、回帰テストも含めてテストスピードが一定であることを前提としているが、ある意味目標かもしれない。Twitterでの返信でも書いたけど、そもそもテストの粒度の扱いをどうするかが悩ましく感じる人もいるかもしれない。また、いかに回帰テストを効率よくやるかも目標だろう。

なお、冒頭でバグゼロが非現実的と書いたけど、(第三者検証に対しては)バグゼロに近づける事を目指していることや、実際近づきつつあるのは事実。テストツールでの事前確認もそうだし、イテレーション毎に出荷できるリリースを目指す開発手法なども普及しつつある。なので、ここで述べた追いつくまでの期間や修正行数が、ゼロに近づきつつあるとは言える。


いわゆる信頼度成長曲線で(開発の)状況を分析するのは良いことだと思う。自分自身はアンチ信頼度成長曲線派でもなく、使うべきとの考え。また、対数曲線や二次曲線での近似も悪くないことを、このブログでも書いた。 

http://blog-honda.cocolog-nifty.com/gijyutuya_nikki/2010/03/post-4fef.html

ただ、信頼度成長曲線は信頼度を示すけど、ソフトウェアテスト自体の状況を示している訳じゃない。ソフトウェアテストの状況を知って改善するには、別の指標での監視が必要だし、理想での指標を頭にイメージしておくべきと言える。

12月 16, 2011 ソフトウェアテスト, 品質 | | コメント (0) | トラックバック (0)

2011年11月 8日 (火)

初期「受け入れテスト」

少し前に、何度か偶然「コンポーネント指向開発」が話題となることがあり、”コンポーネントテスト”と”コンポーネントのテスト”が気になっていた。コンポーネントテストはユニットテストと呼ばれるもので、ソフトウェアモジュールを分離してテストするもの。後者は一般用語にはなっていないが、ここでのイメージは、開発の際の市販を含めた外部のモジュールをテストするものである。

で、ここでの”コンポーネントのテスト”って、一般的な用語では”受け入れテスト”に近い。開発の最初の頃に、テストフェーズでの終盤のテストと同じような事を実施することになる。反面”受け入れテスト”と多少異なるのは、利用する部分のテストでも十分であることや不具合発見が開発全体に影響することが多いことだろう。(開発の中間や終わりに、中心的なモジュールが利用できないと発覚したら、システム設計自体の見直しにもなりかねない。)

ただその観点で、「受け入れテスト」(ただしコンポーネントのテスト)のテスト技法とかの議論を、あまり見かけないように思えてきた。特にテスト効率などの議論。その辺りが気になった。

で、調べてみたら、JSTQB(ISTQB)のFLシラバスでは、2.2.4. 「受け入れテスト」でいくつかのテストを述べている。FL:Foundation Level AL:Advanced Level

・ユーザ受け入れテスト
・運用受け入れテスト
・契約、および規程による受け入れテスト
・アルファ、ベータ(あるいはフィールド)テスト

また、「市販ソフトウェアプロダクト(COTS)は、インストールや統合時点で受け入れテストを実施する。」、「コンポーネントのユーザピリティの受け入れテストは、コンポーネントテストで実施する。」との記載もある。なので、ここで書いた”コンポーネントのテスト”は、受け入れテストと呼んでも良さそうに思う。ただしJSTQB(ISTQB)では、”受け入れテスト”はテストレベルでの1つとしており、テストレベルはテストフェーズの意味でもあるので、用語の概念としてすっきりしない。

ちなみに、JSTQB(ISTQB)のALシラバスの方では、受け入れテスト自体の細部に関してはFLほどには言及していない。

用語をすっきりさせるには、組織体で○○コンポーネント受け入れテストとか○○モジュール受け入れテストと呼んだり、多少一般化するのなら”コンポーネント受け入れテスト”という用語などを使った方が良さそうに個人的には思えた。


なお、懇親会の類では、特に海外製のモジュールに重大バグがあったり窓口対応が悪かったりで、開発スケジュールに大きな影響が出たなどの話は少なくない。そして、同じ社内のモジュールとか装置開発の遅れ起因がある。割合的には後者は少ない気がするが、起きてシステムプロジェクト側が責任を負わされたり犠牲になることも。同じ社内なので、責任追及しにくかったり、元々駄目チームと分かってても利用しないと行けない事情があるのだろう。

ちなみにコンポーネント受け入れテストで話題になるのは、以下辺りが多い。

・テスト効率
・負荷テスト
・非機能要件
・外部を含めたバグ管理
・スタブ作成チーム、テスト作業チーム形成
・テスト環境保存 (自動化でスクリプトを作成したらその保存なども)

最近は外部機器でもネット接続可能なものが増えたり、市販コンポーネントでもサンプルプログラムが付いたものも少なくない。パソコンを利用して、それらの機器やコンポーネントをテストすることは増えている。さらには、GUIやネット系の自動テストツールや画面操作再生ツールなどを利用すると、結構効率良いテスト環境を構築できる。組込みソフトウェア産業実態調査報告書などで自作テストツールの割合が多いが、今後は市販ツールの利用が増えていくと思われる。

用語がすっきりするのは良いことだが、結局この類のテストの重要性を感じているところは以前も含めて実施しており、何らかの呼称を行っているだろう。また、テスト自動化の議論と多少似てて、実施しているところはさらなる効率化を目指していて、一般的な議論は進みにくいようにも思えてきた。


補足:通常の受け入れテストが発注者側が主体であるのに対して、ここでの”コンポーネントのテスト”や”コンポーネント受け入れテスト”は機器やシステムの開発側/受注者側が主体となる。発注者、開発者/受注者の各々の目線でテストのフェーズを考えることが多いので、それも少し違和感が発生するのかもしれない。開発者/受注者目線で考えるなら、テストのフェーズとしては受け入れテストという言葉よりも、出荷テストとかカットオーバーテストの方が良いように思える。

11月 8, 2011 ソフトウェア, ソフトウェアテスト, プロジェクトマネジメント | | コメント (1) | トラックバック (0)

2011年10月28日 (金)

組み合わせ生成ツール Hexawise

久しぶりに、ソフトウェアテストの組み合わせ生成ツールのサイトを覗いてみた。いくつかツールが増えていた。

http://www.pairwise.org/tools.asp

最後に書かれていたのが、Hexawise。Webベースだし、フリーでも利用できるようなのでアクセスしてみた。

http://hexawise.com/

上のページでのビデオが、ちょっと参考になるかも。特に中盤でのGoogleマップの辺りが具体的で面白かった。

フリーで利用するにも、メールアドレスや会社名を登録。また、メールアドレスとしてGoogleメールアドレスは不可だった。

ただし、因子や水準に日本語表記を入れるとエラーになるので、個人的には利用は控えそう。因子ごとに重み付けが出来るのは利点だし、エクセルなどからインポートできそうなのも利点とは思うのだが。

10月 28, 2011 ソフトウェアテスト | | コメント (0) | トラックバック (0)

2011年5月10日 (火)

ディシジョンテーブルに対する苦手意識-2

「ディシジョンテーブル/原因-結果グラフに対する苦手意識」の続編。

どうやら苦手意識は、真理値表的な話と状態遷移的な話が混在して話されるケースがあるからと思えてきた。2つの記述を1つのテーブルで行うために、自分は混乱しやすい。

真理値表的な話なら、論理式による簡略化(圧縮)が可能だし分かりやすい。逆に、状態遷移的な話の場合、状態遷移表(など)を作成することで、状態の遷移や処理の流れをイメージしやすい。状態遷移なら、無限ループ的なこともあり得る。

ちなみに状態遷移表での記述の場合は、関連するツールにより、ロジック上の間違い検出やテスト生成なども可能である。ツールによってはテーブル圧縮を行ってくれるものもあるかもしれない。ただしロジックのレビューなどで人手で行うことが多そうに思える。(前のブログで述べたように、真理値表による記述であれば、それに応じたツールは少なくない。)

なお電子回路なら、真理値表的な話はANDやORでのロジック回路の世界で、状態遷移的な話はフリップフロップなどを含む順序回路の世界と考えても良さそうだ。

ディシジョンテーブルの上で、真理値表的な記述と状態遷移的な記述を混在させるのは、人や組織体の好き好きに思えてきた。個人的には、テーブル圧縮やテストの網羅性なども考えるのなら、2つは区別した方が効率的に思えるんだが。

5月 10, 2011 ソフトウェアテスト | | コメント (0) | トラックバック (0)

2011年4月23日 (土)

ディシジョンテーブルの圧縮

ついでに、ディシジョンテーブルの圧縮なり最適化も少し考えてみた。ある意味、簡易版。もとの題材は「デシジョン・テーブルを活用する」。”表を圧縮する”以降の部分。

http://homepage3.nifty.com/kaku-chan/q_and_p/decision_table.html

題材での表をGoogle Spreadにしたものが、以下。

https://spreadsheets.google.com/spreadsheet/pub?hl=ja&key=0At5_RJyc2TPhdHNDVVA5VHFJejVTMVNxRVdzWUlBelE&hl=ja&gid=0

操作などをしやすくするために、行/列を入れ替えたのが以下。

https://spreadsheets.google.com/spreadsheet/pub?hl=ja&key=0At5_RJyc2TPhdHNDVVA5VHFJejVTMVNxRVdzWUlBelE&hl=ja&gid=1

Google Spreadでもフィルタ機能を使うことでフィルタリングできるが、上のようなWeb共有ではできない。(ちょっと残念というか、わかりにくいけど。興味あれば、自分のSpreadやエクセルで試してもらえれば幸い。)


行/列を入れ替えた方が、テストする際のチェックシートと親和性があって分かりやすいと思う。規格と異なるので、文句言う人はいるだろうけど。 あと、入れ替えて、しかもテストケースを右の方に書いているケースもネットで結構目にする。個人的には、テストの視点ではその方が良いと感じる。

基本的なチェックとしては以下の項目だろうか。

・条件指定に、Y/Nがあるなど条件に矛盾するものがない。

これは行列入れ替えだと、各列での縦方向のチェック。

・動作指定部に、Xがないものはない。

こちらも行列入れ替えだと、各列での縦方向のチェック。

あとは、動作が同じものをまとめる事になるが、このためにフィルタリング機能は有益だろう。また条件指定部をソートすることも、漏れがないかのチェックには有益と考える。

「あたため」ボタンと「ふっくらパン」ボタンが排他的なことに気付くかは、その人によるかな~。この辺りとかロジックの矛盾を自動検出するのは、少し面倒だろう。逆に、(高信頼性の機器開発などでは)以前述べたツール類で行う方が不安感はないように思える。ただし、あくまでディシジョンテーブルベースで行う場合。

ちなみに例えばこの表で、”ユーザ指定時間”とあるのは時間の設定が伴う。ソフトウェアテストの感覚では、最小時間や最大時間をテストケースに含めたいだろう。この辺りが、設計寄りのディシジョンテーブルとテスト側でのでディシジョンテーブルを分けた方がよい(事が多い)ケースの代表と考える。設計寄りのテーブルでは、特に最適化を行えば、最小限のテストケースになりやすい。

また、ディシジョンテーブルの規格では、条件と動作については、記述は表に記載されている順番とするとなっている。テストケース6や12は、トースト動作の後にレンジ動作が行われることになる。この辺りが、真理値表と考え方が違うところだし、ディシジョンテーブルの表内での圧縮や最適を機械的に行うネックなのかもしれない。(あるいは、順序が関係することを明示的に示す、他の表記が良さそうに思える原因かもしれない。)


状態遷移表によるアプローチなども実験してみるけど、しばらく先になりそう。

4月 23, 2011 ソフトウェアテスト | | コメント (0) | トラックバック (0)

ディシジョンテーブル/原因-結果グラフに対する苦手意識

どうも”ディシジョンテーブル”って、今まで本格的に使ったことがなかったこともあり、ある意味では苦手意識を持ってた。ディシジョンテーブルに関係する”原因-結果グラフ(CEG)”とかについても同様である。(以下では”原因結果グラフ”と表記。なお”CFD法”という手法もそれらに多少関係するが、今回ここでは触れないことにする。)

多少「苦手意識のままじゃいかん」と思い^.^;、今まで使ってこなかった明確な理由があるのかと考えながら、ちょっぴりディシジョンテーブルなどを勉強した。忘れるといけない程度に、メモを残しとく。念のためだけど、あくまで自分の整理のためで、ディシジョンテーブルそのものとか、その題材を否定してるわけじゃない。

なお、ディシジョンテーブルは規格としては、ISO 5806、JIS X 0125:1986 「決定表」。


なぜ避けてきたかを考えたら、、、、。

・そもそも利用したことがない。使う場面に遭遇しなかった/遭遇せずに済んだ。

・ディシジョンテーブルは表計算ソフトとかを利用すると操作しやすいが、原因結果グラフは描画するのが面倒。あるいはそのツールがあるのか良くわからない。

・論理記述の十分性チェック、項目漏れや最適化(論理の再整理)が、ツールで利用できるとありがたいが、その議論を余り聞かない。

・原因結果グラフでは、否定の記号が”∽”を上下逆にしたマークだったり、ANDやORの記号に馴染みがない。電子回路ではNOTやANDなどの記号があるし、そちらの方が入力線が明確だしその類のツールの利用ができるだろうにとついつい考えてしまう。

・勉強会での事例が入場料のようなビジネスプロセス系の話が少なくなくて、(組込みを含めた)ソフトウェアロジックの確認の用途と少し違う感覚が発生してしまう。

・ディシジョンテーブルをモデルの一つと考えると、自分としてはどうしてもコード生成やリバースエンジニアリングの事が頭をよぎるが、その辺りに言及した話が少ない。

・仕様変更などを考えると、履歴管理や差分抽出が行えるべきだが、原因結果グラフそのものでは難しそう。(原因結果グラフのCSVファイルなどで対応するしかないようだ。)

まっ、小学校での分数でつまづいた子が、その後も馴染めないのと似てるかな。^.^;;;

なお、上の”ビジネスプロセス系の話”の項で述べた件は、たとえばJaSST'07 Tokyoでの「三賢者、テストを語る (DTvsCEGvsCFD)」ではこうである。(ちなみに本ミニパネルは、ソフトウェアテストの人たちには有名。)

http://www.jasst.jp/archives/jasst07e/pdf/A5.pdf

テーマ2が入場料問題となっている。PDFのP28、P30。個人的には、ソフトウェアでの観点で”入場券売機”問題と考え、1200円、1000円、600円、500円のボタンがあれば良い気がしてしまう。あるいは、半額ボタンと1200円、1000円ボタン。(処理的には押されたボタンの券を発券する、後者だと半額ボタンが押された後なら半額券を発券。)

逆に入場でのチェック手順だとすると、団体での人数確認とか年齢確認、県内在住かの確認方法などが書かれてそうに思えてしまう。(厳密なチェックかは別として。)

入場料のような事項をベースにしたものがディシジョンテーブルの事例に少なくなくて、自分はどうもそこで頭が停止してしまうようだ。つまり、なんで入場券販売機の話にならないんだろうと考えてしまう。(ちなみにビジネスなりエンプラ系でのディシジョンテーブルの利用に関しては多少後述。)


で、今回「それじゃいかん」と思い、勉強なりおさらいしたことをいくつか。

まず、ディシジョンテーブルなどの歴史的なこと。これは、ソフトウェアテストPRESS Vol.8の「テスト技法の歴史」に書かれている。例えば、GE社には1960年に、ディシジョンテーブルから直接TABSOLというコンピュータ言語へのソースコード生成の方法があったと。”TABSOL”、”tabular systems oriented language”での検索でも引っかかる。

原因結果グラフに関しては、Myersの著書で広く知られるようになったとし、TELDAPというツールや日立製作所でのツールに関しても触れている。これらのツールは1970年とか1980年。所謂グラフィック端末を利用するツールだったのではないだろうかとふと思った。なお、GEや日立などのツールが、今でも、しかも外販等されていてポピュラーな言語への対応や開発環境に組み込まれていたら便利と思ったが、どうやらそれは無理そう。

ただし原因結果グラフでのTELDAPというツールは、今は”BenderRBT Test Case Design Tool”として利用可能なようだ。(価格までは不明。)

http://benderrbt.com/bendersoftware.htm

http://www.stickyminds.com/sitewide.asp?ObjectId=4436&Function=edetail&ObjectType=TOOL


ディシジョンテーブルのおさらいも兼ねて、Myersの「ソフトウェア・テストの技法」を再読。多少1版、2版を比較したけど、ここでは2版でのページ数などで。

この本での事例は、メモリダンプ(メモリの開始番地、終了番地を入力して、その値を表示する)。P70。 ”DISPLAY”というコマンドで、第1パラメータが開始番地、省略されたら、、、、。といたって具体的な仕様記述。

しかも、考えられるテストケースが列挙されている。P79、P80。2つのパラメータの省略とか終了番地の方が大きい場合など。さらに言えば、”DISPLAY”コマンドでのエラーメッセージ3種類が示されていて、各テストではどのエラーメッセージになるかとの予測まで書かれている。ある意味では当たり前だが。

そしてディシジョンテーブルを元に、原因と結果の紐付けと同時に、テストケースとの関係を述べている。なおテストケース22はあり得ないというのは、22のテストでは最終番地が7FFFなので、結果が1行で収まることはなくてテストケース33での結果と同じはずであるとのことと思われる。

ちなみにP68では、原因結果グラフと、それと等価な論理図(論理回路図)を示している。

また読者に考えさせられる記述(P82)もあり、”DISPLAY”の実行で1行以内かそうでないかの視点が大事ということである。ある意味テスト項目の変更なり見直しの必要性の述べていると考えた。また、限界条件のテストケース(P63)やエラー推定で追加した方が良さそうなテストケースについても述べている(P84)。

「ソフトウェア・テストの技法」を読むと、開発~テストの流れとしては、ある程度自然に思えてきた。原因結果グラフも、動作仕様の検討の際にどの条件から考えていくかには悪くない考え(かもしれない)と思えてきた。

では何故「ソフトウェア・テストの技法」で触れているのに、使ってみなかったかだけど、、、、。昔だと原因結果グラフの描画ツールが身近にないこととか、既に述べたように図のアイコンに馴染みがないのが大きな理由だろう。

また本に書かれている”DISPLAY”コマンドの事例では、パラメータは2つでその解析部分は同じような処理となる。そうなると、後は省略時とか開始のパラメータの方が大きい場合程度のテストを行えば良いことになる。なので、こじつけになろうが、表にまでする必要はないと感じたかもしれない。


「ソフトウェア・テストの技法」を読んで、テストの網羅性確認などにはディシジョンテーブルは良いかもしれないとの視点で、ネットなどを再調査してみた。ポツリポツリとネット上にツールを見つけることができた。もっと本格的なものがあるかもしれないが、目に付いたものを紹介。(一部は、以前から多少知っていたのもあるけど。)

・「CEGTest」

http://softest.cocolog-nifty.com/labo/CEGTest/

ソフトウェアテスト関連の人たちには有名なツール。”CEGTest”での検索で、実例とか関連する話題も引っかかる。

ブラウザ上で原因結果グラフの作成ができ、ディシジョンテーブルも描画される。画面上でCSV文字列をペーストしたりすることでインポートやエクスポートは可能だが、基本的に画面上の操作のみと考えた方がよい。

・「Testlink」でディシジョンテーブルのインポート

http://d.hatena.ne.jp/mamecyan2001/20090727/1248682218

テスト管理ツールのリンクが可能であるとのことで、ディシジョンテーブルそのものの論理性のチェックや最適化は別途行うことになる。

・「PICTMaster」でのディシジョンテーブル

http://ameblo.jp/pictmaster/theme-10011516354.html

PICTMasterは、組合わせテストの生成のためのツールとしてソフトウェアテスト関連の人たちには知られている。ただし個人的にはディシジョンテーブルはロジックを表すものとの理解なので、組合せテストでの制約条件の操作でディシジョンテーブルを生成できる方法は、こんな事もできるとの範疇と思える。

・オラクルのツールで、ビジネスルール記述でディシジョンテーブルを利用できるようだ。

http://biz-tech-services.com/2009/12/24/%E3%83%93%E3%82%B8%E3%83%8D%E3%82%B9%E3%83%AB%E3%83%BC%E3%83%AB%E5%AE%9A%E7%BE%A9%E3%81%AB%E3%83%87%E3%82%B7%E3%82%B8%E3%83%A7%E3%83%B3%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB%E3%82%92%E3%82%B5%E3%83%9D/


http://thinkit.co.jp/story/2010/09/17/1762?page=0,0

・SAPでの真理値表に関するページ

http://help.sap.com/saphelp_46c/helpdata/ja/5b/d2331b43c611d182b30000e829fbfe/content.htm

単なる演算子の説明かもしれない。真理値表の(R3とかERPシリーズでの)利用方法などのページはすぐに見つからず。

・以下もビジネスルール記述ツールでの例

http://docs.redhat.com/docs/ja-JP/JBoss_Enterprise_SOA_Platform/4.3/html/JBoss_Rules_Reference_Guide/chap-JBoss_Rules_Reference_Manual-Decision_Tables.html

・モデリングツール「Enterprise Architect」でも、ディシジョンテーブルを使えるが、、、、

http://www.sparxsystems.jp/help/compose_business_rules.htm

ディシジョンテーブルそのものの論理記述の十分性チェックなどは行ってくれそうだが、ページの記述では良くわからない。あるいはコード生成の利用とかで判別するのかもしれないし、論理記述の十分性のチェックはできないのかもしれない。

いずれにしろ残念なことに(何故か)、Enterprise Architect Suite ビジネスモデリング版での機能で、(組込み系のための)システムエンジニアリング版では利用できないようだ。

・「デシジョン・テーブルを活用する」

http://homepage3.nifty.com/kaku-chan/q_and_p/decision_table.html

規格を踏まえての説明、表の圧縮などが丁寧に説明されている。


なお、ディシジョンテーブルは”真理値表”とも呼ばれ、論理回路を記述しチェックするのには利用されている。

・MATLABでの真理値表

http://www.mathworks.co.jp/help/ja_JP/toolbox/stateflow/ug/f32-95974.html

この後のコンテンツに、Simulink モデルでの利用が記載されている。

・組込みソフトモデリングでの特化ツール

真理値表記述が可能なものがあるようだ。

http://www.argo-s.com/ae/tuto/tuto.html

・ブール関数(論理式)の最簡形を求めるツール

簡単な論理式や、1出力に対する条件の最適を求める場合には有効。ソフトウェアロジックで利用する事は少ないと思われるが、参考程度に。

http://ahotoke.com/tools/qm/

・EDAツールでの最適化

回路の最適化、つまり真理値表での不要な部分の削除や最適な回路への置き換えを行ってくれる。ここでの記述は一般的なものだが、大抵のEDAツールには備わっているだろう。

http://www.takagi.nuie.nagoya-u.ac.jp/~ktakagi/kougi/eda/first/index.html

ここで記載した上やMATLABでの真理値表以外にも、EDAやそれに類する世界には、モデリングやさらには最適化そして自動テストの類のツールが非常に多い。このようなツールを利用するのも1つの手段かもしれない。実際、ソフトウェアの検証のために活用している記事や、これらのツールでの出力結果の書き込みなどもぽつりぽつりとあるように感じる。

・論理回路用ツール

いくつかの入力に対して出力を記述することで、論理式を出力してくれるものがある。論理回路では、「カルノー図」なるものがあるがそちらを表示してくれるものもある。以下は、フリーの例。

http://www.vector.co.jp/soft/win95/edu/se314587.html

ディシジョンテーブルでの1つの結果(ここでは出力)を本ツールなどで論理式として表示させたりは可能だろうが、複数の結果を含めてさらに最適化まで検討するとなると、EDAツールの世界になりそう。特にソフトウェアロジックの検討時には論理式は必要なことがあるが、テストの検討では記述の十分性チェックや項目漏れが重要だからだ。


で、結論めいた話。プログラム作成でのロジック検証としてのディシジョンテーブルは、使っている開発環境のツールにあれば利用しても良いかな~程度に思えてきた。無くてディシジョンテーブルを利用したければ、表ソフトで作ってレビュー行うとかも良いかもしれない。なお状態遷移表でも(完璧は無理としても)、できるかもしれないのでちょっと検討してみるつもり。 ちなみに個人的には、ロジック検証などをさらに厳密に行うには、形式手法を利用したり、動的な網羅率の監視などの方が有効に思える。

またどちらかというと設計時にディシジョンテーブルを使うのは、最適化まで含めてソフトウェアロジックをシンプルとするメリットを念頭に置いた方がよいだろう。複雑なままではメンテナンスに苦慮する。

ソフトウェアテストの方は、設計でのディシジョンテーブルを利用したテスト項目は、必須テスト項目と考えて状況に応じて追加しても良い/大抵は追加すべきであろう。特にエラー推測などは別枠にして、ディシジョンテーブル上は代表項目程度にする方が良さそうに思う。これは「ソフトウェア・テストの技法」でのエラー推定追加に関する記載にも関連する。ブラックボックステストでの利用では、ディシジョンテーブルはテストケースの検討には悪くないかもしれない。特にテストの限界条件を探るのには悪くない。

注意点は、テスト追加のバランス。特定部分だけに追加テスト項目が偏るのは芳しくない。(テスト結果での不具合が偏ってテスト項目追加するような事態だと、その部分の設計手直しが重要になるだろう。)

なお、設計時のロジック検討で、原因結果グラフのようなもので検討することは悪くないだろうが、設計者とか設計チームの好き嫌いに依存しそうだ。社内規定で原因結果グラフの提出が必須なら別だが、そうでなければ思考用のツールを利用が良さそうに感じる。設計時は、どうモジュール化するかとか様々な検討も必要なためだ。テスト、特にブラックボックステストでも同様と言える。ただ、項目の詳細化の際にはディシジョンテーブルのように、明確に項目列挙してみるのは悪くない。表にY、NやXを埋める前に、入力や処理の項目自体が妥当かの確認は行った方が良いだろう。

ただし、いずれにしろ、ディシジョンテーブルを作成した場合の項目過不足チェックは重要。表計算(エクセルとか)のマクロなどでも良さそうだ。こちらもちょっと考えてみるか、、、、。というか、既にポピュラーなものがどこかにあったら教えてください。

4月 23, 2011 ソフトウェアテスト | | コメント (0) | トラックバック (0)

2011年1月14日 (金)

JaSST'11 Tokyoでの「テスト設計コンテスト」

都合で出席できないけど、結構楽しみにしてるのが、JaSST'11 Tokyoでの「テスト設計コンテスト」。目黒雅叙園 1/26(水)。

http://www.jasst.jp/archives/jasst11e/session_11e.html#a5

仮想的な機器(魔法瓶)の仕様書を元に、テスト設計を行い、コンテストとするというもの。魔法瓶の仕様書は、結構詳しいというかポイントを押さえた書き方をしてあると思っている。

楽しみにしてるのは、

1)テスト設計書の具体的なものを、公の場で議論する事って少ない

今まで、あったらいいな~と懇親会の類で話したこともあって、期待してる。

2)どんな視点でのテスト設計書が出てくるか

ソフトウェアの分野では、組込み系。自分の経験をベースに言えば、この魔法瓶の仕様書には、基本的な要求とか商品性での重要事項がちりばめられている。それをコンテストの出場者が、どうテスト設計書に反映するだろうかと。

3)”テスト設計”での受け取り方

「成果物:テスト設計書 ※設計技法は問いません」の記載で、コンテスト出場者からのテスト設計書/テスト設計(仕様)書に大きな違いがあるのか無いのかも少し気になるところ。フォーマット(/記載項目)が自体が千差万別になるのか、フォーマットは似通ったもので記述内容が異なる程度なのか、、、、。


興味ある方は、コンテストに出場したり、会場に出向いてはどうでしょう。


蛇足:コンテストの後日にでも、現実の魔法瓶のソフトウェアテスト担当者や品質保証の人なんかとの、意見交換があっても良いだろう。事務局による催しでも良いし、雑誌社なんかの企画でも面白そう。現実の魔法瓶のテスト設計の方が相当進んでいるかもしれないし、逆にコンテストでの考え方が現実のテストに役立つこともあるかもしれない。あるいは、テストに関する視点の違いなんかも、我々には気になる。(”魔法瓶”に限定する必要は無いんだけど、コンテスト前ということもあって、ここでは敢えて明示しないでおく。)

1月 14, 2011 ソフトウェアテスト | | コメント (0) | トラックバック (0)

2010年12月31日 (金)

2010年雑記

大晦日なので、今年2010年に読んだ本や気になったことなどを書いてみる。読んだ後とかにブログに書こうと思いながらも、書くタイミングを失ったものが多い。(一部既に書いてることがあったら、ごめんなさい。)

・プリウスリコール

1月とか2月に話題となった、ブレーキの件。あくまでブレーキの件。個人的には、今でも(本来のリコールの定義で)、当初ブレーキの問題がリコール扱いに該当するか疑問という考え。

良い勉強になったのは、まずはマスコミでの扱い。結構細部まで内容を記載するマスコミもあれば、品質問題とか安心・安全に十把一絡げの所も。同じマスコミの会社や媒体でも、記者によって扱い方が違うのも興味深かった。後は、学者先生とか業界人の意見も色々。**さんは、そんな思考だったのかと人物像なりを考え直すこともあった。なお失敗学の畑村さんなどによる講演(パネルディスカッション)は、個人的には良かったとの印象。

トヨタの「グローバル品質特別委員会」設置や、その様子のビデオ公開など、消費者や世論へのアピールの動きは、当初少し驚いた。特に後者は、そこまでやるのかな~との印象。(くどいけど、あくまでプリウスのブレーキの件。) ただし今後のこの類の対応として、大なり小なり他の製造業の会社でも必要になってくるだろう。その意味では、注目しておこうと思う。


・トラブル対応としてのポイントバック

ソフトウェアトラブルおよびその対応で今年気になったのは、ネットゲームなどネット系アプリのトラブルの対応としてのポイントバック。従来慣れ親しんだ(製造業での)商品の場合は、返品とか返金に該当する対応。

ネット系のアプリケーションの場合は、そもそも”品”が存在しないし、無料の場合が多い。ただし、ゲームの場合は、”ポイント”が溜まったり、実貨幣でポイントを購入できるものもある。その場合のソフトウェアトラブルの損害とその代償をどう考えたらよいかと思っていた。

今年、ちょっと目に付いたのは、ポイントバックとか、ネット上の仮想商品の供給。

あくまでケーススタディとしての例示だけど、3月にmixiでのゲームアプリ「サンシャイン牧場」でゲームアイテムの個人掲示板が使えないトラブルが発生した。その個人掲示板は、ある意味有料のアイテム。不具合の修正も行われたが、無料で購入できるとすると共に、既に有料で購入した人には別アイテムがサービスされた。いくつかのキーワードで検索するとたどりついたり、キャッシュを見ることが出来るはず。

システムなりサービスを設計する際には、トラブル時の対応も考えた方が良い。その対応は、そのシステム/サービス内に入れ込むものもある。予備システムなどは典型例。他に、そのシステム/サービス”外”に設けるものもあるだろう。人手での代用も一つ。個人的には、システム設計の際に、トラブル時にシステム/サービス”外”の対応や必要ならその部分の検討を行うべきだと考える。

ちなみに、危険の大きさと効用の大きさを比較することが良く行われるが、あまりに数値的のみの比較での弊害として「フォード・ピント事件」があるので、留意。(危険の大きさとしては、このサイトでは残存バグの可能性が分かりやすい。ただし、「フォード・ピント事件」での危険は、車での構造欠陥。)


・電子書籍

今年は、iPadの購入を機会に、今までのドキュメントファイルの整理や紙情報→スキャンファイル化を結構行った。本のスキャンに関しては、どっか近くのコピーショップで行えればいいな~と探したり問い合わせしたけど、実際は見つからなかった。先々スキャンサービスの利用や、離れたショップの利用なども検討したい。


P6260019P6270023左側2つの写真は、購入した裁断機と裁断結果の様子。こんなものもAmazonで販売してて、Amazon経由で購入した。

実験兼ねて本や雑誌の裁断を行ってみたけど、2つ折りの雑誌が結構難しい。折ってあるところが三角形に近くて、そのまま裁断しようとするとずれていく。広げて、真ん中で裁断しようとしてみたけど、丁度真ん中だと裁断機の刀とホチキス部分がぶつかるので出来ない。少しずらそうとするにも、位置合わせが少し難しい。結局2つ折りの雑誌は、(今のところ)従来のようにカッターナイフで切断してる。

裁断機を利用しての自炊の経験から言うと、コンビニでコピーサービスとかがあるのなら、スキャンデータ渡しもやってくれても良さそうな気がする。まっ、媒体やネット利用可能とするかなど検討が多いのだろうか。ただ、調べた限りでは、カタログとかちょっとしたプリント物はスキャンサービスで利用不可。スキャナーを購入するほどでもない人達にとって有用だろう。

お試し的に、電子書籍をダウンロードしてiPadで読むこともやってみた。しかし、ダウンロード書籍に対する栞(しおり)やマーキングなどの機能でちょうど良いリーダーがなくて、つい遠ざかってしまった。個人的には、集中して読むなら、まだ紙の書籍の方が馴染む。

多少似ているが、日経新聞電子版も会員になっているが、プリントが制限されることで利用頻度はさほどでもない。会社からの帰りに、携帯で夕刊を読んでおく利用が一番多い。

また、 図書館でコピーが可能なのだから、電子データ渡しも検討して欲しいと思うようになった。デジタルデータなのが問題なら、低解像度にするとか認証などを設けても良いのかもしれない。少なくとも、一般的な書籍ではない例えば郷土史とか古文書とかなら課題は少ないと思うのだが。


・ソフトウェア進化

知り合いと、夏に少し話題となった。「ソフトウェア進化」に関する日本語論文もいくつかあるし、大学では「ソフトウェア進化工学」と称して工学的に研究しているところもある。イメージ的には、ソフトウェアプログラムがプログラム自身を自ら変更して機能を作り出すことや、ソフトウェアの外部変化への適応性がテーマになっている(と思っている)。

ただし夏での知り合いとの議論は、生物の進化と類似するのなら、生物進化そのものよりも、品種改良のような(人間社会にとって)能動的なことを検討した方が良いのかな~というもの。進化論学者さんの話よりも、農林水産試験場の研究員や園芸家のような人達の話を聞いてみたい感じ。有益そうなら、そのネタを仕込んで成長させてみるようなアプローチ。ソフトウェア進化よりも、ソフトウェア改良とかの言葉が良さそうに思えるとの意見も。ただし、「ソフトウェア改良」だと単なるデバッグみたいなので、用語的には一工夫いりそう。

あと知り合いとの議論では、DNAでの不要部分との類似性をどう考えた方が良いかも少し話になった。ソフトウェア進化ではそのようなものは、不要とか該当しそうな部分はなさそうと考えるのかな。あるいは、少しくらいバグがあったり、無駄と思える部分を用意してる方がいいかもとの話も。あくまで、DNAや進化論と類似性があるのではとの前提での話で、合意なり結論めいた話にはならなかった。


・社内伝道師(エバンジェリスト)

今年、ちょっと引っかかったのが「○○さんは、エバンジェリスト、、、、」という言い方。もちろん会社によっては職位として”エバンジェリスト”がある会社があるけど、そんな会社の人達とのやり取りじゃない。各自の会社でのスタッフ部門の人なり専門家の人の説明でのこと。

引っかかるのは、自分の周りでは尊敬の意味でが9割くらいだけど、残りが融通が利かないような意味で使われてる点。後者は一方的な説明だったり、別の考えとの妥協点を探ろうと相談してるのにその専門分野での考えを譲ろうとしない。また、各分野の説明をする時は良いんだけど、(分野間で多少矛盾する時に)その人なりの考えの統一性に欠けることもあるとも。それらにより、ある意味、弊害になることもあるらしい。

そんなことを気にして、伝道師(エバンジェリスト)と呼ぶより、 お坊さんとか小坊主、納所坊主(なっしょぼうず)など呼んだらいいのにと思った。伝道師が一神教系での用語で、他の考えを受け入れないイメージもあるためだ。日本でクリスマスや初詣を行うように、多神教系の言葉の方が良さそうに思えた。ただし、納所坊主って寺の会計とかを取り扱うお坊さんと知って、ちょっと適さないな~と。お地蔵さんも良いんだけど、じっとしているイメージが強い。

ただし、そもそも伝道師って、正教師の資格を持たない人のことと知った。正教師は、牧師さんのこと。また、伝道師って、物事のよさを伝える人の意味もあるようだ。(本来卓越した人を会社でも”牧師”と呼んでも良さそうだけど、用語的に宗教っぽ過ぎるので使ってないのだろうと推察する。)

伝道師(エバンジェリスト)と呼ぶべき専門家なら、現場への普及で余りに強制的に/固定的な考えを押しつけるのは似つかわしくないと思うようになった。


・i○○○は日本で作れるか

今年の受講した講演でスポット的に触れられたり、懇親会で会話になったもの。iPodだったり、iPadだったりしたと思う。日本の競争力低下の原因探りみたいな面もあったのだろう。とある懇親会で、その話題になったので、以下のことを述べた。
 

①日本だって作れる。作れないのはAppStoreなどの方。
ハードは、日本でも作れるだろう。細かいこととしては、アップルと同様に中国などでの製造で、日本での製造じゃ製造価格が割に合わない。また、じゃA4のチップを設計できるかとかがある。しかし、いずれにしろ、日本メーカーは、AppStoreとか緩い著作権管理は、心理的に発想しにくい。さらに言えば、ハードウェアチームとソフトウェア(特にシステム/ITを含めた)チームが、日本企業では協力体制になることが考えにくい。

②作れても商品化に行き着かない。
特に品質部隊や関連部隊とか事業部長とかが、出荷OKと言いそうにない。自分でもiPad買ったときに驚いたけど、電源ボタンが無い、音のボリュームも無い。社内でのレビューで、こんな設計なら色々文句が出るだろう。他には、PCとの接続とかネットワーク接続が前提。PC持ってない人やネットワーク接続できてない人を考慮しないのか!と怒られそう。さらには、同梱の説明書が薄いというか紙切れ。これだってマニュアル部隊から総スカンになりそう。


・「ガラパゴス化する日本の製造業」

2008年発売で、長く積ん読状態だったもの。講演等で日本の特異性を”ガラパゴス”と呼ぶことが増えつつあった頃の出版だったと思うので、タイトルに”ガラパゴス”を題した本としては早いほうだったはず。(ただし当時、”ガラパゴス”の話とAndroidの話とを一緒に聞く機会が多くAndroid採用勧誘のような受け取り方をしたせいか、この本を含め”ガラパゴス”関連本をほとんど読まなかった。)

今年日本でも各社からスマートフォンが商品化された。そこでふと、”ガラパゴス”騒動ってなんだったんだろうかと思い、この本を読むことにした。

当初予想では、日本の特に携帯などの特異性が多く述べてあると思っていた。でも実際は、韓国や台湾の企業に関する事項が結構詳しく述べられている。また、ある意味では必然だが、エレクトロニクス業界を扱っている。第7章「世界で勝ち抜くためのビジネスモデル」では、7つの条件を挙げており参考になるが、エレクトロニクス業界に関してのもの。8章は自動車業界に触れており自動車業界の課題も書かれているが、エレクトロニクス業界との関連が主になっている。

世界で勝ち抜くための7つの条件の冒頭が、”すり合わせ”の技術が活かせる分野としている。実は以前から、”すり合わせ”と”組み合せ”の技術論での2つの違いで悩むことが少なくなかった。この本で、”すり合わせ”技術の業界として自動車や工作機械とのイメージが強まった。自分の中で、”すり合わせ”技術=自動車・機会(業界)、”組み合せ”技術=電気(業界)と捉えてすっきりした。その基本的な気づきができただけでも、結構価値があった。

なお著者は野村證券の主任研究員であり、海外の企業情報が詳しいのも頷けた。ODM売り上げランキングや、実効税率の台湾・韓国メーカーと日本メーカの比較なども記載されている。台湾や韓国を含めたエレクトロニクス業界を考える上で、参考になることが多かった。


・「『失われた十年』は乗り越えられたか」

発売は2006年と、ちょっと前。「ガラパゴス化する日本の製造業」を読むうちに、こちらも面白そうと読んだ本。

”「失われた十年」を乗り切った自動車産業”と”自ら不況を招いた家電・電子産業”とを、章立てレベルで明言している。そこが結構、小気味良い。

海外に進出した中小企業も登場したり、タイやマレーシアの動向などにも書かれている。また、この本でも、”すり合わせ”の技術に触れており、その分野でアメリカ製造業は地位低下したと述べている。

この本では、アングロアメリカン型の考えに批判的な部分も少なくない。株主価値を前提としたコーポレートガバナンスなどである。そんな部分も参考になった。

12月 31, 2010 ソフトウェア, ソフトウェアテスト, プロジェクトマネジメント, プロジェクト管理, 日記・コラム・つぶやき, 書籍・雑誌, 電子ブック | | コメント (0) | トラックバック (0)

2010年11月25日 (木)

「立ち会い試験仕様書」

某つぶやきに、「立ち会い試験仕様書」って書かれていて反応したけど、その後思いついたこともあって書いとく。

実は最初、”受け入れ試験(受け入れテスト)”に近いもののことかと思った。ソフトウェアテストでは一般的には、「立ち会い試験」より「受け入れテスト」に馴染みがあるため。ただし、システム物件などで”立ち会い検査”と言うことがあるのを思い出した。ちなみに、Googleで単語検索したらヒットした件数は以下。

 ”立会試験”  2千くらい
 ”立会検査” 76千近く

”立ち会い検査”は、受注側の工場などに発注者が出向いて検査するもの。会社によるだろうけど、個人的にはその際の検査結果は、受注者側が用意するのがほとんどと思ってる。

なお、”受け入れ試験(受け入れテスト)”は、最終納品場所などに機械等を納めてのテスト。なので、その検査項目や検査の主体は発注者の場合が多い。(と思ってる)

ちなみに、個人的には、両方とも発注者側が主体的に意見を言うのが、最終的にはうまく行くケースが多いと感じてる。立会検査の場合も、受注者側が検査予定項目を事前に発注者に見せて、必要なら検査項目を追加する。そんなイメージ。

なお、「立ち会い試験仕様書」での”仕様書”には少し違和感を感じたけど、広く使われているんだろうか。立合試験計画書とか立合試験項目(表)とか立合試験結果報告書とかならさほど違和感を感じないが、”仕様書”がつくと何となく収まりが悪い。

”テスト設計仕様”という言葉があり多少は広まっているというか、IEEE 829などのSpecificationを”仕様”と訳さざるおえない。それを踏まえると、「立ち会い試験設計仕様書」だと、まだ分かりやすいのかもしれない。でも、なんか長ったらしいし用語としてえらく違和感が出てる。「立会テスト設計仕様書」は、なおさらおかしいように思えるし、、、。

ちなみに考えてみるに、”立ち会い検査”や”立ち会い試験”って、(ソフトウェア)テストチームが関与することが無い訳じゃないと思う。しかし、試験項目を発注者/受注者のどちらが書くかとか、受注者側が書くとしてどんな部署が書くかなどの議論が余りないような気もしてきた。ある意味、ちょっと良いテーマなのかもしれない。

11月 25, 2010 ソフトウェアテスト | | コメント (0) | トラックバック (0)