Làm thế nào để làm cho các bài kiểm tra tự động phổ biến? [đóng cửa]

Cơ sở mã của chúng tôi đang phát triển trong 20 năm nay. Chúng tôi có khoảng 10 dev + sqa làm việc với 500kloc. Cách đây một thời gian, một nhóm nhỏ của chúng tôi (2 nhà phát triển, một người từ sqa) bắt đầu làm việc trên một chương trình thử nghiệm tự động. Hiện tại một lần chạy mất 11h và bằng cách nào đó là một bài kiểm tra tích hợp. Chúng tôi đang làm việc để giảm bớt điều này và giảm các kết quả dương tính giả và đang đạt được tiến bộ tốt trong đó. Nhưng chi tiết không quan trọng.

Nó đang hoạt động tốt và chúng tôi tiếp tục cải thiện nó. Chúng tôi (nhóm nhỏ) rất thích nó. Nếu chúng tôi phá vỡ một cái gì đó, chúng tôi nhận thấy một ngày sau đó và không 2 tháng sau khi sqa xem xét. Ngoài ra, các nhà quản lý của chúng tôi (dev + sqa) thích ý tưởng này. Nhưng những người khác trong đội chỉ bỏ qua các bài kiểm tra. Trong suy nghĩ của họ, nếu các bài kiểm tra thất bại sau khi đăng ký, thì đó là vấn đề của bài kiểm tra chứ không phải do thay đổi mã và đó chỉ là dự án đồ chơi của chúng tôi. Chúng tôi đã thảo luận nhiều lần nếu một bài kiểm tra thất bại là một lỗi thực sự. Hầu hết các lần nó là.

Chúng tôi không thể và không muốn thực thi một cái gì đó. Làm thế nào chúng ta có thể chỉ ra rằng kiểm tra tự động là một điều?

Khước từ

Mặc dù tôi có vẻ giống như một người quản lý, tôi đã viết điều này với tư cách là một nhà phát triển, người cũng cần được thuyết phục rằng các bài kiểm tra tự động là tốt.

Bạn phải hiểu tâm lý cơ bản của các nhà phát triển. Đó là một nhu cầu ăn sâu của các nhà phát triển để cam kết mã. Bất cứ điều gì ngăn cản họ làm như vậy là một điều rất, rất xấu. Kiểm tra thất bại chắc chắn là một cái gì đó ngăn cản họ làm như vậy, ergo nó là một điều xấu. Do đó kháng chiến.

Những gì bạn phải chỉ ra là, trong khi các bài kiểm tra tự động làm chúng chậm lại trong thời gian ngắn, về lâu dài nó sẽ giúp họ tiết kiệm rất nhiều đau buồn và thực sự sẽ tăng tốc chúng, bởi vì họ sẽ có thể tập trung hơn vào sự phát triển của những điều mới và sẽ mất ít thời gian hơn để làm điều khác mà các nhà phát triển ghét phải làm: sửa lỗi.

Và vâng, bạn phải thực thi nó. Bạn phải nhận được sự hỗ trợ vô điều kiện từ ban quản lý và thực hiện viết bài kiểm tra tự động bắt buộc và không thể thương lượng. Theo thời gian, các nhà phát triển sẽ quen với chúng. Điều gì sẽ giúp là nếu bạn có thể đưa ra một số số liệu sẽ cho thấy mức độ phát triển mới đã được thực hiện nhiều hơn và số lượng lỗi đã giảm bao nhiêu kể từ khi bạn giới thiệu các bài kiểm tra tự động. Từ ngữ không ổn định. Số là rắn. Và con số là thứ mà một nhà phát triển trung bình hiểu rõ hơn từ ngữ. Nếu bạn có thể chứng minh bằng cách sử dụng các số rắn rằng các bài kiểm tra tự động là tốt, bạn sẽ nhận được rất ít để không kháng lại chúng.

Trong suy nghĩ của họ, nếu các bài kiểm tra thất bại sau khi đăng ký, thì đó là vấn đề của bài kiểm tra chứ không phải do thay đổi mã và đó chỉ là dự án đồ chơi của chúng tôi. Chúng tôi đã thảo luận nhiều lần nếu một bài kiểm tra thất bại là một lỗi thực sự. Hầu hết các lần nó là.

Có vấn đề của bạn. Nếu các bài kiểm tra của bạn không ổn định (ngay cả khi chúng đáng tin cậy 'hầu hết thời gian'), thì mọi người sẽ có xu hướng bỏ qua kết quả. Nhóm tự động hóa của bạn nên tập trung vào việc loại bỏ những tiêu cực sai. Chỉ sau đó, phần còn lại của nhóm sẽ có đủ tự tin vào kết quả để thực sự tin tưởng họ.

Chúng tôi không thể và không muốn thực thi một cái gì đó.

Bạn chắc chắn nên thực thi nó! Nếu ai đó đẩy mã mới và các thử nghiệm thất bại, mã sẽ bị từ chối! Đó là cách duy nhất đáng tin cậy để duy trì một dự án phần mềm lớn hơn.