Tại sao hướng dẫn Scrum nói không có người kiểm tra?

Tôi đã đọc Hướng dẫn Scrum từ scrum.org và nó nói:

Nhóm phát triển không chứa các nhóm phụ dành riêng cho các miền cụ thể như thử nghiệm hoặc phân tích kinh doanh.

Trong bản dịch nghĩa đen của nó, điều này có nghĩa là không có người kiểm tra nào gây nhầm lẫn. Làm thế nào họ có thể đề nghị này?

Nó có nghĩa là:

1. Người kiểm thử được tích hợp vào nhóm phát triển - công cụ xây dựng để giúp nhà phát triển kiểm tra cũng như kiểm tra.

   hoặc là:

2. Nhóm thực hành Kiểm tra hướng phát triển - tức là họ viết các bài kiểm tra tự động thực hiện hệ thống.

Một trong hai điều này có nghĩa là không cần một nhóm thử nghiệm riêng biệt.

Trong bản dịch nghĩa đen của nó, điều này có nghĩa là không có người kiểm tra nào gây nhầm lẫn ... Làm thế nào họ có thể đề xuất điều này?

Vâng, đây chính xác là những gì họ đề xuất. Nói cách khác - nhà phát triển là người thử nghiệm và người thử nghiệm là nhà phát triển.

Ý tưởng là để thúc đẩy quyền sở hữu và chất lượng mã .

Điều này không có nghĩa là mã không được kiểm tra, mà những người liên quan đến việc viết nó là những người liên quan đến việc kiểm tra nó - không có sự phân tách trách nhiệm.

Vấn đề mà phương pháp này đang cố gắng giải quyết là sự tách biệt quá phổ biến giữa nhà phát triển và người thử nghiệm, nơi các nhà phát triển sẽ viết mã và "ném nó qua tường" cho nhóm khác và sau đó quay lại, trì hoãn dự án và sản xuất phần mềm dưới chuẩn.

Phần cơ bản của vấn đề này là trách nhiệm của người viết mã là tạo ra mã hoạt động và đáp ứng yêu cầu. Điều này đòi hỏi một tư duy đặc biệt - "Mã mà tôi đang viết thực hiện những gì nó phải làm."

Để trộn lẫn các trách nhiệm của người viết mã có nghĩa là bây giờ người lập trình bắt buộc phải nhập các tư duy khác cho các hoạt động khác, tuy nhiên, với tư cách là một lập trình viên, thật khó để người ta có thể tự ly dị hoàn toàn với suy nghĩ đó.

Trách nhiệm của người kiểm tra là tìm ra các lỗi và những nơi mà chức năng chuyển hướng khỏi chức năng được yêu cầu. Điều này đòi hỏi tư duy "Mã bị hỏng và tôi sẽ tìm ra cách."

Tương tự như vậy, một nhà phân tích kinh doanh đang cố gắng xác định các yêu cầu mà khách hàng thực sự yêu cầu. Điều này đòi hỏi một tư duy khác về "ứng dụng không hoạt động theo cách này, nhưng nó nên."

Để một lập trình viên làm việc trong bất kỳ khả năng nào khác, có khả năng hợp lý rằng các tư duy sẽ xung đột và lập trình viên sẽ thực hiện mệnh giá phụ:

• Coder / QA - "Mã hoạt động hoàn hảo và tôi đã được mã hóa để xử lý mọi cách có thể mà tôi có thể nghĩ về điều đó có thể phá vỡ nó."
• Coder / BA - "Mã phải hoạt động theo cách mà tôi muốn và đây sẽ là những thứ gọn gàng để thêm vào nó mà khách hàng không nghĩ tới.

Điều này không có nghĩa là mọi coder đều dễ gặp phải những vấn đề này (tôi đã gặp một số loại coder / QA rất có năng khiếu ... mặc dù không phải vì mã mà họ đã viết).

Điều này mở rộng cho nhóm phát triển là tốt. Trộn lẫn các trách nhiệm và tư duy liên quan của các trách nhiệm đó đối với nhóm phát triển làm ảnh hưởng đến sản phẩm cuối cùng (mã).

Nó nói rằng không có sub -team dành riêng cho thử nghiệm. Điều đó không có nghĩa là không có bài kiểm tra nào được thực hiện. Điều đó chỉ có nghĩa là các thành viên trong nhóm sẽ tự kiểm tra và thường kiểm tra mã / tính năng của người khác. Tôi không quen thuộc với phương pháp scrum, nhưng tôi sẽ đi chi và nói rằng khách hàng cũng có thể tham gia vào thử nghiệm.

Tôi nghĩ rằng điều này một phần có nghĩa là bạn dự kiến ​​sẽ viết các bài kiểm tra cho mã của riêng bạn để bạn biết nó hoạt động (nếu không, bạn đã thực sự hoàn thành nó) và một phần rằng đôi khi bạn có thể được kỳ vọng là người kiểm tra mã của người khác .

Thay vì cho phép mọi người giảm tải công việc chất lượng phần mềm cho người khác và bỏ qua nó, điều này buộc mọi người phải nghĩ về mã họ đang viết từ quan điểm chất lượng mọi lúc, vì vậy đó là một ý tưởng tốt.

Tuyên bố này về cơ bản là cố gắng để tránh làm việc im lặng. Một phần của giải pháp cho vấn đề này là các thực tiễn như - Phát triển dựa trên thử nghiệm - Lập trình cặp - Yêu cầu kéo - Tự động hóa thử nghiệm và những thứ tương tự làm cho thử nghiệm trở thành một phần nội tại của quá trình phát triển thay vì một thứ được thực hiện tách biệt ở bên cạnh hoặc 'sau'.

Ngoài ra, có rất ít thảo luận về vai trò trong Hướng dẫn Scrum. Trong thực tế, họ nói về Nhóm phát triển. Điều họ muốn nói là bạn muốn có một đội ngũ đa chức năng mạnh mẽ. Điều này có nghĩa là phụ thuộc vào những gì dự án của bạn cần, bạn cần một loạt các kỹ năng, chẳng hạn như UX, BA, QA / Tester, Ops, Coder, v.v.

Các đội tôi làm việc cùng chắc chắn có vai trò QA, vì chúng tôi có người DevOps. Nhưng tất cả họ cũng là Dev, chỉ với chuyên môn trong các lĩnh vực này. Bí quyết thực sự là không rơi vào silo và làm việc trong sự cô lập.

Nó không nhất thiết có nghĩa là không có người kiểm tra. Nó có thể là trường hợp một nhóm Scrum có người kiểm tra chuyên dụng hoặc có thể không.

Đối với tôi, điều mà tuyên bố này về Scrum có nghĩa là bạn nên suy nghĩ về toàn bộ đường ống phân phối như một nhóm duy nhất. Là thành viên của cùng một nhóm gợi ý một số điều:

1. Có một ước tính duy nhất về một câu chuyện / lỗi / nhiệm vụ. Không có ước tính dev và ước tính thử nghiệm.
2. Nhóm không ước tính một câu chuyện và cam kết với nó mà không có người kiểm tra có mặt.
3. Nếu có lỗi xảy ra, đó không phải là lỗi của người kiểm tra hơn lỗi của người phát triển. Đó là lỗi của đội .
4. Nhóm không bao giờ cần phải mượn, yêu cầu hoặc yêu cầu người kiểm tra.
5. Kiểm tra là một phần của định nghĩa thực hiện. Công việc chưa được kiểm tra là công việc không hoàn thành.
6. Các nhà phát triển nên xem xét khả năng kiểm tra khi họ thiết kế mã của họ.

Nếu họ làm việc cùng một nhóm, thì nhóm đó thành công cùng nhau và thất bại cùng nhau. Tôi đã ở trong một nhóm Scrum rất thành công với nhiều người thử nghiệm. Người kiểm tra đã có mặt trong tất cả các lần đứng lên, phiên chải chuốt, lập kế hoạch, v.v ... Nếu không rõ cách kiểm tra một câu chuyện, nhóm sẽ không cam kết với nó. Chúng tôi luôn nói chuyện với những người thử nghiệm của chúng tôi khi ước tính.

Dấu hiệu tiềm năng bạn có thể không thực sự coi người kiểm tra là một phần của nhóm giao hàng, ngay cả khi bạn nghĩ rằng mình làm:

1. Những người thử nghiệm có một "QA standup" (yup, tôi đã thấy nó).
2. Người kiểm tra có một cấu trúc quản lý riêng.
3. Bạn có một lãnh đạo QA.
4. Bạn phụ thuộc rất nhiều vào các bài kiểm tra đầu cuối.
5. Các bài kiểm tra được viết nước rút sau đây.
6. Hầu hết các thử nghiệm xảy ra vào ngày cuối cùng của nước rút.

Đây là những chủ quan và không nhất thiết là sai. Họ là những lá cờ đỏ, theo ý kiến ​​của tôi.

Tất cả điều này đã nói, hoàn toàn có thể có một nhóm Scrum mà không có ai có vai trò thử nghiệm được chỉ định. Điều đó cũng có thể làm việc tốt. Đặc biệt nếu bạn tự động kiểm tra. TDD cũng giúp.