ソフトウェアテストの利点を誇る多くの研究記事や技術ブログを目にしました。私はそれを確信しました。しかし、ソフトウェアテストの研究はすべて大規模なソフトウェア会社によって行われているため、スタートアップに実際に適用されるとは思いません。新興企業には、大規模なソフトウェア会社と比較して、異なるニーズと制約があるためです。
したがって、これは問題を提起しました。テック系スタートアップは自動テストを書くべきか?もしそうなら、それらは大手ソフトウェア会社と同じ方法で行われますか? (スモークテスト、回帰テストなど)このトピックに関するいくつかの研究記事を参照していただければ幸いです。自分で見つけることができなかったためです。
(私はまだキャリアの早い段階ですが、自動テストの作成に真剣に取り組んでいるスタートアップを見たことはありません)
何をすべきかと私たちが現実的に時間を持っているものとの間には常に矛盾があります。はい、多くの新興企業は、プロジェクトを立ち上げて実行するために、時間を節約するために、テスト駆動開発と自動テストを忘れています。
ソーシャルネットワーキングサイトとモバイルアプリ会社は現在大きなバブルであり、それらは激しい競争力があります。場合によっては、4か月と5か月でライブに移行することの違いは、あなたが失うことを意味します。
市場投入までの時間は重要であり、成功した場合はスケーリングする時間です。テストされていないがらくたのテストされていないソフトウェアを価値のあるものにリファクタリングする時間は十分にあります。
ソフトウェアのテストは宗教ではありません。とても良い考えです。
あなたは今テストを書く人力がないと言いますか?いいよ。今から6週間後、適切なテストを実施していればすぐに発見されるはずだった、アプリケーションをクラッシュさせるバグを見つけるためのマンパワーを手に入れますか?
テストが多すぎると、開発が遅くなる可能性があります。 少なすぎるテストでも速度が低下する可能性があります。適切なバランスを見つける必要がありますが、それがどこにあるのかを判断することは通常困難です。そして、これは大企業や中小企業に固有のものではありません。
何年もの間、小さな会社や新興企業で働いていたとき、私は誤解の下にいた"コードの単体テストを書くのに十分な時間がなかった"。
私がテストを書いたとき、それらは肥大化した重いものであり、ユニットテストを書くべきだと思うようになっただけですknew必要なときだけです。
最近、 テスト駆動開発 を使用するように勧められ、それが完全な啓示。
私は今と確信しています"時間がないのでnotwrite unit-tests "。
私の経験では、テストを念頭に置いて開発することで、よりクリーンなインターフェース、より集中したクラスとモジュール、そして一般的にはより多くの [〜#〜] 、テスト可能なコード。
単体テストのないレガシーコードで作業し、手動で何かをテストする必要があるたびに、私は考え続けます"このコードに既に単体テストがあった場合、これは非常に速くなります"。結合度の高いコードに単体テスト機能を追加する必要があるたびに、私は考え続けます"これは、分離された方法で記述されていれば、はるかに簡単です"。
私が長年にわたって発見したことが1つある場合、スタートアップで作業している場合は、 softwareだけでなくagileである必要があります。開発方法論 感覚。私にとって、TDDはagileの開始と維持を可能にする重要なツールです。
ソフトウェアテストを誰が行うべきかということではありません。ソフトウェアテストは、ソフトウェア開発の哲学のようなものです。ソフトウェアテストは優れたソフトウェア品質の基礎を設定し、スタートアップでは、大企業による買収が間近に迫っている場合、ソフトウェア品質はボーナスになります。
おばあちゃんをウェブサイトにする場合でも、衛星のガイダンスシステムを作成する場合でも、ベストプラクティスは業界全体です。彼らは常に彼ら自身を専門家であると考えたい人たちによって続かれるべきです、それが彼らがベストプラクティスと呼ばれる理由です。
はい、スタートアップは時々手を抜いて、適切なテストを意味しません。時々これは適切です(十分に小さいプロジェクトの場合、または時間/お金が重要な場合)
ただし、これは新興企業に限定されるものではありません。サプライヤの1つであるIT請負業者には、テスト環境さえあります。すべてが生きるために直接行われ、これは大規模な多国籍ソフトウェア会社です(怖い!)
彼らはすべきですか?はい。実際にはそうする必要はありません。
与えられる最も一般的な理由は、開発者の時間、専用またはパートタイムのテスターを雇うコスト、テスト環境をセットアップするコストなどを含むリソースの不足です。小規模な新興企業だけでなく、大企業の環境でもこれらの言い訳を見つけることができます。
別の見方をすると、テストは開発スケジュールから切り取るのが最も簡単なことの1つであり、特に目に見える結果を生み出すために非常に厳しい時間のプレッシャーやコストのプレッシャーがある場合は特にそうです。詳細な設計作業に加えて、多くのマネージャーによって「ふわふわ」と見なされており、最初に「スケジュールと予算を作成できるように削減する」と言い、次に「コーディングしないのはなぜですか」と言います。
一部の企業では、プッシュテストを行う人がいます。通常、これは採用される開発者であり、通常は経験のある人であり、おそらく会社で何らかの金銭的利害関係を持つ人です。この「DNA」で始まる企業は、おそらく最初からテストを行うでしょう。