Để lại lỗi cố ý trong mã để người kiểm tra tìm

Chúng tôi không làm điều này tại công ty của chúng tôi, nhưng một trong những người bạn của tôi nói rằng người quản lý dự án của anh ấy đã yêu cầu mọi nhà phát triển thêm các lỗi cố ý ngay trước khi sản phẩm chuyển sang QA. Đây là cách nó hoạt động:

1. Ngay trước khi sản phẩm đến QA, nhóm phát triển đã thêm một số lỗi cố ý tại các vị trí ngẫu nhiên trong mã. Họ sao lưu đúng mã gốc, mã làm việc để đảm bảo rằng các lỗi đó không được gửi cùng với sản phẩm cuối.
2. Người kiểm tra cũng được thông báo về điều này. Vì vậy, họ sẽ kiểm tra chăm chỉ, bởi vì họ biết có lỗi và không tìm thấy chúng có thể được coi là một dấu hiệu của sự bất tài.
3. Nếu một lỗi (cố ý hoặc cách khác) đã được tìm thấy, chúng sẽ được báo cáo cho nhóm phát triển để khắc phục. Sau đó, nhóm phát triển thêm một lỗi cố ý khác vào phần liên quan của mã ngay trước khi sản phẩm chuyển sang QA cấp hai. Người quản lý dự án nói rằng một người thử nghiệm nên suy nghĩ như một nhà phát triển và anh ta / cô ta nên mong đợi các lỗi mới trong các phần mà các thay đổi được thực hiện.

Vâng, đây là cách nó đi. Họ nói rằng phương pháp này có những lợi thế sau.

1. Người kiểm tra sẽ luôn ở trên đầu họ và họ sẽ kiểm tra như điên. Điều đó giúp họ cũng tìm ra các lỗi ẩn (không chủ ý) để các nhà phát triển có thể sửa chúng.
2. Người kiểm tra ăn bọ. Không tìm thấy bất kỳ lỗi sẽ ảnh hưởng đến tinh thần của họ. Vì vậy, cho họ một thứ dễ tìm sẽ giúp ích cho tinh thần của họ.

Nếu bạn bỏ qua kịch bản mà một trong những lỗi cố ý này được đưa ra cùng với sản phẩm cuối cùng, thì những nhược điểm khác chúng ta nên xem xét trước khi nghĩ đến việc áp dụng phương pháp này là gì?

Một số làm rõ:

1. Họ sao lưu đúng mã gốc trong kiểm soát nguồn.
2. Khi một người kiểm tra tìm thấy lỗi cố ý, nhóm phát triển sẽ bỏ qua nó. Nếu người kiểm tra phát hiện ra lỗi vô ý (nguyên bản), trước tiên nhóm phát triển sẽ kiểm tra xem nó có phải do bất kỳ lỗi cố ý nào không. Đó là, trước tiên nhóm phát triển cố gắng tái tạo mã đó trên mã làm việc ban đầu và cố gắng sửa nó nếu có thể.
3. Chỉ cần bỏ qua các vấn đề mối quan hệ giữa QA và nhóm phát triển. Tôi đặc biệt hỏi câu hỏi này trên Lập trình viên , không phải trên Nơi làm việc . Hãy xem xét rằng có mối quan hệ tốt giữa QA và nhóm phát triển và họ tiệc tùng cùng nhau sau giờ làm việc. Người quản lý dự án là một quý ông tốt bụng, luôn sẵn sàng hỗ trợ cả hai đội (Godsend).

Điều này nghe hoàn toàn hạt dẻ. Nó đang dành rất nhiều nỗ lực cho lợi ích rất đáng nghi ngờ, và thực tế dường như dựa trên một số tiền đề bị lỗi:

• QA sẽ không làm việc chăm chỉ trừ khi họ biết rằng họ đang được kiểm tra mỗi ngày (điều này không thể tốt cho tinh thần)

• Rằng không có đủ lỗi vô tình được giới thiệu trong phần mềm để QA tìm thấy

• Công việc của QA là tìm lỗi - không phải vậy; đó là đảm bảo phần mềm có chất lượng sản xuất

• Rằng cuộc chiến trí tuệ giữa phát triển và QA theo một cách nào đó có lợi cho công ty - không phải vậy; tất cả nhân viên nên làm việc cùng nhau chống lại các đối thủ cạnh tranh của công ty thay vì lẫn nhau.

Đó là một ý tưởng tồi tệ và người quản lý dự án trong câu hỏi là một thằng ngốc / kẻ ngốc không hiểu gì về con người và động lực. Và nó không tốt cho kinh doanh.

Để mở rộng mô tả của tôi về "công việc của QA:" QA chắc chắn nên tìm lỗi - cả trong mã và trong bộ thử nghiệm của họ - như một vật phẩm để thực hiện công việc của họ, nhưng vai trò không nên được định nghĩa là "bạn phải tìm lỗi. " Cần phải là "bạn phải luôn cập nhật các bộ thử nghiệm để tính đến các tính năng mới và đảm bảo tất cả các phạm vi thử nghiệm cao. Nếu điều này không dẫn đến việc tìm ra lỗi, thì quy trình thử nghiệm không đủ tinh vi cho sản phẩm.

Chà, dựa trên những gì tôi đã học:

1. Đó không phải là một cuộc phỏng vấn trường học cũng như công việc;
2. Người thử không phải là trẻ em;
3. Đây không phải là một trò chơi;
4. Nó làm lãng phí tiền của công ty.

QA không chỉ tìm thấy lỗi mà còn lo lắng về việc hệ thống trực quan như thế nào , đường cong học tập cho người dùng, tính khả dụng và khả năng truy cập nói chung. Ví dụ: "Hệ thống có xấu không?", "Người dùng có bị mù màu và công cụ có màu đỏ và xanh không?" Họ cũng nên phàn nàn.

Các yêu cầu tối thiểu để một hệ thống vượt qua QA thường được mô tả trong câu chuyện của người dùng về tính năng cụ thể đó hoặc theo cách mà PO muốn hệ thống nằm trong đầu anh ta.

tl; dr

Đó không chỉ là lỗi, người kiểm tra nên phát triển từ quan điểm hẹp này.

Ý kiến ​​tồi.

Từ quan điểm của người kiểm tra: "Vì vậy, họ sẽ kiểm tra chăm chỉ, bởi vì họ biết có lỗi và không tìm thấy chúng có thể được coi là sự bất tài của họ." Về cơ bản các nhà phát triển đang đặt bẫy mã. Rất ít người thích làm công việc mà cuối cùng là vô nghĩa (vì các lỗi đã được biết trước) nhưng vẫn ảnh hưởng đến cách họ cảm nhận. Nếu có những hình phạt hữu hình vì không tìm thấy cạm bẫy, hơn thế nữa. Và bạn có biết người thử nghiệm phát triển mạnh trong việc tìm lỗi? Nghe có vẻ như một môi trường đối đầu độc hại; QA nên vui mừng nếu mã họ đang kiểm tra có chất lượng cao. Mặc dù nếu họ được trả tiền bởi lỗi ... http: //thed Dailywtf.com/articles/The-Defect-Black-Market

Từ quan điểm của nhà phát triển: QAs đang được khuyến khích để tìm ra các lỗi mà bạn biết là có. Điều đó cũng có thể làm tăng khả năng lỗi thực sự ra khỏi cửa; QAs đang dành ít nhất một chút thời gian để tìm kiếm loại bọ dễ trồng, không thực sự tinh vi. Thêm vào đó, có một cơ hội nhỏ rằng một cái bẫy booby có thể làm cho nó ra khỏi cửa.

Tôi đồng ý hoàn toàn với các câu trả lời ở trên về lý do tại sao điều này không tốt cho động lực và nói chung là quản lý con người khủng khiếp. Tuy nhiên, có thể có những lý do kỹ thuật hợp lý cho việc không làm điều này là tốt:

Ngay trước khi sản phẩm đến QA, nhóm nhà phát triển đã thêm một số lỗi cố ý tại các vị trí ngẫu nhiên trong mã. Họ sao lưu đúng mã gốc, mã làm việc để đảm bảo rằng các lỗi đó không được gửi cùng với sản phẩm cuối.

1. Dựa trên tuyên bố đầu tiên, bạn không bao giờ thực sự kiểm tra mã sản xuất dự định của mình trong hai lần này.

2. Tôi sẽ tưởng tượng bạn tăng khả năng vô tình bao gồm cả lỗi 'cố ý' vào mã sản xuất được phát hành của bạn khi cố gắng vượt qua thay đổi cho khách hàng. Có thể gây ra một vài má đỏ tại một số điểm.

3. Tôi sẽ tưởng tượng rằng điều này chỉ huấn luyện những người thử nghiệm của bạn suy nghĩ giống như các nhà phát triển của bạn (tức là Tom sẽ thêm một lỗi ở đây như thế nào) có thể khiến họ ít tìm thấy các lỗi mà Tom không nghĩ tới.

Biên tập

Tôi muốn làm rõ rằng câu trả lời này chỉ nói về khái niệm kiểm tra quy trình QA của bạn và tôi không bảo vệ phương pháp cụ thể được miêu tả trong câu hỏi.

Kết thúc chỉnh sửa

Có một lý do hợp lệ để kiểm tra xem thử nghiệm / kiểm tra của bạn có thực sự hoạt động hay không. Hãy để tôi cho bạn một ví dụ từ sản xuất, nhưng nguyên tắc là như nhau.

Đó là điển hình khi cho vật liệu qua máy mà bộ nạp có thể không đẩy vật liệu đi đủ xa. Đây được gọi là "nguồn cấp dữ liệu ngắn" và để ngăn chặn điều này, chúng tôi có thể cài đặt "cảm biến nguồn cấp dữ liệu ngắn" (thường là cảm biến loại xuyên chùm bị vật liệu chặn). Cảm biến này phát hiện sự kết thúc của vật liệu khi nó đạt đến chiều dài thức ăn đầy đủ. Tại một thời điểm nhất định trong chu kỳ máy, chúng tôi kiểm tra cảm biến có bị chặn không và dừng máy nếu kiểm tra thất bại.

Bây giờ bạn phải suy nghĩ về cách thử nghiệm chính nó có thể thất bại. Chẳng hạn, một số bụi bẩn hoặc mảnh vụn khác có thể chặn cảm biến và nó sẽ luôn báo cáo "OK" và không bao giờ dừng máy. Ngoài ra, bản chất của cảm biến là máy thu bật khi chùm tia chạm vào nó, do đó tùy thuộc vào loại cảm biến bạn đã cài đặt, bằng điện bạn có được đầu vào "BẬT" khi cảm biến không bị chặn . Điều đó có nghĩa là nếu cáp bị cắt hoặc mất nguồn cho cảm biến đó hoặc đầu vào không thành công, logic chương trình của bạn sẽ đọc "TẮT" và điều đó có nghĩa là "bị chặn" hoặc "OK".

Để nắm bắt các chế độ thất bại này của thử nghiệm, chúng tôi thường chèn một kiểm tra thứ hai để đảm bảo cảm biến thực sự được bỏ chặn trong phần thứ hai của chu kỳ. Bằng cách này, chúng tôi kiểm tra xem thử nghiệm có thực sự vẫn hoạt động không (tốt nhất có thể).

Tương tự như vậy, có nhiều cách mà một bộ phận QA có thể thất bại. Có lẽ các bài kiểm tra tự động đã không chạy và báo cáo đang xem xét một bản sao cũ của dữ liệu kiểm tra. Có lẽ ai đó không làm đúng công việc của họ. Kiểm tra bộ phận QA là một điều hợp lý để làm.

Rõ ràng nhược điểm là "lỗi kiểm tra" có thể thông qua bộ phận QA và vào thành phẩm. Trong ngành sản xuất đôi khi có những trường hợp một phần xấu được biết đến, đôi khi được gọi là "Thỏ đỏ" được đưa vào quy trình (thường là bởi một người nào đó từ QA) và họ xem phần đó trải qua quá trình và đo lường thời gian cần thiết tìm phần và loại bỏ nó Thông thường phần này được sơn màu đỏ tươi (hoặc màu cam) để có thể dễ dàng theo dõi. Vì ai đó đang xem phần trải qua quá trình trong quá trình thử nghiệm này, nên cơ hội đưa nó vào sản phẩm cuối cùng thực tế là không. Tất nhiên, có những câu chuyện về ngày tận thế của một người ném một phần xấu đã biết vào quy trình để "xem hệ thống có thể tìm thấy nó không",

Thành thật mà nói, tôi gọi hành vi này một cách trắng trợn là phi đạo đức và không thực tế. Thủ tướng đang cần một số đào tạo lại nghiêm túc, nếu không chấm dứt.

• Nó cho thấy sự thiếu hiểu biết cơ bản về khái niệm đảm bảo chất lượng . Người thử nghiệm không nên nghĩ như nhà phát triển: họ nên nghĩ như người dùng cuối. Toàn bộ lý do để có các nhóm QA là các nhà phát triển vốn đã quá gần với mã; QA được cho là duy trì đủ khoảng cách từ mã mà họ có thể nắm bắt được những gì các nhà phát triển bỏ lỡ.
• Nó lãng phí nỗ lực QA . Giả sử rằng những lỗi này không tầm thường - hãy xem bên dưới khi chúng - điều đó có nghĩa là QA đang dành thời gian và nguồn lực để điều tra những điều đã biết, khi họ có thể dành nỗ lực đó để tìm kiếm những gì chưa biết.
• Nó lãng phí nỗ lực của nhà phát triển . Để những người QA bắt được những lỗi không tầm thường này, trước tiên các nhà phát triển phải viết chúng. Điều này đòi hỏi nỗ lực hơn nữa, dành không chỉ mã hóa các lỗi, mà còn xem xét các yêu cầu và thiết kế phần mềm.
• Nó đặt sản xuất vào rủi ro không cần thiết . Chỉ là vấn đề thời gian trước khi những thay đổi không được hợp nhất.
• Nếu nó không làm như trên, thì thật vô nghĩa . Nếu tất cả các lỗi đã biết là tầm thường, thì chúng sẽ không bắt được những người lao động không đạt tiêu chuẩn: họ sẽ chỉ bắt những người không làm việc gì cả. Có nhiều cách tốt hơn để làm điều đó.
• Nó đầu độc môi trường làm việc . Người kiểm tra QA của bạn là các chuyên gia. Họ nên được tin tưởng là chuyên nghiệp cho đến khi có lý do thực sự để nghi ngờ khác. Khi có là lý do gì để nghi ngờ khác, cần có một cuộc điều tra thích hợp thay vì những trò chơi tâm trí. Bất cứ điều gì khác giết chết tinh thần.

Nghiêm túc. Ngay cả khi sự hoang tưởng của Thủ tướng hóa ra là có cơ sở trong trường hợp cụ thể này, đây không phải là người có bất kỳ người thử nghiệm quản lý kinh doanh nào.

Cá nhân, tôi cảm thấy không thoải mái với phương pháp này.

Điều chính mà tôi quan tâm là tính thực tế của việc chèn các lỗi cố ý . Điều này đối với tôi dường như khó thực hiện theo bất kỳ cách nào có thể dự đoán được.

Bất kỳ thay đổi mã (cố ý hoặc cách khác) có nguy cơ có tác dụng phụ. Những tác dụng phụ này có thể được tiết lộ trong quá trình thử nghiệm nhưng có thể không rõ ràng (ngay cả với nhà phát triển đã trồng lỗi) nguyên nhân gốc rễ là gì. Nó không cảm thấy "an toàn", nếu bạn hiểu ý tôi (tôi đang nói từ ruột của tôi ở đây).

Ngoài ra, người kiểm tra sẽ lãng phí rất nhiều thời gian kiểm tra mã mà sẽ không thực sự được phát hành. Một khi các lỗi cố ý được loại bỏ, theo ý kiến ​​của tôi, việc kiểm tra lại hoàn toàn nên được thực hiện. Đó là toàn bộ quan điểm của thử nghiệm. Một cái gì đó thay đổi, bất cứ điều gì , và bạn kiểm tra lại tất cả mọi thứ . Ok tôi biết điều đó không bao giờ xảy ra trong thực tế, nhưng đó là tất cả những gì về kiểm tra hồi quy.

Vì vậy, về tổng thể, không thuyết phục.

Mặt khác, chúng tôi có xu hướng để khách hàng xác minh công việc của các nhóm QA, điều này có thể không lý tưởng. Đó là một vòng phản hồi rất mạnh mặc dù.

Đó là một ý tưởng tồi cho tất cả các lý do đã được đưa ra, nhưng seed buging là một công cụ hữu ích cho một mục đích khác. Bạn có thể sử dụng nó để có được một số liệu sơ bộ về hiệu quả của quy trình QA.

Trong trường hợp đơn giản nhất, giả sử bạn gieo 100 lỗi và chúng là đại diện cho toàn bộ lỗi thực sự (tôi biết, không có khả năng, nhưng tôi đang đơn giản hóa). Bạn không nói với QA bạn đang làm điều này để tránh làm hỏng thử nghiệm. Vào cuối quá trình QA, giả sử họ đã tìm thấy 60 trong số 100 lỗi được gieo hạt (và các lỗi thực sự khác). Bây giờ bạn biết QA đang tìm 60% lỗi.

Bạn có thể mở rộng điều này hơn nữa bằng cách đếm số lượng lỗi thực sự QA tìm thấy và áp dụng tỷ lệ lỗi giả. Trong ví dụ của chúng tôi, nếu QA tìm thấy 200 lỗi thực sự thì bạn có thể kết luận họ chỉ tìm thấy 60% trong số đó, vì vậy vẫn còn 133.

Tất nhiên, đây chỉ là một ước tính rộng với các thanh lỗi lớn. Viết thực tế, lỗi đại diện là khó. Các lỗi bạn viết có thể dễ dàng tìm thấy QA hơn vì các nhà phát triển được đào tạo để không viết các lỗi. Có thể tốt hơn để mô phỏng một loại lỗi như lỗi do lỗi, lỗi Unicode, lỗi tràn bộ đệm, v.v.

Điều này nên được áp dụng cho toàn bộ quy trình QA , bao gồm thử nghiệm đơn vị nhà phát triển, tích hợp liên tục và, nếu có, một nhóm QA chuyên dụng.

Đây là một số liệu và không nên bị tấn công như một công cụ tạo động lực quản lý.

Ý kiến ​​tồi.

Đây là cách tiếp cận nhị phân, hợp lý mà các nhà phát triển thường mang lại, nhưng nó đang làm mất hứng thú cho các QE. Nó chỉ đơn giản là thể hiện sự thiếu tin tưởng. Các QE thường được đặt trong các tình huống này mà không có nhiều thông tin từ họ và họ cho rằng họ ổn với điều đó và đó không phải là nơi để họ đề xuất khác.

Kiểu suy nghĩ này kết hợp với QEs chỉ là người kiểm tra thủ công và không có động lực để hiểu mã thực tế đang thử nghiệm.

Tôi là một QE cấp cao và đây là một vấn đề quen thuộc trong hầu hết các tổ chức tôi đã làm việc.

Tôi muốn nói ý kiến ​​tồi.

Một: Các lập trình viên sẽ dành thời gian để đưa các lỗi cố ý vào mã và một số nỗ lực để lưu phiên bản tốt. Mặc dù người kiểm tra có lẽ nên kiểm tra tất cả mọi thứ, bao gồm các tính năng có lỗi đã trồng, nhưng khi tìm thấy, họ có thể phải quay lại và chạy lại kiểm tra đó để xác minh rằng đây thực sự là một lỗi (và không phải là người kiểm tra đã nhầm lẫn một cách nào đó). Ở mức tối thiểu, những người thử nghiệm sẽ dành thời gian để viết lên những con bọ đã trồng. Sau đó, các lập trình viên phải dành thời gian để sửa lỗi mà họ trồng. Đây là rất nhiều nỗ lực có thể được dành để cố gắng viết mã tốt và viết ra các lỗi thực sự.

Hai: Nó gửi một thông điệp rõ ràng đến những người kiểm tra rằng các lập trình viên và / hoặc quản lý nghĩ rằng họ không làm việc của họ và phải được đối xử như những đứa trẻ. Tôi không thể tưởng tượng rằng điều này là tốt cho tinh thần. Là một lập trình viên, nếu tôi được cung cấp các thông số mơ hồ hoặc mâu thuẫn cho một chương trình và phải dành rất nhiều thời gian để làm rõ chúng, và sau khi lãng phí hàng giờ hoặc nhiều ngày, ông chủ của tôi nói với tôi, "Ồ, vâng, tôi đã cố tình đưa các tuyên bố mâu thuẫn vào thông số kỹ thuật chỉ để đảm bảo rằng bạn đã thực sự đọc chúng ", tôi nghĩ rằng tôi sẽ thực sự khó chịu. Nếu điều đó xảy ra thường xuyên, điều đó có thể đủ để khiến tôi tìm kiếm một công việc khác.

Trong cuộc sống thực, tất cả trừ những thay đổi mã tầm thường nhất SILL có lỗi. Tôi chưa bao giờ gặp vấn đề với những người thử nghiệm trở nên tự mãn vì mã dự thảo đầu tiên họ được đưa ra thường rất hoàn hảo 100%. Tôi đã phải đối phó với những người kiểm tra lười biếng, những người không làm một công việc đầy đủ, nhưng họ không có được điều đó bởi vì các lập trình viên quá hoàn hảo. Người thử nghiệm tốt nhất tôi từng làm việc cùng đã từng nói với tôi rằng để phát hành phần mềm mới, anh ta đặt cho mình một mục tiêu cá nhân để tìm ra 100 lỗi. Được rồi, liệu 100 có phải là con số thực tế hay không phụ thuộc vào mức độ lớn của sản phẩm và mức độ thay đổi của nó, nhưng trong trường hợp của chúng tôi, anh ấy hầu như luôn xoay sở để đáp ứng mục tiêu đó. Đôi khi anh ta phải kéo dài mọi thứ, như gọi một từ sai chính tả trong tin nhắn là "lỗi", nhưng này, nó đã phải được sửa.

Kịch bản bài đăng: Nếu bạn làm điều này, tôi cá rằng sớm muộn các lập trình viên sẽ cố tình tạo ra một lỗi, người kiểm tra không tìm thấy lỗi cụ thể đó và các lập trình viên quên đặt lại mã tốt. Vì vậy, bây giờ một lỗi cố ý trồng được chuyển đến khách hàng.

Tôi thực sự không nghĩ rằng đây là một ý tưởng tồi . Có rất nhiều điều mà tôi sẽ suy đoán làm việc tốt hơn:

1. Làm cho QA chịu trách nhiệm về chất lượng bằng mọi cách bạn có thể. Ví dụ bằng cách hỗ trợ trách nhiệm của họ cũng. Điều này sẽ tăng động lực của họ để đảm bảo các sản phẩm được vận chuyển có chất lượng cao hơn. Sau đó, bạn luôn mất ít nỗ lực hơn để phát hiện ra sự bất cập (lỗi, rõ ràng là thiếu tính năng, hành vi phản trực giác) sau đó để cố gắng hiểu những gì người dùng khó chịu của bạn đang cố gắng giải thích. Và đặt một số trách nhiệm đó ngay cả lên các nhà phát triển có thể tăng động lực của họ để giúp QA thực hiện công việc của họ tốt nhất có thể.

2. Có nhiều đội QA, có thể cạnh tranh. Bạn cần phải tìm một số liệu hợp lý của khóa học. Chắc chắn không chỉ là số lượng các vấn đề. Bao thanh toán về mức độ nghiêm trọng của khuyết tật hoặc giá trị kinh doanh (như được xác định bởi các bên liên quan) của các cải tiến được đề xuất sẽ giúp ích.

Thật khó để biết liệu QA có "đủ tốt" hay không. Về lâu dài sẽ dễ dàng hơn và thậm chí tốt hơn để tìm cách cho QA "không ngừng cải thiện".

Tuy nhiên, vẫn có một vấn đề cần lưu ý nếu bạn giới thiệu các lỗi cố ý: Làm thế nào để bạn biết mã "chính xác" thực sự là chính xác ngay từ đầu? Sau QA thứ 2, bạn loại bỏ tất cả các lỗi cố ý chưa được phát hiện. Không có cách nào để biết rằng bạn không chỉ thay thế chúng bằng mã bị hỏng theo một cách khác hoặc bạn không cho phép hành vi bị hỏng mà không thể truy cập trước đó (ví dụ phóng đại: một số hộp thoại không mở do lỗi cố ý, nhưng bản thân hộp thoại bị hỏng - bạn không nên tìm hiểu vì người kiểm tra đã không thấy nó).

Như những người khác đã nói, các nhà phát triển không nên cố tình thêm các lỗi trong phần mềm, nhưng đó là một chiến lược hợp pháp để bộ kiểm tra của bạn thêm các lỗi vào phần mềm như một phần của quy trình kiểm tra.

Nó được gọi là thử nghiệm đột biến . Ý tưởng là sử dụng phần mềm để tự động hóa việc tạo ra những thay đổi nhỏ trong mã nguồn (được gọi là đột biến). Các thay đổi được thiết kế để tạo hành vi khác nhau, ví dụ: chúng ta có thể thay đổi

if x < 10:
    print "X is small!"

vào

# we flipped the inequality operator
if x > 10:
    print "X is small!"

và một bài kiểm tra đơn vị tốt sẽ phát hiện ra rằng đoạn mã đột biến không còn hoạt động như mong đợi và giết chết người đột biến . Khi mã ban đầu vượt qua bài kiểm tra và tất cả các đột biến (không xảy ra tương đương về chức năng) đều thất bại trong bài kiểm tra, thì bạn biết rằng mã của bạn và các bài kiểm tra của bạn rất mạnh .

Tôi thích ý tưởng. Có phải Tướng Patton đã nói: "Càng đổ mồ hôi trong hòa bình, bạn càng ít chảy máu trong chiến tranh".

Đặt lỗi cố ý "lãng phí thời gian" của người kiểm tra. Nhưng điều đó cũng làm cho họ làm việc chăm chỉ hơn, có nghĩa là họ cũng sẽ làm tốt hơn việc tìm kiếm các lỗi không chủ ý. (Và bạn có một bản sao của "bản gốc" để bạn không phải sống với những gì bạn đã làm.)

Tìm thêm các lỗi vô ý có thể sẽ giúp bạn tiết kiệm được nhiều đau buồn hơn về lâu dài rằng chi phí xử lý các lỗi cố ý.

Thêm vào đó, bạn có thể có được một ý tưởng về những người thử nghiệm của bạn tốt như thế nào, bản thân nó không phải là một lợi ích nhỏ.

Không có cơ sở cho một phần thưởng hoặc hình phạt trên giá trị riêng của nó, nhưng về kết quả của hành vi bạn đang nhắm mục tiêu. Và đôi khi có những hậu quả không lường trước được. Là mục tiêu để giữ cho nhóm QA không bị trì hoãn hoặc làm cho một số người quản lý cảm thấy như anh ta thực sự đóng góp một cái gì đó mà không nhận ra rằng anh ta đang cản trở.

Kết quả tích cực - Nhóm QA làm việc chăm chỉ hơn để tìm lỗi. Ai biết được, có lẽ họ xem đây là một thử thách. Đây là một trò chơi thân thiện. Hay họ chỉ đang làm vì họ đang bị theo dõi (Hiệu ứng Hawthorne?).

Kết quả tiêu cực - Dù sao họ cũng không thể làm việc chăm chỉ hơn và tìm ra lỗi. QA coi điều này là nhỏ nhặt và bất lợi. Vì vậy, bây giờ, họ đi vào ổ đĩa tìm lỗi siêu tốc và trả về tất cả các loại vấn đề nhỏ nhặt kén chọn. Phông chữ đó không hiển thị đúng khi tôi chụp ảnh màn hình và chuyển đổi nó thành pdf và xem nó ở mức 500%.

Không có tác động - âm thanh với tôi như thế này không có gì khác biệt, vậy tại sao phải bận tâm? Bạn chỉ có nguy cơ lãng phí thời gian và chọc tức mọi người.

Tất cả chúng ta có thể đồng ý rằng điều này sẽ không hoạt động 90% thời gian. Điều đó không làm được gì nhiều cho 10% còn lại. Kiểm tra mọi thứ cho chính mình. Khách hàng có hài lòng hơn với một bản phát hành có lỗi mã cố ý không? Nó có ảnh hưởng đến tinh thần và năng suất của người lao động trong các lĩnh vực khác không? Tăng doanh thu? Bạn nói họ.

Đến từ một thế giới nơi các nhà phát triển dự kiến ​​sẽ tự viết và chạy thử nghiệm, silo "thử nghiệm" "QA" này mà bạn đang đề cập đến sự sợ hãi và làm tôi bối rối, vì vậy tôi sẽ cố gắng trả lời từ quan điểm này. Bên cạnh đó, các kỹ sư QA có trình độ, theo quan điểm của tôi, (như được mô tả tốt trong câu trả lời của @ SparK), nên tập trung vào các vấn đề lớn hơn để đảm bảo rằng phần mềm đáp ứng đầy đủ các câu chuyện của người dùng và có "chất lượng" tổng thể (liên quan đến tên miền mà phần mềm được dành cho), thay vì săn tìm lỗi.

Điều thu hút tôi ở đây là @ JamesMcleod đề cập đến "tiêm khiếm khuyết" trong các bình luận cho câu hỏi. Tôi thực sự nghĩ rằng việc các nhà phát triển nghĩ làm thế nào họ có thể tiêm các lỗi vào hệ thống là một ý tưởng tuyệt vời để nhắm mục tiêu vào khái niệm phòng thủ theo chiều sâu. Không một lỗi nào là đủ để hạ gục toàn bộ hệ thống theo cách không được kiểm soát (không có ghi nhật ký rõ ràng có thể hành động), gây ra bất kỳ tham nhũng dữ liệu nào hoặc tự nó lộ ra lỗ hổng bảo mật.

Việc các nhà phát triển của từng thành phần tạo ra các khiếm khuyết có chủ ý, xử lý các thành phần khác và nói chung có một tư duy bất lợi hơn về phần mềm của họ có thể giúp cải thiện sự mạnh mẽ của phần mềm. Ngay cả lợi ích trước mắt cũng có thể là đáng kể - tôi yêu cầu rằng trong mỗi lần tiêm một loại khiếm khuyết mới như vậy (chưa được kiểm tra), nhà phát triển sẽ ngay lập tức bao phủ nó bằng một thử nghiệm mới, sẽ được đặt một lá cờ sẽ được gắn cờ cho phép lỗi tồn tại trong cơ sở mã không bị xáo trộn trong một thời gian ngắn và sau đó bật trước khi giao hàng (và loại bỏ lỗi), để biến thành một thử nghiệm thông thường sẽ làm cho bộ kiểm tra toàn diện hơn.

Một tùy chọn liên quan là việc sử dụng cờ tính năng để cố ý tắt các tính năng trong các thành phần cụ thể để kiểm tra cách các thành phần khác xử lý vấn đề đó. Tôi cũng rất muốn giới thiệu đọc cuốn sách / bài báo miễn phí "Học hỏi từ những người phản hồi đầu tiên: Khi hệ thống của bạn phải làm việc" mô tả thử nghiệm rộng rãi như vậy về cơ sở hạ tầng phần mềm sẽ được nhóm Obama sử dụng cho cuộc bầu cử năm 2012.

Như những người khác đã nói, công việc của QA không chỉ là tìm lỗi. Tôi sẽ đi xa hơn và nói rằng đó không phải là công việc của họ, về mặt kỹ thuật. Các nhà phát triển phải có trách nhiệm giữ cho mã của họ không có lỗi. Các bộ kiểm thử nên được chạy trước khi mã mới thậm chí được cam kết và nếu các bộ kiểm thử bị lỗi, thì nó sẽ không bao giờ được đưa đến QA ngay từ đầu. Giới thiệu lỗi cố ý có nghĩa là bạn chắc chắn không thể vượt qua các bộ thử nghiệm của mình, vậy tại sao mã của bạn lại chuyển sang QA?

Công việc của QA là xác nhận ứng dụng dựa trên các câu chuyện của người dùng mà nó thực hiện. Họ nên kiểm tra luồng, giao diện người dùng, v.v. và đảm bảo rằng người dùng có thể làm mọi thứ mà người dùng có thể làm, theo cách dễ sử dụng và dễ tiếp cận nhất có thể. Trong khi làm điều này, tất nhiên, họ có thể vấp phải lỗi, nhưng đó là tác dụng phụ của những gì họ làm, không phải những gì họ làm. Hãy nhớ QA có nghĩa là Đảm bảo chất lượng, không phải Đảm bảo không có lỗi.

Điều này không nhất thiết là điên như âm thanh. Nó khá phụ thuộc vào động lực của bạn. Nếu bạn đang tìm kiếm một cây gậy để đánh bại nhóm thử nghiệm của bạn với, rõ rằng sẽ được điên. Mặt khác, một trong những điều khó khăn nhất trong phát triển phần mềm là để biết cách tiếp cận thử nghiệm của bạn hiệu quả như thế nào.

Vì vậy, nếu bạn cấu trúc nó đúng cách, bạn có thể sử dụng kỹ thuật này để ước tính có bao nhiêu lỗi không tồn tại trong sản phẩm bạn sắp giao. Vì vậy, hãy tưởng tượng rằng bạn đã gieo mầm 100 lỗi một cách giả tạo trong bản dựng thử nghiệm của mình và người kiểm tra tìm thấy 50 lỗi. Sau đó, bạn có thể suy luận rằng có một khả năng nhất định rằng nếu họ cũng tìm thấy 50 lỗi chưa được phát hiện, có lẽ còn 50 để tìm.

Tất nhiên, điều này có nhiều vấn đề. Bạn có thể quyết định có nên giao hàng dựa trên những thống kê này hay không, nhưng trong cuộc sống thực, bạn có thể tìm thấy một vấn đề rất khó chịu, hoặc một ngàn sự khó chịu nhỏ.

Tuy nhiên - kiến ​​thức là sức mạnh và không có kỹ thuật này, bạn thậm chí còn ít ý tưởng về chất lượng của cơ sở mã của mình. Nếu bạn có thể thực hiện nó một cách tôn trọng và vì những lý do đúng đắn, tôi sẽ nói "Tại sao không?"

Một điều chưa ai khác đề cập đến: thử nghiệm đột biến .

Đây là nơi một công cụ tự động lấy mã nguồn của bạn và cố tình chèn các lỗi vào nó. (Ví dụ: xóa câu lệnh được chọn ngẫu nhiên, thay đổi AND thành OR hoặc bất cứ điều gì.) Sau đó, nó chạy bộ kiểm tra đầy đủ của bạn và kiểm tra xem các bài kiểm tra có vượt qua hay không.

Nếu tất cả các bài kiểm tra vượt qua, thì có hai khả năng:

• Thứ đã được thay đổi không làm gì cả. Nói cách khác, bạn có mã chết.
• Thay đổi đã giới thiệu một lỗi mà bộ kiểm tra của bạn không bắt được. Bạn cần nhiều bài kiểm tra hơn.

Lưu ý rằng, không giống như đề xuất của bạn, mọi thứ tôi đã mô tả ở trên là tự động . Bạn không lãng phí thời gian của các nhà phát triển để chèn các lỗi vô nghĩa bằng tay. Và bạn không lãng phí thời gian của người kiểm tra để tìm lỗi đã biết. Điều duy nhất bạn đang sử dụng là thời gian máy, rẻ hơn nhiều. (Máy móc không cảm thấy nhàm chán khi thực hiện cùng một bài kiểm tra 20.000 lần. Con người ngừng quan tâm sau một thời gian!)

Tôi muốn đề xuất rằng thử nghiệm đột biến tự động là một cách tiếp cận tốt hơn nhiều so với kịch bản thủ công mà bạn đang nói đến.

Lưu ý rằng nếu bạn yêu cầu nhà phát triển chèn thủ công các lỗi, loại lỗi bạn gặp có lẽ không phải là đại diện cho loại lỗi vô ý mà con người có thể mắc phải. (Ví dụ: nếu bạn không nhận ra có một điều kiện chủng tộc có thể xảy ra, thì bạn cũng không thể chèn một điều có chủ ý.) Liệu một công cụ tự động có thể trở nên khách quan hơn hay không, tất nhiên là có thể nhìn thấy

Mặc dù đó là một ý tưởng tồi nói chung (các câu trả lời khác giải thích hoàn hảo tại sao), có một vài tình huống đặc biệt khi cố tình tiêm bọ vào mã sản xuất một cách có kiểm soát, tạm thời có thể có ý nghĩa.

Khi bạn cấu trúc lại mã kiểm tra - và bạn nên, mã kiểm tra đáng được chú ý đến từng chi tiết như mã sản xuất - bạn có thể muốn biết liệu mã kiểm tra có còn tìm thấy các lỗi cần tìm hay không.

Sau đó, bạn có thể cố tình phá mã sản xuất để xác minh xem các thử nghiệm có còn hoạt động không.

Có nhiều cấp độ mà điều này là có thể:

• Một nhà phát triển vừa tái cấu trúc một số thử nghiệm đơn vị có thể phá vỡ mã sản xuất để xác minh rằng thử nghiệm đơn vị vẫn tìm thấy những gì nó cần tìm.
• Một người kiểm tra vừa tái cấu trúc một số thử nghiệm chấp nhận có thể phá vỡ mã sản xuất để xác minh rằng thử nghiệm chấp nhận vẫn xác minh những gì cần xác minh.
• Nếu giao diện ổn định và đủ mạnh (tức là dựa trên giao thức), công ty có thể muốn giữ một bộ các phiên bản sản phẩm bị lỗi đã biết và chạy thử nghiệm để kiểm tra lại chúng để kiểm tra hồi quy.

Cho dù những điều này có ý nghĩa phụ thuộc. Nếu tôi là nhà phát triển và tôi chỉ mất một phút để tiêm lỗi, kiểm tra thử nghiệm đơn vị, xóa lỗi - thì tại sao không. Nhưng tôi nên có trình soạn thảo, chu trình và hệ thống kiểm soát phiên bản của mình dưới sự kiểm soát tốt đến mức tôi sẽ không vô tình cam kết / phân phối / đăng ký / đẩy lỗi. Cùng đi cho người kiểm tra và kiểm tra chấp nhận.

Liệu nó có ý nghĩa đối với một tổ chức để giữ các bộ phiên bản sản phẩm bị lỗi đã biết và kiểm tra hồi quy hay không, thử nghiệm phụ thuộc. Đối với một cửa hàng trực tuyến, tôi sẽ không. Đối với ô tô nhúng, nhúng hàng không vũ trụ, thẻ ngân hàng hoặc thẻ TV trả tiền tôi sẽ làm.

Bao nhiêu nỗ lực này phụ thuộc mạnh mẽ vào mức độ phân tách các thử nghiệm từ mã sản xuất. Các thử nghiệm được tách rời càng nhiều từ mã sản xuất, thì càng ít nỗ lực để làm điều này, các thử nghiệm càng gắn kết với mã sản xuất, càng nhiều nỗ lực.

Lý do đơn giản là thế này: Khi các thử nghiệm và mã sản xuất của bạn gắn kết, việc thay đổi mã sản xuất đòi hỏi phải thay đổi các thử nghiệm thường xuyên và điều đó sẽ phá vỡ sự phụ thuộc giữa các thử nghiệm và các mẫu sản xuất bị lỗi. Sau đó, bạn cũng sẽ phải duy trì các mẫu sản xuất bị lỗi. Trong những trường hợp hiếm hoi thậm chí có thể đáng để nỗ lực, và chế giễu cũng như sử dụng thông minh hệ thống kiểm soát phiên bản có thể làm giảm đáng kể nỗ lực, nhưng nó đòi hỏi vượt xa các nhà phát triển lành nghề.

Khái niệm cố ý tiêm lỗi trong mã sản xuất được gọi là phá hoại , lỗi tiêm được gọi là saboteur .

Một người kiểm tra không lấy mã được kiểm tra trực tiếp từ kho lưu trữ đang làm sai. (1)

Một nhà phát triển đang kiểm tra mã đã biết bị lỗi vào kho lưu trữ đang làm sai. (2)

Vì vậy, ở giai đoạn này, không có cách nào để chương trình này hoạt động mà không có một hoặc cả hai bên vi phạm các tiền đề rất cơ bản về cách phát triển và thử nghiệm nên được thực hiện.

(1) Bởi vì bạn cần ghi lại phiên bản nào bạn đã thử nghiệm. Phiên bản được gắn thẻ băm Git hoặc số sửa đổi SVN là thứ bạn có thể kiểm tra, "mã Joe đưa cho tôi" thì không.

(2) Bởi vì bạn không, bên ngoài trình điều khiển thử nghiệm đang mong đợi thất bại.

Đây là một nỗ lực với một lý do "sân thang máy" ngắn nhất có thể, có ý nghĩa ngay lập tức đối với các nhà phát triển, người thử nghiệm và quản lý.

Tôi khuyên bạn không nên cố tình tiêm lỗi vào MỌI bản dựng mà bạn gửi cho QA.

Thỉnh thoảng, bạn có thể nói mỗi năm một lần, thực hiện một "kiểm toán QA" bí mật. Lấy một cơ sở mã "đã thử nghiệm và hoạt động" và càng nhiều tính năng mới nhỏ từ danh sách Todo của bạn càng tốt. Thực hiện chúng "chậm hơn một chút" so với bạn thường làm. Hãy nghĩ về các trường hợp cạnh, viết chúng ra, nhưng đừng sửa mã của bạn để đưa chúng vào tài khoản. Gửi nó cho QA.

Nếu họ tìm thấy nhiều lỗi trường hợp không hoạt động hơn bạn đã viết, chắc chắn đó không phải là QA của bạn cần giám sát ... ;-)