Một nhà phát triển cũng nên hoạt động như một người thử nghiệm? [đóng cửa]


60

Chúng tôi là một nhóm scrum gồm 3 nhà phát triển, 1 nhà thiết kế, chủ scrum và chủ sở hữu sản phẩm. Tuy nhiên, chúng tôi không có người thử nghiệm chính thức trong nhóm của chúng tôi. Một vấn đề luôn xảy ra với chúng tôi, đó là, thử nghiệm ứng dụng và vượt qua các thử nghiệm đó và loại bỏ các lỗi đã được xác định là một trong những tiêu chí để xem xét PBI (Product Backlog Item) là xong.

Nhưng vấn đề là ở chỗ, dù chúng tôi (3 nhà phát triển và 1 nhà thiết kế) cố gắng thử nghiệm ứng dụng và triển khai các trường hợp sử dụng như thế nào, vẫn có một số lỗi không được nhìn thấy và phá hỏng phần trình bày của chúng tôi ( luật Murphy ) cho các bên liên quan.

Để khắc phục, chúng tôi khuyên công ty nên thuê một người thử nghiệm mới. Ai đó công việc sẽ được thử nghiệm và chỉ thử nghiệm. Một thử nghiệm chuyên nghiệp chính thức.

Tuy nhiên, vấn đề là, chủ scrum và các bên liên quan tin rằng một nhà phát triển (hoặc một nhà thiết kế) cũng nên là một người thử nghiệm.

Họ có đúng không? Chúng ta có nên phát triển (cũng là nhà thiết kế) không?


1
Bản sao có thể có của các lập trình viên.stackexchange.com/questions / 100637 / , mặc dù điều đó được hỏi từ quan điểm ngược lại.
Adam Lear

Trong nhóm scrum tôi đã tham gia, mọi người trong số họ đang thử nghiệm ứng dụng điện thoại thông minh hoặc máy tính bảng và tất cả đều giúp đỡ rất nhiều.
ott--

Nhà văn cần một biên tập viên.
JeffO

Câu trả lời:


59

Ex ante: Dường như có rất nhiều nhầm lẫn về những gì được coi là thử nghiệm những gì không. Chắc chắn, mọi nhà phát triển cần kiểm tra mã của anh ta khi anh ta tạo nó, anh ta / cô ta cần xác minh nó hoạt động. Cô ấy / anh ấy không thể đưa nó cho người kiểm tra trước khi anh ấy / cô ấy nghĩ rằng nó đã hoàn thành và đủ tốt. Nhưng các nhà phát triển không nhìn thấy mọi thứ. Họ có thể không nhận ra lỗi. Những lỗi này chỉ có thể được tìm thấy sau này trong chu kỳ phát triển khi tiến hành kiểm tra kỹ lưỡng. Câu hỏi đặt ra là liệu các nhà phát triển có nên tiến hành loại thử nghiệm đó hay không, và theo ý kiến ​​khiêm tốn của tôi, điều này cần được xem xét từ quan điểm của người quản lý dự án:

Các nhà phát triển có thể là người thử nghiệm, nhưng họ không nên là người thử nghiệm . Các nhà phát triển có xu hướng vô tình / vô ý tránh sử dụng ứng dụng theo cách có thể phá vỡ nó. Đó là bởi vì họ đã viết nó và chủ yếu kiểm tra nó theo cách nó nên được sử dụng.

Một người kiểm tra tốt mặt khác, cố gắng tra tấn ứng dụng. Mục đích chính của anh ấy / cô ấy là phá vỡ nó. Họ thường sử dụng ứng dụng theo cách mà các nhà phát triển sẽ không tưởng tượng được. Họ gần gũi với người dùng hơn nhà phát triển và thường có cách tiếp cận khác để kiểm tra quy trình làm việc.

Ngoài ra, sử dụng các nhà phát triển làm người thử nghiệm làm tăng chi phí phát triển và không có lợi cho chất lượng sản phẩm nhiều như có một người thử nghiệm chuyên dụng. Tôi sẽ không để các nhà phát triển kiểm tra chéo các tác phẩm của họ khi tôi có thể hoàn thành tốt hơn bởi một người thử nghiệm với giá rẻ. Chỉ khi vòng phản hồi giữa nhà phát triển và người thử nghiệm trở nên quá đắt, tôi mới có nhà phát triển kiểm tra mã của nhau, nhưng theo kinh nghiệm của tôi thì hiếm khi xảy ra và nó phụ thuộc nhiều vào quy trình.

Điều đó không có nghĩa là một nhà phát triển nên cẩu thả và để lại mọi thứ cho người kiểm tra. Phần mềm nên được sao lưu bằng các bài kiểm tra đơn vị và các lỗi kỹ thuật nên được giảm đến mức tối thiểu trước khi bàn giao phần mềm cho người kiểm tra. Tuy nhiên, đôi khi bạn đã khắc phục ở đây, khắc phục sự cố hoặc các lỗi khác mà không nhà phát triển nào có thể thấy trước, điều đó không sao cả. Ngoài ra, kiểm thử tích hợp nên được thực hiện chủ yếu bởi các nhà phát triển. Mục tiêu chính của người kiểm tra là xác minh rằng các yêu cầu được đáp ứng.

Trong một nhóm nhỏ như vậy (và cũng tùy thuộc vào kích thước của ứng dụng), tôi cũng có thể thấy người thử nghiệm trong vai trò kết hợp, viết bài kiểm tra đơn vị và kiểm tra giao diện người dùng. Bạn chắc chắn nên thuê một .

Nhưng quan trọng hơn người kiểm tra là đóng băng / chi nhánh thường xuyên. Đừng trình bày bất cứ điều gì chưa được kiểm tra đúng cách. Khi bạn đã thêm một tính năng hoặc thay đổi một cái gì đó, mọi thứ xung quanh nó phải được xác minh lại. Bạn sẽ chỉ nhận được một danh tiếng xấu nếu công ty của bạn không. Đừng phát hành một cái gì đó không ổn định. Khi khách hàng muốn có phần mềm vào một ngày nhất định, sau đó dừng phát triển đủ sớm và kiểm tra phần mềm đúng cách, do đó bạn có đủ thời gian để sửa lỗi. Thông thường, tốt hơn là từ chối các yêu cầu tính năng vào phút cuối hơn là triển khai chúng kém hoặc phát hành mà không có thử nghiệm thích hợp.


9
Không đồng ý mạnh mẽ và kịch liệt ... Các nhà phát triển có thể là người thử nghiệm hiệu quả cao nhưng nhà phát triển tính năng KHÔNG nên là người thử nghiệm tính năng tương tự. Nhiều nhóm nhỏ đóng cả hai vai trò, bởi ba người làm việc trên ba tính năng khác nhau, sau đó tiến hành thử nghiệm cho một trong ba nhà phát triển khác. Nó hoạt động rất tốt khi một nhóm không có người kiểm tra QA.
maple_shaft

5
@maple_shaft: Imho không có lý do gì để không có người kiểm tra. Bất kỳ dự án nào cũng sẽ cung cấp chất lượng cao hơn với một người thử nghiệm chuyên dụng và các nhà phát triển có thể tập trung vào, phát triển tốt nếu có. Có các nhà phát triển kiểm tra mã của nhau là một giải pháp tạm thời, ngay cả đối với các nhóm nhỏ imho. Bạn cũng nên đọc bài viết của Joel về nó.
Falcon

3
Các nhà phát triển có thể là người thử nghiệm - và một nhà phát triển giỏi thực sự biết nhiều nơi mà mã có thể yếu và có thể bị phá vỡ. Không bao giờ có người kiểm tra mã họ thiết kế hoặc viết - điều đó là vô ích. Mã của người khác có thể ổn.
StasM

4
@deadalnix: Nó thực sự đánh đố tôi tại sao mọi người downvote mà không đọc và hiểu câu trả lời của tôi. Để tự trích dẫn: "Phần mềm nên được sao lưu bằng các bài kiểm tra đơn vị và các lỗi kỹ thuật nên được giảm đến mức tối thiểu trước khi bàn giao phần mềm cho người kiểm tra."
Falcon

2
"Mặt khác, một người thử nghiệm giỏi, cố gắng tra tấn ứng dụng. Mục đích chính của anh ta / cô ta là phá vỡ nó." - Hoàn toàn không đồng ý. Tôi có một trình kiểm tra liên tục cố gắng nghiền bàn phím xuống hoặc tràn các trường. Chắc chắn, đây là những lỗi, nhưng một hóa đơn trị giá 1 nghìn tỷ nghìn tỷ đồng gây ra lỗi rất thấp trong danh sách việc cần làm của tôi là không đăng ký. Một người kiểm tra TUYỆT VỜI kiểm tra tất cả các kịch bản mà nhiều người dùng sẽ sử dụng ứng dụng. Một nhà phát triển tốt đảm bảo tất cả các đường dẫn mã đã được kiểm tra và ứng dụng hoạt động khi được sử dụng như dự định.
Paul

42

Các nhà phát triển có thể là người thử nghiệm - mã của các nhà phát triển khác.

Nhưng kiểm tra mã của riêng bạn không phải là một động thái tốt - các nhà phát triển có xu hướng có các khối tinh thần về mã riêng của họ và do đó gặp khó khăn trong việc thiết kế các thử nghiệm toàn diện hoặc phù hợp.

Sẽ luôn có những nhà phát triển nghĩ rằng họ làm tốt điều này, nhưng thường thì họ không (và tôi chắc chắn biết rằng tôi có nhiều điểm mù).

Nếu bạn THỰC SỰ CANT thuê một người thử nghiệm, sau đó yêu cầu các nhà phát triển thử nghiệm chéo với nhau - nghĩa là, nếu A viết mã và thực hiện kiểm tra đơn vị, sau đó yêu cầu B xem qua các thử nghiệm đơn vị đó và xem liệu có thể thêm những thứ khác không . Và nhận B để thử và kiểm tra mã (với tư cách là người dùng) và báo cáo lỗi.

Điều này không hoàn hảo nhưng tốt hơn là một nhà phát triển cố gắng làm mọi thứ.

Đôi khi các đồng nghiệp của bạn có thể thực sự giỏi trong việc phá vỡ phần mềm của bạn, bởi vì họ nhận được sự thích thú từ đó và không quan tâm lắm - vì đó không phải là mã CỦA HỌ.


2
Ồ vâng, chắc chắn. Hoàn toàn đồng ý. Chỉ là khi bạn không thể có được 100% những gì bạn muốn, bạn có thể phải giải quyết ít hơn. Bạn biết rằng ít hơn là không tốt nhưng tốt hơn là không có gì.
quick_now

4
Tôi thường đồng ý với thử nghiệm chéo nhưng trên một số đội sẽ đưa ra xung đột. Một số người thích đổ lỗi cho người khác ("công cụ của tôi hoạt động, không phải của bạn, lol, tôi tốt hơn bạn rất nhiều") và điều đó không thể chấp nhận được. Tôi đã chứng kiến ​​điều đó nhiều lần. Crosstesting chỉ nên được thực hiện giữa các đồng nghiệp tôn trọng lẫn nhau. Trong nhóm của tôi, tôi đã giới thiệu nhà phát triển không tên , người bị đổ lỗi cho mọi lỗi để tránh việc bất cứ ai mất mặt. Lỗi là không tên, chúng xảy ra.
Chim ưng

5
+1 không thể kiểm tra chính xác mã của bạn. Thật đáng kinh ngạc khi những thủ thuật mà tâm trí có thể chơi với bạn - bạn sẽ chắc chắn 100% bạn đã mã hóa và thử nghiệm một số chức năng và sẽ phải nhờ người khác chỉ cho bạn thấy nó thực sự không hoạt động trừ trường hợp rất hẹp và nó sẽ rõ ràng cho bạn một khi được hiển thị - nhưng bạn sẽ không bao giờ nhìn thấy nó. Tâm trí sử dụng các phím tắt nhận thức và trong việc kiểm tra những điều đó khiến người thiết kế và phát triển mã không thể kiểm tra nó một cách chính xác.
StasM

2
@StasM - đã đồng ý, với một bằng cấp nhỏ: Tôi đã thấy rằng trở lại mã của chính mình vài tháng sau, tôi có thể thấy các lỗi và có thể thực hiện công việc kiểm tra nó một cách khách quan hơn. Nhưng kiểm tra của riêng bạn sau khi viết là rất khó.
quick_now

1
@Ben Aston: Một nhà phát triển vẫn nên thực hiện các bài kiểm tra đơn vị, kiểm tra tích hợp, v.v. Các điểm mù sẽ không biến mất chỉ vì bạn muốn chúng.
quick_now

11

Nhà báo có nên viết đúng? Ý tôi là, đó là công việc chỉnh sửa và biên tập viên để tìm tất cả các lỗi ngữ pháp.

Tuy nhiên, các nhà báo cung cấp một số kiểm tra chính tả của mình. Tuy nhiên, sửa chữa là một nghề riêng biệt và quan trọng.

Điều tương tự về các nhà phát triển và người thử nghiệm, ngoại trừ thực tế là QA thậm chí còn là một phần quan trọng hơn của sự phát triển. Ngay cả khi bạn là một nhà phát triển giỏi, bạn cũng không có thời gian để kiểm tra kỹ tất cả các trường hợp thử nghiệm, để bao quát tất cả các môi trường, trình duyệt, HĐH mà sản phẩm của bạn đang hỗ trợ.

Nếu một người, ngoài việc phát triển, liên tục làm công việc đó, nó chỉ có nghĩa là một thực tế đơn giản - anh ta là một người thử nghiệm bán thời gian.


10

bất kể chúng tôi (3 nhà phát triển và 1 nhà thiết kế) cố gắng thử nghiệm ứng dụng và triển khai các trường hợp sử dụng như thế nào, vẫn còn một số lỗi không được nhìn thấy và làm hỏng bản trình bày của chúng tôi ... cho các bên liên quan.

Xem xét thực hiện "chạy có kiểm soát" cho một hoặc hai lần chạy nước rút, theo dõi các nỗ lực phát triển và thử nghiệm riêng biệt. Khi kết thúc quá trình đó, hãy phân tích dữ liệu thu thập được để tìm hiểu xem bạn đã dành bao nhiêu nỗ lực để thử nghiệm.

Nếu bạn phát hiện ra rằng việc kiểm tra tốn nhiều công sức, hãy chuyển dữ liệu đó cho quản lý - đó sẽ là một bằng chứng thuyết phục hỗ trợ cho yêu cầu của bạn (hấp dẫn hơn nhiều so với hiện tại).

Mặt khác (nếu bạn thấy thử nghiệm của mình mất ít thời gian), hãy xem xét đầu tư thêm nỗ lực để thực hiện nó tốt hơn (hoặc học cách làm điều đó). Đàm phán rằng nỗ lực bổ sung mà bạn lên kế hoạch với quản lý của mình - bởi vì họ có thể thích thuê một người thử nghiệm thay thế. :)


... Chúng tôi đề nghị công ty thuê một người thử nghiệm mới. Ai đó công việc sẽ được thử nghiệm và chỉ thử nghiệm. Một thử nghiệm chuyên nghiệp chính thức.

Tuy nhiên, vấn đề là, chủ scrum và các bên liên quan tin rằng một nhà phát triển (hoặc một nhà thiết kế) cũng nên là một người thử nghiệm.

Phải thừa nhận, quản lý của công ty bạn trông khá khập khiễng. Ý tôi là - ok, có thể rất khó để tìm ra có bao nhiêu người thử nghiệm sẽ là tốt nhất cho dự án, tốt thôi.

Nhưng để có ít nhất một người thử nghiệm chỉ là một vụ cá cược an toàn - thực sự buồn cười là họ ngần ngại thử nó, trong khi tự nhận mình là scrum / nhanh nhẹn .


9

Vâng, chúng tôi đã có hai nhà phát triển thử nghiệm chéo sau khi người đầu tiên thực hiện một số thay đổi đối với màn hình nhập cảnh. Đây là khi người kiểm tra thường xuyên của chúng tôi được nghỉ thai sản.

Về cơ bản, ông đã thay đổi màn hình Danh sách hóa đơn mà người dùng đã sử dụng để chọn hóa đơn trước khi phóng to để thực hiện một số chỉnh sửa thông qua nút "Chỉnh sửa". Danh sách ban đầu đã bị loại bỏ và một khung nhìn lưới mới được chèn, với tính năng lọc, nhóm, sắp xếp và tất cả các loại chức năng thú vị.

Thử nghiệm đã diễn ra tuyệt vời và họ đã tải lên các thay đổi cho khách hàng vào ngày hôm sau. Hai tuần sau, khách hàng gọi điện và nói "Chúng tôi thực sự thích thứ mới mà bạn đưa vào, chúng tôi có thể thấy tất cả các loại thông tin bây giờ. Nhưng ... er ..... chúng ta sẽ đi đâu để chỉnh sửa hóa đơn bây giờ? ?? "

Hóa ra nhà phát triển lấy ra hộp kiểm (để chọn) và nút chỉnh sửa và vì các nhà phát triển luôn nhấp đúp để chọn một mục nào đó, nên không ai trong số họ tìm thấy bất cứ điều gì sai với nó ......

Các nhà phát triển và người dùng sống ở các thế giới khác nhau, có thử nghiệm chéo tốt hơn là nhà phát triển thử nghiệm công việc của chính anh ta nhưng nó vẫn không hoàn toàn giống nhau.


3
Tôi sẽ không nói "họ sống ở các thế giới khác nhau", nhưng mọi người có thói quen và mã của nhà phát triển sẽ hoạt động nếu nó được sử dụng bởi một người có cùng thói quen. Tôi không thể đếm được tần suất tôi không thể tái tạo một lỗi do người kiểm tra tìm thấy, nhìn qua vai anh ta trong khi anh ta tái tạo lỗi và nói "wow, tôi sẽ không bao giờ làm những gì bạn vừa làm".
gnasher729

4

Như những người khác ở đây đã nói rằng các nhà phát triển có thể kiểm tra chéo mã của nhau (kiểm tra đơn vị hoặc chức năng) và có lẽ chủ sở hữu sản phẩm và chủ sở hữu sản phẩm của bạn có thể giúp kiểm tra tích hợp, nhưng để kiểm tra chấp nhận người dùng, bạn nên chắc chắn rằng mình đang nhận được rất nhiều phản hồi từ thử nghiệm của khách hàng - có nghĩa là triển khai thường xuyên mà họ có thể làm việc theo cách mà người dùng thực sự làm và một kênh liên lạc thực sự mở .


2

Bạn nên thiết kế với khả năng kiểm tra nhưng nếu bạn không có người kiểm tra chuyên dụng thì một số thứ sẽ đơn giản trượt qua vết nứt vì không có đủ thời gian trong ngày để thiết kế, thực hiện và kiểm tra phần mềm.


2

Kiểm thử phần mềm là một công việc chuyên nghiệp toàn thời gian. Nó cần một bộ não tốt, tài năng và nhiều kinh nghiệm để trở thành một người thử nghiệm giỏi. Thật nực cười khi cho rằng một nhà phát triển phần mềm, dù thông minh đến đâu, có thể đến gần một người kiểm thử chuyên nghiệp khi kiểm thử chỉ là một thành phần nhỏ trong công việc hàng ngày của anh ta.

Trên hết là vấn đề mà tiềm thức mà nhà phát triển phần mềm không muốn tìm ra lỗi.


1

Tôi đồng ý với quan điểm của họ rằng các nhà phát triển / nhà thiết kế nên kiểm tra mã của họ, với cavaet rằng nhà thiết kế / nhà phát triển đã thực hiện một phần mã không phải là bộ "mắt" duy nhất trên mã đó trước khi cam kết tồn tại. Mặc dù điều đó sẽ không lấy được tất cả mọi thứ, nhưng ít nhất nó sẽ giúp tránh được sự mù quáng trong việc kiểm tra và kiểm tra lại mã của chính bạn trong khi phát triển.

Từ việc đề cập đến trường hợp sử dụng, tôi sẽ cho rằng bạn cũng đang sử dụng các công cụ bao trùm mã? Nếu không, nó có thể giúp xem mã nào có thể không được kiểm tra và có thể xuất hiện các lỗi không mong muốn trong các điều kiện nhất định.

Điều đó đang được nói, nếu có đủ công việc hoặc tổ chức của bạn có quy mô khá, tôi đồng ý rằng cần có một người QA chuyên nghiệp, sẽ giúp tập trung vai trò của mọi người nhiều hơn một chút, và họ cũng có thể xem liệu có bất kỳ mô hình nào về điều gì không đang bị bỏ lỡ, và quan trọng hơn là làm thế nào để khắc phục nó.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.