Làm thế nào tôi có thể bắt đầu thử nghiệm trong một thử nghiệm chống nuôi cấy? [đóng cửa]

Tôi có một lời thú nhận để thực hiện: Kiểm thử tự động chính thức chưa bao giờ là một phần của nền tảng lập trình của tôi. Bây giờ tôi làm việc trong một công ty rất lớn với nhiều nhà phát triển (hầu hết trong số họ là nhà phát triển web thuộc loại này hoặc loại khác) và rõ ràng là hầu hết trong số họ không thử nghiệm *. (* Tôi sẽ không tiếp tục nói chính thức ; vui lòng suy luận ra.)

Nếu tôi chờ đợi để có sự hỗ trợ của tổ chức của tôi để bắt đầu thử nghiệm thì điều đó sẽ không bao giờ xảy ra. Nếu tôi cố gắng "thay đổi mọi thứ từ bên trong" bằng cách đẩy thử nghiệm tại ban quản lý, tôi sẽ hết hơi trước khi thay đổi xảy ra. Tôi cần bắt đầu thử nghiệm ngay bây giờ.

Nhưng với TDD và ilk của nó, tôi sẽ kết thúc với rất nhiều mã thử nghiệm cùng với mã sản xuất. Các hệ thống kiểm soát phiên bản của chúng tôi (tất cả tập trung) không được tổ chức để lưu trữ mã kiểm tra. Tôi sẽ phải tìm một nơi cho tất cả những thứ đó trên máy trạm của tôi.

Có thể bắt đầu một thực hành cá nhân về kiểm thử phần mềm trong một nền văn hóa không có giá trị hoặc cung cấp các công cụ cho nó không? Những kỹ thuật và công cụ nào bạn sử dụng để cho phép bạn kiểm tra khi các công cụ và tổ chức chính thức không có chỗ để kiểm tra, khung và tự động hóa?

Cá nhân tôi đã làm điều này với thành công đáng kể. Các yếu tố chính để thành công:

• Nhận (dự kiến) hỗ trợ quản lý. Những lợi thế của kiểm tra tự động hóa là tài liệu tốt và nên thuyết phục bất kỳ người quản lý nào ít nhất thử nó. Điều đó bao gồm tìm một vị trí trong VCS và máy chủ xây dựng, bởi vì
• Kiểm tra tự động chỉ cung cấp giá trị đầy đủ của chúng nếu chúng được chạy thường xuyên và tự động để bạn sớm biết về các vấn đề và không phải dựa vào những người không quên chạy chúng. Bạn cần một máy chủ xây dựng chạy chúng ít nhất hàng ngày. Đây có thể là một máy trạm cũ. Jenkins mất rất ít công việc để chạy.
• Dẫn bằng ví dụ. Viết bài kiểm tra, nói về lợi ích mà họ cung cấp cho bạn và khi họ tiết lộ các lỗi được giới thiệu bởi các nhà phát triển khác, hãy nói về vấn đề họ được bảo vệ khỏi sự bối rối lớn hơn nhiều.
• Đi cho trái cây treo thấp. Một số phần của ứng dụng sẽ khó kiểm tra, những phần khác thì dễ. Một số sẽ mạnh mẽ, một số khác giòn. Viết bài kiểm tra cho các phần dễ vỡ, nhưng dễ kiểm tra cung cấp giá trị nhất trong thời gian ngắn nhất.
• Xem nếu bạn có thể viết các bài kiểm tra có thể sử dụng lại, ví dụ: các quy ước hoặc tính năng kiểm tra mà tất cả các mô-đun (trang web, dịch vụ REST, bất cứ điều gì) phải có nhưng thường bị lãng quên.

Không có sự hỗ trợ quản lý, bạn sẽ chết trong nước. Quản lý sẽ tuyên bố rằng bạn không làm việc đáng giá, bạn sẽ bị phạt trong các đánh giá của bạn, và cuối cùng bạn sẽ bị sa thải. Có nhiều cách để đưa quản lý thấy rằng thử nghiệm sớm chi phí cho họ ít hơn và tất cả điều đó. Có thể thay đổi văn hóa nhưng bạn đang đặt cổ lên khối chặt.

Tôi sẽ đề nghị đọc Machiavelli Chương Hoàng tử về cách giới thiệu thay đổi trước khi làm bất cứ điều gì.

Theo kinh nghiệm của tôi nếu văn hóa chống thử nghiệm, bạn không thể giới thiệu nó một cách hợp lý. Các bài kiểm tra sẽ bị coi là lãng phí thời gian và bạn sẽ bị khiển trách vì "lãng phí thời gian" hoặc "mất quá nhiều thời gian", hoặc mã đã bị hủy bỏ sau nhiều năm không được viết theo cách có thể kiểm tra được (ví dụ: không có giao diện, mọi thứ kết hợp chặt chẽ) và bạn sẽ phải dành nhiều thời gian để tái cấu trúc và / hoặc viết lại mã (do đó có nguy cơ "mất quá nhiều thời gian" và "lãng phí thời gian") để có thể kiểm tra được ngay từ đầu .

Bạn có thể có cơ hội nếu bạn đang làm những thứ trên greenfield chỉ phải tương tác với những thứ hiện có (tạo một trình bao bọc đẹp xung quanh các khu vực xấu) hoặc nếu bạn có thể làm điều đó với số lượng nhỏ, nơi nó sẽ không gây ra vấn đề hoặc yêu cầu bạn phải "Làm việc trên các nhiệm vụ không được giao cho bạn" có thể đưa bạn vào nhà ổ chuột.

Tôi không nghĩ rằng bạn sẽ đi rất xa cho đến khi bạn có thể đưa ra một trường hợp đủ tốt để có một vấn đề (hiện có thể không được công nhận) mà kiểm tra tự động có thể giải quyết.

Nếu có văn hóa kiểm tra thủ công đối với các tập lệnh được xác định, thì sẽ có chi phí thực hiện các tập lệnh đó cùng với rủi ro về kết quả không đầy đủ hoặc không chính xác. Có thể có một lịch sử (tài liệu hoặc ở dạng "câu chuyện chiến tranh"). Đề xuất một dự án thí điểm để tự động hóa một số thử nghiệm thủ công nhằm cung cấp một khoản tiết kiệm chi phí dài hạn.

Nếu thậm chí không có chức năng kiểm tra thủ công thì tôi đề nghị doanh nghiệp không nhận thấy rằng bất kỳ loại thử nghiệm chính thức nào, tự động hay nói cách khác, đều có giá trị. Trong trường hợp đó, tôi coi con đường phía trước là dài và dốc lên, nhưng một lần nữa có thể cần một minh chứng rõ ràng rằng doanh nghiệp có thể hưởng lợi từ việc áp dụng cách tiếp cận ít bình thường hơn đối với chất lượng phần mềm. Nếu bạn không thể làm điều đó thì thật khó để thấy làm thế nào có thể có bất kỳ sự hỗ trợ nào cho ý tưởng trên cơ sở thương mại.

Một ý tưởng là bạn đặt mục tiêu viết một bài kiểm tra chứng minh rằng mã mà người khác đã viết bị lỗi. Nên bán khái niệm.