Bài 8 - Agile Testing là gì?
ฝัง
- เผยแพร่เมื่อ 23 ก.ย. 2024
- AGILE TESTING là một phương thức test tuân theo các quy tắc và nguyên tắc phát triển phần mềm agile. Không giống như phương pháp Waterfall, Agile Testing có thể được thực hiện ngay từ thời điểm bắt đầu dự án với sự kết hợp liên tục giữa phát triển và kiểm thử. Agile Testing không tuân theo thứ tự (tức là chỉ được thực hiện sau khi code xong) mà nó được thực hiện liên tục.
#agile #tester #automationtester #agiletesting
► Xem thêm các bài viết về kiểm thử phần mềm tại đây: levunguyen.com... levunguyen.com...
#hoclaptrinh #kiemthuphanmem #agiletesting
► Subscribe kênh TH-cam của Nguyên để nhận được video mới MIỄN PHÍ hằng tuần tại đây ngay nhé: bom.to/644ln9z9hS
Channel Le Vu Nguyen Vlog là nơi chia sẻ những kiến thức chuyên môn về lập trình nhằm hỗ trợ cho quá trình học lập trình của các bạn. Với những chia sẻ về kiến thức lập trình từ cơ bản cho đến nâng cao được phân loại theo từng danh mục hi vọng sẽ giúp bạn từng bước chinh phục lĩnh vực này và có thể trở thành một lập trình viên chuyên nghiệp trong tương lai.
► Khám phá thêm các nguồn học lập trình miễn phí:
Các khoá học lập trình online miễn phí tại: hoclaptrinhonl...
Các bài viết chia sẻ về lĩnh vực lập trình tại: levunguyen.com
Tham gia group Da Nang Agile Developer Community để hỏi-đáp về lĩnh vực lập trình: / danangagiledeveloper
Kênh tiktok lĩnh vực lập trình: www.tiktok.com...
ĐỪNG NGẠI ĐỂ LẠI THẮC MẮC CỦA BẠN DƯỚI PHẦN BÌNH LUẬN, MÌNH SẼ CỐ GẮNG GIẢI ĐÁP SỚM NHẤT CHO CÁC BẠN.
Anh cho em hỏi, nếu tester chạy chậm hơn team dev 1 sprint, vậy thì khi bug xảy ra thì team dev có chỉnh sửa ngay không. Hay đợi kết thúc sprint có test report do tester cập nhật, set up fix bug thành 1 task trong sprind mới. Và nếu vậy thì cái fix bug đó sẽ nằm trong user story nào. Như ví dụ của anh sprint 1 : dev phát triển user story 1,2,3 . sprint 2: dev phát triển user story 4,5,6 , tester test user story 1,2,3 và cho ra test report 1,2,3. Vậy thì sprint 3 : dev sẽ tiếp tục phát triển user story 7,8,9 + fix bug 1,2,3. Hay ở sprint 2: dev sẽ work on 4,5,6 + fix bug 1,2,3 (làm việc song song với tester)?
nếu là bug có độ ưu tiên quan trọng thì dev bắt buộc phải fix và release gấp trong sprint đó. Trương hợp khác thì bug đó sẽ được chuyển qua sprint tiếp theo của dev. Khi bug chuyển sang sprint tiếp theo đồng nghĩa với việc team dev sẽ làm được ít velocity hơn, vì thời gian đã dành cho việc fix bugs không có time cho việc tạo ra giá trị. Như vậy khi làm sprint retro cả team phải ngồi với nhau xem xét tại sao lại có nhiều bugs nguyên nhân và hướng giải quyết, để các sprint tiếp theo bug ít hơn.
Anh ơi nếu anh còn giữ slide này, anh có thể chia sẻ cho em với được không ạ?
Cảm ơn a
Hay quá ạ :3 Mong anh ra nhiều video hơn ạ
Hồi xưa cực hen anh 😂 Giờ có mấy cái Jira, Trello đỡ dễ sợ, dễ follow theo task nữa. :))