エラーを起こす 何事においてもエラーを起こすのが重要。 トライアンドエラー。 エラーすら起こせなければ、自分が間違った方向に進んでいることに気づけない。 試行錯誤を続けていこう。 死ぬまでの時間は、まだたっぷりあるから大丈夫。 でも、その時間を死んだように生きるかどうかを決めるのは、これからの思考と行動次第。 どうせ1回しかないなら、鮮やかに舞い散ろう。 死んだように生きるのか？ それとも、一度死んだと開き直って、不死鳥のように生きるのか？ ソフトウェアテスト
実務で学んだ単体テスト仕様書作成のコツ 現在、単体テストの仕様書作成を進めている。 正直、納期を少し過ぎてしまった。 これまでにないようなボリュームのテーマだったからという言い訳はできる。 しかし、他のメンバーはボリュームが多い中でも納期内に仕上げているのを確認している。 メンバーというかリーダーの人だ。 だから、完全に自分の実力不足である。 本日、チームメンバーに単体テスト仕様書作成のコツを聞いた。 その内容を記事にしていきたい。 関数は最小限の機能をテストする 関数の単体テストは、メイン処理と分けて行う。 当たり前のことかもしれないがそれが意識できていなかった。 ボリュームが多いと頭の中がとっ散らかってしまう。 関数は、引数（入力）があって出力（返り値）があるというのが基本。 途中の処理… ソフトウェアテスト プログラミング学習
測定情報部の適用範囲を誤ったプログラムの問題と解決策 プログラムを設計・実装する中で、データ処理のロジックにおいて意図しない動作が発生する場合がある。今回直面した問題は、複数ファイルを扱う際に、それぞれのファイルごとの測定情報部を適切にデータ部へ付与する処理が正しく動作せず、誤ったデータが生成されるというものであった。テスト仕様書を自分で作成していて気がついた。 この記事では、問題の背景、原因、そして解決策について詳述する。同じような問題に直面している方にとって参考となれば幸いである。 問題の背景 本プログラムでは、以下のような処理を行う必要があった： 複数のファイルを読み込む。 各ファイルには「測定情報部」と「測定データ部」が含まれる。 測定情報部はファイルの先頭に固定行数で格納されている（例：最初の8… ソフトウェアテスト トラブルシューティング
テストケースを考える – 単体テスト仕様書作成の挑戦と気づき 今回は、Pythonで開発したETLプロセスの単体テスト仕様書を作成する中で感じた課題や、新たに学んだテスト手法について記録する。テストケース作成の進め方や、それを支える生活習慣や心構えについても触れる。自分の成長と今後のキャリアを見据えた目標に向け、試行錯誤を続ける日々だ。 テストケース作成の難しさ 現在、PythonのETL処理の単体テスト仕様書を作成しているが、テストケースを設計するのが難しいと感じている。例えば、ファイルの読み込み件数が0件、1件、2件以上の場合や、出力先テーブルにデータが既にあるかどうかなど、条件が多岐にわたると、それだけで組み合わせが増えてしまう。これらの条件だけでも、すでに6通りのケースが必要になる。 しかし、テストケース… ソフトウェアテスト 行動
