Chiến lược kiểm thử khi gặp quá nhiều test cases.

[tvn]

Một bạn hỏi trên group Skype TVN:

Mọi người ơi cho mình hỏi tình huống này với ạ:
Team Lead giao cho tester 1000 TCs (sau khi đã đã lựa chọn, lọc kỹ từ danh sách 2000 test Cases)

Một tester Nguyễn Văn A chỉ test có 700 TCs hà, còn 300 TCs bạn đó đánh kết quả pass/fail dựa theo cảm nhận của họ.
Mình hỏi bạn ấy vậy thì sao mà đáng tin cậy được. Bạn ấy nói đó là cách test khoa học, dựa trên kinh nghiệm từ các sprints, để mà tự nhận định được test case đó pass hay fail và biết được có cần phải test nó hay không. Và bạn ấy nói thêm là là áp dụng Exploratory Testing. Bạn còn nói là "Tester là phải test một cách khoa học, chứ đừng test như một con trâu."

Mà mình vẫn cảm thấy sao sao ấy. Cho mình hỏi bạn ấy nói vậy có đúng không? Trong thực tế mọi người sẽ áp dụng như vậy hay khác?

Mình cảm thấy test kiểu này, nó rất chủ quan. Nếu sau này có chuyện gì xảy ra, mình nhận lỗi với khách hàng cũng không lấy lại được uy tín và sự tin tưởng của họ được nữa.

[tvn]

Cảm ơn nhiều bạn đã góp ý về câu hỏi và quan ngại này. Nhưng mình thấy nhiều câu trả lời chưa có "đầu tư" kỹ. Mọi người nên đầu tư thêm xíu để câu trả lời chất lượng hơn nhé.

Theo quan điểm của mình về vấn đề này như sau:
Bạn Nguyễn Văn A kia đã làm sai và không trung thực. Hành động này còn có thể gây nguy hiểm cho nhóm phát triển phần mềm, đó là mất uy tín với khách hàng. Đúng như lo ngại của bạn Author, người đưa ra câu hỏi. Hành động sai của bạn Tester A là chỉ test 700 test cases, mà dám điền kết quả passed/failed cho 300 test case còn lại.

Không có cơ sở nào hay kinh nghiệm nào để biết được 300 test case đó pass hay fail trong khi KHÔNG thực thi chúng. Ngay cả khi, tuần trước, hoặc hôm qua hay sáng nay nó đã pass, giờ có bản build mới vừa được deploy lên server. Và Test Lead đề nghị phải test lại hết 1000 test cases. Thì chỉ có duy nhất một cách là phải test hết 1000 cases này thì mới dám / có thể ghi kết quả passed hay failed.

Trong trường hợp này, test case nào không/chưa được test thì cứ ghi kết quả là Not Test. Chứ không test mà ghi passed hoặc failed đều không hợp lý. Túm cái váy, không test thì cứ ghi là không test, và ghi lý do tại sao. Ví dụ: tôi thấy lần sửa đổi này không ảnh hưởng đến khu vực này nên tôi thấy không cần thiết phải test.

Nói về trường hợp "work smart not work hard" thì mình hoàn toàn đồng ý với quan điểm "đừng test như một con trâu" hay "exhaustive testing là test cho đến kiệt sức thì thôi (nói vui)." Mình là một tester thuộc dạng khá lười, luôn tìm cách làm nhanh gọn lẹ, và không thích trườm rà. Lúc còn làm ở công ty outsourcing, mình đã từng viết 500 test case cho 1 màn hình. Và tài liệu yêu cầu cứ thay đổi liên tục. Nên từ lúc đọc tài liệu, viết test case, update test case, mình muốn thuộc lòng bộ test case luôn rồi . Vì vậy, đến lú dev code xong, mình chạy test. Thì mình không đọc từng test case để mà chạy theo các bước của nó. Mình đọc qua 1 lượt một số test case có liên quan đến một Button (nút) chức năng nào đó rồi mình chạy ứng dụng (web) để test nó. Test nhiều case, test theo suy nghĩ của mình, test tá lả. Rồi sau đó mình đọc file test case (excel) để điền kết quả. Những case nào không chắc, không nhớ rõ là đã được test hay chưa, thì mình test lại case đó rồi điền kết quả test cho nó. Cách này thì tiết kiểm thời gian cho việc đọc từng test case. Và một điểm hay nữa là trong lúc mình test như vậy, có nhiều case bị bug nhưng không có test case nào mô tả trường hợp đó. Nên mình phải viết thêm 1 test case cho nó, và dĩ nhiên, post 1 con bug cho lỗi đó. Nhắc lại, với cách làm này của mình, những test case nào mình không tets được, ví dụ vì test case khác failed nên không test được test case này. Mình ghi là pending và ghi lý do tại sao không test được.

Mãi về sau này, mình mới biết cách test lung tung đó là exploratory testing. Sau này, mới nhận ra: thật ra mình đã làm Ad hoc testing chứ không phải exploratory testing.

[StevenPhuong]

Về mặt nguyên tắc các test case đã được liệt kê ra là cần phải test.
Nên có 3 cases xảy ra trong topic này:
1 đủ time: quất láng, giết ráo.
Không đủ time: chọn ra bộ test case theo risk, theo main feature, theo new feature, theo request của release note.
Quá ít time: Explorary test.

Còn việc không chạy mà wánh test result thì không ủng hộ tí nào.

[hieuln1991]

Từ "chuyên ngành" gọi hành động này là "Bùa" =))

Trước hết mình muốn kể về 1 trường hợp mình đã từng kinh qua.

Cách đây 1 năm, trong dự án của mình cũng có 1 bạn tester test theo kiểu khoa học của bạn test A trong topic.
Hai ngày sau khi release, KH gửi một số bug về. Trong đó có một bug thuộc loại siêu dễ phát hiện (obviously bugs).
KH yêu cầu giải thích tại sao lại còn bug "dễ" như vậy sau release (Beta release).

Sau khi phân tích, team thấy bug đó đúng ra đã được cover trong test case trong đợt releae đó. Check lại thì test case đó được đánh passed.
Team setup lại môi trường test và executed lại thì thấy case đó bị fail.
Lúc này trace ra mới biết bạn tester đó đã không execute TC mà làm theo kiểu "khoa học" (được đề cập ở trên) do áp lực thời gian.
Sau đợt đó KH doạ "cái gì không xài được thì bỏ".

Quay lại với bạn A. Theo cá nhân mình thấy thì test phải khoa học là đúng rồi nhưng không phải khoa học theo kiểu của bạn Tester A trong trường hợp ở trên.

Mình phân tích thế này nhé:
1. Team Lead giao cho tester 1000 TCs (sau khi đã đã lựa chọn, lọc kỹ từ danh sách 2000 test Cases) => số test case này được đánh giá là quan trọng nên mới cần phải test. Nên việc tự ý không chạy test case đã là một sai lầm. Chưa kể bạn "bùa" kết quả test - lừa dối KH và team.

2. "Tester là phải test một cách khoa học, chứ đừng test như một con trâu." Đúng là tester phải thông minh và làm việc khoa học.
Khi test lead đưa task xuống cho bạn. Lead đó hẳn đã phải estimate thời gian cho bạn thực hiện test (chạy) 1000 TCs như một con người chứ không phải như một con trâu

Nếu bạn bị bắt test như một con trâu ^.^ thì bạn hoàn toàn có quyền la lên để tìm cách giải quyết khác hay hơn việc tự chọn 300 TCs không execute.
Ví dụ: bạn có thể đưa ra option cho team lead: 1K TCs bắt bạn test trong thời gian X là không hợp lý. Bạn cần thêm thời gian hoặc lọc bớt TCs hoặc cần thêm người support, vv.. Túm lại bạn có nhiều cách khoa học hơn để giải quyết chuyện này.

3. "Bạn ấy nói thêm là là áp dụng Exploratory Testing." Nó giúp bạn có thể tiên đoán vùng nào có thể có bug hoặc không. Dựa vào đó có thể tiết kiệm thời gian, bắt được những bug quan trọng trong thời gian nhanh chóng. Bạn A không thể dựa vào kiết quả "tiên đoán" và biến nó thành kết quả thực tế được.

Chốt lại thì lỗi này mình thấy nhiều ở những bạn fresher tester (hoặc các bạn chưa có nhiều kinh nghiệm xương máu) hơn là những người có KN. Và thường xảy ra khi các bạn gặp áp lực về thời gian hoặc những bạn luôn luôn 'say YES' với Team Lead.

Nếu rơi vào trường hợp bạn cảm thấy phải làm "như trâu" thì hãy la lên với Leader của bạn và cùng tìm hướng giải quyết thay vì tự ý quyết định theo kiểu "khoa học" đề cập ở trên. Là member hãy cân nhắc và đánh giá task (ước lượng kiểm thử) trước khi say YES để khỏi bị hố.
Là team lead hãy cố gắng estimate đúng cho members, và quan trọng là lâu lâu cũng nên tự tạo ra những "phốt" trong TCs để "test" độ trung thực của members

[tvn]

Về mặt nguyên tắc các test case đã được liệt kê ra là cần phải test.
Nên có 3 cases xảy ra trong topic này:
1 đủ time: quất láng, giết ráo.
Không đủ time: chọn ra bộ test case theo risk, theo main feature, theo new feature, theo request của release note.
Quá ít time: Explorary test.

Còn việc không chạy mà wánh test result thì không ủng hộ tí nào.

Góp ý của em là đúng, nhưng vấn đề quan trọng và trọng tâm là câu cuối của em. Nếu không test thì không được điền kết quả. Phải ghi là Not Test hoặc Pending (ví dụ vậy). Và ghi lý do tại sao.

[tvn]

Từ "chuyên ngành" gọi hành động này là "Bùa" =))

Trước hết mình muốn kể về 1 trường hợp mình đã từng kinh qua.

Cách đây 1 năm, trong dự án của mình cũng có 1 bạn tester test theo kiểu khoa học của bạn test A trong topic.
Hai ngày sau khi release, KH gửi một số bug về. Trong đó có một bug thuộc loại siêu dễ phát hiện (obviously bugs).
KH yêu cầu giải thích tại sao lại còn bug "dễ" như vậy sau release (Beta release).

Sau khi phân tích, team thấy bug đó đúng ra đã được cover trong test case trong đợt releae đó. Check lại thì test case đó được đánh passed.
Team setup lại môi trường test và executed lại thì thấy case đó bị fail.
Lúc này trace ra mới biết bạn tester đó đã không execute TC mà làm theo kiểu "khoa học" (được đề cập ở trên) do áp lực thời gian.
Sau đợt đó KH doạ "cái gì không xài được thì bỏ".

Yes, hoàn toàn đồng ý với phân tích hay, rõ ràng và sâu sắc, chân thật nhất có thể. Và cái ví dụ xương máu này

[StevenPhuong]

Về mặt nguyên tắc các test case đã được liệt kê ra là cần phải test.
Nên có 3 cases xảy ra trong topic này:
1 đủ time: quất láng, giết ráo.
Không đủ time: chọn ra bộ test case theo risk, theo main feature, theo new feature, theo request của release note.
Quá ít time: Explorary test.

Còn việc không chạy mà wánh test result thì không ủng hộ tí nào.

Góp ý của em là đúng, nhưng vấn đề quan trọng và trọng tâm là câu cuối của em. Nếu không test thì không được điền kết quả. Phải ghi là Not Test hoặc Pending (ví dụ vậy). Và ghi lý do tại sao.

Đã ko đủ time còn đủ thời gian để làm bước giải thích vì sao không đủ test sao anh ? ngay từ đầu phải làm process, nhìn vô thấy là tự hiểu chớ .