Chuyển đến nội dung chính

Funny Section

 This page contents some of funny exception, some story base on the real story!

 

Dịch vụ OTP,

Giờ đi đâu cũng có smartphone nên mấy ông PO nghĩ rằng ai cũng có SIM điện thoại! Cơ mà SIM điện thoại thì dùng trả trước, nên có SIM nhưng chưa chắc đã có tiền. Team phát triển tài khoản thì đưa ra yêu cầu ai mua hàng thì phải active bằng OTP, nên ông người dùng nào nghèo không có tiền nạp điện thoại thì coi như không mua hàng sendo luôn!

  • So, stop being poor ?!

Tiếp nối câu chuyện SIM của tôi, tôi dùng 2 SIM, đăng ký được 2 cái tài khoản sendo, nạp cho nó ít tiền trong ví SenPay. Đến lúc cần giao dịch online, SIM ít dùng bị khóa 2 chiều, không nhận được OTP của SenPay gửi về, khi gọi lên CSKH SenPay thì em gãi vỗ bàn đùng đúng là em có gửi SMS cho anh rồi (sure, nhưng anh không nhận được). Giờ coi như nạp tiện ích cho SIM đó bằng tiền SenPay bị dead lock!

Câu chuyện UX và apps.

Khi mua hàng sendo, gặp đâu cũng chê UX tệ các kiểu, lên mua mấy cha nội như tiki, lazada,… thấy nó còn tệ hơn, thôi về lại sendo mua ít hàng!

Câu chuyện OTP login,

Lần ấy tôi login bằng OTP trên app Sendo, nhập sdt xong ngồi chờ 10p không thấy đâu, gọi qua bên backend hỏi thì bển kêu hệ thống của người dùng nhà mạng MobiFone đang bị delay 10p, trong khi OTP hết hạn trong vòng 1p …,

Việc login là của mình, lại đi phụ thuộc thêm 1 kẻ khác …, dạo thêm 1 vòng thì thấy mấy thằng app khác cũng làm vậy (tiki, laz…), chắc mình già rồi không hiểu nổi.


Nhãn:

Nhận xét

Đăng nhận xét

Bài đăng phổ biến từ blog này

Hướng dẫn test negative (Test tiêu cực, test không hợp lệ, test ngược ...)

Hướng dẫn test negative Link tham khảo: Guru99.com Test tiêu cực - Dịch chuối quá - nên mình quyết định dùng từ gốc là: Negative testing. Bài hướng dẫn sẽ gồm các phần sau: Định nghĩa - Negative testing là gì. (What) Negative testing có quan trọng không? (Is) Làm như thế nào? (How) Ưu và nhược điểm! (Pros. & cons.) Định nghĩa negative testing! Để đảm bảo hệ thống chạy trơn tru và ổn định, chúng ta chỉ test những trường hợp bình thường và hợp lệ là chưa đủ. Vì vậy, để đảm bảo hệ thống chạy có thể xử lý được những trường hợp ngoại lệ ta cần test thêm những ngữ cảnh không hợp lệ! (negative testing). Làm được việc này thì hệ thống sẽ có kinh nghiệm xử lý khi các ngữ cảnh này xảy ra bất thường. ví dụ:  Thực tế đời sống: Xe buýt chở được 20 người. Ta cho 20 người cho xe chở bình thường. Nhưng chuyện gì sẽ xảy ra nếu nó chở 21 hoặc 30 người? Xe bị đổ, nghiêng, lún, lái khó ...=> Đây là negative case. Phần mềm: Email field có thể chứa đến 50 ký tự => Đ...
Đăng nhận xét
Đọc thêm

Ba lợi ích không ngờ tới của việc kết hợp test API trong quá trình code.

Bằng việc kết hợp TTD (Phát triển phần mềm theo hướng test) trong đó có API testing đưa đến ba hiệu quả rất thiết thực sau đây: 1. Chất lượng test. Nếu bạn chờ sau khi hoàn thành xong việc phát triển mới bắt tay vào test API thì những testcase của bạn sẽ có xu hướng trở thành happy case (những case thuận) và rất ít khi cho ra lỗi. Hiệu quả của việc này là phần mềm của bạn sẽ chạy rất khó khăn khi đưa ra môi trường thực tế. Ngược lại nếu bạn thực hiện API testing sớm thì những passive case sẽ chạy được và làm cho API trở nên mạnh mẽ và sáng tạo có khả năng hoạt động linh hoạt về lâu dài. 2. Test coverage (Độ bao phủ test). Thông thường API sẽ bao phủ toàn bộ các chức năng chính của phần mềm bạn, với xu hướng mobile web và đa nền hoạt động như hiện nay, độ che phủ chức năng của API ngày lại càng trở nên linh động và bao trùm. Do đó nếu làm tốt việc test API, thì bạn có thể khẳng định rằng phần mềm của bạn đã được bao phủ bởi nhiều testcase. 3. Test reuse (Sử dụng lại) Khi sử ...
Đăng nhận xét
Đọc thêm

Bảy nguyên tắc cơ bản của Kiểm thử phần mềm

Nội dung: nói và diễn giải về bảy nguyên tắc cơ bản trong testing software. Bài này là bài lý thuyết bổ sung và tester phải nắm được nằm lòng các nguyên tắc này! Bảy nguyên tắc (như khẩu huyết trong võ công): Kiểm thử tất cả mọi trường hợp là không thể được. ( EXHAUSTIVE testing is not possible ). Giải thích như sau: Một form có textbox cho phép nhập từ 1 -> 1.000.000.000.000. Nếu để kiểm thử nhập liệu cho textbox này ta phải kiểm thử 1k tỷ lần. Mỗi thao tác nhập cho là 1 giây, và phép toán kiểm tra nhập liệu là 0.1 giây nữa thì ta phải mất xấp xỉ 1k tỷ giây là khoảng 31k năm để thực thi nó. Đời người chỉ khoảng một trăm năm, vậy phải mất cả mấy nghìn đời để thực thi kiểm tra một textbox mà chưa kể đến nhiều đối tượng khác cho nên mới nói điều này là không thể làm được! (Chi phí nuôi nghìn người và giá trị bỏ ra là không xứng). Để xử lý thì ta: dùng kỹ thuật phân vùng tương đương, Phân nhánh nghiệp vụ, chia lớp xử lý... (Sẽ nói chi tiết sau). Kiểm thử là chỉ ra sai sót đang có ...
Đăng nhận xét
Đọc thêm