Đã từ lâu, đối với quy trình tạo ra sản phẩm trong ngành IT của chúng ta, việc kiểm tra – testing cũng được coi là 1 step quan trọng trước khi sản phẩm được release cho khách hàng. Chính vì vậy mà đội ngũ team QA chúng tôi được hình thành và đảm nhận vai trò đảm bảo chất lượng sản phẩm trước khi giao "thành quả" cho khách hàng. Và nếu ai đó hỏi bất kì QA hay tester nào rằng: Các bạn đã tìm ra bug như thế nào? thì chúng tôi có thể nhanh chóng định hình lại những công việc của mình và trả lời không thiếu một “step” nào. Nhưng câu trả lời đó rồi cũng nhanh chóng bị quên đi khi các bạn còn phải quan tâm đến những vấn đề khác.Vậy nên chúng tôi sẽ viết lại đôi ba dòng tâm sự ở đây để cho những người bạn hàng ngày thân thiết nhưng còn chưa "tường minh" về công thức tìm ra bug của chúng tôi để có thể test "như những tester" :))))
Công thức nào cũng đi theo các step, và công thức tìm ra bug của chúng tôi cũng vậy. Nhưng trước khi bắt tay thực hiện step 1, chúng ta thử lướt web, gõ vài dòng tra trên google để xem bug có nghĩa là gì nhé!
Bug là gì ?
Theo wikipedia định nghĩa thì:
"Bug là những error, flaw, failure, hay fault tạo ra một kết quả sai, hoặc không lường đến được."Đơn giản có thể coi nó như một thứ gì đó không hoạt động đúng theo thiết kế. Tuy nhiên còn nhiều thứ phát sinh không được mô tả trong thiết kế và requirement của khách hàng.
Đọc đến đây thì thử dừng lại và nghĩ một chút nào !
Thứ nhất: – Bug là 1 thứ gì đó không hoạt động đúng theo thiết kế và requirement.Vậy lật ngược lại vấn đề, ta sẽ thấy rằng, chỉ cần làm đúng theo requirement là sẽ không tạo ra bug. Vì vậy mà QA/Tester khi viết testcase sẽ dựa vào yêu cầu trong requirement để check xem mọi thứ đã được làm theo đúng requirement chưa.
Thứ hai: – Có nhiều thứ phát sinh không nằm trong thiết kế và requirement.
Vậy những thứ phát sinh không nằm trong requirement là gì? Tùy theo kinh nghiệm ít nhiều của mỗi QA/Tester thì có thể biết được những thứ phát sinh không nằm trong requirement.Ví dụ: các common defect (lỗi nhập html, validate trường số điện thoại, validate trường mail, lỗi phi chân lí …). Những lỗi như vậy khách hàng không mô tả trong req nhưng chúng ta vẫn phải đảm bảo hệ thống không mắc các lỗi trên.
Bây giờ ta sẽ đi vào step đầu tiên.
Step 1. Phân tích requirement
Ở step này, chúng ta cần phải đảm bảo rằng mọi thông tin liên quan đến dự án đều được cung cấp đầy đủ. Đầu tiên sẽ là đọc lướt qua toàn bộ requirement để biết được các thông tin cơ bản của dự án như:
– Mục đích của dự án là gì
– Quy mô của dự án như thế nào?
– Thời gian thực hiện dự án
V..v..
Sau đó, ta sẽ đi vào đọc hiểu mô tả cụ thể các chức năng chúng ta cần phải thực
hiện và nếu có thể, hãy tự thống kê lại các chức năng của hệ thống bằng mô hình sơ đồ cây.
Step 2. Chuẩn bị bộ test case thật chất lượng
Dựa trên requirement đã đọc hiểu và phân tích, chúng ta sẽ bắt tay vào viết testcase. Tùy từng dự án để quyết định viết auto test case hay detail test case dành cho manual test hay chỉ đơn giản là list ra các trường hợp cần test cho từng chức năng khi thời gian test dự án quá gấp. Sau khi viết xong, nếu có thời gian, các thành viên trong team sẽ thực hiện review chéo test case để đảm bảo không bỏ sót trường hợp test nào. Và làm thế nào để có một bộ test case thật chất lượng? Ta sẽ dựa vào requirement để thực hiện viết testcase.
Ví dụ khi requirement yêu cầu check validate ở mục name ở một form đăng kí như sau:
|
Required |
Type |
Format |
Maxlengh |
|
|
Name |
〇 |
Text(alphabet,kanji,katakana) |
20 |
Từ requirement trên ta có những trường hợp test sau:
– Name: + Kiểm tra trường hợp bỏ trống
+ Kiểm tra trường hợp kí tự nhập là alphabet (VD: hana …)
+ Kiểm tra trường hợp kí tự nhập là kanji (VD: 山田 …)
+ Kiểm tra trường hợp kí tự nhập là katakana (VD: カタカナ…)
+ Kiểm tra trường hợp kí tự nhập là kí hiệu đặc biệt (#$%^&)
+ Kiểm tra trường hợp nhập maxlengh 19 kí tự
+ Kiểm tra trường hợp nhập maxlengh 20 kí tự
+ Kiểm tra trường hợp nhập maxlengh 21 kí tự
+ Kiểm tra trường hợp nhập kí tự số
Ngoài những mô tả trong requirement cũng cần phải kiểm tra trường hợp về "những thứ phát sinh không nằm trong mô tả hay bản thiết kế" như:
+ Kiểm tra trường hợp nhập kí tự html
+ Kiểm tra trường hợp clear data vừa nhập sau khi nhấn button cancel
Step 3.Thực hiện test
Khoan hãy test vội các bạn nhé, chúng ta cần phải đảm bảo rằng môi trường, device và data đều sẵn sàng trước khi bắt tay vào test. Nếu mọi thứ đã sẵn sàng thì có thể sử dụng "vũ khí" là bộ test case để ra trận rồi. Trước tiên hãy đảm bảo toàn bộ test case đều pass rồi sau đó sẽ thực hiện test lặp lại với các môi trường test khác nhau vì nhiều khi trên Chrome không bị lỗi nhưng khi chạy trên IE lại bị lỗi. Trường hợp lỗi ở môi trường khác nhau như thế này hoàn toàn không hiếm. Trồng cây bao lâu cũng đã đến lúc thu "thành quả" rồi đây các bạn ạ. Khi tìm ra bug chúng ta sẽ phải làm gì với nó? Hãy "báo cáo" cho "cha đẻ" của chúng bằng cách log chúng thành issue lên phabicator của dự án. Ơ nhưng mà log như thế nào cho dễ hiểu nhỉ? Thử tham khảo hướng dẫn log bug dưới đây nhé:
https://viblo.asia/p/log-bug-gioi-nhu-mot-ky-su-m68Z0NrA5kG
Khi bạn nghĩ bạn đã hoàn thành hầu như tất cả các test case và cảm thấy hơi mệt thì hãy chuyển sang thực hiện một vài random testing. Có những trường hợp test cần phải tích hợp giữa các chức năng với nhau thì lúc này random testting rất quan trọng và còn giúp QA/Tester tìm ra "bug khủng" nữa đấy.
Đã xong ! Chỉ với 3 step đơn giản bạn đã có thể trở thành tester không chuyên nghiệp nhưng cũng đủ để các bạn dev phải dè chừng rồi 😛
Tiếp theo là góc chia sẻ của chúng tôi về việc làm thế nào để tìm bug tốt hơn:
Các bạn hãy tham gia các cộng đồng tester, tìm biết thêm về các bug "khủng" mà các dev hay mắc phải trong quá trình code.Bên cạnh đó, bạn hãy chăm chỉ đọc defect file mà các đồng nghiệp bên cạnh và khách hàng đã log (tôi tin rằng bạn sẽ học được rất rất nhiều kinh nghiệm test từ họ).
Cuối cùng là mối quan hệ "đơn thuần nhưng lại cần mềm và mỏng" giữa QA/Tester và Dev
Tester: "Tôi cực kì quan trọng, không có tôi thì không thấy bug và chất lượng sản phẩm cũng không được đảm bảo" …
Developer: "Tôi cực kì quan trọng vì tôi tạo ra những dòng code và xây dựng cả phần mềm không thì lấy gì cho bạn test" …
PO: "Tôi rất là quan trọng và cốt lõi của dự án, tôi đàm phán với khách hàng và phân chia task, tạo kế hoạch và đốc thúc tất cả các thành viên làm việc" ..
CEO: "Tôi ko quan tâm các anh làm gì, hay ai quan trọng, nếu ko hoạt động trơn tru hoặc khách hàng không hài lòng" blah blah blah.. mời các anh ra đường.
Câu chuyện trên chắc hẳn là tâm lí chung của chúng ta. Nhưng thực tế DEV và QA hay PO(nhóm phát triển) cùng một phe, cùng nhau thực hiện một nhiệm vụ đó là làm ra những sản phẩm chất lượng thế nhưng mặt khác DEV và QA là ở 2 chí tuyến khác nhau:
DEV lập trình – QA tìm lỗi – DEV sửa – QA tìm lỗi, vòng lặp cứ tiếp tục như vậy cho đến khi không còn bug hoặc đến ngày phải release cho khách hàng. Dù ở chiến tuyến nào thì mục đích chung của chúng ta vẫn là một sản phẩm chất lượng tốt, khách hàng hài lòng. Vậy nên, thay vì cố gắng khẳng định bug QA tìm ra không phải là lỗi hay cố gắng tìm ra nhiều bug nhất có thể rồi bắt dev phải fix mà không cần nghe dev giải thích thì chúng ta nên "hợp tác" với nhau, cùng nhau "phát triển" để mang về sự hài lòng từ khách hàng. Chẳng phải như vậy ắt sẽ mang lại một cái kết có hậu hay sao ? 🙂
Mong rằng dù ít hay nhiều thì các bạn cũng đã có cái nhìn sơ đẳng nhất về công việc testing và nếu có cơ hội hãy thử thực hành nhé. Bật mí một chút là cảm giác tìm ra bug rất yo most đấy 🙂