Làm thế nào để kiểm tra phần mềm được thực hiện tại các công ty khởi nghiệp công nghệ?

10

Tôi đã thấy rất nhiều bài báo nghiên cứu và blog công nghệ tự hào về lợi ích của kiểm thử phần mềm. Tôi đã thuyết phục về điều đó. Nhưng vì tất cả các nghiên cứu kiểm thử phần mềm được thực hiện bởi các công ty phần mềm lớn, tôi không tin rằng họ thực sự áp dụng cho các công ty khởi nghiệp. Vì các công ty khởi nghiệp có những nhu cầu và ràng buộc khác nhau so với các công ty phần mềm lớn.

Vì vậy, điều này đặt ra các câu hỏi. Các công ty khởi nghiệp công nghệ có nên viết bài kiểm tra tự động? Nếu vậy, họ có được thực hiện theo cách tương tự như các công ty phần mềm lớn? (kiểm tra khói, kiểm tra hồi quy, v.v.) Tốt nhất là bạn có thể tham khảo một số bài viết nghiên cứu về chủ đề này..sao tôi không thể tự mình tìm thấy bất kỳ bài viết nào.

(Tôi phải thừa nhận rằng mặc dù tôi vẫn còn sớm trong sự nghiệp, nhưng tôi chưa thấy một startup nào cam kết nghiêm túc viết các bài kiểm tra tự động)

testing startup

— ming_codes
nguồn

5

Tôi đã tham gia vào một start-up nhỏ bé 10-yo và tôi là người đầu tiên thực sự thêm các bài kiểm tra chạy vào ban đêm. Không phải vì tôi là một thiên tài, nhưng đây là lần đầu tiên người quản lý (cũng là lập trình viên) nhận ra rằng đã đến lúc phải thêm họ, và cuối cùng họ đã có nhân lực. Strat-up thường phải tồn tại trước, và hoàn hảo sau. Cấp, khởi nghiệp này đã được bắt đầu bởi những người không phải là kỹ thuật viên, vì vậy tính năng này phải được "đưa vào".

— Công việc

5

Khởi nghiệp 10 tuổi ...?

— pap

Dilbert nói : "Nếu thực hành tốt nhất được mọi người trong ngành áp dụng, thì thực tiễn tốt nhất sẽ trở thành tầm thường." Tôi đoán đó là sự thật, heh.

— ming_codes

Khởi nghiệp 10 tuổi ... họ phải sử dụng Java: thiết kế 3 năm + 7 phát triển :) chỉ nói đùa (Tôi là một nhà phát triển Java btw)

— nuvio

11

Luôn có một mâu thuẫn giữa những gì nên làm và những gì chúng ta thực sự có thời gian. Có rất nhiều công ty khởi nghiệp đã từ bỏ thử nghiệm phát triển và thử nghiệm tự động để rút ngắn thời gian để khởi động dự án.

Các trang web mạng xã hội và các công ty ứng dụng di động là những bong bóng lớn hiện nay và chúng cạnh tranh khốc liệt . Đôi khi sự khác biệt giữa việc sống trong 4 tháng so với 5 tháng có nghĩa là Bạn Mất.

Thời gian để tiếp thị là chìa khóa, và sau đó nếu thành công xảy ra thì đã đến lúc mở rộng quy mô, sau đó sẽ có nhiều thời gian để cấu trúc lại phần mềm chưa được kiểm tra của bạn thành một thứ đáng giá.

— phong_shaft
nguồn

Thời gian để thị trường là một chút huyền thoại mặc dù. Những người tham gia muộn vào một thị trường có thể thổi bay những người chơi hiện có: friendster> myspace> facebook.

— Joeri Sebrechts

@JoeriSebrechts Tôi đã đọc một bài viết thú vị về sự tiến bộ của phần mềm và làm thế nào nó liên quan đến sự thành công của những người tham gia muộn. Có nhiều biến số khi chơi, khoảng thời gian an toàn cho người đăng ký muộn với giải pháp tương tự bằng với thời gian để cơ sở người dùng của phần mềm chuyển đổi từ Người áp dụng sớm thành Người dùng chung. Giải pháp tương tự tất nhiên có nghĩa là các tính năng tương tự và không đột phá so với người đầu tiên tham gia vào thị trường (Ví dụ: Facebook là đột phá so với MySpace). Sau khi đạt được khối lượng quan trọng của Adopters sớm, người dùng phổ thông bắt đầu di chuyển.

— maple_shaft

12

Kiểm thử phần mềm không phải là một tôn giáo. Đó chỉ là một ý tưởng rất tốt.

Bạn nói rằng bạn không có nhân lực để viết bài kiểm tra ngay bây giờ? Được rồi 6 tuần kể từ bây giờ, bạn sẽ có nhân lực để tìm ra lỗi làm hỏng ứng dụng của bạn, nó sẽ được tìm thấy ngay lập tức nếu bạn có các xét nghiệm thích hợp?

Quá nhiều thử nghiệm có thể làm chậm sự phát triển. Quá ít thử nghiệm cũng có thể làm chậm nó. Bạn phải tìm sự cân bằng phù hợp và thường rất khó để biết đó là đâu. Và không ai trong số này là dành riêng cho các công ty lớn hay nhỏ.

— Mike Baranczak
nguồn

4

Trong nhiều năm, khi làm việc trong các công ty nhỏ và khởi nghiệp, tôi đã hiểu sai rằng tôi "không có đủ thời gian để viết bài kiểm tra đơn vị cho mã của mình" .

Khi tôi viết bài kiểm tra, chúng là những thứ nặng nề, nặng nề, điều đó chỉ khuyến khích tôi nghĩ rằng tôi chỉ nên viết bài kiểm tra đơn vị khi tôi biết chúng là cần thiết.

Gần đây tôi đã được khuyến khích sử dụng Phát triển theo hướng thử nghiệm và tôi thấy đó là một tiết lộ hoàn chỉnh .

Bây giờ tôi tin chắc rằng tôi "không có thời gian để không viết bài kiểm tra đơn vị" .

Theo kinh nghiệm của tôi, bằng cách phát triển với thử nghiệm trong tâm trí, bạn kết thúc với các giao diện sạch hơn, các lớp và mô-đun tập trung hơn và nói chung là RẮN hơn , mã có thể kiểm tra.

Mỗi lần tôi làm việc với mã kế thừa không có kiểm tra đơn vị và phải kiểm tra thủ công một cái gì đó, tôi cứ nghĩ "việc này sẽ nhanh hơn rất nhiều nếu mã này đã có kiểm tra đơn vị" . Mỗi lần tôi phải thử và thêm chức năng kiểm tra đơn vị vào mã có độ khớp cao, tôi cứ nghĩ "việc này sẽ dễ dàng hơn nhiều nếu nó được viết theo cách tách rời" .

Nếu có một điều tôi đã phát hiện ra trong nhiều năm qua, nếu bạn đang làm việc khi mới khởi nghiệp, bạn cần phải nhanh nhẹn , và không chỉ theo nghĩa phương pháp phát triển phần mềm . Đối với tôi TDD là một công cụ quan trọng cho phép bắt đầu và duy trì sự nhanh nhẹn .

— Đánh dấu gian hàng
nguồn

1

Đây không phải là về việc ai sẽ thực hiện kiểm thử phần mềm, Kiểm thử phần mềm là một triết lý phát triển phần mềm. Kiểm thử phần mềm đặt nền tảng cho chất lượng phần mềm tốt và trong khi khởi động, chất lượng phần mềm là phần thưởng khi việc mua lại bởi một công ty lớn đang ở một góc;)

— Francisco Valdez
nguồn

1

Thực tiễn tốt nhất là toàn ngành, cho dù bạn đang tạo ra một trang web hay tạo ra hệ thống hướng dẫn cho một vệ tinh. Họ phải luôn được theo dõi bởi những người muốn coi mình là chuyên nghiệp, đó là lý do tại sao họ được gọi là thực hành TỐT NHẤT.

— Ryathal
nguồn

Bạn có thể ngạc nhiên khi biết rằng các thực tiễn tốt nhất không phải là tất cả các ngành công nghiệp. thed Dailywtf.com

— Gary Willoughby

Về mặt lý thuyết, nó giống như một ngành công nghiệp rộng lớn, hoặc một phần của thế giới không tưởng đó, nơi các dự án có các mốc thời gian thực tế và html có ý nghĩa ngữ nghĩa và các nhà quản lý thừa nhận họ thiếu kiến thức kỹ thuật sẽ giúp họ đưa ra quyết định tốt hơn ...

— Ryathal

"Thực tiễn tốt nhất" thường có nghĩa là làm những việc như mọi người khác, tạo ra kết quả trung bình. Công ty trung bình được thành lập hoạt động khá tốt, nhưng công ty khởi nghiệp công nghệ trung bình không đủ mạnh để sụp đổ một cách ngoạn mục.

— David Thornley

1

@DavidThornley - Không, tôi nghĩ rằng "Thực hành tốt nhất" là điều mà hầu hết mọi người tin rằng họ nên làm, cho dù họ có thời gian, năng lượng hoặc quản lý để thực hiện hay không. * 8 ')

— Đánh dấu gian hàng

@Mark booth: Thông thường, khi tôi nghe cụm từ này, nó có nghĩa là những gì tôi đã nói. YMMV, tất nhiên. Tuy nhiên, Ryathal đề cập đến một thế giới nơi các dự án có các mốc thời gian thực tế và điều đó không nhất thiết có thể xảy ra trong kinh doanh. Có một sản phẩm ra mắt muộn hai tháng có thể không quan trọng hoặc gây tử vong (đặc biệt là một công ty khởi nghiệp có thể gặp nguy hiểm vì hết tiền), và thật khó chịu khi thường có một trường hợp kinh doanh mạnh mẽ để có được thứ gì đó chủ yếu hoạt động ngoài cửa càng sớm càng tốt. Tôi cảm thấy khó tin vào "những thực tiễn tốt nhất" có thể làm chết một công ty.

— David Thornley

1

Có phần khởi động đôi khi cắt góc và không thực hiện kiểm tra thích hợp. Đôi khi điều này là phù hợp (đối với các dự án đủ nhỏ hoặc khi thời gian / tiền bạc rất quan trọng)

Điều này không dành riêng cho người khởi nghiệp mặc dù. Một trong những nhà cung cấp CNTT của chúng tôi, nhà thầu CNTT thậm chí còn có môi trường thử nghiệm. Mọi thứ đều được thực hiện trực tiếp và đây là một công ty phần mềm đa quốc gia lớn (đáng sợ!)

— Tom Squires
nguồn

1

Họ nên? Đúng. Họ làm như vậy trong thực tế, không thường xuyên như họ nên.

Lý do điển hình nhất được đưa ra là thiếu tài nguyên bao gồm thời gian của nhà phát triển, chi phí thuê người kiểm tra chuyên dụng hoặc bán thời gian, chi phí thiết lập môi trường thử nghiệm, v.v. Bạn thậm chí có thể tìm thấy những lời bào chữa này trong các thiết lập công ty lớn cũng như các công ty khởi nghiệp nhỏ.

Nhìn theo một cách khác, thử nghiệm là một trong những điều dễ nhất để cắt giảm từ lịch trình phát triển, đặc biệt là thử nghiệm với áp lực thời gian rất chặt chẽ và / hoặc áp lực chi phí để tạo ra kết quả rõ ràng. Cùng với công việc thiết kế chi tiết, nó được nhiều nhà quản lý coi là 'lông tơ' và là nơi đầu tiên họ sẽ nói "cắt giảm để chúng tôi có thể thực hiện lịch trình và ngân sách của mình" theo sau là "Tại sao bạn không mã hóa?".

Ở một số công ty, sẽ có người thực hiện thử nghiệm đẩy. Thông thường, đây sẽ là nhà phát triển được thuê và thông thường họ sẽ là người có kinh nghiệm và có thể là người có cổ phần tài chính thuộc loại nào đó trong công ty. Một công ty bắt đầu với "DNA" này có thể sẽ thực hiện thử nghiệm ngay từ đầu.

— jfrankcarr
nguồn