ひとりごと

  • 2011.07.11 Monday
  • 03:08

 
TEF参加者としてたいしたことが出来ていないので,
JSTQBのFLでも自腹で受けてみようかと思ったが受験料見て挫折(笑)

Oracleとか有名ベンダ試験ほど高額ではないが,
でも,テスターの環境改善,品質向上の為に自己研鑽に励む自腹勉強者の為に
受験料は5000円から8000円位にして欲しかったり。で,年二回とか。
あ,TEF参加してると割引用の特別コードをもらえたりとか?(笑

IPAで資格試験作ってくれないかなぁ。。。ってまだ無理か?

ただでさえ学術書寄りの資料一つ一つの価格が高いので配慮して頂けると,
精神論から抜け出せないテストエンジニア達に勧めやすかったりするかも。

#てことで8/27はPyConに行ってこようかと。

本体のソフトウェア品質確保のため

  • 2011.07.04 Monday
  • 01:28
シャープ、AQUOS最上位機「L5シリーズ」を発売延期
−ソフトウェア品質確保のため8月5日発売に

http://av.watch.impress.co.jp/docs/news/20110701_457615.html

6月の製品発表時には、7月15日の発売を予告していた。
発売延期の理由については「本体のソフトウェア品質確保のため」としている。


あのシャープさんが延期するんだから死者が出たんじゃないかと心配したり。(汗
まぁ、廃人は発生したでしょうな。

なんでこうもまぁどこも殺人的なスケジュールになっているのやら。
節電支援でリリーススケジュールももう少し製品を愛し、家族を愛せる
スケジュールにしないと志気は下がり浪費が増えるに決まってるじゃんか。

NTTやらHONDAやらの研究所は相変わらずのんびり楽しくやってるのかなぁ
最近その方面との接触がないので、ふと昔を思い出して思った。

※いや、きっかけは「ソフトウェア品質確保の為」という説明は
誰向けの説明なのだろうと思っただけなんですけどね。
感想が先走ってしまった。

ソフトウェアテスト楽しいですか?

  • 2011.05.28 Saturday
  • 18:12

 先日、単純バグを見逃して大目玉食らったシステムテスト部隊の反省会を拝聴した夢を見た。

各社の反省で挙がった対策案。

1. 他グループ担当の機能にまで関心を持つ
1. 危機感を持って頑張る
1. プロ意識を持って頑張る
1. 納得できるまで試験する

全体の総轄では

1.項目試験を極力抑えて使い込み試験を強化
1.「これは自分がつくった製品なんだ」と胸を張るプロ意識を持って試験をすれば、
  どんなにどろどろくたくたになっても頑張れる。

結論:

頑張りましょう。

というものだった。此処まで問題のなぜなぜ分析もなし、
ソフトウェアテスト関連書籍を読んでいそうなキーワードも出現せず。
「最後の砦」という役割が強調されていたが、
満足な武器無しで本土決戦に望む一般市民とそれを鼓舞する軍を見ているかのようだった。


・・・という夢だった。かなり驚いた。

(続く)

Test Case Manager その後とTestLinkなど

  • 2011.03.03 Thursday
  • 01:46
 Test Case Manager で検索して来られる方ごめんなさい、という記事を書いて久しいが、
アクセス解析によると、3月1,2日で約150ユニークユーザ、この3ヶ月で3000強の
ユニークユーザが記事No.18へアクセスしてこられている。
なんでやねん?
一般的なキーワードだから?
ソフトウェアテストPressのバックナンバーを読み始めた人が多い?
と思って自分も検索してみると、上記に加えて、
OpenOfficeのテストケース管理も同じ名前という事情もあるように思えた。
こちらは未調査。

ちなみに、Test Case Manager の開発元が使用していたドメイン pb-sys.com は
ただの広告サイトになっている。
左側に表示されるリンクはテストケース管理の情報を期待して訪問するユーザの多いことを示しているのだと思う。

ところで、先日、TestLinkを作業用PCにインストールしてみた。
和田さんのTDDのように、ひとりででも始めて成果を出したいと思って。
スケジュールと割り込み作業に追われてまだ試せていないのだけど。

先日のデブサミではRedmineとTestLinkをリンクして活用する記事も載せられている以下の書籍があったので購入して参照中。


Redmineによるタスクマネジメント実践技法
小川 明彦 阪井 誠
翔泳社
売り上げランキング: 7592


検索してみるとこんな記事もあった。

プロジェクト管理システムredMineとTestLinkの統合手順
http://testlinkjp.org/modules/pukiwiki/?Benri%2FTestLinkRedMine

第5回 脱Excel! TestLinkでアジャイルにテストをする
http://jibun.atmarkit.co.jp/lskill01/rensai/tool10/05/06.html

以上、メモ書き!

JaSST '11 Tokyo 1日目

  • 2011.01.26 Wednesday
  • 00:26
JaSST@目黒雅叙園。行ってきました。
 
1日目。

セッション内容の感想:


●基調講演。
朝、妻の体調が悪く途中から参加。
通訳の方の声質が2人互いに似ていて聞きやすかったのと、
「crap」を一瞬間を置きながらも直訳した英断が印象的だった。(笑
内容はテストのトレンドを総轄してくれるものだった。
James A. Whittakerを強力プッシュしていたので読んでみようか。


●テストプロセス〜積善のプロセスに余慶あり〜
最初の学生さんの発表は、研究のゴールが明確でなく、サンプリング手法や
取得データの正当性の説明もなく、「今ここで何故それを説明されているのか?」
理解できない聴衆を置いてきぼりで秋山さんのセッションにゆくべきだったかと
一瞬思ったが、質問タイムで聴衆から適切な質問、指摘がされプレゼンレビューされた。
「そうか、文句を言わず若手を育てる場として積極的に参加すればよいのか」と
感心。彼らが今後業界を支えてくれる。成長してくれるのを楽しみにしています。

こやまさんと永田さんのセッションは興味深い話題で楽しいセッションだったが
うとうとして十分参加できず。


●手動でのテストに「革新」をおこせ!
自動テストケース作成とテスト実行のを支援するツールと
バグ発生時のキャプチャやログの取得・保存が効率的に出来、
開発者に伝えやすいというツールの話し。

ここら辺のツールは、
・試験工程の成果物フォーマットへの転記が容易でないとそれがバグの元になる
・既存BTSとの親和性が高くないと使う気にならない
・単に「自動でテストできる、けど手でやった方が早いという人もいる」と
 言っていては駄目で、「自動テストでリグレッションテストをぐるぐる回して、
 不具合修正後確認もリファクタリングも楽ですよ」と言うあたりを
 大いに推進していかないと意味ないんじゃないかと思われ。


●ライトニングトークス〜ととのいました!テストとかけましてぇ〜

今日では一番面白かったセッションだった。
AgileJapanでもあったけど、ワークショップは恥ずかしいけど楽しい。
でも、「ワークショップ楽しみにしてきましたか?」と尋ねられたら、
手を挙げて目立ったら何をさせられるか分からないので挙がりませんよ(笑
でも、周囲の人のノリを見ると、明らかにLTワークショップも楽しみにして
きたのだろうと確信させられた。

自分はあほなんで、配られた紙をただの原稿用紙にしていたのだが、
同じグループの大半は、ちゃんと紙芝居的に皆に見てもらえる絵やら語句やらを
描いていた。こりゃ明らかにLT調べてきてるって(笑

ちなみに、自分のグループは、
・リサーチ会社の社内SE2名「まともにテスト仕様書を書いたことがないので
 勉強に来た
・業務管理のポータル作成SE
・新潟方面の上流SE「ちょっと行ってこいって言われてみたらJaSSTだった」
・組み込み方面、ペアプロ、TDD実施
・JaSSTは久々、SQiP方面は常連

という方々だった。人数がやや少ないのを聞いていたこともあって、
「ワークショップなんざに集まる奴は志高い奴だ。どんな奴らだろう」と思って
いたら期待通りだった。


その後の招待LTは咳さんが調子狂っていたものの圧倒的にそれぞれがこなし、
あとは、歌えや踊れやで和田さん、ナガタさん、師匠がパフュームの替え歌で
踊っておった。業務に戻ったら和田さんにお礼言おう(笑
ナガタさんは振り付けをちゃんと練習してきたっぽいなめらかな振りだった。

ちなみにLTワークショップで自分は継続開発とテストの話しをしたら、あとで
上流SEの方が「うちも同じ。自分の現場も改善できればと努力している」と
激励に来て下さった。

●思ったこと
製造工程の次の品証としてのテストと、製造する為のテストが
明示的に区別して語られていないことがあり、
そうすると開発者視点なのか、テスター視点なのか分かりにくく
新規参加、初心者の混乱の元になるのだろうなと思った。

●その他
日科技連の書籍が2割引!(現金払いのみ)
他社も1割引(カードOK)

●こんな本を買った

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際
秋山 浩一
日科技連出版社
売り上げランキング: 43297

なぜなぜ分析10則―真の論理力を鍛える
小倉 仁志
日科技連出版社
売り上げランキング: 55562

失敗学と創造学―守りから攻めの品質保証へ
濱口 哲也
日科技連出版社
売り上げランキング: 86196

あれ?ほんのイメージが出ない(汗

今日はJaSST'11 Tokyo

  • 2011.01.25 Tuesday
  • 02:59
 久方ぶりに参加。今回も有給休暇使って自費参加。

「検証は単価が安いから」と括ってしまい、テスティングスキルの向上に対する理解も
支援もないことへ愚痴りたい気持ちを抑え(笑)、
志の高い会社との、志の高い人々との交流を通して刺激と明日の活力を得てこよう。

ますます予算が削られ納期も短くなり並行プロジェクトも増える中での派生開発において、
ドキュメントの改善、レビューの改善、テストの改善、をどの様に盛り込んでいけるのか、
アジャイル的な、TDD的な改善をどの様に周囲の理解と協力を得て盛り込んでゆけるのか、
ヒントが得られたら嬉しい。

テスト仕様作成

  • 2010.06.19 Saturday
  • 10:45
テストの手法や用語(境界値だのカバレッジだの)については大分見慣れてきたけど、
実装に追われている傍らでテスト仕様の作成をすると、
疲れているのと忙しいのとで頭が回らず、網羅の手を抜きがち。
テスト作成の適正な工数見積もりってあるんだろうか。

と、twitterレベルの記事を書いてしまった。orz

(追記)

ブログを見てくれた師匠から直電。ありがたや。

提案してくれた内容としては、
・テストすべき項目の網羅については、仕様をマインドマップに書き出していって、
足りない点や気づいた点を都度埋める。
・テストのカバレッジについてはテスト内容や対象にプライオリティをつけて、
作成可能、試験可能な範囲をエビデンスを残してコミットする。
Jasstの講演内容を思い出させてくれた。

現在の仕事場が、ツールを使うためには申請をせねばならず、
「あるもので出来ることをすればいいか」と思っていたら、いつの間にか改善を持ち込めずに
要求だけどんどん増えていって残業も増えて効率も落ちてと悪循環になっていた。

今の現場は仕様がしっかり定まらないうちに期限に追われて次の工程に進むので
後から後から不明点がでたり仕様変更が来たりして、その対応と、試験作成、実施が並行してしまう。
機能を担当したばかりに、適当な仕様のままで引き継いだばかりに酷い目に遭う。

師匠からのありがたいメッセージを思いに、
週明けしっかり業務を見直して対応していこう。

テスト設計書をつくる

  • 2009.12.15 Tuesday
  • 23:34
携帯電話アプリの開発に関わるようになって早2年。

今まではメイクの最中に次の試験フェーズのためのCT,IT項目仕様書を作成していた。
修正内容の規模に応じて項目数ありきで作成。作成の仕方が結構やっつけになっていたが、
テストの実施が完全人力だったので、その過程で不具合を割と洗い出せていたように思う。
後は、ST部隊で問題処理票を上げてもらって対応していた。
ただ、修正後のリグレッションテストが手薄で、
そのためコード改善、リファクタリングはほぼ無理。

APIの修正にしても、C++なら引数の追加はcall前のスタック積み増しにすぎないので問題ないはずだが、
グローバル変数を用意され絶句したこともあった。
修正部分に不具合があったら責任がとれるのか、という不思議な論理。

おっと愚痴になったorz

本来開発側のユニットテストはリポジトリから引っ張ってきたソースでの
dailyビルドやweeklyビルドごとに自動で全実施し、
NGなら自動でBTSに登録、開発者に通知されるものだろうし、

開発の過程でのノウハウはWikiなどに参照検索しやすいように蓄積され、
同じ事ではまる人を減らすなど工夫が出来るはず。

そんなことを思いながらも、時々口にしては「そんなのいらないじゃん」と一蹴されていた。

しかし最近、開発する機種が増え、同時開発数の増加、工期の短縮、後工程での
フレームワーク大改造恒常化により、修正は少ないものの全機種対応が必要な当グループは、
従来の開発プロセスの非効率、担当アプリのスパゲッティープログラムデザインの影響が
作業遅延に現れるようになり、顧客の厳しい指摘により改善を盛り込まざるを得なくなった。

メイクの方は大分フレームワークが分かってきたので比較的適切なデザインでの作成、
ないしアドバイスが出来るようになってきた。

加えてテストの改善。

テストのデザインを早期に始め、テストしやすいデザイン(外部コンポーネントのインタフェースに
ラッパをかぶせるなど)をメイクに盛り込みたい。
また、上記のようなデイリービルド→自動テストの流れを作り、リファクタリングも盛り込みたい。
などと考え、まともにテスト設計をさせてもらうことにした。

さて、設計書を書こうと筆を執ったのはよいが、資料によると作る仕様書として、
テストプラン(概要)、テスト詳細プラン、テスト項目仕様書、テスト実施手順仕様書など、
本当のゴールである高品質化や効率化より、手段が目的化してしまいそうだった。

そこで、現在思案中。試験実施期間はもう目の前。
がんばりどころだ。

Google Chrome と テストファースト

  • 2009.06.10 Wednesday
  • 00:04
GDDJ2009 の chromeについて語るセッションの最後に、
プロジェクトのファイル構成についてグラフで見せてくれた。
 総ファイル数が約88000。うち、レイアウトテストに関するファイルが7万強。
 そして、それを拡張子別でグラフにしたのが以下。
 chrome ファイル分類

一番左が、レイアウトテストを含むテキストファイル。 画像ファイルもテストで使用。

極力自動テストを心がけており、リグレッションテストは欠かさないそうだ。
バージョン管理に登録すると自動ビルド・自動テストを行ってくれるツールも 紹介してくれていた。

 配布された小冊子にもテストのことが記載されていて興味深かった。
 内容については後日触れたい。

自分の現場も、そういう開発が喜んで受け入れられるチームにしたい。

直交表LT

  • 2009.04.17 Friday
  • 12:48
お客さんに、直交表についてのLTを連発してもらった。聴衆私一人。
2^n直交表の作り方、拡張の仕方〜線点図の書き方まで何とか分かった気に。
多水準直交表の手作りの仕方がなんとなく。
線点図見てを作るところがあと少し。

理解してまとめるぞ!
久々にお役立ちネタがかけそうで嬉しい。
コミュニケーション大切!アウトプット大切!

calendar

S M T W T F S
   1234
567891011
12131415161718
19202122232425
262728293031 
<< July 2020 >>

Google サイド広告

selected entries

categories

archives

recent comment

recent trackback

profile

search this site.

others

mobile

qrcode

powered

無料ブログ作成サービス JUGEM