Anh ơi em thấy đoạn 17:00 anh giảng về Error, Defects, Failure em thấy không giống như trong ISTQB ạ. "A person can make an error (mistake), which can lead to the introduction of a defect (fault or bug) in the software code or in some other related work product. An error that leads to the introduction of a defect in one work product can trigger an error that leads to the introduction of a defect in a related work product. For example, a requirements elicitation error can lead to a requirements defect, which then results in a programming error that leads to a defect in the code. If a defect in the code is executed, this may cause a failure, but not necessarily in all circumstances." Từ đoạn trích trên thì theo em hiểu error = mistake - là lỗi do con người trong quá trình tạo ra workproduct, error (mistake) đó tạo nên defect ở trong workproduct (code/spec,..) và defect này có thể tạo ra failure khi execute software. Còn trên slide và video anh giảng là Defect dẫn tới Error và Error dẫn tới Failure thì em thấy không khớp với ISTQB ạ.
@@testwithme An error that leads to the introduction of a defect in one work product can trigger an error that leads to the introduction of a defect in a related work product. For example, a requirements elicitation error can lead to a requirements defect, which then results in a programming error that leads to a defect in the code. Chỗ này là error -> defect mừ anh. theo ví dụ là error trong lúc tạo requirement -> defect trong requirement. vì defect trong requirement dẫn đến error trong programming, kiểu dev họ đọc requirement xong hiểu sai nên lập trình sai -> tạo ra defect trong code. Nên error A (= mistake) tạo ra defect A -> từ defect A trong work product A -> rồi dẫn tới một error B tạo nên defect B của work product B base trên work product A í ạ (code base trên requirement) chứ bản chất thì là error rồi mới đến defect ạ
Yup cũng hợp lý. chỗ này do thiếu sót của anh rồi. đúng ra theo cách anh nói thì anh phải nói thêm cho đủ là mistake -> defect -> errors -> defect -> failure mới hợp lý. Thanks em nhiều! Để anh pin cái này nên đầu để các bạn khác tham khảo.
hi bạn, bạn có thể chia sẻ thêm về cách chọn tập mẫu khi review testcase của member của lead hoặc manager không. vì khi bạn là lead của 1 nhóm bạn không thể đi ngồi đọc và review từng case được như thế sẽ mất nhiều thời gian.
Hi bạn. với câu hỏi này mình xin phép chia sẻ kinh nghiệm của mình như sau. Mình có kinh nghiệm là manager manage hơn 30 members. Với việc làm manager thì mình ko có thời gian để review test case là điều tất nhiên, việc này sẽ dc giao cho các test lead thực hiện, việc mình quan tâm sẽ là các luồng chính phục vụ business có hoạt động đúng theo yêu cầu của khách hàng hoặc cũng có thể chú ý qua các high level testcases. Đối với Test Lead thì chúng ta nên xây dựng nguyên tắc thiết kế test case, template... để các bạn tuân thủ theo thì khi review chúng ta chỉ theo đó mà làm sẽ nhanh hơn rất nhiều, chúng ta ko cần tập chung quá vào chi tiết test case mà tập trung vào test case đó làm gì và đối chiếu với requirement là dc. Trước khi Test Lead review thì có thể yêu cầu các bạn review chéo lẫn nhau, như vậy sẽ đỡ đc rất nhiều thời gian công sức của Test Lead. Khi tới Test Lead review thì nên có checklist để follow theo, như vậy sẽ nhanh hơn, cũng như đỡ bỏ sót. Còn về việc bạn nói là chọn tập mẫu thì mình khuyên ko nên làm như vậy, về mặt chất lượng chúng ta là lead chúng ta cần aware về những thứ mà chúng ta quản lý, chúng ta nên chọn cách để làm nhanh hơn chứ ko phải là chọn đường tắt, cắt bỏ các bước.
Anh ơi em thấy đoạn 17:00 anh giảng về Error, Defects, Failure em thấy không giống như trong ISTQB ạ.
"A person can make an error (mistake), which can lead to the introduction of a defect (fault or bug) in the software code or in some other related work product. An error that leads to the introduction of a defect in one work product can trigger an error that leads to the introduction of a defect in a related work product. For example, a requirements elicitation error can lead to a requirements defect, which then results in a programming error that leads to a defect in the code. If a defect in the code is executed, this may cause a failure, but not necessarily in all circumstances."
Từ đoạn trích trên thì theo em hiểu error = mistake - là lỗi do con người trong quá trình tạo ra workproduct, error (mistake) đó tạo nên defect ở trong workproduct (code/spec,..) và defect này có thể tạo ra failure khi execute software.
Còn trên slide và video anh giảng là Defect dẫn tới Error và Error dẫn tới Failure thì em thấy không khớp với ISTQB ạ.
Do cách dùng từ trong syllabus dễ bị hiểu nhầm đó. Em coi cái ví dụ họ viết cũng là mistake -> defect -> errors -> failure
Với cách nói tiếng việt mình anh nói cho hợp chữ hợp nghĩa chứ cũng ko phải dịch nguyên văn của họ ra đâu 😅
@@testwithme An error that leads to the introduction of a defect in one work product can trigger an error that leads to the introduction of a defect in a related work product. For example, a requirements elicitation error can lead to a requirements defect, which then results in a programming error that leads to a defect in the code.
Chỗ này là error -> defect mừ anh. theo ví dụ là error trong lúc tạo requirement -> defect trong requirement. vì defect trong requirement dẫn đến error trong programming, kiểu dev họ đọc requirement xong hiểu sai nên lập trình sai -> tạo ra defect trong code.
Nên error A (= mistake) tạo ra defect A -> từ defect A trong work product A -> rồi dẫn tới một error B tạo nên defect B của work product B base trên work product A í ạ (code base trên requirement) chứ bản chất thì là error rồi mới đến defect ạ
Yup cũng hợp lý. chỗ này do thiếu sót của anh rồi. đúng ra theo cách anh nói thì anh phải nói thêm cho đủ là mistake -> defect -> errors -> defect -> failure mới hợp lý. Thanks em nhiều! Để anh pin cái này nên đầu để các bạn khác tham khảo.
@@testwithme dạ vâng ạ 🥰 cám ơn anh đã giúp chúng em ôn bài ạ
hi bạn, bạn có thể chia sẻ thêm về cách chọn tập mẫu khi review testcase của member của lead hoặc manager không.
vì khi bạn là lead của 1 nhóm bạn không thể đi ngồi đọc và review từng case được như thế sẽ mất nhiều thời gian.
Hi bạn. với câu hỏi này mình xin phép chia sẻ kinh nghiệm của mình như sau. Mình có kinh nghiệm là manager manage hơn 30 members. Với việc làm manager thì mình ko có thời gian để review test case là điều tất nhiên, việc này sẽ dc giao cho các test lead thực hiện, việc mình quan tâm sẽ là các luồng chính phục vụ business có hoạt động đúng theo yêu cầu của khách hàng hoặc cũng có thể chú ý qua các high level testcases. Đối với Test Lead thì chúng ta nên xây dựng nguyên tắc thiết kế test case, template... để các bạn tuân thủ theo thì khi review chúng ta chỉ theo đó mà làm sẽ nhanh hơn rất nhiều, chúng ta ko cần tập chung quá vào chi tiết test case mà tập trung vào test case đó làm gì và đối chiếu với requirement là dc. Trước khi Test Lead review thì có thể yêu cầu các bạn review chéo lẫn nhau, như vậy sẽ đỡ đc rất nhiều thời gian công sức của Test Lead. Khi tới Test Lead review thì nên có checklist để follow theo, như vậy sẽ nhanh hơn, cũng như đỡ bỏ sót. Còn về việc bạn nói là chọn tập mẫu thì mình khuyên ko nên làm như vậy, về mặt chất lượng chúng ta là lead chúng ta cần aware về những thứ mà chúng ta quản lý, chúng ta nên chọn cách để làm nhanh hơn chứ ko phải là chọn đường tắt, cắt bỏ các bước.
a ơi có slide bài giảng k ạ
em chịu khó xem video nhé. slide anh ko share dc