Làm gì khi không đủ thời gian để test

Bạn đã bao giờ rơi vào trường hợp không đủ thời gian để test sản phẩm ? Nếu bạn đã từng trải qua thì không khó nhận ra rằng nó không hề thú vị tí nào.

Đầu tiên, bạn cần biết vấn đề nằm ở đâu, tại sao lại không đủ thời gian để test? Có rất nhiều lý do:

1. Estimate không chính xác

Nếu bạn khởi đầu việc test khi mọi sự dự đoán của bạn không thực sự chính xác, mọi thứ sẽ dễ dàng fail hơn cả. Một tester tốt estimate dựa trên các yếu tố sau:

• Thời gian để chuẩn bị cho task: Chúng ta đang nói về task trong ngữ cảnh:

• Xác định và xây dựng bộ test case.
• Tạo dữ liệu test
• Thời gian để xác định loại test (VD: smoke/ sanity test...)

• Test case maintenance: Test case được sử dụng lâu dài. Chúng cần phải được update trong suốt quá trình test. Tôi khuyên bạn nên phân bổ 30% thời gian thực hiện test cho việc update test case.

• Adhoc/ Exploration testing - Số lượng test case của một dự án luôn là một con số khổng lồ. Tuy nhiên, không có bất cứ tester nào trên thế giới không thực hiện test khám phá ngay cả khi bộ testcase của bạn đã gần như đã đầy đủ.

• Báo cáo/ Giao tiếp: Chúng ta sẽ phải tham gia vào nhiều cuộc họp của dự án và luôn luôn phải cập nhật các công cụ quản lý công việc của dự án.

• Yếu tố dự phòng: Bạn nên tăng thêm 25-30% cho ước tính thời gian ban đầu của bạn. Điều đó là khó tránh khỏi khi dự án sẽ có những thay đổi mà bạn cần thêm thời gian để cập nhật. Hơn hết, bạn cũng nên có chút thời gian dự phòng để thở, thay vì ước tính quá sát.

• Team và khả năng của bản thân: Nếu team bạn đều là những người mới lần đầu làm việc cùng nhau hoặc bạn phải sử dụng một công cụ mới toanh, bạn có lẽ cần thời gian làm quen với sự mới mẻ này. Như vậy, việc điều chỉnh thời gian estimate là rất cần thiết.

2. Các vấn đề về buid không chắc chắn và các vấn đề về kỹ thuật khác

• Smoke/ Sanity test thất bại: Khi hệ thống bị fail ngay sau khi deploy trên môi trường của QA bị fail thì toàn bộ task test cho các phần đó sẽ bị block lại. Khi đó QA sẽ phải làm task khác nhưng sẽ không đúng như dự định ban đầu. Điều này sẽ lãng phí một lượng thời gian lớn.

• Dữ liệu test không có sẵn: Chúng ta thường tạo sẵn dữ liệu test trước. Tuy nhiên có nhiều trường hợp, ta phải vừa test vừa tạo dữ liệu. Điều này cũng rất tốn thời gian.

• Các vấn đề về môi trường: Việc build bị fail, sercer bị time out và rất nhiều vấn đề khác vẫn luôn rình rập dự án. Điều này xuất phát từ thực tế, nhiều công ty (không phải là tất cả) không coi trọng môi trường test cho QA làm việc hiệu quả. Họ thường cố gắng dựng trên môi trường có bộ nhớ ít, RAM và CPU ít.

3. Thiếu sự thỏa thuận giữa các bên liên quan

Đây là vấn đề thường gặp với team Agile khi dev và QA có nhiều bất đồng.

=> Khi chúng ta đã phát hiện ra vấn đề, chúng ta cùng bắt tay nghĩ ra cách để khắc phục nó.

• Ước lượng chính xác: Khi có sự nghi ngờ, đắn đo, bạn nên ước lượng nhiều hơn một chút, đừng đánh giá thấp quá. Đừng quên estimate dựa trên cả team, tool và qui trình của team bạn.
• Xem xét lại các dự án trước đó để rút kinh nghiệm

• Các loại vấn đề gây ra sự gián đoạn của test cycle trước đó.
• Cần phải kiểm tra bao nhiêu lần thì một case passed.
• Những lỗi nào thì cần phải báo cáo
• Những lỗi nào gây ra gián đoạn việc test

• Hãy trả lời những câu hỏi sau và lên kế hoạch dựa trên chúng trong khoảng thời gian khủng hoảng nhất:

• Chức năng nào là quan trọng nhất đối với mục đích dự định của dự án?
• Chức năng nào là người dùng có thể thấy được?
• Chức năng nào có ảnh hưởng đến sự an toàn lớn nhất?
• Chức năng nào có ảnh hưởng đến tài chính lớn nhất đối với người dùng?
• Các mặt nào của ứng dụng là quan trọng nhật đối với khách hàng?
• Các mặt nào của ứng dụng trong chu trình phát triển phần mềm có thể test sớm được?
• Các phần nào của code phức tạp nhất mà dễ dẫn đến vấn đề xảy ra lỗi?
• Các phần nào của ứng dụng đã được phát triển trong trạng thái gấp gáp hoặc lo lắng?
• Các phần nào của các dự án tương tự/ có liên quan đến các dự án trước đã gây ra lỗi?
• Các phần nào của các dự án tương tự/ có liên quan đến các dự án trước có chi phí cho việc bảo trì lớn nhất?
• Các phần nào của SPEC (tài liệu thiết kế chi tiết) và thiết kế được nghĩ là không được rõ ràng và sơ sài nhất?
• Các DEV nghĩ cái gì là khía cạnh (mặt) rủi ro cao nhất của ứng dụng?
• Các loại lỗi nào có thể là nguyên nhân đáng công khai nhất?
• Các loại lỗi nào có thể là nguyên nhân gây ra việc khiếu nại dịch vụ khách hàng nhất?
• Các kiểm thử (test case) nào có thể dễ dàng bao phủ nhiều chức năng?
• Các kiểm thử nào sẽ có nguy cơ chiếm tỷ lệ thời gian yêu cầu cao nhất?

• Sử dụng các công cụ quản lý test. Đây là một cách giảm đáng kể lượng thời gian thời gian cũng như công sức chuẩn bị, báo cáo và bảo trì.

• Vấn đề xảy ra về build/ kỹ thuật thì khó cải thiện hơn nhưng ta vẫn có thể sử dụng unit test để làm chúng tốt hơn. Nếu công cụ quản lý test của bạn hỗ trợ tích hợp CI, bạn nên tìm hiểu một chút thông tin không quá phức tạp để hiểu nhiều hơn về sự ổn định của ứng dụng.

• Xem xét nâng suất làm việc thường xuyên. Hãy chắc chắn rằng bạn đang giám sát chặt chẽ các mục tiêu hàng ngày và khả năng bạn hoàn thành chúng.

Khi rơi vào tình trạng không đủ thời gian test quả thực stress rất nhiều. Vì vậy ngoài sự cố gắng của bạn thân để khắc phục bạn có thể nhờ sự trợ giúp từ mọi người trong đội kiểm thử của công ty. Vì một sản phẩm ít lỗi nhất có thể, chúng ta cùng cố gắng.

Bài viết được dịch từ link sau: http://www.softwaretestinghelp.com/what-if-there-isnt-enough-time-for-thorough-testing/