Tại sao nên để / không cho phép các nhà phát triển kiểm tra công việc của chính họ

Tôi muốn thu thập một số lý lẽ về lý do tại sao để nhà phát triển thử nghiệm công việc của chính họ như là bước cuối cùng trước khi sản phẩm đi vào sản xuất là một ý tưởng tồi, bởi vì thật không may, nơi làm việc của tôi đôi khi làm điều này (lần cuối cùng xuất hiện , cuộc tranh luận sôi nổi với hầu hết mọi người quá bận rộn với những thứ khác và không có thời gian để làm cho một người khác làm quen với phần đó của chương trình - đó là phần mềm rất chuyên dụng).

Có kế hoạch kiểm tra trong trường hợp này (mặc dù không phải lúc nào cũng vậy), nhưng tôi rất ủng hộ việc tạo ra một người không thực hiện các thay đổi được thử nghiệm thực sự đang thực hiện thử nghiệm cuối cùng. Vì vậy, tôi đang hỏi liệu bạn có thể cung cấp cho tôi một danh sách các lập luận tốt và vững chắc mà tôi có thể đưa ra trong lần tiếp theo khi thảo luận này không. Hoặc để cung cấp các đối số phản đối, trong trường hợp bạn nghĩ rằng điều này là hoàn toàn tốt, đặc biệt là khi có các trường hợp thử nghiệm chính thức để kiểm tra.

Như những người khác (và chính bạn) đã lưu ý, các nhà phát triển nên kiểm tra mã của riêng họ. Tuy nhiên, sau đó, bất kỳ sản phẩm không cần thiết nào cũng cần được kiểm tra bởi người độc lập (bộ phận QA và / hoặc chính khách hàng).

Các nhà phát triển thường làm việc với tư duy của nhà phát triển về "làm thế nào để làm việc này?" . Một người thử nghiệm tốt đang suy nghĩ về "làm thế nào để phá vỡ điều này?" - một suy nghĩ rất khác. Kiểm thử đơn vị và TDD không dạy các nhà phát triển thay đổi mũ ở một mức độ nào đó, nhưng bạn không nên dựa vào nó. Hơn nữa, như những người khác đã lưu ý, luôn có khả năng hiểu sai các yêu cầu. Do đó, các thử nghiệm chấp nhận cuối cùng nên được tiến hành bởi một người nào đó càng gần khách hàng càng tốt .

Nhà phát triển biết cách mã của họ hoạt động và sẽ rơi vào thói quen kiểm tra mã của họ theo kiến ​​thức này.

Nhà phát triển sẽ gặp khó khăn trong việc loại bỏ chính họ khỏi suy nghĩ về 'cách thức hoạt động' trái ngược với 'cách thức hoạt động'.

Do đó, tốt hơn là nhờ ai đó có mức độ khách quan cao để kiểm tra chương trình, tức là QA hoặc Kỹ sư kiểm tra

Kiểm thử nghiệm để phá vỡ, đơn giản. Kiểu thiên vị này là cần thiết để thực sự tìm ra các điểm dừng chương trình.

Các nhà phát triển PHẢI kiểm tra công việc của họ. Đó là một trách nhiệm ngụ ý.

Tôi cho rằng bạn không có một nhóm chuyên làm các bài kiểm tra dựa trên tuyên bố của bạn. Tuy nhiên, việc có một nhóm chuyên dụng để thử nghiệm sẽ thực sự hữu ích khi các nhà phát triển có xu hướng kiểm tra mã của họ theo cách họ mã hóa nó. Điều đó không có nghĩa là một khi bạn có một nhóm đảm bảo chất lượng thuộc loại nào đó, bạn đã có thể đưa ra thử nghiệm như một trách nhiệm của các nhà phát triển.

Các nhà phát triển thường sử dụng lưới có lỗ lớn để bắt bọ. Kết quả là các lỗi nhỏ hơn thoát ra.

Bởi vì các nhà phát triển không giỏi trong việc cố gắng phá vỡ mã của riêng họ. Tâm trí của họ chỉ đơn giản là đi theo đúng đường dẫn nhập dữ liệu và tương tác với ứng dụng. Nhiều lỗi là kết quả của việc tương tác với hệ thống như một chàng trai bình thường . Nhà phát triển không phải là người dùng bình thường. Họ là những người dùng chuyên nghiệp.

Có một vài lý do tốt để có một nhóm thử nghiệm chuyên dụng. Đầu tiên, như đã đề cập ở trên, các nhà phát triển rất giỏi trong việc kiểm tra mã của họ hoạt động, nhưng không phá vỡ nó.

Ngoài ra, như bạn nói, một nhà phát triển biết những gì họ đã viết, nhưng một nhóm thử nghiệm biết những gì nên được viết. Đôi khi, hai khái niệm này không khớp với nhau. Một trong những công việc của nhóm thử nghiệm là đảm bảo rằng phần mềm đáp ứng các yêu cầu. Trong nhiều trường hợp, một nhà phát triển chỉ biết rất rõ một vài phần của hệ thống nhưng nhóm QA biết toàn bộ.

Điều này dẫn đến lý do tiếp theo, các nhóm thử nghiệm thực hiện kiểm tra tích hợp đầy đủ. Đoạn mã mà bạn vừa viết có thể hoạt động tốt, nhưng có thể phá vỡ các chức năng khác mà bạn không biết.

Đã làm việc với một nhóm QA và không có, tôi có thể nói với bạn rằng tôi đánh giá cao 100% công việc họ làm và sẽ nói rằng họ là một phần có giá trị của nhóm phần mềm. Khi bạn có nhóm QA, việc phát hành mã của bạn trở nên dễ dàng hơn rất nhiều, vì bạn biết rằng nó đã được kiểm tra kỹ lưỡng và điều đó có nghĩa là bạn sẽ nhận được ít hơn 3 giờ gọi.

Các nhà phát triển nên đơn vị kiểm tra mã riêng của họ.

Những người kiểm tra độc lập không chỉ kiểm tra để phá vỡ, họ kiểm tra các giả định không được xác định và không xác định mà các nhà phát triển đã thực hiện trong khi mã hóa.

Tôi hy vọng nhà phát triển sẽ thực hiện một số thử nghiệm ban đầu trước khi họ cam kết bất kỳ thay đổi nào và tự hài lòng rằng mã hoạt động. Sau đó, tôi sẽ mong đợi nhà phát triển đưa vào các trường hợp thử nghiệm bất kỳ kiến ​​thức 'hộp trắng' cụ thể nào họ có. Ví dụ, chi tiết bất kỳ khu vực nào khác của mã có thể đã bị ảnh hưởng.

Sự phản đối chính đối với các nhà phát triển kiểm tra mã riêng của họ là bạn chỉ đang kiểm tra một quan điểm. Các nhà phát triển đã đọc các đặc điểm kỹ thuật và giải thích nó. Hy vọng rằng đặc điểm kỹ thuật là rõ ràng, đầy đủ và rõ ràng, nhưng điều này không phải lúc nào cũng đúng. Các nhà phát triển có thể đã hiểu nhầm một phần của đặc điểm kỹ thuật. Nếu họ kiểm tra mã của riêng họ thì điều này sẽ không bị bắt vì họ sẽ thấy hàm hoạt động như họ mong đợi.

Những người khác nhau cũng sẽ có xu hướng sử dụng một sản phẩm theo cách khác nhau và kết quả là có các tuyến khác nhau thông qua mã. Một nhà phát triển sẽ đảm bảo rằng mã hoạt động cho họ, nhưng có thể không xem xét trường hợp cạnh mà người kiểm tra khác có thể tìm thấy.

Các nhà phát triển nên kiểm tra công việc riêng của họ. Để các nhà phát triển đẩy công việc chưa được kiểm tra vào nhóm QA hoặc các đồng nghiệp phát triển của họ là một ý tưởng thực sự tồi tệ. Nó lãng phí thời gian của các nhà phát triển và người thử nghiệm như nhau, và phá hỏng các mối quan hệ.

Tuy nhiên, điều đó không phải lúc nào cũng đủ. Các nhà phát triển có khả năng đi theo một con đường hạnh phúc thông qua hệ thống, hoặc bị mù với một số đặc điểm riêng mà họ đã tiếp xúc nhiều lần trong suốt quá trình phát triển.

Một điểm khác là có thể có một số lớp giao tiếp giữa đặc tả và triển khai. Điều này có thể dẫn đến hiệu ứng Whispers Trung Quốc trên bản triển khai cuối cùng. Nó là tốt nhất nếu bất cứ ai xác định yêu cầu hoặc báo cáo lỗi kiểm tra rằng nó hoạt động theo cách họ muốn.

Là một nhà phát triển, bạn chịu trách nhiệm về mã của riêng mình, bạn nên kiểm tra nó. Does the feature work as expected?Nếu câu trả lời là có, bạn đã hoàn thành.

Tại sao bạn không nên làm test-case?

1. Bạn chủ quan , vì tìm thấy lỗi được viết bởi bạn (hoặc đồng nghiệp của bạn).
2. Bạn quá tốn kém cho công ty để chạy thử nghiệm trường hợp. (Tôi hi vọng).

Thông thường, trong hầu hết các trường hợp, các nhà phát triển sẽ không phải là những người sử dụng mã ngoại trừ trong một số trường hợp chuyên biệt nhất định. Vì vậy, bước thử nghiệm cuối cùng trước khi quảng bá cho một hệ thống sản xuất nên là thử nghiệm chấp nhận của người dùng, UAT. Họ thường [được cho là] quen thuộc hơn với những gì họ mong đợi gói sẽ được thực hiện. Và thường có khả năng phá vỡ mọi thứ với các luồng nhập không quen thuộc với người không sử dụng nó hàng ngày.

Kế hoạch dự án của bạn không phục vụ cho thử nghiệm người dùng? Nếu bạn khiến người dùng kiểm tra nó, bạn có thể bắt lỗi sớm hơn sau khi thực hiện mà trong thế giới của tôi không có gì xấu.

Các nhà phát triển không nên thử nghiệm mã của riêng họ vì điều đó gần giống với việc đánh giá nghệ thuật của con bạn. Dù sao nó cũng sẽ đẹp với bạn, và bạn thực sự cần một chuyên gia để chỉ ra những sai sót. Mặt khác, kiểm tra đơn vị giống như để đảm bảo con bạn không cố vẽ bằng chì.

Trong trường hợp các bạn THỰC SỰ không muốn thuê QA, hãy nhờ các nhà phát triển viết mã kiểm tra cho các nhà phát triển khác. Đó là bước đầu tiên tốt - chẳng mấy chốc bạn sẽ thấy các nhà phát triển yêu cầu tài nguyên QA vì phần lớn thời gian của họ được dành để kiểm tra mã của các vấn đề khác, ngoài CR.

Không chỉ các nhà phát triển bảo vệ mã của họ, nếu họ không nhận ra một trường hợp cụ thể hoặc hiểu sai một đặc tả trong cách họ phát triển một cái gì đó, thì họ sẽ bỏ lỡ những trường hợp đó khi kiểm tra mã của họ.

Các kỹ thuật và kỹ năng để kiểm tra đều rất khác nhau.

Hầu hết các thử nghiệm của nhóm thử nghiệm là chức năng (rằng một sản phẩm hoạt động theo thông số kỹ thuật) và hộp đen (nhóm thử nghiệm sẽ không thấy hoạt động bên trong của ứng dụng). Người kiểm tra chức năng không cần quan tâm đến cách mọi thứ hoạt động, họ chỉ cần tập trung vào việc họ có làm hay không.

Theo kinh nghiệm của tôi, ít nhất là trong tổ chức nhỏ của tôi, người dùng cuối cần kiểm tra. Hầu như mọi dự án chúng tôi nhận được, họ không cung cấp tất cả thông tin cần thiết và luôn để lại những chi tiết nhất định. Nhà phát triển luôn gặp bất lợi khi thử nghiệm vì anh ta không biết cách thực hiện công việc của người dùng, vì vậy trong khi anh ta biết phần mềm hoạt động theo thông tin anh ta đã cung cấp, anh ta không biết liệu nó có giúp được người dùng cuối không làm công việc của họ.

Các nhà phát triển đọc sai và yêu cầu giải thích sai và những người chịu trách nhiệm cho các yêu cầu thường không xác định những điều quan trọng. Nếu không có ai ngoại trừ các nhà phát triển kiểm tra, thì sẽ không ai tìm thấy các ngắt kết nối này trước khi đi vào hoạt động. Khi các nhà phát triển kiểm tra, họ biết quá nhiều về cách thức hoạt động của nó và không thử những thứ ngu ngốc mà người dùng có thể thử. Các nhà phát triển cũng viết các bài kiểm tra của họ dựa trên sự tương tác của chính họ đối với yêu cầu thường không phải là những gì thực sự có nghĩa. Vì vậy, các bài kiểm tra vượt qua nhưng yêu cầu không được đáp ứng. Khi bạn thử nghiệm người khác, người đó có thể có ý tưởng khác nhau về các yêu cầu và bạn thường tìm thấy những nơi mà việc nghỉ hưu được thể hiện kém bằng cách hai người khác nhau diễn giải nó. Tốt hơn nhiều để tìm ra điều này trong thử nghiệm hơn sau khi bạn đi trực tiếp.

Nhà phát triển nên thực hiện thử nghiệm ban đầu để chúng tôi biết phần mà chúng tôi đã mã hóa sẽ hoạt động theo cách nó được mong đợi hoạt động, theo yêu cầu chúng tôi có. Vì vậy, chúng tôi đã thực hiện kiểm tra bình thường cũng như viết Kiểm tra đơn vị cho mã chúng tôi đã viết.

Bước tiếp theo là công việc của QAs để tìm hiểu những gì các nhà phát triển không nhìn thấy khi chúng tôi viết mã. Một nhà phát triển nghĩ ở cấp độ cao hơn nhưng người dùng có thể không nghĩ ở cấp độ tương tự. Khi nhà phát triển đang kiểm tra tác phẩm của mình và phải nhập một số văn bản vào hộp văn bản, anh ta có thể luôn nhập một chuỗi đầy đủ suy nghĩ người dùng cũng sẽ làm điều đó. Có thể người dùng cũng có thể làm điều đó, nhưng ngẫu nhiên khi anh ta nhập một ký tự đặc biệt như% & $ ^ trong văn bản và điều đó làm hỏng ứng dụng, nó không phù hợp với người dùng cuối. Một nhà phát triển không thể và sẽ không nghĩ về tất cả các khả năng có thể xảy ra bởi vì anh ta không được đào tạo để nghĩ theo cách đó. Khi nói đến QA (người kiểm tra), họ luôn nghĩ về những gì người dùng có thể làm để phá vỡ ứng dụng này và thử mọi điều ngu ngốc trong cuốn sách, không phải người dùng là ngu ngốc nhưng chúng ta không nên để bất cứ điều gì có cơ hội.

Bây giờ chúng tôi cũng phải hiểu rằng thường có nhiều hơn một tác phẩm được thực hiện cùng một lúc và cả hai sẽ được sản xuất. Nhà phát triển chỉ có thể kiểm tra tác phẩm của mình và nghĩ rằng nó hoạt động tốt nhưng kiểm tra hồi quy tổng thể cần được thực hiện cho tất cả các phần đang được đẩy cũng như tìm ra rằng sự kết hợp của hai phần khác nhau có thể phá vỡ ứng dụng và nó đã làm nhìn cũng không đẹp. Chúng tôi cũng phải xem xét các kịch bản thử nghiệm tải và những thứ khác mà người thử nghiệm đã làm quen hơn.

Cuối cùng, chúng ta phải trải qua UAT (Kiểm tra chấp nhận người dùng) để xem liệu tác phẩm chúng ta đã làm có đúng như mong đợi hay không. Nói chung, mặc dù các yêu cầu thông qua BA, người cuối cùng có thể không biết chính xác nó trông như thế nào và anh ấy / cô ấy có thể nghĩ rằng đó không phải là những gì họ mong đợi hoặc họ có thể muốn thêm một cái gì đó để làm cho nó trông tốt hơn hoặc vì lý do nào đó họ có thể loại bỏ toàn bộ tác phẩm vì họ nghĩ rằng tác phẩm sẽ không phù hợp với chức năng đã có sẵn.

Như đã giải thích ở trên, những điều này rất quan trọng và không thể được thực hiện bởi nhà phát triển và hoàn toàn cần thiết để ứng dụng hoạt động tốt. Ban quản lý có thể nói đây là một cách tiếp cận bảo thủ nhưng nó là cách tiếp cận tốt hơn. Chúng tôi có thể thực hiện một số điều chỉnh như đã nói ở trên nhưng không thể tránh được.

Các ý kiến ​​trên nâng cao điểm tuyệt vời.

Một điều nữa không được đề cập trước đây là việc có một mã kiểm tra riêng lẻ hoạt động như một kiểm tra bổ sung cho các yêu cầu và nếu hệ thống thực hiện đúng chúng.

Các yêu cầu và tài liệu không hoàn hảo, và việc triển khai thường là kết quả của việc giải thích các yêu cầu của nhà phát triển.

Khi kiểm tra được thực hiện bởi một cá nhân riêng biệt, họ cũng cung cấp giải thích riêng về các yêu cầu khi tạo kế hoạch kiểm tra và thực hiện các kiểm tra.

Khi các hoạt động kiểm tra được thực hiện độc lập với các hoạt động phát triển và kết quả đầu ra của cả hai "đồng ý", nó cung cấp một xác nhận bổ sung rằng hệ thống là chính xác và thực sự phù hợp với mục đích ban đầu của các yêu cầu.

Một lập trình viên, khi kiểm tra, sẽ thấy một hộp văn bản có nhãn "Số lượng" và nhập "1". Một lập trình viên có nhiều kinh nghiệm sau đó sẽ thực hiện một bài kiểm tra tiếp theo với giá trị "2".

Một người dùng sẽ thấy một hộp văn bản có nhãn "Số lượng" và nhập "~ ~ kỳ lân ROX !!! ~ ~". Một người dùng có kinh nghiệm cũng sẽ thử "-12 1/2".

Hy vọng, một người thử nghiệm sẽ ở đó một nơi nào đó để cảnh báo cho lập trình viên về những gì người dùng sẽ trải nghiệm khi họ làm những việc này.

Một lý do là bởi vì các nhà phát triển quá gần với mã của riêng họ. Họ biết đó là những điều kỳ quặc, đó là những hành vi kỳ lạ. Họ có xu hướng kiểm tra xung quanh những đặc điểm nhỏ mà họ biết rất rõ. Họ không đủ khách quan về nó. Các nhóm thử nghiệm coi nó như một hộp đen. Họ viết ma trận của hàng chục hoặc hàng trăm trường hợp thử nghiệm và chạy một cách có phương pháp để xem mã sẽ làm gì. Thường thì họ đưa ra các kịch bản mà nhóm phát triển sẽ không bao giờ mơ tới.

Một lý do khác là thời gian. Đối với các dự án lớn được xây dựng theo giai đoạn, nhóm phát triển sẽ xây dựng Giai đoạn 1. Sau đó, người kiểm tra sẽ kiểm tra nó trong khi Giai đoạn 2 đang được xây dựng và các khiếm khuyết của Giai đoạn 1 đã được sửa chữa. Điều này diễn ra cho tất cả các giai đoạn, vì vậy giai đoạn đang được thử nghiệm là giai đoạn trước đó đã được xây dựng.

Tôi muốn thu thập một số lập luận về lý do tại sao để nhà phát triển thử nghiệm công việc của chính họ như là bước cuối cùng trước khi thử nghiệm đi vào sản xuất là một ý tưởng tồi, bởi vì thật không may, nơi làm việc của tôi đôi khi làm điều này (lần cuối cùng xuất hiện , cuộc tranh luận sôi nổi với hầu hết mọi người quá bận rộn với những thứ khác và không có thời gian để làm cho một người khác làm quen với phần đó của chương trình - đó là phần mềm rất chuyên dụng).

Các thử nghiệm không phải là tùy chọn cho một nhà phát triển. Một nhà phát triển phải kiểm tra mã anh ta viết. Làm thế nào khác anh ta có thể chắc chắn, rằng nhiệm vụ đã được hoàn thành thành công? Bạn có thể phải viết một số loại kiểm tra tự động hóa (không kiểm tra) hoặc thực hiện công việc kiểm tra "là máy thực hiện những gì tôi muốn nó thực hiện" bằng cách sử dụng GUI, gọi lệnh trên dòng lệnh hoặc bất cứ điều gì).

Tất cả mọi thứ đang được thử nghiệm sau đó là "chỉ" thử nghiệm bổ sung bởi những người khác (đồng nghiệp, QA, ...). Không có sự thay thế cho thử nghiệm trực tiếp của một nhà phát triển. Mọi người nói với tôi rằng nhà phát triển không phải kiểm tra (hoặc thậm chí không được phép) mã / tính năng anh ta viết đơn giản là không hiểu gì về cách phần mềm đang được phát triển.

Nó được kiểm tra bởi một người không quen thuộc với mã dù bạn có thích hay không. Câu hỏi là liệu bạn có muốn ai đó là khách hàng của mình không.

Câu hỏi tuyệt vời. Trong tình huống của bạn, các trường hợp thử nghiệm - trong nhiều trường hợp - tồn tại và phần mềm dường như đủ phức tạp để khiến người mới bắt kịp tốc độ trên sản phẩm là không thực tế. Bạn cũng nói thử nghiệm được thực hiện là thử nghiệm cuối cùng trước khi sản xuất

Lý do có thể ổn cho nhà phát triển để thực hiện bài kiểm tra cuối cùng

• Có đủ phạm vi kiểm tra khác ... Các thử nghiệm đơn vị tồn tại, môi trường thử nghiệm tích hợp tồn tại và được sử dụng, thử nghiệm giao diện người dùng, thử nghiệm thăm dò, v.v. đã được thực hiện, v.v. Sau đó, thử nghiệm cuối cùng là một tiêu chí chấp nhận khắt khe hơn so với cuối cùng " chạy xuyên qua"
• Một tập hợp các trường hợp thử nghiệm được viết bởi một SQA / Tester chuyên nghiệp tồn tại mà ai đó (nhà phát triển) có thể / cần phải theo dõi một cách rõ ràng
• Nguy cơ thất bại của tính năng / sản phẩm / mô-đun đã được giảm nhẹ xuống mức thấp (hãy để chuyên gia kiểm tra các khu vực rủi ro cao và kiểm tra "tân binh" mức rủi ro thấp hơn)
• Thực tế của tình hình kinh doanh là việc phát hành một sản phẩm có khiếm khuyết tiềm năng tốt hơn là trì hoãn việc phát hành
• Nhà phát triển được đề cập thực sự là một người thử nghiệm rất có trình độ và có thể thay đổi vai trò về mặt tinh thần
• Thay đổi là bản sửa lỗi được nhà phát triển thực hiện trong lĩnh vực này khi trang web của khách hàng bị đóng cửa hoặc mất doanh thu vì hệ thống đang ngoại tuyến (bản vá sẽ được đưa trở lại văn phòng và được kiểm tra / phát hành trong phiên bản được kiểm soát càng sớm càng tốt )

Lý do nhà phát triển không nên thực hiện thử nghiệm

• Còn gì nữa không

Nói chung, có vẻ như bạn đang đi đúng hướng để tấn công giải pháp thực sự - Yêu cầu chuyên gia SQA tạo ra các Test Case ...

Lưu ý: Tôi thường ủng hộ việc cho phép Nhà phát triển thực hiện thử nghiệm, nhưng tôi chắc chắn rằng điểm đầu tiên tồn tại ....

Con người, là con người, có xu hướng bị Bias nhận thức - nơi mà phán đoán của họ trong hai kịch bản gần giống nhau sẽ khác nhau, đơn giản chỉ vì một vài điều đã thay đổi - một điều tôi nhận thấy trong 8 năm phát triển, đó là khi một nhà phát triển phải đối mặt với việc kiểm tra mã riêng của mình, trái ngược với mã mà đồng nghiệp đã viết, thử nghiệm được thực hiện trên mã của chính họ có chất lượng kém hơn rất nhiều.

Điều này không có nghĩa là nhà phát triển có lỗi trực tiếp - bộ não của anh ấy / cô ấy sẽ sử dụng sự thiên vị mà họ đã viết nó, để củng cố thực tế rằng họ tin rằng nó đúng và sẽ chỉ thực hiện kiểm tra cơ bản, trái ngược với nhà phát triển đang xem mã của người khác, sẽ kiểm tra kỹ lưỡng hơn.

Có hàng ngàn ví dụ ngoài kia, nơi quy trình đã được đưa ra để ngăn chặn sự thiên lệch nhận thức, hay thường được gọi là "Nhân tố con người", chẳng hạn như các hệ thống máy tính trong kiểm soát không lưu, để ngăn chặn hai máy bay khác nhau chiếm cùng một không phận thời gian, để các thủ tục y tế được đưa ra để nhiều hơn một bác sĩ phải đưa ra chẩn đoán.

Đã đến lúc ngành công nghiệp CNTT chuyển sang một thái độ chuyên nghiệp hơn và đưa ra các quy trình để ngăn chặn việc kiểm tra mã của riêng bạn.

• Eeveryone nên kiểm tra - Mã kiểm tra của người phát hiện, chức năng kiểm tra của QA, Tin nhắn kiểm tra tiếp thị. Bằng cách đó, mọi người đều có chung triết lý và ngôn ngữ xung quanh việc thử nghiệm, đó là một nửa trận chiến.

• Kiểm tra là bảo trì thường xuyên và tôi thường sử dụng các chất tương tự để so sánh . Ví dụ, sự thay đổi dầu xe tương tự. Bạn không bao giờ phải 'thay dầu'. Nhưng dù sao bạn cũng làm điều đó thường xuyên. Tương tự cho việc đánh răng. Có một lý do để bạn duy trì chúng hàng ngày - chúng sẽ không phá vỡ 'hôm nay', đó là tất cả về ngày mai và ngày tương lai và đầu tư.

• Mọi người nên chia sẻ trách nhiệm để kiểm tra. Nhóm QA rất quan trọng, tuy nhiên, thực hiện "thử nghiệm" là điều mà chỉ nhóm QA thực hiện khiến nó trở thành một hoạt động 'riêng biệt' mà nó không được tích hợp để phát triển sản phẩm và quy trình làm việc không phải là một điều tốt.

• Khi bất cứ điều gì phá vỡ trong sản xuất làm hai điều:

  1. Nói "hmm, chúng tôi có một bài kiểm tra cho điều đó " như là nhận xét đầu tiên.
  2. Thực hiện bất kỳ sửa chữa bao gồm kiểm tra cho vấn đề , đầu tiên để tái tạo, hơn là sửa chữa.

Tại công ty của tôi, chúng tôi xây dựng một số ứng dụng tài chính khá phức tạp. Chính sách chung của chúng tôi là nhà phát triển cần đảm bảo rằng không có lỗi kỹ thuật phát sinh. Về cơ bản, hãy thử mọi thứ bạn có thể để phá vỡ nó, dựa trên tài nguyên của người dùng. Khi bạn không thể tìm thấy lỗi thời gian chạy, hãy gửi nó tới các BA để kiểm tra. Chúng tôi đã có một vài nhà phát triển bị lạc trong việc thử nghiệm các yêu cầu kinh doanh đến mức kiệt sức, nhưng chỉ vì tất cả những thử nghiệm đó không phải là trách nhiệm của họ. Trừ khi có một số lỗi rõ ràng có thể nhìn thấy rõ, chúng tôi sẽ gửi nó cho những người được trả tiền để hiểu đầu ra. Ngoài ra, người dùng nên có một vai trò thực sự trong việc xác minh kết quả. Nhân viên bán hàng tại một cửa hàng bán lẻ không thử quần áo cho bạn, họ chỉ giúp bạn "các chi tiết kỹ thuật" như tìm quần áo đúng kích cỡ.

Một vấn đề là các nhà phát triển có ít động lực để phá vỡ mã của riêng họ - rất ít người sẵn sàng tìm kiếm các khiếm khuyết trong công việc của chính họ hoặc sẵn sàng mắc lỗi. Có một nhóm riêng giúp đảm bảo rằng mọi thứ sẽ bị phá vỡ.

Vai trò Đảm bảo Chất lượng là rất cần thiết, trong số các lý do khác, để ai đó có thể kiểm tra xem nhà phát triển đã hiểu các yêu cầu chưa. Nhà phát triển không thể tự kiểm tra điều này bởi vì nếu họ nghĩ rằng họ đã hiểu lầm sẽ yêu cầu làm rõ.