Ai nên viết kế hoạch kiểm tra?

Tôi thuộc nhóm phát triển nội bộ của công ty tôi và chúng tôi phát triển các trang web của công ty chúng tôi theo yêu cầu của nhóm tiếp thị. Trước khi phát hành trang web cho họ để thử nghiệm chấp nhận, chúng tôi đã được yêu cầu cung cấp cho họ một kế hoạch kiểm tra để tuân theo.

Tuy nhiên, nhóm phát triển cảm thấy rằng vì các yêu cầu đến từ những người yêu cầu, họ sẽ có kiến ​​thức tốt nhất về những gì cần kiểm tra, những gì cần chú ý, mọi thứ nên ứng xử như thế nào và do đó không cần phải có kế hoạch kiểm tra. Chúng tôi luôn tranh cãi về vấn đề này và các nhà phát triển thấy lãng phí thời gian để viết ra những điều như: -

1. Click vào nút Một .
2. Quan trọng trong việc XYZ vào trường biểu mẫu và nhấp chuột vào nút B .
3. Bạn sẽ thấy hành vi C .

mà chúng ta phải lặp lại cho mỗi yêu cầu / tính năng được yêu cầu. Điều này về cơ bản là ghi lại những gì đã có trong tài liệu yêu cầu.

Chúng tôi đang hướng tới việc sử dụng một cách tiếp cận Agile để quản lý các dự án của chúng tôi và điều này cũng được yêu cầu vào cuối mỗi lần lặp.

Kiểm tra đơn vị và tích hợp sang một bên, ai sẽ là người đưa ra kế hoạch kiểm tra chấp nhận người dùng cuối? Nó nên là reqestors hay nhà phát triển?

Rất cám ơn trước.

Trân trọng
CK

Kế hoạch kiểm tra KHÔNG nên được viết bởi các nhà phát triển. Một phần của kế hoạch kiểm tra cần làm là kiểm tra xem liệu nhà phát triển có giải thích chính xác yêu cầu hay không. Một nhà phát triển không thể viết một kế hoạch kiểm tra mã mà anh ta sẽ viết một cách hiệu quả. Kế hoạch kiểm tra nên được viết bởi những người sẽ làm QA hoặc bởi các nhà phân tích kinh doanh. Nếu các nhà phát triển phải viết các kế hoạch, đừng bao giờ chỉ định ai đó viết kế hoạch cho phần chương trình mà anh ta sẽ viết.

Lưu ý rằng điều này khác với thiết kế các bài kiểm tra đơn vị phải được viết bởi nhà phát triển vì anh ta nên kiểm tra mã mà anh ta đã viết để xem liệu nó có làm được điều anh ta mong đợi không. Nhưng các kế hoạch kiểm tra là để kiểm tra xem ứng dụng có hoạt động theo cách nó được mong đợi hoạt động hay không và điều này phải được thực hiện bởi một người không biết ứng dụng được thiết kế kỹ thuật để hoạt động như thế nào để có hiệu quả.

Nhóm QA nên viết và thực hiện kế hoạch kiểm tra.

Lý tưởng nhất là kế hoạch kiểm tra nên được viết song song với đặc tả chức năng - thật đáng kinh ngạc khi nghĩ về cách kiểm tra chức năng tập trung tâm trí và cải thiện đặc điểm kỹ thuật.

Câu trả lời Scrum: Nếu bạn muốn xác định 'Định nghĩa hoàn thành', bạn sẽ nhận thấy rằng có một kế hoạch kiểm tra nhanh chóng trở thành một trong những mục. Làm thế nào khác bạn có thể mô tả câu chuyện sẽ được thực hiện, nếu nó chưa được thử nghiệm.

Ai chịu trách nhiệm tạo kế hoạch kiểm tra? Đội

Đội là ai? Bất kỳ ai cam kết hiện thực hóa sản phẩm nên là thành viên của Nhóm.

Vì vậy, trong trường hợp của bạn, bạn có thể bao gồm (hoặc thuê) người có thể viết kế hoạch kiểm tra vào 'nhóm phát triển' của bạn. Nếu bạn đang chuyển sang Agile, bạn sẽ nhận thấy rằng việc tạo một kế hoạch kiểm tra xảy ra song song với sự phát triển. Cả hai bắt đầu từ cùng một câu chuyện, và thông qua giao tiếp cuối cùng được đồng bộ hóa và phân phối cùng một lúc. Bạn không nên tuyên bố câu chuyện của mình 'xong' trước khi vượt qua các trường hợp thử nghiệm mà các SH tham gia xem là quan trọng.

Tôi thấy rằng các kế hoạch kiểm tra chức năng nên được viết bởi các nhà phân tích chức năng / kinh doanh. Họ viết phân tích chức năng (ngay cả khi bạn đang làm việc nhanh nhẹn, tôi giả sử bạn có một số phân tích), và vì vậy họ nên viết ra những đường dẫn trong ứng dụng nên được theo dõi cho mục đích thử nghiệm.

Điều đó hoàn toàn phụ thuộc vào cách bạn làm việc, nhưng theo tôi, các nhà phát triển không nên viết các tài liệu chức năng về cách kiểm tra ứng dụng, sử dụng dữ liệu nào để kiểm tra ứng dụng, v.v.

Đây là một ý tưởng có thể làm cho cả hai nhóm hài lòng và phù hợp với việc tiến tới một cách tiếp cận Agile:

Tự động hóa kiểm tra chấp nhận người dùng của bạn và ghi lại chúng.

http://pragprog.com/mag Magazine / 2009-12/automating-screencasts

Nghe có vẻ như một phần của vấn đề bạn gặp phải là các kế hoạch kiểm tra bạn đang viết rất lặp đi lặp lại và hoàn toàn xác nhận. Thành thật mà nói, tôi sẽ không gọi những gì bạn đang viết thử nghiệm - nếu nó chỉ xác nhận các yêu cầu, thì nó đang kiểm tra . Tự động hóa điều này và ghi lại nó sẽ cho phép bạn đóng gói một bản demo gọn gàng cho khách hàng của bạn thường xuyên (thậm chí bạn có thể gửi cho họ trong một ngày ngắn) - họ sẽ có nhiều khả năng nhấp vào bản demo và xem nó hơn là mở kế hoạch kiểm tra và bắt đầu làm việc với nó, vì vậy hy vọng bạn sẽ nhận được phản hồi nhanh hơn (rất quan trọng nếu bạn đang tiến tới một cách tiếp cận Agile hơn). Bạn sẽ có thể sử dụng lại các thành phần để nó giảm khối lượng công việc cho bạn,

Nó cũng cung cấp một cách thực sự thực hiện các yêu cầu - bạn đã xem qua các thông số kỹ thuật thực thi của Gojko Adzic chưa? Hãy xem tại đây: http://gojko.net/2010/08/04/lets-change-the-tune/ Nếu bạn đang nghĩ về điều này như một cách để đưa các yêu cầu vào một hình thức thực thi để demo cho khách hàng của bạn , sau đó nó đột nhiên dường như ít vô nghĩa hơn.

Bây giờ, đặt mũ thử nghiệm của tôi, tôi rất vinh dự chỉ ra rằng nếu điều đó xảy ra, nó sẽ giải phóng bạn / các bên liên quan của bạn để thực hiện một số thử nghiệm thích hợp - tức là thử các trường hợp cạnh và thử nghiệm thực sự thách thức ứng dụng , thay vì chỉ xác nhận các yêu cầu. Tôi muốn đề nghị bạn cung cấp các screencasts cùng với các câu hỏi hoặc gợi ý ngắn cho các khu vực bạn muốn phản hồi nhiều hơn, ví dụ:

1) Đây là mẫu đăng ký mới của chúng tôi - hãy xem đoạn ghi hình này để xem nó hoạt động như thế nào!

Những gì chúng tôi muốn phản hồi về: Chúng tôi đã thêm rất nhiều kiểm tra vào biểu mẫu này để đảm bảo khách hàng không thể nhập dữ liệu sai - chúng tôi thực sự muốn bạn xem các thông báo lỗi mà khách hàng gặp phải khi họ đặt sai và cho chúng tôi biết khách hàng của chúng tôi sẽ thấy họ dễ hiểu.
Chúng tôi cũng muốn biết liệu chúng tôi đã quá nghiêm ngặt trong một số trường hợp - nếu bạn có bất kỳ dữ liệu khách hàng đặc biệt nào (có thể là một tên thực sự dài, hoặc một tên thực sự ngắn hoặc ai đó có các ký tự khác thường trong tên của họ, hoặc một cái gì đó khác mà chúng tôi không nghĩ ra, hoặc có thể địa chỉ của họ không có tên đường hoặc một cái gì đó kỳ lạ như vậy?) thì có lẽ bạn có thể dành vài phút để thử chúng?

Tức là bạn trình bày một screencast đẹp, và sau đó yêu cầu phản hồi, đóng khung nó mà không quá cụ thể, khiến họ suy nghĩ về các vấn đề tiềm năng thay vì chỉ xác nhận. Làm cho họ suy nghĩ , thay vì chỉ nhấp một cách mù quáng thông qua một kế hoạch kiểm tra. Về cơ bản bạn đang viết một điều lệ thử nghiệm thăm dò cho họ. (Nếu bạn nhìn vào Quadrant thử nghiệm Agile , đây sẽ là các thử nghiệm trong Quadrant 3).

Hãy cải tạo ngôi nhà của bạn làm ví dụ. Bạn có chấp nhận một danh sách kiểm tra được thực hiện bởi nhà thầu của bạn yêu cầu bạn kiểm tra những gì anh ta đã làm cho bạn? Hoặc bạn sẽ đưa ra danh sách kiểm tra của riêng mình và kiểm tra xem nhà thầu đã thực hiện những gì BẠN đã chỉ định chưa?

Câu trả lời rất rõ ràng: người yêu cầu nên kiểm tra xem liệu những gì anh / cô ấy yêu cầu được thực hiện theo thông số kỹ thuật. Anh ấy / cô ấy nên đi ra với danh sách kiểm tra của riêng mình và kiểm tra ứng dụng. chống lại danh sách này.

Tuy nhiên, nhà phát triển nên có danh sách kiểm tra của riêng họ và đảm bảo kiểm tra nội bộ phù hợp được thực hiện và xóa lỗi trước khi xử lý ứng dụng. hơn cho UAT. Tốt nhất, nhà phát triển nên tự động hóa hầu hết các thử nghiệm này dưới dạng các kịch bản thử nghiệm. Ghi nhớ TDD? Lý tưởng nhất, các kịch bản thử nghiệm (trong trường hợp này, các trường hợp thử nghiệm đơn vị) nên được viết để kiểm tra các thành phần của ứng dụng. Bộ kiểm thử sau đó nên được viết để kết hợp các trường hợp kiểm thử đơn vị này để thực hiện kiểm tra hồi quy tích hợp và sau đó.

Kế hoạch kiểm tra chấp nhận của người dùng cuối thường được viết bởi khách hàng hoặc một đối tác kinh doanh tại công ty đại diện cho khách hàng. Nó được cho là đại diện cho các tính năng khách hàng muốn và bổ sung cho thử nghiệm tích hợp của QA. Cả QA và Phát triển đều không thể lập kế hoạch kiểm tra chấp nhận người dùng một cách hiệu quả, vì một trong những mục tiêu chính của kiểm tra chấp nhận người dùng là đảm bảo rằng những gì QA và Phát triển nghĩ rằng khách hàng muốn là thực sự chính xác.