常連

会社でテストの品質が悪く、単体テストレベルのバグがお客様の総合テストで数多く発見され、ある一定の品質を保つためにテスト仕様書を作成することになりました。
テスト仕様書のひな形を作成するように言われたのですが、いい例を見つけられずに困っています。
いい例を紹介いただけませんでしょうか？
よろしくお願い致します。

テスト仕様書について

## テーマ、知りたいこと

SIerをされている方にご回答いただきたいです。
教えていただきたいのは、「テストコードを書いているか」です。
(可能であれば、開発言語と利用されているフレームワークも教えていただきたいです)

## 背景、状況

私はSIerとして5年程、基幹系システムの開発(コーディング、単体テストフェーズ)に
従事しておりますが、業務では一度もテストコードを書いたことがありません。
現在転職を検討中ですが、そもそもテストコードをまともに書けないプログラマって
どうなんだろうかと悩んでおります。

会社はテストコード書くことに対して否定的なのですが、一般的にどうなのか
気になったので教えていただけると幸いです。



テストコードを書くか否かについて

１、インストールは環境を触るのでできるだけ.zipファイルをダウンロードしてきてその中の.exeファイルを使う方が安全だと思うのですが実際どうなのでしょうか？　環境をいじることによって動作がおかしくなるとかよくわからん謎のエラーに悩まされるといったよくある問題のことです。

2、.exeインストーラーでインストールした.exeは消しても大丈夫なのでしょうか？提示画像



![イメージ説明](106562d59f4301812ff34047bbc629c2.png)

環境構築 .exe と.zipどっちが安全なのか知りたい。ソフトウェアのインストールと利用

C言語で組み込みの開発をやっています。
今担当しているソースには下のようなソースがたくさんあります。

ユニットテストでの確認対象としては、なんとなく下記のような事が考えられますが、みなさんはどの程度までユニットテストで確認していますか？
可能なら、その理由も教えて頂けると助かります。
担当しているプロジェクトでのユニットテストの方針を決める上で参考にしたいと思います。

1)関数の戻り値（例はvoidですが・・・）
2)グローバル変数の出力値
3)関数コールの有無（スタブを作成して確認）
4)関数コールへ渡す引数の値（スタブを作成して確認）
5)呼び出し先関数の中身も考慮した出力値

**※当初の質問内容では、期待していた回答をなかなか得られていなかったので、質問内容を大幅に修正させて頂きました。すでに回答してくださった方、ありがとうございます。**

```c言語
int value;

void func(){
　　　value = funcXYZ();
　　　if(value == x){
		funcX(x);
		funcA();
	}else{
		funcX(a);
		funcB();
	}
}
```

ユニットテストでどこまで確認するのか？

先日，最終回を迎えたTVドラマ「下町ロケット」を見て，ふと思いました．
ソフトウェアに携わるエンジニアが開発した新たな製品を受注先に納める，コンシューマー向けに販売する，
そういった中でエンジニアが誇れる『技術力』とは，どういったものになるのでしょうか？
ここでいう『技術力』は，エンジニアの自己満足レベルでかまいません．


--


「下町ロケット」ではハードウェアの開発でしたので，製品試験でその製品の性能が数値として表れることで，エンジニアが高い技術力を誇りに思うことは可能です．新規特許の取得もそれに当てはまるでしょう．ところがソフトウェアの場合，製品試験では要求を満たしているかどうか，それまでであり，性能を数値に表わし技術力を評価できるようなことはない気がします．
ソフトウェアにおける技術力は，言うならば「バグが発生しないこと」でしょうか？ だとしても，バグなんて「一定期間内に発生しない」ことでしか評価できませんし，良くも悪くも何とでも言えると思います．数値のようにはいきません．


私の認識では，ハードウェアには限界があっても，ソフトウェアには限界はない，何でも実現できる，と思っています．IT事業においても，実現性における事業の妨げとなるのはハードウェアだったり法関連だったりであって，（プロジェクトのコスト面以外で）ソフトウェアの問題で実現不可能になることはないと．そのため，こういった疑問が出てくるのかもしれません．


--


繰り返しになりますが，先述の通り，

> 製品を受注先に納める，コンシューマ向けに販売する

に限定しています．
例えば，「同じCPU資源で，より正確な円周率を算出できるアルゴリズムを発見した」といったようなものは除くこととします．


最後に，かんたんに私のプロフィールを載せておきます．
現在学生で，翌4月からSEへの門を叩きはじめます．
ですので，業界のことは就活等で得た知識がある程度で，**わかっているようで知らないことだらけ**です．
本格的にコードを書き始めてから10年ほどで，開発経験としてはWindowsアプリケーション，Webサイト，組み込みシステム，低レベルAPIを用いた処理，スマートフォンアプリ，といった具合です．スマートフォンアプリに関しては地域活性化をテーマに企画からリリースにメンテナンスまで，今年はコンテストで賞獲得を目標に設定し，SEごっことでも言いますか，来年以降を意識してプロジェクトを立て，チームで開発に取り組んできました．


以上となります．

ぜひ，みなさんのご意見をお聞かせください．
よろしくお願いいたします．


--
あまりうまく質問を記述できていない点，ご容赦願います．
また，いくらでも補足いたしますので，なんなりとお申し付けいただければ幸いです．

ソフトウェアにおける『技術力』って何でしょう？

### 概要

開発システムのデプロイ環境について一般的な運用方法が知りたいです。
２つ質問があります。

### 質問１
本番デプロイ後に本番環境ですべての機能のテストは通常行うものですか？
自身が勤めている会社ではステージングでフル機能のテストを行った後、本番環境にアップして本番環境でもフル機能のテストを行います。
ステージングと本番が全く同じであるとした場合、これは必要な作業なのでしょうか。

### 質問２
（質問１が必要である場合、）本番環境を「稼働用」「待機用」と２つ用意して待機用をステージングとして扱い、交互にアップと公開を切り替えて使用するような運用方法は存在しますか？
　もしも存在するならば、どのような企業で使われているかなど、また存在しないならばどのようなデメリットがあって実現できないかを教えていただけないでしょうか。

　※２．の上記の詳細として、「稼働用」環境はお客さんに公開している環境で、「待機用」環境はアップデートとテストを行います。
　　そして、本番反映日が来ると、お客さんがアクセスするURLは同じで、接続するルーティングだけをプログラム的にもう一方へ切り替えることを想定しています。
　　そして「稼働用」と「待機用」が切り替わります。
　　そうすれば、ステージングテスト後の本番環境でのテストは不要になると考えました。
　　現状、本番環境のフルテストを行っている間に、お客さんを待たせているためにそのように思っています。


### 前提

自身は中小規模のITベンチャーに勤めています。
テスト業務を担当していますが、エンジニアではありません。

よろしくお願いします。


開発システムのデプロイ環境について一般的な運用方法が知りたい。

### 前提・実現したいこと

Reactコンポーネントのテストを Jest + testing-library を使って書いています。
セレクトボックスの値が変更されることをテストコードで書いていて以下のエラーが発生しました。

### 発生している問題・エラーメッセージ

```
TestingLibraryElementError: Unable to find an element with the display value: First
```

### 該当のソースコード

`<Select>`というセレクトボックスのコンポーネントに配列形式で`category`という Props を渡すと、option にカテゴリとして選択項目が追加されます。デフォルトでは '選択してください' という項目が表示されています。

```typescript
const categories = [
  {
    id: 1,
    name: 'First',
  },
  {
    id: 2,
    name: 'Second',
    description: 'Second',
  },
]

const onSubmit = jest.fn()

// テストコード
describe('<Select />', () => {
  test('セレクトボックスの値が変更される', async () => {
    render(
      <CategorySelect
        categories={categories}
        onSubmit={onSubmit}
      />
    )

    const selectCategory = screen.getByDisplayValue('選択してください')
    fireEvent.change(selectCategory, { target: { value: '1' } }) //1番目のoptionを選択

    await waitFor(() => expect(
      screen.getByDisplayValue(categories[0].name) 
    ).toBeInTheDocument()) <- この部分で上記のエラーメッセージが出ます
```

### 試したこと
`getByDisplayValue`と await 句を使うことでテストが失敗します。
1.`getByDisplayValue`を`getByText`に書き換えたところ、テストがパスします。
2.また、`waitFor(() =>`の前の await を記述しないでおくと、`getByDisplayValue`でもテストがパスします。

そこで、2の方法で await を記述せず`waitFor(() =>`のみを書いたテストコードをレビューに提出したところ、`await`句が必須であると指摘されました。
セレクトボックスの中の値は `getByText` ではなく `getByDisplayValue` で取得した方がよいと考えているのですが、上記のテストが通らない原因には何が考えられるのでしょうか？
また、testing-library の`waitFor`を使う際は await 句は必須でしょうか？

testing-libraryに詳しい方、お力を貸していただけると幸いです。

### 補足情報（FW/ツールのバージョンなど）
React v.17
testing-library/react v11.2.2

testing-library : await waitFor(() => でテストが通りません

あるソフトウェアに手を加えたときにどこまでテストをやればいいのか、しっくり来ないので皆さんのご意見が聞きたいです。
単体テスト、結合テストが次のそれぞれの項目について必要かどうかご意見ください。


i)あるメソッドA(外部への参照等を一切せず、inputとoutputのみが外界との接触であるとする)をリファクタリング
ii)上述のメソッドAの機能に変更を加え、outputが変化する場合
iii)あるメソッドB(DBを変更するメソッドを含む。inputとoutputはない)をリファクタリング
iv)上述のメソッドBの機能に変更を加え、DBへの変更値に変化がある場合

また、おすすめのソフトフェアテストの書籍があればご紹介くださいm(__)m

ソフトウェアテスト