[試験]JSTQBテスト技術者資格認定(8/25)

JSTQB試験も来週に迫っています。よくみると、今回の試験日は土曜日なんですね。いいなー。

今回の試験は、直前にテスト本が続々出ていたり(6月 マインドマップから始めるソフトウェアテスト、7月 ソフトウェア・テスト PRESS Vol.5、7月 ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方)、JaSSTが開催されていたりで、受験者も急増したんではないでしょうか。

無料で配布されているシラバスや、模擬試験などを活用したり、教科書・問題集を購入するもよし。

JSTQB教科書 JSTQB認定テスト技術者 Foundation Level試験 (JSTQB教科書)
大西 建児 勝亦 匡秀 加藤 大受 佐々木 方規 鈴木 三紀夫 町田 欣史 吉澤 智美 湯本 剛
翔泳社 (2007/02/08)
売り上げランキング: 23005
演習で学ぶ ソフトウェアテスト特訓150問 JSTQBテスト技術者認定Foundation対応
正木 威寛
技術評論社 (2006/07/28)
売り上げランキング: 12904
おすすめ度の平均: 4.0
3 ソフトウェアテストの用語がコンパクトにまとまっているよい本だと思います。
5 受験者にも、そうでない人にもオススメ


資格があれば品質が上がる、というわけではないですが、継続的な勉強のための一里塚として考えておくのもいいかと思います。第4回目は年越し2月くらい?

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

第2回JSTQB認定テスト技術者資格 試験結果

JSTQB認定テスト技術者資格の試験結果が出てます。僕も受験しててとりあえず合格しててよかったー。合格率は60%超でした。

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

JSTQBシラバスが求めているテスト技術者(2)

JSTQBテスト技術者の試験も無事終了。シャーペンとか消しゴムとか解答用紙見直しとか久しぶりな1日でした。

==

試験前にまとめ記事は書いておきたかったが、続きを。

  • テストのマネジメント
  • テストを誰がやるか。実装をした開発担当者なのか、プロジェクト内のチームメンバーなのか、社内のテスト専門部隊なのか、社外の品質マネジメントを専門とする部隊なのか。基本的には後者に行くにしたがってプロジェクトとの関係が薄くなり、独立性が高くなる。開発担当者の思い込みやステークホルダーのプレッシャーなどの要因がなくなり、欠陥検出の観点でいえば精度があがるといわれる。ただし、独立性が高くなるほど当のメンバーの品質意識が薄れてしまい、欠陥作りこみの観点でいえば品質が低下する可能性も秘めている。誰がやるか、という問いであれば「テストツール」という選択肢もあり、その場合も同じようなことが言えそうだ。思い込みは全くないが、テストツールに依存しすぎると逆に品質低下の坂を転げ落ちる可能性もある。

    プロジェクトに影響するリスク(=プロジェクトリスト)と、プロダクトに影響するリスク(=プロダクトリスト)という区分をした場合、前者はテストというプロセス自体に影響がでる。後者はテストというプロセスが影響を及ぼす。すなわち、テストというプロセスがプロダクトリスクの対策になりうる。

    それにしても終了基準ってけっこうあいまいなところが多そうだな。

  • テスト支援ツール
  • 最後の章はテストを支援するツール。静的解析ツールやキャプチャリプレイツール、不可試験ツールが有名。テスト実行ツールあたりは、ここらへんは日立)加藤さんの講演とかをきくとまとまっていて理解しやすいと思う。テストマネジメントの支援ツールなどは比較的どのプロジェクトでも効果が出そうな気がする。私見では。


    ==

    テスト工程ってけっこう感覚的に行っているケースが多いが、体系的なテストプロセスを学習してみると、まさにプロジェクトの中のサブプロジェクトだね。僕らが期待するような解の公式はない。複数の視点・観点で分析しないとなかなかひとつ高いステージの品質にはあがらない。仕様ベースと構造ベース。「バグを作らない」と「バグを見つける」。個人単位の品質意識の向上と個人の能力に左右されないプロセス。

    (続く)

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

    JSTQBシラバスが求めているテスト技術者(1)

    テストオラクルという切り口で今は勉強中。エイゴニガテ。

    ==

    明日3/2にJSTQBテスト技術者資格認定の試験があります。僕も問題集や教科書やこことかで勉強してみました。


    一通りこなしてみて、復習・おさらい・新たな気づきのために自分なりにまとめてみようかと。

  • テストの基礎
  • テストがなぜ必要・重要なのか。上手なテストはどういうリスクを回避するのか。静的テストというテスト。テストプロセスってどんな風に行うの?

    実はシステム開発の半分以上のコストがテスト工程に費やされている、というデータもあるとおり、コスト面で効率化が必要。また昨今のシステムトラブルなどをみても品質面でも効果性を求められる。じゃあ、そのテストについてもっと研究してみようよ、という章かな。

    テスト=バグ(欠陥)を見つけること、という視点、レビューなどの静的テストという視点、システム開発のサブプロジェクトとしてテストを考える、心理的な観点からだれがテスト(設計)すべきかな、どなど。


  • ソフトウェアライフサイクルを通じてのテスト
  • システム開発の手法によってテストの関わり方がかわってくる。ウォーターフォール型開発の中のテスト、反復型・アジャイル型開発の中のテスト。それ以外にも、構成単位の粒の大きさでテストをカテゴライズすることもある。コンポーネントテスト(あるいは、ユニットテスト、単体テストとも)、統合テスト(あるいは、結合テストとも)、システムテスト、受け入れテスト。テスト工程といったらこの呼び名が一番馴染み深いかも。これはテストのレベルというカテゴライズで、V字開発モデルではそれぞれが詳細設計、システム設計、要件定義などと対として扱われる。

    その他にもテストのタイプというカテゴライズもある。これは機能テスト、非機能テスト、構造テスト、確認テスト、保守テストといった種類(タイプ)がある。それぞれにテスト評価基準があり、要件のカバレッジであったり、条件のカバレッジであったり。非機能テストにおいては品質特性(JIS X0129)と呼ばれるカテゴリを参考にする方法もある。システム開発をはじめたころは機能テストばっかりをやっていた気がするなあ。

    こういった複数の視点でテストを分析していくことでより多くのバグを検出できるテスト設計が可能になる。仕様書ベースだけでテストケースを作成していても、見つからないバグもある。ステートメントカバレッジに注目しているだけでは見つからないバグもある。とか。


  • 静的技法
  • ソースレビューとかテスト設計レビューとかペアプロとか。プロジェクトの早い段階でバグを作りこまない対策として最も一般的に知られているが、人によってはまちまちなのも事実か。開発担当者自身に気づかせるためのウォークスルー、技術的な指摘をメインにしたテクニカルレビュー、静的解析ツールを利用することで品質を均一にしするという試みもある。ここでの取り組みがあとあとの手戻りコストを小さくしてくれる。ただし、一長一短である。実際に動かしてみないとわからないバグも必ずある。


  • テスト設計技法
  • 静的テストは「バグを作りこまない」「バグの件数を小さくする」という視点。テスト設計をするときは「より多くのバグを見つける」「より少ない手数でバグを見つける」という視点。前者は手戻りコストを抑え、後者はテスト実行のコストを下げる。

    仕様ベースとかブラックボックスと呼ばれる技法は、入力(事前条件)と出力(期待される結果)に注目してテストケースを設計する技法。期待される結果を比較(テストオラクル)。要件・機能カバレッジをチェックすることが一般的。

    構造ベースとかホワイトボックスと呼ばれる技法は、経路に注目するテスト技法。ステートメントカバレッジ・ブランチカバレッジ・コンディションカバレッジをチェックする。

    どちらも長所短所をもっていて、例えばコンポーネントテストでは構造ベースが、より上位の結合テストでは仕様ベースで設計することがよさそう。ただし、設計においても複数視点での設計が必要になる場合が多く、システムテスト以降であれば仕様・構造両方で分析・設計するのが望ましいだろうな。


    (続く)

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

    [試験]JSTQBテスト技術者資格認定

    第2回JSTQB技術者認定の試験があって、その受付が始まりました。

    JSTQBテスト技術者認定
    受験受付について

    資格というよりもスコアといった意味合いが強いかと思いますが、テストという観点で、業界底上げするにはこの技術者認定試験がもっと有名になるといいな、と。

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