Chiếc hộp của dân QA

Bước vào lĩnh vực kiểm thử phần mềm, một trong những điều đầu tiên chúng ta được học là “Hai Hộp” - hộp trắng và hộp đen. Và như một điều tất yếu, ta thường chỉ tập trung vào xem xét hai chiếc hộp đó. Chính điều này đã hạn chế tư duy, và ngăn chúng ta đột phá.Trường lớp không dạy bạn cách “think outside the box” để cân nhắc nhiều khía cạnh hơn, tìm ra nhiều điều quan trọng, như cái cách mà một kiểm thử viên nên hướng tới. 

Thử hình dung nhé, khi test nếu bạn được đưa ra hai lựa chọn, bạn sẽ chỉ chọn trong 2 phương án đó? Hay nếu chỉ được cung cấp một công cụ, bạn cũng sẽ chỉ sử dụng công cụ đó ư?

Nếu bạn không làm vậy mà chủ động tìm kiếm các công cụ, các cách thử nghiệm khác nghĩa là bạn đang bắt đầu “think outside the box” rồi đấy. Không cần gì quá lớn lao, chỉ cần một vài động thái sáng tạo, “nghĩ cách tốt hơn, thử làm điều mới”. Nếu bạn muốn có những điều chưa bao giờ có, hãy làm những điều chưa từng làm!

Để có được câu trả lời cụ thể hơn, chúng sẽ cùng thảo luận về một vài kỹ thuật trong kiểm thử phần mềm nhé!

1. Kỹ thuật Rapid Fire

Rapid Fire cho ta biết cách tạo ra các Test case một cách nhanh chóng nhất. Kĩ thuật này kết nối việc kiểm thử (testing) với hiệu suất (performance). Vậy ở đây chúng ta làm sao để tư duy đột phá? Những điều ban đầu xuất hiện trong đầu khi chúng ta nói về việc tạo trường hợp thử nghiệm là Tài liệu yêu cầu, Bảng tính Excel và một số hướng dẫn do tổ chức cung cấp. Hãy bỏ hết chúng qua một bên và suy nghĩ về một ý tưởng mới, về những gì bạn nghĩ rằng bạn sắp kiểm tra.

Thử dùng đến giấy và bút, viết ra tất cả kịch bản bạn có thể tưởng tượng đến trong vòng 60 giây. Lặp lại quá trình này cho đến khi bạn không thể nghĩ ra thêm gì nữa và cuối cùng xem xét chúng. Bạn sẽ ngạc nhiên khi thấy số lượng ý tưởng/test case bạn đã tự mình tìm ra.

2. Ý tưởng kiểm tra ngược hoặc lùi

Quy trình bình thường mà bạn bạn hay làm khi thử nghiệm là gì? Đây là các bước chính xác được sử dụng trong khi phát triển ứng dụng?

“Requirements >> Unit Cases >> Integration Testing >> System Testing”

Mặc dù trong quá trình phát triển sản phẩm, các dev luôn tìm cách mang đến những trải nghiệm tốt nhất cho người dùng. Tuy nhiên không phải lúc nào cũng thành công vì End-users,đôi khi sẽ có những cách nhìn nhận khác hơn. Đó là lý do tại sao khiếm khuyết sản phẩm hoặc khiếm khuyết UAT tồn tại ngay cả sau các vòng thử nghiệm đơn vị, thử nghiệm tích hợp và thử nghiệm hệ thống.

Ví dụ: Yêu cầu cho biết bạn có thể tải lên một tệp không vượt quá kích thước 10 MB. Hầu hết tester sẽ theo dõi việc tải lên 1 MB, 2 MB, 3 MB và cứ thế đạt đến 10 MB hoặc thông báo lỗi được hiển thị. Tại sao không bắt đầu với 10 MB và sau đó thử 11 MB rồi 9 MB? Ví dụ này không có gì ngoài một BVA (Phân tích giá trị biên). Tuy nhiên, có bao nhiêu người trong chúng ta đã thử sử dụng BVA trong các tình huống khác với hộp đầu vào?

3. Luôn đặt câu hỏi

Mỗi QA luôn cần biết rõ về mục đích của một yêu cầu. Việc đặt câu hỏi sẽ giúp QA hoàn thiện mục đích thử nghiệm của mình. Muốn kiểm thử giỏi, bạn giỏi việc đưa ra các câu hỏi trước đã. Cần chắc chắn rằng không một mệnh đề nào (dù nhỏ đến mấy) nào bị bỏ qua. Điều này cũng sẽ nâng cao kiến thức Miền của người thực hiện kiểm tra. 

Chia sẻ về vấn đề có nên thường xuyên đặt ra câu hỏi, cô nàng QA xinh đẹp Hà Trần cho biết: “ Trong quá trình làm việc, mình thấy các câu hỏi Q&A thường là các câu hỏi liên quan spec dự án. Đôi khi có những vấn đề cảm thấy chưa chắc chắn, cũng muốn liên hệ khỏi khách hàng cho chắc chắn nhưng lại e ngại họ phiền lụy và đánh giá rằng “dễ như thế mà cũng phải hỏi”. Tuy vậy, mất lòng trước được lòng sau, lắm lúc vẫn cứ phải cân nhắc để đưa ra câu hỏi hợp lý nhất có thể, quan trọng nhất vẫn phải là hiệu quả cuối cùng của dự án.”

Hãy luôn nhớ rằng: Câu hỏi ngớ ngẩn duy nhất là câu hỏi không có nội dung.

4. Nghiên cứu lại case cũ

Nghiên cứu rất có lợi trước khi bắt đầu kiểm thử. Chỉ cần lưu ý đến những vấn đề mà người khác gặp phải trong khi thực hiện một nhiệm vụ tương tự. Giả sử, bạn được yêu cầu kiểm tra trình duyệt chéo. Trước khi bắt đầu thử nghiệm, hãy xem xét kĩ các vấn đề mà người khác gặp phải khi sử dụng cùng một trình duyệt, bạn có thể tìm ra lỗi trước khi bắt đầu thử nghiệm thực tế của mình.

5. Tận dụng kinh nghiệm

Thỉnh thoảng, bạn sẽ gặp lại một vài ứng dụng tương tự như mà mình từng làm trước đây. Khi đó, hãy nhớ lại những gì đã trải qua, bạn sẽ có thể xác định các vấn đề tương tự theo cách nhanh hơn và tất nhiên là giải quyết chúng tốc độ hơn.

Kinh nghiệm đôi khi cũng là ở cách bạn xử lý linh động các tình huống “khó đỡ” trong quá trình phối hợp với đồng nghiệp một cách khéo léo. 

Ta có thể thấy rõ điều đó ở câu chuyện dưới đây từ chia sẻ của chị Thái Hà:

“Khi làm QA chắc chắn bạn đã từng đối đầu rất nhiều những bạn developer trẻ mới ra trường, nhiệt huyết và khá “cứng rắn”.Và QA có lẽ là đối tượng mà các bạn cho rằng hay “gây khó dễ” nhất tới công việc của mình. Đôi khi suy nghĩ đó có cũng tương tự với cả các dev kỳ cựu. Nhưng chờ đã, việc tìm ra gì đó chưa đúng chẳng phải chính là nhiệm vụ của chúng tôi hay sao? Cả QA và Dev đều làm phần việc riêng của mình để góp phần hoàn thiện sản phẩm. Thì QA ơi..khi đó bạn sẽ nghĩ như nào:

1. Thôi mặc kệ cứ đẩy cho BrSE hoặc BA confirm làm hay không? 

2. Mình cần ra tay một chút!

Nếu bạn chọn 1 thì đó là cách đơn giản đỡ phải nghĩ nhiều, cũng tốt cho bạn thôi nhưng lại chưa hẳn tốt cho dự án cũng như cho khách hàng hoặc là chính mối quan hệ của bạn với các dev.

Với mình, mình chọn phương án 2. Cách thứ 2 khi mình nói "mình cần ra tay một chút" ở đây không phải là "xuống tay, tranh cãi, gây gổ". Mà ý mình là nên có chút tác động đến Dev trước khi đưa cho BrSE confirm. Để làm gì ? Mình sang nói chuyện giải thích nguyên do vì sao mình muốn fix bug đó, hậu quả khi không fix sẽ như thế nào và nói nhẹ nhàng với dev rằng nếu như mình có thể giúp đối tác đánh giá cao hơn chỉ với vài skill nho nhỏ, mất chút xíu thời gian của dev thôi thì... Mình nghĩ sẽ không khó khăn gì để họ đồng tình và hợp tác hơn. 

Với mình thì chút động thái vận dụng kinh nghiệm và tư duy như vậy chính là một sự “đột phá” nho nhỏ trong công việc rồi.”

6. Tạm dừng kiểm thử

Kiểm thử đôi khi là một quá trình đơn điệu và các ý tưởng có thể bắt đầu bão hòa. Có nhiều lúc ta sẽ cảm thấy rằng không có giải pháp nào hiệu quả hoặc thậm chí cạn kiệt ý tưởng. Trong những trường hợp như vậy, hãy tạm dừng làm việc, để đầu óc nghỉ ngơi. Thư giãn và cho phép tâm trí của chúng ta cởi mở với những điều mới. Một cái đầu thoải mái sẽ mang đến cho bạn những tư duy sáng tạo mới, mở nút thắt khiến mà tưởng chừng như đã hết cách xử lý.

Nguồn tham khảo tại đây