Tôi tình cờ biết một số quản trị viên hệ thống và theo anh ta, những người thử nghiệm không được ưu tiên trong một tổ chức so với các nhà phát triển. Không thể nghi ngờ việc phát hành phần mềm là không thể nếu không có người kiểm tra nhưng tôi chưa bao giờ đặt tay vào thử nghiệm nên không biết nhiều về nó. Không có ý định phạm tội.
Câu trả lời:
Theo kinh nghiệm của tôi, thật không may, họ thường bị đối xử như những nhân viên hạng hai và thậm chí tệ hơn là một kỹ năng phù phiếm cho các lập trình viên.
Nó bắt nguồn từ một số điều:
Khi những người thử nghiệm đang thực hiện công việc của họ một cách chính xác, mọi người đều dễ dàng quên đi những lập trình viên thậm chí còn tồn tại. Giống như một quản trị viên mạng, bạn chỉ chú ý đến họ khi họ không làm việc của họ hoặc làm việc đó không tốt. Vì vậy, từ quan điểm của phần còn lại của tổ chức, họ chỉ được nhớ cho những sai lầm của họ.
Nó bị nhầm lẫn là một công việc cấp đầu vào cho những người khao khát trở thành lập trình viên, nhưng chưa đủ điều kiện cho những công việc đó. Trên thực tế, tại một công ty tôi làm việc, họ đã được trao các chức danh công việc của Lập trình viên mặc dù họ cầu xin để có được một chức danh hỏi đáp. Ngay cả việc họ ở trong một bộ phận QA cũng không đủ để khiến HR phải nhúc nhích về điều đó.
Vì số 2, người ta cho rằng những người thử nghiệm đều là những người ở cấp nhập cảnh và nên được trả tiền tương ứng.
Không ai thích bị chỉ trích, và tất cả đều quá phổ biến đối với các lập trình viên phòng thủ không thích người kiểm thử vì công việc của họ yêu cầu họ chỉ ra lỗi lập trình viên cả ngày. Là một người quản lý, tôi liên tục thực hiện một nhiệm vụ PR để nhắc nhở các lập trình viên rằng nhóm QA đã ở đó để làm cho họ trông ổn, chứ không phải nói ra.
Nó có xu hướng là một công việc mà mọi người gặp phải một cách tình cờ và không phải là sự lựa chọn, ít nhất là ban đầu. Tôi không nhớ bất kỳ kế hoạch cấp bằng nào tại bất kỳ trường nào tôi theo học mà mọi người chuẩn bị cho hỏi đáp phần mềm. Họ tồn tại, nhưng thường ở các trường dạy nghề cấp thấp, điều này chỉ góp phần vào ý tưởng rằng họ là những chuyên gia kém tay nghề.
Các công việc kiểm tra có nhiều khả năng hơn các công việc lập trình được gửi ra nước ngoài. Ít nhất các lập trình viên có thể lập luận rằng việc truyền đạt nhu cầu thiết kế tại địa phương sẽ hiệu quả hơn và việc giữ kiến thức về cách ứng dụng hàng đầu của công ty hoạt động trong công ty sẽ hiệu quả hơn. Kiểm tra, tuy nhiên, dễ dàng hơn nhiều để mô đun hóa và do đó dễ dàng thuê ngoài hơn.
Vì tất cả các lý do trên, người kiểm tra có xu hướng nhìn thấy chữ viết trên tường và chuyển sang các công việc khác (như lập trình), đặc biệt là những công việc thực sự tốt. Điều này có nghĩa là hầu hết các công việc kiểm tra có xu hướng được bố trí nhân sự với nhiều người ở cấp độ đầu vào chưa bị đốt cháy hoặc chuyển sang những thứ khác, điều không may củng cố một số ý tưởng trên.
Nó phụ thuộc vào công ty, nhưng thường. Họ thường được coi là công dân hạng hai, và trong nhiều công ty, thử nghiệm được coi là một vị trí cấp đầu vào mà từ đó bạn sẽ chuyển sang trở thành một nhà phát triển thực sự.
Đây là, tất nhiên, tào lao. Đã làm việc với một số người thử nghiệm tốt, tôi có thể nói rằng cả hai đều có giá trị và khó có thể đi qua. Một người có đầu óc đủ sáng tạo để tìm ra những lỗi không rõ ràng và đủ phương pháp để thực hiện một công việc kỹ lưỡng.
Mặc dù vậy, có một ngoại lệ: Tôi đã biết một vài người thử nghiệm của Microsoft và tôi nghe rằng những người thử nghiệm có những công dân hạng nhất.
Tôi đã làm việc như một người thử nghiệm chức năng trong một năm cho một dự án khá lớn. Mỗi đội gồm khoảng 10 thành viên có 2-3 người thử nghiệm. Tôi phải nói rằng chúng tôi đã được đối xử quan trọng như nhau đối với dự án như các nhà phát triển.
Tìm lỗi không dễ. Đầu tiên, người kiểm tra phải hiểu mã được cho là để làm gì. Điều đó có nghĩa là đọc và hiểu các yêu cầu. Chìa khóa ở đây là hiểu các yêu cầu - nếu người kiểm tra không thể hiểu rõ các yêu cầu đủ để biết cách viết trường hợp kiểm tra dương tính, bạn nên lo lắng. Điều này có nghĩa là các nhà phát triển đã viết một số mã thực hiện những gì họ đã giả định nó làm. Đây có phải là giả định đúng không? Bạn không biết cho đến khi bạn sắp xếp các yêu cầu và bạn có thể cảm ơn những người thử nghiệm của bạn vì đã tìm ra lỗ hổng đó.
Thứ hai, người kiểm tra phải viết các trường hợp kiểm thử sai, điều này đảm bảo rằng mã không phải là điều không nên làm. Một nguyên tắc hợp lý là bạn viết 5-10 trường hợp kiểm tra sai cho mỗi trường hợp kiểm tra dương tính. Điều này có nghĩa là hiểu các yêu cầu hơn nữa, và thường nàythông tin là, hoặc ít nhất là trong dự án của chúng tôi, khó hiểu và mơ hồ. (Và đó không phải là do nỗ lực thấp trong việc thu thập các yêu cầu - chúng tôi đã có khoảng 13.000 người trong nhóm của chúng tôi.) Một lần nữa, các nhà phát triển sẽ viết mã bằng các giả định của họ, hoặc thậm chí tệ hơn, thậm chí không xem xét điều này. Vì vậy, mã làm gì trong những điều kiện không bình thường? Bạn không biết cho đến khi bạn đã thử nó. Có lẽ chương trình không đáp ứng; có lẽ nó chỉ gặp sự cố; có thể nó phá hủy dữ liệu; có lẽ nó cho phép người dùng chạy các lệnh như người dùng root. Dù nó làm gì, bạn muốn biết. Nếu không, bạn có thể thấy mình đang đọc tiêu đề sau trên báo một ngày - BUG IN [TÊN CÔNG TY CỦA BẠN] CHƯƠNG TRÌNH FLAGSHIP LEAKS SỐ SỐ THẺ TÍN DỤNG CỦA KHÁCH HÀNG.
Vì vậy, đối xử tốt với người thử nghiệm của bạn. Đối xử tốt với họ. Rốt cuộc, họ là những người tìm ra lỗi trong phần mềm của bạn và làm cho cuộc sống của bạn và chúng ta dễ dàng hơn.
Những người kiểm tra giỏi, người có thể phân tích vấn đề hiệu quả và có thể tự động hóa bài kiểm tra đàng hoàng đáng giá vàng của họ vì có rất nhiều người kiểm tra cao bồi ngoài kia (khi phỏng vấn một "người kiểm tra" một khi anh ta thực sự bật cười khi nhận ra rằng chúng ta biết rằng anh ta đang làm nhét vào chỗ đó trong khi được hỏi về CV của mình).
Trong nhóm của tôi, người kiểm tra được coi là một người bình đẳng - bao gồm trách nhiệm và tiền lương. Nếu bạn muốn một người kiểm tra nhấp vào cả ngày hôm sau - thuê ngoài họ đến một nơi nào đó giá rẻ (chúng tôi cũng làm điều đó).
Cập nhật sau khi đọc các câu trả lời khác: Có rất nhiều chuyên gia QA yêu thích công việc họ làm. Chỉ để đưa ra một viễn cảnh khác nếu bạn chưa bắt gặp bất kỳ vị trí QA đáng kính nào, một ví dụ ở đây: Thử nghiệm ứng dụng nhúng / ứng dụng di động cho các nhà sản xuất ô tô hàng đầu. Họ đảm bảo các yêu cầu kinh doanh được đáp ứng hoàn toàn trước khi một chiếc xe được phát hành ra thị trường và không có người dùng nào trải nghiệm bảng điều khiển xe chậm hoặc không phản hồi. Họ làm việc chặt chẽ với các nhà quản lý và quản lý cấp cao hơn, và cả các nhà phát triển bắt đầu từ việc lập kế hoạch cho quy trình QA đến thử nghiệm trực tiếp trên các thiết bị mô phỏng trong cơ sở thiết kế. Tôi không thể nghĩ rằng họ là hồ sơ thấp, họ xử lý trách nhiệm và quyền sở hữu lớn và họ là một trong những kỹ sư tốt nhất.
bây giờ câu trả lời trước đó của tôi, mặt trái:
Tôi đã quan sát thấy rằng sinh viên tốt nghiệp kỹ thuật ghét được phân bổ cho các đơn vị thử nghiệm (bối cảnh: Ấn Độ, các công ty dịch vụ phần mềm lớn, nơi mọi thứ được điều khiển bởi 'yêu cầu kinh doanh'), vì họ coi đó là môi trường làm việc phi kỹ thuật. Họ được cung cấp các bảng excel với các hướng dẫn như 'nhấp vào tất cả các liên kết trong trang web và xác minh', bị buộc phải làm việc với các sinh viên tốt nghiệp từ các luồng phi kỹ thuật (khoa học, nghệ thuật) mà họ coi là một sự sỉ nhục và cảm thấy như các kỹ năng công nghệ của họ không tận dụng. Những phân bổ này hoàn toàn dựa trên yêu cầu của tổ chức, và hầu hết thời gian, không có khả năng đàm phán con đường sự nghiệp của mình. Vì vậy, nếu bạn là một người tìm việc nhắm vào một công ty CNTT lớn như vậy, bạn đã được cảnh báo. Bạn không thể làm nhiều, thực tế, ngoại trừ ra khỏi công ty vào đúng thời điểm.
Trừ khi có cơ hội học thử nghiệm tự động, thử nghiệm tải / hiệu suất, v.v., sự nghiệp bị đình trệ ở một mức độ nào đó. Cá nhân tôi biết các cơ hội cho các bài tập tại chỗ (= tải tiền từ quan điểm lập trình viên ở nước ngoài) sẽ nhiều hơn cho đơn vị thử nghiệm tổ chức của tôi hơn bất kỳ đơn vị khác. Họ làm việc với tất cả các ngành dọc như một chất độn hoặc keo, vì việc kiểm tra là không thể tránh khỏi trong các dự án trong tất cả các lĩnh vực.
Nếu bạn tự tin bạn có thể điều khiển sự nghiệp của mình theo cách bạn muốn, thử nghiệm không có gì là thấp. Với 4-5 năm kinh nghiệm và một chút may mắn, bạn có thể có được sự tiếp xúc rất tốt, đôi khi tương tác với người dùng doanh nghiệp cấp cao nhất. Bạn cũng có thể nắm bắt tốt về ngành / lĩnh vực bạn đang làm việc (so với một nhà phát triển chủ yếu tập trung vào một số phần của hệ thống). Tại thời điểm này, người ta có thể chọn chuyển sang vai trò phân tích kinh doanh.
Tôi biết các công ty nơi nhóm QA chịu trách nhiệm phát hành. Điều này có nghĩa là họ có quyền chặn phát hành do thiếu chất lượng. Nếu một vấn đề được báo cáo trong lĩnh vực này, họ là người đầu tiên trong dòng lửa (ngay sau khi kỹ sư hiện trường).
Thông thường họ có kiến thức tên miền cao hơn. Họ có xu hướng biết chức năng tổng thể của sản phẩm tốt hơn trong khi các nhà phát triển tập trung vào mô-đun / tính năng của họ.
Ngoài ra tôi biết về QA orgs nơi họ phải viết các công cụ kiểm tra của riêng họ. Chưa kể tự động hóa toàn bộ công cụ. Tôi là một nhà phát triển và luôn đánh giá cao những người QA kiểm tra các tính năng của tôi.
Ít nhất trong tổ chức của tôi, QA được đối xử bình đẳng với các nhà phát triển. Tôi nghĩ rằng đó là do miền (viễn thông) nơi kiến thức về giao thức và kiến trúc mạng có giá trị ngang nhau với các kỹ năng lập trình.
Đúng. Dù thích hay bỏ nó, chúng đều quan trọng như nhau nhưng luôn ít được ưa thích hơn. Có thể là vì chúng dễ thay thế.