Hiếu_Nguyễn

• Critical - Mức độ nghiêm trọng: Những lỗi nghiêm trọng khiến người dùng không thể sử dụng được ứng dụng như hệ thống sập, dữ liệu bị mất, ứng dụng không cài đặt được...
• Major - Mức độ cao: Chức năng chính của sản phẩm không hoạt động
• Medium - Mức độ trung bình: Sản phẩm hoặc ứng dụng hoạt động không đáp ứng tiêu chí nhất định hoặc vẫn còn bộc lộ một số hành vi không mong muốn, tuy nhiên các chức năng khác của hệ thống không bị ảnh hưởng.
• Low - Mức độ thấp: Lỗi xảy ra hầu như không ảnh hưởng gì đến chức năng, nhưng vẫn là lỗi và vẫn cần được sửa. Ví dụ như các lỗi về sai text, sai vị trí button,

• High: Bug phải được sửa ngay lập tức sau khi phát hiện bug
• Medium: Bug có thể được sửa trong lần cập nhật phiên bản sau
• Low: Bug không cần sửa ngay, có thể sửa sau khi các bug High và Medium đã được sửa hết

• High priority, high severity bug: Có lỗi xảy ra trên các chức năng cơ bản của ứng dụng và người dùng không thể sử dụng được hệ thống. Ví dụ: Khi đăng nhập vào một hệ thống, lỗi "Run time error" hiển thị trên trang web và người dùng không thể thực hiện được bất cứ thao tác nào nữa. Bug này được thể hiện là đường màu đỏ trên ảnh.
• High Severity – Low Priority bug: Điều này xảy ra khi các lỗi gây ra vấn đề lớn, nhưng chỉ xảy ra với 1 số điều kiện hoặc tình huống mà thực tế rất hiếm gặp. Bug này sẽ được sửa nhưng không cần sửa ngay lập tức. Ví dụ, khách hàng sử dụng các trình duyệt rất cũ và không thể tiếp tục đặt hàng trực tuyến được. Vì số lượng khách hàng sử dụng trình duyệt phiên bản cũ cũ là rất thấp, nên nó không phải là bug có độ ưu tiên cao. Bug này được thể hiện là đường màu hồng trên ảnh
• High Priority – Low Severity bug: Bug sẽ được sửa ngay nhưng không ảnh hưởng đến các chức năng khác của hệ thống. Ví dụ: Logo hoặc tên của công ty không được hiển thị trên trang web. Bug này phải được sửa càng sớm càng tốt mặc dù nó có thể không gây ra nhiều thiệt hại. Đường màu xanh biển thể hiện chính xác loại bug này.
• Low Priority – Low Severity bug: Loại bug này được thể hiện bằng màu xanh lá cây như trên hình. Lỗi không ảnh hưởng đến chức năng của hệ thống nhưng vẫn không đáp ứng được các tiêu chuẩn ở mức độ thấp. Ví dụ: Không có nhiều người quan tâm và xem trang chính sách quyền riêng tư trên một website bất kỳ, và việc trang này tải rất chậm cũng không ảnh hưởng quá nhiều đến người sử dụng. Bug này sẽ được xếp vào loại Low Priority – Low Severity.

• Hiểu và nắm chắc khái niệm độ ưu tiên và độ nghiêm trọng của bug, tránh nhầm lẫn và sử dụng thay thế cho nhau.
• Luôn luôn chọn mức độ nghiêm trọng dựa trên các vấn đề sẽ ảnh hưởng đến ưu tiên của nó. Trên thực tế là việc xác định độ nghiêm trọng của bug không hẳn lúc nào cũng mang tính chất tuyệt đối. Sẽ không có gì ngạc nhiên nếu chúng ta cho rằng vấn đề này là nghiêm trọng trong khi chủ sản phẩm, nhà quản lý dự án lại không nghĩ như vậy. Có thể cách chúng ta cung cấp thông tin không thể hiện được đầy đủ mức độ nghiêm trọng của vấn đề. Hãy phân tích và cung cấp thêm thông tin để cho thấy tác động nghiêm trọng của bug đối với sản phẩm cũng như người dùng như thế nào như xảy ra trên nhiều môi trường nào; tính lặp đi lặp lại của bug; có khả năng ảnh hưởng đến các thành phần, chức năng khác; hình ảnh thương mại của công ty v.v. Từ đó có thể lựa chọn độ ưu tiên của bug một cách hợp lý.
• Hiểu chức năng của hệ thống hoạt động như thế nào, phân tích, suy luận và hiểu kịch bản kiểm thử hoặc trường hợp kiểm thử trên thực tế sẽ ảnh hưởng như thế nào đến người sử dụng. Điều này cần rất nhiều sự hợp tác và tương tác với đội phát triển, trưởng nhóm test, trưởng nhóm phát triển... Trong các cuộc trao đổi đó bạn cũng cần phải tính đến yếu tố mất bao nhiêu thời gian để sửa các bug đó dựa vào độ phức tạp và thời gian xác nhận bug.
• Độ ưu tiên và độ nghiêm trọng của bug có thể sẽ khác nhau ở từng thời điểm và giai đoạn phát triển sản phẩm.

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ử.

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.

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.

Kiểm thử trong suốt quá trình phát triển

Sự tham gia của developer trong kiểm thử

Cross Functional Teams (Nhóm liên chức năng)

Mục tiêu ngăn ngừa lỗi hơn là phát hiện lỗi

Ít tài liệu hơn, tăng tính cộng tác