バグを修正するには「3ステップ」が必要、なぜか
GitHub Security Labのセキュリティ研究者、ケビン・バックハウス氏は2021年11月9日（米国時間）、ソフトウェアのバグ、特に、セキュリティ脆弱（ぜいじゃく）性を修正する際に踏むべきステップを解説した。 同氏は「回帰テストの追加」「バグの修正」「バリアント（亜種）の発見と修正」という3ステップを挙げた。「バグの修正」は当然、必要不可欠だが、なぜ他の2つのステップが重要なのか、なぜこの順序で実行すべきなのかを解説した。 回帰テストの追加 回帰テストの目的は、同じ誤りを繰り返さないことにある。バグの修正時には同じバグが再発した場合、失敗するように設計した回帰テストを追加する必要がある。なぜだろうか。修正済みのバグのテストを作成するのは、時間の浪費ではないのか。 時間に追われていると、「現実的に、誰かがこれと全く同じバグを再発させる可能性はどれだけあるのだろうか」と考えて、回帰テ
ソフトウェア技術者のためのバグ百科事典（7）要求仕様書がバグってる
1．はじめに このバグ百科事典では、筆者が気になったバグを紹介し、読者の方々に「バグの早期発見」と「バグの未然防止」に役立てていただくものです。本コラムによって、より良いソフトウェア開発のお役に立てればと思います。 ⇒連載「山浦恒央の“くみこみ”な話」バックナンバー 2．要求仕様フェーズ ソフトウェア・ライフサイクルの中で最も重要なフェーズは、もちろん、要求仕様フェーズです。このフェーズでは、顧客が求める「機能」をキチンと聞き取り、要求仕様書にまとめます。例えば、エアコンのソフトウェアの場合、「機能」には、「室内を冷やす」「室内を暖める」「除湿する」「除菌する」などがあります。 要求仕様書をしっかり作成しないと、その後のフェーズでさまざまな問題が発生し、プロジェクトの進行に大きく影響します※1）。今回は、全工程の「最重要フェーズ」である要求仕様書のバグを取り上げます。 2.1 要求仕様が凍
ソフトウェア技術者のためのバグ百科事典（6）不信感を生む“文書作成のバグ”
ソフトウェア技術者のためのバグ百科事典（6）不信感を生む“文書作成のバグ”：山浦恒央の“くみこみ”な話（127）（1/3 ページ） ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第6回は、ソフトウェア開発業務の中で圧倒的に大きな比率を占める「文書作成」における間違い、「文書作成のバグ」を取り上げます。プログラムの動作には影響しませんが、その文書を読んだユーザーに不信感を与えかねない危険なバグなのです。 ⇒連載「山浦恒央の“くみこみ”な話」バックナンバー 1．はじめに バグ百科事典は、筆者が気になったバグを紹介し、読者の皆さまに「バグの早期発見」と「バグの未然防止」に役立てていただくものです。本コラムによって、より良いソフトウェア開発のお役に立てればと思います。 2．文書作成のバグ ソフトウェア開発業務の中で、圧倒的に大きな比率を占める作業が、文書
ソフトウェア技術者のためのバグ百科事典（5）意外に多い「実装抜け」のバグ
⇒連載「山浦恒央の“くみこみ”な話」バックナンバー 1．はじめに 「バグ百科事典」では、筆者が気になったバグを紹介し、読者の「バグの早期発見」 「バグの未然防止」に役立てていただくものです。今回は、学生からヒントを得たバグを紹介します。学生の話ですが、プロの開発現場でもよく起きるバグです。 2．学生とプロのソフト開発の違い 過去のコラムでも何回か説明しましたが、学生とプロの開発方式には違いがあります。最も大きいのは、開発規模、働き方、品質要求の違いでしょう。 学生が作成するプログラムの開発規模は、多くて1000行程度です。また、学生は労働基準法を順守する必要はなく、熱意と体力が続き、空腹を我慢できる限り作業に没頭します。ただし、学生が作るのは、「正常データで正常ケースさえ動けばよいプログラム」なので、異常ケースは考えません。 プロのソフトウェア開発の規模では、数万行は当たり前で、携帯電話機
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
