DVMS Co.,Ltd

I. Khái niệm

Phương thức phát triển phần mềm Agile là một tập hợp các phương thức phát triển lặp và tăng dần trong đó các yêu cầu và giải pháp được phát triển thông qua sự liên kết cộng tác giữa các nhóm tự quản và liên chức năng. Agile là cách thức làm phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt càng sớm càng tốt và được xem như là sự cải tiến so với những mô hình cũ như mô hình “Thác nước (waterfall)” hay “CMMI”.

Nguyên tắc áp dụng trong phương pháp Agile

1. Kiểm thử giúp dự án nhanh chóng được bàn giao

   Ở dự án truyền thống, kiểm thử thường được xem là bước cuối kiểm tra chất lượng sản phẩm. Và việc ngăn chặn lỗi của phầm mềm bị coi như trách nhiệm của QA/tester. Bug được tìm thấy dù quan trọng hay không thì cũng sẽ làm chậm quá trình bàn giao sản phẩm.

   Trong dự án Agile, chúng ta xây dựng một sản phẩm tốt ngay từ ban đầu, sử dụng kiểm thử để phản hồi trên ngay khi phát triển để làm thế nào cho sản phẩm tương đồng với yêu cầu.

   Nghe có vẻ là thay đổi nhỏ, nhưng thực chất thì việc này có ý nghĩa lớn. Mối liên hệ giữa tester và dev cần là sự cộng tác, tương hỗ lẫn nhau

   

2. Kiểm thử không chỉ là một giai đoạn của dự án

   Kiểm thử không phải là một giai đoạn trong quá trình phát triển Agile mà cần được tham gia sâu vào quy trình phát triển từ sớm.

   Cách tiếp cận Agile tập trung vào việc xác nhận những điều đúng đắn ngay từđầu, giảm sự cần thiết phải có nhiều kiểm thử viên (QA Tester) ở cuối quy trình để đạt được kết quả. Đảm bảo tiến độ dự án được liên tục.

3. Cá nhân và sự tương hỗ quan trọng hơn quy trình

   Với dự án truyền thống, tester làm việc độc lập và chịu trách nhiệm với toàn bộ hoạt động test.

   Đối với Agile, các hoạt động test được thực hiện bởi toàn bộ dự án. Để thực hiện được hết test thì cần thực hiện lặp lại qua các sprint.

   Tuy nhiên tới khi dự án lớn hoặc phức tạp lên thì sẽ có lúc không thể test hết các testcase đề ra và không thể thực hiện được mục tiêu ban đầu đề ra. Có nghĩa team không thể thực hiện nhanh như họ nghĩ. Vì nếu test chưa xong thì feature cũng không thể xong được, vì vậy để đẩy nhanh tốc độ thì cả team phải làm cùng nhau và đẩy nhanh phần chậm nhất, test cùng nhau.

    

1. Rút ngắn vòng lặp phản hồi

   Thời gian từ khi viết code và thực hiện code tới khi biết được code vận hành như thế nào được gọi là feedback loop (vòng phản hồi).

   Nếu một phần mềm không được thực hiện test cho tới khi kết thúc và được bàn giao thì vòng phản hồi này bị kéo dài tới cả tháng, như thế là quá dài.

   Agile tạo nên một vòng phản hồi ngắn hơn bởi với dự án Agile, phần mềm được sẵn sàng để test ngay từ khi bắt đầu. Đặc thù của Agile là đội dự án có rất nhiều cấp độ kiểm thử để có thể tấn công được nhiều loại dữ liệu khác nhau.

   Agile sử dụng nhiều test tự động vì nó trả lại phản hồi nhanh. Test hồi quy thủ công mất nhiều thời gian thực hiện hơn, cần có nhân lực và có thể không thực hiện ngay lập tức được. Kiểm tra thủ công vẫn còn quan trọng.

   Tuy nhiên, đội Agile thường thấy rằng những thông tin phản hồi nhanh chóng tạo nên bởi hồi quy tự động là chìa khóa để phát hiện các vấn đề một cách nhanh chóng, do đó làm giảm rủi ro và giảm việc phải làm lại.

   

2. Thỏa mãn mong muốn của khách hàng

   Cho dù là test tự động hay test thủ công thì kịch bản test cần phải khớp với yêu cầu và mong đợi của khách hàng. Trước khi tốn thời gian tìm bug nên đặt câu hỏi để làm sáng tỏ mong muốn của khách hàng đối với chức năng sản phẩm

   

3. Giữ code rõ ràng

   Nguyên tắc này là một ví dụ về một nguyên tắc mà đội Agile phải có. Sẽ mất nhiều công sức và thời gian để sửa lỗi khi chúng được tìm thấy.

   Nếu đó là một lỗi chính đáng nó sẽ được sửa trong vòng lặp và đôi khi kết quả sau khi sửa sẽ không được tốt bằng làm từ đầu vì nó ảnh hưởng tới những phần khác.

   

4. Giản lược tài liệu kiểm thử

   Thay vì viết dài dòng thì Agile test

• Tái sử dụng checklist
• Tập trung vào bản chất của các thử nghiệm chứ không phải là các chi tiết ngẫu nhiên
• Sử dụng các tài liệu hướng dẫn đơn giản
• Nắm bắt những ý tưởng thử nghiệm trong điều lệ kiểm nghiệm thăm dò

8. Chưa thể hoàn thành khi chưa qua giai đoạn kiểm thử

   Trong dự án truyền thống có sự phân tách rõ ràng giữa dev và test, đó là đặc trưng cho việc dev nói “xong” với phần họ phát triển nhưng nó vẫn chưa được test. Do đó thực tế là phần phát triển ấy vẫn chưa xong cho tới khi test xong và bug được fix.

   Đó là lý do vì sao mà phần mềm chỉ được để “90% done”. Agile không tính là “done” mà nó cần được sẵn sàng cho sự chấp nhận của Product Owner và khách hàng cho tới khi nó được thực thi và test

   

9. Test-Last và Test-Driven

   Trong môi trường phát triển truyền thống, test được lấy từ tài liệu yêu cầu. Yêu cầu và design đầu tiên, sau đó đến kiểm thử. Quá trình kiểm thử diễn ra ở cuối dự án.
   Tuy nhiên kiểm thử cung cấp một ví dụ về ý nghĩa của việc phát triển thỏa mãn yêu cầu.
   Test được định hướng từ các thành phần của project, trong đó có tài liệu dự án. Việc thực hiện test được tiến hành vào thời điểm cuối cùng của project. Đây gọi là cách tiếp cận “testlast” – Test sau cùng

II. Các giai đoạn kiểm thử phần mềm tương ứng với các giai đoạn phát triển phần mềm trong mô hình Agile

1. Tiền-Phân-đoạn (Pre-iteration):####

Yêu cầu được phân tích chi tiết bởi BA (Business Analyst – chuyên viên phân tích nghiệp vụ) và các tiêu chí chấp nhận (acceptance criteria). Và QA sử dụng các yêu cầu này ngay từ đầu, ta cần phải xác minh (verify) những yêu cầu đó từ sớm và thường xuyên.

2. Xác minh Yêu cầu:

Kiểm thử Agile thiên về việc đưa ra phản hồi sớm, và phải bắt đầu bằng việc kiểm tra các yêu cầu từ sớm bởi QA hoặc tester để làm sáng rõ ý nghĩa và tính khả-kiểm (testability). Việc này sẽ đảm bảo các yêu cầu luôn rõ ràng và có thể kiểm thử được.

• Yêu cầu cần đủ nhỏ để có ý nghĩa trong bối cảnh xác định
• Tiêu chí chấp nhận (acceptance criteria những story thường được sử dụng cho các tiêu chí chấp nhận) không nên bị trùng lặp, chồng chéo từ những story khác nhau
• Các giai đoạn:
  

   

  • user story: là một tóm tắt đơn giản, ngắn gọn về chức năng mà khách hàng mong muốn.
  • Tiêu chí chấp nhận (Acceptance Criteria): là những tiêu chí dùng để đánh giá sản phẩm, chức năng đã thực hiện đúng yêu cầu hay chưa? Có thể coi đó là các tiêu chí xác nhận hoàn thành story.Các tiêu chí đặt ra phải đáp ứng các đặc tính sau:
    • Tính khả dụng (usability): là tiêu chí trả lời cho câu hỏi: Có dễ sử dụng hay không?
    • Tính chức năng (Functionality)
    • Xử lý lỗi (error handing) : Liệt kê ra những lỗi có thể gặp phải trong quá trình sử dụng chương trình và phương thức để xử lý. Ví dụ người dùng có thể thực hiện sai thứ tự các bước và khi đó chương trình sẽ xử lý như thế nào?
    • Hiệu suất( Performance)
    • Stress tests: Là tiêu chí trả lời cho câu hỏi: Hệ thống sẽ hoạt động như thế nào dưới những áp lực như có nhiều người truy cập tại cùng 1 thời điểm, có quá nhiều request được gửi đến hệ thống…

    Để đạt được mục tiêu của giai đoạn này cần có sự giao tiếp chặt chẽ giữa các bên Đội Phát triển / Nhà phân tích nghiệp vụ/ Đảm bảo chất lượng.

    • Khả kiểm (Testable): Các khía cạnh có thể kiểm thử được phải được xem xét chi tiết. Những yếu tố này thường là:
      • Tìm kiếm các yêu cầu ẩn
      • Môi trường
      • Dữ liệu kiểm thử (test data)
      • Sự phụ thuộc vào các yêu cầu khác

3. Các hoạt động Đảm bảo chất lượng:####

• Kiểm thử chấp nhận là các yêu cầu về phương diện kiểm thử cần được thực hiện để hiểu các yêu cầu phần mềm. Các kiểm thử chấp nhận này được sinh ra tự động và dùng để hướng dẫn quá trình phát triển.
• Các kiểm thử chấp nhận không nên bao gồm toàn bộ các tình huống (case scenarios) do điều này có thể tạo ra những sự ngưng trệ không cần thiết và có thể tạo ra quá nhiều bộ kiểm thử tự động (automated test) tương tự nhau.
• Kiểm thử chấp nhận trong các dự án Agile rất khác biệt so với các dự án truyền thống. Không giống như các dự án truyền thống, nơi kiểm thử chấp nhận xảy ra ở phần cuối của vòng đời phần mềm, trong dự án Agile kiểm thử chấp nhận được thực hiện trước khi phần mềm được chuyển giao. Kiểm thử chấp nhận cũng có xu hướng được tự động hóa để họ có thể chạy như là kiểm thử hồi quy (regression test).
• Kiểm thử tự động rất quan trọng đối với mọi dự án Agile. Các bản build thường xuyên yêu cầu các chu kỳ phản hồi ngắn, do đó kiểm thử hồi quy phải nhanh chóng và chính xác.
• Trong các dự án Agile, kiểm thử tự động được thực hiện bởi tất cả các cấp độ – lập trình viên, kiểm thử viên bảo đảm chất lượng(QA tester) và các nhà phân tích nghiệp vụ (BA). Sự tham gia của tất cả mọi người làm gia tăng tính xác đáng của các phần kiểm thử và thường giúp xác định đúng các phần kiểm thử. Tuy nhiên, điều này không có nghĩa là tất cả mọi người phải đều phải viết mã kiểm thử.

Techtalk Via Viblo

DVMS chuyên:
- Tư vấn, xây dựng, chuyển giao công nghệ Blockchain, mạng xã hội,...
- Tư vấn ứng dụng cho smartphone và máy tính bảng, tư vấn ứng dụng vận tải thông minh, thực tế ảo, game mobile,...
- Tư vấn các hệ thống theo mô hình kinh tế chia sẻ như Uber, Grab, ứng dụng giúp việc,...
- Xây dựng các giải pháp quản lý vận tải, quản lý xe công vụ, quản lý xe doanh nghiệp, phần mềm và ứng dụng logistics, kho vận, vé xe điện tử,...
- Tư vấn và xây dựng mạng xã hội, tư vấn giải pháp CNTT cho doanh nghiệp, startup,...

Vì sao chọn DVMS?
- DVMS nắm vững nhiều công nghệ phần mềm, mạng và viễn thông. Như Payment gateway, SMS gateway, GIS, VOIP, iOS, Android, Blackberry, Windows Phone, cloud computing,…
- DVMS có kinh nghiệm triển khai các hệ thống trên các nền tảng điện toán đám mây nổi tiếng như Google, Amazon, Microsoft,…
- DVMS có kinh nghiệm thực tế tư vấn, xây dựng, triển khai, chuyển giao, gia công các giải pháp phần mềm cho khách hàng Việt Nam, USA, Singapore, Germany, France, các tập đoàn của nước ngoài tại Việt Nam,…

Quý khách xem Hồ sơ năng lực của DVMS tại đây >>

Quý khách gửi yêu cầu tư vấn và báo giá tại đây >>