Tại sao người kiểm tra và lập trình viên không thích nhau? [đóng cửa]

Trong suốt sự nghiệp làm lập trình viên, tôi đã thấy nhiều lập trình viên và người thử nghiệm khác nhau, và nhiều người trong số họ không / không thích nhau. Ý tôi là, các lập trình viên nghĩ rằng công việc của người kiểm thử không phải là công việc "thực sự" và người kiểm thử nghĩ rằng lập trình viên quá "tự hào".

Đây có phải là quyết định đúng đắn của tôi, tại sao lại như vậy, và chúng ta có thể làm gì để tránh những vấn đề tử tế này?

Tôi nghĩ đó là một tổng số trên tổng quát hóa và đơn giản hóa hơn.

Tôi hiện đang là một người thử nghiệm, tôi viết gần như nhiều mã như tôi đã viết như một dev (phụ thuộc vào giai đoạn thử nghiệm) và người bạn thân nhất của tôi trong công ty là một dev và tất cả chúng tôi đều hợp nhau.

Bạn có thể muốn xem xét văn hóa doanh nghiệp và cách các nhóm làm việc liên quan đến nhau để tìm câu trả lời của bạn. Theo kinh nghiệm của tôi, nếu bạn có quy trình làm việc rất phản động (ví dụ: dev "ném một bản dựng lên tường để kiểm tra" và kiểm tra "ném lỗi trở lại") thay vì làm việc cùng nhau , chỉ từ các điểm lấy nét khác nhau hoặc "vectơ tấn công" thì bạn ' sẽ thấy rằng cả hai bộ phận nói chung, sẽ không thích nhau.

Nơi tôi làm việc, mỗi nhóm tính năng hoặc nhóm thiết kế có gần như nhiều người thử nghiệm như các nhà phát triển làm việc cùng nhau để tạo đầu ra. Đầu ra đó là mã sản xuất đáp ứng các yêu cầu được đặt ra bởi mã kiểm tra.

biên tập

Cũng lưu ý rằng tôi nghĩ rằng onus nằm trên máy thử nhiều hơn dev để hỗ trợ mối quan hệ giữa hai người.

Chúng ta dễ dàng hơn nhiều để làm cho cuộc sống của dev tốt hơn hoặc tồi tệ hơn, nhưng mục tiêu không chỉ đơn giản là "tìm lỗi" mà còn tìm giải pháp tiềm năng. Nếu tôi không thể, thì tôi không thể, và tôi sẽ làm việc với bất kỳ ai được chỉ định lỗi tại thời điểm đó để tìm giải pháp. Nhưng nếu đó là một giải pháp đơn giản thì tôi sẽ cung cấp những gì tôi tin là một giải pháp tiềm năng đáp ứng các yêu cầu khác nhau và bài kiểm tra hồi quy cuối cùng mà tôi sẽ viết.

Tôi yêu những người thử nghiệm của tôi - họ giúp tôi khắc phục sự cố và phát hiện ra những điều mà tôi không nghĩ là vấn đề, nhưng khách hàng của chúng tôi sẽ làm. Và quan trọng nhất với tôi, họ giúp tôi đảm bảo rằng tôi không giết người có mã xấu.

Tại sao các vấn đề bật lên?

• Bạn thường xuyên đánh giá từng công việc khác, và một số người không thể lấy bất kỳ loại critism
• Làm một công việc tồi tệ làm lãng phí thời gian của bạn
• Cả hai bạn đều chịu áp lực, cùng một lúc, vì cùng một điều và không ai muốn trở thành người nắm giữ mọi thứ

Sự kết hợp của những điều trên cùng với bản chất của các vị trí có nghĩa là thực sự dễ dàng loại bỏ sự tức giận và sự thất vọng hiện tại của bạn, nếu bạn rơi vào cái bẫy đó, bạn sẽ ngừng làm việc với nhau và bắt đầu làm việc với nhau. Điều đó thật khó để thoát ra và nó không tốt cho bất cứ ai.

Tôi đoán nó sẽ xảy ra khi các lập trình viên tạo ra một chương trình và họ nhận thấy rằng những người thử nghiệm sau đó cố gắng tìm ra lỗ hổng trong đó (mặc dù những người thử nghiệm thực sự là một phần của việc cải thiện sản phẩm cuối cùng). Bất cứ khi nào ai đó tìm thấy sai sót trong một cái gì đó mà bạn nỗ lực rất nhiều, đó có thể là một phản ứng tự nhiên để phản ứng tiêu cực đối với họ.

Các cách để giảm thiểu điều này là làm cho các nhà phát triển và người thử nghiệm xem sản phẩm hoàn chỉnh là đầu ra của cả nhóm (bao gồm cả người thử nghiệm và nhà phát triển) và khiến họ hiểu rằng thử nghiệm không phải là nhiệm vụ tìm lỗi độc lập mà là một phần quan trọng của những phát triển quá trình. Và nếu các nhà phát triển không nghĩ kiểm thử là một công việc thực sự hoặc điều đó dễ dàng, hãy để họ viết ma trận kiểm tra, thực hiện hàng trăm trường hợp kiểm thử, ghi lại từng bước và từng kết quả.

Tôi biết các lập trình viên cụ thể và những người thử nghiệm cụ thể không thích nhau, nhưng không phải vì những lý do bạn nêu mà là vì họ làm việc cho nhau.

Đó là bản chất của con thú. Một số người thử nghiệm cụ thể mà tôi biết là những người không quan tâm đến các lập trình viên cụ thể vì họ cảm thấy mã của họ dễ bị lỗi thông qua sự bất cẩn / lười biếng / v.v. Một số lập trình viên cụ thể mà tôi biết, những người không quan tâm đến những người thử nghiệm cụ thể cảm thấy họ đã sử dụng các điều kiện kiểm tra giả định một cách lố bịch (chọn nits) hoặc sẽ yêu cầu sửa đổi mã dựa trên kiểu dáng.

Tôi nghĩ việc giữ cá tính ra khỏi nó, và tập trung vào nhiệm vụ trong tay sẽ giúp giảm căng thẳng. Nếu một tổ chức đủ lớn, thử nghiệm mù đôi là một ý tưởng tuyệt vời.

Một người thử nghiệm có thể thể hiện rõ ràng các vấn đề và các lập trình viên thực hiện rõ ràng các giải pháp là một nhóm tuyệt vời.

Trong các đội mà tôi đã làm việc chặt chẽ với những người thử nghiệm, chúng tôi đã hòa hợp tuyệt vời. Người kiểm tra hiểu các quyết định đã đi vào các quyết định khác nhau được đưa ra, họ biết lịch trình của nhà phát triển là như thế nào và mối quan hệ được xây dựng giữa hai nhóm.

Trong các đội nơi kiểm tra là một số thực thể vô định hình ngoài khơi, điều này đã không xảy ra. Kết quả của những người thử nghiệm ít liên quan hơn vì họ không biết nhiều về những gì đang diễn ra, các nhà phát triển bắt đầu sợ hãi những gì họ coi là chi tiết không quan trọng trong các phần của chương trình chưa được chạm vào trong hai phần nhiều tháng, nhóm thử nghiệm cảm thấy khó chịu vì không có lỗi nào được sửa chữa (vì lịch trình bị sai sót và các nhà phát triển bận rộn để sẵn sàng cho các bản demo hoặc thêm các tính năng được yêu cầu, v.v.) và nói chung cả hai nhóm đều coi nhau là đối kháng "Những người khác" trái ngược với các thành viên trong nhóm.

Làm việc chặt chẽ và mọi thứ sẽ ổn. Ai đó cần đảm bảo cả hai đội được phối hợp và trên cùng một trang. Kinh nghiệm tốt nhất của tôi, nhóm thử nghiệm đã được mời tham dự bất kỳ cuộc họp cấp cao nào mà nhóm phát triển được mời (tất cả họ) và tất cả chúng tôi đều biết lịch trình, chúng tôi có một danh sách ưu tiên thống nhất, và các nhà phát triển và thử nghiệm đều có cùng (lên đến ngày) tài liệu yêu cầu. Trải nghiệm tồi tệ nhất của tôi (ngoài việc không có kiểm tra) về cơ bản chúng tôi đã đóng gói đồ đạc của mình, chuyển nó ra nước ngoài để xem xét, sau đó lấy lại mọi thứ sau đó với những thứ được đánh dấu là sai thậm chí không phải của chúng tôi (plugin của bên thứ 3 đã gặp mới yêu cầu, nhưng không phải là mong đợi của nhóm thử nghiệm).

Không dev hoặc test sẽ thành công mà không có khác. Nếu bạn làm việc như hai nửa của cùng một máy và tôn trọng phía bên kia cũng như bạn tôn trọng các thành viên trong nhóm ngay lập tức hơn, mọi việc sẽ ổn. Hành xử như hai máy riêng biệt và cho rằng máy của bạn tốt hơn, mọi thứ sẽ rất tồi tệ.

Khi các lập trình viên và người kiểm thử không thích nhau, thường là do họ tưởng tượng nhầm rằng mục tiêu của họ xung đột.

Tôi đã thấy rằng những vấn đề này được giảm thiểu rất nhiều khi những người thử nghiệm và nhà phát triển ở cùng một nhóm, thay vì một "nhóm thử nghiệm" và "nhóm phát triển". Tôi nghĩ đây là lý do tại sao, với tư cách là một người thử nghiệm, tôi rất thích làm việc trong các nhóm Agile hơn là phát triển thác nước. Có nhiều giao tiếp hơn, quay vòng nhanh hơn và các nhà phát triển có sự đánh giá cao hơn về thời gian và tài năng đi vào thử nghiệm khi công việc đó minh bạch hơn.

Cá nhân, có rất nhiều có thể được thực hiện là tốt. Là một người thử nghiệm, tôi thấy tôi có thể giảm ma sát này bằng cách cung cấp phản hồi tích cực cũng như tìm ra lỗi. Tôi vẫn chưa thử nghiệm cho một nhà phát triển không thể dạy tôi rất nhiều và tôi thấy các nhà phát triển đánh giá cao một người thử nghiệm thực sự làm việc để hiểu mã. Các nhà phát triển đang tự hào, giống như bất kỳ nghệ nhân tốt. Điều quan trọng là cho họ biết rằng có lỗi không làm cho họ bớt đáng ngưỡng mộ

Các nhà phát triển Tôi thấy dễ dàng nhất để làm việc với chất lượng tốt được đánh giá cao và đã chứng minh điều đó bằng cách nỗ lực viết mã chất lượng cao trước khi người kiểm tra thấy nó, bao gồm thực hiện thử nghiệm sơ bộ (chủ yếu là kiểm tra đơn vị tự động và kiểm tra khói thủ công). Những nhà phát triển này cũng yêu cầu kiểm tra để thực hiện đánh giá mã cho khả năng kiểm tra và đưa người kiểm tra vào quy trình càng sớm càng tốt, bao gồm trình bày các thiết kế cho họ sớm (cho phép người kiểm tra bắt đầu lập kế hoạch chiến lược kiểm tra sớm, khi kiểm tra có tải nhẹ hơn). Các nhà phát triển có thể giúp người kiểm thử tìm các khu vực yếu trong mã của họ bằng cách cho họ biết khu vực nào được phát triển vội vàng hoặc khu vực nào khó kiểm tra đơn vị. Nói chung, bất cứ điều gì các nhà phát triển có thể làm để làm cho công việc của người kiểm tra dễ dàng hơn đều được đánh giá cao và cho thấy rằng họ coi trọng thời gian của người kiểm tra cũng như của chính họ. Khi các nhà phát triển làm điều này,

Một vấn đề khác là QA thường là suy nghĩ của nhiều công ty. Rất nhiều lần nó được kể về các dự án vào phút cuối và bị thiếu hụt rất nhiều so với nhóm phát triển. Tại một số nơi, đường dẫn đến nhà phát triển là hỗ trợ kỹ thuật, QA và sau đó là nhà phát triển. Vì vậy, đôi khi nó được bố trí với những người muốn họ là nhà phát triển ... Và sau đó khi họ phát hiện ra khuyết điểm thì thái độ của họ là làm sao người đó có thể là nhà phát triển chứ không phải tôi, tôi sẽ không bao giờ mắc lỗi như vậy, v.v ...

Nhìn chung, tôi sẽ yêu một đội QA. Ngoài ra tôi cũng nghĩ rằng kiểm thử đơn vị nên là một phần cần thiết trong phát triển phần mềm tách biệt với QA. Vì vậy, khi QA tìm thấy lỗi, các bài kiểm tra đơn vị được thay đổi để kiểm tra điều đó. Ngoài ra, tôi nghĩ rằng các nhà phát triển kiểm tra đơn vị có thể hiểu rõ hơn về những gì QA đang tìm kiếm.

Ngoài ra, nhiều nhóm QA phải thực hiện thủ công, trong trường hợp đó là một công việc nhàm chán THỰC SỰ. Ở một số nơi, QA viết tập lệnh và sử dụng các chương trình tự động hóa thậm chí cho phép GUI kịch bản (thông qua một số loại nhận dạng hình ảnh trên màn hình cho các nút / v.v.). Sau đó, vẫn còn khó khăn khi những thay đổi lớn xảy ra lúc đầu, nhưng sau đó mọi thứ được tự động hóa và có vẻ vui hơn ...

Ngoài ra một số nhà phát triển xem thường QA. Vẫn còn hơn là QA tìm thấy một khiếm khuyết hơn khách hàng ....

Chúng tôi yêu những người thử nghiệm của chúng tôi ở đây, nhưng sau đó nhiều người trong chúng tôi nhớ nó như thế nào trước khi chúng tôi có chúng. Thật tốt khi có những người kiểm tra tìm thấy vấn đề hơn là để khách hàng tìm thấy chúng sau khi bạn đã đi vào sản xuất. Không có nhà phát triển nào còn sống đã tạo ra lỗi hoặc giải thích sai yêu cầu.

Điều quan trọng là đối xử với tất cả các chuyên gia một cách lịch sự và tôn trọng cho dù họ có làm những gì bạn làm hay không. Một khi bạn bắt đầu nghĩ rằng công việc của bạn tốt hơn hoặc quan trọng hơn công việc của họ thì bạn đã mất.

Dựa trên câu hỏi này: Các kỹ thuật hoặc danh mục kiểm thử phần mềm Tôi nghi ngờ bạn cần điều chỉnh thái độ đối với người kiểm thử và kiểm thử nói chung.

Là một nhà phát triển, tôi đã trải nghiệm sự chia sẻ căng thẳng của mình với những người thử nghiệm.

Trong một công việc, những người thử nghiệm sẽ hiếm khi được thử nghiệm "điều đúng". Tôi đã triển khai một tính năng mới cho máy chủ của sản phẩm của chúng tôi và những người thử nghiệm sẽ báo cáo cả đống lỗi về giao diện người dùng. Vì trong sản phẩm đó, giao diện người dùng được định cấu hình không được mã hóa , sự hiện diện (hoặc không) của các vấn đề trong giao diện người dùng phát triển của chúng tôi hoàn toàn không có liên quan đến việc người dùng cuối có gặp phải UI có vấn đề tương tự hay không. Những người thử nghiệm biết điều này, nhưng vẫn kiên trì ghi nhật ký lỗi về các khu vực bên ngoài.

Điều đó nói rằng, những người thử nghiệm tốt đáng giá vàng của họ - Tôi sẽ trao đổi một nhà phát triển tệ hại cho một người thử nghiệm tốt ngay lập tức. Một người thử nghiệm tốt là một đối tác trong việc cung cấp một sản phẩm chất lượng.

Tôi cũng đã biết một số nhà phát triển coi những người thử nghiệm là kẻ thù - như thể những người thử nghiệm đang giới thiệu các lỗi. Điều quan trọng đối với các nhà phát triển là nhận ra rằng những người thử nghiệm không bao giờ đưa ra lỗi - họ chỉ phát hiện ra nó.

Làm thế nào để tránh những vấn đề này? Làm thế nào là tốt đẹp với nhau? Người ta cần người kia để có được một ứng dụng phần mềm chất lượng, vậy tại sao không tôn trọng những gì mỗi bên cần làm để thực hiện điều này? Nhận biết những gì mỗi bên làm và bạn thực sự có thể đánh giá cao công việc liên quan.

Sự bướng bỉnh ở cả hai phía của việc giải thích chính xác yêu cầu sẽ là nơi tôi có xu hướng nhìn thấy xung đột giữa các nhà phát triển và người thử nghiệm nói chung. Mặc dù có thể có sự xuất hiện của hợm hĩnh hoặc kiêu ngạo, nhưng chỉ là mỗi bên dính vào súng của họ và muốn đúng.

Một cách tốt để tránh vấn đề này là có 3 bên, nhà phát triển, người kiểm tra và một số hòa giải viên hoặc một nhà phân tích kinh doanh hoặc người quản lý dự án làm việc thông qua cách xử lý các trường hợp ranh giới khác nhau. Một cái gì đó để xem xét là loại bản ngã có thể phát sinh khi có sự bất đồng giữa các nhà phát triển và người thử nghiệm.

Cảm giác xấu thường là kết quả của giao tiếp xấu, thường là kết quả của các lập trình viên và người kiểm tra có quan điểm khác nhau về mã. Lập trình viên biết các bit mà anh ta đang làm việc thân mật, nhưng có thể không biết làm thế nào chúng phù hợp với hệ thống tổng thể (ngoài những gì đặc điểm kỹ thuật nói với anh ta). Người kiểm tra nhìn thấy bức tranh lớn, nhưng không biết chi tiết mã. Các nhóm có thể sử dụng các thuật ngữ và thủ tục khác nhau cho cùng một thứ.

Điều này có thể dẫn đến các lỗi được gửi đối với thành phần sai (vì thành phần đó đang phản ứng với sự cố ngược dòng) hoặc các nhà phát triển đóng các lỗi hợp pháp vì họ không thể tái tạo vấn đề trong môi trường của họ (vì họ không thực sự hiểu cách tái tạo vấn đề chính xác). Nếu điều này xảy ra nhiều, nó có thể làm căng thẳng mối quan hệ giữa các nhóm.

Sau đó, có niềm vui nhận được một loạt các khiếm khuyết vào giờ thứ 11; thời hạn sắp hết, áp lực đến với bạn từ người quản lý trực tiếp của bạn trong chuỗi và bạn nhận được một loạt lỗi mới về một vấn đề mà bạn biết bạn đã khắc phục và bạn thực sự không muốn mất thời gian để giải quyết thông qua quá trình để chứng minh điều đó.

Một cách thực sự tốt để loại bỏ nhóm QA của bạn là tổng hợp hàng trăm lỗi khiếm khuyết hợp pháp nhưng có mức độ ưu tiên thấp (chủ yếu được nộp chống lại các UI xấu xí hoặc không nhất quán có chức năng khác) với lý do rằng tồn đọng ưu tiên cao hơn của bạn quá lớn. " chúng ta sẽ không bao giờ đến với những người đó. " Bạn chuyển từ màu đỏ sang màu xanh lá cây trên bảng tính của người quản lý chương trình và nhận được chứng nhận từ quản lý cấp cao hơn, trong khi nhóm QA đánh vào số liệu của họ để nộp một loạt các khiếm khuyết không có thật.

Juju xấu.

Điều này thường phát sinh từ ba yếu tố -

• Những câu hỏi như thế này chỉ ra sự tồn tại của một "văn hóa dân gian" trong ngành mà các nhà phát triển và người thử nghiệm không thích nhau. Mọi người cố gắng tìm các khía cạnh củng cố điều này, ngay cả khi cảm giác như vậy có thể không tồn tại trong đội của họ.
• Người quản lý dự án không đủ năng lực đo lường tiến độ theo số liệu như số lượng lỗi được ghi lại.
• Một nhóm rối loạn chức năng (và thiếu các nhà lãnh đạo quan tâm đủ để sửa chữa nó).

Tôi thích người thử nghiệm, nhưng hai trường hợp tôi đã tìm thấy xung đột.

1. Khi quản lý chơi thử và dev lệch nhau.

2. Khi các vấn đề liên tục được gửi mà thiếu chi tiết, tức là "Màn hình x không hoạt động".

Tôi nghĩ rằng nếu đây thực sự là một trường hợp, đó là một dấu hiệu của sự non nớt. Đôi khi bạn có thể nói về nó như một trò đùa. Nhưng nếu bạn (nhà phát triển và người thử nghiệm làm việc trong cùng một dự án) không cảm thấy như một nhóm, kết quả sẽ là một thảm họa.

Kiểm thử là một phần khá quan trọng trong vòng đời phát triển phần mềm (có thể nhanh nhẹn hay không). Vì vậy, bạn không nên nghĩ về những người thử nghiệm như những người sống để làm phiền bạn với các lỗi, mà là một đồng đội giúp bạn vận chuyển phần mềm chất lượng.