Đôi khi developer và tester cãi nhau về lỗi của ứng dụng, và có rất nhiều nguyên do cho chuyện đó: hiểu lầm giữa hai bên, lỗi đó không phải do code, tester báo lỗi sai, v.v… Việc này gây mất đoàn kết trong nội bộ và ảnh hưởng đến công việc chung của cả nhóm. Vậy làm thế nào để giải quyết rắc rối này đây?
Trước hết, chúng ta cùng xem lại định nghĩa về công việc của cả hai:
- Developer là những người xây dựng và phát triển ứng dụng.
- Tester là người kiểm tra và tìm kiếm lỗi trong ứng dụng.
Có thể chia tester làm 4 cấp bậc:
- Developer viết đoạn code đó
- Một developer khác
- Tester chuyên kiểm tra và tìm loại
- Một công ty chuyên về test
Và cũng có 4 cấp độ của test:
- Unit testing: Còn có tên gọi khác là component test, module test. Mục đích chính là tìm kiếm lỗi trong thiết kế của phần mềm, mô hình dữ liệu, xác định các chức năng, cũng như hiệu quả hoạt động của các thành phần. Unit testing thường được thực hiện bởi các developer, có thể là người viết ra nó hoặc là một developer khác trong nhóm. Việc áp dụng unit testing vào ngay những giai đoạn đầu sẽ giúp chúng ta dễ dàng kiểm soát cũng như tìm ra lỗi của phần mềm, giảm khả năng phát sinh lỗi và giảm chi phí quá trình xây dựng sản phẩm.
- Integration testing: Tập trung vào test sự tương tác của các thành phần. Cách tốt nhất để thực hiện integration testing chính là chúng ta sẽ “tích hợp” những phần mà chúng ta cho rằng khi kết hợp với nhau nó sẽ gây ra lỗi. Mức độ test này thường được thực hiện bởi một nhóm chuyên về integration test hoặc là nhóm tester.
- System testing: Đảm bảo sản phẩm sẽ đáp ứng được yêu cầu của khách hàng khi chạy thử. Bên cạnh đó là tìm được càng nhiều lỗi trong mức có thể càng tốt. Chúng ta sẽ đưa ró ra môi trường giống như thực tế (như môi trường khi lên production) để chắc chắn xem phần mềm có chạy ổn định, đúng đặc tả hay chưa, có đáp ứng yêu cầu kinh doanh hay không. Và người chịu trách nhiệm về system testing là những đội test chuyên biệt hay đội test độc lập – những tester có hiểu biết về tất cả các lĩnh vực từ kinh doanh đến kỹ thuật hay thiết kế.
- Acceptance testing: Sau khi phần mềm đã được sửa hết những lỗi được phát hiện. Chúng ta chuyển sản phẩm cho khách hàng. Người sử dụng và khách hàng là người chịu trách nhiệm cho acceptance testing. Họ đảm bảo phần mềm hoạt động đúng theo những yêu cầu mà họ đã đề ra. Có những công việc liên quan đến mức độ test này như là khả năng backup/restore, bảo mật…
Tester thường cảm thấy phấn khích khi tìm được những lỗi nghiêm trọng, đặc biệt là những lỗi dẫn đến ứng dụng bị tắt đột ngột (crash). Nhưng developer thường biện hộ rằng lỗi này không phải do họ gây ra. Vậy làm thế nào để developer và tester hiểu nhau hơn?
Theo kinh nghiệm làm QA của Xuân Thu:
Việc đầu tiên, bạn phải kiểm tra cẩn thận lại lỗi bạn vừa tìm được. Đảm bảo bạn có thể tạo ra lỗi đó một lần nữa, ghi lại các bước thực hiện để phát sinh lỗi và chụp lại màn hình.Việc tiếp theo, bạn báo cáo lỗi này cho nhóm của mình, đặc biệt là developer. Công đoạn này rất quan trọng, tìm lỗi dễ hơn là báo lỗi. Bạn có thể liệt kê được nhiều lỗi, nhưng để developer có thể sửa được chúng còn phụ thuộc vào loại lỗi bạn tìm thấy và cách bạn giao tiếp với họ.
Bạn phải có kinh nghiệm trong việc testing để biết được lỗi nào là đúng – lỗi đúng là lỗi mà mọi người đều công nhận chứ không phải dựa trên suy nghĩ của bạn. Ví dụ: bạn nghĩ một ứng dụng đọc sách nên có chế độ đọc cho màn hình nằm ngang, đây không phải là lỗi mà là cách sử dụng của bạn, trên thực tế hầu hết người dùng đều đọc sách ở chế độ màn hình dọc.
Giao tiếp cũng là một việc rất quan trọng. Mục đích cuối cùng của developer và tester là tạo ra một sản phẩm tốt cho người sử dụng. Vì vậy, khi nói chuyện với developer, bạn phải truyền đạt được thông điệp đó. Mục đích của việc tìm lỗi là đưa ra các vấn đề cần được giải quyết cho developer chứ không phải là chỉ trích hay phàn nàn về chúng.
Khi báo lỗi, bạn nên dùng những câu như “mình nên thay đổi cái này” thay vì “anh/chị phải thay đổi cái này”, “cái này chưa được ổn lắm” thay vì “cái này làm sai rồi”… Bạn cũng có thể sử dụng một vài công cụ để quản lý và báo lỗi như Trello, Scrumwise… Ví dụ, khi sử dụng Trello: Card của bạn nên có tiêu đề ngắn gọn và thể hiện được nội dung chính của lỗi; bạn nên mô tả đầy đủ về lỗi này và các bước cần thực hiện để tạo ra nó, đính kèm thêm ảnh chụp hoặc ảnh động gif, làm thế sẽ khiến lỗi rõ ràng hơn; thêm các thành viên khác vào card bên cạnh bạn như developer, project manager…
Nếu bạn thực hiện được những điều này, mình nghĩ developer sẽ vui vẻ khi nhận các thông báo lỗi từ bạn. ^_^
Theo: Xuân Thu - siliconstraits.vn
No comments:
Post a Comment