・品質は良いほうが良い 至極当然ですが、それを言うとどんな製品も品質を求めるあまり、とてつもなく高価になるかもしれません。 広義には性能も品質なのですから、性能の向上を無尽蔵に続けても売れなければ意味がありません。 だから、単純に品質が良いほ…

・基本的には テストの目的は不具合を検出することにあります。そして見つけることはできるでしょう。 さて、何をもって十分とするか、それが問題です。 ・全部見たのか？というが人がいて とても困ったことに、全部見たのかと問う人がいます。ソフトウェア…

・品質が要求を満たすことであるなら 相手さえわかれば、勝つ算段を立てることも可能だと思っています。しかし、不特定多数を相手にする要求は難しいと思います。 いろいろな立場と状況があり、画一的でない勝利条件のなかで戦い抜き、勝利を収めるのは、難…

・正解なんて知りません 対象をテストするとして、どうテストすればいいかなんて、わかるはずもありません。正しい方向性は存在しますが、揺るぐことのない正解なんてあろうはずもありません。まあ、筆者が勉強不足でそれを知らないということかも知れないで…

・テスト期間の設定 スケジュール上のテスト期間は、テスト以外のことに食われる時間を持っていますので、期間内いっぱいのテスト予定を組んでしまうと、時間が足りなくなります。 もちろん、前工程から時間が押してくることもあります。 ・プランBは当然 時…

・人じゃないよね 人がだめだという偉い人は、ずっと同じことを言い続けている気がします。 それは原因が特定できているのに直せないですと言っているのと同じだと思っていないということです。 ・仕様書は必要だけど 仕様書がちゃんとしていないのはちゃん…

・次の話ではなく ふりかえりがうまくいかないのは、自分のために他人を変えさせようとする人がいるからです。そうではなく、自分が変わることで、組織に貢献することが肝要だと個人的には思っています。 ・今変えること そして、次の機会にするのではなく、…

・人は万能ではない できて当然という思いは、あっても悪いということはありません。 ただ、よく知っている人に対して持つそれと違って、よく知らない人にそれを持ってはいけないと考えています。 ・外部委託したから 請け負ったのは専門家だから、とかの安…

・管理されている状態 管理されている状態であるならば、管理者が現状を把握していないということはあり得ません。 完全な把握はともかく、状況判断に足るだけの材料がなければいけません。 ・開発にはいろいろなことが起きる 千差万別ではありますが、ソフ…

・成功より大事なこと 営利団体に所属していながら、開発が終わることより大事なことがあると言えばまずいのかもしれません。 わけのわからない成功より、ロジカルに行動した結果失敗に至った方が、組織的には成長できると考えています。 ・ロジカルな失敗 …

・営利団体である以上 売らなければ儲けはないのは必定で、いつまでも売りに出せないのでは会社が干上がるのは自明の理なのはわかります。だからと言ってどんな品質でも出せばいいというものではありません。 ・どこまでか 品質を追求する側としては、テスト…

・勝ちも負けも必然 納期に間に合うかどうかの勝負、いつも負けるから、期日を少し前に設定するとかいうやり方で満足する品質のソフトウェア開発は不可能です。 物理的なモノづくりなのですから、論理的に追い詰めて、必然の積み上げの結果でものが出来上が…

・個人的に嫌いなのですが 良い思い出がないというのが理由ですが、自動テストが悪いと思っている訳ではありません。検証チームと既存の自動テストツールの相性があまりよくないと思っているからです。 ・一番効果があると思うのは 単体テストでの関数内であ…

・プロダクト品質 出来上がったものの品質が良ければいいだけなら、トレーサビリティという言葉がここまで頻繁に聞かれることはないと思います。 ものさえよければ、どんなプロセスで作られていようと気にならないという客ならそれでもいいでしょう。 しかし…

・全部は使わないけど 一番多く使うのは、「バグは偏在する」でしょうか。「全数テストは不可能」は言い訳がましく聞こえるから、やはり偏在の原則は普通に使いますよね。 これとセットで覚えておくと良いのは、５％の領域に８０％の不具合があったとかいう…

・テストでNGのあと テストでNGが出た後の処理は、直したものをチェックすれば良いというものではありません。 品質を保証するという観点から、デグレードがないことを含めて保証しなければなりませんので、そこだけ見るというわけには行きません。 ・全部見…

・できないをできるにする 個人的にできないことができるようになるということではなく、製品や商品が新しいことをできるような機能を搭載する。それ自体はよくあるのですが、それを作るというときに実験や要素技術の確立といった作業では、試行錯誤が当たり…

#ソフトウェア品質 #ソフトウェア開発 ・仕様書もろくにない 仕様書が本当にろくにないのだとしたら、検証はどうなるのでしょうか。明らかに第三者検証は想定されていないということになります。 こうなると何に対して正しいのか正しくないのかが不明確にな…

・優柔不断ではないかも 決断に迷うことはあります。うろたえて思考が回っていない事もしばしば起こります。 困るのは、今が『悪い』と認識しているからで、それだけでも認識できていない人よりは優れています。問題は良い方向に導く決断ができないことは、…

・機能性としてはOKだけど 機能として目的を達成できていることは、ある意味では問題ないといえるのですが、品質というものはそれだけではありません。 もちろんき要求を満足できてこそではあるのですが、要求というのは難しいものなのです。 ・使いやすい …

・正論は危険が伴うことも 正論には危険さが伴うというのが最近覚えたことで、やらないよりやったほうがいいでは、完璧以外すべてダメと言っているのと同じになってしまう怖さがあります。 正論ではなく、論理的に到着点を導き出す必要があります。 ・全部な…

・プロダクトの品質が悪いと これが悪いのは致命的で、目立つし、すぐに影響範囲が広がってしまいます。 当然、問題として挙げられ、なぜこうなったのかという話になってしまいます。 しかし、偶然品質が悪くなるというのは、かなり稀なケースではないかと思…

・品質を守りたくても 商業的に納期を無視する話は成立しないのはわかります。とはいえ、何の論理性もないテストを時間内に頑張っても、品質の管理をする意味では厳しくなります。 十分な能力と十分な時間に問題のないプロセスが機能しているなら別ですが、…

・時間が足りないというけど 開発はというより仕事は常に時間との闘いがあります。期日のない仕事はないからです。 そして、いつも現場でささやかれるのは「時間が足りない」です。 この、時間が足りないについて、いくつかの質の問題があると最近思っていま…

・レビューに参加したら ソフトウェアテストの設計や仕様書の確認のレビューで何を言うべきか、誤字脱字とかのレベルではなく、気の利いたことを言わねばなりません。 なんでもOKのザルみたいなチェックなら必要ないので頑張る必要があります。 ・着目するの…

・正しいプロセスで 1回しか作らないのに、プロセスを問われるのはどうなのかという考え方をしてはいけないようです。 品質は良かったとしても、偶然にできたものには、品質が保証できるだけの信頼を与えられないとかんがえるべきのようですね。 ゆえに、だ…

・分かるの問題とは 故・システムクリエイツの清水さんが、硬派のホームページの中で掲載していたあるページに書かれていた内容で、とても大きな薫陶を受けたものでした。「わかりましたか？」「わかりました。」 このやり取りにはとてつもなく大きな落とし…

・終わってからということ 痛みというのは、痛い最中と過去の記憶になってからでは、それに対する反応は同じにはならない。問題がどれだけ起きても、それは過去のことになってしまっている。さらに質が悪いのは、改善などしなくても開発ができてしまった事例…

・ソフトウェア固有の問題 小説家がいて、書いた行数が多いから順調に進んでいると解釈するのはやや危険といえます。 ソフトウェアも進捗を管理するには様々な困難を伴うものだと思っています。 ・人は主観の中で生きている 説明して「わかりましたか？」と…

・全部見たのかと問う人 安易にこれを聞ける人をうらやましいと思ってしまうのですが、#ソフトウェアテスト における全部はそんなに簡単なものではありません。言うのは簡単ですけどね。 管理を考えれば、全部が明確でなければならず、思いつく範囲程度の話…