Là một lập trình viên được cho là tự túc?


28

Tại nơi làm việc hiện tại của tôi, chúng tôi không có bất kỳ người thử nghiệm nào, lý do căn bản của quản lý là: "nếu chúng tôi có người kiểm tra, bạn sẽ không kiểm tra mã của riêng bạn". Kiểu suy nghĩ này dường như gây bất lợi cho chất lượng sản phẩm, vì trong khi tôi kiểm tra mã của riêng mình, có rất nhiều điều tôi sẽ bỏ lỡ chỉ vì tôi biết hệ thống bên trong và không biết cách sử dụng nó sai rồi". Thử nghiệm hộp đen không thực sự hiệu quả khi tôi vô thức tránh những cạm bẫy mà một người thử nghiệm chuyên dụng sẽ rơi vào. Rất nhiều thời gian của tôi dành cho việc sửa các lỗi đã chuyển sang mã sản xuất và được tìm thấy bởi người dùng cuối.

Hệ thống trong câu hỏi là lớn nhưng chỉ được phát triển bởi tôi. Điều này cũng đã khiến một số nhiệm vụ quản lý rơi vào lòng tôi, chẳng hạn như xác định lịch trình và làm việc trên các thông số kỹ thuật.

Những loại nhiệm vụ này có phải là trách nhiệm của tôi? Tôi thấy mình nghiêm túc như một lập trình viên và không có gì khác. Và nếu đây là trách nhiệm của tôi, ở mức độ nào? Khi một dự án lớn đến mức nó đòi hỏi người thử nghiệm? Một lập trình viên có nên tinh chỉnh đặc tả, lo lắng về việc quản lý dự án hoặc thậm chí cung cấp hỗ trợ khách hàng?

chú thích

Một số người có thể có ấn tượng rằng tôi chống lại việc mở rộng trách nhiệm của mình - đó không phải là trường hợp, tôi rất mong muốn nhận được một vai trò liên quan đến nhiều nhiệm vụ quản lý hơn, nhưng hiện tại nó không có trong mô tả công việc của tôi. Cho đến khi tôi chính thức được tuyển dụng như vậy hoặc các nhiệm vụ bổ sung bắt đầu hiển thị trong tiền lương của tôi, tôi sẽ nghĩ mình là "chỉ là" một lập trình viên. Thật không may, là một nhà phát triển cơ sở, việc chuyển sang nhiệm vụ quản lý sẽ không xảy ra sớm.

Câu trả lời tuyệt vời cho đến nay, hãy để chúng đến nếu bạn có điều gì đó để thêm hoặc kinh nghiệm cá nhân để chia sẻ!


4
Ah, kịch bản "người dùng thử nghiệm" cũ tốt. Tôi biết nó tốt.
Matt Ellen

Tôi xin lỗi tôi phải nói với bạn điều này nhưng..Quản lý của bạn đầy những kẻ ngốc :(
dr Hannibal Lecter

1
Công ty bạn làm việc lớn đến mức nào? Nếu họ đã thuê một người thử nghiệm, liệu có đủ công việc để khiến họ bận rộn toàn thời gian không? Nếu họ thuê một người quản lý dự án, liệu có đủ công việc để khiến họ bận rộn toàn thời gian không? Những công việc mà tôi phải tự mình quản lý những thứ như thế là những công ty không đủ lớn để biện minh cho một nhân viên khác đảm nhận những vai trò đó.
Carson63000

@ Carson6300, hiện tại chúng tôi có 7 lập trình viên đều làm việc quá sức và cùng số lượng thiết kế đồ họa. Chúng tôi cũng làm có người quản lý dự án, ít nhất là trong một số ý nghĩa của từ này. Như tôi đã nói, '.. đã thực hiện một số nhiệm vụ quản lý ..'; hầu hết việc quản lý vẫn được thực hiện bởi người quản lý dự án. Tôi nghĩ chúng ta đủ lớn để biện minh cho những người thử nghiệm chuyên dụng.
Tatu Ulmanen

Có lẽ, bạn cần trình bày cho quản lý của mình bài viết sau: Điều hòa hoạt động bằng lỗi phần mềm
Vaibhav Garg

Câu trả lời:


19

Bạn làm có xét nghiệm. Chỉ, bạn gọi họ là "người dùng cuối." Điều này gây bất lợi cho tất cả các lý do bạn mô tả; cho dù bạn là một lập trình viên có lương tâm đến mức nào, bạn chỉ đơn giản là sẽ không bao giờ có thể làm một công việc đủ tốt để vượt qua những định kiến ​​của riêng bạn về cách sử dụng mã "để" tìm ra tất cả các cách mà nó có thể làm hỏng .

Bạn cần mở lại vấn đề này với quản lý. Đến thời điểm này, có vẻ như bạn có một số dữ liệu cứng để hỗ trợ cho trường hợp của bạn; phương pháp tiếp cận hiện tại để đảm bảo chất lượng vừa lãng phí thời gian của bạn vừa làm ảnh hưởng đến trải nghiệm của người dùng. Bạn cần cẩn thận trong cách bạn trình bày vấn đề này để rõ ràng đây là một vấn đề cấu trúc và không phải là trường hợp "Bạn chỉ cần thử nghiệm", nhưng có vẻ như một cuộc thảo luận cần phải xảy ra.

Có vẻ như bạn đang đến ngã tư với nhà tuyển dụng này. Nếu bạn có ý định duy trì một lập trình viên và không có gì khác, bạn có thể cần phải bắt đầu đẩy lùi và yêu cầu họ bắt đầu giúp bạn một số công việc quản lý khỏi đĩa của bạn, bằng cách đưa ai đó mới hoặc bằng cách mở rộng trách nhiệm của đồng nghiệp hiện có. ("Đây không phải là những gì bạn thuê tôi và những nhiệm vụ này sẽ không biến mất. Thời gian tôi dành cho việc này không tốt là thời gian tôi không dành cho những gì tôi giỏi.") Nhưng điều đó có thể hoặc có thể không thực tế Bạn có nghĩ rằng bạn có thể xử lý việc chuyển sang vai trò quản lý nhiều hơn nếu họ cung cấp cho bạn các nguồn lực và quyền hạn mà bạn cần để hoàn thành công việc phải không?

Dự án cần lớn đến mức nào trước khi cần người kiểm tra, tôi không chắc làm thế nào để xác định chính xác dòng đó, nhưng tôi chắc chắn nghĩ rằng bạn đã vượt qua nó. Bạn đang dành nhiều thời gian hơn bạn muốn sửa các báo cáo lỗi đến từ người dùng thực tế; với tôi rằng đã đến lúc phải dành nhiều nỗ lực hơn để ngăn chặn lỗi đến với người dùng ngay từ đầu.


Nói rất nhiều, tôi đã làm việc ở rất nhiều nơi mà ông chủ nghĩ rằng nhà phát triển phải kiểm thử phần mềm, không phải nơi nào là nơi làm việc tốt, nếu công ty không có người kiểm tra thì họ chỉ không nắm bắt được những điều cơ bản về phát triển phần mềm hoặc là những kẻ khốn , dù bằng cách nào bạn cũng nên tìm một công việc khác
jonathan

13

Vâng. Nếu bạn phải , bạn sẽ có thể kiểm tra mã của bạn. (Tôi không nói về các bài kiểm tra đơn vị, nhưng các bài kiểm tra chấp nhận và như vậy.)

Không . Người kiểm tra giỏi kiểm tra hơn bạn. Và như bạn chỉ ra, giống như hiệu đính, rất khó để nhận ra sai lầm của chính bạn. Có thêm nhãn cầu sẽ có tác động lớn (tốt) đến chất lượng chương trình của bạn.

Bạn có rất nhiều câu hỏi khác. Tôi sẽ chỉ trả lời một:

Một lập trình viên có nên tinh chỉnh các đặc điểm kỹ thuật?

Vâng! Bạn phải thực hiện các đặc tả, vì vậy bạn phải đảm bảo rằng các đặc tả thực sự có thể thực hiện được. Ngoài ra, là một lập trình viên - được đào tạo về tư duy rõ ràng, chính xác và như vậy - bạn có thể giúp mọi người khám phá những gì thực sự cần phải làm, và loại bỏ các yêu cầu mơ hồ hoặc thiếu sót về mặt logic.


5

Những gì họ đang nói và thực tế có lẽ là hai điều khác nhau. Lý do rất có thể là:
"Tại sao tôi phải trả lương cho người kiểm tra khi tôi chỉ có thể khiến lập trình viên thực hiện nhiệm vụ kép?"

Tất nhiên, họ sẽ không nói điều đó và sẽ tạo ra tất cả các loại lý do mà họ cho là hợp lý. Tôi có thể nghĩ về một số phản bác theo quan điểm của họ, nhưng thành thật mà nói họ sẽ không giúp đỡ. Tôi đã thấy trận chiến này lặp đi lặp lại và họ sẽ thay đổi cách tiếp cận của họ bất cứ khi nào bạn gỡ rối lý luận hiện tại của họ. Cuối cùng, họ sẽ từ bỏ và chỉ đạo bạn làm điều đó và bạn sẽ bị gán cho một người khiếu nại.

Cách tiếp cận tốt nhất tôi có thể nghĩ đến là giải quyết nó không phải từ quan điểm chất lượng, mà quản lý dường như không bao giờ coi trọng cho đến khi có vấn đề, nhưng từ quan điểm chi phí. Người kiểm thử, hoặc ít nhất được coi là, ít tốn kém hơn so với người lập trình. Nhắc nhở họ rằng bằng cách bạn thực hiện nhiệm vụ kép, họ đang trả một tài nguyên (lập trình viên) được trả cao hơn để thực hiện công việc có thể được thực hiện bằng một tài nguyên (người kiểm tra) ít tốn kém hơn. Do đó, họ không tối đa hóa giá trị mà họ đang trích xuất từ ​​kỹ năng lập trình của bạn.

Cách tiếp cận này có nhược điểm của việc sụp đổ nếu bạn được trả lương và họ không có sự ràng buộc nào về việc chỉ khiến bạn làm việc nhiều hơn không được trả lương, nhưng nó đáng để thử.


Nếu bạn được trả lương và họ không có sự ràng buộc nào về việc khiến bạn làm việc nhiều hơn không được trả lương thì đã đến lúc bỏ việc.
glenatron

Cảm ơn chúa vì việc làm thêm giờ không được trả lương bắt buộc không được luật hóa ở mọi nơi.
Steven Evers

3

Hệ thống trong câu hỏi là lớn nhưng chỉ được phát triển bởi tôi. Điều này cũng đã khiến một số nhiệm vụ quản lý rơi vào lòng tôi, chẳng hạn như xác định lịch trình và làm việc trên các thông số kỹ thuật.

Đủ công bằng.

Những loại nhiệm vụ này có phải là trách nhiệm của tôi?

Điều đó cuối cùng là do quản lý của bạn quyết định.

Tôi thấy mình nghiêm túc như một lập trình viên và không có gì khác.

Có lẽ bạn đang ở sai công việc rồi. Rất nhiều người thích được giao thêm trách nhiệm.

Và nếu đây là trách nhiệm của tôi, ở mức độ nào?

Nếu quản lý nói như vậy, có.

Khi một dự án lớn đến mức nó đòi hỏi người thử nghiệm?

Khi có quá nhiều công việc khác mà các nhà phát triển phải làm. Tại thời điểm đó, quản lý cần quyết định xem họ có muốn sử dụng một người thử nghiệm chuyên dụng hay không, có nguy cơ bỏ qua việc kiểm tra hay không. (Cuối cùng, các nhà phát triển chỉ có thể làm rất nhiều.)

Có những lợi thế nhất định trong việc có những người thử nghiệm chuyên dụng, nhưng cũng có những nhược điểm ... ngoài chi phí thuê thêm nhân viên.

Một lập trình viên phải tinh chỉnh các đặc điểm kỹ thuật,

Nếu cần thiết, có. Trong thực tế, nếu đặc tả cần tinh chỉnh và không có ai khác làm việc với nó, thì việc không thực hiện được điều này có thể khiến dự án thất bại.

lo lắng về quản lý dự án

Nếu cần thiết, có.

hoặc thậm chí cung cấp hỗ trợ khách hàng?

Nếu cần thiết, có.

Tôi nghe có vẻ như bạn đang làm việc quá sức và phản ứng với áp lực. Đây là một vấn đề. Nhưng đảm nhận vị trí "không phải là công việc của bạn để làm X, Y, Z" sẽ không có ích. Một kế hoạch tốt hơn là làm rõ rằng chỉ có rất nhiều việc bạn có thể làm, và chỉ ra rằng điều này có thể khiến thời hạn bị bỏ lỡ, chất lượng bị trượt, hỗ trợ khách hàng kém, v.v. Nhưng dù sao thì hãy cố gắng hết sức ... mà không làm tổn hại sức khỏe, các mối quan hệ, v.v.


Đó không phải là tất cả về quản lý, còn có anh ấy đảm nhận và bồi thường thích hợp. Nếu OP không hài lòng với trách nhiệm của mình so với bồi thường thì việc cố gắng lấy đường cơ sở để khám phá những kỳ vọng của họ gần với thực tế là hoàn toàn hợp lý.
jmoreno

3

Chúng tôi có người kiểm tra. Tôi sẽ không muốn làm việc mà không có họ. Mặc dù tôi viết các bài kiểm tra đơn vị (sử dụng TDD) và kiểm tra tích hợp tự động cho tất cả các mã của tôi, người kiểm tra vẫn có một chức năng rất có giá trị.

  1. Họ có tay nghề cao, và có các kỹ năng khác nhau cho các lập trình viên.
    1. Họ có nhiều kinh nghiệm và kiến ​​thức về cách thực hiện kiểm tra QA và cách xác minh rằng mã được sản xuất thực sự phù hợp với cả mong đợi của người dùng và hành vi thực tế của người dùng.
    2. Họ đã trải qua nhiều lỗi và rất giỏi nghĩ về các tình huống có thể phá vỡ phần mềm.
    3. Họ có xu hướng hoài nghi và có hệ thống. Tôi đã quan sát thấy rằng các lập trình viên thường lạc quan hơn nhiều.
  2. Họ cung cấp thông tin phản hồi sớm có giá trị về khả năng sử dụng. Chẳng hạn, khi tạo API REST gần đây, các khu vực mà người kiểm tra QA không thể hiểu dễ dàng là một dấu hiệu tốt về các khu vực mà người dùng cũng sẽ không hài lòng.
  3. Họ kiểm tra trên môi trường thực tế, trên thực tế nhiều cấu hình của phần cứng thực, HĐH, v.v.
  4. Họ biết cách xây dựng quy mô lớn, thực tế, thử nghiệm trên giường và thực hiện kiểm tra hiệu suất, tải trọng và căng thẳng
  5. Họ đang tập trung vào việc ngăn chặn các bản phát hành xấu ra khỏi. Các lập trình viên có xu hướng tập trung vào việc phát hành mã. Gần giống như, một lập trình viên sẽ phát hành mã theo mặc định, nhưng người kiểm tra QA sẽ cần một lý do để phát hành mã (nó đã được hiển thị để hoạt động!)

0

"nếu chúng tôi có người kiểm tra, bạn sẽ không kiểm tra mã của riêng mình"

" Nếu xe của bạn có dây an toàn, bạn sẽ gặp sự cố mọi lúc! "

Những loại nhiệm vụ này có phải là trách nhiệm của tôi? [...] Và nếu đây là trách nhiệm của tôi, ở mức độ nào?

Câu trả lời cho điều đó là "nó phụ thuộc". Theo những gì tôi hiểu, nhà tuyển dụng của bạn coi bạn là "bộ phận một người đàn ông CNTT". Nếu đó là trường hợp, có, họ là (trách nhiệm của bạn). Nếu bạn có trách nhiệm mà bạn hoàn toàn ghét và muốn tránh, hãy tìm một vị trí trong một công ty có bộ phận CNTT lớn hơn.

Khi một dự án lớn đến mức nó đòi hỏi người thử nghiệm?

Đó không phải (khá) một câu hỏi chính xác để hỏi. Bạn nên hỏi "khi nào chất lượng sản phẩm / hình ảnh của công ty quan trọng đến mức nó yêu cầu người kiểm tra?"

Nếu một lập trình viên phải tinh chỉnh đặc tả, [...]

Vâng chắc chắn. Hầu hết thời gian, có sự khác biệt lớn giữa những gì nhà phát triển / người thực hiện cần và những gì khách hàng cung cấp [như thông số kỹ thuật].

Nhiều khi bạn phải tìm các khu vực màu xám / không xác định và đặt câu hỏi đúng, để thông báo và chỉ ra các yêu cầu không thể hoặc mâu thuẫn về mặt kỹ thuật, v.v. (đặc biệt nếu bạn là nhà phát triển duy nhất).

[...] Lo lắng về việc quản lý dự án hoặc thậm chí cung cấp hỗ trợ khách hàng?

Điều đó phụ thuộc vào trách nhiệm bạn chấp nhận khi bạn đảm nhận vị trí này. Ví dụ, một số vị trí yêu cầu bạn giải quyết trực tiếp khách hàng. Tất cả những thứ khác đều bằng nhau, tôi sẽ cố gắng tránh những vị trí như vậy (nhưng tùy thuộc vào bạn và bạn có thể không có nhiều lựa chọn công việc).


0

Trước hết, kiểm tra, hay nói tốt hơn là Đảm bảo chất lượng, không chỉ là về kiểm tra chức năng bằng cách nhấp qua ứng dụng. Đảm bảo chất lượng là về các quy trình . Không chỉ để kiểm tra ứng dụng để tìm lỗi, họ còn phải ngăn các nhà phát triển thực hiện chúng.

  1. Đặc điểm kỹ thuật sản phẩm + trường hợp sử dụng
    Ngay cả khi mọi người biết (hoặc nghĩ rằng họ làm) chức năng của sản phẩm là gì, thì nó phải được ghi lại. Bạn không thể kiểm tra một ứng dụng mà không có thông số kỹ thuật rõ ràng. Một đặc tả xác định thế nào là hành vi đúng và lỗi là gì.
  2. Kiểm tra đơn vị,
    Kiểm tra tích hợp Kiểm tra các nội bộ khó kiểm tra thông qua UI, trạng thái ứng dụng đặc biệt. Đây là điều bắt buộc cho mọi hệ thống lớn hơn. Cả hai loại thử nghiệm cũng có một thuộc tính thú vị khác - chúng buộc bạn phải xem lại mọi phần của mã và bạn sẽ nhận ra các lỗi / kiến ​​trúc mà bạn chưa từng thấy trước đây.
  3. Chất lượng mã & Tiêu chuẩn mã hóa
    Một trong những nhiệm vụ QA nên làm là đo độ phức tạp của mã. Mã phức tạp thấp làm giảm khả năng lỗi (ngăn ngừa lỗi).
  4. Đánh giá mã
    Khi một dự án đạt đến một kích thước nhất định hoặc được nhiều người dùng sử dụng, đánh giá mã là bắt buộc. Một lập trình viên khác luôn tìm thấy các vấn đề về mã / lỗi mà bạn đã bỏ lỡ. Lập trình viên đôi khi mù với các lỗi rõ ràng trong mã riêng của họ.
  5. Tài liệu Tài
    liệu mã của bạn và kiến ​​trúc của nó, nó sẽ giúp bạn nhận ra những sai sót có thể xảy ra (kinh nghiệm của riêng tôi).
  6. Người kiểm tra thử nghiệm
    không phải là một con khỉ chỉ nhấp qua giao diện người dùng. Một người kiểm tra lấy đặc tả & trường hợp sử dụng và tạo trường hợp kiểm thử. Sau đó anh ấy / cô ấy kiểm tra từng cái một. Nếu một lỗi được báo cáo bởi người dùng cuối, một trường hợp thử nghiệm phải được thêm vào đó.

Một lập trình viên không bao giờ nên tạo đặc tả (1). Bạn không ở đó để quyết định chức năng. Thông thường họ phải nói chuyện với người dùng cuối, tạo ra các thiết kế đồ họa, vv Đó là một công việc tốn thời gian. Nếu một lập trình viên quyết định chức năng, thông thường nó sẽ kết thúc bằng "đó là okey nhưng bạn có thể thay đổi mọi thứ trong cửa sổ này vào ngày mai không?" "Đây không phải là điều tôi muốn" "nó hoạt động nhưng thật khó để sử dụng" "nó thiếu chức năng duy nhất chúng tôi thực sự cần".

Những gì một lập trình viên có thể đạt được là 2, 3 và 5.

Bạn cần một lập trình viên khác cho 4. Bất kỳ công ty nào có dự án CNTT lớn và chỉ có một nhà phát triển biết hệ thống bước trên một nền tảng rất nguy hiểm.

Nếu bạn không có đủ thời gian, đừng bao giờ bận tâm tạo ra các trường hợp thử nghiệm (5). Một người tận tâm thường là cần thiết vì nó tốn rất nhiều thời gian. Không có trường hợp thử nghiệm, thử nghiệm chỉ là một trò đùa.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.