投稿者: webmaster

弊社代表取締役 倉田克徳が一般社団法人 IT検証産業協会副会長に就任

弊社代表取締役 倉田克徳が一般社団法人 IT検証産業協会副会長に就任

株式会社エス・キュー・シー(本社:東京都新宿区)の代表取締役である倉田克徳が、2023 年 6 月 10 日付けで一般社団法人 IT検証産業協会副会長(所在地:東京、以下 IVIA)に就任しましたのでお知らせいたします。

IT検証産業協会: https://www.ivia.or.jp

■一般社団法人 IT検証産業協会(IT Verification Industry Association 略称 IVIA(アイビア)とは

IT検証サービスに関する関連企業、団体、個人が集い、よりよいIT検証サービスを目指して研磨し、

業界の健全なる発展を促進するとともに産業として確立させ、わが国の社会。経済の発展に寄与する

ことを目的としております。

もも

本社移転のお知らせ

時下ますますご清栄のこととお慶び申し上げます。 平素は格別のご高配を賜り、厚く御礼申し上げます。

さて、このたび弊社では2023年4月17日より、
本社オフィスを下記住所に移転いたしますのでご案内申し上げます。移転を機に、サービスのさらなる向上をめざし皆様のご期待に沿えるよう努力してまいりますので、 今後とも変わらぬお引立てを賜りますようお願い申し上げます。【移転先住所】
〒160-0023
東京都新宿区西新宿6丁目24−1 西新宿三井ビルディング 6階

もも

「沖縄NICE映画祭2022」に協賛しています

沖縄 NICE映画祭 2022が、2023年1月27日(金)~29日(日)に、桜坂劇場 (沖縄県那覇市牧志3-6-10)で開催されます。

映画好きによる、映画好きの為の、映画好きな クセが強すぎる映画祭 爆誕 !
沖縄 NICE 映画祭は沖縄で、映画好きなメンバーが集まって出来上がった映画祭です。

これまでは、クリエイター達で創った自主映画を上映する催しでしたが、今年から一般向けの作品も募集する事にし、学生、プロ、アマ問わず誰でも応募できることになりました。

当社は、本イベントを通じ、「演じてみたい人」「脚本書いてみたい人」「映像作品をイチから創ってみたい人 」「音楽や効果音制作に興味がある人 」「イベント運営にトライしたい人」…等々、
そんなナイスな人を応援したいと考え、「沖縄 NICE映画祭 2022」に協賛しています。

詳細はこちらをご覧ください。
沖縄 NICE映画祭 公式サイト
沖縄 NICE映画祭 Instagram
沖縄 NICE映画祭 Twitter
沖縄 NICE映画祭 クラウドファウンディング

もも

年末年始のお知らせ

年末年始のお知らせ

 

拝啓 師走の候、ますますご健勝のこととお喜び申し上げます。
平素は格別のご高配を賜り、厚くお礼申し上げます。

 

さて、株式会社エス・キュー・シーでは年末年始の休業日につきまして、下記のとおり休業日とさせていただきます。
皆様には大変ご迷惑をおかけいたしますが、ご了承いただきますようお願い申し上げます。

 

敬具

 

 

■年末年始休業日
2022年12月29日(木)~2023年1月4日(水)

 

※2023年1月5日(木)より、通常営業を開始いたします。
※お問い合わせにつきましては、2023年1月5日(木)以降ご連絡させて頂きます。

もも
もも

「テレワーク先駆者百選」に選定されました

当社(株式会社エス・キュー・シー 代表取締役社長 倉田 克徳 )は、テレワークへの取り組みが評価され、このたび、総務省が主催する「テレワーク先駆者百選」に選定されましたことをお知らせいたします。

総務省では、平成27年度から、テレワークの導入・活用を進めている企業・団体を「テレワーク先駆者」とし、その中から十分な実績を持つ団体等を「テレワーク先駆者百選」として公表しています。

本年度は、103団体が「テレワーク先駆者百選」に選定されました。

当社は、2019年度より「働き方改革」の一環として様々な勤務形態と環境を整備して参りました。

当社は従業員とその家族をはじめとする関係者皆さまの安全と健康を最優先に、社内外の感染防止のため、コロナ禍においても、テレワークを最大限活用し、創意工夫を重ねながら事業を継続しています。

今後も「テレワーク先駆者百選」の企業として、テレワークの普及、利用促進に、積極的に 取り組んでまいります。

[関連リンク]

令和3年度「テレワーク先駆者百選 総務大臣賞」等の公表

 

もも

ITmediaに当社に関する記事が掲載されました

ITmedia(2021年11月10日)に当社代表のインタビュー記事が掲載されました。

ソフトウェア検証”の老舗が「みんなの電子署名」を採用 ユーザーから信頼を得る電子署名サービスを使う意義」というタイトルで当社の取り組みをご紹介いただきました。

当社が利用している電子署名システムは、「日本の働き方を変える みんなの電子署名」です。

 

 

もも

当社従業員のワクチン接種時における特別有給休暇付与に関するお知らせ

平素は格別のご高配を賜り、厚く御礼申し上げます。

当社では、新型コロナウイルス感染症拡大防止策の一環として、全従業員を対象にワクチン接種時および副反応が出た場合、

特別有給休暇を付与いたします。

1.ワクチン接種日は特別休暇を付与する。
従業員本人がワクチン接種を行う日には、特別有給休暇を付与します。

2.ワクチン接種会場までの交通費は会社が負担する。
自宅からワクチン接種会場までの交通費は、会社が全額負担します。

3.ワクチン副反応が出た場合の療養期間は特別休暇を付与する。
ワクチン接種により副反応が出た場合は、特別有給休暇を付与します。

お客様ならびに関係者各位には、何卒ご理解を賜りますようお願い申し上げます。

今後も政府および関係自治体からの要請に応じるとともに、感染動向に応じた対策を実施してまいります。

もも

新型コロナウィルス感染症の感染拡大防止に関する取り組みについて

平素は格別のご高配を賜り、厚く御礼申し上げます。 当社では、新型コロナウイルスによる感染症への対策として、 お客様ならびに従業員の健康と安全を第一に考え、

以下の対策を行っております。 何卒ご理解ならびにご協力を賜りますようお願い申し上げます。

1、勤務体系

  • 在宅勤務、時差出勤(出社率2割を実現しております)

2、出張およびお客様との打ち合わせ

  • 不要不急の出張自粛
  • WEB会議の活用(全社員にWEB会議システムを導入しております)
  • 不要不急の来客対応自粛

3、ニューノーマルに対応したDX化の推進

  • 受発注システムのシステム化
  • 電子署名の導入
  • 勤務・労務システムの導入

お客様ならびに関係者各位にはご不便をおかけいたしますが、何卒ご理解を賜りますようお願い申し上げます。

今後も政府および関係自治体からの要請に応じるとともに、感染動向に応じた対策を実施してまいります。

 

もも

「テレワーク東京ルール」宣言実践企業に登録されました

エス・キュー・シーは、東京都が普及推進する「テレワーク東京ルール」に取り組んでおり、宣言実践企業として登録されております。

テレワークを新型コロナウイルス感染症防止のための緊急避難的な一過性のものとすることなく、促進・定着に向けて取り組んでいます。

もも
もも

虚礼廃止のお知らせ

平素は格別のお引き立てを賜り、厚く御礼申し上げます

弊社では、虚礼廃止の意味から、会社全体として、お取引先様に対する中元・歳暮の贈答、年賀状による年始のご挨拶を廃止させていただくことと致しました。
つきましては、失礼ながら、弊社から中元・歳暮をお贈りすること、ならびに年賀状をお出しすることは差し控えさせていただきます。

皆様におかれましても、弊社や弊社社員あての中元・歳暮等のお心遣いはどうかご無用に願いたく存じます。
今後は、感謝の気持ちを今まで以上に仕事に向けてまいる所存でございますので、何卒ご理解の程よろしくお願い申し上げます。

                                                       以上

もも

創業25周年のご挨拶

創業25周年にあたって

 

弊社は、2020年9月11日をもって創業25周年を無事迎えることができました。これもひとえに多くの方々の支えがあり、

ご協力の賜と思っております。この場をお借りしまして感謝と御礼申し上げます。

今年は年初より新型コロナウィルスの影響から2020年が始まり、現在に至ってもまだ収束傾向が見えていません。

人類史上では、「天災」「戦争」「疫病」がいろいろな物事の転換点と言われており、

まさに今年は世界的にコロナ禍による諸々の転換点を迎えていると言えることが出来るでしょう。

「ニューノーマル」という新たな生活スタイルになりつつある中で、我々の本業たるシステム品質(サービス品質)も

その転換点に来ているのではないかと考えます。

今までの25年の蓄積の中から積み上げてきたノウハウ、そして、今後50年後、100年後を見据えたサービスプロバイダーとして

あるべき姿を見いだしながら、さらなる躍進につなげていきたいと考えます。

今後ともご指導、ご鞭撻をよろしくお願いいたします。

 

株式会社エス・キュー・シー

代表取締役 倉田 克徳

もも
もも

メモリリーク

メモリリーク (英: memory leak) とは、プログラミングにおけるバグの一種。プログラムが確保したメモリの一部、または全部を解放するのを忘れ、確保したままになってしまうことを言う。プログラマによる単純なミスやプログラムの論理的欠陥によって発生することが多い。

[参考:Wikipedia]

 

もも

リソースリーク

リソースリーク (英: resource leak) とは、メモリリークをファイルやネットワーク接続、OS、ハードウェアなど一般のリソースに拡張した概念である。

例えば、一般的なOS環境でファイルへの読み書きをする場合、最初にファイルを開く処理が必要であり、これはメモリでいえば確保する処理にあたる。ファイルに対する処理が終了した時には、ファイルを閉じ、該当ファイルの使用権をOSに返却する処理が必要であり、これはメモリを解放する処理にあたる。通例、ファイルを閉じることで自動的にストリームがフラッシュされ、変更内容も反映(コミット)される。このとき、ファイルを閉じる処理を忘れて、不要なファイルがいつまでも開いた状態にあれば、リソースリークが発生したことになる。ユーザーが他のプログラムでそのファイルを開こうとしても失敗したり、ファイルを削除しようとしても失敗したり、などの原因不明のエラーに悩まされることになる。ほとんどの場合、リソースリークを起こしたプログラムが終了すれば、OSによって正常な状態に復帰されるが、ファイルを閉じるための正常な処理を経ていない場合、ファイルへの変更内容が反映されないこともある。

Windowsでは標準のタスク マネージャーやProcess Explorerといったツールを使って、各プロセスが使用しているハンドルの数を監視することで、リソースリークを診断することが可能である。

C++ではデストラクタによるRAIIを活用することでリソースリークを防止できる。JavaやC#のファイナライザはフェイルセーフとしての役目しか期待できないが、Javaのtry-with-resources文や、C#のusing文といった、C++のデストラクタによるRAIIに類似した機能を活用することで、リソースリークを防止できる。

[参考:Wikipedia]

キーワード関連:メモリリーク

もも

デッドロック

デッドロック (英: deadlock) とは、特に計算機科学において、2つ以上のスレッドあるいはプロセスなどの処理単位が互いの処理終了を待ち、結果としてどの処理も先に進めなくなってしまうことを言う。

また、合弁契約書などにおいてパートナーと利害関係がぶつかるような問題が生じた場合の解決方法を定めた条項を「デッドロック条項(Deadlock Clause)」と言う。 英語ではもともと行き詰まりの意味である。

[参考:Wikipedia]

もも

リバースエンジニアリング

リバースエンジニアリング(Reverse engineeringから。直訳すれば逆行工学という意味)とは、機械を分解したり、製品の動作を観察したり、ソフトウェアの動作を解析するなどして、製品の構造を分析し、そこから製造方法や動作原理、設計図などの仕様やソースコードなどを調査することを指す。

一般的に工業製品の多くは、設計図や仕様書の概略程度しか公表されておらず、詳細な動作の原理などは公表されていない。

また、コンピュータ・プログラムのソースコードも、近年優勢なオープンソース製品では公開されており、広く検証されているものも多いが、プロプライエタリ商品の場合は一部を除き非公開のため、情報セキュリティ上の危険が(仮に)存在していても秘密扱いの場合がほとんどである。そのため、様々な技術や創意工夫が用いられているこれら工業製品についての技術的情報に関しては、公開された文献から入手できない場合が大半であり、時には危険が存在しても「秘密として法的に保護」されていることすらある(各種製造物責任法などにより対抗手段もないでもないが)。

また仮に自社開発した製品であっても、それが古い製品の場合、当時の技術者がすでに退職・死亡してしまっていたり、設計図や仕様書の所在が不明になったり、あるいはそもそも最初から作成されていなかったなどの事情により、十分な情報を得ることが不可能な場合がある。

こういった事情とも絡んで、非公開情報を入手するために、ひいては、より優れた製品の開発のためにも従来の工業製品やソフトウェア製品をリバースエンジニアリングすることによって使用されている技術を分析、調査、確認することは、現場での製品開発において欠かせないプロセスの一つともなっている。

[参考:Wikipedia]

もも

ソフトウェア測定法

ソフトウェア測定法(ソフトウェアそくていほう)またはソフトウェアメトリック(英: Software metric )とは、ソフトウェアやその仕様の属性の尺度である。

定量的手法の威力は他の分野で証明されていたことから、計算機科学の分野でも同様の手法をソフトウェア開発に持ち込もうとする努力が続けられてきた。Tom DeMarco は DeMarco, T. (1982) Controlling Software Projects: Management, Measurement & Estimation, Yourdon Press, New York, USA, p3 の中で「測定できないものは制御できない」と記している。

典型的なソフトウェア測定法

  • 成長オーダー(アルゴリズム解析、O記法など参照)
  • ソースコードの行数
  • 循環的複雑度
  • ファンクションポイント法
  • ソースコードの行当たりのバグ数
  • コード網羅率
  • 顧客要求仕様の行数
  • クラスおよびインタフェースの個数
  • Robert Cecil Martin のソフトウェアパッケージ測定法
  • 凝集度
  • 結合度

[参考:Wikipedia]

もも

動的プログラム解析

動的プログラム解析 (Dynamic Program Analysis) とは、ソフトウェア解析手法の一種であり、実際のあるいは仮想のプロセッサでプログラムを実行して解析を行うこと。動的解析を効率よく行うために、標的プログラムに十分な量のテストケースを入力し、興味深い動作を起こす。コードカバレッジ等のソフトウェアテスト技法を用いて、起こりうる動作を記述したソースコードの箇所を十分な量見つけ出すことができる。ただし、実行中の一時的な命令の効果を過小評価してしまうことに気をつける必要がある。

静的解析と動的解析は相互に補完する技術である。例えば、マルチスレッド処理にまつわるバグは静的解析では見落とすおそれがあるが、動的解析では特定することができるため、Javaアプリケーションの解析には両方の解析手法が必要である。

静的解析と動的解析を組み合わせることで、バグ検出の精度と速度が高まり、競合状態やデッドロック、リソースリークなど、実行してみないと表面化しない処理を徹底的に解析することができる。 静的解析、動的解析で発見できることは、モデル検査、証明系でより効率的に発見できることもある。これらの機能を動的解析の中に組み込んでいる場合もある。

[参考:Wikipedia]

キーワード関連:静的プログラム解析デッドロックメモリリーク

もも

静的プログラム解析

静的コード解析 (static code analysis) または静的プログラム解析 (static program analysis)とは、コンピュータのソフトウェアの解析手法の一種であり、実行ファイルを実行することなく解析を行うこと。逆にソフトウェアを実行して行う解析を動的プログラム解析と呼ぶ。静的コード解析はソースコードに対して行われることが多く、少数ながらオブジェクトコードに対して行う場合もある。

ツールが行う静的コード解析の洗練度は、個々の文や宣言だけを検証するものから、プログラム全体を解析するものまで様々である。解析結果の利用も様々で、Lintのように単に指摘するだけのものから、形式手法を使ってそのプログラムの特性を数学的に証明する(仕様記述と振る舞いが一致しているかどうかを検証する)ものまである。

ソフトウェア測定法やリバースエンジニアリングも静的解析の一部とみなすこともある。特に組み込みシステムの開発において、ソフトウェア測定法と静的コード解析が品質向上の一助として活用されることが多くなっている

静的解析の商業利用が増えているのは、重要なコンピュータシステムで使用されるソフトウェアの検証や潜在的なセキュリティホールを検出する必要性が増大したことを意味する。以下のような分野で、複雑さを増していくソフトウェアの品質向上に静的コード解析が使われている。

  • 医療用ソフトウェア – アメリカ食品医薬品局 (FDA) は医療機器で静的コード解析が活用されているとしている
  • 原子力関連のソフトウェア – イギリスの Health and Safety Executive は原子炉保護系(英語版)での静的コード解析の活用を推奨している

VDC Research が行った調査(2012年)によれば、組み込みシステムのソフトウェア技術者の28.7%が静的コード解析ツールを既に使っており、39.7%が2年以内に使いたいと答えた

アプリケーションのセキュリティの分野では Static Application Security Testing (SAST) という用語が使われている。

[参考:Wikipedia]

キーワード関連:動的プログラム解析ソフトウェア測定法リバースエンジニアリング

もも
もも

回帰試験

プログラムを修正・変更した場合に、過去に実施したテストを再度実施することを回帰試験 (regression test) 又は退行テストという。修正前の試験に再度合格するかどうか、他の機能に影響与えていないかどうか、他の機能が動作するかどうかを確認する。過去のテスト資産を使い、実施する回数も多いことから、実施を省略することがないようにテスト自動化することにより効率化を図る。

[参考:Wikipedia]

もも

境界値分析

同値分割で得られた同値クラスの端となる値(およびその前後の値)を明らかにして、それをテストデータとするテスト技法のこと。

境界値分析は、同値クラスの境界値付近には、バグが集中するという経験則に基づいている。例えば、入力条件として「0以上99未満」のような範囲指定があるとき、設計書で「以下」と「未満」を取り違えたり、コーディングで「≧」と「>」の記述ミスを犯したりという誤りが起こりやすい。出力についても同値クラスの上限値や下限値は、経路分岐やロジックが正しいかどうかが端的に表れるポイントとなる。

[参考:ITmedia]

もも

同値分割

ソフトウェアテストのテストケースを設計する代表的なテクニックの1つ。システム機能における入力?出力関係の集合をいくつかの同値クラスに分け、各クラスから代表値を選んでテストデータとする方法をいう。

同値分割は、主にシステムやプログラムの仕様に基づいて行われる機能テストに用いられる。システムの機能とは「入力に対して出力を返すこと」と考えられる。入力に対して出力が正しいか(あるいは間違っているか)を検証するとき、「出力結果が同じと期待される入力の集合」を等価とみなせば、入力を試行する回数の削減が図れる。

[参考:ITmedia]

もも

経路網羅

経路網羅基準を用いてテストを行う場合は、すべての経路が少なくとも1回はとるように実行すればよい。反復構造を持つプログラムの全ての経路を特定することは普通は不可能であるから、この場合、完全な経路網羅は実行可能な目標とは考えられない。

[参考:Wikipedia]

もも

複合条件網羅

複合条件網羅基準を用いてテストを行う場合は、それぞれの判定における全ての結果の全ての可能な組み合わせを少なくとも1回はとるように実行すればよい。ただし、ある組み合わせは作ることが不可能である場合がある。たとえば、条件 (A > 2) と (A < 10) とでは、可能な組み合わせは3つしかない。

[参考:Wikipedia]

もも

条件網羅

条件網羅とは、ソフトウェアテストの実施方針の一つで、対象プログラム中に含まれる条件分岐について、その条件の組み合わせのすべてを一度は実行すること。また、条件のすべての組み合わせのうちテストされた条件の割合を条件網羅率という。

[参考:E-Words]

もも

分岐網羅

分岐網羅とは、ソフトウェアテストの実施方針の一つで、対象プログラム中に含まれる条件分岐について、そのすべての分岐を必ず一度は実行すること。また、全分岐のうちテストされた分岐の割合を分岐網羅率という。

[参考:E-Words]

もも
もも

ブラックボックステスト

ブラックボックステスト (black box test) は、プログラムの入出力だけに注目し仕様通りにプログラムが動作するか(もしくは仕様通りに動作しないか)をテストする。プログラムの入力が単一の値である場合は同値分割や限界値分析を、プログラムの入力が複数あり相互に影響を与えるような場合はディシジョンテーブルや原因結果グラフなどを用いて入力を決定する。大域変数の読み書き、通信、割り込みなどが処理中にある場合には、それらも入出力の一つとして扱う。

[参考:Wikipedia]

キーワード関連:同値分割限界値分析

もも

ホワイトボックステスト

ホワイトボックステスト (white box test) は、プログラムの構造に着目したソフトウェアテストのことである。着目する構造には命令や分岐などがあり、注目した構造に対してどれだけの割合の部分を実行できたかを網羅率で表す。

[参考:Wikipedia]

キーワード関連:命令網羅分岐網羅条件網羅複合条件網羅経路網羅

もも

上昇試験

単体テストおよび結合テストにおける手法の一つ。トップダウンテストとは逆に、単体テストが完了した下位モジュールから順に結合させてテストを行なう。この手法の利点は、数が多く独立性の高い下位モジュールから順に検証することで、開発とテストを平行して実施できることにある。一方で、システムの根幹となる上位モジュールで不具合が発見された場合、テストが完了したはずの下位モジュールも影響を受けるという欠点も持っている。単体試験を行う場合に、他の関数等を呼び出している関数を試験する場合に、呼出のない関数を試験してから、呼出をしている試験を行う場合にボトムアップテストになっている。

  • ボトムアップテストを行う際には「テストドライバ」を用意しなければならない。

[参考:Wikipedia]

キーワード関連:下降試験

もも

下降試験

単体テストおよび結合テストにおける手法の一つ。単体テストが完了したモジュールのうち、上位モジュールから順に結合させてテストを行なう。この手法の利点は、仕様的な振る舞いを決定する上位モジュールを早期に検証することによって、機能漏れ、仕様の認識違いなどの致命的な不具合を、開発の早い段階で発見できることにある。一方で、数の多い下位モジュールの検証が先送りされるため、開発と平行してテストを進めにくいという欠点もある。

  • トップダウンテストを行う際には「テストスタブ」を用意しなければならない。

[参考:Wikipedia]

キーワード関連:上昇試験

もも
もも

適合試験

OS、プログラミング言語、ネットワーク通信プロトコル、データベースなどソフトウェアを動かすための基本的なプラットフォームが、仕様に適合しているかどうかを確認する検証試験 (verification test)。OSの国際規格の一つであるPOSIXでは、 が適合試験のソースコードを公開している。 自動車用OSの国際規格OSEKでは、MODISTARC (Methods and tools for the validation of OSEK/VDX based distributed architectures) がある。 TOPPERS OSでは、TTSP (TOPPERS Test Suite Package) というテスト環境を提供し適合テスト等を実施しやすくしている。 プラットフォームの適合試験を実施せずに、アプリケーションソフトウェアの試験を実施すると、プラットフォーム仕様の変化に対応できていないことがある。

[参考:Wikipedia]

もも
もも

システムテスト

プログラムを単独ではなく、他のプログラムやハードウェア、通信ネットワーク、データベースなどと組み合わせて実施するテスト。開発環境と実行環境が異なる場合には、実際の実行環境を使って行うこともある。顧客にしか実際の実行環境がない場合には、顧客環境で行う場合がある。実際の環境を利用することが高価であったり時間がかかる場合には、模擬試験環境 (simulator) を作成して実施することがある。この場合には、模擬環境のシステム試験、実環境でのシステム試験と区分する。模擬環境では、複数の事象を同時に発生させることが難しかったり、逆に実環境ではありえない事象を発生させることができなかったり、それぞれの短所・長所を見極めて試験を実施する。エンタープライズ系と組込みソフトウェアで本質的な違いがあるわけではなく、OS、言語、ネットワーク、データベース、接続機器数の違いが大きい。

[参考:Wikipedia]

もも

統合試験

統合試験 (integration testing) は、単体試験が完了したプログラムを組み合わせて行う試験である。プログラムのどの部分から組み合わせていくかで、トップダウンテスト (top down test) とボトムアップテスト (bottom up test) に分けることができる。「Integration Testing」の略である「IT」と呼ぶことがある。また、結合テストと呼ぶ場合もある。 統合試験とシステム試験を分ける場合もある。統合試験とシステム試験を分ける場合に、模擬試験 (simulation) を統合試験に分類する場合と、システム試験に分類する場合がある。

[参考:Wikipedia]

もも

単体試験

単体試験 (unit test) は、関数、メソッドなどの小さな単位で行うテストのことである。単体テストは、関数の場合には基本はブラックボックステストである。ブラックボックステストが済んだものの品質を確保するためにホワイトボックステストを行う。「Unit Testing」の略である「UT」と呼ぶことがある。また、開発現場によっては「CT(和製: Coding Test)」や「PT(和製: Program Test)」と略すこともある。

単体試験の道具としてJavaではテスティングフレームワークJUnitが有名である。これはJava専用である。他の言語にも同様のものがあり、それらを総称してxUnitと呼んでいる。

[参考:Wikipedia]

もも

ストレステスト

ストレステストは、ソフトウェアシステムに対して高い負荷を与え、処理の低下・抜け、データの破壊、発熱など致命的な問題が、どういう条件で発生するかを試験する。ストレステストを行うことで、高い負荷が加わっている状況でしか発生しない不具合や、発生確率の低い欠陥、著しい性能の低下を発見することがある。性能試験の一部として実施し、対応可能な付加の仕様を確かめることがある。

[参考:Wikipedia]

もも

性能試験

性能試験は、ソフトウェアシステムの性能を測り、必要な性能が出ることを確かめる試験である。入力をどれだけ受付けるか、どれだけの出力が可能か。通信経路数・通信速度、処理件数などプログラム単体では問題が発生しなくても、通信、データベース、入出力 (I/O)、同時に起動するソフトウェアなどの高負荷、長時間使用などの条件下では性能が低下することがある。性能を確認する試験は、システムの性能に影響を与えないように測定する必要があるため、OSやミドルウェアなどでは性能を測定する効率的な計測方法を提供していることもある。 性能試験は、単体試験から実施する場合と統合試験から実施する場合とがある。 過負荷に対する性能試験をストレステストという。

[参考:Wikipedia]

キーワード関連:単体試験統合試験ストレステスト

 

もも

機能試験

機能試験は、規定した機能を果たすかどうかを試す。 関数であれば、規定した引数を与えると、想定した戻り値を返すブラックボックス試験が機能試験に相当し、単体試験の一部である。 適合試験、単体試験は、機能試験を主とするが、性能試験を含むことがある。

[参考:Wikipedia]

キーワード関連:ブラックボックス単体試験

もも

ソフトウェアレビュー

ソフトウェアプロジェクトの各工程において作成される成果物について、権限者や専門家が管理面ないし技術面から審査・評価・決裁・見直し・問題指摘などを行うこと。

ソフトウェアに関する主なレビューには、承認レビューと成果物レビューの2つがある。前者は契約やマネジメントで規定された正式な認証行為としてのレビューであり、後者はソフトウェア成果物に潜む問題の早期発見を図る品質活動としてのレビューである。このほかに作業状況を評価するレビュー、プロセス品質を評価するレビュー、採用技術の評価を行うレビュー、未経験者の教育を目的としたレビューなどがある。

[参考:ITmedia]

もも

インスペクション

最も公式なソフトウェアレビュー。ソフトウェア中の問題を検出するために、事前に定められた観点で第三者が厳密にレビュー対象を点検して欠陥の指摘と認定を行い、その結果に基づいて対象の修正と開発プロセスの評価・改善を行う。

インスペクションは、事前に定められた手順とチェックリストに従って第三者がレビューを行う、最も形式的なレビュー手法である。レビュー対象にはソースコードのほかにプロジェクト計画・要求定義・基本設計・詳細設計の各フェイズにおける各種成果物が含まれ、上流工程から実施可能な欠陥未然防止技法になっている。

[参考:ITmedia]

キーワード関連:ソフトウェアレビュー

もも

静的テスト

プログラムコードを実行せずに、ドキュメントやソースコードなどのチェックによって誤りや脆弱性を検出するテスト手法のこと。静的検証、静的検査ということもある。

静的テストには、ソースコードレビューや設計書レビュー、インスペクションなどのように人間が成果物をチェックする「ソフトウェアレビュー」と、モデル検査やメトリクス解析、コーディング規約違反チェック、静的解析、形式手法などの「コンピュータによる検査」がある。

[参考:ITmedia]

キーワード関連:インスペクションソフトウェアレビュー静的プログラム解析

 

もも

動的テスト

プログラムコードを実行して、その結果からソフトウェアのバグ検出や品質評価、動作確認を行うテスト方法のこと。静的テストの対語である。

一般にソフトウェアテストといえば動的テストをいう。静的テストはバグ検出効率やその修正コストなどの面で大きなメリットがあるとされるが、最終的なプログラムコードの品質を保証するものではないため、多くの開発プロジェクトでソフトウェアテストの中核は動的テストである(※)。両テストは相互補完的な関係にあるので、適材適所に実施することが望ましい。

[参考:ITmedia]

キーワード関連:静的テスト 動的プログラム解析

 

もも

ソフトウェアテスト

ソフトウェアテスト (Software testing) は、コンピュータのプログラムから仕様にない振舞または欠陥(バグ)を見つけ出す作業のことである。ソフトウェアテストで見つかったプログラム中の欠陥を修正する作業をデバッグという。ソフトウェアテストに成功するとは、テストで欠陥が発見されるか、規定した試験項目にすべて合格するか、規定した品質目標に到達することである。目標とした品質には、規定した試験項目にすべて合格することもある。

[参考:Wikipedia]

 

もも

キーワード駆動スクリプト

キーワード駆動スクリプト」では、スクリプトの部品化、スクリプトとデータの分離を行った上で、さらにそれらの部品を、自然言語に近い「キーワード」として抽象化します。ドメインエキスパートやテストエンジニアは、それらのキーワードを使うことで、スクリプトの内部構造を意識せずに自動テストケースを記述できるようになります。

[参考:システムテスト自動化 標準ガイド]

もも

データ駆動スクリプト

共有スクリプトでは一連の操作を分割することでスクリプトを部品化したのに対し、「データ駆動スクリプト」ではスクリプトとデータを分離します。これによって、「手順は同じだが、入力する値は異なる」テストケースを、1つのスクリプトと複数のデータのセットで実現することができます。

[参考:システムテスト自動化 標準ガイド]

もも

共有スクリプト

共有スクリプト」のアプローチでは、テストケース間で重複して現れるスクリプトを部品として切り出し、それらを複数のテストケースから呼び出すことで、テストスクリプトの保守性や可読性をさらに向上させることができます。また、部品同士を組み合わせた新しいテストケースを組み立てることもできるので、リニアスクリプトが抱えていた「線形」の問題から逃れられることになります。

[参考:システムテスト自動化 標準ガイド]

もも

構造化スクリプティング

構造化スクリプティング」では、分岐・反復といった、プログラミングの基本的な構造を使ってスクリプトを表現することで、スクリプトの保守性・可読性を向上させることができます。

ニアスクリプトや構造化スクリプティングのアプローチでは、複数のテストケースに共通の操作(たとえばログイン/ログアウト、特定の画面への遷移など)に対応するスクリプトがテストケースごとに現れるため、操作に変更が発生した場合、そのすべてを修正する必要があります。

[参考:システムテスト自動化 標準ガイド]

キーワード関連:ニアスクリプト

もも

リニアスクリプト

リニアスクリプト」は、キャプチャーリプレイツールで操作を記録することで自動生成されたスクリプトを、ほとんどそのまま使うものです。1つのテストケースが1つのテストスクリプトに対応するため、テストケースの数が10倍になればスクリプトの数も10倍と、「線形に(リニアに)」増加してしまいます。

[参考:システムテスト自動化 標準ガイド]

もも

自動化テストスクリプティング技法

テストを自動実行するためのスクリプティングの「技法」として、5つのアプローチがあります。
①リニアスクリプト
②構造化スクリプティング
③共有スクリプト
④ データ駆動スクリプト
⑤キーワード駆動スクリプト

[参考:システムテスト自動化 標準ガイド]

キーワード関連:リニアスクリプト構造化スクリプティング共有スクリプトデータ駆動スクリプトキーワード駆動スクリプト

もも

キーワード駆動テスト

キーワド駆動テストは、テストの自動化を行うときや、自動化のフレームワークの開発のときに用いられることの多い方法論です。
しかし、キーワード駆動テスト自体は自動化ためにだけ意味のあることではなく、自動化されていない、または自動化の予定がない場合でも有効な手段となります。

キーワード駆動テストはテスト用フレームワークで、ファンクションテスト用スクリプトの開発と、テストケースまたはワークフローの作成とを別々に行う事ができます。テストする特別なファンクションを表すキーワードやアクションワードを使用します。それらは各キーワード(データ)用の引数と一緒に外部データ表内にあります。

このプロセスはデータ駆動テストと似ていますが、純粋にデータだけを入力するのではなく、キーワードと関連するデータを一緒にテスト実行ドライバに入力します。

[参考:EggplantIVIA]

もも

ISO/IEC/IEEE 29119

ISO/IEC/IEEE 29119は、「ソフトウェアテストの国際規格」です。
・本規格で提示されているテストの考え方(プロセス、文書、テスト技法)は、国際的に通用するものである
・あらゆるソフトウェア組織に適用可能である
・あらゆるソフトウェア開発に適用可能である

[参考:WikipediaIVIA]

もも

テスト自動化

テスト自動化(テストじどうか)とは、テスト支援ツール等を使うことにより、ソフトウェアテストを自動化することである。 ソフトウェアテストを行うためには、以下のような作業をする必要がある。テスト自動化とは、これらの作業の一部を自動化することである。

  • テストケースの設計
  • テストの実行と結果の確認
  • テスト進捗の管理
  • レポートの作成

[参考:Wikipedia]

もも

ビヘイビア駆動開発

テスト駆動開発で記述されるテストケースは、作成したプログラムの動作が正しいかどうかを検証するために行う「テスト」である。テストであるという点は同一であるが、加えて、これから作成しようとするプログラムに期待される「振る舞い」や「制約条件」、つまり「要求仕様」に近い形で、自然言語を併記しながらテストコードを記述する。テストフレームワークのメソッド名も自然言語(英語など)に近い形をとっている。

テストコードの可読性があがる上、テストコードが要求仕様となりうる。要求仕様からテストコードを起こす際も、スムーズにコードに移行しやすい。

BDDではスペック(仕様)とテストは限りなく近い物である。従って、テスト駆動開発における「テストファースト」は、BDDにおいては「スペックファースト」となり、スペックを作ってから実装するという、より自然な形でのプログラム製作を実現している。

いくつかのテストフレームワークは、

  • アプリケーションの振る舞いを記述するストーリーフレームワーク
  • オブジェクトの振る舞いを記述するスペックフレームワーク

の2種類を含む。

[参考:Wikipedia]

もも

エクストリーム・プログラミング

エクストリーム・プログラミングXP(英: extreme programming)は、ケント・ベックらによって定式化され、提唱されているソフトウェア開発手法である。柔軟性の高い開発手法であるため、難易度の高い開発やビジネス上の要求が刻々と変わるような状況に向いた開発手法である。事前計画よりも柔軟性を重視する。1999年に書籍『XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法』によって発表された。

XPは、軽量開発手法あるいはアジャイルソフトウェア開発手法と呼ばれる、同種の開発手法のなかで代表的なものである。柔軟性の高い開発手法であるが、古典的には開発が進むにつれ変更コストは大きくなると言うことを前提に開発手法が構築されているのに対して、自動テストを導入するなど様々な対策をすることにより開発が進んでも変更コストが大きくならないような工夫を持ち込むことにより、変更に対する柔軟性を実現している。この変更コストが増大しないという前提が破綻すると、この手法も破綻する。

XPは比較的少人数の開発にもっとも適用しやすく、5つの価値と19の具体的なプラクティス(実践)が定義されている。XPはドキュメントよりもソースコードを、組織的開発の歯車となることよりも、個人の責任と勇気を重んじる人間中心の開発プロセスであるとしている。

[参考:Wikipedia]

もも

アジャイルソフトウェア開発

アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。 近年、アジャイルソフトウェア開発手法が数多く考案されている。 ソフトウェア開発で実際に採用される事例も少しずつではあるが増えつつある。 アジャイルソフトウェア開発手法の例としては、エクストリーム・プログラミング (XP) などがある。 非営利組織 Agile Alliance がアジャイルソフトウェア開発手法を推進している

[参考:Wikipedia]

もも

VDM

VDMVienna Development Method)は、IBMのウィーン研究所で1960年代から70年代にかけて開発された形式手法。

その仕様記述言語VDM-SLは1996年にISO標準(ISO_IEC_13817-1)となっている。VDM-SLをオブジェクト指向拡張したVDM++も、欧州連合ESPRIT計画のAFRODITEプロジェクトで開発された。

[参考:Wikipedia]

もも
もも

B-Method

B-Methodとは、AMN(Abstract Machine Notation)という仕様記述言語(兼プログラミング言語)を中心とした形式手法に基づいたソフトウェア開発手法である。B-Method で使用する形式手法やそのツール群は単に B と呼ぶ。

Jean-Raymond Abrial を中心としてフランスおよびイギリスで開発された。Abrial の開発したZ言語とも関連しており、仕様からのプログラミング言語コード作成をサポートしている。ヨーロッパでは、大規模なインフラシステムで利用されており(パリのメトロ14号線など)、産業界の注目を集めつつある。堅牢で商業利用可能なツールが提供されており、仕様記述、設計、検証、ソースコード生成が可能である。

Z言語に比較して抽象化レベルが低く、単なる形式仕様記述というよりもコードへの詳細化に重きを置いている。そのため、B で書かれた仕様はZ言語の場合よりも実装が容易である。特にそのために様々なツール群が用意されている。

[参考:Wikipedia]

もも

テスト駆動開発

テスト駆動開発 (てすとくどうかいはつ、test-driven development; TDD) とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き(これをテストファーストと言う)、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。多くのアジャイルソフトウェア開発手法、例えばエクストリーム・プログラミングにおいて強く推奨されている。近年はビヘイビア駆動開発へと発展を遂げている。

[参考:Wikipedia]

キーワード関連:アジャイルソフトウェア開発エクストリーム・プログラミングビヘイビア駆動開発

もも

MAIC

MAICとは、シックス・シグマにおける行動プロセスである。QCサークル活動などおけるPDCAサイクルを発展させたものであるが、大きな特徴はM(Measurement)、A(Analysis)という現状分析に、より大きな主眼をおいていることである。

MAICの意味は次のとおりである。下記プロセスを持続的に繰り返す。

  1. Measurement:測定
  2. Analysis:分析
  3. Improvement:改善
  4. Control:改善定着の管理

[参考:Wikipedia]

もも

シックス・シグマ

シックス・シグマSix Sigma, Lean Six Sigma)とは、1980年代に米モトローラが開発した品質管理手法、または経営手法である。その適用範囲は、主に製造業が中心であるが、製造業の製造部門に留まらず、営業部門、企画部門などの間接部門への適用、更にはサービス業などの非製造業への適用も多い。統計分析手法、品質管理手法を体系的に用いて製品製造工程などの各種プロセスの分析を行い、原因の特定やそれへの対策を行って、不良率の引き下げや顧客満足度の向上などをしていく。

[参考:Wikipedia]

キーワード関連:MAIC

もも

ISO/IEC 15504

ISO/IEC 15504 は,世の中に存在するプロセス診断のモデルや方法についての枠組み(フレームワーク)であって特定のモデルだけに適用できる標準規格ではない。その主題は組織の運営能力と作業(プロセス)定義構造に基づいた診断(アセスメント)である。ISO/IEC 15504は 、完結した方法論を網羅せず,いろいろな方法論の共通部分だけを規定している。例示としてのモデルの一つ第5部(Part5)は、ソフトウェア事業(プロジェクト)で発生しうる活動の枠組みであるソフトウェアライフサイクルプロセス(ISO/IEC 12207: JIS X 0160)に対して、やっていてよかった指標(プラクティス)を示している。第6部(Part6)は、システムライフサイクルプロセス(ISO/IEC 15288: JIS X 0170)に対するモデルである。モデルに記載していることはやっていてよかったという過去の知見である。実施すべきものとしているわけではない。作業生産物(work product)も例である。紙であることを明示しているものは少ない。ISO/IEC 15504 は診断員(assessor)が対象の入力と出力に関して診断の前から分かっていること、面談の結果や証拠を分類し、作業の能力を判定する。診断のやり方は調達を目的として外部から観察する方法と、改善を目的として内部で作業をしている人が判断する方法がある。

[参考:Wikipedia]

もも

ISO 9000

ISO 9000シリーズないし、ISO 9000ファミリーとは、国際標準化機構 (ISO) による品質マネジメントシステムに関する規格の総称で、その中核をなす規格はISO 9001である。もともと、現在のISO 9001の前身となる規格が事業所の性格に応じてISO 9001、ISO 9002、ISO 9003に分かれていたことや、現在でも関連の規格が9000番台である物が中心になっているので、まとめてISO 9000シリーズと呼ばれる。認証の対象となる規格はISO 9001である。

[参考:Wikipedia]

もも

ISO/IEC 12207

ISO/IEC 12207 (Systems and software engineering — Software life cycle processes) とは、ソフトウェアのライフサイクル全般についての標準である。国際標準化機構 (ISO) と国際電気標準会議 (IEC) の合同技術委員会 (JTC 1) が1995年に策定した。ソフトウェアの開発や保守に関わる活動全般の標準を定義することを目的としている。翻訳が、日本工業規格 JIS X 0160(ソフトウェアライフサイクルプロセス)になっている。

ISO/IEC 12207 ではソフトウェアのライフサイクルを定義しており、システム上のサービスの入手や構成に関わる活動やプロセスも含まれる。各プロセスには必ずその出力となるものが定義されている。実際には 23種類のプロセス、95種類の活動、325種類のタスク、224種類の出力(成果物)が定義されている。

この標準の主な目的は、ソフトウェアの開発や保守に関わる様々なステークホルダー(購入者、提供者、開発者、保守者、操作者、管理者、技術者)に共通の構造を提供し、相互のコミュニケーションを円滑にすることである。そのような共通の言語はうまく定義されたプロセスで確立される。標準自体の構造は柔軟でモジュール性があり、必要な人が必要な部分だけを採用することができるようになっている。この標準の2つの基本原則は、モジュール性と信頼性である。モジュール性とは、定義されたプロセス間の結合度が最小で凝集度が最大となっていることを意味する。信頼性とは、各プロセスの信頼性を確立し、標準を応用したプロジェクトに多くの人々が法的に参加できるものにすることである。

プロセス、活動、タスクはソフトウェアプロジェクトに適用可能である。プロセスは3種類に分類されている。

基本プロセス
購入プロセス(発注プロセス)、提供プロセス、開発プロセス、運用プロセス、保守プロセス
サポートプロセス
文書化プロセス、構成プロセス、品質保証プロセス、検証プロセス、評価プロセス、ジョイントレビュープロセス、報告プロセス、問題解決プロセス
組織プロセス
管理プロセス、基盤プロセス、改善プロセス、訓練プロセス

[参考:Wikipedia]

もも

プロセスモデル

プロセスモデル(英: process model)とは、何らかのプロセス(過程、工程)の模型(モデル)である。 化学工学はプロセス産業と呼ぶように、プロセスモデルが処理モデルである。 ビジネスプロセスモデルとは、企業の仕事の仕方のモデルである。 コンピュータでは、処理方法がプロセスモデルである。並列処理の方式などがある。 ソフトウェアプロセスは、ソフトウェアを設計し、利用し、廃棄する流れの一つの視点を提供するものであり、人の作業とコンピュータの処理を含む。

コレット・ローランドはプロセスモデルを次のように定義している:

同じ性質を持つプロセスは1つのプロセスモデルに分類する。つまり、プロセスモデルはプロセスの抽象記述である。プロセスモデルが抽象的であるとすれば、個々のプロセスは実体化したものである。

プロセスモデルは様々な開発に繰り返し利用するため、その実体は多数存在する。 […] プロセスモデルは「物事をどのようにするか(するべきか/しなければならないか)」を記述したものである。

プロセスモデルは、プロセスがどのようになるかを仮定し、予測するものである。仮定を立てるためには、前提条件が必要となり、時間的な条件、論理的な条件または空間的条件を設定する。時間的条件には初期条件,終了条件がある。論理的な条件には事前条件,事後条件,不変条件がある。空間的条件には、境界条件がある。 プロセスがこうあるべきだという方針は、常に状況(前提条件の変化)に応じて改善していくものである。
プロセスモデルの分類:
①適用分野による分類

[Dowson1988]は、以下の4つの異なる意味でプロセスモデルという用語が使われているとした:

活動指向: ある製品を定義する目的の下で関連する活動群。目標達成までの半順序的ステップ群。[Feiler1993][5]
製品指向: 製品を目標のレベルにするための一連の活動。
決定指向: 特定の製品定義のために必要な決定の集合。
文脈指向: 製品の改良をもたらす一連の文脈(コンテキスト)の集合。

②レベルによる分類

ローランドによれば、プロセスは以下のように分類され、それぞれモデル化手法が異なる。

戦略的プロセス
代替案を検討し、それを実行する計画を立案することもある。
高度な活動であり、代替案の選択も重要な選択となる。
戦術的プロセス
計画の実行を支援する。
実際の計画実行により近く、計画の詳細化を行う。
実装プロセス
最も下位のプロセス。
計画を実施するための詳細を扱う。

③粒度による分類

粒度とは、プロセスモデルの詳細さのレベルを意味する。

「粒度は提供すべき手引き、説明、手順の種類に影響を与える。粒度が粗い場合、あまり具体化しない。粒度が細かい場合、より詳細なものを提供する。必要とされる粒度は状況に依存する」[Rolland1998]

顧客や経営者は粗い粒度のプロセス記述を要求する傾向があり、意思決定のための概略的情報を必要とする。一方、ソフトウェア技術者やユーザーは細かい粒度のプロセスモデルを必要とし、それによって具体的手順を知ったり、個々の人々の依存関係が明らかになる。

細かい粒度のモデル記述法もあるが、粗い粒度のモデル記述法の方が古くから存在する。プロセスモデルは理想的にはあらゆる粒度に対応できるのが望ましい(例えば、Process Weaver [Fernström1991])[Rolland1998]。
④柔軟性による分類

プロセスモデルは何らかの予測を行うが、実際に起きることは予測通りではない[Rolland1999]。従って、フレームワークを実際の状況に合わせて修正することでモデルの価値が向上する。このようなフレームワークの研究を Situational Method Engineering と呼ぶ。

方式を構築する手法は柔軟性の低いものから高いものまである[Harmsen1994]。

[参考:Wikipedia]

もも