Khi tìm hiểu về Testing trong Agile, bạn thường đi vào tìm hiểu chi tiết cụ thể luôn như:
- Agile áp dụng kỹ thuật gì?
- Sử dụng phương pháp ra sao?
- Cần tool gì?
- Hoạt động như thế nào?
- .....
Bước này rất quan trọng trước khi bước vào tiến hành 1 dự án, Tester cần bắt buộc phải nắm rõ, ít nhất là các đầu mục câu hỏi trên. Nếu không chúng ta sẽ gặp nhiều khó khăn trong quá trình làm việc.
Lướt qua 1 vài thông tin chính của Agile:
Agile sử dụng các phương pháp luận phát triển dựa trên nguyên tắc phát triển phân đoạn lặp (iterative) và tăng trường (incremental)
Agile sử dụng cách lập kế hoạch thích ứng (adative planning), phát triển và chuyển giao theo hướng tiến hoá
Agile sử dụng các khung thời gian ngắn và linh hoạt để dễ dàng phản hồi lại với các thay đổi trong quá trình phát triển
Agile đóng góp trong cách thức làm việc/ quản lý/ sản xuất ... ở các ngành sản xuất (manufacturing), dịch vụ (services), sales, marketing, giáo dục (education),....
"Hiện tại, Agile đang là "mốt", là xu hướng chủ yếu của các công ty phần mềm. Bên cạnh 1 RUP (Rational Unified Process) đã từng là quy trình phổ biến nhất của các công ty trong khoảng vài 3 năm trước.
Nhưng như thế nào là Agile? Vận dụng Agile trong Testing như nào cho hiệu quả thì vẫn đang là vấn đề đau đầu cùa nhiều công ty
Agile hiệu quả, chính xác. Nếu không hiệu quả thì nó không thể thay thế hay kế thừa RUP được, và được sử dụng như 1 trào lưu mới bây giờ.
Nhưng có phải lúc nào cũng vận dụng Agile cũng là hiệu quả? Cũng chưa chắc! Đó là con dao 2 lưỡi, kể cả trong phạm vi dự án nói chung và công việc Testing nói riêng!" - trích đoạn chia sẻ của bạn winter ;)
>>> Agile dưới quan điểm của Tester
Tác động của Agile lên đội phát triển phần mềm là "khổng lồ". Với đội Test thì điều này còn rõ ràng hơn, đặc biệt đối với dự án trong quá trình phát triển gặp nhiều vấn đề.
Việc chuyển sang Agile có nhiều điểm tích cực, tuy nhiên cũng không ít điểm chúng ta cần xem xét. Vì thông thường lý thuyết luôn màu hồng, còn từ lý thuyết sang thực tế là cả 1 chặng đường.
Agile hay và linh hoạt nhưng nên áp dụng thực tiễn vào công ty bạn như thế nào, vì mỗi công ty có một phương thức áp dụng riêng, không phải công ty nào cũng giống nhau mặc dù củng là Agile
Trước khi làm việc với Agile thực sự phải nắm rõ các khái niệm, và hiểu 1 cách đúng đắn về Agile hay quản lý Developer code như thế nào
Agile có nhiều cách thức thực hiện khác nhau với nhiều người.
Tester cần làm gì để chuẩn bị cho Agile?
Các khía cạnh tập trung ảnh hưởng trực tiếp lên Software Testing?
Giải đáp như sau:
hầu hết các tài liệu hướng dẫn và các bài giảng ngày nay về Agile, Scrum & XP tập trung vào các hoạt động cụ thể (practice) Ví dụ như phương thức TDD (Test Driven Development), Sprint Retrospective và Estimate User Story, nhưng với nội dung bài viết này tôi tập trung vào Software Testing (test theo truyền thống) chứ không theo nghĩa testing acceptance trong User Story
Thứ hai: Cần tập trung và các yếu tố mà Agile thường bị bỏ qua ví dụ như: Tính năng động của Team (Dynamic), khả năng tự định hình ( Seft-forming), Tự định hướng (Seft-Directing), và Tool
Agile: Những điểm tích cực của mô hình
- Tăng tính tương tác của team member
- Tập trung nhiều hơn vào việc sắp xếp theo vị trí vật lý
- Bảo vệ hay tránh được các trường hợp bị ngắt quãng (interupt)
Không gì là hoàn hảo tất cả được. Ngoài những điểm tích cực thì Agile có 1 số hạn chế sau:
- Overtime
- Thiếu tính chất đóng kín (hay kết thúc)
Agile xử lý các vấn đề này không giống như bất kỳ mô hình nào trước đó. Trước Agile chưa có bất kỳ mô hình quản lý dự án nào được phát triển dựa trên việc Team ngồi gần nhau, tập trung xử lý một tập các Task một cách thông minh, thống nhất, và họp daily như vậy.
2.Agile không có nghĩa là nhanh hơn!
Agiletập trung vào yếu tố con người và tính tương tác nhiều hơn là vào Quy trình và Tool, làm việc theo từng bước xác định và dựa trên các team Tự quản lý.
Những người làm việc trong các dự án Agile thường cần hài lòng hơn với công việc của họ, làm theo từng bước xác định và cảm thấy tốt hơn về chất lượng của sản phẩm. Nếu không, có nghĩa là công ty bạn không theo đúng con thuyền Agile. Nếu Agile tại công ty bạn tập trung vào Tool, hay triển khai một tập hợp các Tool nhiều hơn là các yếu tố vừa đề cập, có nghĩa là có điều gì đó chưa đúng ở đây.
3.Tester thường được đưa ra nhiều ý tưởng và các hoạt động trong một thời gian dài:
- "Unit Testing thực sự là tốt - chúng ta nên triển khai nhiều hơn!". CÁc Testers sẽ nói điều này trong bao lâu?
- "Chấp nhận sự thật là chúng ta luôn luôn chấp nhận những thay đổi của dự án dù ở giai đoạn cuối hơn là giả bộ như chúng ta không chấp nhận".
- "Tôi (chính thức trước đây cũng là một QA) không làm nên chất lượng - Chất lượng đến từ tất cả chúng ta!"
- "Các bạn sẽ ngừng gọi chúng tôi là QA Team"
- "Chúng ta cần automate nhiều hơn nữa"
- "Chúng ta cần thiết kế code để sao cho có thể test được"
Thực tế là Test Team đã từng biết đến rất nhiều kinh nghiệm tốt trong việc triển khai Agile trong một thời gian dài. Trong một số trường hợp, sử dụng Agile có thể không hề ảnh hưởng gì tới cách thức làm việc của Tester truyền thống. Bản chất của việc Testing thì có thể không thay đổi nhiều. Nhưng cách thức các dự án được quản lý như thế nào thì lại thay đổi khá nhiều
Với Tester:
Thứ nhất: Agile không có nghĩa là nhanh hơn! Đó không phải là Scrum, XP (Xtreame programming) hay Lean.
Agile không phải là 1 Quy trình phát triển phần mềm (SDLC - Software Development Life Cycle), hay dùng để quản lý 1 dự án.
Bài viết trên mình tổng hợp từ nhiều nguồn từ hanoiscrum và 1 chút hiểu của mình. Rất vui khi Bạn đọc góp ý bổ sung để trao đổi kiến thức nhiều hơn. Thank for reading
No comments:
Post a Comment