How To Test Software Without Any Requirements?

Tất cả các phần mềm có những yêu cầu và mục đích sử dụng của nó. Tuy nhiên, phần mềm mà không có tài liệu yêu cầu, tài liệu yêu cầu không đầy đủ, không chính xác hoặc là tài liệu đã lỗi thời... là một thực tế mà không may hầu hết chúng ta gặp phải, đó hẳn là điều mà chúng ta không hề mong muốn. Và trên thực tế thì điều này rất hay xảy ra. Nó không những gây khó khăn trong công việc mà còn không thể đánh giá và lập kế hoạch test một cách chính xác, ảnh hưởng đến chất lượng sản phẩm phần mềm.

Trong bài viết này sẽ thảo luận về vấn đề Làm thế nào để thực hiện kiểm thử phần mềm khi mà không có bất cứ tài liệu yêu cầu nào. Không SRS, không FRD và làm thế nào tester có thể thực hiện công việc của mình một cách hiệu quả.

Làm thể nào để kiểm thử phần mềm mà không có bất kỳ yêu cầu nào?

Hãy cùng thảo luận những khó khăn mà tester phải đối mặt khi thực hiện kiểm thử phần mềm mà không hề có bất kỳ tài liệu đặc tả yêu cầu nào.

1. Việc thiết kế Test cases hoặc Test Scenarios trở nên khó khăn vì bạn không hề có bất kỳ tài liệu nào để tham khảo.
2. Khi bạn có tài liệu yêu cầu cụ thể, bạn sẽ biết được phần mềm hoạt động như thế nào khi chúng được hoàn thành nhưng ở đây bạn chỉ có thể tiếp cận ở mức tối thiểu mà thôi.
3. Ngoài ra tài liệu yêu cầu cũng có thể dễ dàng gây ra hiểu lầm hoặc thay đổi thường xuyên dẫn đến việc hệ thống không ổn định và khó khăn trong việc kiểm thử.

Để làm việc với những dự án như vậy, bạn cần có sự hiểu biết tốt, giao tiếp hiệu quả bằng lời nói cũng như bằng văn bản và có một kế hoạch thích hợp. Có một vài điều quan trọng cần biết trước khi bắt đầu giai đoạn kiểm thử, chẳng hạn như:

1. Xác định kỹ thuật kiểm thử sẽ sử dụng trong quá trình kiểm thử hệ thống (kiểm thử chức năng, kiểm thử hồi quy, kiểm thử tải...)
2. Sử dụng version cũ của phần mềm như một tài liệu tham khảo để kiểm thử phiên bản tương lai của sản phẩm phần mềm.
3. Những tài liệu mà developer tham khảo cho mục đích code thì Tester cũng có thể tham khảo để có ý tưởng phần mềm sẽ hoạt động thế nào.
4. Những rủi ro liên quan đến các sản phẩm phần mềm.

Một khi đã phân tích tất cả các điểm trên, sẽ dễ dàng hơn cho chúng ta lập kế hoạch phù hợp và thực hiện kiểm thử. Bây giờ chúng ta hãy xem một số điểm quan trọng trong khi kiểm thử sản phẩm phần mềm như vậy:

1. Đọc các tài liệu mà dev phát triển sản phẩm dựa trên tài liệu ấy và chia sẻ test cases của bạn với họ. Bằng cách này, bạn sẽ biết dev đang phát triển phần mềm như thế nào và bạn có thể thiết kế test cases của bạn dựa trên đó. Ngoài ra, bằng cách chia sẻ các trường hợp thử nghiệm của bạn với họ, bạn được đảm bảo rằng bạn hiểu các chức năng và sẽ test nó một cách đúng đắn.

2. Trong trường hợp của bất kỳ sự mơ hồ nào, hãy làm cho nó rõ ràng càng sớm càng tốt. Liên quan đến tất cả các team như là testers, developers, business analysts và clients. Hãy chắc chắn rằng sau khi buổi họp tất cả các đội bóng đang ở trên mức độ hiểu biết cùng và sau đó tiến hành với quá trình này.

3. Lập tài liệu về những gì bạn đã test và work flow cho phần mềm, nên sử dụng sơ đồ sẽ giúp bạn hiểu rõ hơn về hệ thống.

4. Chuẩn bị một danh sách các mục In-Scope, Out-of-Scope và chia sẻ với tất cả các thành viên trong team và được manager của bạn phê duyệt. Bạn có thể cập nhật danh sách bất cứ lúc nào sau này sau khi thảo luận với các thành viên trong team.

5. Đôi khi, người dùng cuối (tại phía khách hàng) có thể thử nghiệm các sản phẩm ở giai đoạn sớm hơn, nên nếu có thể, hãy lập ra những test case từ cách sử dụng hệ thống của người dùng biết những mong muốn và lợi ích của các phần mềm của họ.

6. Thực hiện Exploratory Testing nhiều lần, vì bạn không có bất cứ yêu cầu cụ thể nào, bạn có thể thường xuyên kiểm tra ngẫu nhiên và bất cứ điều gì bạn cảm thấy là không đúng, bạn có thể thảo luận với khách hàng và làm cho nó chính xác hơn bằng cách gửi nó cho team developer.

7. Hãy suy nghĩ từ quan điểm của tất cả người sử dụng và làm cho phần mềm hữu ích hơn. Đề xuất ý kiến và giải pháp của bạn. Có nhiều cách sử dụng khác nhau từ phía người dùng, nếu bạn có thể suy nghĩ từ quan điểm của họ sau đó phần mềm sẽ trở nên tương thích và linh hoạt hơn.

8. Chia toàn bộ hệ thống thành các module nhỏ và hiểu chúng một cách chi tiết. Bằng cách này bạn sẽ test của mỗi một phần của việc tạo ra phần mềm tối đa vùng phủ sóng thử nghiệm. Nó là dễ dàng hơn để kiểm thử một module nhỏ hơn là kiểm thử toàn bộ hệ thống cùng một lúc.

9. Tự động hoá các test case những chức năng đã được cố định để tiết kiệm thời gian và nguồn lực. Trong những giai đoạn đầu của dự án khi mà yêu cầu liên tục thay đổi, bước này có thể thấy không cần thiết, nhưng sau một thời gian khi các yêu cầu hoặc chức năng được cố định, bạn có thể tạo test case tự động. Ví dụ, một màn hình đăng nhập. Bạn biết chắc chắn những thông tin đầu vào có trên màn hình như Username, password, Captcha... vv, do đó bạn có thể viết các test case cơ bản liên quan đến màn hình này và tự động hóa chúng.

Kết luận:

Khi chúng ta làm việc với một dự án mà không có yêu cầu, kế hoạch cụ thể, sẽ có những thách thức mà chúng ta vừa thảo luận, nhưng có nhiều cách để xử lý chúng. Giao tiếp tốt với khách hàng và developer, lấy ý kiến phản hồi của họ thường xuyên để biết mong muốn của họ là gì. Khi bạn biết cần phải test gì và test như thế nào, bạn có thể tự tạo tài liệu yêu cầu và có thể tham khảo hoặc cập nhật suốt quá trình kiểm thử.