Skip to main content

Testing like a boss

Manual mobile app testing là một công việc không hề dễ dàng, nó đòi hỏi QA/Tester phải giành nhiều thời gian và công sức để có thể verify/qualify được hết tất cả các test case. Đặc biệt khi những yêu cầu như pixel perfect hay khi dữ liệu được combine từ nhiều nguồn khác nhau (API/Cache/Local Database/Sharepreferences), thì thời gian mà QA/Tester bỏ ra để có thể đánh giá được chính xác "development progress" là ko hề nhỏ. Tôi có thể kể ra một số câu hỏi thường gặp khi manual testing mobile app 
1. Liệu 2 màu ()() (implementation/specs) có thực sự giống nhau? Hãy chỉ ra mã màu của chúng?
2. Textsize là bao nhiêu? Typeface là gì? TextColor, HintColor giá trị như thế nào? Làm sao để trả lời đã tuân theo design specs hay chưa?
3. Khoảng cách giữa 2 view là bao nhiêu pixel? Có đúng specs ko?
4. Làm sao có thể biết được trong một màn hình, dữ liệu lấy từ đâu? (API/Cache/Local Database/Sharepreferences)
5. Làm sao có thể xoá local storage khi cần thiết?
6. Kiểm tra giá trị sharepreference thế nào?
7. Kiểm tra local database thế nào?
8. Kiểm tra request/respone của API bằng cách nào?
9. Làm sao để tiện record video screen làm bằng chứng khi có bug...
Có rất nhiều câu hỏi dạng này, đây là những challenges thực sự đối với QA/Tester khi tiến hành manual testing, mà thời gian bỏ ra để trả lời và ứng dụng vào việc testing là rất lớn. Bài toán đặt ra là làm thế nào để tăng productivity của QA/QC team khi manual testing. 

Hyperion là một tool (both Android/iOS) với đầy đủ các module được tích hợp sẵn, và một giao diện thân thiện với người dùng mà bất cứ ai (QA/Tester/Developer/PM) cũng có thể sử dụng được ngay để tăng productivity của manual testing.


Một số plugign được tích hợp sẵn

Third Party Plugins

Core Plugins



Đây là giao diện của Hperion




Là một tool bên mình đang phát triển nhằm tăng productivity của  QA/Tester trong việc so sánh việc implementation và specs. Tool này dựa trên screen capture của screen thực tế và design để so sánh. Hãy sử dụng nếu nó có thể giúp được bạn và tạo issue để giúp cho tool được hữu ích hơn. 

Comments

Popular posts from this blog

Auto Code Review (Danger)

Code review là một quy trình bắt buộc trong qui trình phát triển phần mềm chuyên nghiệp. Mục tiêu quan trọng nhất của code review là nâng cao code quality của dự án. Tuy nhiên đối với những team làm outsource hoặc khi tính chất của dự án “quick win” với deadline oriented. Thông thường cách tiếp cận của team trong code review chỉ là apply một số rule về coding convention và coding style để cho dự án chạy. Lý do thường thấy nhất đó là reviewer thường phàn nàn không có đủ thời gian để làm review một cách chuẩn chỉnh và qui củ, hơn nữa việc bỏ sót lỗi trong quá trình review là khó tránh khỏi (human mistake). Hoàn toàn hợp lý tuy nhiên chúng ta có thể có một cách tiếp cận tốt hơn bằng cách delegate việc review code style, code convention, và kết quả static analysis tool cho code review bot (Danger). Bằng cách này chúng ta giải quyết được 3 vấn đề chính: Reviewer chỉ cần focus vào review business logic, cái này giá trị hơn rất nhiều so với code style và code convention cũng như s...

Idiomatic Git commit message

Source control is a developer’s best friend. The ability to share code with multiple developers, track changes, and easily roll back when problems arise is indispensable in this distributed world. Reviewing others’ commits and pull requests becomes something worth doing, and suddenly can be done independently. Understanding why something happened months or years ago becomes not only possible but efficient. A project’s long-term success rests (among other things) on its maintainability, and a maintainer has few tools more powerful than his project’s log. It’s worth taking the time to learn how to care for one properly. What may be a hassle at first soon becomes habit, and eventually a source of pride and productivity for all involved. The seven rules of a great Git commit message 1. Separate subject from body with a blank line 2. Limit the subject line to 50 characters 3. Capitalize the subject line 4. Do not end the subject line with a period 5 .Use the imperative mood in ...