Chia sẻ các trường hợp thử nghiệm phát triển (tích hợp đơn vị và phát triển) với nhóm QA (thử nghiệm)?

8

Nhóm thử nghiệm (nhóm được gọi là nhóm QA trong một số tổ chức) khẳng định rằng nhóm phát triển nên chia sẻ các trường hợp thử nghiệm của họ (nhóm phát triển) với họ. Lập luận của họ là các trường hợp thử nghiệm phát triển là điểm khởi đầu cho thử nghiệm QA.

Là thành viên nhóm phát triển, tôi không hiểu yêu cầu. Theo tôi, người kiểm tra nên kiểm tra giải pháp dựa trên các yêu cầu. Tôi không biết liệu nhóm thử nghiệm có nên được chia sẻ với tài liệu thiết kế chi tiết (thiết kế cấp thấp) hay không. Tuy nhiên, chúng tôi đang chia sẻ cho họ thiết kế chi tiết.

Tôi đã đọc một số bài đăng ở đây nói rằng nhóm QA nên chia sẻ các trường hợp thử nghiệm của họ với nhóm phát triển để có giải pháp tốt hơn và cho thông lượng tốt hơn. Nhưng, không có gì loại nhóm phát triển chia sẻ các trường hợp thử nghiệm của họ với nhóm thử nghiệm QA.

Có vẻ như nhóm QA của tôi rất vui nếu tôi chia sẻ đơn vị phát triển và các trường hợp thử nghiệm tích hợp và kết quả thử nghiệm.

— Sudhi Sukumara
nguồn

6

QA không cần tài liệu thiết kế chi tiết. Họ được cho là để kiểm tra các yêu cầu , không phải thiết kế .

Một lợi ích của việc chia sẻ thông tin này là nhóm QA có thể xác định xem họ có đang diễn giải các yêu cầu giống như nhóm nhà phát triển hay không. Hoặc bạn muốn cung cấp một số tài liệu khác hoặc đi qua nó trong một cuộc họp?

— JeffO

2

Stack Exchange không phải là một diễn đàn ...

— Peter Mortensen

4

@JeffO thực sự, đó là một lý do tốt để không chia sẻ các trường hợp thử nghiệm phát triển, nhưng yêu cầu tạo chúng trực tiếp từ các yêu cầu. Một lợi ích chính từ chức năng kiểm tra riêng biệt là những giả định đầy thách thức được đưa ra trong quá trình phát triển bằng cách "có đôi mắt mới" về các yêu cầu. Nếu một số bài kiểm tra QA thất bại vì chúng xen vào các yêu cầu khác với nhóm nhà phát triển - thật tuyệt, đó là thông tin rất quan trọng sẽ bị bỏ qua nếu chúng bắt đầu bằng cách đọc cách giải thích "rõ ràng" của nhóm nhà phát triển.

— Peteris

19

Khi nhóm nhà phát triển của bạn và nhóm QA của bạn không nói chuyện với nhau, có một rủi ro nhất định rằng một số bài kiểm tra được thực hiện không cần thiết hai lần và một số bài kiểm tra khác bị lãng quên. Một trường hợp xấu nhất là khi nhóm nhà phát triển của bạn đã thực hiện một số thử nghiệm tích hợp tự động tốt, chạy trong vài phút hoặc vài giờ và người QA của bạn sẽ kiểm tra những thứ tương tự bằng tay, dành nhiều ngày hoặc vài tuần cho nhiệm vụ đó. Một kịch bản xấu khác là khi cả hai nhóm nghĩ rằng nhóm kia chịu trách nhiệm cho một số loại thử nghiệm, và vì vậy những thử nghiệm đó bị bỏ qua.

Vì vậy, giả sử cả hai nhóm làm việc theo nhóm và không chống lại nhau, sẽ hợp lý khi thông báo cho nhau chi tiết các thử nghiệm được thực hiện bởi nhóm nào và để hai nhóm phối hợp hoạt động.

— Bác sĩ Brown
nguồn

3

theo kinh nghiệm của tôi, cách đáng tin cậy nhất để thông báo cho nhau một cách chi tiết là thông qua phạm vi kiểm tra . Không có vấn đề nếu QA hoặc dev quên điều gì đó, phân tích bảo hiểm thường sẽ hiển thị những gì đã sai. Hạn chế duy nhất là nó quá hấp dẫn khi dựa vào nó quá nhiều và tắt não "chúng tôi đã có 100%, chúng tôi hoàn hảo!" vâng chắc chắn

— gnat

mã bảo hiểm không có nghĩa là mã hoạt động. Các chương trình thành công không chỉ là logic mã - còn có dữ liệu liên quan. Thêm các yếu tố môi trường (ví dụ: hoạt động tốt trên XP, không phải trên Win7) và tương tác (ví dụ: tôi kích hoạt mô-đun sản phẩm và tôi không thể đăng nhập được nữa). Mã bảo hiểm là cận thị tập trung vào nhà phát triển.

— gbjbaanb

@gnat: phân tích bảo hiểm có thể là một chỉ số hữu ích để tìm một số phần chưa được kiểm tra trong chương trình của bạn mà có thể quên nếu không, tôi đồng ý. Nhưng tất nhiên, để phát triển một bộ thử nghiệm tốt, chỉ riêng phạm vi bảo hiểm là không đủ và nó cũng không giúp bạn tránh làm những việc tương tự hai lần một cách không cần thiết. Và nếu đó là công cụ phù hợp để giao tiếp mọi thứ giữa nhóm QA và nhóm dev? Điều này phụ thuộc rất nhiều vào cách hai đội làm việc.

— Doc Brown

1

@gbjbaanb đồng ý về cận thị, tôi đã thấy quá thường xuyên mọi người rơi vào ảo tưởng "được bảo hiểm = thử nghiệm", điều đó khá có hại. Điều hữu ích duy nhất ( rất hữu ích để chính xác) tôi từng thấy từ phân tích bảo hiểm là "khoảng trống", cho thấy những gì không được bảo hiểm. Ngoài ra, nó đơn giản là không còn hữu ích, nó không thể biết được liệu mã được bảo hiểm có được kiểm tra chính xác hay không

— gnat

1

@DocBrown Tôi muốn nói rằng đây là công cụ phù hợp để kiểm soát các lỗ hổng có thể có trong giao tiếp ... :) không có cách nào thay thế cho thảo luận, làm việc nhóm và chuyển giao kiến thức

— gnat

16

Nhóm thử nghiệm (nhóm được gọi là nhóm QA trong một số tổ chức) khẳng định rằng nhóm phát triển nên chia sẻ các trường hợp thử nghiệm của họ (nhóm Dev) với họ.

Chắc chắn, QA nên có một sự hiểu biết chung về những gì được bao phủ bởi các bài kiểm tra đơn vị / tích hợp và những gì không.

Đối số của họ là các trường hợp thử nghiệm Dev là điểm khởi đầu cho thử nghiệm QA.

... Ngay cả khi lý luận của họ là thiếu sót. Câu thần chú số 1 của một người QA là không tin tưởng các nhà phát triển . "Đừng lo lắng về điều đó! Tôi đã kiểm tra kỹ lưỡng!" là bước đầu tiên hướng tới một vấn đề sản xuất khổng lồ.

Như Doc Brown nói, thật không tốt khi dành cả đống thời gian QA cho một thứ gì đó được bao phủ tốt bởi các bài kiểm tra tự động. Nhưng thật là ngu ngốc khi không dành thời gian cho một cái gì đó được bao phủ tốt bởi các bài kiểm tra tự động. Và thật lãng phí khi dành cả đống thời gian để ghi lại các bài kiểm tra đơn vị của bạn một cách chi tiết khi QA không thực sự tin tưởng họ dù sao (và vì mức độ tài liệu đó thúc đẩy các nhà phát triển của bạn thực hiện các bài kiểm tra đơn vị kém / tệ).

— Telastyn
nguồn

Tôi hoàn toàn đồng ý với những gì bạn đã viết, các quy tắc bảo đảm chất lượng hàng đầu tất nhiên là "kiểm tra kỹ mọi thứ" và "hai cặp mắt tốt hơn một".

— Doc Brown

4

Trong một kiến trúc phần mềm hiện đại, mục đích là các bài kiểm tra không chỉ kiểm tra mã mà chúng còn thực hiện theo cách ghi lại chức năng của chúng.

Tài liệu này về những gì mã làm (ngoài những gì nó dự định làm trong thông số kỹ thuật) rất hữu ích cho QA'ers để hiểu rõ hơn về ý định của mã và cả liệu nó có phù hợp với yêu cầu hay không. Nó cũng là thông tin hữu ích khi QA'ers đang viết các trường hợp thử nghiệm và nó sẽ giúp cung cấp cho họ cảm giác về lý thuyết, về lý thuyết, đã được thử nghiệm. Một số khu vực được thử nghiệm có thể được hưởng lợi từ các trường hợp bổ sung và những khu vực khác có thể bị lộ là không có xét nghiệm nào cả.

Các chi tiết thực tế của việc tiếp xúc này sẽ phụ thuộc rất lớn vào cấu trúc tổ chức và đặc biệt là độ sâu kỹ thuật của người kiểm tra (ví dụ đọc mã nguồn).

Để hơi trái ngược ... Tôi thường thích bỏ qua các bài kiểm tra của nhà phát triển và đưa ra các bài kiểm tra 'của riêng tôi' (tôi là thành viên của một nhóm QE lớn). Tôi đã phát hiện ra rằng bỏ qua các thử nghiệm dành cho nhà phát triển sẽ giúp tránh suy nghĩ chỉ xem xét vấn đề / vấn đề / tính năng theo quan điểm của nhà phát triển.

Phương châm QE của tôi là: QE nên gia tăng giá trị bằng cách thử nghiệm sản phẩm. "Hợp nhất và chạy thử nghiệm đơn vị" một mình là không đủ QA!

— Michael Durrant
nguồn

3

Phản ứng đầu tiên của tôi về câu hỏi này là trên mạng.

Nó phụ thuộc vào ý nghĩa của bạn trong trường hợp thử nghiệm của nhóm phát triển.

Nếu bạn chỉ có bài kiểm tra đơn vị ( kiểm tra hộp trắng ); Nhóm QA (tích hợp và kiểm tra hệ thống) không thể tận dụng các trường hợp thử nghiệm của bạn. Kiểm tra đơn vị chỉ ở đó để xác minh đơn vị của bạn, đơn vị không đáp ứng yêu cầu (chủ yếu). Kiểm thử hộp trắng không phải là cách để kiểm tra tích hợp hoặc hệ thống.
Nếu bạn có các bài kiểm tra hành vi; Nhóm QA có thể sử dụng chúng để rút ra một số tình huống tích hợp.
Nếu bạn đang sử dụng TDD ; theo định nghĩa, các bài kiểm tra là các tài liệu thực thi về các yêu cầu, kiến trúc và thiết kế của ứng dụng. Đội QA chắc chắn sẽ cần những trường hợp thử nghiệm này.
Một số phương pháp thiết kế thử nghiệm như thử nghiệm hộp xám yêu cầu thông tin thiết kế chi tiết để có thể cô lập hoặc giả định các đối tượng thử nghiệm như thành phần hoặc hệ thống con (thử nghiệm tích hợp). Do đó, việc chia sẻ thiết kế chi tiết với nhóm QA cũng là cần thiết.
Kiểm tra hệ thống kẻ không bao giờ bận tâm với thiết kế chi tiết. Họ tập trung vào các kịch bản người dùng. Do đó, các thử nghiệm phát triển (hộp trắng) sẽ không được sử dụng cho chúng.

Đề xuất khiêm tốn của tôi cho trường hợp của bạn là đánh giá các cách tiếp cận nhanh như thử nghiệm (QA) trong nhóm thử nghiệm và thiết kế thử nghiệm (tính năng, tích hợp, hệ thống) cùng nhau trả trước.

— Kaan
nguồn

1

Không có lý do gì mà bạn không nên chia sẻ những gì bạn đã thử nghiệm với nhóm QA, tuy nhiên họ nên sao chép các thử nghiệm của bạn mà họ cảm thấy rất quan trọng để xác minh đúng ứng dụng.

1) Họ chịu trách nhiệm kiểm tra mã / ứng dụng / bất cứ điều gì. Bằng cách sao chép các bài kiểm tra của bạn khi thích hợp, họ xác minh rằng bài kiểm tra của bạn đã được thực hiện đúng.

2) Là nhà phát triển, bạn chịu trách nhiệm kiểm tra đơn vị mã của mình (nói chung, tuy nhiên, một số tổ chức cũng đã bắt đầu kiểm tra mã của họ). Đây là một cách tiếp cận khác và thường được tập trung nhiều hơn vào việc bao quát các điểm quyết định trong một phương pháp.

3) Như bạn đã đề cập, điều quan trọng đối với nhóm thử nghiệm của bạn là chia sẻ các trường hợp thử nghiệm của họ với bạn để giúp bạn nghĩ về các trường hợp mà bạn có thể chưa xem xét ban đầu.

4) Ai đó đã đề cập rằng đó là trách nhiệm của các nhóm thử nghiệm để kiểm tra các yêu cầu và trong khi điều này là đúng, thiết kế chi tiết cũng khá hữu ích. Bằng cách thiết kế, nhóm thử nghiệm không chỉ có thể đảm bảo rằng bạn đáp ứng các yêu cầu mà còn giúp họ hiểu một số quyết định thiết kế và sẽ giúp họ cuối cùng tạo ra các trường hợp thử nghiệm tốt hơn.

— Đẹp hơn
nguồn