Làm thế nào để kiểm thử một ứng dụng mà không có các yêu cầu?

How to Test an Application without Requirements?

Về mặt kỹ thuật thì không có ứng dụng nào mà không cần tài liệu mô tả. Hãy tưởng tượng một phần mềm không làm gì cụ thể mà chỉ đơn giản là chạy những dòng code. Nó sẽ giống như việc một chiếc cầu thang mà không dẫn đến đâu cả. Tất cả các phần mềm đều có những yêu cầu và được đặt mục tiêu vào một nhiệm vụ cụ thể, cụ thể nó là giải pháp cho một vấn đề nào đó. Vì vậy, phần mềm mà không có requirement là không thể. Tuy nhiên, phần mềm mà không có tài liệu yêu cầu là một thực tế không mong muốn mà hầu hết chúng ta phải đối mặt thường xuyên hơn là chúng ta muốn. Điều duy nhất tệ hại có thể xảy ra là tài liệu không đầy đủ, không chính xác hoặc tài liệu đã quá cũ. Đáng buồn thay là chuyện này cũng xảy ra. Thành thật mà nói, thực sự thì ko có gì thay thế được một bản yêu cầu tính năng/hệ thống được soạn thảo đầy đủ với các use cases và các màn hình mock up. Mặc dù chúng ta phải thừa nhận rằng điều này đang trở nên khan hiếm trong nghành công nghệ do chu kỳ phát triển nhành chóng và sự chuyển đổi mô hình theo hướng tối thiểu hoặc không có tài liệu. Do đó, bài viết này sẽ cố gắng đưa ra một vài kinh nghiệm, theo đó chúng ta có thể thấy được chính mình trong những tình huống đó.

Chúng ta hãy xem một vài lý do tại sao có thể bắt đầu một dự án mà không có tài liệu mô tả:

1. Một dự án đã hoãn được mở trở lại.
2. Tài liệu có ít format trong quá trình làm việc.
3. Tài liệu có thể đã có nhưng có thể không chi tiết hoặc chưa hoàn thành.
4. Release liên tục và các phiên bản cũ có thông tin liên quan không đạt được kết qủa mong muốn dẫn đến thiếu sót trong việc nắm bắt xem các chức năng hiện tại phản ứng thế nào với những cái mới. Đây là tất cả những trở ngại mà chúng tôi, tester, phải dũng cảm vượt qua và xuất hiện thành công.

Dưới đây là 3 phương pháp để kiểm thử một ứng dụng mà không có requirement:

Phương thức 1.

Với bất cứ một công việc nào bạn làm mà có ít tài liệu trên tay. Nó có thể là một backlog cơ bản bản (trong alige project ), một help file, một email, một phiên bản cũ của BRD/FRD hoặc các testcase cũ…

Điều tra, đặt câu hỏi xung quanh vấn đề và luôn luôn có một số tài liệu thử nghiện dù là nhỏ nhất.

Khi điều này không được thực hiện cũng không làm giảm kinh nghiệm sử dụng phần mềm của bạn. Ví dụ, nếu bạn phải kiểm thử hoạt động chuyển khoản cho một tài khoản ngân hàng, không ai nói cho chúng ta biết cần làm thế nào, phải không? Bởi vì với những khách hàng sử dụng ngân hàng trực tuyến tất cả cũng ta điều biết rằng chúng ta cần những account với một lượng tiền có sẵn để thực hiện chuyển khoản.

Phải thừa nhận rằng không phải tất cả các tình huống đều đơn giản như vậy, nhưng lại cũng có thể xảy ra.

Phương thức 2.

Sử dụng các phiên bản cũ / hiện tại của ứng dụng như một tài liệu tham khảo để kiểm tra các phiên bản tương lai của một sản phẩm phần mềm. Bây giờ, tôi thừa nhận điều này là trái ngược với quy tắc, "Không bao giờ viết các testcase bằng cách sử dụng ứng dụng như một sự tham khảo". Tuy nhiên, khi chúng ta đang làm việc trong một tình huống không hoàn hảo, chúng ta phải uốn nắn các quy định để phù hợp với nhu cầu của chúng ta.

Nó giúp ta dữ vững quan điểm trong từng khía cạnh khi làm việc bởi vì:

• Ứng dụng có thể chứa bug - vì vậy nếu sau khi đăng ký, hệ thống trực tiếp sẽ đưa bạn đến Screen1 (một màn hình giả thuyết nào đó vì lợi ích của ví dụ) - Không bao giờ được cho đó là hành vi đúng đắn. Ngoài ra nếu một trường có ký tự chữ và số và là một số điện thoại thì câu hỏi đặt ra là: chắc chắn rằng bạn không coi ứng dụng như 1 ví dụ cho các chức năng mong muốn
• Trong tình huống nêu trên sử dụng cách nhìn của bạn và có sự trợ giúp của ứng dụng để giúp bạn start, nhưng hãy cẩn thận với câu hỏi: nó có đang làm việc?

Phương thức 3

Nói chuyện với các member trong dự án:

• Đề nghị họ tham gia các cuộc meeting của dự án
• Đặt câu hỏi nếu bạn có thể tham gia vào các giai đoạn unit test và intergration test
• Nếu không, hãy hỏi nếu đội dev có thể chia sẻ các kết quả unit test và intergration test của họ.
• Sắp xếp thời gian để truyền đạt lại kiến thức khi bạn có thể.

Bây giờ chúng ta hãy áp dụng các phương pháp cho một ứng dụng cụ thể:

Chúng ta hãy giả sử có một trang web mua sắm, nơi bạn có thể thêm các sản phẩm vào giỏ hàng. Lý tưởng nhất là nếu có tài liệu hướng dẫn cần thiết cho chúng ta biết làm thế nào để thêm sản phẩm vào giỏ hàng, có bao nhiêu đối tượng có thể có ở một thời điểm, điều gì sẽ xảy ra khi các đối tượng mà bạn đã thêm vào đột nhiên biến mất khỏi giỏ hàng, số lượng sản phẩm tối đa bạn có thể mua cùng một lúc … Vấn đề của chúng ta là không có gì có sẵn tại thời điểm hiện tại.

Sử dụng phương thức 1:

Tìm bất kỳ tài liệu nào bạn có thể. Hỏi đội dev nếu họ có các màn hình mock-up, công cụ ALM hoặc bất kỳ thứ gì có thể phục vụ cho công việc của bạn. Nều bạn tìm thấy một thứ gì đó, thì đó sẽ là một khởi đầu tốt. Những nếu bạn không thu được gì từ phương pháp này, sau đó bạn có thể sử dụng trực giác hoặc sự phán đoán của một người kiểm thử để tiếp tục công việc.

Tất cả chúng ta đều biết giỏ hàng hoạt động như thế nào để đưa ra các giả thuyết và đi đến các kịch bản cơ bản như sau:

• Các item có thể được thêm vào giỏ hàng sau khi được duyệt hay tìm kiếm
• Một khi tôi thêm các item vào giỏ mua hàng, danh sách các item cần được refresh.
• Người dùng sẽ có thể tiếp tục mua sắm thậm chí sau khi thêm vài mặt hàng vào giỏ hàng.
• Thêm các mục giống nhau hai lần sẽ làm cho số lượng các item phải tăng lên.
• Các item có thể được cập nhật
• Các item có thể bị xóa bỏ
• Tổng số mặt hàng phải tương ứng với tổng giá trị của các mặt hàng khi được thêm vào giỏ hàng.
• Thuế phải được tính toán dựa trên việc nhập vào các mã zip
• Chi phí vận chuyển phải được thêm vào tương ứng

Sử dụng phương thức 2

Nếu đã có sẵn một phiên bản cũ của ứng dụng, điều này có thể giúp ích cho việc viết test case của bạn bởi vì bạn sẽ phải viết chính xác các step của vị trí click chuột, vị trí nhập dữ liệu đầu vào, kiểm thử cái gì… Screenshots/mock ups/wire-frames nếu có sẵn để có thể thay thế cũng rất tuyệt vời.

Như bạn có thể nhìn thấy từ màn hình phía dưới, những thứ này là những tên trường dễ thấy, các button hoặc các phần tử khác đang được hiện diện.

Bây giờ, ở thời điểm này người kiểm thử cần có một số câu hỏi như:

• Điều gì xảy ra khi tôi đưa một kí tự vào trong box số tiền?
• Khi tôi thêm quá nhiều mặt hàng?
• Số lớn nhất của các mặt hàng này có thể mua là bao nhiêu?

Áp dụng phương pháp 3.

Đưa danh sách các câu hỏi của bạn để BA, Developer hoặc có thể là khách hàng để tìm cách làm rõ vấn đề. Một khi phương pháp 3 được thực hiện, bạn nên trang bị cho mình tất cả các thông tin mà bạn sẽ cần để viết những test case chi tiết và thực thi các thử nghiệm của bạn một cách tự tin như khi bạn có sẵn một tài liệu hướng dẫn. Đồng ý rằng nó có rất nhiều bước và nhiều follow hơn nữa, nhưng để đảm bảo chất lượng kiểm thử thì không thể tránh khỏi những bước này.

Nguồn tham khảo: http://www.softwaretestinghelp.com/how-to-test-an-application-without-requirements/