Bạn có tin rằng các Kỹ sư Phần mềm phải làm việc như các Kỹ sư Đảm bảo Chất lượng trong một khoảng thời gian không? [đóng cửa]

Tôi tin rằng đó là. Tại sao?

1. Tôi đã gặp nhiều Kỹ sư phần mềm tin rằng họ bằng cách nào đó vượt trội so với các kỹ sư QA. Tôi nghĩ rằng nó có thể giúp dập tắt niềm tin này nếu họ làm công việc của một kỹ sư QA một thời gian và nhận ra rằng đó là một bộ kỹ năng độc đáo và có giá trị của riêng mình.

2. Kỹ sư phần mềm càng giỏi trong việc kiểm tra các chương trình của riêng họ, thì mã của họ càng mất ít thời gian khi thực hiện phần còn lại của vòng đời phát triển phần mềm.

3. Kỹ sư phần mềm càng dành nhiều thời gian suy nghĩ về cách chương trình có thể phá vỡ, họ càng thường xuyên xem xét các trường hợp này khi họ đang phát triển chúng, do đó giảm lỗi trong sản phẩm cuối cùng.

4. Định nghĩa "hoàn thành" của Kỹ sư phần mềm luôn thú vị ... nếu họ dành thời gian làm kỹ sư QA, định nghĩa này sẽ phù hợp hơn với người thiết kế phần mềm.

Lưu ý Tôi đưa ra đề xuất ở trên với một khung thời gian nhỏ trong đầu vì tôi biết rằng có ai đó làm việc ở một vị trí không phải là vị trí họ được thuê chắc chắn là một công thức để mất nhà phát triển đó.

Tất cả các bạn nghĩ gì?

1. Tôi đã gặp nhiều Kỹ sư phần mềm tin rằng họ bằng cách nào đó vượt trội so với các kỹ sư QA. Tôi nghĩ rằng nó có thể giúp dập tắt niềm tin này nếu họ làm công việc của một kỹ sư QA một thời gian và nhận ra rằng đó là một bộ kỹ năng độc đáo và có giá trị của riêng mình.

Một kỹ thuật phần mềm tốt có một nền tảng về chất lượng, bao gồm kiểm tra, số liệu và thống kê. Bất cứ ai làm bất kỳ loại phát triển phần mềm nào cũng cần lưu ý (nếu không quen thuộc) duy trì mã nguồn chất lượng và sản xuất / duy trì các trường hợp thử nghiệm hiệu quả. Theo thời gian, tôi sẽ nghi ngờ rằng bất kỳ nhà phát triển phần mềm nào cũng sẽ hiểu được các khía cạnh khác nhau của chất lượng - chất lượng mã, tính di động, khả năng bảo trì, khả năng kiểm tra, khả năng sử dụng, độ tin cậy, hiệu quả và bảo mật.

Các kỹ sư phần mềm có thể tập trung vào một khía cạnh cụ thể của vòng đời - yêu cầu kỹ thuật, kiến ​​trúc và thiết kế, xây dựng, thử nghiệm và bảo trì. Tuy nhiên, bất kể trọng tâm của bạn (là công việc hay ở giai đoạn hiện tại của dự án), điều quan trọng là phải nhớ chất lượng.

2. Kỹ sư phần mềm càng giỏi trong việc kiểm tra các chương trình của riêng họ, thì chi phí phát sinh mã của họ càng ít khi đi qua phần còn lại của vòng đời phát triển phần mềm.

Điều đó có thể đúng. Nhưng một số vấn đề được nhìn thấy tốt nhất sau này trong phát triển. Ví dụ, các vấn đề về hiệu suất và hiệu quả có thể không được nhìn thấy cho đến khi tích hợp. Có mã tốt, vững chắc và kiểm tra đơn vị hiệu quả chỉ là khởi đầu. Chất lượng cần phải bắt đầu với các yêu cầu, và làm theo tất cả các cách thông qua các hoạt động bảo trì.

3. Kỹ sư phần mềm càng dành nhiều thời gian suy nghĩ về cách chương trình có thể phá vỡ, họ càng thường xuyên xem xét các trường hợp này khi họ đang phát triển chúng, do đó giảm lỗi trong sản phẩm cuối.

Đó là một tuyên bố hoàn toàn đúng. Nhưng một lần nữa, các kỹ sư cũng yêu cầu xác minh rằng không có xung đột trong yêu cầu, các kiến ​​trúc sư để đảm bảo rằng thiết kế thực sự giải quyết các yêu cầu, v.v. Mọi người nên cố gắng chọc lỗ trong công việc của họ và sau đó làm việc với những người thích hợp để niêm phong chúng thật đẹp và chặt chẽ.

4. Định nghĩa "hoàn thành" của Kỹ sư phần mềm luôn thú vị ... nếu họ dành thời gian làm kỹ sư QA, định nghĩa này sẽ phù hợp hơn với người thiết kế phần mềm.

"Hoàn thành" chỉ có thể được đo theo yêu cầu. Hoặc là các yêu cầu được thỏa mãn và dự án hoàn thành, hoặc có những yêu cầu không đầy đủ và dự án không hoàn thành. Bất kỳ biện pháp hoàn thành khác là vô ích.

Làm cho các lập trình viên chịu trách nhiệm về mã của họ và yêu cầu họ sửa các lỗi của riêng họ có thể xử lý việc này. Điều đó và mất tiền thưởng và / hoặc công việc.

Không phải trải nghiệm này sẽ không giúp ích gì, nhưng bạn có thể đi bao xa với dòng suy nghĩ này? Hỗ trợ kỹ thuật, Bán hàng, Người dùng Beta, cọ rửa nhà vệ sinh (đó sẽ là một trải nghiệm khiêm tốn).

"... phải làm việc như các kỹ sư QA ..."? Bạn làm cho nó âm thanh nghịch cảnh hoặc trừng phạt.

Tôi là một nhà phát triển phần mềm. Tôi coi đó là một phần công việc của mình để trở thành kỹ sư QA, mặc dù chúng tôi có bộ phận QA. Công việc của tôi là cung cấp phần mềm hoàn thành một số việc nhất định và để làm được điều đó tôi phải viết các bài kiểm tra đơn vị và đảm bảo phần mềm vượt qua chúng.

Tôi hợp tác với bộ phận QA của chúng tôi. Mục tiêu của tôi là làm cho công việc của họ trở nên dễ dàng hơn, giống như công việc của họ là giúp tôi đáp ứng mục tiêu cung cấp phần mềm làm những gì cần thiết, từ đó giúp cuộc sống của tôi dễ dàng hơn. Tôi coi chúng là đôi mắt thứ hai của tôi và một phần của mạng lưới an toàn, giống như tôi làm các bài kiểm tra đơn vị của mình.

Tôi chọn phát triển phần mềm, và muốn phát triển phần mềm. Nếu một số người quản lý đến gặp tôi và nói với tôi rằng tôi không thể làm điều đó và phải làm QA, tôi sẽ nói với họ rằng họ cần tìm một nhà phát triển phần mềm mới VÀ một người QA vì tôi sẽ không làm việc ở đó. Tôi là hậu môn như có thể với mã của tôi nhưng quá trình sáng tạo và câu đố / thử thách lập trình là vô cùng quan trọng đối với tôi. Tôi thà quay trở lại lái xe nâng ngã ba nếu tôi không thể viết mã bởi vì ở trong môi trường công ty mà không có khả năng sáng tạo và bị thách thức theo cách tôi sẽ là địa ngục tuyệt đối với tôi.

Nói chung, các tùy chọn bạn trình bày nghe có vẻ rất bất lợi và khiến tôi tự hỏi liệu bạn đã có một số trải nghiệm thực sự tồi tệ với một số nhà phát triển khủng khiếp. Trong tâm trí của tôi, một nhà phát triển phải LUÔN LUÔN nhận thức được các vấn đề chất lượng và thử nghiệm và nên tự hào về công việc của họ mà họ không xem xét nó đã hoàn thành cho đến khi nó vượt qua các thử nghiệm nghiêm ngặt trong thử nghiệm đơn vị của họ như những gì bộ phận QA chính thức sẽ sử dụng. Nếu tôi có một người ngang hàng, hoặc là người dẫn đầu về công nghệ trong một nhóm và có một nhà phát triển thể hiện bất kỳ sự "thô lỗ" nào đối với QA, anh ta sẽ thấy tôi lôi anh ta ra để điều chỉnh thái độ. Nếu cả hai mặt của đồng xu phân phối phần mềm không thể hợp tác và hoạt động như một nhóm thì đó là một vấn đề văn hóa thực sự. Tôi sẽ không muốn làm việc ở đó và nhân sự, cùng với quản lý cấp trên, sẽ cần phải được theo dõi.

Bắt các lập trình viên làm việc như các kỹ sư QA là một công thức để mất các nhà phát triển tốt nhất của bạn. Lập trình và QA yêu cầu các bộ kỹ năng và quy trình suy nghĩ khác nhau.

Tuy nhiên, điều quan trọng là các lập trình viên của bạn phải có kỹ năng kiểm tra và xác nhận công việc của chính họ trước khi chuyển nó cho nhóm QA. Các nhà phát triển và QA có quyền truy cập vào các công cụ, kiến ​​thức và kỹ năng khác nhau. Các nhà phát triển cần phải có kỹ năng bước qua mã của họ để tìm kiếm hành vi bất ngờ, kiểm tra đơn vị cho các điều kiện ràng buộc, nhấn mạnh mã luồng tìm kiếm các điều kiện chủng tộc, v.v. Kiểm tra từ góc độ nhà phát triển.

QA làm thử nghiệm của họ từ góc độ người dùng. Suy nghĩ giống như các loại người dùng khác nhau, phát minh ra các trường hợp cạnh lạ và làm cho các vấn đề mơ hồ có thể lặp lại là các kỹ năng QA.

Không nhất thiết - cả lập trình viên và người kiểm tra đều được yêu cầu phải có các kỹ năng khác nhau. Chỉ vì bạn là một lập trình viên giỏi không có nghĩa là bạn có thể là một người thử nghiệm giỏi (nhiều người không hiểu điều đó, nhưng là một lập trình viên không tự động đủ điều kiện để bạn trở thành một người thử nghiệm).

Một người thử nghiệm tuyệt vời cần phải có những kỹ năng thực sự quỷ quái, có thể làm những việc mà phần mềm không được thiết kế để làm, nhưng có thể mong đợi người dùng làm trong thế giới thực. Điều đó đòi hỏi kỹ năng, sự kiên nhẫn, khả năng nhìn thấy những gì có thể sai ở đâu, sự hiểu biết về tâm lý của người dùng và rất nhiều yếu tố khác.

Lưu ý rằng tôi sử dụng các từ lập trình viên và người kiểm thử - nhưng nếu bạn là một kỹ sư phần mềm và chưa quyết định bạn muốn trở thành một lập trình viên hay người kiểm thử, thì nó bao gồm cả hai điều này và do đó, bạn nên có kinh nghiệm trong cả hai trong vài năm đầu đời trước khi đưa ra quyết định.

Điều đó không có nghĩa là bạn lấy một lập trình viên có kinh nghiệm và khiến anh ta kiểm tra một lúc chỉ để khiến anh ta hiểu các kỹ sư QA làm việc chăm chỉ như thế nào.

Dưới đây là một số vấn đề tiềm ẩn tôi thấy với đề xuất của bạn:

1) Nếu bạn đề xuất rằng bạn sẽ đưa các kỹ sư phần mềm mới vào lĩnh vực QA trong một thời gian ngắn, điều này sẽ không có tác dụng ngược? - họ có thể cho rằng QA là việc bạn làm khi bạn là người mới và bạn không hiểu bạn đang làm gì - sau tất cả, đó là cách nó hoạt động với họ.

2) Trở thành một người thử nghiệm rất tệ trong một thời gian sẽ không nhất thiết phải dạy họ bất cứ điều gì có giá trị. Nhưng nó có thể khiến họ không thể tin được sau này, bởi vì họ sẽ cho rằng họ biết tất cả về thử nghiệm bây giờ, bởi vì họ đã dành 6 tuần trong một bộ phận kiểm tra một lần.

3) Cho rằng rõ ràng là họ sẽ chỉ ở đó trong một thời gian ngắn và bộ phận QA sẽ biết điều này, cũng có khả năng họ sẽ chỉ được giao những nhiệm vụ tương đối dễ dàng, không cần sự giám sát hoặc hiểu biết, nhưng khiến họ bận rộn . Điều này sẽ chỉ củng cố 1 và 2.

4) Nếu bạn muốn tránh 1, 2 và 3, bạn sẽ thuyết phục bộ phận kiểm tra của mình như thế nào để đầu tư một lượng năng lượng khổng lồ vào việc giảng dạy và giám sát một người thậm chí không quan tâm đến việc kiểm tra? (Tôi có thể nói với bạn, phải mất một lượng thời gian và năng lượng đáng sợ để làm việc với ai đó, hãy nhớ, đã không được chọn vì khả năng thử nghiệm của họ . Bạn sẽ không cung cấp tài nguyên bổ sung cho nhóm thử nghiệm trong vài tuần, bạn Tôi đang yêu cầu họ mất một trong những người có kinh nghiệm nhất trong vài tuần, trong khi họ dạy người mới của bạn).

Đã nói tất cả, tôi nghĩ mục tiêu chung của bạn - để tăng sự hiểu biết về kiểm thử của các kỹ sư phần mềm mới - thực sự tuyệt vời. Tôi nghĩ rằng đề xuất của Greg có nhiều khả năng đạt được điều đó hơn - khiến các nhóm dev & QA của bạn cộng tác chặt chẽ với nhau và làm việc để phá vỡ mọi rào cản giữa các đội. (Tôi hiện đang làm việc trong một công ty nơi những người thử nghiệm và lập trình viên ở cùng một đội - điều đó thực sự rất tuyệt và tôi không bao giờ muốn quay lại làm việc trong các nhóm riêng biệt.)

Nếu bạn vẫn muốn các lập trình viên tham gia vào QA - đây là một gợi ý: dẫn dắt bằng ví dụ. Tự đi trước. Có lẽ biến nó thành thứ gì đó mà các thành viên trong nhóm của bạn sẽ làm khi họ đã tốt và muốn có thêm lợi thế, bằng cách dành một chút thời gian mỗi tuần với các đội khác chuyên về các lĩnh vực chồng chéo - kiểm tra, DBA, v.v. Nếu bạn trình bày nó như thế, sau đó bạn sẽ có nhiều cơ hội thành công hơn.

Tôi đã sắp xếp một con đường sự nghiệp giống như những gì bạn thường thấy. Tôi bắt đầu làm phần mềm hỗ trợ cho vật lý thách thức khoa học, rồi cuối cùng làm việc trong giao điểm của kiến ​​trúc, lập trình và thuật toán cho một công ty máy tính. Sau đó, tôi đã tối ưu hóa hiệu suất của một mã kỹ thuật chính trong vài năm, nhưng ngay cả công việc đó cũng hết. Bây giờ, khi tôi sắp đến tuổi nghỉ hưu, tôi đang làm QA với cùng một mã. Đó là sự kết hợp của thử thách và sự quyết liệt. Chúng tôi có một anh chàng mới thực sự sắc sảo làm việc 100% trong việc sửa lỗi và tôi dành rất nhiều thời gian để làm việc với anh ta. Đó là một vị trí đầy thách thức, và bạn có thể học được rất nhiều khi làm điều đó. Tại thời điểm này, mối quan tâm chính của tôi đối với sự phát triển chuyên nghiệp là dành cho hai cậu bé sinh đôi của tôi, là sinh viên năm nhất đại học. Vì vậy, tôi có hứng thú mới trong việc học (hoặc học lại) những thứ sẽ phù hợp với nghề nghiệp của họ, đặc biệt là toán ứng dụng. Bây giờ tôi có một quan điểm khác về những điều mà tôi quan tâm với QA / xác nhận, trong những thế kỷ trước đó là tốc độ, tốc độ, tốc độ bằng mọi giá.

Kiểm thử phần mềm là quá trình phá hủy hơn là mang tính xây dựng. Nhưng lập trình viên nghĩ về việc xây dựng sản phẩm của họ để đảm bảo sản phẩm hoàn thành đúng thời hạn và với ngân sách. Nếu nhà phát triển phần mềm nghĩ rằng phá hủy sản phẩm của chính họ thì ai sẽ là người bên cạnh xây dựng sản phẩm. Vì vậy, mỗi phần của chu trình phát triển phần mềm phải được thực hiện bởi những người được chỉ định trong từng phần của chu kỳ phát triển. Nếu bạn tham gia vào hai lĩnh vực trở lên thì chắc chắn bạn sẽ không bao giờ hoàn hảo với bất kỳ ai trong số họ, vì vậy hãy làm một điều hoặc là lập trình viên hoặc QA hoặc bất kỳ tùy chọn nào khác và hoàn hảo về điều đó.