技と術と芸で考えるソフトウェアテスト

このエントリーは、「Software Test & Quality Advent Calendar 2011」の12/23分として書いています。

前日の12/21は、@takanorig さんによる「JaSST 10th Anniversary」でした。

僕は普段はソフトウェア開発とそのマネジメントをしていますが、ソフトウェアテストに関する活動・勉強会をしています。その中で「WACATE」と呼ばれる若手テストエンジニア向けのワークショップの実行委員をしています。今回のエントリーは、昨年のワークショップで少し話をした「技と術と芸」について個人の考えとしてまとめたものです。

同値分割やデシジョンテーブル、直交表などを一般的にはテスト技法と呼びますが、「技法」ってなんだろう? とふと思ったのがきっかけでした。そして、技法、技、技術、・・・、といろいろな言葉を調べていて、「技」「術」「芸」の3つについて自分の中での定義を作り、ワークショップの最後に発表しました。

※もともとはウィキペディアに記述されている定義を参考にしています。

まずは技(わざ)。

Waza

技(わざ)とは、「特定の目的を持ち、その目的を果たすための手段・手法」、である。絵にもあるように、関節を攻めるための関節技のように、具体的な目的・標的があって、それを実現する手段である。逆にいえば、目的が合致しない場合はその技は効力を発揮できない。テスト技法と呼ばれるもののいくつかは、この「技」に分類できるのではないか。

次は術(じゅつ)。

Jutsu

術(じゅつ)とは、「技を体系的にまとめ、改変が施されて流派に分かれたり、統一されたすべ」、である。技よりもより体系化・フレームワーク化・パターン化されたり、いくつもの技の連なり・組合せを表すのではないか。テスト技法でいえば、テスト条件を同値分割を使ってグループ分けし、その境界値を狙う、といったものが当てはまる。戦術、あるいは戦法といった言葉に近づくイメージである。

最後は芸(げい)。

Gei

芸(げい)とは、「個性的・独創的で継承することが困難だが、作品を確認することで業績を知ることができる技能
、である。結果については驚異的であり、劇的であり、感動すらありうるが、途中のプロセスはやや隠ぺいされているため、真似ることや教えること、説明することが難しい。当人にとっては理論的だが、それらの一部に飛躍が多いのかもしれない。

==

この3つについては、ある種の状態遷移というモデルが当てはまるのではないかと思いました。

Stm

「技」は鍛錬によって使い手のスキルとして身についていく。そして、「技」は体系化という行為によって「術」に変わる。技を覚えるだけでは、実践では役に立たない。それらを適切な場面、標的に使うことではじめて武器になる。また、「術」は使い手が日々磨きをかけていくとともに、アプローチの違いや特徴を持ち始め、流派が生まれることがある。

また、「技」は突如、独創性や直感的なエッセンスを得ることで「芸」に変化する。誤解を恐れずに言えば、突然変異かもしれない。そして、「芸」の驚異的な結果をどうにかして使いたいと思う。そのためには、「芸」を分析して、特定の切り口が解明されてくると、それはツール・道具となり、状態は「技」になる。

他にも遷移はあるかもしれないが、こういった「技」「術」「芸」の移り変わりがあってこそ、新しい考え方や概念が生まれ、ソフトウェア開発の質が向上し、ひいてはユーザへの価値が高まるのだ。

テスト技法やテスト手法を学び、プロダクトの品質を向上させつつ、こういった「技」「術」「芸」を磨くことも忘れてはならないなあと感じました。

| | コメント (5) | トラックバック (0)

レビュアー7つ道具

自分はまだまだ熟練エンジニアとはいえないのだが、チーム内では比較的経験年数が多いほう。なので、レビュアーをお願いされることが多い。主に、設計レビューやコードレビュー、テストケースレビュー、メンテナンス手順レビュー。そういうレビュアーをするときに意識していることをQC7つ道具になぞらえて、レビュアー7つ道具という名目でまとめてみた。



  1. チェックシート

  2. 「チェックシート」は2つの用途で使います。一つ目はレビュー観点をまとめたシートです。それはコーディング規約の類であったり、仕様書であったり、過去の指摘項目リストであったりします。例えば、コードレビューにおいて、変数の初期化、スコープが適切であるか、などなど。もうひとつはレビュー対象リストです。基本的にはある程度細かい単位でレビューすることが多いですが、関数や処理といったリストを使う場合もあります。
    「チェックシート」の目的は、実施漏れをなくしたり、レビュー対象の規模を把握したり、記録用にも使います。

  3. 対話

  4. パスアラウンド方式であれば難しいところはありますが、ミーティング形式ならば「対話」というツールをうまく活用すべきだと思います。対話をさらに分けるならば「疑問」「質問」「自問」でしょうか。

    • 疑問

    • 単純にレビュアーが理解できなかったことについて解説を求めます。レビュアーの理解もそうですが、作成者にとっては説明するということが理解を深めることにもつながると思います。
    • 質問

    • 疑問と似ていますが、レビュアーがある程度推測できることや、完全に理解していることを、あえて問うてみます。レビュアーの頭の中では作成者のロジックの組み立てをチェックしたりもします。
    • 自問

    • 所感やリスク分析などを促し、作成者に考えさせて自己解決・認識させます。人に「これではだめ」といわれるよりも自分自身で「これではだめ」と気づくことも重要。

     「対話」の目的は、理解度の共有でもあり、コードレビューについていえば作成者のクセ・センスを確認することができ、この情報は今後に役立つ可能性もあると思っています。

  5. 分割

  6. 「分割」も2つの用途で使います。一つ目はレビュー対象の分割を行い、単純化とレビュー時間の細分化を行います。もうひとつはレビュアーの役割分割です。自分のチームでは基本は複数名のレビュアーとしているので、各人の切り口を変えてレビューを進めたりします。
     「分割」の目的は、単純化と細分化、切り口を多くしてより多くの欠陥を探すことができると考えます。

  7. ズームアウト・ズームイン

  8. 「ズームアウト」はレビュー対象を大枠で眺めることで単純化し、逆に「ズームイン」はレビュー対象の詳細について査読します。IF文の入れ子ブロックであったり、画面全体仕様と各画面の仕様であったり。大枠についての査読をした後、細かいところについてチェックをする、比較的常套手段かな、と。
    「ズームアウト・ズームイン」の目的も、単純化と細分化ですが、見方によってはモデル化ともいえるでしょうか。

  9. 日本語化・口語化

  10. 「対話」と関連してきますが、図表やコードをレビュアーが「日本語化/口語化」して説明して、作成者との認識チェックを行います。あるテスト技法について学ぶときも、複数の書籍を見比べて勉強したりしますね、それに似ていると思います。物事を換言することは理解を深めるときに重要だと思います。
    「日本語化・口語化」の目的は、作成者の脳とレビュアーの脳が同じインプットに対して同じアウトプットが出せるか、という視点でチェックをする、みたいなイメージです。

  11. 将来設計

  12. 「将来設計」とは、ソフトウェア/システムの将来的な規模、拡張性、引継ぎなどを考慮します。これにはいくつか特性があると思いますが、

    • スケールアウト可能か

    • 拡張・変更が容易か

    • メンテナンス・引継ぎが容易か


    といったところでしょうか。
    「将来設計」の目的は、文字通りの将来の品質に着目すること。

  13. 休憩

  14. 1時間くらいで「休憩」を取り、頭を休めたり、作成者と会話を楽しみます。レビューは人間関係も大切です。作成者もレビュアーも作成物の品質向上とエンジニア自身の成長につながるようなレビューを心がけるようにしています。


同僚の作成物のレビュアーをする機会は多いと思いますが、皆さんはどんなツールをお持ちですか?

| | コメント (0) | トラックバック (0)

日本経営品質賞アセスメントガイドブック

ちょっと路線の違う書籍の紹介。

2008年度版 日本経営品質賞 アセスメントガイドブック

画像は経営品質協議会より

ソフトウェアテストとは少し離れてしまいそうですが、「経営品質」とは、というくだりでは、以下のような言葉がありました。

日本では「品質」という言葉は、製品の機能や特性を表すものととらえられてきました。ものの質だから、「品質」だという概念が定着しています。
(中略)
品質は「クオリティ」という言葉を訳したものです。クオリティの語源はギリシャ語の「クオリス」です。この言葉は「ものの明らかさ、適切さ」を意味しています。
(中略)
ある目的で適切なことであっても目的が違っていれば適切でなくなるのです。急いでいるお客様に対しての時間価値を目的としたサービスの質と、ゆっくりとくつろぎたい人むけの時間価値を目的としたサービスの質は異なります。このように品質は目的と深く関係している考え方なのです。

品質=顧客満足度ととらえることはこの「クオリティ」という言葉の語源からもしっくりくる考え方です。この本ではいかにして「経営」品質を向上させる組織を築くかについて書かれていますが、これらは同時にソフトウェア品質を向上させる組織・チームの築き方が隠されているようです。

amazonでは販売していませんが、いろいろな場面で活用できるテキストだと思います。

| | コメント (0) | トラックバック (0)

コンサルティング

マイミクさんのマイミクさんの日記を見たら、かつてコンサルタントをしたお客さんとの邂逅について書かれていてた。コンサルの後も、その組織は自ら問題を解決し、自ら成長し続けていたようです。コメントにもあったとおり「その組織の問題解決のコンサルティング」ではなく「その組織に問題解決できる力をつけるコンサルティング」をしたということなのだ。

先月にしさんが「テストコンサルタントを目指してみよう」というテーマでお話されていたことが思い出されます。自分はどれだけよい工夫や考え方を皆に伝えて共有しようとしているだろうか。




| | コメント (0) | トラックバック (0)

登山とソフトウェアテスト

「ソフトウェアテスト」って「山登り」に似てるなあ。

  • ゴール(頂上)はひとつ

お客様第一、お客様が品質を決める、そこはどんな分野でもどんなプロダクトでもどんなプロジェクトでも同じ。いかに上手に(効率的に、効果的に)頂上にたどり着くか。

  • ゴール(頂上)への道はひとつじゃない

頂上はひとつだが、登り方にはいろいろある。登る道筋はリーダーが指し示し、登るペース配分はマネージャーが管理する。なるべくリスクを小さく保ちつつ、近くて緩やかな坂道を登りたい。山登りについて何も知らなければぐるぐる回ってるだけで頂上に近づかないかもしれない。

  • 高い山と低い山とでは装備(ツール)が違う

高い山に登るときはそれなりの装備(ツールや知識)、パーティー(チーム)、時間などが必要になる。でも、低い山なら重装備はいらない。けれど、準備のために買い物に行くといろいろな装備(ツール)がほしくなる。意外に高い。

  • 5合目くらいまでは車でいける場合がある

道路が舗装されていると5合目くらいまでは車やケーブルカー(自動ツール)でいける。でも頂上まではいけると思っちゃいけない。

  • 遭難すると高くつく

山の天気は変わりやすい。なかなか頂上にたどり着けずに夜になっちゃった(デスマ)。救援してもらわないといけないけど、ヘリコプターとか救助隊は高くつくなあ。。。

適切な方向性と妥当なスケジュールと最適のツールを装備して、山に登りたいものだ。

| | コメント (0) | トラックバック (0)

テストのさしすせそ

トラブル対応で1週間があっという間に過ぎてしまった。

==

どこかのサイトでソフトウェアテストのあいうえお作文が載ってた記憶が。自分なりに、効率的・効果的なソフトウェアテストのあいうえお作文。サ行で。

  • :サボれ!

  • :自動化すればいいんだっけ?

  • :水準値は肝

  • :センスも必要

  • :「ソフトウェアテスト」でググれ!
  • 完全テストは無理なので、緩急のつけ方が重要。サボれるところはサボれ。自動化という呪文にだまされるな。メンテナンスは自動じゃないぞ。水準値の取り方で効率と効果がぜんぜん違う。無駄にテストしても品質は上がらないよ。プログラミングと同じでテストもセンスが必要。今はソフトウェアテストのサイトも書籍も充実してる、まずはインターネットを活用して勉強するべし。

    なんてね。

    2008/03/06追記
    テストのはひふへほ
    このコラムにインスパイヤされて。

  • | | コメント (11) | トラックバック (0)

    Don't write redundant tests, and don't write too few tests. - テストは無駄なく漏れなく

    昨日は社内では改正される特電法のお勉強会。社外ではWeb自動テストツールのお勉強会。

    ==

    TotT: Too Many Tests by Google Testing Blog

    単純な処理を例に挙げて、「テストケースが非常に多いこと」の考察をしている。int型の単純なべき数(=2^32のパラメータ数分のべき)では、多すぎる。条件分岐がTrueの場合とFalseの場合の2通り(100%ステートメントカバレッジ)は、少なすぎる。境界値と同値クラスを考慮した場合も、少し多そう。最後は、条件分岐(OR条件)がTrueになる場合(=3通り)とFalseになる場合(=1通り)を考え、そのサブ処理で各2通りを考えた10通り。


    | | コメント (0) | トラックバック (0)

    原因結果グラフを解剖 - 原因から?結果から?

    BlackBerryのメールは本文をBase64にするみたい。

    ==

    原因結果グラフをデシジョンテーブルに変換する際、まずは小さなテーブル(サブテーブル)を作成してから、全体のテーブルを作っていく手順で僕は行っていたが、サブテーブルはどちらから結合したほうが簡単なのだろうか。ごくごくシンプルな原因結果グラフであれば、中間ノードと結果ノードから大枠をサブテーブル化して、細部を組み立てるほうがわかりやすそうだけれども、制約条件が関係してくると、原因ノードと中間ノードからサブテーブルを作成して、制約条件を先に考慮したほうがよさそうにも思える。

    などと考えてみる。

    今のところの結論としては、原因側から右側へ結合させていくほうがよさそうに思える。原因ノードと中間ノードについてのサブテーブルを作成する際に、原因ノードと制約条件をもつ原因ノードも一緒にしてしまうといいのではないか。

    | | コメント (4) | トラックバック (0)

    実施不足と考慮漏れと自動化と

    少し落ち着いてきたので、ブログ更新。今日は結婚式の打ち合わせ×2回分。明日はディズニーランド、でも天気は荒れ模様らしい。でも。晴れ男だからチャラ・ヘッチャラ。

    ==

    タイトルにそんなに深い意味がないけど、ここ数週間で思ったキーワード。超基本的だけど、勉強と実行には大きなギャップがありますねぇ。まだまだ経験が足りないな。経験しなくては。

    | | コメント (0) | トラックバック (0)

    新年度だ 静的テストだ

    ずいぶんと間を空けてしまった。現在は少しずつ本を読んでるところ。今年に入って動的テストばっかりだったので、心機一転静的テストとかに目を向けようかな。レビューとかインスペクションって有名な本がけっこうあるけど、読んだことないや。まずは何を読んでみたらいいんだろうか。

  • 事前の自己レビュー

  • レジュメ

  • 機能のポイント

  • 実装のポイント

  • リスク(プロダクト)のポイント

  • テストのポイント

  • テスト方法
  • 思いついた単語を並べてみただけ。

    ==
    2007/04/05追記。
    静的テストといっても、新規システム開発バグ修正エンハンスで手法もかわってくる。列挙したのはバグ修正やエンハンスをイメージして書いた。

    | | コメント (2) | トラックバック (0)

    より以前の記事一覧