Kiểm tra giao tiếp nhà phát triển

Mặc dù có rất nhiều bài viết về giao tiếp giữa nhà phát triển-nhà phát triển, nhà phát triển-khách hàng, nhà quản lý nhóm nhà phát triển, tôi không thể tìm thấy bất kỳ văn bản nào đưa ra hướng dẫn về giao tiếp và mối quan hệ giữa nhà phát triển thử nghiệm.

Cho dù người thử nghiệm và nhà phát triển là các nhóm riêng biệt hoặc trong cùng một nhóm (trong trường hợp của tôi, tôi là người thử nghiệm đơn độc trong dự án phát triển nhanh), tôi có niềm tin rằng cách người thử nghiệm cảm nhận là cực kỳ quan trọng để thử nghiệm được chấp nhận tốt và để phục vụ mục tiêu của nó trong việc nâng cao chất lượng của dự án (ví dụ, họ không nên được xem như là một lực lượng cảnh sát).

Bất kỳ lời khuyên, hoặc nghiên cứu về cách một người thử nghiệm nên giao tiếp với các nhà phát triển?

Cập nhật : Cảm ơn tất cả các câu trả lời của bạn. Họ đều xác nhận những gì tôi có trong tâm trí. Hiện tại, nhóm của tôi rất dễ tiếp nhận vai trò của tôi và cuối cùng chúng tôi đã đạt được tiến bộ thực sự. Tôi có thể đã chọn nhiều hơn một câu trả lời nhưng tôi phải đưa ra quyết định của mình.

Cách dễ nhất để cải thiện giao tiếp là làm việc cùng với các nhà phát triển của bạn (và các nhà thiết kế và kiến ​​trúc sư, v.v.) và từ từ phá vỡ những vai trò ngớ ngẩn đó và cuối cùng nhận ra rằng tất cả chúng ta đều là người thử nghiệm, ngoại trừ một số người trong chúng ta có nhiều kinh nghiệm hơn những người khác.

Đối với nhanh nhẹn, chỉ cần làm nó "bằng cuốn sách". Người kiểm tra là một phần của nhóm và không chỉ là một thực thể bên ngoài mà bạn bàn giao công cụ khi hoàn thành. Chuyên môn có giá trị của bạn được đưa vào sử dụng trong toàn bộ sự phát triển. Đầu tiên khi tạo câu chuyện người dùng, bạn sẽ giúp rút ra các bài kiểm tra chấp nhận và làm cho chúng tự động. Những thử nghiệm này sau đó được sử dụng bởi các nhà phát triển trong công việc của họ. Bạn cũng dành thời gian hàng ngày để kiểm tra thăm dò công việc một phần và hoàn thành, và nói chuyện với PO để làm rõ và cải thiện bài kiểm tra của bạn liên tục.

Đó là những gì tôi muốn nói khi tôi nói về "làm việc cùng nhau". Tôi hoàn toàn chắc chắn đây là cách giao tiếp trong một nhóm nên hoạt động. Bài viết này giải thích nó rất tốt btw.

Đối lập với điều này, nhiều tổ chức muốn xử lý sự phát triển bằng cách đặt tất cả những người thử nghiệm (và DBA, và các nhà thiết kế và lập trình viên) vào các phòng ban riêng biệt. Điều này hoạt động chống lại truyền thông và chỉ phục vụ cho ý tưởng phát triển theo giai đoạn. Cố gắng cải thiện giao tiếp trong tình huống như vậy là có thể, nhưng những cải tiến nhỏ bạn có thể mong đợi là không đáng để nỗ lực. Ít nhất là không so với việc thực sự đưa mọi người vào cùng một phòng và tạo ra các nhóm chức năng chéo.

Tôi là một người tin tưởng vững chắc vào MỌI loại giao tiếp giữa dev và test.

Đã rất nhiều lần tôi thấy các trận đấu nảy giữa các đội, qua lại ("đóng theo thiết kế", sau đó là "mở lại", v.v.).

Tôi luôn nói với những người thử nghiệm mà tôi làm việc cùng đến và nói chuyện với tôi nếu họ có bất kỳ nghi ngờ nào.

Một điều tôi thực sự ghét, là các nhà phát triển nhận được tất cả sự kiêu ngạo về thử nghiệm và nói về nó, vì vậy bất cứ điều gì tôi có thể làm để thúc đẩy mối quan hệ tốt với các nhóm thử nghiệm, tôi cố gắng làm.

Một người kiểm tra nên rất rõ ràng và chính xác với các nhà phát triển khi truyền đạt về lỗi và kiểm tra. Danh sách chi tiết các bước để tạo lại lỗi, ảnh chụp màn hình nếu cần ... Mô tả mơ hồ về các lỗi không thể sao chép hoặc có các bước không rõ ràng để tái tạo sẽ nhanh chóng làm hỏng mối quan hệ giữa người phát triển và người kiểm tra.

Tôi chưa bao giờ tin rằng luôn có sự bất đồng giữa nhà phát triển và người thử nghiệm nhưng tôi đã phải đối mặt với tình huống này khi một trong những người bạn thân nhất của tôi có vai trò thử nghiệm trong công ty tôi đang làm việc và thật ngạc nhiên là anh ta được giao cùng một mô-đun để kiểm tra rằng tôi đang phát triển và vì vậy thật sự FUNhợp tác với anh ấy và tôi phải nói rằng điều rất quan trọng là phải hiểu ý kiến ​​của người khác trong tình huống như vậy và kiểm soát cái tôi của chính mình, điều này đã giúp tôi rất nhiều và chúng tôi làm tốt về chuyên môn của chúng tôi các cam kết cũng như mức độ tình bạn cá nhân.

Vì bạn đã nói rằng bạn là người thử nghiệm duy nhất trong môi trường Agile (giả sử Scrum) có lẽ tận dụng cuộc họp hồi cứu như một diễn đàn mở để xác định quá trình giao tiếp có thể theo thứ tự.

Như bạn đã biết cuộc họp giới thiệu là để giải quyết các nếp nhăn trong quy trình Scrum. Đây có thể là các mục như cho phép các nhà phát triển hàng giờ XY không bị gián đoạn, chỉ liên lạc qua email vào thứ Hai và bằng lời nói trong phần còn lại của tuần, bất cứ điều gì phù hợp với nhóm CỦA BẠN ; vì giao tiếp không bao giờ là một kích thước phù hợp với tất cả các phương pháp tiếp cận.

Là một nhà phát triển, tôi đánh giá cao một người thử nghiệm thể hiện sự chủ động. Họ không vẽ đường ... họ muốn khiếm khuyết được giải quyết; Bất kể nguyên nhân gốc rễ. Các nhà phát triển và người thử nghiệm phải tách biệt cảm xúc với kinh doanh. Khiếm khuyết là một phần của kinh doanh kể từ khi con người tham gia. Cách tiếp cận tốt nhất để giải quyết lỗi là một nhóm liên kết được thiết lập để giải quyết các khiếm khuyết một cách toàn diện. Khi đường bắt đầu nổi lên và đường viền được đặt ra; giao tiếp sẽ bị phá vỡ.

Tận dụng các cuộc họp độc lập hàng ngày của bạn. Tham gia càng nhiều càng tốt; không chỉ với thử nghiệm mà còn với toàn bộ sản phẩm. Vào cuối ngày, một nhà phát triển và một người thử nghiệm đang làm việc trên một mục tiêu và phải luôn luôn tập trung vào mục tiêu đó.

Tôi thích xem những người thử nghiệm là một phần của cùng một đội. Về vấn đề đó không có vấn đề giao tiếp.

Bất cứ khi nào một người kiểm tra phải nói chuyện với một nhà phát triển hoặc cách khác chỉ cần đến và hãy trò chuyện. Chỉ là một thói quen hàng ngày.

Tuy nhiên, cả hai bên phải tôn trọng lẫn nhau và thực hiện công việc của họ đúng cách.

Người kiểm tra cần cung cấp chi tiết kỹ lưỡng về các điều kiện lỗi và không báo cáo điều gì là lỗi trong khi thiết kế. Đặc biệt là khi chỉ cần hỏi anh chàng đằng kia về một thứ đáng ngờ trông giống như một tính năng.

Các nhà phát triển phải nghiêm túc báo cáo lỗi và điều tra sâu không chỉ đóng vấn đề nếu bạn không tái tạo lỗi trong năm lần nhấp.

Thái độ chuyên nghiệp là tất cả những gì nó cần.

Công cụ số 1 tôi thấy rằng tôi, với tư cách là người thử nghiệm (SDET), có thể tận dụng để cải thiện mối quan hệ kiểm tra dev là sự tâng bốc trung thực, đặc biệt là dưới hình thức tìm kiếm sự hướng dẫn từ các nhà phát triển.

Hy vọng rằng, các nhà phát triển mà tôi làm việc cùng là các nhà phát triển Betters hơn tôi. Họ không hoàn hảo, hoặc tôi sẽ không có việc làm, nhưng có rất nhiều điều họ biết rõ hơn tôi. Họ đã phát triển thuần túy, trong khi sự chú ý của tôi tập trung một phần vào thử nghiệm. Tôi lưu ý những điều mà họ làm tốt hơn, và tôi thường xuyên đề cập đến chúng. Khi tôi đọc mã của họ, tôi lưu ý các chi tiết trang nhã hoặc sử dụng gọn gàng các mẫu thiết kế và đưa chúng lên trong cuộc trò chuyện. Tôi bắt chước các nhà phát triển, sử dụng các quy ước mã hóa tương tự khi có thể và tích hợp các thành phần từ sản xuất vào các công cụ kiểm tra của tôi khi thích hợp (ví dụ: ghi nhật ký). Tôi công nhận chuyên môn của họ, và kết quả là họ rất vui khi được công nhận của tôi. Nhắc bạn, nếu tôi nghĩ có một cách tốt hơn để làm mọi thứ thì tôi hoàn toàn lên tiếng - nhưng tôi hướng đến việc đưa ra phản hồi tích cực hơn là tiêu cực, tổng thể. Nói chung, tôi cố gắng làm cho phản hồi tiêu cực trở nên trang trọng và không khách quan hơn (ví dụ: báo cáo lỗi) và phản hồi tích cực ít trang trọng và cá nhân hơn (ví dụ: các cuộc hội thoại trực tiếp).

Đưa ra phản hồi tích cực về chất lượng cũng như phản hồi tiêu cực và xin lời khuyên thay đổi mối quan hệ từ việc gây tranh cãi sang làm việc theo nhóm và học hỏi lẫn nhau và làm giảm khả năng phòng thủ. Các nhà phát triển biết rằng họ có thể tin tưởng tôi luôn nói những điều tốt hơn là xấu, vì vậy họ cảm thấy thoải mái khi nghe tôi nói. Ngoài ra, việc hỏi những câu hỏi sâu sắc về sự phát triển làm tăng ý kiến ​​của họ về tôi và vượt qua khuôn mẫu "SDETs là dev dev" (nơi nó vẫn tồn tại).

Tôi tin chắc rằng giao tiếp tốt giữa nhà phát triển và người thử nghiệm là rất quan trọng. Đối với cách tốt nhất để làm, tôi chắc chắn rằng có nhiều cách tiếp cận tốt nhưng đây là những gì đã làm việc tốt nhất cho tôi.

Giao tiếp trực tiếp / cá nhân! Tôi đã thấy rằng cá nhân, không phải email, giao tiếp luôn hoạt động tốt nhất. Nó cho phép nhà phát triển và người thử nghiệm hình thành mối quan hệ cá nhân. Một khi bạn có những thứ đó dường như hoạt động tốt hơn và có xu hướng chảy. Họ không bao giờ gặp vấn đề khi chạy một bài kiểm tra đặc biệt hoặc đi thêm một dặm cho bạn. Điều tương tự cũng xảy ra với nhà phát triển và tôi luôn dành thêm thời gian để xem xét những thứ mà họ cần giúp đỡ hoặc đang gặp vấn đề. Theo kinh nghiệm của tôi, nó làm cho việc giải quyết vấn đề diễn ra nhanh hơn, ít lãng phí thời gian hơn.