見出し画像

第240回: 「ALTAのテキストをつくろう」3 ソフトウェア開発ライフサイクルにおけるテスト

◀前の記事へ 次の記事へ▶


≡ はじめに

前回は「ALTAの関与が期待されるテストプロセス」について書きました。

前回の復習は以下で模擬試験問題の確認を通して行うとして、今回はJSTQBのALTAシラバスの「1.2 ソフトウェア開発ライフサイクルにおけるテスト」について書きます。



≡ 前回の復習

以下は前回の最後の方に出したJSTQB ALTAの模擬試験問題を𝕏にツイートしたものです。

noteでのツイートの埋め込み機能が上手く働かなくなってしまったようなので、画面コピーしています。これもTwitterのAPI制限の影響なのでしょうか。大きく言えば「知の流れ」を止めているので良くないことだなあと思います。
(ただ乗り業者を締め出すためには仕方のないことかもしれませんが、ホワイトリストをつくるなどして解決できないものなのでしょうか?)


𝕏に投稿したアンケート結果

アンケートの結果は、ご覧の通り「テスト計画(41.9%)」と「テスト実装(53.5%)」が二分しました。

正解は「テスト計画」の方です。理由に納得がいかない方は、前回のnoteを読み直してください。

こちらの答えですが、“ISTQBがそう決めた”というだけの話なので、技術的に深い意味はありません。
例えば、実務として「テスト計画策定時にテストアナリストが助言する」ことは良いことだと思います。例えば、「この規模の開発なら、この程度のテストケース数になると見込まれるからテスト工数やテスト期間は○○必要」というアドバイスをすることはテストアナリストの仕事だと思います。
非常に書きにくいのですが、今日のパートは、「テストアナリストはソフトウェア開発ライフサイクルを理解してテスト戦略を立てよ」というものです。テスト戦略はテスト計画の一部ですので「テスト計画を誤りとする」のはどうかと思います。

想像ですが、テスト計画は、マネジメントの要素が大きいため、ALTAよりも、ALTMの関与が期待されるテストプロセスとしたのではないでしょうか。ということで、ALTMシラバスのイントロダクションを確認してみます。

JSTQB ALTMシラバスより

ALTMの担当個所は明記されていませんでした。それではということで、ISTQBの最新のALTMシラバスを見てみましょう。 (CTAL TM 2012 Syllabus v2.0

ISTQB ALTM Syllabus

JSTQBのALTMシラバスと同じでした。

同じ、、、といいますか、ALTMの新しいバージョンのシラバスはISTQBのサイトに置いていませんでした。(たぶん、もうすぐ出るはずです)

ところで、JSTQBの翻訳時期とのギャップがあるケースを想定し、JSTQBのシラバスに疑問を持ったときには、このように、ISTQBの該当する個所をチェックすることをお勧めします。(今でしたら、FLについては新しい方(4.0英語版)もチェックしたほうが良いです)



≡  ソフトウェア開発ライフサイクルにおけるテスト

「ソフトウェア開発ライフサイクル」はSDLC(Software Development Life Cycle)と略すことが多いです。
国際規格および[JIS]では「ISO/IEC 12207 [JIS X0160:2021]」に規定されています。

V字モデルを採用している開発組織であれば、上記「JIS X0160:2021」でもよいのですが、日本の企業ではIPAの『共通フレーム 2013』を参照して自組織の開発プロセスを定義している場合が多いです。詳しく書いてあるからです。
『共通フレーム 2013』は、Kindleの電子書籍となっています。買っておくとなにかと便利です。550円と安価ですし。

なお、主要な図については、IPAサイトからダウンロードできますので、手元に持っておくと良いでしょう。例えば、以下の図を自分で一からつくるのは大変ですから。

『共通フレーム 2013』図2-12共通フレームの基本構成

ということで「ソフトウェア開発ライフサイクル」がどのようなものを指しているかをお伝えしました。要は、「ソフトウェアをつくって、保守する一連の流れやプロセス」がまとまったものです。

さて、ここで、ソフトウェアのつくりかたが複数あることに注意が必要です。よく聞くのは「ウォーターフォール」と「アジャイル」でしょうか。
「ウォーターフォール」と「アジャイル」(アジャイルは考え方だけですので、SDLCの文脈ではスクラムなど開発方法をいう方が良いかもしれません)は、ソフトウェアのつくりかたを抽象化したものですから、「モデル」とよびます。

「ソフトウェア開発ライフサイクルモデル」には以下のようなものがあります。

  • ウォーターフォールモデル

  • 反復モデル

  • スパイラルモデル

  • Vモデル

  • Wモデル

  • ビッグバンモデル

  • アジャイル モデル

  • RAD モデル

  • プロトタイピング モデル

たくさんのモデルがあります。しかも、これらのモデルは組み合わせて使うこともあります。(ハイブリッドモデルと呼びます)
他にも例えば岸田孝一さんは、"Flower Model"という名前のソフトウェア開発ライフサイクルモデルを考案されました。画期的なモデルなのに残念ながら公開はされていません。(私も、何かのプレゼンの補足資料で拝見した程度ですが、中心から花弁が波紋のように広がり、ソフトウェアの開発が進むと大輪の花になる感じのモデルでした)

さて、今回のタイトルは、「ソフトウェア開発ライフサイクルにおけるテスト」です。テストアナリストはソフトウェア開発ライフサイクルに合わせてテスト戦略をつくろうということです。

「こういう前提があるのなら、今回のSDLCはこのモデル(例えばスクラム)で行こう」とテストアナリストが提案しても良いと私は思うのですが、ISTQBでは、SDLCは先に決まっていることが前提のようです。

下の図は、『共通フレームワーク 2013』のV字モデルに目玉(=テストアナリスト)と線を追記したものです。(エヴァの使徒みたいになってしまいました。)

『共通フレームワーク 2013』とテスト

『共通フレームワーク 2013』には、すでに、「2.4.7 ソフトウェア適格性確認テスト」と「2.3.6 システム適格性確認テスト」の2つのテストプロセスが描いてあります。上図で言えばオレンジ色のプロセスです。

テストアナリストは、上記2つのテストプロセスの具体化・詳細化を行うだけではなく、赤矢印が示すように、ソフトウェア開発ライフサイクルモデルに現れる全てのプロセスに目を配る必要があります。例えば、「「2.4.2 ソフトウェア要件定義」プロセスでは、テストはレビューアとして貢献しよう」といったように、テストアナリストはSDLCに合わせて全体のテスト戦略をつくります

(ALTAシラバスより)「テストの活動は、選択したSDLC(シーケンシャル、イテレーティブ、インクリメンタル、またはそれらのハイブリッドのいずれか)と整合している必要がある」からです。


≡ JSTQB ALTA試験対策

前回、試験対策として、

「JSTQBの試験で何を確認されるか」については、当該シラバスの各章のはじめにある「学習の目的」に書いてあります。

と書きました。今回の個所では以下の通りです。

TA-1.2.1 (K2)対応するソフトウェア開発ライフサイクルモデルに応じて、テストアナリストが関与するタイミングとその関わり方がどのように異なるのか、またその理由を説明する。

後半の「(テストの)関わり方の違い」については、このnoteには書いていません。気になる人はシラバスを読んでください。(例として……。)

ということで模擬問題です。

《例題》 テストアナリストがソフトウェア開発ライフサイクル全体を考慮するタイミングを下記の選択肢から1つ選びなさい。

 1. テスト戦略を定義するとき
 2. テスト分析を開始するとき
 3. テスト設計を開始するとき
 4. テスト実行中

答えは次回に書きます。



≡  おわりに

今回は、SDLCにおけるテストでした。

以下に今回までのテキストを置きます。

9ページまでです。

パワポのノートについて、前回のnoteの記載をコピペしています。

次回は、「1.3 テスト分析」を書きます。


この記事が気に入ったらサポートをしてみませんか?