コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

ほどよし信頼性工学に関してソフトウェアテストと絡めてざっくりまとめる

信頼性を高める工程はある一定の信頼まで達するとそれ以上のものにするコストは高まるという話

サイト「新語時事用語辞典」曰く

時事用語を扱っている新語時事用語辞典の記載内容がまとまっているため引用すると以下の通り

商用の超小型衛星に関する設計思想で、設計信頼度をとことん追究するよりも、むしろ性能・信頼性・コストのバランスがほどよくつりあうことを重視するという考え方。東京大学大学院・中須賀研究室を中心として提唱されている。ほどよし信頼性工学の考え方は、つまり「ほどほどに手を抜く」ことであると言える。 - 新語時事用語辞典: ほどよし信頼性工学

信頼性とコストの壁

提唱している方曰く、宇宙開発におけるコストと信頼性の完成はある程度の段階まではコストを抑えつつ信頼性を上げることが可能だが、あるレベルのボーダーラインを超えるといきなり信頼性の増加に対してコストが高くつく。

ほどよし信頼性工学における信頼性とコストの考え方

そのため、そのボーダーラインを超えないレベルの信頼性まで高めて問題ないものをつくる、という考え方になる。

ソフトウェア開発のテストにもつながる部分

ソフトウェアにおいても信頼性を突き詰めていく場合に一定のレベルでは不具合が起きないが、「100%不具合が起きない」という状態に近づけようとすればするほどコストはあがる。そのうち細かい穴を埋めていくレベルにまで達すると穴を探して埋めることがコスト高となる。

そのためほどほどの信頼度で開発しつつ、エッジケースになるような不具合を埋めるための信頼性の向上をするのではなく、不具合が起きたときに早期に復旧できるような仕組みを考えるなど、ほどよし信頼性工学の実践しているアプローチを転用できると考えられる。

参考リンク

なお、言葉そのものを知ったきっかけは下記書籍から

Pairwise法に関してざっくりまとめる

経験則から導かれた方法ではあるが、どういう利点と欠点があるのかを調べる

概要

3つ以上のパラメータがある場合、そのすべてのパラメータの組み合わせを調べるのではなく、パラメータを2つで1つのペアと考え、そのペアのパターンが全網羅されるようにテストケースを考える手法

たとえば利用者の「性別」「成年かどうか」「過去に1回でも利用しているか」の3つの要素によって振る舞いが変わる処理があるとする。その場合愚直に組み合わせをつくると8個のケースを考える必要がある。

ただし、ペアワイズ法を用いると、それぞれの要素の組み合わせがあるかを見ればいいので4個のケースを探せば満たせる

ケースを減らす背景

組み合わせは増えれば増えるほど爆発的に増えるので、全数テストをせずにいかにバグを出すかということが求められるのでその1つのアプローチ。

なぜペアなのか

なぜペアワイズはペアで考えるのかというと2004年頃の論文にて「データとして残っている障害のうち70%以上が1つか2つの条件によってのみ引き起こされている」という旨の記載があり、4つや5つのパラメータの組み合わせのパターンでは発生しないということが説明されている。

このような研究結果と、全数テストが難しいというところで編み出されたのがこのペアワイズの手法である。

ペアワイズを試したい場合

3つのパラメータなどであれば上記であげたようにできるが、4つ以上のパラメータになると組み合わせの洗い出しだけでも難しいので自動ツールを使うとよい。もともとはマイクロソフトが提供しているPICT が有名であるが、現在ではいろいろなツールが提供されている。

参考サイト

クレイグ・ラーマンの法則に関してざっくりまとめる

あまり情報がないのでざっくり再理解のためにもまとめる

原典

Larman's Laws of Organizational Behavior - Craig Larman

内容について

日本語訳に関しては下記を参照していただきたい。

クレイグ・ラーマンの法則 (Larman’s Laws) - スクラムマスター

組織と文化に関してのラーマン氏の体験した内容を法則の形で文章としてまとめており、「文化は組織構造に従う」ということを述べています。

大きな組織の文化を変えたい場合は組織構造を変えないといけないしそうなるような取り組みをしなければならない、というのがこの法則でのメインの部分だと思われます。

逆に組織が小さい場合は文化(ここで言うところの文化は個々人の振る舞いと捉えるとよさそう)に組織構造が最適化されるということも紹介されており、組織サイズによって構造にアプローチすべきか、人にアプローチすべきかが変わるということかと思われます。

そもそもクレイグ・ラーマン氏とは

ご本人のプロフィール紹介英語版のWikipediaから読み解くと、昔からソフトウェア開発者から開発手法に関して様々な取り組みをされてきた方。近年はスクラムアジャイルに関しての取り組みが多く、LeSS (Large-Scale Scrum)の共同策定者でもある。

参考リンク

カラーユニバーサルデザインについてざっくりまとめる

プレゼン資料を作る際に、色覚の違いに配慮したいなと思いざっくり調べてみた

概要

カラーユニバーサルデザインはカラーユニバーサルデザイン機構(Color Universal Design Organization ,略称CUDO)によって提唱されている考え方で、公式サイトの言葉を引用すると「人の色覚の多様性に対応した製品や施設・建築物、環境、サービス、情報を提供する考え方」

大きく提唱しているポイントとしては以下の3点

  • できるだけ多くの人に見分けやすい配色を選ぶ。
  • 色を見分けにくい人(場合)でも情報が伝わるようにする。
  • 色の名前を用いたコミュニケーションを可能にする

参考にできるポイント

色覚に基づいて、モニタの見え方や印刷物において見分けやすい配色に関してガイドを公開している。

カラーユニバーサルデザイン推奨配色セットについて

情報伝達において、色の感じ方が異なる場合に見えづらくなることが発生しづらい配色の組み合わせが紹介されており、広く多くの方に公開する資料を作る際に参考になる情報

関連リンク

iCalendarというカレンダー情報の標準形式についてざっくりまとめる

イベントなどでicsファイルを提供しているケースがあるので、そのicsファイルの使用に関して調べる

仕様の情報元

もともとはRFC 2445 - Internet Calendaring and Scheduling Core Object Specification (iCalendar)がベースにあるが、改定され現在はRFC 5545: Internet Calendaring and Scheduling Core Object Specification (iCalendar)が最新の仕様となっている。

なお拡張子は ical , ics などがある。

ざっくりな仕様

カレンダーやスケジュールを共有するためのフォーマット仕様。以下のような情報が定義できる

  • 予定の開始と終了の日時
  • 予定の詳細
  • 予定自体が作られた日付、管理用のID
  • 開催場所

上記のようなカレンダー的な用途の他にもTODO情報やジャーナル情報のようなものを定義するためのフォーマットも用意されている。

また、一部のソフトウェアに適応できるようにXと接頭辞がついたパラメータも用意されている。

2022年時点において

かなり前に策定されたものだが、2022年時点でも使われているフォーマットであり、WebサービスとしてはGoogleカレンダーサイボウズなどでも使われているため、カレンダーのインポートエクスポートを考える際には利用できる仕様と思われる。

参考リンク

シフトレフトテストとは何なのかざっくりまとめる

フレーズとして認識しているがもうちょっと掘り下げて確認する

言葉としての意味

シフトレストテストあるいはシフトレフトとは、開発のライフサイクルを左から右に流れる時系列になぞらえてなるべく左の方にシフトしてテストを行う、つまり開発の早い段階でテストを行うという考え方。

初出

Larry Smith氏のブログ記事Shift-Left Testingが初出とされている

記事で語られていること

ブログ記事は2001/9/1ですが、QAのタイミングと自動テストの有用性に関して語られており、自動テストをすべきという話や、テストコードを書きやすいプロダクションコードは利点があるなどが記載されています。

2022年時点におけるシフトレフト

2022年時点ではシフトレフト自体は継続的テストと合わせて語られるようになり、またバグは早期発見すると影響度を最小限にして修正が可能になるという話にもつながる部分で多く意識されるようになってきたように思われます。

関連リンク

ホワイトボックステストにおける制御フローテストに関してざっくりまとめる

制御フローテストとは

制御フローテストはホワイトボックステストの一種で、文字通り「制御のフロー」をテストするもの。プログラムにおいて、ソースコードの処理そのものを網羅するテストのことを指すことが多い。網羅に関しての基準がいくつかあるため、基準の名前を交えながら説明していく。

制御フローテストにおける網羅の種別

以下のRubyの2つのメソッドのデモコードでどの範囲を網羅するものなのかを説明します。

def single_test(value_a)
  if value_a > 10
    print "over 10"
  end

  print "end"
end
def twin_test(value_a, value_b)
  if (value_a > 5 && value_b > 20)
    print "double match"
  else
    print "not double match"
  end
end

命令網羅 (Statement Coverage)

命令網羅は文字通り、すべての行が実行され網羅できているかを確かめるテスト。

single_test の場合は 10以上の値をセットして実行すればOKなので single_test(11) などを実行すれば満たせる twin_test の場合はifの分岐を両方通るようにすればいいので、 twin_test(0,0)twin_test(100,100) を実行すれば満たせる。

判定網羅(Decision Coverage)

判定網羅は判定文の条件をすべて網羅していることを確認するテスト。

twin_test を例に上げると、if (value_a > 5 && value_b > 20) がtrueとfalseのときのテストをすることが必要なので、 twin_test(0,1)twin_test(10,30) のように判定の真偽を両方実行できればOK

条件網羅 (Condition Coverage)

条件網羅は判定文の条件が網羅できているかのテストです。

twin_test の場合、 value_a > 5value_b > 20 という2つの条件があるため、この2つの条件文の真偽を両方確かめることができていればOK

複合条件網羅 (Multiple Condition Coverage)

複合条件網羅は「複合条件」における条件設定を網羅していることを確認するテスト。条件内の値に着目するのではなく条件の状態に着目して網羅する。

twin_test の場合、value_a > 5value_b > 20 この2つの条件、つまり複合の条件を網羅する。たとえばvalue_a > 5 が条件1、value_b > 20が条件2としたときに以下の4つの状態をテストすれば網羅できる

  • 条件1が真 、 条件2が真
  • 条件1が真 、 条件2が偽
  • 条件1が偽 、 条件2が真
  • 条件1が偽 、 条件2が偽

なので以下のような値のテストをすれば複合網羅条件はクリアとなる

条件 value_a value_b
真&真 10 30
真&偽 7 11
偽&真 3 24
偽&偽 2 10

MC/DC網羅(Modified Condition/Decision Coverage)

MC/DC網羅は条件分岐のパターンを網羅していることを確認するテスト。なお、MC/DCは Modified Condition/Decision Coverage の略。複合条件網羅では各条件の真偽を確認したが、こちらは更に引いて複合条件の条件文そのもので発生するパターンのみにする。

twin_test の場合、

if (value_a > 5 && value_b > 20)
  print "double match"
else
  print "not double match"
end

とあるように value_a > 5 && value_b > 20 を満たすときと満たさない時で分岐するのでそこに着目してテストケースを考えます。たとえばvalue_a > 5 が条件1、value_b > 20が条件2としたときにMC/DCで考えるべきは以下の3つのケースになります。

  1. 条件1も条件2のときに満たす処理があるので「条件1が真 、条件2が真」のケース
  2. 条件1は満たすが、条件2を満たさないときにelse以降の処理にいく必要があるので「条件1が真、条件2が偽」のケース
  3. 条件1が満たせていないとelseにいくのでその流れを確かめるケース。具体的には条件1が偽であればいいので、「条件1が偽、条件2が真」あるいは「条件1が偽、条件2が偽」のケースのいずれか。

そのため一覧化すると以下のようになる

条件 value_a value_b
真&真 6 30
真&偽 7 11
条件1が偽 3 24

このように条件1が偽であれば、条件2の状態別のチェックは省略するというようなコンセプトのものがMD/DC網羅になる。

関連リンク