QA có nên là một phần của bộ phận phát triển?

Tôi làm việc cho một công ty nhỏ đã có một bộ phận phát triển sản phẩm khá lâu. Tuy nhiên, cái mà chúng tôi chưa có là nhóm QA / thử nghiệm.

Chúng tôi đang tìm cách thêm một nhóm thử nghiệm, nhưng đang đấu tranh để xác định nơi tốt nhất để đưa họ vào cơ cấu tổ chức của công ty. Cụ thể, chúng tôi sẽ thuê một vị trí "người thử nghiệm dẫn đầu". Họ nên được đưa vào như một phần của bộ phận phát triển sản phẩm, hay họ nên là một bộ phận mới? Họ có nên ở một nơi khác?

Công ty chúng tôi có cấu trúc đại khái như sau:

• CEO
  • CTO
    • Giám đốc phát triển sản phẩm
    • Giám đốc chăm sóc khách hàng
      • Nhà phát triển
    • Hoạt động của VP
      • Kỹ sư mạng
  • Kỹ sư bán hàng / bán hàng
  • chủ tịch
    • Bộ điều khiển

Có và không :)

Cả nhà phát triển và người QA nên có cùng một mục tiêu (và hiệu suất của họ được đo theo điều đó): cung cấp một sản phẩm chất lượng đúng thời gian và ngân sách. Bạn có thể định nghĩa "sản phẩm chất lượng", nhưng nó phải giống nhau cho cả hai nhóm. Tại sao? Bởi vì nếu nó không giống nhau, bạn sẽ có hai nhóm với các chương trình nghị sự khác nhau và điều đó có thể nhanh chóng trở nên xấu đi trong tình huống gây bất lợi cho sản phẩm / công ty.

QA nên phối hợp chặt chẽ với các nhà phát triển và ngược lại, nhưng cả hai nên hoàn toàn độc lập với nhau trong quá trình ra quyết định. Rốt cuộc, họ chịu trách nhiệm cho các khía cạnh hoàn toàn khác nhau trong phát triển sản phẩm

Cách chúng tôi đã thiết lập là "Phát triển sản phẩm" là một bộ phận "ảo" được thực hiện bởi hai bộ phận cụ thể: QA và Phát triển. Cả hai báo cáo cho cùng một thành viên của nhóm quản lý: CTO. Điều này đảm bảo rằng có một người duy nhất chịu trách nhiệm về sản phẩm (CTO của chúng tôi) và cả QA và Phát triển đều độc lập với nhau.

Nó thực sự phụ thuộc vào mức độ nghiêm trọng của công ty bạn về QA. Ví dụ, bạn sẽ làm kiểm tra phát triển?

Bạn đề cập đến một "nhóm thử nghiệm", điều này sẽ gợi ý nhiều người. Nếu thực tế nó là một nhóm gồm nhiều người thì có lẽ nên là một bộ phận riêng biệt. Tuy nhiên, điều khiến tôi thắc mắc là hiện tại bạn có ít nhất một người dành cho QA và thử nghiệm không? Nếu không, bạn có kế hoạch đứng lên một nhóm hoàn toàn mới một cách nhanh chóng? Nếu vậy, đây sẽ là một sự chuyển đổi tổ chức đáng kể và có thể gây ra xích mích lớn với các nhà phát triển hiện tại của bạn, những người cần thay đổi cách họ làm việc.

Nếu những gì bạn đang lên kế hoạch đang thuê một người QA duy nhất bây giờ và có lẽ đang dần phát triển chức năng QA, thì có lẽ sẽ tốt hơn nếu người đó báo cáo trực tiếp với giám đốc phát triển sản phẩm. Phần khó nhất trong công việc của anh ấy, và quan trọng nhất, sẽ là biến đổi văn hóa tổ chức của bạn để tích hợp QA vào tất cả các bước của quy trình chứ không phải là điều được thực hiện sau thực tế.

Tuy nhiên, thứ chúng tôi chưa có là QA ...

Đã được thực hiện điều đó - lời chia buồn chân thành của tôi. Được đưa ra ở trên tôi sẽ nói rằng việc thử nghiệm (s) sẽ tốt hơn nhiều so với những gì bạn có bây giờ, bất kể họ sẽ hạ cánh ở bộ phận nào.

Ngoài ra, tôi cảm thấy an toàn khi đề xuất bộ phận riêng cho QA.

Tôi đã tham gia vào hai bản phát hành không theo quan điểm QA - một lần với tư cách là người thử nghiệm, một bản khác là nhà phát triển. Trong cả hai trường hợp, tôi nghĩ rằng có bộ phận QA riêng biệt là khá hữu ích.

Theo như tôi có thể biết khi những người thử nghiệm ở bộ phận riêng biệt, việc che giấu các vấn đề về chất lượng sản phẩm đằng sau "liên kết nhóm" giả mạo trở nên khó khăn hơn . Điều này giúp mọi người hiểu rõ những gì chúng tôi đang phát hành và tại sao. Điều này lần lượt giúp quản lý kỳ vọng của khách hàng và lập kế hoạch phát triển hơn nữa.

Trong hầu hết các trường hợp, QA nên tách biệt với Phát triển. Mặc dù mục tiêu giữa cả hai bộ phận là như nhau (phát hành các sản phẩm / giải pháp chất lượng), QA cần cảm thấy họ có quyền sửa chữa và đưa ra đề xuất về các sản phẩm có sự phát triển và có cùng quan điểm. Nếu người đứng đầu QA báo cáo trực tiếp cho người đứng đầu phát triển, điều này có thể dẫn đến việc QA lùi lại một bước và chịu sự phát triển (và do đó, mã / sản phẩm chậm chạp bị đẩy vào sản xuất).

Phụ thuộc vào phương pháp phát triển mà bạn đang sử dụng: nếu bạn đang thực hiện nhanh nhẹn / nạc thì Thử nghiệm Agile có thể là hướng đi và vì thế sẽ cần phải gần gũi với các nhà phát triển.

Từ những gì bạn đang nói, bạn có một công ty nhỏ. Nó có ý nghĩa với tôi để tận dụng kích thước và khả năng giao tiếp trong khi bạn có thể, trước khi bạn trở nên lớn hơn. Điều này ngụ ý giữ chúng với sự phát triển.

Trong một công ty lớn hơn khi bạn có các nhóm Dev và QA có quy mô khá, việc chia tách chúng ra sau đó và có thể duy trì các mục tiêu nhóm riêng biệt, riêng biệt, v.v.

Bây giờ, tôi cũng chắc chắn sẽ có một vài vị trí QA đầu tiên là vị trí SDET ... tức là. người kiểm tra với mã hóa. Tự động hóa của bạn lên, chạy và ổn định từ đầu.