Tài liệu Nghiên cứu phát triển phần mềm hướng hành vi ứng dụng công cụ Behat

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ -----------o0o----------- PHAN THI ̣GẤM NGHIÊN CƢ́U PHÁ T TRIỂN PHẦN MỀM HƢỚNG HÀ NH VI VÀ Ƣ́NG DỤNG CÔNG CỤ BEHAT LUẬN VĂN THẠC SĨ NGÀ NH CÔNG NGHỆ THÔNG TIN HÀ NỘI 12– 2013 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ -----------o0o----------- PHAN THI ̣GẤM NGHIÊN CƢ́U PHÁ T TRIỂN PHẦN MỀM HƢỚNG HÀ NH VI VÀ Ƣ́NG DỤNG CÔNG CỤ BEHAT Ngành: Công nghê ̣thông tin Chuyên ngành: Công nghê ̣phầ n mềm Mã số: 60 48 10 LUẬN VĂN THẠC SĨ NGƢỜI HƢỚNG DẪN KHOA HỌC TS. TRƢƠNG ANH HOÀ NG HÀ NỘI – 2013 i LỜI CAM ĐOAN Tôi xin cam đoan kết quả đạt đƣợc trong luận văn là sản phẩm nghiên cứu, tìm hiểu của riêng cá nhân tôi. Trong toàn bộ nội dung của luận văn, những điều đƣợc trình bày hoặc là của cá nhân tôi hoặc là đƣợc tổng hợp từ nhiều nguồn tài liệu. Tất cả các tài liệu tham khảo đều có xuất xứ rõ ràng và đƣợc trích dẫn hợp pháp. Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định cho lời cam đoan của mình. Học viên thực hiện Phan Thị Gấm ii LỜI CẢM ƠN Tôi xin bày tỏ lòng biết ơn sâu sắc đến tất cả mọi ngƣời đã giúp đỡ, hỗ trợ thực hiện luận văn này, xin cảm ơn Khoa Công nghê ̣ thông tin , Trƣờng Đa ̣i học Công nghê ̣, Đa ̣i học Quốc g ia Hà Nô ̣i đã cho phép và tạo điều kiện để tôi thực hiện luận văn này. Luận văn này sẽ không thể hoàn thành nếu không có sự giúp đỡ và chỉ bảo tận tình của Thầygiáo, Tiế n siT ̃ rƣơng Anh Hoàng , giáo viên hƣớng dẫn của tôi. Em xin chân thành biết ơn về những chỉ bảo, định hƣớng nghiên cứu, hỗ trợ, tạo những điều kiện tốt nhất cho em trong suốt quá trình thực hiện đề tài. Con xin bày tỏ lòng biết ơn sâu sắc đến nhƣ̃ng ngƣời thân trong gia đình đă ̣c biê ̣t là Bố , Mẹ, Chồng và con gái đã động viên, ủng hộ trong những lúc khó khăn để con có đƣợc nhƣ ngày hôm nay. Xin chân thành cảm ơn tất cả quý Thầy,Cô trong Khoa, Trƣờng đã tận tình chỉ bảo, rèn luyện, truyền đạt những tri thức, kỹ năng, kinh nghiệm quý báu cho tôi trong suốt nhƣ̃ng năm học vừa qua. Học viên thực hiện Phan Thị Gấm iii MỤC LỤC LỜI CAM ĐOAN................................................................................................... i LỜI CẢM ƠN ....................................................................................................... ii DANH MỤC CÁC TƢ̀ VIẾT TẮT....................................................................... v DANH MỤC BẢNG BIỂU ................................................................................. vi DANH MỤC HÌNH VẼ ....................................................................................... vi CHƢƠNG – MỞ ĐẦU ........................................................................................ 1 CHƢƠNG 1. KIỂM THỬ TRONG PHƢƠNG PHÁP PHÁT TRIỂN PHẦN MỀM LINH HOA ̣T............................................................................................. 5 1.1. Mô hình phát triển lặp trong phƣơng pháp phát triển linh hoạt ........... 5 1.1.1. Quy trình Scrum ........................................................................................ 6 1.1.2. Lập trình cực hạn .................................................................................... 10 1.2. Kiểm thử trong phƣơng pháp triển linh hoạt ........................................ 11 1.2.1. Kiểm thử đơn vị ...................................................................................... 13 1.2.2. Kiểm thử chấp nhận trong lâ ̣p trình cƣ̣c ha ̣n XP .................................... 13 1.3. Đặc tả yêu cầu hệ thống bằng câu chuyện ngƣời dùng ......................... 13 1.4. Các kỹ thuâ ̣t phát triển phần mềm theo hƣớng kiểm thử .................... 16 1.4.1. Phát triển phần mềm theo hƣớng kiểm thử ............................................. 16 1.4.2. Phát triển phần mềm theo hƣớng kiểm thử chấp nhận ........................... 20 1.4.3. Mô ̣t số vấ n đề của phát triể n phầ n mề m dƣ̣a vào kiể m thƣ̉ .................... 22 CHƢƠNG 2. PHÁT TRIỂN PHẦN MỀM HƢỚNG HÀNH VI ................. 24 2.1. Tổng quan về phát triển phần mềm hƣớng hành vi .............................. 24 2.2. Nguyên lý hoạt động.................................................................................. 25 2.3. Quy trình phát triển phần mềm theo hƣớng hành vi ............................ 27 2.3.1. Đặc tả hành vi của ƣ́ng du ̣ng................................................................... 29 2.3.2. Viế t kiể m thƣ̉ cho các bƣớc .................................................................... 30 2.3.3. Lă ̣p để cài đă ̣t ƣ́ng du ̣ng .......................................................................... 31 2.4. Ngôn ngữ đặc tả ứng dụng ....................................................................... 31 CHƢƠNG 3. CÔNG CỤ BEHAT ................................................................... 35 3.1. Giới thiệu công cụ Behat .......................................................................... 35 3.1.1. Công cụ dòng lệnh của Behat ................................................................. 35 3.1.2. Cấu trúc thƣ mục ..................................................................................... 36 3.2. Cách sử dụng Behat .................................................................................. 36 3.2.1. Xác định các tính năng ............................................................................ 36 3.2.2. Sử dụng Gherkin để viết các tính năng ................................................... 37 3.2.3. Xây dƣ̣ng các định nghĩa bƣớc ............................................................... 43 3.2.4. Móc nối quá trình kiểm thử và các sự kiện............................................. 48 3.2.4.1. Các sự kiện trong Behat .................................................................. 48 iv 3.2.4.2. Hooks .............................................................................................. 49 3.2.5. Kiểm thử các tính năng – lớp FeatureContext ........................................ 50 3.3. Phát triển ứng dụng Web với Mink ........................................................ 51 3.4. Lớp MinkContext ...................................................................................... 52 3.5. Cấu hình Behat với behat.yml ................................................................. 55 CHƢƠNG 4. ÁP DỤNG PHÁT TRIỂN PHẦN MỀM HƢỚNG HÀNH VI VÀ CÔNG CỤ BEHAT..................................................................................... 60 4.1. Giai đoa ̣n chuẩ n bi .................................................................................... 60 ̣ 4.2. Tiế n trin ̀ h thƣ̣c hiêṇ ƣ́ng du ̣ng ................................................................. 61 4.3. Áp dụng phát triển hƣớng hành vi và công cụ Behat............................ 63 4.3.1. Tính năng “Xem trang chủ” .................................................................... 63 4.3.2. Tính năng “Đăng ký thành viên” ............................................................ 70 4.4. Nhận xét và kết luận ................................................................................. 92 KẾT LUẬN 95 TÀI LIỆU THAM KHẢO ................................................................................... 97 PHỤ LỤC ............................................................................................................ 98 v DANH MỤC CÁC TƢ̀ VIẾT TẮT JS CSS HTTP API Ajax DOM XP TDD ATDD BDD JavaScript Cascading Style Sheets Giao thƣ́c HTTP Application Programming Interface Asynchronous Javascript and XML Document Object Model eXtreme Programming Test Driven Development Acceptance Test Driven Development Behaviour Driven Development vi DANH MỤC BẢNG BIỂU Bảng 3-1. Các thuộc tính của lệnh behat ............................................................ 35 Bảng 3-2 MinkContext với các đinh ̣ nghiã bƣớc để ta ̣o yêu cầ u ........................ 53 Bảng 3-3 MinkContext các đinh ̣ nghiã với bƣớc tƣơng tác Form ...................... 54 Bảng 3-4 MinkContext định nghĩa các bƣớc cho DOM ..................................... 55 Bảng 3-5 MinkContext với các bƣớc kiểm tra hồi đáp trang ............................. 55 DANH MỤC HÌ NH VẼ Hình 1-1. Mô hình phát triển lặp........................................................................... 5 Hình 1-2. Quy trin ̀ h Scrum.................................................................................... 7 Hình 1-3. Vòng đời của dự án XP ....................................................................... 11 Hình 1-4. Nguyên lý TDD................................................................................... 17 Hình 1-5. Vòng đời của phần mềm phát triển theo TDD.................................... 18 Hình 1-6. Quy trin ̀ h ATDD.................................................................................. 21 Hình 2-1 Tiế n trin ̀ h phát triể n phầ n mề m hƣớng hành vi ................................... 28 Hình 3-1. Cấ u trúc thƣ mu ̣c làm viê ̣c của Behat ................................................. 36 Hình 3-2. Cấ u trúc chung của mô ̣t tính năng bằ ng Gherkin ............................... 38 Hình 3-3. Mô tả các tính năng ............................................................................. 41 Hình 3-4. Các sự kiện Hook của Behat ............................................................... 49 Hình 3-5 Cấ u hin ̀ h behat.yml .............................................................................. 56 Hình 4-2 Tiế n hình áp du ̣ng BDD và Behat để phát triể n ƣ́ng du ̣ng .................. 62 Hình 4-3 Tính năng trang chủ hệ thống .............................................................. 63 Hình 4-4. Sử dụng bộ điều khiển trình duyệt Selenium...................................... 80 -1- CHƢƠNG – MỞ ĐẦU Chấ t lƣơ ̣ng là mô ̣t trong nhƣ̃ng yế u tố quan tro ̣ng nhấ t của sản phẩ m phầ n mề m. Lỗi phầ n mề m không chỉ ảnh hƣởng đế n dƣ̃ liê ̣u, hoạt động của cơ quan tổ chƣ́c sƣ̉ du ̣ng phầ n mề m mà đôi khi còn ảnh hƣởng đế n tính ma ̣n g con ngƣờ i. Nhƣ̃ng ha ̣n chế hay lỗi phầ n mề m sẽ che lấ p các tiń h năng và tiê ̣n ić h mà hê ̣ thố ng đó mang la ̣i. Đặc biệt, trong thi ̣trƣờng ca ̣nh tranh chấ t lƣơ ̣ng cao nhƣ hiê ̣n nay mô ̣t phầ n mề m phát sinh lỗi trong quá triǹ h sƣ̉ du ̣ng sẽ là m ảnh hƣởng nghiêm tro ̣ng tới danh tiế ng , thƣơng hiê ̣u và uy tiń của công ty sản xuấ t phầ n mề m. Chính vì lý do đó đảm bảo chất lƣợng phần mềm là một vấn đề quan trọng và ngày càng cầ n đƣơ ̣c quan tâm hàng đầ u trong liñ h vƣ̣c phát triển phần mềm. Tuy nhiên, mô ̣t phầ n mề m chấ t lƣơ ̣ng cao cũng có thể gă ̣p thấ t ba ̣i trên thi ̣ trƣờng nế u phầ n mề m đó không đáp ƣ́ng đƣơ ̣c nhu cầ u của khách hàng. Các công ty sản xuấ t phầ n mề m luôn cố gắ ng đƣa ra các hệ thố ng với các tính năng mới để ca ̣nh tranh với các nhà cung cấ p khác . Với đa phầ n các hê ̣ thố ng thƣơng mại, tại thời điểm bắt đầu dự án , có thể đội phát triển không thu thập đƣợc các yêu cầ u thƣ̣c sƣ̣ tƣ̀ khách hàng , phầ n mề m sẽ đƣơ ̣c phát triể n dƣ̣a trên các tiń h năng phỏng đoán và trong trƣờng hơ ̣p tồ i tê ̣ các tiń h năng đó có thể không phù hơ ̣p với mong muố n của khách hàng . Viê ̣c thu thâ ̣p yêu cầ u khách hàng và sử dụng các mô tả tƣờng minh đ ể yêu cầu đó không bị sai lệch trong quá trình phát triể n phầ n mề m là vấn đề lớn của các nhà sản xuấ t. Thông qua quá trình sƣ̉ du ̣ng phầ n mề m , ngƣời sƣ̉ du ̣ng sẽ dễ hình dung ra các hoạt động của hệ thống và hiể u rõ hơn về nghiê ̣p vu ̣ và miề n ƣ́ng du ̣ng , khi đó khách hàng dễ đƣa ra các ý tƣởng cho tiń h năng mới và bổ sung chúng. Đây là hạn chế lớn nhất của các phƣơng pháp phát triển phần mềm truyền thống , bởi khi có sƣ̣ bổ sung hoă ̣c t hay đổ i yêu cầ u phầ n mề m đang phát triển sẽ dễ phá vỡ cấ u trúc hê ̣ thố ng. Trong phƣơng pháp phát triể n phầ n mề m truyề n thố ng , khách hàng cũng chỉ đƣợc tiếp xúc với phần mềm sau khi các yêu cầu phần mềm đã đƣơc̣ cài đă ̣t hoàn thiện, do đó viê ̣c phát hiê ̣n sai sót hoă ̣c cài đă ̣t hê ̣ thố ng không đúng với yêu cầ u khách hàng rấ t dễ xảy ra . Quy triǹ h phát triể n phầ n mề m lă ̣p hiê ̣n đa ̣i đƣơ ̣c coi là mô ̣t giải pháp khắ c phu ̣c vấ n đề thay đổ i yêu cầ u củ a ngƣời sƣ̉ du ̣ng. Ý tƣởng cơ bản trong các quy trình lặp hiê ̣n đa ̣i là phần mềm đƣợc sản xuấ t theo tƣ̀ng bƣớc, mỗi bƣớc chỉ thƣ̣c hiê ̣n mô ̣t số tính năng tƣơng đố i đô ̣c lâ ̣p để đƣa ra một phần mềm nhỏ có thể dùng đƣợc . Sau mỗ i vòng lă ̣p , khách hàng có thể dùng thử phần mềm để đƣa ra các phản hồi về hệ thống và dƣ̣a vào các phản hồi đó đội phát triển sẽ bổ sung các tính năng hữu ích hoặc cải thiện các tính năng đã đƣợc phát triển theo hƣ ớng tốt hơn cho khách hàng . Viê ̣c cho ̣n các -2tính năng để đƣa vào mỗi vòng lặp thƣờng căn cứ vào độ ƣu tiên của chúng , do đó các tính năng quan tro ̣ng thƣờng đƣơ c̣ cho ̣n để phát triể n trƣớc. Điề u này cho phép khách hàng sử dụ ng hê ̣ thố ng sớm hơn các phƣơng pháp phát triể n phầ n mề m truyề n thố ng. Bên ca ̣nh nhƣ̃ng lơ ̣i ích đáp ƣ́ng sƣ̣ thay đổ i yêu cầ u , các quy trình phát triể n phầ n mề m theo phƣơng pháp lă ̣p cũng ta ̣o ra nhƣ̃ng thách thƣ́c mới cho giai đoa ̣n kiể m thƣ̉ phầ n mề m . Ở quy triǹ h phát triể n truyề n thố ng , kiể m thƣ̉ là mô ̣t pha đƣơ ̣c thƣ̣c hiê ̣n và o cuố i dƣ̣ án , khi hê ̣ thố ng đã đƣơ ̣c cài đă ̣t hoàn thiện, nhƣngvới các hê ̣ thố ng sƣ̉ du ̣ng phƣơng pháp lă ̣p , phầ n mề m sẽ đƣơ ̣c kiể m tra trong mỗi vòng lă ̣p. Khách hàng thƣờng xuyên đƣợc sử dụng các phiên bản nhỏ của hệ thống , nên lỗi phầ n mề m hoă ̣c các tính năng sai sót sẽ sớm đƣơ ̣c phát hiê ̣n và giải quyế t trƣớc khi sản phẩ m chiń h thƣ́c đƣơ ̣c bàn giao cho khách hàng. Trong điề u kiê ̣n lý tƣởng , sau mỗi vòng lă ̣p khách hàng sẽ nhận đƣợc mô ̣t sản phẩ m có chất lƣợng cao, phù hợp với yêu cầu. Trong phƣơng pháp phát triể n phầ n mề m linh hoa ̣t , nhu cầ u kiể m thƣ̉ đƣơ ̣c hiể u là c ác quy tắc hay hoạt động đƣợc sử dụng để đảm bảo chất lƣợng phần mề m. Quá trình phát triển phần mềm thƣờng sử dụng các kỹ thuật và công cụ hỗ trơ ̣ để mã nguồn viết cho mỗi tính năng hoạt động đúng , chẳ ng ha ̣n nhƣ các kỹ thuâ ̣t lâ ̣p trình theo că ̣p , kỹ thuật phát triển hệ thống lấy kiểm thử làm trọng tâm hay kỹ thuật kiể m thƣ̉ trƣớc, ... . Tuy nhiên, mô ̣t tính năng đúngchƣa hẳ n đã phù hơ ̣p yêu cầu của khách hàng, và để kiểm tra điều đó cầ n mô ̣t phƣơng pháp kiể m thƣ̉ ở mƣ́c đô ̣ cao hơn , đó là kiể m thƣ̉ chấ p nhâ ̣n hay kiể m thƣ̉ của khách hàng . Yêu cầ u của khác h hàng là yế u tố quan tro ̣ng nhấ t để xác đinh ̣ các trƣờng hơ ̣p kiể m thƣ̉ , viê ̣c kiể m thƣ̉ nhằ m đảm bảo phầ n mề m làm ra đáp ƣ́ng nhu cầ u của khách hàng. Trong quy trin ̀ h lă ̣p , phầ n mề m đƣơ ̣c phát triể n qua các vòng lă ̣p và có sƣ̣ thay đổ i liên tu ̣c sẽ có lơ ̣i cho viê ̣c kiể m tra các tiń h năng . Mỗi tiń h năng đƣơ ̣c kiể m thƣ̉ ít nhấ t m ột lần, thâ ̣m chí nhƣ̃ng tính năng quan tro ̣ng đƣơ ̣c kiể m thƣ̉ nhiề u lầ n thông qua các vòng lă ̣p khi bổ sung các tính năng mới . Chính vì thế ,kiể m thƣ̉ hồ i quy trở nên n hàm chán và khó thực hiện ; càng gần cuối chu trình phát triể n phầ n mề m , viê ̣c kiể m thƣ̉ các tiń h năng ban đầ u quan tro ̣ng nhấ t dễ bi ̣ tiế n hành lỏng lẻo bởi tâm lý chủ quan của kiểm thử viên . Trái lại, khi tić h hơ ̣p thêm các tin ́ h năng mới, rấ t dễ phát sinh các lỗi ảnh hƣởng tới toàn hệ thống và lỗi đó phát hiện càng muộn t hì chi phí sữa lỗi càng cao . Đặc biệt ở nhƣ̃ng vòng lặp cuối thì rất khó để thực hiện , lúc này kiểm thử tự động trở thành một giải pháp hữu hiệu để giải quyết vấn đề tr ên. Kiể m thƣ̉ tƣ̣ đô ̣ng là viê ̣c sƣ̉ du ̣ng -3các phần mềm , các công cụ để kiểm thử phần mềm khác nhằm hỗ trợ cho con ngƣời tƣ̣ đô ̣ng hóa quá trình kiể m thƣ̉ . Kiể m thƣ̉ tƣ̣ đô ̣ng giúp công viê ̣c thƣ̣c hiê ̣n mô ̣t cách nhanh chóng , chính xác hơn , giải quyết các vấn đề về tâm lý trong quá trin ̀ h kiể m thƣ̉ . Kiể m thƣ̉ tƣ̣ đô ̣ng đă ̣c biê ̣t hƣ̃u hiê ̣u trong vấ n đề kiể m thƣ̉ hồ i quy , bởi có thể thƣ̣c hiê ̣n hằ ng ngày , hằ ng giờ , cho mo ̣i vòng lă ̣p mà không hề nhàm chán. Hiê ̣n nay có khá nhiề u công cu ̣ để kiể m thƣ̉ tƣ̣ đô ̣ng và nó trở thành mô ̣t phầ n không thể thiế u đố i với các hê ̣ thố ng phát triể n theo phƣơng pháp linh hoa ̣t. Tuy nhiên, để tự động hóa quá trình kiểm thử chấp nhận thì cần phải lựa chọn mô ̣t kỹ thuâ ̣t phù hơ ̣p để mô tả yêu cầ u của khách hàng . Viê ̣c sƣ̉ du ̣ng công cu ̣ phầ n lớn phu ̣ thuô ̣c vào ngôn ngƣ̃ lâ ̣p trình và kỹ thuâ ̣t đă ̣c tả yêu cầ u ngƣời dùng. Với sƣ̣ phát triể n ma ̣nh mẽ của các quy triǹ h phát triển phần mềm theo phƣơng pháp linh hoa ̣t thì thời gian gần đây có rất nhiều công cụ hỗ trợ chẳ ng hạn nhƣ PHPUnit, Selenium, TestPro, … Nghiên cứu và tìm hiểu mô ̣t kỹ thuật phát triển phần mềm, có thể đặc tả những tiêu chí kiểm thử chấp nhận từ ngƣời sử dụng và tái sử dụng các tiêu chí đó cho việc tự động hóa kiểm thử chấp nhậnlà rất cần thiết. Chính vì lí do đó tôi chọn đề tài “Nghiên cứu phát triển phần mềm hƣớng hành vi và ứng dụng công cụ Behat”. Nô ̣i dung luâ ̣n văn tâ ̣p trung vào những vấn đề sau:  Giới thiê ̣u tổ ng quan về phƣơng pháp phát triể n phầ n mề m linh hoa ̣t ; Giới thiê ̣u hai quy trình đƣơ ̣c sƣ̉ du ̣ng phổ biế n trong A gile là quy trình Scrum và lâ ̣p trình cực hạn XP; Tổng kết mục đích và vai trò của kiểm thử trong phƣơng pháp phát triển phần mềm linh hoạt , chỉ ra các mức kiểm thử thƣờng đƣợc áp dụng nhƣ kiể m thƣ̉ đơn vi,̣ kiể m thƣ̉ chấ p nhâ ̣n, …  Tìm hiểu một số kỹ thuật phát triển phần mềm thƣờng áp dụng trong phƣơng pháp phát triể n linh hoa ̣t . Phầ n này chủ yế u triǹ h bày phƣơng pháp phát triể n phầ n mề m lấ y kiể m thƣ̉ làm tro ̣ng tâm ; đƣa ra các khái niê ̣m và quy triǹ h thƣ̣c hiê ̣n của phƣơng pháp phát triể n dƣ̣a vào kiể m thƣ̉ (TDD) và phƣơng pháp phát triển dựa vào kiểm thử chấp nhận (ATDD). Phầ n này cũng nêu lên mô ̣t số hạn chế của các kỹ thuật này.  Nghiên cƣ́u phƣơng pháp phát triể n phầ n mề m hƣớng hành vi . Đây là mô ̣t phƣơng pháp mới , chƣa đƣơ ̣c áp du ̣ng phổ biế n trong sản xuấ t phầ n mề m . Tuy nhiên, thông qua nghiên cƣ́u của miǹ h tôi thấ y đây là mô ̣t kỹ thuâ ̣t hay, có thể áp dụng rộng rãi , vì thế trong phần này , tôi trình bày nhƣ̃ng kiế n thƣ́c cơ bản nhấ t -4về phƣơng pháp phát triể n phầ n mề m dƣ̣a vào hành vi của ƣ́ng du ̣ng nhƣ : nguyên lý , quy trình, các sản phẩm cũng nhƣ công cụ hỗ trợ ;chú trọng trình bày dạng thức mô tả yêu cầu ứng dụng dƣới dạng một tính năng ; định dạng mô tả tính năng, các kịch bản sƣ̉ du ̣ng tiń h năng, cũng nhƣ mô tả các tiêu chí kiểm thử chấ p nhâ ̣n thông qua các bƣớc của kịch bản.  Nghiên cƣ́u công cu ̣ Behat :Trình bày chi tiết về các h cài đặt , cấ u hình , kiế n trúc và cách thƣ́c sƣ̉ du ̣ng công cu ̣ này ;mô tả cách sử dụng ngôn ngữ Gherkin để viế t tin ̣ nghiã các tiêu chí kiể m thƣ̉ chấ p nhâ ̣n nhƣ là các ́ h năng, đinh bƣớc của kich ̣ bản ; Cách định nghĩa phƣơng thức kiểm thử chấp nhận trong lớp ngƣ̃ cảnh.  Áp dụng những nghiên cứu về phát triển phần mềm hƣớng hành vi và công cụ Behat để xây dựng ứng dụng minh họa: giới thiê ̣u công cu ̣ và kỹ thuâ ̣t hỗ trơ;̣ mô tả ƣ́ng du ̣ng và các bƣớc xây dƣ̣ng ƣ́ng du ̣ng ; tổ ng kế t, đánh giá viê ̣c áp dụng. Cấ u trúc của luâ ̣n văn gồ m bố n phầ n nhƣ sau:  Chƣơng 1 –Kiểm thử phần mềm trong Agile:Trình bày các khái niệm cơ bản , một số quy trình phát triển phần mềm theo phƣơng pháp phát triển linh hoạt; Mục đích, tầm quan trọng, các loại hình kiểm thử trong phƣơng pháp phát triể n linh hoạt.  Chƣơng 2 – Phát triển phần mềm theo hƣớng hành vi – BDD: Trình bày khái niệm, quy trình và một số kiến thức liên quan đến phát triển phần mềm hƣớng hành vi.  Chƣơng 3 – Công cụ Behat: Giới thiệu công cụ Behat và các thành phần liên quan.  Chƣơng 4 - Áp dụng phát triển phần mề m hƣớng hành vi và công cu ̣ Behat:Vâ ̣n du ̣ngphát triển phần mềm hƣớng hành vi và sử dụng công cụ Behat để xây dựng ứng dụng minh họa. -5- CHƢƠNG 1. KIỂM THỬ TRONG PHƢƠNG PHÁP PHÁT TRIỂN PHẦN MỀM LINH HOA ̣T 1.1. Mô hình phát triển lặp trong phƣơng pháp phát triển linh hoạt Phƣơng pháp phát triển phần mềm theo nguyên lý lặp đã xuất hiện nhiều năm nay [1], biểu hiện trong mô hình xoắn ốc hay mô hình phát triển phần mềm theo bản mẫu. Tuy nhiên, thƣ̣c tế các mô hình đó ít đƣợc áp dụng và chƣa đem lại hiệu quả cao. Những năm gần đây, các phƣơng pháp phát triể n phầ n mề m hoạt động theo nguyên lý lặp đƣợc áp dụng phổ biến và đem lại những lợi ích to lớn cho ngành công nghiệp phần mềm, đó là nhóm các mô hình phần mềm trong phƣơng pháp phát triển phần mềm linh hoạt (còn gọi là phƣơng phápAgile)[4]. Theo mô hình phát triển lặp, phần mềm sẽ đƣợc hoàn thiện dần thông qua nhiều vòng lặp, mỗi vòng lặp tạo ra một phiên bản phần mềm tích hợp dần các chức năng để hoàn thiện hệ thống. Sử dụng phƣơng pháp này, hệ thống tăng trƣởngthông qua việc tích hợp thêm các tính năng mới hoặc cải thiện tính năng cũ qua từng vòng lặp. Khách hàng đƣa ra các tính năng của phần mềm, đồng thời đánh giá độ ƣu tiên của mỗi tính năng và thông qua đó đội phát triển sẽ đƣa các tính năng vào các vòng lặp và xác định điểm khởi tạo của mỗi vòng lặp để thực hiện dự án. Trong các quy trình phát triển phần mềm theo nguyên lý lặp nhƣlập trình cực hạn (eXtreme Programming viết tắt là XP)[4]hay quy trình Scrum[3] thì mỗi vòng lặp thƣờng đƣợc triển khai từ 2 – 6 tuần để thực hiện các tính năng có liên quan với nhau nhằm tạo ra một phần hoàn thiện của hệ thống[2]. Mỗi vòng lặp nhƣmột dự án thu nhỏ, đƣợc tiến hành đầy đủ các pha nhƣ lập kế hoạch, phân tích, thiết kế, cài đặt, kiểm thử và triển khai nhƣ Hình 1-1. Hình 1-1. Mô hình phát triển lặp Phƣơng pháp phát triển phần mềm linh hoạt Agile là phƣơng pháp phát triển phần mềm hiện đại nhất và đƣợc áp dụng rộng rãi trong các công ty phần mềm hiện nay. Nhân tố chính của phƣơng pháp phát triển linh hoạt là “lặp”, mặc dù không có định nghĩa cụ thể cho phƣơng pháp này [4]nhƣng mục đích của các quy trình phần mềm theo Agile là phát triển phần mềm có chất lƣợng cao trong giới hạn tài nguyên cho phép. Phƣơng pháp phát triể n phầ n mề m linh hoạt Agile đảm bảo phần mềm thành công bằng việc đƣa nhân tố ngƣời sử dụng tham gia -6vào dự án để phần mềm sau khi hoàn thiện đáp ứng đúng các tiêu chí kiểm thử chấp nhận. Có nhiều quy trình phát triển phần mềm dựa trên các nguyên lý của phƣơng pháp Agile, chẳng hạn nhƣ quy trình tinh gọn (Learn Software Development), quy trình Kaban, quy trình Scrum hay lập trình cực hạn XP, … . Các quy trình này có các thuộc tính, quy định, cũng nhƣ cách làm việc khác nhau, nhƣng chúng đều là các quy trình phát triển phần mềm theo nguyên lý lặp. Những năm gần đây, các quy trình phần mềm trong nhóm phƣơng pháp phát triển linh hoạt Agile đƣợc sử dụng phổ biến và mang lại nhiều thành công cho các công ty phần mềm, trong đó hai quy trình đƣơ ̣c áp du ̣ng rô ̣ng raĩ nhấ t đó là quy trình Scrum và lập trình cực hạn XP. 1.1.1. Quy trin ̀ h Scrum Thuật ngữ“Scrum”đƣợc trình bày lần đầu tiên trong bài báo của Takeuchi và Nonakavào năm 1986 [3]vềkhả năng thích nghi, nhanh chóng, tính tự tổ chức trong việc phát triển phần mềm. Thuật ngữ “Scrum” có nguồn gốc từ một chiến thuật trong môn bóng bầu dục ám chỉ việc đƣa bóng vào cuộc.Kent Schwaber lần đầu tiên mô tả về phƣơng pháp Scrum vào năm 1996, là một quá trình chấp nhận và phát triển các yêu cầu chƣa đƣợc xác định trƣớc. Nguyên tắc của phƣơng pháp Scrum là phát triển một phần mềm bằng việc gia tăng dần viê ̣c cài đă ̣t các yêu cầu phầ n mề m . Phầ n mề m thƣờng xuyên đƣơ ̣c bàn giao cho khách hàng theo hƣớng bổ sung thê m các tính năng mới hoă ̣c cải thiê ̣n các tính năng của phiên bản trƣớc theo đúng yêu cầ u của khách hàng . Scrum làm viê ̣c theo quy trình lă ̣p , mỗi vòng lặp gọi là một Sprint thƣờng có một khoảng thời gian cố định khoảng từ 2 đến 4 tuần. Cách thức làm việc của từng vòng lặp mô tả nhƣHình 1-2[3]. Mô ̣t dƣ̣ án phầ n mề m áp dụng quy trình Scrum thƣ ờng đƣợc cài đặt theo các bƣớc sau [3]: Bƣớc 1: Thu thập các đặc điểm của sản phẩm. Các đặc điểm của sản phẩm hay còn gọi là các yêu cầu đƣợ c thu thâ ̣p thông qua cuô ̣c trao đổ i với khách hàng , các yêu cầu đƣợc tập hợp lại thành tập yêu cầ u sản phẩm (product backlog). Đây là bƣớc quan trọng nhất, quyế t đinh ̣ sƣ̣ thành công của dự án . Ở bƣớc này , ngƣời quản lý dƣ̣ án cũng thành lập các đội làm việc, các đội này thƣờng xuyên thảo luận với nhau về nghiệp vụ cần làm và bổ nhiệm một ngƣời vào vị trí chủ sản phẩm (Product owner), ngƣời này có khả năng trao đổi, bao quát công việc tốt, biết sắp xếp đô ̣ ƣu tiên cho cá c nhiê ̣m vu ,̣ -7cho các công viê ̣c . Sau đó tự tổ chức lại đội làm việc, đề xuất ra vị trí Scrum master và thảo luận chi tiết các yêu cầu, sắp xếp chúng theo thứ tự ƣu tiên. Các vai trò và sản phẩ m của Scrum đƣơ ̣c triǹ h bày chi tiế t ở các phầ n sau. Hình 1-2. Quy triǹ h Scrum Bƣớc 2: Ƣớc lƣợng các yêu cầu về sản phẩm đầu ra. Bƣớc này còn go ̣i là bƣớc ƣớc lƣợng các yêu cầu ở mức độ cao:Chia sản phẩm thành mô ̣t số danh mục backlog , số lƣơ ̣ng danh mu ̣c có thể đƣơ ̣c điề u chỉnh, bổ sung trong quá trin ̀ h phát triể n ; Ƣớc lƣợng chi tiết từng backlog, ƣớc lƣợng số lƣợng các đội làm việc, … Bƣớc 3: Lên kế hoạch phát triển các vòng lặp Sprint. Thông qua các cuộc trao đổi kế hoạch phát triển Sprint với tất cả các thành viên để xác định chi tiết của Sprint . Giai đoa ̣n này cũng xác địnhmục tiêu của Sprint là gì, sẽ đạt đƣợc gì, phân tích các yêu cầu của Sprint một cách rõ ràng. Bƣớc 4: Lên kế hoạch phát triển các tác vu ̣ của Sprint. Đầu tiên, đô ̣i dƣ̣ án sẽ ho ̣p la ̣i để xác định ngân sách của Sprint đó, sau đó chia các đặc điểm thành các tác vụ nhỏ hơn, ƣớc lƣợng thời gian sẽ làm từng tác vụ, hoàn tất các yêu cầu và nhận dạng tác vụ quan trọng. Bƣớc 5: Tạo ra không gian làm việc cộng tác cho tất cả mọi ngƣời. Môi trƣờng làm viê ̣c là yế u tố quan tro ̣ng trong viê ̣c áp du ̣ng quy trình Scrum; Các thành viên tự chịu trách nhiệm cho các tác vụ của mình và có sự -8giao tiế p với các thành viên khác khi cần thiết. Với hê ̣ thố ng phát triể n theo quy trình Scrum, quá trình làm việc đội dự án thƣờng sử dụng bảng trắng để nêu những vấn đề cần thiết cho tất cả mọi ngƣời cùng đánh giá. Bƣớc 6: Các thành viên bắt tay xây dựng từng Sprint. Giai đoa ̣n này đô ̣i phát triể n t iế n hành các công viê ̣c l ập trình, kiểm thử và điều chỉnh thời gian để có hiệu quả tốt nhất. Khi thƣ̣c hiê ̣n mô ̣t Sprint không hiê ̣u quả hoă ̣c gă ̣p bế tắ c không giải quyế t đƣơ ̣c , các bên liên quan có thể điều chỉnh, hủy bỏ Sprint đó để quay lại pha lập kế hoạch. Bƣớc 7: Các thành viên báo cáo kết quả để tiếp tục làm việc. Trong Scrum, các thành viên thƣờng xuyên báo cáo công việc thông qua các cuộc họp ngắn. Các báo cáo tập trung vào các vấn đề: đạt đƣợc những gì so với lần trao đổi trƣớc; sẽ hoàn thành những gì trong lần trao đổi tiếp theo; có những trở ngại gì trong quá trình làm việc. Thông qua các báo cáo sẽ nhanh chóng giải quyết các vấn đề còn tồn đọng để tiếp tục công viê ̣c. Bƣớc 8: Tổng hợp kết quả trên biểu đồ. Với dƣ̣ án áp du ̣ng quy triǹ h Scrum, quá trình làm việc và tiến độ công việc sẽ thƣờng xuyên đƣợc cập nhật thông qua biểu đồ burn down . Đây là bức tranh tổng quát về những việc đã làm đƣợc, những việc chƣa làm đƣợc, thời gian ƣớc lƣợng còn lại, … . Biểu đồ burn down giúp cho ngƣời quản lý và đội phát triển biết tình hìnhphát triển dự án để nhanh chóng có những điều chỉnh cho phù hợp với thực tế. Bƣớc 9: Xem xét để hoàn tất. Mô ̣t ràng buô ̣c quan tro ̣ng nhấ t trong quy triǹ h Scrum là c ác thành viên tự chịu trách n hiê ̣m cho công viê ̣c của miǹ h . Khi các thành viên thông báo công việc đã hoàn thành có nghĩa là mọi thay đổi sẽ bị từ chối ở Sprint đó , nế u còn tồ n đo ̣ng sẽ đẩy lại cho vòng lặp sau. Bƣớc 10: Đánh giá, phản ánh và lặp lại. Các thành viên tham gia dự án t hƣờng xuyên có các cuộc họp đánh giá lại Sprint. Các cuộc họp tập trung vàokết quả đã đạt đƣợc , phản hồi của khách hàng, xem xét thời hạn thƣ̣c hi ện của Sprint. Thông qua biể u đồ burn down ở bƣớc 8 để xác định lại toàn bộ hệ thống và tiếp nhận những đóng góp, bổ sung để đƣa tiếp vào các vòng lặp Sprint tiếp theo. Quy trin ̀ h phát triể n phầ n mề m Scrum chia các bên liên quan thành các nhóm ngƣời riêng biệt và phân định quyền hạn cho mỗi nhóm. Viê ̣c chia nhóm -9nhằ m đảm bảo cho dƣ̣ án đƣơ ̣c thƣ̣c hiê ̣n mô ̣t cách trôi chảy và thôi thúc các thành viên tự chịu trách nhiệm cho công việc c ủa mình. Trong quy trình Scrum có các nhóm ngƣời dùng sau:  Chủ sở hữu sản phẩm (Product owner):Là mô ̣t ngƣời chịu trách nhiệm cho toàn dự án; quản lý, kiểm soát và thống kê các yêu cầu chƣa đƣợc thực hiện của cầu sản phẩm. Product owner đƣợc lựa chọn bởi nhƣ̃ng ngƣời lañ h đa ̣o nhóm, khách hàng và quản lý dƣ̣ án.  Trƣởng nhóm (ScrumMaster): Là ngƣời hỗ trợ đắc lực cho dự án, làm việc chặt chẽ với ngƣời chủ sở hữu sản phẩm.Ngƣời này có trách nhiê ̣m kiểm tra công việc của các thành viên và đảm bảo đội phát triển hoạt động năng suất, hiệu quả.  Đội phát triển (ScrumTeam): Là một đội tập trung khoảng từ 4 đến 10 thành viên có kinh nghiệm và có vai trò thiế t yế u trong một dự án. Đội phát triển có quyền quyết định những hoạt động cần thiết để đạt đƣợc mục tiêu của Sprint.  Khách hàng (Customer): Là những ngƣời t ham gia vào dƣ̣ án để thƣ̣c hiê ̣n các nhiệm vụ mô tả yêu cầ u nhằ m kiể m soát chấ t lƣơ ̣ng sản phẩ m .  Quản lý dƣ̣ án (Management): Là ngƣời q uyết định kết quả cuối cùng của dự án, tham gia vào việc thiết lập các yêu cầu. Việc phân chia các vai trò này nhằm mục đó gán trách nhiệm và quyền hạn cho mỗi nhóm ngƣời và yêu cầu vai trò đó phải tự chịu trách nhiệm cho công việc của mình. Chính sự quản lý chặt chẻ theo cấp bậc từ trên xuống dƣới tạo cho các bên liên quan đến dự án có thể làm việc theo ý của mình mà không đi lê ̣ch mục tiêu của vòng lặp là nhằm tạo sự hài lòng cho khách hàng. Trong quy trình Scrum cũng rất chú trọng đến việc giao tiếp giữa các bên liên quan để phát triển sản phẩm, nhằm tạo điều kiện cho các vòng lặp thực hiện một cách trôi chảy. Có một số hình thức họp bàn nhƣ sau: i. Họp lập kế hoạch cho Sprint (Sprint planning) Đội phát triển sẽ gặp gỡ với chủ sở hữu sản phẩm, ngƣời quản lý, khách hàng nhằm lên kế hoạch làm việc cho một Sprint. Cuô ̣c ho ̣p này giải quyế t c ác công việc nhƣ là: lựa chọn các yêu cầu cần phát triển, phân tích và nhận biết các công việc phải làm kèm theo các ƣớc lƣợng thời gian cần thiết để hoàn tất các công việc. Quy trin ̀ h Scrum sử dụng phƣơng thức lập kế hoạch từng phần và tăng dần theo thời gian. Theo đó, việc lập kế hoạch không diễn ra duy nhất một lần trong vòng đời của dự án mà đƣợc lặp đi lặp lại cho tƣ̀ng Sprint. -10Việc giao tiếp thƣờng xuyên giữa khách hàng, chủ sở hữu sản phẩm và ngƣời quản lý dự án sẽ giúp bổ sung các yêu cầu thiếu sót một cách liên tục và nhanh chóng làm rõ các yêu cầu đang tồn đọng, giúp đội phát triển luôn luôn thực hiện phần mềm đúng theo yêu cầu của khách hàng. Khi khách hàng có sự thay đổi yêu cầu, các bên cần phải thảo luận các lý do thay đổi, mục đích của việc thay đổi và kết quả của việc thay đổi nhằm phân tích xem sự thay đổi đó có cải tiến chất lƣợng sản phẩm hay không? Hay chúng có ảnh hƣởng tới phầ n hê ̣ thố ng đã phát triể n hay không? ii. Họp hằng ngày (Daily Scrum) Mỗi ngày, toàn đội sẽ tập trung trong vòng 15 phút vào đầu buổi sáng để tổng kết công việc ngày hôm qua, kế hoạch công việc sẽ làm trong ngày hôm nay và kiểm tra các tình huống có thể cản trở công việc trong ngày đó. Các vƣớng mắc về mặt kỹ thuật, cũng nhƣ về mặt nghiệp vụ sẽ đƣợc giải quyết một cách nhanh chóng để toàn đội phát triển có thể tiếp tục công việc của mình. iii. Họp đánh giá (Sprint Review) Cuối mỗi Sprint, đội phát triển cùng với chủ sở hữu sản phẩm sẽ rà soát lại các công việc đã hoàn thành trong Sprint đó và đề xuất các chỉnh sửa hoặc thay đổi cần thiết cho sản phẩm. iv. Họp cải tiến (Sprint Retrospective) Dƣới sự chỉ đạo của đô ̣i trƣởng, toàn đội phát triển sẽ rà soát lại toàn diện Sprint vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng nhƣ sản phẩm đƣợc tạo ra từ Sprint đó. Việc kiểm tra sản phẩm thƣờng xuyên thông qua các cuộc họp giúp cho hê ̣ thố ng luôn phát triển đúng theo mục tiêu mà chủ sở hữu và khách hàng đề ra. Nếu quá trình thực hiện Sprint có vấn đề phát sinh thì nó sẽ đƣợc xem xét dƣới các góc độ kỹ thuật và về mặt nghiệp vụ để nhanh chóng giải quyết, đảm bảo phần mềm phát triển đúng tiến độ vàtạo ra sản phẩm có chất lƣợngcao. 1.1.2. Lập trình cực hạn Lâ ̣p trin ̀ h cƣ̣c ha ̣n(Extreme Programming viế t tắ t là XP) là một trong nhƣ̃ng phƣơng pháp phát triể n phầ n mề m hiê ̣n đa ̣i đƣợc sử dụng khá phổ biế n , do Martin Flower và Ron Jeffries đề xƣớng[2]. Phƣơng pháp này nhấn mạnh vào sự cộng tác giƣ̃a các thành viên liên quan tới dƣ̣ án nhằ m tạo ra phần mềm một cách nhanh chóng và dễ mở rộng trong quá trình thực hiện. Phƣơng pháp lâ ̣p trình cực hạn đƣợc cô đọng trong bốn nguyên tắc: sự trao đổi(communication), đơn giản hóa (simplicity), sự phản hồi (feedback), và sự dũng cảm (courage)[2]. -11Lâ ̣p trình cực hạn đƣơ ̣c đánh giá là quy trình phù hợp với các dự án khách hàng thƣờng xuyên thay đổi yêu cầu và mong muốn sớm nhận đƣợc sản phẩm từ ngƣời phát triển. Phƣơng pháp này khuyến khích các nhóm làm việc chung với nhau, bàn giao các phiên bản phần mềm chất lƣợng cao hơn các phƣơng pháp truyền thống. Phƣơng pháp lâ ̣p trin ̀ h cƣ̣c ha ̣n đă ̣t ra mô ̣t tâ ̣p các quy tắc và các thực hành giúp ngƣời lập trình mô tả chi tiết các hoạt động. Vòng đời của dƣ̣ án phầ n mề m phát triển bằng lập trình cực hạn XP gồm có các pha: khảo sát, lập kế hoạch,lặp để phát hành,sản xuất, bảo trì và kết thúcnhƣHình 1-3[2]. Hình 1-3. Vòng đời của dự án XP Các dự án sử dụng lâ ̣p triǹ h cƣ̣c ha ̣n XP sẽ bắt đầu với một tập yêu cầu đƣợc gọi là tâ ̣p câu chuyện ngƣời dùng. Các câu chuyện ngƣời dùng đƣợc viết bởi khách hàng và đƣợc sắp xếp theo độ ƣu tiên. Lập trình cực hạn XP là quy trình phát triển lặp, thông qua các vòng lă ̣p , phần mềm thƣờng xuyên đƣợc tích hợp thêm các tính năng mới hoă ̣c cải thiê ̣n tiń h năng đã có; Cuối mỗi vòng lặp sản phẩm sẽ đƣợc kiểm thử chấp nhận bởi khách hàng, nếu phiên bản đó đáp ứng các tiêu chí kiểm thử chấp nhận thì các phần chức năng vừa đƣợc tiến hành trong vòng lặp đó sẽ đƣợc tích hợp thêm vào hệ thống mới, ngƣợc lại sẽ phải bổ sung hoặc chỉnh sữa các yêu cầu để đƣa vào vòng lặp tiếp theo. Với dƣ̣ án áp dụng lập trình cực hạn , hệ thống đƣợc phát triển theo đúng yêu cầu của khách hàng. Một vòng lặp không mang lại lợi ích cho khách hàng thì các tính năng của vòng lặp đó sẽ sớm đƣợc loại bỏ hoặc cải thiện theo hƣớng tốt hơn. 1.2. Kiểm thử trongphƣơng pháp triển linh hoạt -12Để dự án phát triển theo phƣơng pháp phát triển linh hoạt Agile thành công thì kiểm thử đóng vai trò rất quan trọng. Ở đây, việc kiểm thử không đơn thuần là kiểm tra tính đúng đắn của mã nguồn phần mềm so vớitài liê ̣u đặc tả yêu cầ u . Chìa khóa quan trọng nhất vẫn là sự giao tiế p giữa thành phần phát triển dự án và ngƣời kiểm thử. Trong các quy triǹ h phát triể n phầ n mề m của phƣơng pháp phát triển linh hoạt ,kiểm thử viên tham gia vào dự án và kiểm thử phần mềm ngay cả khi hệ thống chƣa hoàn thiện. Việc kiểm thử sớm nhằm tăng độ tin cậy của quá trình phát triển phần mềm. Chẳng hạn trong lâ ̣p trình cƣ̣c ha ̣n XP, độ tin cậy đƣợc xây dựng dựa trên hai mức kiểm thử: kiểm thử đơn vị thông qua quá trình sử dụng phƣơng pháp phát triển phần mềm theo hƣớng kiểm thử TDD và kiểm thử chấp nhận. Kiểm thử đơn vị để đảm bảo các yêu cầu của hệ thống làm việc đúng và kiểm thử chấp nhận để đảm bảo rằng chƣơng trình đúng đã đƣợc cài đặt phù hợp với yêu cầu khách hàng . Trong quy trình Scrum thì khái niệm kiểm thử tích hợp và kiểm thử chấp nhận không đƣợc nêu rõ, vì thế các cá nhân trong đội phát triển sẽ xác định các vấn đề liên quan đến kiểm thử và tự chịu trách nhiệm cho các chức năng do miǹ h thƣ̣c hiê ̣n. Kiểm thử trong phƣơng pháp phát triển linh hoạt cònthể hiện qua việc xây dựng một quy cách làm việc nhằm đảm bảo chất lƣợng phần mềm. Trong phƣơng pháp phát triể n linh hoa ̣t, việc đảm bảo chất lƣợng sản phẩm đƣợc thực hiện bởi tất cả thành viên tham gia vào dự án. Các lập trình viên thực hiện kiểm thử đơn vị và kiểm thử tích hợp. Đại diện khách hàng kiểm tra công việc của lập trình viên và trợ giúp họ bằng cáckiểm thử của khách hàng. Khi các kiểm thử viên tìm ra lỗi, cả đội cùng nhau phân tích nguyên nhân và tìm cách cải tiến quy trình để ngăn ngừa lỗi tái diễn.Sƣ̉ du ̣ng các quy triǹ h trong phƣơng pháp này việc phát triển phần mềm thƣờng gắn liền với công cu ̣ kiể m thƣ̉ tƣ̣ đô ̣ng để hỗ trơ ̣ kiể m thƣ̉ hồ i quy hê ̣ thố ng mô ̣t cách nhanh chóng, chính xác. Các kiểm thử hồi quythƣờng đƣợc thực hiện bởi các lập trình viên khi họ tích hợp thêm mã nguồn mới vào hệ thống; phƣơng pháp l ập trình theo cặp cũng góp phần nâng cao chất lƣợng công việc. Sƣ̉ du ̣ng phƣơng pháp phát triể n linh hoa ̣t, các mức kiểm thử thƣờng chồng chéo lên nhau để đảm bảo các phần của hệ thống làm việc đƣợc phát hành liên tục. Không giống nhƣ trong kiểm thử truyền thống, cái khái niệm về các mức kiểm thử cũng có sự thay đổi. Trong lâ ̣p triǹ h cƣ̣c ha ̣n XP thì kiểm thử đƣợc chia theo hai mức đơn giản là kiểm thử đơn vị và kiểm thử chấp nhận, còn trong quy trình Scrum thì không có khái niệm rõ ràng cho các mức kiểm thử. Tuy nhiên có thể tạm chia kiểm thử thành các mức nhƣ sau: