Trách nhiệm của các vai trò trong vòng đời phát triển phần mềm

Trong hầu hết các trường hợp, vòng đời phát triển phần mềm bao gồm 6 giai đoạn được hiển thị bên dưới.

Để mô tả ngắn gọn tất cả các giai đoạn, trong giai đoạn Phân tích , tất cả các thông tin cần thiết và có sẵn được thu thập từ khách hàng để phát triển sản phẩm theo nhu cầu và mong đợi của khách hàng, và việc phân tích thông tin thu được được thực hiện. Kết quả của giai đoạn Phân tích là Đặc tả yêu cầu phần mềm. Trong Giai đoạn thiết kế , kiến ​​trúc phần mềm được phát triển, được sử dụng để triển khai phát triển hệ thống. Giai đoạn Phát triển bao gồm việc triển khai và mã hóa tất cả các thành phần của phần mềm sẽ được phát triển. Trong giai đoạn Kiểm thử , phần mềm đã phát triển được kiểm tra kỹ lưỡng và bất kỳ lỗi nào được tìm thấy đều được chuyển cho các nhà phát triển để loại bỏ nhằm đảm bảo rằng phần mềm đáp ứng tiêu chuẩn tuân thủ của khách hàng. Sau khi phần mềm được kiểm tra, nó được triển khai trong môi trường sản xuất. Sau khi được triển khai trong môi trường sản xuất, phần mềm phải được nhóm phát triển bảo trì .

BA và QA có những trách nhiệm chính trong suốt SDLC để đưa ra những thông lệ tốt nhất.

Nhưng thật không may, trên thực tế do thiếu nguồn lực nên không phải mọi trách nhiệm đều được đáp ứng.

Cách tiếp cận truyền thống thường gặp phải vấn đề là QA không tham gia đủ vào quá trình phát triển, dẫn đến hậu quả không thể khắc phục được — nhiều lỗi và vấn đề đã được phát hiện trong giai đoạn đầu của quá trình phát triển nhưng lại không được phát hiện cho đến giai đoạn cuối của dự án. Điều này khiến nhóm phát triển gặp khó khăn trong việc tìm ra bản chất của vấn đề và dẫn đến những thay đổi lớn về cấu trúc và kiến ​​trúc đòi hỏi nhiều nguồn lực khác nhau (thời gian và tiền bạc) để khắc phục nguyên nhân.

Chúng ta hãy cùng xem xét những cách tiếp cận chính trong sự hợp tác giữa BA và QA.

Làm việc trong sự cô lập

Nhìn chung, BA và QA là hai vai trò khác nhau hoạt động riêng biệt. Không đi sâu vào chi tiết, BA chuẩn bị các yêu cầu, QA không tham gia vào quá trình này và bắt đầu tìm hiểu các yêu cầu khi thử nghiệm một số tính năng nhất định. Cách tiếp cận như vậy có thể tiết kiệm thời gian và các nguồn lực khác cho cả hai vai trò ở giai đoạn đầu triển khai dự án.

Một phần vấn đề của cách tiếp cận truyền thống hơn khi quản lý dự án là QA không được tích hợp đầy đủ vào quy trình phát triển ngay từ những giai đoạn đầu tiên và do đó, rất nhiều quan niệm sai lầm, lỗi và vấn đề có thể được phát hiện trước đó không được phát hiện kịp thời.

Sự giao tiếp và cộng tác kém giữa BA và QA có thể dẫn đến nhiều hậu quả khác, chẳng hạn như hiểu sai các thuật ngữ được sử dụng trong hệ thống đã phát triển, hiểu sai về mối quan hệ giữa các tính năng và yêu cầu cũng như bỏ sót nhiều điểm.

Tóm lại, cách tiếp cận như vậy làm giảm hiệu quả và năng suất của nhóm, cuối cùng có thể dẫn đến thất bại của dự án.

Sự hợp tác

Một cách tiếp cận hợp tác khác là liên quan đến QA ngay từ những giai đoạn đầu, tức là từ quá trình thu thập yêu cầu.

Dựa trên kinh nghiệm, phương pháp này có những ưu điểm đáng kể nhất so với các phương pháp khác:

• Có một đôi mắt khác theo dõi việc này để tránh những định kiến ​​trong yêu cầu.
• BA hỗ trợ QA phân tích phạm vi kiểm thử, chuyển đổi use case thành test case và cung cấp thông tin để kiểm thử các tính năng phức tạp. Đây cũng là thông lệ rất phổ biến khi các test case được viết bởi BA.
• Trao đổi kiến ​​thức theo cả hai hướng.

Bên cạnh nhiều lợi ích, cách tiếp cận này cũng có nhược điểm là cần nhiều nguồn lực và thời gian hơn cho công việc thường ngày.

Sáp nhập vai trò BA và QA

Một số công ty và nhóm phát triển đã quyết định kết hợp trách nhiệm BA và QA thành một vai trò, đưa cùng một người vào cả hai đầu của quy trình để cải thiện sự hợp tác giữa các vai trò phát triển. Vai trò hợp nhất này là một liên kết quan trọng giữa nhu cầu kinh doanh của khách hàng và chuyên môn của nhóm.

Các nghiên cứu có sẵn về cách tiếp cận này cho biết vai trò tích hợp xác định nhiều số liệu hơn giúp cải thiện chất lượng sản phẩm. Và nó cũng cho phép phát hiện các vấn đề của dự án ở giai đoạn đầu của quy trình và giải quyết chúng với chi phí thấp hơn.

Nhưng giống như các cách tiếp cận khác, phương pháp này cũng có những hạn chế và nhược điểm, chẳng hạn như bỏ sót một số điểm quan trọng và nhấn mạnh vào một khía cạnh (phân tích kinh doanh hoặc đảm bảo chất lượng) do yếu tố con người, chỉ tiến hành thử nghiệm chức năng trong hầu hết các trường hợp, áp lực thời gian, quá tải thông tin và trách nhiệm ảnh hưởng đến hiệu quả thực hiện nhiệm vụ, bỏ lỡ cơ hội được giám sát thêm trong quá trình thực hiện, v.v.

Thay vì kết luận

Điều duy nhất còn lại để nói là việc sản xuất phần mềm đòi hỏi sự hợp tác liên tục của tất cả các bên liên quan để đạt được kết quả tốt nhất. Cần phải tìm ra một điểm chung và điều chỉnh theo đặc thù của từng dự án và nhóm.