Làm gì khi không đủ thời gian thực hiện test

Khi dự án trải qua một phần của vòng đời kiểm thử , bạn thường nhận ra rằng bạn không có đủ thời gian để test? Tất cả mọi thứ đã nằm trong sự kiểm soát của bạn, để bắt đầu, nhưng ngay sau đó bạn nhìn thấy kế hoạch bất ngờ rằng "Phải làm gì khi không có đủ thời gian để test?" Chúng ta cùng nghĩ về vấn đề này về lâu dài và mức độ khó khăn của nó. Vậy làm thế nào mà một dự án khi bắt đầu thì rất tốt, nhưng nhanh chóng đi xuống rất tệ. Và, đây là những phân tích: Khi thời gian kiểm thử bắt đầu.

Câu hỏi đầu tiên sẽ được đặt ra là tại sao vấn đề này lại xảy ra? Có rất nhiều lý do và một trong số chúng là:

1) Estimate không đúng

Nếu bạn bắt đầu với một tính toán không chính xác thì những thứ này sẽ dẫn đến thất bại. Một estimate cho việc kiểm thử tốt phải bám sát được những vấn đề sau: Thời gian để chuẩn bị cho các tasks: Chúng ta đang nói về những task như:

• Xác định và đặt một bộ test case hồi qui cùng với nhau • Tạo dữ liệu kiểm thử • Thời gian để xác định mức độ sẵn sàng cho việc kiểm thử (Ví dụ .: Smoke / Sanity Test), vv

• Test case maintenance: Test case là tài sản của dự án mà sẽ được sử dụng lâu dài. Chúng cần phải được update trong quá trình test để phù hợp với từng dự án và yêu cầu của khách hàng. Điều này khuyến cáo rằng với các sản phẩm mới khoảng trên 30% thời gian kiểm thử của bạn nên được phân bổ cho các nhiệm vụ maintainance. Tất cả các team và các dự án có thể không cần 30%, nhưng phân bổ một số thời gian và công sức cho nhiệm vụ này.

• Ad-hoc/Exploratory tesing: Số lượng của kịch bản kiểm thử là một số lượng lớn. Tuy nhiên, không có bất cứ một nhóm kiểm thử nào trên thế giới này sẽ từ chối việc tham gia khám phá phần mềm ngay cả khi dự án đó đã được bao quát tất cả các kịch bản.

• Reporting/Communication (Báo cáo / Trao đổi thông tin) - Điều này bao gồm việc phân loại / đưa ra các ý kiến trong các cuộc họp, cập nhật các công cụ quản lý công việc của dự án vv..

• Contingency factor (Yếu tố bất ngờ): Do team khó có khả năng ước tính sát được với thực tế nên tiêu chuẩn sai lệch (buffer) khuyến nghị khoảng 25-30% so với ước tính ban đầu của dự án.

• Team and its capabilities: Nếu team bạn toàn là các member mới hoặc nếu như họ đang sử dụng một tool mới hoàn toàn, có thể bạn cần phải thiết lập một số thời gian dành cho việc đào tạo. Do đó những điều chỉnh estimate của bạn nên dựa vào team mà bạn đang làm việc.

2) Bản build không ổn định và các vấn đề kỹ thuật khác:

• Smoke / Sanity kiểm thử thất bại: Khi các kiểm thử cơ bản trên AUT thất bại. 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 cho việc test không có sẵn: Có những dự án khi đủ time có thể tạo test data trước khi thực hiện test. Tuy nhiên có nhiều dự án, QA sẽ phải vừa test vừa tạo dữ liệu. Điều này dẫn đến việc thiếu thời gian cho việc test • Các vấn đề môi trường - Việc bản build bị lỗi, server bị timeout, và rất nhiều các vấn đề khác có thể xảy ra. Điều này có lẽ xuất phát từ thực tế, một số công ty (không phải tất cả) không coi trọng việc dựng môi trường test gần giống với môi trường thật cho QA . Họ thường cố gắng dựng trên môi trường có bộ nhớ ít, RAM và CPU ít. Chính những tư tưởng này làm giảm chất lượng công việc cũng như mất nhiều thơi gian cho việc kiểm thử

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

Đây có thể là một vấn đề hiếm với các đội sau Agile hoặc SAFe do các sprint diễn ra trong thời gian ngắn, nhưng có nhiều team vẫn phải chịu đựng sự bất đồng hoặc hiểu lầm như khi Dev, Ops, và QA nghĩ rằng sẽ phải nhận bản build deliver từ một trong số họ. Do đó gây ra sự chậm trễ. Bây giờ chúng ta đã biết nguyên nhân gây ra những vấn đề này, Và sau đây là một số cách để khắc phục nó.

Vậy làm thế nào để Tester có thể có đủ thời gian để kiểm thử?

a) Ước lượng chính xác.

Khi nghi ngờ về việc vượt quá ước lượng , nhưng không đánh giá quá thấp. Đừng quên để thực hiện điều chỉnh dự toán dựa trên team, công cụ và quy trình của bạn. Khi thực hiện, tìm kiếm dấu hiệu chính thức để mọi người biết và vào lưu giữ trong phase tiếp theo.

b) Xem xét lại lịch sử của các dự án or phase trước đó –Các công cụ quản lý Test là người bạn tốt nhất của bạn.

• Thời gian kiểm thử trước đó kéo dài bao lâu? • Những loại vấn đề gây ra sự gián đoạn trong thời gian kiểm thử đó? • Có bao nhiêu Test case đc kiểm thử trước khi chúng pass? • Những bug nào đã được tìm thấy? • Những bug nào gây ra gián đoạn trong quá trình kiểm thử?

c) Đưa ra những câu hỏi và kế hoạch phù hợp trong thời gian khủng hoảng:

1. Chức năng nào là quan trọng nhất đối với mục đích dự định của dự án?
2. Chức năng nào là người dùng có thể thấy được?
3. Chức năng nào có ảnh hưởng đến sự an toàn lớn nhất?
4. 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?
5. Các mặt nào của ứng dụng là quan trọng nhật đối với khách hàng?
6. 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?
7. 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?
8. 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?
9. 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?
10. 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?
11. 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?
12. 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?
13. Các loại lỗi nào có thể là nguyên nhân đáng công khai nhất?
14. 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?
15. Các kiểm thử (test case) nào có thể dễ dàng bao phủ nhiều chức năng?
16. 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?

d) Sử dụng một công cụ quản lý kiểm thử.

Điều này sẽ làm giảm đáng kể số lượng công việc trong việc chuẩn bị, báo cáo và thời gian bảo trì và nỗ lực.

=> Dưới đây là danh sách các lựa chọn công cụ Test quản lý phổ biến nhất:

1. qTest
2. PractiTest
3. Zephyr
4. Test Collab
5. TestFLO for JIRA
6. XQual
7. TestCaseLab
8. QAComplete
9. QACoverage
10. JIRA
11. TestRail
12. TestLodge
13. HP ALM/Quality center
14. QMetry
15. Testuff
16. TestLink

e) Không có nhiều điều chúng ta có thể làm như build không đúng hay như các vấn đề kĩ thuật, nhưng một trong những điều mà có thể giúp chúng ta nhìn được đấy là kết quả Unit Test. Điều này sẽ giúp cho chúng ta có một ý tưởng về việc liệu bản build này có OK hay không và loại kiểm thử này có bị fail – vì vậy chúng ta sẽ ko sử dụng bản build này mà sẽ phải develop lại trước khi khi đưa sang giai đoạn kiểm thử tiếp theo.

Nếu Công cụ quản lý thử nghiệm của bạn hỗ trợ tích hợp CI, bạn có thông tin có sẵn mà không gây ra bất cứ một ồn ào nào vì vậy bạn hiểu sự ổn định của các ứng dụng tốt hơn.

f) Đo lường năng suất và tiến bộ thường xuyên của các member.

Đừng để báo cáo tình trạng sẽ có bước tiến chỉ vì lợi ích của các team bên ngoài. 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 của bạn và khả năng của bạn để thực hiện chúng.

Ngoài ra, hãy chắc chắn để không nhận được các câu hỏi hóc búa cổ điển về “Tốc độ và Chất lượng”. Bởi vì, khi bạn báo cáo, nói rằng, 50 lỗi một ngày, nó có thể xuất hiện nếu như bạn đang là một người cực kì suất sắc. Nhưng nếu hầu hết các member khác không như bạn mong đợi thì bạn đang gặp vấn đề .

Vì vậy cần theo dõi và giám sát nhiều hơn.

Kết luận:

Khi không có đủ thời gian để thực hiện kiểm thử toàn bộ phần mềm, chúng ta sẽ chỉ kiểm thử một số phần nào đó được cho là chức năng chính của phần mềm đang được xây dựng và những phần có độ ưu tiên cao dễ gây ra bug cho phần mềm bằng việc sử dụng phân tích rủi ro, song song với việc thảo luận của các bên liên quan tới dự án, để xác định chỗ nào cần phải được tập trung test.

Nguồn dịch: http://www.softwaretestinghelp.com/what-if-there-isnt-enough-time-for-thorough-testing/#more-31