Những vấn đề liên quan đến Software Requirement Documents

 Jan-04-2021 01:59 PM
#news

Đối với một QA cụm từ Software Requirement Documents là một cụm từ vô cùng gần gũi. Mỗi dự án lại có một tài liệu đặc tả yêu cầu riêng, nó là một tài liệu vô cùng quan trọng, góp phần vào sự thành công của dự án. Tuy nhiên không phải lúc nào tài liệu requirement cũng là một tài liệu hoàn chỉnh, điều này đã gây một số khó khăn nhất định cho đội phát triển dự án nói chung và team QA nói riêng. Vậy có những khó khăn nào liên quan đến tài liệu đặc tả của phần mềm và cách giải quyết ra sao, trong bài viết này tôi và bạn hãy cùng làm rõ nó nhé !

1. Định nghĩa

  • Tài liệu đặc tả yêu cầu của phần mềm tài liệu mô tả được những yêu cầu của khách hàng đối với hệ thống, sản phẩm sẽ cần đáp ứng những gì, mục tiêu hoạt động của phần mềm là gì.
  • Tài liệu yêu cầu phần mềm bao gồm các yêu cầu chức năng và các yêu cầu phi chức năng

2. Tầm quan trọng trong việc phân tích tài liệu đặc tả yêu cầu của phần mềm

Việc phân tích tài liệu đặc tả yêu cầu một cách kỹ càng có rất nhiều lợi ích:

  • Tránh nhầm lẫn trong yêu cầu
  • Đưa ra đề xuất để cải thiện chất lượng phần mềm
  • Giúp QA liệt kê ra tất cả các test case dựa trên yêu cầu
  • Ngăn ngừa lỗi ở những giai đoạn đầu
  • Tiết kiệm thời gian và chi phí phát triển phần mềm

3. Những khó khăn xoay quanh Requirement

 

  • Không có requirement
  • Requirement nghèo nàn
  • Xung đột requirement

Không có requirement, requirement nghèo nàn hoặc xung đột requirement dẫn tới việc đội phát triển dự án không nắm được đầu ra của ứng dụng, không có quy chuẩn để biết được phần mềm có đang hoạt động đúng hay không

Khi không có một tài liệu đặc tả cụ thể đồng nghĩa với việc không thể đảm bảo được đội dự án đang hiểu đúng chức năng mà khách hàng yêu cầu,có thể có sự xung đột trong suy nghĩ của các thành viên trong đội dự án, và xung đột với mong muốn đáp ứng của khách hàng. Đến cuối cùng khi sản phẩm được làm ra không đúng với mục đích của khách hàng thì sẽ mất rất nhiều thời gian, công sức và chi phí để sửa chữa

Đôi khi chính khách hàng cũng không hiểu họ muốn gì nên có thể đưa ra những yêu cầu xung đột nhau. Điều này khiến cho requirement bị thay đổi liên tục, kéo theo đội phát triển dự án cũng liên tục phải chạy theo những thay đổi “chưa có hồi kết" của khách hàng

Ngoài ra việc requirement không đầy đủ cũng gây rất nhiều khó khăn cho QA trong quá trình thiết kế Test Checklist và Test cases

4. Giải pháp

Vậy chúng ta phải làm thế nào để vượt qua được những cản trở đó? Sau đây là một số giải pháp:

  • Điều tra, đặt câu hỏi xung quanh vấn đề, tạo dựng Q&A file.Không dùng ứng dụng như một tài liệu mong muốn, ứng dụng có thể giúp bạn bắt đầu nhưng hãy luôn đặt câu hỏi: Nó có đang làm việc đúng
  • Là một QA chúng ta không chỉ hoàn toàn phụ thuộc vào khách hàng mà còn phải luôn luôn gợi ý, hỗ trợ để cùng khách hàng đưa ra phương án tối ưu nhất đồng thời tránh những thay đổi nhiều lần về sau
  • Luôn đặt mình vào vị trí của người dùng cuối tìm hiểu từ các ứng dụng khác, hành vi được mong đợi chung của người dùng, hiểu về luồng công việc, nghĩ về các cách thức thuận tiện cho người dùng, logic của ứng dụng và cách để đối mặt với các tình cảnh khác nhau

Một số tình huống thường gặp

Nếu test function không có đủ tài liệu hoặc tài liệu nghiệp vụ không chi tiết thì làm thế nào?

Trong trường hợp test function không có đủ tài liệu hoặc tài liệu nghiệp vụ thì ta cần xác nhận lại vấn đề tài liệu đặc tả yêu cầu không đầy đủ với BA và PM của dự án. Trong trường hợp hiện tại chưa thể có thêm nghiệp vụ hay dự án của mình vừa làm vừa nghiên cứu thì chúng ta dựa trên những luồng nghiệp vụ hiện tại để viết test cases và thực hiện test. Trong trường hợp chưa có người tham gia phân tích hay viết tài liệu chi tiết hơn thì em có thể tham gia hỗ trợ dự án bổ xung, viết hay thu thập nghiệp vụ cho dự án

Nếu không có Tài liệu Đặc tả yêu cầu thì có thể chuyển từ yêu cầu của khách hàng sang tài liệu đặc tả yêu cầu được không?

Như chúng ta đã biết những yêu cầu của khách hàng thường mang tính chất văn nói, còn một tài liệu đặc tả yêu cầu thường mang tính khoa học. Nếu không có tài liệu đặc tả yêu cầu thì chúng ta không thể đưa nguyên các yêu cầu của khách hàng thành tài liêụ đặc tả yêu cầu được. Tuy nhiên trong trường hợp chưa có nhân lực hoặc chưa có thời gian để hoàn thành tài liệu đặc tả yêu cầu thì ta có thể sử dụng yêu cầu của khách hàng để bám vào viết test cases và thực hiện test. Nếu thiếu nội dung thì trong quá trình việc chúng ta sẽ hỏi thêm và confirm với BA ( cán bộ giải pháp) hoặc PM ( Quản trị dự án)

Khách hàng thay đổi yêu cầu liên tục. Bạn sẽ làm gì với tình huống này ở vị trí leader?

Khi có bất cứ một sự thay đổi nào chúng ta cũng cần họp team phát triển lại để đánh giá, phân tích yêu cầu thay đổi: Đội dự án cần phân tích những yêu cầu thay đổi đó, nếu thay đổi đó được thực hiện thì có khả năng ảnh hưởng đến những chức năng nào? Ước lượng effort bỏ ra để thay đổi, liệu có ảnh hưởng đến thời gian release sản phẩm hay không? Nếu thay đổi quá nhiều, tính thành man-month và trả phí cho mỗi lần thay đổi nghiệp vụ. Đồng thời ngay từ giai đoạn phân tích yêu cầu, QA phải báo lại cho khách hàng nếu phát hiện những bất hợp lý trong tài liệu, tích cực đưa ra những suggest cho khách hàng nhằm giảm thiểu sai sót ngay từ giai đoạn đầu và tránh dẫn đến nhiều thay đổi về sau

5. Kết luận

Không phải lúc nào tài liệu Software Requirement cũng đầy đủ, điều này gây nhiều khó khăn cho QA, tuy nhiên trong mọi trường hợp chúng ta bình tĩnh, hãy cố gắng kiểm soát và đưa ra giải pháp hợp lý,góp phần phát triển một ứng dụng tuyệt vời.

Đào Thị Vân Anh

Hỗ trợ trực tuyến
Online Offline
Hỗ trợ trực tuyến