Có nên cập nhật test case mỗi khi thay đổi yêu cầu?

Tất cả các câu hỏi liên quan đến test case
Post Reply
tvn
Admin
Posts: 4792
Joined: Tue 10 Aug, 2010 10:11 am
Location: HCM
Contact:

Có nên cập nhật test case mỗi khi thay đổi yêu cầu?

Post by tvn » Thu 09 Aug, 2018 3:05 pm

Chào cả nhà,

Mọi người ơi, cho em tham khảo vấn đề này xíu.

Khi thay đổi yêu cầu (features/enhancement) thì QA thường phải cập nhật lại test cases phải không ah? Giả sử như hiện tại mình có là 500 test cases. Khi có thay đổi yêu cầu, gây ảnh hưởng đến tầm 1/3 số test case đó. Và, giờ QA phải ngồi update lại số test case bị ảnh hưởng này.

Và, giả sử như, việc thay đổi yêu cầu này xảy ra thường xuyên, nhiều lần thì số lần QA phải update TCs cũng tăng lên nhiều. Dẫn đến việc tốn rất nhiều thời gian cập nhật test case như vậy.

Trong tình huống này, mọi người có thể chia sẻ cách quản lý và cập nhật test case như thế nào cho hiệu quả với ạ.

Cám ơn.
(Thy Nguyễn)



tvn
Admin
Posts: 4792
Joined: Tue 10 Aug, 2010 10:11 am
Location: HCM
Contact:

Re: Có nên cập nhật test case mỗi khi thay đổi yêu cầu?

Post by tvn » Thu 09 Aug, 2018 8:36 pm

Sau đây là tổng hợp trả lời, gợi ý của một số bạn tren group chat TVN (Skype)
(tvn có cập nhật sửa đổi một số câu chữ cho nó có ngữ cảnh => dễ hiểu hơn.)

Tester A mách nước
Đây là bài toán muôn thuở của QC, tester nói chung. Nếu bạn đang làm việc theo dạng testing service thì chắc chắn là bạn phải cập nhật test case mỗi khi có thay đổi yêu cầu, tốn thời gian dù nhiều hay ít cũng không quan tâm.

Tester B
Nhưng làm project base có deadline rõ ràng thì nên thỏa thuận với bên bộ phận quảnly1 một cách rõ ràng. Hoặc làm một cái estimate draft (ước lượng sơ bộ) gửi cho khách hàng/quản lý để họ thấy tốn thời gian bao nhiêu cho việc cập nhật test case này.

Nhớ áp dụng buffer sơ sơ thế này:
+ update test case do chính mình viết thì cứ estimate bình thường
+ update test case do người khác viết hoặc estimate dùm người khác thì lấy số estimate ra tăng thêm 20% - 30% tuỳ mức độ complex của dự án

Còn làm sao cho hiệu quả thì bạn phải cho mọi người thêm thông tin :) Chứ riêng Steven thì 10 dự án là 10 cách khác nhau rồi =)) Cách sau là rút kinh nghiệm của cách trước hoặc bổ sung sửa đổi cho phù hợp nhất đối với từng cách tiếp cận. Chứ không có template (mẫu) hay tool (công cụ) nào mà mình bố trí test case structure 1 kiểu cho cả 10 dự án

Tester B
Theo ý kiến cá nhân mình.
Tester build 1 bộ testcase cũng như dev build các function cho app, khi thay đổi requirement thì dev phải update code và tester phải update test case là điểu hiển nhiên rồi.

Vấn đề ở chỗ là mình design test case cho các function sao cho nó dễ maintenance và đễ tốn effort khi requirement thay đôi. Cũng như dev phải code theo design pattern để dễ reuse, maintenance khi fix bug và change requirement.

Tester B
> Giả sử như TCs hiện có là 500 tcs, thay đổi mới gây ảnh hưởng tầm 1/3 số tcs đó. và QA phải ngồi update lại.

Thay đổi feature mà ảnh hưởng đến nhiều test case vậy thì mình cũng xem lại xem cách tổ chức và viết test case xem đã tối ưu chưa.

Tester B
Tester build 1 bộ testcase cũng như dev build các function cho app, khi thay đổi requirement thì dev phải update code và tester phải update test case là điểu hiển nhiên rồi.

Vấn đề ở chỗ là mình design test case cho các function sao cho nó dễ maintenance và đễ tốn effort khi requirement thay đôi. Cũng như dev phải code theo design pattern để dễ reuse, maintenance khi fix bug và change requirement.

Tác giả
Cảm ơn a steven chia sẽ nhé. nhưng e k phải hỏi về vấn đề estimation ah. ý e muốn hỏi làm sao để ít tốn thời gian cho việc update trên TCs cũ ah.

Hiện tại structure TCs hiện tại của e là:
  • 1.Test plan
  • 1.1 Module 1
  • 1.2 Module 2
  • 1.2.1
  • 1.2.2
  • 1.3 Module 3
Nếu có một thay đổi và làm cho các test case trong cái test plan đó bị sai, thì hiện tại mình phải ngồi dò lại mức ảnh hưởng của nó để xác định thêm hay sửa các tester case cũ.
Mình đang nghĩ tới trường hợp làm sao để giảm thiểu thời gian tìm kiếm các test case cũ bị ảnh hưởng (do thay đổi yêu cầu) để update thì mình sẽ tạo một folder changes

Changes 08072018 (10 test cases cho phần thay đổi mới này, viết mới mà không cần thay đổi 300 test cases cũ có liên quan)

Changes 02012018: thì sẽ test cho những cái changes trước và nếu khi test xuống những test case cũ và thấy ko còn đúng nữa thì lúc đó mình sẽ bit được nó đã được cập nhật/thay đổi

Mọi người thấy cách này thế nào ah?

Tác giả vặn lại
Tại sao a lại đưa vấn đề estimate lên trước vì nếu ko estimate mà workload của QC tăng lên tới mức phải OT without request để complete thì ko ổn. phải balance đc trước. Theo structure của em thì anh thấy giống giống Test Link đúng ko. Anh nghĩ cách của em là 1 trong các best choice. Thay gì update thì Test Plan cũ giữ nguyên. Viết mới bộ 1 test plan new feature mới.

Em có bộ Sanity Test chưa ? nếu chưa thì nên làm 1 bộ luôn. khi có build thì chạy Sanity done >> bộ new done >> full regression >> trong time dev fix bug thì remove + update bộ cũ.

Nhưng sẽ có 1 bài toán mới cho cách quản lý này là mình có quá nhiều test plan. Cách này thật ra team anh cũng từng dùng, nhưng chủ yếu dùng cho big feature

Tác giả
Vâng, hiện tại mình không tạo bộ sanity test/ smoke test. vì trước đây e có tạo tách ra những tốn time cho việc kéo các tcs vào bộ này.

Hiện tại mình dùng cách là set Priority cho TCs, những case nào P1 là important TCs. Thì e chỉ cần querry những tcs cho các feature đó vào và run thôi.

Comments
Vậy good rồi. Anh thì tách ra luôn 3 test plans cho dễ quản lý.
  • 1. full;
  • 2. sanity;
  • 3. smoke
Tác giả hỏi
> Thay đổi feature mà ảnh hưởng đến nhiều test case vậy thì mình cũng xem lại xem các tổ chức và viết test case xem đã tối ưu chưa

vậy anh đã gặp trường hợp thay đổi features mà bộ test cases của a bị thay đổi nhiều chưa? Cách để a giảm tải việc update là gì?

Tester A
Thường thì 1 bộ test case nó link giữa các test case khá nhiều.
Làm thế nào để Cắt nhỏ ra và giảm sự liên hệ gữa các test case càng nhiều. Thì khi update càng đỡ cực thôi. Hiện tại cách anh làm là theo screen và object. Mỗi 1 test case chỉ care 1 object và mỗi 1 test suit chỉ care 1 screen. Khi có liên hệ giữa 2 screen thì complete của screen 1 là screen 2 hiện ra như vậy là Pass ở screen 1. Còn vấn đề data hiện sai đúng thế nào thì giao cho screen 2, ví dụ vậy.

Với structure này thì phải hướng dẫn sơ các bạn test execute 1 xíu :D
Lượng test case tăng lên so với cách hướng function 1 xíu :) Là nhược điểm của cách này

Tester B
Anh cũng nghĩ giống Steven, trong coding có nguyên tắc là thứ nhất 1 phương thứcv(method/function) chỉ làm 1 việc, và càng đơn giản càng tốt (simplest), thứ 2 đoạn code nào dùng lại thì luôn tách thành 1 phương thức (method/function) riêng để reuse (tái sử dụng). Mình có thể áp dụng nguyên tắc này cho viết các test cases

Cảm ơn mọi người đã chia sẻ nhé. Mình sẽ tham khảo và áp dụng cho dự án của mình.



Post Reply

Return to “Test cases - Tập hợp các trường hợp kiểm thử”