JSTQB 2章 2018

単語カード

設定全面表示

• sequential

  順次的な、逐次的な、連続的な
• incremental

  増加の、漸進的な
• イテレーティブ開発モデル

  仕様化・設計・構築・テストのサイクルを何度も繰り返す。代表としてRUP・scrum・Kanban・spiralがある。
• RUP

  Rational Unified Process：ラショナル統一プロセス。アプリケーション開発のライフサイクルを包括的にカバーする。UMLを用いて設計を行い、イテレーションの期間は2，3ヶ月と比較的長期。
• scrum

  アジャイル開発手法の一つで、チームメンバーが一体となって目的に向かうことを表す。ロール（役割）をもったメンバーで10人以下のチームを組み、サイクル（スプリント）を繰り返し、プロダクトを完成させる。
• Kanban

  カンバンボードを使ってタスクを可視化したり、実行するタスクを調整したりして、効率的に作業を進める。イテレーションは必須ではないため機関による制限がなく、リリースする単位の自由度も高い。
• spiral

  スパイラルまたはプロトタイピング。開発初期でプロトタイプを作成し、フィードバックにより仕様を確定した後で本番開発を行う。
• deployment

  デプロイ。コンピューターネットワークを通じて提供されるアプリケーションやウェブ上のサービスを、利用可能な状態にすること。「配備、展開」
• instance

  オブジェクト指向プログラミングにおいて用いられる用語であり、クラスと呼ばれる設計図に基づいて作られたオブジェクトそのもの。「実例、ケース」
• stab

  テストの焦点を内部実装に絞り込む目的で使われるツール
• driver

  一時的に別のコンポーネントを置き換え、テストアイテムを単独で制御または呼び出す、コンポーネントまたはツール。
• mock object

  テスト対象の外部への出力や影響を検証するために使われるツール
• mock

  偽の、嘲る
• decision test

  コード内の判定をテストし、実行したコードを判定結果に基づいて評価する事
• decision table

  決定表。対象が取り得る条件と、その結果動作との組み合わせを整理し一覧化した表であり、複雑な条件と動作を視覚化し表現するのに役立つ。
• TDD

  Test-Driven Development：テスト駆動開発。まずテストコードを書いた後にそのテストをパスするようにプロダクト本体を実装する開発手法
• Data Driven

  データ駆動型とは、データを元に次のアクションを決めたり、意思決定を行ったりすること
• XP

  extreme programming ：アジャイル開発の一種で、設計・実装・テストを短期間で何度も繰り返しながら、顧客の意見や要望を都度取り入れて開発を進める
• API

  Application Programming Interface：アプリケーションをプログラミングするためのインターフェース。または、接続先のOSを呼び出すことや互いのソフトウェアやアプリケーション機能の一部を共有すること。
• protocol

  コンピュータでデータをやりとりするために定められた手順や規約、信号の電気的規則、通信における送受信の手順などを定めた規格 「手続き、外交儀礼」
• microservices

  ソフトウェア開発における技法のひとつで、規模が小さいサービス同士を組み合わせて連係させることで、ひとつの大きなアプリケーションやサイトの構築を行う。マイクロサービスアーキテクチャともいう
• Monolithic Architecture

  1 つのコードベースを使用して複数のビジネス機能を実行する従来のソフトウェア開発モデル。自己完結型で他のアプリケーションから独立した統合ユニットとして構築されている。
• encode

  データを一定の規則に従って、他のデータ形式に変換すること。 これを行う機器やソフトウェアを「エンコーダ」という。
• big bang

  すべてのコンポーネントやシステムに対して一度に実施。各業務モジュールを段階的に導入するのではなく、必要な機能を一括で導入・稼働させる方法
• end-to-end

  略してE2E。 通信・ネットワーク分野においては、通信を行う二者を結ぶ経路全体、もしくはその両端を示す。
• E2Eの原則

  エラー検知など高度な処理はなるべくシステムの末端（エンドシステム）で行い、ネットワーク経路上はなるべく単純な処理のみを行うこと。
• SUT

  System under test：正常な動作についてテストされているシステムのことを指す。被試験システムと言うこともある。
• load testing

  負荷テスト。システムに同時に多数のアクセスがある状況をシミュレートする負荷をかけるテストを実施し、性能を確認するテスト
• usability testing

  使用性テスト。特定のユーザーが特定の条件下でシステムを使用する際の有効性、効率性、満足度の度合いを評価するテスト
• interoperability testing

  相互運用性テスト。2つ以上のコンポーネントやシステムが情報を交換でき、それを使用できる度合い。
• interoperability

  相互運用性。地理的、政治的、または組織の境界にかかわらず、アプリケーションとシステムが安全かつ自動的にデータを交換できること
• schema

  スキーマ。データベースの構造を定義したもの。データベースのデータをどう管理するかの、一連の約束
• staging environment

  ステージング環境。システムやソフトウェア開発において、本番環境に近い環境を模擬的に構築したもの
• UAT

  User Acceptance Test：受け入れテスト。完成したソフトウェアが業務要件を満たしているかを検証するために、実際の利用環境もしくはそれに近い環境で問題なく動作するかを確認するテスト。《承認テスト、検収テスト》
• administrator

  企業において、コンピューターやネットワーク、システムといったものの管理や維持、サポートなどを担当している人のこと
• COTS

  Commercial Off-The-Shelf：商用オフザシェルフとは、既製品で販売やリースが可能となっているソフトウェア製品やハードウェア製品、または一般向けにライセンス提供されるものを採用することである。
• Off-The-Shelf

  既製品　『商品を棚から下ろしてすぐに使える』
• lease

  リース会社が、企業に対して機械や設備を長期間賃貸すること 「貸す」
• hot site

  企業の情報システムのバックアップ施設などの運用方式の一つで、遠隔地に設けた施設に本運用とほぼ同じシステムを導入し、常時データ複製などを行いながら稼動状態で待機しておき、障害発生時に直ちに切り替えて運用を引き継ぐ方式。
• conversion

  変換
• query

  ソフトウェアに対するデータの問い合わせや要求などを一定の形式で文字に表現すること。 クエリを通じて、データの検索や更新、削除、抽出などの要求をデータベース（DBMS）に送信することができる。 「問い合わせ、訪ねる」
• refactoring

  プログラムの動作を保ったままソースコードを改善する作業のこと。 ソフトウェアに新たな機能を追加する作業や問題点を解決するバグ修正とは異なり、リファクタリングでは外から見た挙動は変わらない。
• regular expression

  正規表現。文字列の集合を一つの文字列で表現する方法の一つ
• revision

  ソフトウェアやハードウェアの発売・公開後に細かい変更や修正を加えた改訂版のことや、複数の改訂版を識別する通し番号（リビジョン番号）を指す。略は「Rev」 「改訂、改正、補正」
• buffer

  余裕、緩衝、ゆとり
• business logic

  業務システムの中で、具体的な業務で扱う様々な実体（商品、顧客、在庫など）を表現し、また、それらの関係や処理の方法、業務の流れなどをデータモデルやプログラムコードなどとして実装した部分（システムにおける、システム固有の処理を行う部分）のこと
• repository

  さまざまなデータ、情報、知識や成果物を蓄積するデータベースやアーカイブ 「貯蔵庫、倉庫」
• confirmation testing

  確認テスト。変更関連テストの一種で、欠陥を修正した後に実行し、それらの欠陥により引き起こされていた故障が発生しなくなっていることを確認する。
• alpha testing

  開発担当者のテスト環境で実行する受け入れテストの一種。開発組織外の役割となって実行する。
• beta testing

  開発担当者のテスト環境に対して、外部のサイトにおいて実行される受け入れテストの一種。開発組織外の担当者が実行する。
• change-related testing

  変更関連のテスト。コンポーネント、またはシステムの変更を契機に行うテストの一種。
• impact analysis

  影響度分析。変更が影響するすべての作業成果物を識別すること。変更を達成するために必要なリソースの見積りを含む。
• maintenance testing

  メンテナンステスト。運用システム自体の変更や、稼動環境の変更が運用システムに与える影響をテストすること。
• ATDD

  acceptance test-driven development：受け入れテスト駆動開発。定義した受け入れ基準に合格するように開発する。ステークホルダーのドメインの言葉で受け入れテストを定義する。アジャイル開発手法。
• BDD

  behavior-driven development：振る舞い駆動開発。顧客が期待するコンポーネントやシステムの振る舞いを提供することにチームが注力する共同開発アプローチであり、テストの基準を生成する。アジャイル開発手法。
• リーン開発

  leanは「脂肪がない」で、無駄なものを開発せず絶対必要な機能のみ開発してリリースし、顧客の反応から追加開発する
• DDD

  Domain-Driven Design：ドメイン駆動設計。ソフトウェアで解決したい部分(専門領域)を、ソフトウェアの設計にそのまま反映させる、業務をきちんと理解した上でソフトウェア開発を行う
• FDD

  Feature Driven Development：ユーザー機能駆動開発。アジャイル開発手法の一つで、ユーザー目線で価値ある機能を中心に開発を進める手法
• retrospective

  アジャイル開発では、毎回の反復プロセスの最後に行われる振り返り活動のこと。「回顧的な」
• transaction

  ソフトウェアの処理方式のことを指し、処理の一貫性を持たせるために「データベース管理システム」で活用されている。関連する複数の処理を一つの処理として実行・管理する仕組みを「トランザクション処理」と呼ぶ 。「商取引」
• E2E Testing

  アプリの全機能をユーザー観点でテストする
• workflow

  ある業務や活動を構成する、一連の作業や手続き、工程などの流れ。また、流れを構成する各工程の順序や内容、担当部門などを流れ図や表、リストなどの形で定義したもの。
• ゼロデイ攻撃

  発見された脆弱性を解消するための対策が提供される前に行われるサイバー攻撃
• hotfix

  ソフトウェアに発見された不具合を解消するために配布される修正プログラムのうち、問題に迅速に対応するため緊急に発行されるもの。保安上の弱点を修正するためのものが多い。

広告

コメント