Nếu mô hình mới là "Bạn xây dựng nó, bạn điều hành nó" (Werner Voegels, Amazon CTO) rõ ràng đặt nhiều trách nhiệm hơn - và áp lực - lên các kỹ sư phần mềm, thì sự thay đổi này sẽ giới thiệu gì cho nhiệm vụ của nhóm thử nghiệm?
Nếu mô hình mới là "Bạn xây dựng nó, bạn điều hành nó" (Werner Voegels, Amazon CTO) rõ ràng đặt nhiều trách nhiệm hơn - và áp lực - lên các kỹ sư phần mềm, thì sự thay đổi này sẽ giới thiệu gì cho nhiệm vụ của nhóm thử nghiệm?
Câu trả lời:
IMHO phụ thuộc vào vai trò của người thử nghiệm trước khi chuyển đổi như vậy. BTW, tôi tin rằng câu trả lời của tôi áp dụng cho việc chuyển đổi DevOps nói chung, không chỉ cho You build it, you run itmô hình.
Nếu vai trò là một công việc không người lái - thực hiện các thử nghiệm không suy nghĩ - chắc chắn sẽ biến mất, tự động hóa sẽ ăn những công việc đó.
Nếu vai trò bao gồm viết các kế hoạch kiểm tra và thông số kỹ thuật, họ có thể tiếp tục thực hiện điều đó hoặc thậm chí biến thành các kịch bản tự động hóa tương ứng, song song với các nhà phát triển. Hoặc độc lập - trong một số môi trường, bắt buộc phải sử dụng một phương pháp / cơ sở hạ tầng / nhân sự hoàn toàn riêng biệt để thử nghiệm so với (các) được sử dụng để phát triển. Trong nhiều tổ chức, người kiểm thử là các kỹ sư phần mềm, giống như các nhà phát triển.
Nếu vai trò đang thực hiện các thử nghiệm không đáng tin cậy / bất ngờ, đặc biệt đòi hỏi các đặc điểm của con người (cảm xúc, chủ quan, cảm hứng, phản xạ, trực giác, v.v.) để bổ sung cho thử nghiệm tự động - điều đó cũng sẽ không thay đổi.
"Bạn xây dựng nó, bạn chạy nó"
Câu nói này nhằm mục đích đưa ra sự nhấn mạnh về sự phá vỡ giữa các đội silo, một nguyên tắc của các tín đồ là để tránh silo đạt được một nhiệm vụ.
Trong khi ý tưởng ở đây tập trung vào các giai đoạn xây dựng và chạy, ý tưởng quan trọng là kết hợp cả một nhóm, từ kiến trúc đến vai trò khai thác . Một "Nhóm Devops" sẽ được tạo thành từ tất cả các vai trò tham gia vào vòng đời phần mềm, bao gồm cả vai trò người kiểm thử, không có ai trong nhóm xử lý một vai trò duy nhất.
Thay đổi chính đối với người thử nghiệm là học cách nói lên ý kiến và phản hồi của mình về giai đoạn kế hoạch trong một nhóm nhanh nhẹn và có thể tham gia vào một số nhiệm vụ vận hành.
Nhưng trên tất cả, không có quy tắc chính xác, những gì trước đây ai đó trong một silo sẽ làm trong "Nhóm Devops" phụ thuộc vào những gì anh ấy / cô ấy quan tâm và thoải mái hơn để làm. Đó là một trong những thách thức của một nhóm mới được tạo ra, phát hiện ra những khả năng tốt nhất của mọi người để chia sẻ tải theo cách hiệu quả nhất.
Tôi là một kỹ sư cao cấp, trong khả năng đó, tôi làm thuê.
Tại thời điểm tiến triển của các tín đồ, tôi cảm thấy khó khăn khi thuê một Người kiểm tra không thể dễ dàng chuyển sang vai trò Kỹ sư cơ sở hạ tầng (những gì người khác có thể gọi là vai trò của Devops)
Ví dụ, tôi không mong đợi một người thử nghiệm biết được sự phức tạp của đa luồng JVM hoặc rất quan tâm trong thiết kế lớp python. Tôi hy vọng họ có thể hiểu được nguồn mà họ có thể viết mã còn sơ khai hoặc tạo dữ liệu tổng hợp.
Tôi mong đợi một người thử nghiệm hiện đại sẽ biết kho vũ khí cơ bản của các tín đồ trong đội của tôi. Điều đó sẽ bao gồm: việc cung cấp các máy chủ kim loại trần bằng các công cụ CM của chúng tôi, việc triển khai mã thông qua các tạo phẩm hoặc thùng chứa khác nhau.
Tôi sẽ yêu cầu họ phải có một số năng lực như một Kỹ sư dữ liệu theo nghĩa là biết cách dữ liệu di chuyển qua một hệ thống. Suy nghĩ về điểm duy nhất của thất bại là gì và làm thế nào để mô phỏng các thất bại, điều tiết, v.v.
Tôi sẽ không bao giờ thuê một người thử nghiệm để thực hiện kiểm tra mức mô-đun, mà tôi sẽ định nghĩa là sự tương tác của một số ít các lớp (giả sử 1-20) đằng sau một rào cản mạng.
tl; dr Tôi sẽ thuê người kiểm tra để thiết lập môi trường, mô phỏng (hoặc phát lại) dữ liệu qua môi trường đó và gây ra sự hỗn loạn trong môi trường.