Personal tools
You are here: Home ブログ kaito
« November 2010 »
Su Mo Tu We Th Fr Sa
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        
Categories
小市民記
 
Document Actions

そろそろ冬


QG小林です。

最近QGの中ではテストのあり方についてよくミーティングが開かれています。

流動的に更新されていくテスト対象だと、以下の関係があるらしい。

・テスト内容の具体性

抽象的に書く:

利点)流動的に変化する対象においては抽象的に書くことでテスト内容のメンテナンス性を向上できる

欠点)抽象的に書くとテスト実行者によって解釈や精度が大きく異なる場合がある

具体的に書く:

利点)具体的に書くと実行者によるテストのムラが減少する(が、テスト量は増加する)

欠点)変化の乏しいテスト対象ならば問題はないが、変化が多いとメンテナンスが大変(絶望的)

・メンテナンス性

メンテナンス性を向上する:

利点)変化に対応してテスト内容をすぐに更新できる

欠点)重視しすぎるとテスト実行者の読みづらいテストになる?

とりあえず議題にあがったのはこのあたり。

現在のテスト内容はどちらかといえば具体的な内容に置かれていてメンテナンス性が低いので、ここをなんとかしようとしている模様。いくつかの改善案もある様子。

テスト精度とメンテナンス性がトレードオフの関係になっている?ようで、ミーティングではたびたび意見交換を交えながらどの程度のバランスでテスト内容を作成するかが議論の的なのだが、かなり難しい。

いったいどうすれば常に変化していく環境に対して、精度(実行者によらないもの)とメンテナンス性の両方を満たすことができるのだろうか?

・グループの意見をまとめて決定する民主政治がいいのか、一人の意向で決定する哲学政治がよいのか

・精度とメンテナンスはどちらが重要なのか(または両方を満たすにはどうすればいいのか)

・どのような規格でもってテスト内容を構築するのか

・どの程度のテスト精度であれば、人と時間を割いたときに過不足ないのか

自分が思いつくだけでもたくさん課題がある・・・こりゃむずかしそうだ。

思った以上にテスト内容の奥は深い。

話がまとまったら年末大掃除のような感じで一気呵成に作業したほうがよさそうな感じがするが、流動的な環境だとそういうのは難しそうだ。

よいテストの実行のためによいテスト環境を作ることは一筋縄ではいかない。

Category(s)
小市民記
The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/kaito/305d308d305d308d51ac/tbping

QGには何が必要か、何が不要か


前回に続いてオフサイトミーティングに向けて。

課題はQGをよりよくするためには。

とりあえずちょっとしたメモ。

・個人的な前提
目的:品質を向上すること
手段:バグを見つける、要望を出す、テストの精度を上げる

品質向上などに関して
・回帰テストは自動化できる
・自動化=工数削減 というわけではない
・自動化するのにも工数がかかる
・自動化の価値はテスト対象やリリース期間、回帰テスト実施回数に左右される
>テストケースの見直しや書き直し、その他保守性などについての検討はコストに対する効果が得られるのか?
 仮に行うとして何を主導として行うのか?(個人による主導なのか、グループとしての主導なのか)
 前者は即効であり、後者は遅効である 前者はうまくいけば問題なく、後者は前者より失敗しにくい

優先度、コスト、重要度に関して
・テストの優先度やコストに対してテスターは認知したほうがよいか?
・テストの重要度をテスターは認知したほうがよいか
・一テスターとしてこの内容に関与するとチーム全体に効果があるか?
>チーム全体の目標として上げられる
 遅れている重要なテストがわかれば個々でカバーにいける(個々で判断してよいのか?)
 テスト作業の方向性に関してグループで決定する必要があるのか?

テストエンジニアの育成に関して
・知識共有に対する個々の意見を聞くべき(どういう知識を共有するべきなのか、公表するべきなのか)
・チームとしての向上(抽象的過ぎるので検討するべきではない?)
・プロジェクトに配置されている人材は適切なのか?
・突然プロジェクトのテストを依頼される場合、どうすれば効率よくテストを行えるのか
・テストケースの設計について学習するべき?
>Verify精度の向上も狙える?
 個々で学習するよりもグループでの学習のほうがテストケースの規格が統一できてよい?

将来的に求められることに関して
・品質の保持には自動化が有効?
・品質の向上には何をすればいいのか(or何をやめるべきか)
>案のひとつとしてテストケースの修繕があがっている
・製品の売りをより伸ばすためにはどうすればいいのか?(一番難しそう)

とりえあえずQGとしてやる必要がなさそうなのが優先度、コスト、重要度の決定。

これはグループで関与すると面倒なことになるだけなきがする。

で、

求められること:
それなりに即効性があり、継続して効果が保たれるもの。

テストケースの設計について学習した場合次の効果が得られるのでは、と思った
・Verify作業時、スモークテスト時、リグレッションテスト時に担当テストの妥当性が図れる?
・追加したテストケースによるテストの効果があがる?
・今は行われていないけどテストレビューをやるときの効果があがる?
・メンターを行うときのアドバイスにより具体性が増す?

他の人たちにはどんな考えがあるんだろうか。素人ながらQGに貢献できれば・・・とは思うけれど、難しそうだ。

Category(s)
小市民記
The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/kaito/qg306b306f4f555fc58981304b30014f554e0d8981304b/tbping

Re:QGには何が必要か、何が不要か

Posted by inoue at 2010-11-10 23:35
自分の頭で考える態度は素晴らしいと思います。これからも続けてください。考えるだけだと妄想と紙一重なので実践してそのフィードバックを盛り込んでください。かつ、自分ひとりの体験は狭いので視野を広げるために本を読んでください。この3つ(自分の頭で考える、実践する、本を読む)のループを回せれば、怠惰なおっさんを3年で抜けます。

当たり前なことのほうが改善点がある?


こんなのをみかけました

http://www.nikkeibp.co.jp/article/column/20101008/247951/

オフサイトミーティングの議題を決めるために

・視野を広げて(QGチーム以外のチームに対して、など)

・現行の問題点

などを洗い出しの作業が進んでいる。

そしてどうもこの観点からだとなかなか意見が出せない。

かといって今まで当たり前だと思っていた事柄、作業、仕組みに対して意見が出せたわけでもない。

果たして、現行の問題点を探すことと、現行そのものにものを申すのと、どちらが建設的で効果があるのかはわからない。

だけど、自分が仕事を始める前からこうだったわけだし・・・という感じで、当たり前に対して当たり前を受け入れすぎていたのではないだろうか。

次のミーティングで踊ることにはなるだろうけれど少し当たり前の事柄に対して考えてみようと思う。

Category(s)
小市民記
The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/kaito/5f53305f308a524d306a30533068306e307b30466539558470b93042308b/tbping

人と人の間には何センチ必要なのか


QG小林です

オフィスが六本木に移動になり、すごく広くなりました。

が、QGの島はむしろ狭くなったようにかんじます。

今現在人と人の間には4,50Cmほどしか距離がなく、非常に落ち着かない・・・

慣れの問題だろうか。

慣れの問題といえば通勤時間が4倍になったのもつらい。

元が短すぎるとはいえ・・・

Category(s)
小市民記
The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/kaito/4eba30684eba306e9593306b306f4f5530bb30f330c15fc58981306a306e304b/tbping

Copyright(C) 2001 - 2006 Ariel Networks, Inc. All rights reserved.