Người kiểm tra có nên tự động hóa công việc của họ?

Chúng tôi đang cố gắng thiết lập quy trình thử nghiệm của chúng tôi. Chúng tôi tự hỏi nếu người kiểm tra của chúng tôi nên phát triển kiểm tra hồi quy tự động, hoặc nếu các nhà phát triển nên làm điều đó.

Và những loại kiểm tra tự động khác? Người thử nghiệm có nên phát triển chúng?

Tôi nói rằng những người thử nghiệm nên phát triển các thử nghiệm tự động - họ có cách tiếp cận "cặp mắt bên ngoài" đối với mã và sẽ (hoặc đó chỉ là "có thể" phát hiện ra các lỗi mà bạn chưa từng nghĩ tới, chứ đừng nói đến việc xử lý .

Cộng với sự hiểu biết của họ về các yêu cầu chức năng có thể cao hơn mức độ hiểu biết của các nhà phát triển - vì vậy, ngồi giữa kiến ​​thức cấp thấp khó tính của lập trình viên, nhưng không cao hơn trình độ BA.

Nếu bạn có thể tự động hóa nó, tự động hóa nó.

Để người kiểm tra tự do tìm những thứ bạn không thể tự động hóa. Và khi họ tìm thấy một lỗi mới, nếu nó có thể được tự động hóa và thêm vào các thử nghiệm tự động, hãy thêm nó.

Theo tôi, các nhà phát triển và người thử nghiệm chịu trách nhiệm cho các loại thử nghiệm khác nhau.

Nhà phát triển, trong khi viết logic, cũng nên viết các bài kiểm tra đơn vị và tích hợp. Điều này sẽ cho phép nhà phát triển đảm bảo rằng những gì họ đã viết cho đến nay vẫn hoạt động như dự định. Ngoài ra, các thử nghiệm này vẫn sẽ xuất hiện để nhà phát triển chạy khi họ thực hiện các thay đổi trong tương lai. Sau khi logic được hoàn thành, nhà phát triển có thể yên tâm rằng những gì được viết sẽ hoạt động khi họ hiểu các thông số kỹ thuật và có thể chuyển cho người kiểm tra.

Người kiểm tra từ thời điểm này phải chịu trách nhiệm viết các bài kiểm tra toàn hệ thống để đảm bảo logic nghiệp vụ hoạt động như dự định.

Vì các nhà phát triển thường quá gắn bó với mã, người kiểm thử có thể giúp dọn sạch các bài kiểm tra của nhà phát triển nhưng không phải ngược lại.

Theo kinh nghiệm của tôi, cách người kiểm thử thiết lập và thực hiện trường hợp kiểm thử tự động thực sự khác với cách mà nhà phát triển thực hiện. Người kiểm thử sẽ suy nghĩ nhiều hơn về cách lấy thông tin ra khỏi trường hợp kiểm thử, cách thực hiện kiểm tra nhanh chóng, làm thế nào để duy trì kiểm tra, v.v. Quan trọng nhất, người thử nghiệm sẽ thấy các sắc thái của phạm vi thử nghiệm mà các nhà phát triển sẽ bỏ lỡ.

Nếu tài nguyên phát triển thử nghiệm thấp, nhà phát triển có thể giúp đỡ - nhưng người kiểm tra nên xem xét công việc của họ một cách cẩn thận. Các nhà phát triển nên làm việc trên đồ đạc và công cụ kiểm tra trước khi viết các trường hợp kiểm thử thực tế và các nhà phát triển không bao giờ nên viết các trường hợp kiểm thử cho mã riêng của họ. Có các nhà phát triển giúp thử nghiệm sẽ có những đặc quyền - nó giúp các nhà phát triển phát triển các phần khác của sản phẩm và thử nghiệm có thể giúp họ trở thành những nhà phát triển tốt hơn. Tuy nhiên, giống như công việc của một nhà phát triển cơ sở sẽ không bao giờ đi mà không có đánh giá mã, công việc QA của nhà phát triển sẽ nhận được đánh giá QA từ một người có nhiều kinh nghiệm kiểm tra.

Đã chỉnh sửa để thêm: Tôi là một SDET với 5 năm kinh nghiệm. Tôi làm việc với các nhà phát triển tuyệt vời với hơn 10 năm kinh nghiệm và gần đây đã làm việc với họ để vượt qua nút thắt thử nghiệm.

Một điều tôi thực sự muốn có thể thấy là các công cụ tự động hóa vững chắc cho những người thử nghiệm sẽ cho phép họ ghi lại hiệu quả tiến trình của họ thông qua một kịch bản thử nghiệm và sau đó cho phép kịch bản đó được chạy tự động trong tương lai. Đặc biệt là nếu điều này cũng tạo điều kiện cho cùng một kịch bản được chạy trên các phiên bản hệ điều hành khác nhau mà không cần người kiểm tra phải thực hiện tất cả chúng bằng tay.

Thật không may, chắc chắn cho sản phẩm mà tôi làm việc, không có công cụ nào trên thị trường hoàn thành công việc. Nhưng nó đáng để ghi nhớ điều này và xem xét những gì có sẵn trên thị trường trong trường hợp có một cái gì đó sẽ làm việc cho những gì bạn đang làm.

Một điểm khác biệt quan trọng thực sự quan trọng ở đây là: những người thử nghiệm của bạn chỉ đang kiểm tra , hay họ đang thử nghiệm ?

Bài đăng trên blog này của Michael Bolton giải thích nó tốt hơn, nhưng về bản chất: họ đang tìm cách đơn thuần xác nhận hành vi, hay họ đang tìm kiếm các vấn đề với hệ thống?

Tôi nghĩ rằng cũng hữu ích khi xem xét các Quadrant thử nghiệm Agile (Brian Marick ban đầu mô tả những điều này, nhưng tôi đã bắt gặp chúng trong cuốn sách "Thử nghiệm Agile" của Lisa Crispin và Janet Gregory: ngay cả khi bạn không theo phương pháp phát triển Agile, tôi nghĩ rằng phân biệt giữa các thử nghiệm phê bình sản phẩm và thử nghiệm hỗ trợ nhóm, thực sự đáng giá khi xem xét tự động hóa và cố gắng phát triển một kế hoạch cho ai làm gì và tại sao.

Chẳng hạn, kiểm tra đơn vị được viết bởi các nhà phát triển hoạt động như các trình phát hiện thay đổi, cho phép bạn bắt đầu hồi quy sớm khi chúng được chạy lại thường xuyên - đây là các kiểm tra hỗ trợ nhóm. Kiểm tra hồi quy cấp hệ thống được tự động hóa để chúng có thể được chạy lại thường xuyên và nhanh chóng hỗ trợ nhóm bằng cách bắt kịp hồi quy sớm và bổ sung cho kiểm tra đơn vị được thực hiện bởi các nhà phát triển. Điều đó giải phóng thời gian của người thử nghiệm của bạn để thực hiện thử nghiệm phê bình sản phẩm - ví dụ thử nghiệm thăm dò. Hoặc có thể áp dụng một số kiểm tra tự động để kiểm tra căng thẳng sản phẩm.

Một điều khác tôi thực sự thích về bài thuyết trình Lisa Crispin mà tôi đã liên kết là nó chỉ ra rằng tự động hóa cũng có thể được sử dụng để hỗ trợ kiểm tra thủ công - tạo dữ liệu kiểm tra, tự động hóa được sử dụng để đưa kịch bản đến điểm bạn muốn tập trung vào hôm nay, cho thí dụ.

Việc xem xét hai bài viết này hy vọng sẽ giúp bạn phân tích loại thử nghiệm nào bạn muốn thực hiện, giúp dễ dàng chọn ra những gì có thể phù hợp với tự động hóa và tìm ra các bit tự động hóa nào phù hợp hơn để thực hiện bởi người kiểm tra và bởi các nhà phát triển.