Làm thế nào để các lập trình viên cấp dưới viết bài kiểm tra [đóng cửa]

Chúng tôi có một lập trình viên cấp dưới chỉ đơn giản là không viết đủ các bài kiểm tra.
Tôi phải cằn nhằn anh ta hai giờ một lần, "bạn đã viết bài kiểm tra chưa?"
Chúng tôi đã thử:

• Cho thấy thiết kế trở nên đơn giản hơn
• Hiển thị nó ngăn ngừa khuyết tật
• Làm cho nó trở thành một thứ bản ngã nói rằng chỉ những lập trình viên tồi mới không
• Cuối tuần này, 2 thành viên trong nhóm phải đến làm việc vì mã của anh ấy có tham chiếu NULL và anh ấy đã không kiểm tra nó

Công việc của tôi yêu cầu mã ổn định chất lượng hàng đầu và thường mọi người đều 'hiểu được nó' và không cần phải thực hiện các bài kiểm tra. Chúng tôi biết chúng tôi có thể bắt anh ấy viết các bài kiểm tra, nhưng chúng tôi đều biết các bài kiểm tra hữu ích là những bài kiểm tra được viết khi bạn tham gia.

Bạn có biết thêm động lực nào không?

Đây là một trong những điều khó làm nhất. Yêu cầu mọi người của bạn có được nó .

Đôi khi một trong những cách tốt nhất để giúp các lập trình viên cấp cơ sở 'nắm bắt được điều đó' và học được các kỹ thuật phù hợp từ các tiền bối là thực hiện một chút lập trình theo cặp.

Hãy thử cách này: trong một dự án sắp tới, hãy ghép anh chàng cấp dưới với chính bạn hoặc một lập trình viên cấp cao khác. Họ nên làm việc cùng nhau, thay phiên nhau "lái xe" (là người gõ bàn phím của họ) và "huấn luyện" (nhìn qua vai của người lái xe và chỉ ra các đề xuất, sai lầm, v.v. khi họ thực hiện). Nó có vẻ như là một sự lãng phí tài nguyên, nhưng bạn sẽ thấy:

1. Rằng những người này cùng nhau có thể tạo ra mã nhanh và chất lượng cao hơn.
2. Nếu anh chàng cấp dưới của bạn học đủ cách để "đạt được điều đó" với một người đàn anh hướng dẫn anh ta đi theo con đường đúng đắn (ví dụ: "Được rồi, bây giờ trước khi chúng ta tiếp tục, hãy viết lúc thử nghiệm cho chức năng này.") Nó sẽ rất xứng đáng với tài nguyên bạn cam kết với nó.

Cũng có thể có ai đó trong nhóm của bạn đưa ra Bài kiểm tra Đơn vị 101 trình bày bài thuyết trình của Kate Rhodes, tôi nghĩ rằng đó là một cách tuyệt vời để khiến mọi người hào hứng với việc thử nghiệm, nếu được trình bày tốt.

Một điều khác bạn có thể làm là để các Jr. Devs của bạn thực hành Kata trò chơi Bowling , điều này sẽ giúp họ học Phát triển theo hướng kiểm tra. Nó có trong java, nhưng có thể dễ dàng điều chỉnh sang bất kỳ ngôn ngữ nào.

Xem lại mã trước mỗi lần cam kết (ngay cả khi đó là 1 phút "Tôi đã thay đổi tên biến này") và là một phần của quá trình đánh giá mã, hãy xem lại bất kỳ bài kiểm tra đơn vị nào.

Đừng ký vào cam kết cho đến khi các bài kiểm tra được thực hiện.

(Ngoài ra - Nếu công việc của anh ấy không được thử nghiệm - tại sao nó lại được sản xuất ngay từ đầu? Nếu nó không được thử nghiệm, đừng để nó vào, sau đó bạn sẽ không phải làm việc vào cuối tuần)

Đối với bản thân, tôi đã bắt đầu nhấn mạnh rằng mọi lỗi tôi tìm thấy và sửa được đều được thể hiện dưới dạng một bài kiểm tra:

1. "Hừ, không đúng..."
2. Tìm vấn đề có thể xảy ra
3. Viết một bài kiểm tra, cho thấy rằng mã không thành công
4. Khắc phục sự cố
5. Chứng tỏ rằng mã mới đã vượt qua
6. Lặp lại nếu sự cố ban đầu vẫn tiếp diễn

Tôi cố gắng làm điều này ngay cả khi đang đập phá mọi thứ và tôi hoàn thành trong khoảng thời gian tương tự, chỉ với bộ thử nghiệm một phần đã có sẵn.

(Tôi không sống trong môi trường lập trình thương mại và thường là lập trình viên duy nhất làm việc trong một dự án cụ thể.)

Hãy tưởng tượng tôi là một lập trình viên giả, tên là ... Marco. Hãy tưởng tượng tôi đã tốt nghiệp trường cách đây không lâu và chưa bao giờ thực sự phải viết bài kiểm tra. Hãy tưởng tượng tôi làm việc trong một công ty không thực sự thực thi hoặc yêu cầu điều này. ĐỒNG Ý? tốt! Bây giờ hãy tưởng tượng rằng công ty đang chuyển sang sử dụng các bài kiểm tra và họ đang cố gắng giúp tôi phù hợp với điều này. Tôi sẽ đưa ra phản ứng hơi gay gắt đối với các mục được đề cập cho đến nay, như thể tôi không thực hiện bất kỳ nghiên cứu nào về điều này.

Hãy bắt đầu với người tạo:

Cho thấy thiết kế trở nên đơn giản hơn.

Làm thế nào để có thể viết nhiều hơn, làm cho mọi thứ đơn giản hơn. Bây giờ tôi sẽ phải tiếp tục theo dõi các trường hợp khác, v.v. Điều này làm cho nó phức tạp hơn nếu bạn hỏi tôi. Cung cấp cho tôi các chi tiết vững chắc.

Hiển thị nó ngăn ngừa các khuyết tật.

Tôi biết điều đó. Đây là lý do tại sao chúng được gọi là thử nghiệm. Mã của tôi tốt và tôi đã kiểm tra nó để tìm các vấn đề, vì vậy tôi không biết những kiểm tra đó sẽ giúp ích được gì.

Làm cho nó trở thành một thứ bản ngã nói rằng chỉ những lập trình viên tồi mới không làm.

Ồ, vậy bạn nghĩ tôi là một lập trình viên tồi chỉ vì tôi không thực hiện nhiều thử nghiệm đã qua sử dụng. Tôi bị xúc phạm và rất khó chịu với bạn. Tôi muốn có sự hỗ trợ và hỗ trợ hơn là những lời nói.

@ Justin Standard : Khi bắt đầu triển vọng mới, hãy ghép đôi chàng trai cấp dưới với chính bạn hoặc một lập trình viên cấp cao khác.

Ồ, điều này rất quan trọng nên các nguồn lực sẽ được sử dụng để đảm bảo tôi thấy mọi thứ được thực hiện như thế nào và nhờ một số người hỗ trợ tôi về cách mọi thứ được thực hiện. Điều này rất hữu ích và tôi có thể bắt đầu làm nhiều hơn.

@ Justin Standard : Đọc bài thuyết trình Unit Testing 101 của Kate Rhodes.

Ahh, đó là một bài thuyết trình thú vị, và nó khiến tôi nghĩ về việc thử nghiệm. Nó nhấn mạnh một số điểm mà tôi nên xem xét, và nó có thể làm lung lay quan điểm của tôi một chút.

Tôi muốn xem nhiều bài báo hấp dẫn hơn và các công cụ khác để hỗ trợ tôi bắt kịp suy nghĩ đây là cách đúng đắn để làm mọi việc.

@ Dominic Cooney : Dành một chút thời gian và chia sẻ các kỹ thuật kiểm tra.

Ahh, điều này giúp tôi hiểu những gì được mong đợi ở tôi về kỹ thuật và nó giúp tôi có thêm nhiều thứ hơn trong túi kiến ​​thức mà tôi có thể sử dụng lại.

@ Dominic Cooney : Trả lời câu hỏi, ví dụ và sách.

Có một người chỉ dẫn (mọi người) để trả lời câu hỏi rất hữu ích, điều đó có thể khiến tôi có nhiều khả năng thử hơn. Những ví dụ điển hình thật tuyệt vời và nó mang lại cho tôi điều gì đó để hướng tới và điều gì đó để tham khảo. Sách liên quan trực tiếp đến vấn đề này là tài liệu tham khảo tuyệt vời.

@ Adam Hayle : Đánh giá bất ngờ.

Nói gì thì nói, bạn đã làm nảy sinh một thứ mà tôi hoàn toàn không chuẩn bị. Tôi cảm thấy không thoải mái với điều này, nhưng sẽ cố gắng hết sức. Bây giờ tôi sẽ sợ hãi và lo sợ nhẹ về điều này một lần nữa, cảm ơn bạn. Tuy nhiên, chiến thuật hù dọa có thể hiệu quả, nhưng nó phải trả giá. Tuy nhiên, nếu không có gì khác hoạt động, đây có thể chỉ là sự thúc đẩy cần thiết.

@ Rytmis : Các mục chỉ được coi là hoàn thành khi chúng có các trường hợp thử nghiệm.

Ồ, thú vị. Tôi thấy tôi thực sự phải làm điều này ngay bây giờ, nếu không tôi sẽ không hoàn thành bất cứ điều gì. Điều này thật ý nghĩa.

@ jmorris : Thoát khỏi / Hy sinh.

lườm, lườm, lườm - Có cơ hội tôi có thể học hỏi, và với sự hỗ trợ, giúp đỡ, tôi có thể trở thành một phần rất quan trọng và có chức năng trong nhóm. Đây là một trong những tật của tôi bây giờ, nhưng nó sẽ không lâu nữa. Tuy nhiên, nếu tôi không đạt được nó, tôi hiểu rằng tôi sẽ đi. Tôi nghĩ rằng tôi sẽ nhận được nó.

Cuối cùng, sự hỗ trợ của đội tôi đóng một vai trò quan trọng trong tất cả những điều này. Có một người dành thời gian của họ để hỗ trợ và giúp tôi bắt đầu có những thói quen tốt luôn được hoan nghênh. Sau đó, có một lưới hỗ trợ tốt sẽ là điều tuyệt vời. Sẽ luôn được đánh giá cao nếu có ai đó đến vài lần sau đó và xem qua một số đoạn mã, để xem mọi thứ đang diễn ra như thế nào, không phải trong một bài đánh giá mà là một chuyến thăm thân thiện.

Lập luận, Chuẩn bị, Giảng dạy, Theo dõi, Hỗ trợ.

Tôi nhận thấy rằng rất nhiều lập trình viên thấy giá trị của việc thử nghiệm ở mức độ hợp lý. Nếu bạn đã nghe những câu như "vâng, tôi biết tôi nên kiểm tra điều này nhưng tôi thực sự cần phải hoàn thành việc này nhanh chóng" thì bạn biết tôi muốn nói gì. Tuy nhiên, ở mức độ cảm xúc, họ cảm thấy rằng họ chỉ hoàn thành một việc gì đó khi họ đang viết mã thực.

Vì vậy, mục tiêu phải là bằng cách nào đó khiến họ hiểu rằng thực tế kiểm tra là cách duy nhất để đo lường khi nào đó "xong", và do đó tạo cho họ động lực nội tại để viết kiểm tra.

Tuy nhiên, tôi e rằng điều đó khó hơn rất nhiều. Bạn sẽ nghe thấy rất nhiều lời bào chữa dọc theo dòng "Tôi đang rất vội, tôi sẽ viết lại / cấu trúc lại điều này sau và sau đó thêm các bài kiểm tra" - và tất nhiên, việc theo dõi không bao giờ xảy ra bởi vì, đáng ngạc nhiên là họ 'tái giống như bận rộn tuần tới .

Đây là những gì tôi sẽ làm:

• Lần đầu tiên ... "chúng ta sẽ thực hiện dự án này cùng nhau. Tôi sẽ viết các bài kiểm tra và bạn sẽ viết mã. Hãy chú ý đến cách tôi viết các bài kiểm tra, vì đó là cách chúng ta làm quanh đây và đó là điều tôi mong đợi ở bạn. "

• Sau đó ... "Bạn đã hoàn thành? Tuyệt vời! Trước tiên, hãy xem các bài kiểm tra đang thúc đẩy sự phát triển của bạn. Ồ, không có bài kiểm tra nào? Hãy cho tôi biết khi điều đó hoàn thành và chúng tôi sẽ lên lịch lại để xem mã của bạn. Nếu bạn ' bạn đang cần trợ giúp để xây dựng các bài kiểm tra, hãy cho tôi biết và tôi sẽ giúp bạn. "

Anh ấy đã làm điều này. Có thật không. Anh ấy chỉ không viết nó ra. Không thuyết phục? Xem anh ấy trải qua chu kỳ phát triển tiêu chuẩn:

• Viết một đoạn mã
• Biên dịch nó
• Chạy để xem nó làm gì
• Viết đoạn mã tiếp theo

Bước # 3 là kiểm tra. Anh ấy đã thử nghiệm rồi, anh ấy chỉ làm thủ công. Hỏi anh ta câu này: "Làm thế nào để ngày mai bạn biết rằng mã từ hôm nay vẫn hoạt động?" Anh ta sẽ trả lời: "Đó là một lượng mã ít!"

Hỏi: "Thế còn tuần sau?"

Khi anh ấy chưa nhận được câu trả lời, hãy hỏi: "Bạn muốn chương trình của mình thông báo cho bạn như thế nào khi một thay đổi phá vỡ điều gì đó đã hoạt động ngày hôm qua?"

Đó là tất cả những gì về kiểm tra đơn vị tự động.

Là một lập trình viên cấp dưới, tôi vẫn đang cố gắng tập thói quen viết các bài kiểm tra. Rõ ràng là không dễ để có được thói quen mới, nhưng nghĩ về điều gì sẽ làm cho điều này hiệu quả với tôi, tôi phải +1 nhận xét về các bài đánh giá mã và huấn luyện / lập trình cặp.

Cũng có thể cần nhấn mạnh mục đích dài hạn của thử nghiệm: đảm bảo rằng những gì đã hoạt động ngày hôm qua vẫn hoạt động trong ngày hôm nay, tuần tới và tháng sau. Tôi chỉ nói vậy vì khi đọc lướt các câu trả lời, tôi không thấy điều đó được đề cập.

Khi thực hiện đánh giá mã (nếu bạn quyết định làm điều đó), hãy đảm bảo rằng nhà phát triển trẻ của bạn biết điều đó không phải là hạ gục anh ta, mà là làm cho mã tốt hơn. Bởi vì như vậy sự tự tin của anh ấy sẽ ít bị tổn hại hơn. Và đó là điều quan trọng. Mặt khác, biết bao nhiêu bạn biết ít cũng vậy.

Tất nhiên, tôi không thực sự biết bất cứ điều gì. Nhưng tôi hy vọng những lời đã được hữu ích.

Chỉnh sửa: [ Justin Standard ]

Đừng hạ thấp bản thân, những gì bạn phải nói là khá nhiều.

Về quan điểm của bạn về đánh giá mã: điều bạn sẽ thấy là không chỉ các nhà phát triển cơ sở sẽ học hỏi trong quá trình này, mà cả những người đánh giá cũng vậy. Mọi người trong bài đánh giá mã sẽ tìm hiểu xem bạn có biến nó thành một quá trình cộng tác hay không.

Thành thật mà nói, nếu bạn đang phải đặt điều đó nhiều nỗ lực vào việc anh ta làm một cái gì đó sau đó bạn có thể phải đi đến thỏa thuận với ý nghĩ rằng anh ta có thể chỉ không phù hợp tốt cho đội bóng, và có thể cần phải đi. Bây giờ, điều này không nhất thiết có nghĩa là sa thải anh ta ... nó có thể có nghĩa là tìm một nơi khác trong công ty mà kỹ năng của anh ta phù hợp hơn. Nhưng nếu không có nơi nào khác ... bạn biết phải làm gì.

Tôi giả định rằng anh ấy cũng là một nhân viên mới tuyển dụng (<1 năm) và có lẽ gần đây đã ra trường ... trong trường hợp đó, anh ấy có thể không quen với cách mọi thứ hoạt động trong môi trường công ty. Những thứ như thế hầu hết chúng ta có thể bỏ qua khi học đại học.

Nếu đúng như vậy, một điều tôi thấy có tác dụng là có một loại "đánh giá tuyển dụng mới bất ngờ." Nó không quan trọng nếu bạn chưa bao giờ làm điều đó trước đây ... anh ấy sẽ không biết điều đó. Chỉ cần cho anh ấy ngồi xuống và nói với anh ấy rằng bạn sẽ xem lại màn trình diễn của anh ấy và cho anh ấy xem một số con số thực ... hãy lấy bảng đánh giá bình thường của bạn (bạn có quy trình đánh giá chính thức phải không?) Và thay đổi tiêu đề nếu bạn muốn. chính thức và cho anh ta thấy anh ta đứng ở đâu. Nếu bạn cho anh ấy thấy trong một bối cảnh trang trọng rằng việc không làm bài kiểm tra sẽ ảnh hưởng xấu đến xếp hạng hiệu suất của anh ấy thay vì chỉ "cằn nhằn" anh ấy về điều đó, anh ấy hy vọng sẽ nhận được điểm. Bạn phải cho anh ta thấy rằng hành động của anh ta sẽ thực sự ảnh hưởng đến anh ta, dù là trả giá khôn ngoan hay cách khác.

Tôi biết, bạn có thể muốn tránh làm điều này vì nó không phải là chính thức ... nhưng tôi nghĩ bạn có lý do để làm điều đó và nó có lẽ sẽ rẻ hơn rất nhiều so với việc phải sa thải anh ta và tuyển dụng một người mới.

Bản thân là một lập trình viên cấp dưới, tôi nghĩ rằng Id sẽ tiết lộ cảm giác như thế nào khi tôi thấy mình ở trong tình huống tương tự như nhà phát triển cấp dưới của bạn.

Khi tôi lần đầu tiên ra khỏi uni, tôi thấy rằng nó hoàn toàn không trang bị cho tôi để đối phó với thế giới thực. Vâng, tôi biết một số điều cơ bản về JAVA và một số triết lý (đừng hỏi) nhưng đó là về nó. Khi lần đầu tiên tôi nhận được công việc của mình, điều đó có thể nói là hơi nản lòng. Hãy để tôi nói với bạn rằng tôi có lẽ là một trong những cao bồi lớn nhất xung quanh, tôi sẽ hack cùng nhau một bản sửa lỗi / thuật toán nhỏ mà không có nhận xét / thử nghiệm / tài liệu và vận chuyển nó ra khỏi cửa.

Tôi đã may mắn được dưới sự giám sát của một lập trình viên cấp cao tốt bụng và rất kiên nhẫn. Thật may mắn cho tôi, anh ấy đã quyết định ngồi lại với tôi và dành 1-2 tuần để xem lại mã togethor bị tấn công của tôi. Anh ấy sẽ giải thích tôi đã sai ở đâu, điểm tốt hơn của c và con trỏ (cậu bé đã làm tôi bối rối!). Chúng tôi đã viết được một lớp / mô-đun khá tốt trong khoảng một tuần. Tất cả những gì tôi có thể nói là nếu các nhà phát triển cấp cao không đầu tư thời gian để giúp tôi đi đúng con đường, có lẽ tôi đã không trụ được lâu.

Thật hạnh phúc, 2 năm sau, tôi hy vọng rằng một số đồng nghiệp của tôi thậm chí có thể coi tôi là một lập trình viên trung bình.

Nhận điểm về nhà

1. Hầu hết các trường Đại học đều rất kém trong việc chuẩn bị cho sinh viên bước vào thế giới thực
2. Lập trình cặp đôi thực sự đã giúp tôi. Không có nghĩa là nó sẽ giúp ích cho tất cả mọi người nhưng nó đã làm việc cho tôi.

Chỉ định chúng cho các dự án không yêu cầu "mã ổn định chất lượng hàng đầu" nếu đó là mối quan tâm của bạn và để jr. nhà phát triển thất bại. Yêu cầu họ là người 'đến vào cuối tuần' để sửa lỗi của họ. Ăn trưa thật nhiều và nói về các thực hành phát triển phần mềm (không phải các bài giảng, mà là các cuộc thảo luận). Theo thời gian, họ sẽ tiếp thu và phát triển các phương pháp hay nhất để thực hiện nhiệm vụ mà họ được giao.

Biết đâu, họ thậm chí có thể nghĩ ra thứ gì đó tốt hơn những kỹ thuật mà nhóm của bạn hiện đang sử dụng.

Nếu lập trình viên cơ sở, hoặc bất kỳ ai, không nhìn thấy giá trị trong thử nghiệm, thì sẽ rất khó để khiến họ làm điều đó ... kỳ.

Tôi đã khiến các lập trình viên cấp dưới hy sinh cuối tuần của họ để sửa lỗi. Hành động của anh ấy (hoặc thiếu) không ảnh hưởng trực tiếp đến anh ấy. Ngoài ra, hãy làm rõ rằng anh ta sẽ không thấy thăng tiến và / hoặc tăng lương nếu anh ta không cải thiện kỹ năng của mình trong việc kiểm tra.

Cuối cùng, ngay cả với tất cả sự giúp đỡ, động viên, cố vấn của bạn, anh ấy có thể không phù hợp với nhóm của bạn, vì vậy hãy để anh ấy đi và tìm kiếm một người có được điều đó.

Tôi thứ hai nhận xét của RodeoClown về mã xem xét mọi cam kết. Sau khi làm xong một vài lần, anh ấy sẽ có thói quen thử nghiệm mọi thứ.

Tôi không biết liệu bạn có cần chặn các cam kết như vậy không. Tại nơi làm việc của tôi, mọi người đều có cam kết miễn phí đối với mọi thứ, và tất cả các thông báo cam kết của SVN (có khác biệt) đều được gửi qua email cho nhóm.

Lưu ý: bạn thực sự muốn có addon khác biệt màu sấm sét nếu bạn định làm điều này.

Sếp của tôi hoặc bản thân tôi (2 lập trình viên 'cấp cao') sẽ đọc hết các cam kết và nếu có bất kỳ nội dung nào như "bạn quên thêm bài kiểm tra đơn vị", chúng tôi chỉ cần lướt qua email hoặc trò chuyện với người đó, giải thích lý do tại sao họ kiểm tra đơn vị cần thiết hoặc bất cứ điều gì. Mọi người khác cũng được khuyến khích đọc cam kết, vì đó là một cách tuyệt vời để xem những gì đang xảy ra, nhưng các nhà phát triển cấp dưới không bình luận nhiều.

Bạn có thể giúp khuyến khích mọi người có thói quen này bằng cách định kỳ nói những câu như "Này, bob, bạn có thấy lời cam kết mà tôi đã thực hiện sáng nay không, tôi đã tìm thấy mẹo nhỏ này mà bạn có thể làm bất cứ điều gì, hãy đọc bản cam kết và xem làm thế nào nó hoạt động!"

NB: Chúng tôi có 2 nhà phát triển 'cấp cao' và 3 nhà phát triển cấp dưới. Điều này có thể không mở rộng quy mô hoặc bạn có thể cần phải điều chỉnh quy trình một chút với nhiều nhà phát triển hơn.

1. Hãy đưa mã trở thành một phần của các bài đánh giá.
2. Đặt "viết một bài kiểm tra cho thấy lỗi" là điều kiện tiên quyết để sửa lỗi.
3. Yêu cầu một mức độ bao phủ nhất định trước khi mã có thể được đăng ký.
4. Tìm một cuốn sách hay về phát triển theo hướng kiểm tra và sử dụng nó để chỉ ra cách người thử nghiệm có thể tăng tốc độ phát triển.

Rất nhiều tâm lý học và các kỹ thuật "cố vấn" hữu ích, nhưng thành thật mà nói, điều này chỉ tóm gọn lại là "viết bài kiểm tra nếu bạn muốn vẫn có việc làm vào ngày mai."

Bạn có thể sử dụng bất cứ điều gì mà bạn cho là phù hợp, khắc nghiệt hay mềm mại, điều đó không quan trọng. Nhưng thực tế là, các lập trình viên không được trả tiền để chỉ ném mã và kiểm tra nó - họ được trả tiền để đặt mã cẩn thận lại với nhau, sau đó đặt các bài kiểm tra cùng nhau, sau đó kiểm tra mã của họ, SAU ĐÓ kiểm tra toàn bộ. (Ít nhất đó là những gì nó giống như, từ mô tả của bạn.)

Do đó, nếu ai đó định từ chối làm công việc của họ, hãy giải thích với họ rằng họ có thể ở nhà, ngày mai và bạn sẽ thuê một người SẼ làm công việc đó.

Một lần nữa, bạn có thể làm tất cả những điều này một cách nhẹ nhàng, nếu bạn nghĩ điều đó là cần thiết, nhưng rất nhiều người chỉ cần một cú tát mạnh của Life In The Real World , và bạn sẽ giúp họ bằng cách đưa nó cho họ.

Chúc may mắn.

Thay đổi mô tả công việc của anh ấy trong một thời gian để chỉ viết các bài kiểm tra và duy trì các bài kiểm tra. Tôi nghe nói rằng nhiều công ty làm điều này cho những người mới bắt đầu thiếu kinh nghiệm trong một thời gian khi họ bắt đầu.

Ngoài ra, hãy đưa ra một thử thách khi anh ấy đảm nhiệm vai trò đó: Viết các bài kiểm tra sẽ a) không thành công trên mã hiện tại a) đáp ứng các yêu cầu của phần mềm. Hy vọng rằng nó sẽ khiến anh ấy tạo ra một số bài kiểm tra chắc chắn và kỹ lưỡng (cải thiện dự án) và giúp anh ấy viết bài kiểm tra tốt hơn khi anh ấy hòa nhập lại vào phát triển cốt lõi.

chỉnh sửa> đáp ứng đầy đủ các yêu cầu của phần mềm có nghĩa là anh ta không chỉ viết các bài kiểm tra để cố tình phá mã khi mã không bao giờ có ý định hoặc cần thiết để tính đến trường hợp kiểm thử đó.

Nếu đồng nghiệp của bạn thiếu kinh nghiệm viết bài kiểm tra, có thể họ đang gặp khó khăn trong quá trình kiểm tra ngoài các tình huống đơn giản, và điều đó thể hiện là kiểm tra không đầy đủ. Đây là những gì tôi sẽ thử:

• Dành một chút thời gian và chia sẻ các kỹ thuật kiểm tra, chẳng hạn như tiêm phụ thuộc, tìm kiếm các trường hợp cạnh, v.v. với đồng nghiệp của bạn.
• Đề nghị trả lời các câu hỏi về thử nghiệm.
• Thực hiện đánh giá mã của các bài kiểm tra trong một thời gian. Yêu cầu đồng nghiệp của bạn xem xét những thay đổi của bạn để làm gương cho việc kiểm tra tốt. Xem nhận xét của họ để biết liệu họ có thực sự đọc và hiểu mã thử nghiệm của bạn hay không.
• Nếu có cuốn sách đặc biệt phù hợp với triết lý thử nghiệm của nhóm bạn, hãy cho họ một bản sao. Nó có thể hữu ích nếu phản hồi hoặc cuộc thảo luận đánh giá mã của bạn tham khảo cuốn sách để họ có một chuỗi để chọn và theo dõi.

Tôi sẽ không đặc biệt nhấn mạnh đến yếu tố xấu hổ / tội lỗi. Cần phải chỉ ra rằng kiểm tra là một thực tiễn tốt được áp dụng rộng rãi và việc viết và duy trì các bài kiểm tra tốt là một phép lịch sự chuyên nghiệp, vì vậy các đồng nghiệp trong nhóm của bạn không cần dành thời gian cuối tuần tại nơi làm việc, nhưng tôi sẽ không tin vào những điểm đó.

Nếu bạn thực sự cần phải "cứng rắn" thì hãy thiết lập một hệ thống công bằng; không ai thích cảm giác như họ bị đơn lẻ. Ví dụ: nhóm của bạn có thể yêu cầu mã để duy trì một mức độ phù hợp thử nghiệm nhất định (có thể được đánh bạc, nhưng ít nhất có thể được tự động); yêu cầu mã mới có các bài kiểm tra; yêu cầu người đánh giá xem xét chất lượng các bài kiểm tra khi thực hiện rà soát mã; và như thế. Việc thiết lập hệ thống đó nên đến từ sự đồng thuận của cả nhóm. Nếu bạn kiểm duyệt cuộc thảo luận một cách cẩn thận, bạn có thể phát hiện ra những lý do cơ bản khác mà thử nghiệm của đồng nghiệp không như bạn mong đợi.

Người cố vấn của anh ấy có trách nhiệm Dạy cho anh ấy / cô ấy. Bạn đang dạy anh ấy / cô ấy cách kiểm tra tốt như thế nào. Bạn có lập trình cặp với anh ấy không? Nhiều khả năng Junior không biết LÀM THẾ NÀO để thiết lập một bài kiểm tra tốt cho xyz.

Là một học sinh mới ra trường, cậu ấy biết nhiều khái niệm. Một số kỹ thuật. Một số kinh nghiệm. Nhưng cuối cùng, tất cả một Junior đều là TIỀM NĂNG. Hầu hết mọi tính năng mà họ làm việc, sẽ có một cái gì đó mới mà họ chưa từng làm trước đây. Chắc chắn rằng Junior có thể đã thực hiện một mô hình Trạng thái đơn giản cho một dự án trong lớp, mở và đóng các "cánh cửa", nhưng không bao giờ là một ứng dụng thực tế của các mô hình này.

Anh ấy / cô ấy sẽ chỉ tốt như cách bạn dạy. Nếu họ có thể "Just get it", bạn có nghĩ rằng họ sẽ đảm nhận vị trí Junior ngay từ đầu không?

Theo kinh nghiệm của tôi, Juniors được thuê và chịu trách nhiệm gần giống như Seniors, nhưng chỉ được trả ít hơn và sau đó bị bỏ qua khi họ bắt đầu chùn bước. Hãy tha thứ cho tôi nếu tôi có vẻ cay đắng, đó là vì tôi là vậy.

@ jsmorris

Tôi đã từng bị nhà phát triển cấp cao và "kiến trúc sư" mắng mỏ tôi và một người kiểm tra (đó là công việc đầu tiên của tôi khi ra trường) trong email vì đã không ở lại muộn và hoàn thành một nhiệm vụ "dễ dàng" như vậy vào đêm hôm trước. Chúng tôi đã ở đó cả ngày và gọi là nó ngừng hoạt động lúc 7 giờ tối, tôi đã cố gắng từ 11 giờ sáng trước bữa trưa ngày hôm đó và đã quấy rầy mọi thành viên trong nhóm của chúng tôi để được giúp đỡ ít nhất hai lần.

Tôi đã trả lời và nhắn tin cho nhóm với: "Tôi đã thất vọng về bạn trong một tháng nay. Tôi không bao giờ nhận được sự giúp đỡ từ nhóm. Tôi sẽ ở quán cà phê bên kia đường nếu bạn cần. Tôi xin lỗi, tôi không thể gỡ lỗi tham số 12, phương thức 800 dòng mà hầu như mọi thứ đều phụ thuộc vào. "

Sau khi giải nhiệt ở quán cà phê trong một giờ, tôi trở lại văn phòng, cầm lấy đồ đạc của mình và rời đi. Sau một vài ngày, họ gọi cho tôi hỏi tôi có vào không, tôi nói tôi có nhưng tôi có một cuộc phỏng vấn, có thể là ngày mai.

"Vậy cậu bỏ cuộc rồi à?"

Trên kho lưu trữ nguồn của bạn: sử dụng hook trước mỗi lần commit (ví dụ: pre-commit hook cho SVN)

Trong hook đó, hãy kiểm tra sự tồn tại của ít nhất một ca sử dụng cho mỗi phương thức. Sử dụng quy ước cho tổ chức kiểm tra đơn vị mà bạn có thể dễ dàng thực thi thông qua hook cam kết trước.

Trên máy chủ tích hợp, biên dịch mọi thứ và kiểm tra thường xuyên phạm vi kiểm tra bằng công cụ kiểm tra phạm vi. Nếu phạm vi kiểm tra không phải là 100% cho một mã, hãy chặn bất kỳ cam kết nào của nhà phát triển. Anh ấy sẽ gửi cho bạn trường hợp thử nghiệm bao gồm 100% mã.

Chỉ kiểm tra tự động mới có thể mở rộng quy mô tốt trên một dự án. Bạn không thể kiểm tra mọi thứ bằng tay.

Nhà phát triển nên có phương tiện để kiểm tra xem các trường hợp thử nghiệm của mình có bao gồm 100% mã hay không. Bằng cách đó, nếu anh ta không cam kết mã đã được kiểm tra 100%, đó là lỗi của anh ta, không phải lỗi "rất tiếc, tôi đã quên".

Hãy nhớ rằng: Mọi người không bao giờ làm những gì bạn mong đợi, họ luôn làm những gì bạn kiểm tra.

Trước hết, giống như hầu hết những người được hỏi ở đây chỉ ra, nếu anh ta không thấy giá trị của việc thử nghiệm, bạn sẽ không thể làm được gì nhiều và bạn đã chỉ ra rằng bạn không thể sa thải anh ta. Tuy nhiên, thất bại không phải là một lựa chọn ở đây, vậy còn một số điều bạn có thể làm thì sao?

Nếu tổ chức của bạn đủ lớn để có hơn 6 nhà phát triển, tôi thực sự khuyên bạn nên có bộ phận Đảm bảo chất lượng (ngay cả khi bộ phận này chỉ là một người để bắt đầu). Tốt nhất, bạn nên có tỷ lệ 1 người thử nghiệm với 3 - 5 nhà phát triển. Vấn đề về lập trình viên là ... họ là người lập trình, không phải người kiểm thử. Tôi vẫn chưa phỏng vấn một lập trình viên đã được chính thức dạy các kỹ thuật QA thích hợp.

Hầu hết các tổ chức đều mắc phải sai sót nghiêm trọng khi chỉ định vai trò thử nghiệm cho người mới thuê, người có số lượng tiếp xúc với mã của bạn ÍT NHẤT - lý tưởng nhất là các nhà phát triển cấp cao nên chuyển sang vai trò QA vì họ có kinh nghiệm về mã , và (hy vọng) đã phát triển giác quan thứ sáu về mùi mã và điểm lỗi có thể tăng lên.

Hơn nữa, lập trình viên mắc lỗi có thể sẽ không tìm ra lỗi vì nó thường không phải là lỗi cú pháp (những lỗi đó được chọn trong trình biên dịch), mà là lỗi logic - và logic tương tự cũng hoạt động khi họ viết kiểm tra như khi họ viết mã. Đừng nhờ người đã phát triển mã kiểm tra mã đó - họ sẽ tìm thấy ít lỗi hơn bất kỳ ai khác.

Trong trường hợp của bạn, nếu bạn có thể chi trả cho nỗ lực làm việc được chuyển hướng, hãy biến anh chàng mới này trở thành thành viên đầu tiên trong nhóm QA của bạn. Hãy mời anh ấy đọc "Kiểm thử phần mềm trong thế giới thực: Cải tiến quy trình", vì rõ ràng anh ấy sẽ cần một số khóa đào tạo trong vai trò mới của mình. Nếu anh ấy không thích, anh ấy sẽ nghỉ việc và vấn đề của bạn vẫn được giải quyết.

Một cách tiếp cận ít mang tính trả thù hơn một chút là để người này làm những gì họ giỏi (tôi cho rằng người này được tuyển dụng vì họ thực sự có năng lực trong phần lập trình của công việc) và thuê một hoặc hai người thử nghiệm để thực hiện thử nghiệm ( Sinh viên đại học thường có thuật ngữ thực tế hoặc "co-op", rất thích tiếp xúc và rẻ)

Lưu ý phụ: Cuối cùng, bạn sẽ muốn nhóm QA báo cáo cho giám đốc QA hoặc ít nhất là không báo cáo cho người quản lý nhà phát triển phần mềm, bởi vì việc nhóm QA báo cáo cho người quản lý, người mà mục tiêu chính của họ là hoàn thành sản phẩm là một xung đột quan tâm.

Nếu tổ chức của bạn nhỏ hơn 6 hoặc bạn không thể tạo nhóm mới, tôi khuyên bạn nên lập trình theo cặp (PP). Tôi không phải là người chuyển đổi hoàn toàn tất cả các kỹ thuật lập trình cực đoan, nhưng tôi chắc chắn là một người tin tưởng vào lập trình ghép nối. Tuy nhiên, cả hai thành viên của nhóm lập trình được ghép nối đều phải chuyên tâm, hoặc đơn giản là nó không hoạt động. Họ phải tuân theo hai quy tắc: người kiểm tra phải hiểu đầy đủ những gì đang được mã hóa trên màn hình hoặc anh ta phải yêu cầu người viết mã giải thích nó; người lập trình chỉ có thể viết mã những gì anh ta có thể giải thích - không có "bạn sẽ thấy" hoặc "tin tưởng tôi" hoặc vẫy tay sẽ không được chấp nhận.

Tôi chỉ đề xuất PP nếu nhóm của bạn có khả năng làm việc đó, bởi vì, giống như thử nghiệm, không có sự cổ vũ hay đe dọa nào có thể thuyết phục một vài người hướng nội đầy bản ngã làm việc cùng nhau nếu họ không cảm thấy thoải mái khi làm như vậy. Tuy nhiên, tôi thấy rằng giữa lựa chọn viết các thông số kỹ thuật chức năng chi tiết và thực hiện đánh giá mã so với lập trình ghép nối, PP thường chiến thắng.

Nếu PP không dành cho bạn, thì TDD là lựa chọn tốt nhất của bạn, nhưng chỉ khi nó được hiểu theo nghĩa đen. Test Driven Development có nghĩa là bạn viết các bài kiểm tra ĐẦU TIÊN, chạy các bài kiểm tra để chứng minh rằng chúng thực sự thất bại, sau đó viết mã đơn giản nhất để làm cho nó hoạt động. Sự đánh đổi là bây giờ bạn (nên) có một bộ sưu tập hàng nghìn bài kiểm tra, cũng là mã và cũng giống như mã sản xuất có chứa lỗi. Thành thật mà nói, tôi không phải là một fan hâm mộ lớn của TDD, chủ yếu là vì lý do này, nhưng nó hoạt động đối với nhiều nhà phát triển, những người thà viết kịch bản thử nghiệm hơn là tài liệu trường hợp thử nghiệm - một số thử nghiệm tốt hơn là không có. Kết hợp TDD với PP để có khả năng bao phủ thử nghiệm tốt hơn và ít lỗi hơn trong tập lệnh.

Nếu vẫn thất bại, hãy để các lập trình viên tương đương với một cái lọ thề - mỗi khi lập trình viên phá vỡ bản dựng, họ phải bỏ 20 đô la, 50 đô la, 100 đô la (bất kỳ điều gì gây khó khăn vừa phải cho nhân viên của bạn) vào một chiếc lọ mà bạn yêu thích ( đã đăng ký!) tổ chức từ thiện. Cho đến khi họ trả tiền, hãy tránh xa họ :)

Bỏ tất cả chuyện đùa sang một bên, cách tốt nhất để khiến lập trình viên của bạn viết các bài kiểm tra là đừng để anh ta lập trình. Nếu bạn muốn một lập trình viên, hãy thuê một lập trình viên - Nếu bạn muốn các bài kiểm tra, hãy thuê một người kiểm tra. Tôi bắt đầu với tư cách là một lập trình viên cơ sở 12 năm trước khi làm thử nghiệm, và nó đã trở thành con đường sự nghiệp của tôi, và tôi sẽ không đánh đổi nó để lấy bất cứ thứ gì. Một bộ phận QA vững chắc được nuôi dưỡng đúng cách và được trao quyền lực cũng như nhiệm vụ để cải tiến phần mềm cũng có giá trị như những nhà phát triển viết phần mềm ngay từ đầu.

Điều này có thể hơi vô tâm, nhưng cách bạn mô tả tình huống có vẻ như bạn cần sa thải anh chàng này. Hoặc ít nhất hãy nói rõ: từ chối tuân theo các thông lệ phát triển nội bộ (bao gồm cả việc viết thử nghiệm) và kiểm tra mã lỗi mà người khác phải dọn dẹp cuối cùng sẽ khiến bạn bị sa thải.

Lý do chính khiến các kỹ sư / lập trình viên cơ sở không mất nhiều thời gian để thiết kế và thực hiện các tập lệnh thử nghiệm, là vì hầu hết các chứng chỉ CS không yêu cầu quá nhiều về điều này, vì vậy các lĩnh vực kỹ thuật khác được đề cập nhiều hơn trong các chương trình đại học, chẳng hạn như bằng thiết kế.

Theo kinh nghiệm của tôi, cách tốt nhất để các chuyên gia cấp dưới có thói quen là biến nó thành một phần của quy trình một cách rõ ràng. Có nghĩa là, khi ước tính thời gian cần thực hiện một lần lặp, thời gian thiết kế, viết và / hoặc thực hiện các trường hợp phải được kết hợp vào ước tính thời gian này.

Cuối cùng, việc xem xét thiết kế kịch bản thử nghiệm nên là một phần của quá trình xem xét thiết kế và mã thực tế nên được xem xét trong phần đánh giá mã. Điều này khiến lập trình viên có trách nhiệm thực hiện kiểm tra thích hợp từng dòng mã mà họ viết, đồng thời kỹ sư cấp cao và các đồng nghiệp có trách nhiệm cung cấp phản hồi và hướng dẫn về mã và bài kiểm tra được viết.

Dựa trên nhận xét của bạn, "Cho thấy rằng thiết kế trở nên đơn giản hơn" Tôi giả sử các bạn thực hành TDD. Thực hiện đánh giá mã sau khi thực tế sẽ không hoạt động. Toàn bộ điều về TDD là nó là một thiết kế chứ không phải một triết lý thử nghiệm. Nếu anh ta không viết các bài kiểm tra như một phần của thiết kế, bạn sẽ không nhận được nhiều lợi ích từ việc viết các bài kiểm tra sau khi thực tế - đặc biệt là từ một nhà phát triển cơ sở. Cuối cùng anh ta sẽ bỏ lỡ rất nhiều trường hợp góc và mã của anh ta sẽ vẫn còn tồi tệ.

Đặt cược tốt nhất của bạn là có một nhà phát triển cấp cao rất kiên nhẫn ngồi với anh ta và thực hiện một số lập trình cặp. Và cứ tiếp tục cho đến khi anh ấy học được. Hoặc không học, trong trường hợp đó, bạn cần phải giao lại cho anh ta một nhiệm vụ mà anh ta phù hợp hơn bởi vì bạn sẽ chỉ khiến các nhà phát triển thực sự của mình thất vọng.

Không phải ai cũng có tài năng và / hoặc động lực như nhau. Các nhóm phát triển, thậm chí cả những nhóm nhanh nhẹn, bao gồm những người thuộc "Nhóm A" và những người thuộc "Nhóm B". Các thành viên A-Team là người thiết kế ra giải pháp, viết tất cả các mã sản xuất không tầm thường và giao tiếp với các chủ doanh nghiệp - tất cả các công việc đòi hỏi tư duy bên ngoài. B-Team xử lý những việc như quản lý cấu hình, viết kịch bản, sửa lỗi khập khiễng và thực hiện công việc bảo trì - tất cả những công việc có quy trình nghiêm ngặt dẫn đến những hậu quả nhỏ nếu thất bại.