コード日進月歩

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

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

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

言葉としての意味

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

初出

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つの条件文の真偽を両方確かめることが

複合条件網羅 (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網羅になる。

関連リンク

「サボタージュマニュアル」に関してざっくりまとめる

原文がどういうものかも含めてざっくりまとめる

サボタージュマニュアルとは

CIAが第二次世界大戦中の1944年頃に作成された文書で、妨害工作員が日々の行動の中で実現可能な妨害工作に関してまとめられたもの。組織内の人間関係を悪くすることで妨害を行う方法に関しても記載されているため、組織づくりにおいてのバッドノウハウ集として取り上げられることがある。

文章の8割程度が戦時中を背景とした破壊工作などに関してのマニュアルなので、現代のプロジェクト活動に関して関連しそうな部分を中心にこの記事ではざっくりまとめます。

原文

原文はHTML化されたものが公開されている、以下のURL

構成内容

大きくは5つのパートに別れている

  1. はじめに
  2. 考えられる効果
  3. 工作員の動機付け
  4. ツール、ターゲット、タイミング
  5. 単純な妨害行為に対する具体的な提案

この中でも、5では日々の物理的な破壊工作のテクニックなどと合わせて最後に「組織と生産への一般的な干渉」という形で紹介されている。

紹介されている妨害の内容

戦時中ということで戦争が背景にある内容もいくつかあるが、大まかにまとめると以下のようになる。

  • 簡単な仕事でも繰り返し内容に関して質問をして、時間をかけて指示を理解するまでに時間がかかるフリをする
  • 重要な仕事ほどあとでやり、全体的に遅くなるように仕向ける
  • 命令を求め、命令を誤解して、その説明に時間を多くかけさせる
  • 組織のモラルを低下させる。仕事ができない理由を道具や設備のせいにする。
  • 組織の意思決定をあらゆる手で遅らせる

この中でも組織に関しての妨害干渉がいくつかあり、以下のような内容がある。

  • 可能な限り、すべての事柄を委員会に付託し、「さらなる研究と考察」を求める。委員会の人数はできるだけ多くし、決して5人以下にはしない。
  • できるだけ頻繁に無関係な問題を持ち出す。
  • もっと重要な仕事があるのに、会議を開く。
  • もっともらしい方法でペーパーワークを増やす。重複したファイルを作成する。
  • 指示書や給与明細書などの発行に関わる手続きやクリアランスを多重化する。1人でできることはすべて3人で承認しなければならないことを確認する。
  • 「合理的」であること、そして「合理的」であることを同僚に促し、後で困惑や困難を招くような急ぎすぎを避けること。
  • どのような決定も妥当かどうか心配し、そのような行動がグループの管轄内にあるのか、あるいはもっと上位の層の方針と矛盾する可能性があるのか、疑問を投げかける。
  • 可能であれば、従業員の問題を経営陣に提示するグループに参加するか、その編成に協力すること。その際、多くの従業員が出席すること、苦情ごとに複数回の会議を開くこと、架空の問題を持ち出すことなど、経営陣にとってできるだけ不都合な手続きを採用するよう注意する。

この「妨害工作」から反面教師で学べること

具体的な妨害工作が書かれているが、これは自然発生的にも起こりうる現象なので、これらを未然に防ぐことが肝要かと思われる。

なかでも組織運用に関してはひたすらに承認者を増やしたり、「心配である」という背景のもとやることを増やす、というようなことは善意から発生しうる行為なので、サボタージュを自分自身で引き起こしていないかという自戒としては活きる。

また従業員の妨害工作に関しても、意図的に遅らせるという話以外にも繰り返し何度も説明を求めて遅らせるという行為があるので、これを逆に考えると簡潔で伝わりやすい情報伝達やコミュニケーションを心がけないと、妨害工作に匹敵する行動に発展してしまうということに気をつけなければいけない。

関連リンク

CSSにおけるVendor Prefixとはどういうもので、何があるのかざっくりまとめる

非常にググりにくい -moz--webkit- などがつくCSSの要素についてざっくりまとめる

Vendor Prefix(ベンダープレフィックス)とは

MDNには以下のような記載がある

ブラウザーベンダー (提供元) は、時に試験的または非標準な CSS プロパティおよび JavaScript API に接頭辞を追加することがあります。これにより、開発者は標準化プロセスの中で、理論上は、ウェブ開発者のコードを壊すことなく新しいアイデアを試すことができます。 -Vendor Prefix (ベンダー接頭辞) - MDN Web Docs 用語集: ウェブ関連用語の定義 | MDN

このようにブラウザベンダー(ChromeFirefoxなど)がブラウザ特有な記述を追加する際にわかりやすくつけるようなprefix

Vendor Prefixの代表的なもの

prefix 対応するもの
-webkit- WebKit ベースのブラウザのだいたい(Chrome/Safari)
-moz- Firefox
-o- WebKit 導入前の古い Opera
-ms- Internet ExplorerMicrosoft Edge

カバーをするための方法

ベンダープレフィックスを使うこと自体がよろしくないという風潮はあるようではある(関連リンク参照)ので、減少する傾向にはありそうですが、まだ各ブラウザ間で使われている現状はある。

ただ、AutoPrefixerというプラグインがあり、こちらは対応したいブラウザを明示すればprefixが必要な場合に適宜当てたものを出力してくれる。

関連リンク

Rubyのraiseはエラーの指定を省略すると直前の例外を再度raiseさせる

知らなかった仕様

検証した環境

$ ruby -v
ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-darwin19]

出典

例外を発生させます。第一の形式(引用注:raise のみの記述のこと)では直前の例外を再発生させます。 - 制御構造 (Ruby 3.1 リファレンスマニュアル)

というようになっているので、raiseは引数を省略させると同じエラーを発生させる

実例

raiseの直後にraiseを呼ぶというのはrescue句以外だとつかわない、もとよりできないと思うのでrescueの場合の例を記述する。

以下の内容で test.rb をつくる

def demo_raise(happen_exception)
  raise StandardError, "これはエラーです" if happen_exception
  return true
end

begin
  demo_raise(true)
rescue
  p "catch exception"
  raise
end

これを実行すると以下のようになる

$  ruby test.rb
"catch exception"
test.rb:2:in `demo_raise': これはエラーです (StandardError)
        from test.rb:7:in `<main>'

raiseには何も指定していないのに直前のエラーを出している。ただし ensure や ブロックの外だと拾ってもらえないので気をつける

関連リンク

『ソフトウェア品質を高める開発者テスト 改訂版 アジャイル時代の実践的・効率的でスムーズなテストのやり方』を読み終わったよメモ

下記の本を買ってサッと読んだのでメモです

買った経緯

下記の記事でアジャイルなテストに関して語られており、メインスピーカーの方が新しく書籍を出されていたので気になり購入してみた。

logmi.jp

所感

品質のチェックを最後に寄せない、先にやる

買った動機の部分で紹介したお話でも主張されている内容ですが、この書籍で特に主張されている部分としては主に以下の点だと私は感じました。

  • バグの検出をシステム開発の最後の工程に寄せないで前半の工程でも検知していく(シフトレフト)
  • 単体テストをしやすいコードを下記、なるべく増やす
  • 単体テストもすべてやろうとしてない、抑えるべきところを抑える(HotSpot/C1網羅)
  • そもそも複雑にしない

従来からテストコードを重きにおく考え方に親しんできた開発者には馴染みのある部分もありますが、品質管理の分野の観点からも語られているのはよかったです。

新たな観点

「テストコードは書くべきである」「テストコードは後半のテスト作業の圧縮に寄与する」という部分や、テストコードの書き方一般論は割と他の書籍などで語られている部分でもあるのですが、こちらは著者の経験則と2000年代までのソフトウェアテストの文献の内容がアレンジされており、他の書籍ではあまり見たことのない観点もいくつかありました。自分が深堀りをしたほうがいいなと思ったのは以下のトピックです。

  • HotSpot
  • C0網羅/C1網羅
  • McCabe数(循環的複雑度)の指標

その他気になったこと

経験値がアレンジされた書籍なので、かなり経験談ベースの話が多いのですが書きっぷりがかなり口語調かつ読み手によっては不快感を感じることも多い文体なので、万人にオススメできるような感じではありませんでした。

ただ、筆者のかたの経験値と引用書籍の情報はおそらく他にあまりないものだと思いますし、主張自体も理解できる部分が多いものだったので私個人としては大変学びが多かったですし、純粋なテストケースを作ることに対する対策の解として知見を得ることができました。

また、この記事を読む前にtexta.fm第9回SideShowのテストに関する回を聞いており、チェッキングや探索的テストに関しての知見を聞いて理解度が高まったので、合わせて聞くと非常にいいかなと思いました。

関連リンク

中二日、中三日など中○日という表現が表す日程に関してざっくりまとめる

なかふつか、なかみっかなどと表現するがググりにくい言葉なのでざっとまとめる

中○日とは

日単位のアクションにおいて、事象を行ってから結果が発生するまでの間にかかる日数を示している。始端の日と終端の日を除いてかかる日数。

例えば「5/4から中3日かかる」という話だと5/8に結果が届くということを示す。図解すると以下のイメージ

主に使われる場面

  • スポーツ
  • 運送

でよく使われる傾向がある。特に運送などの場合は営業日の概念がここに入るので、ややこしくなるが基本的は間に入る日数というところを起点に考える。

定義が曖昧なので確認したほうがいい

ただしこの中○日、スポーツの場合は概ね上記で述べた考え方で問題がないのだが、発送の場合は到着が終端の日にあたるので発送する日自体は中○日の中に含まれるケースもあれば、そうでないケースもある様子なので不安な場合は確認を行ったほうがよさそう。

参考サイト