Mô hình phát triển Agile nói chung, hoặc mô hình Scrum/Kanban nói riêng tập trung vào việc mang đến giá trị sử dụng cho ngƣời dùng. Đƣa sản phẩm đến môi trƣờng sản phẩm càng sớm càng tốt để mang lại lợi nhuận kinh doanh. [9]
- Đặc điểm của mô hình phát triển Agile
Do các đội tự tổ chức
Quy trình sản phẩm là một chuỗi các “Sprint”
Sản phẩm công việc đƣợc bàn giao thƣờng xuyên (tốt nhất là theo tuần hơn là theo tháng)
Các phƣơng thức Agile nhấn mạnh đến sự giao tiếp trực tiếp hàng ngày (có những cuộc họp hàng ngày, …).
+ Đồ nghề của Scrum
Product backlog: Một danh sách sắp xếp thứ tự tất cả những gì cần thiết của sản
phẩm. Danh sách có thể là các tính năng, chức năng, yêu cầu, cải thiện và sửa lỗi cần thiết để làm nên sản phẩm. Sự sắp xếp có thể dựa theo các giá trị nhƣ sự cần thiết, độ rủi ro, độ ƣu tiên, …
Sprint backlog: Là tập hợp các hạng mục Product backlog đƣợc lựa chọn để
phát triển trong sprint. Hiện thực hoá các mục tiêu này một cách chi tiết vừa đủ để những thay đổi về tiến độ công việc có thể nhìn thấy trong các buổi họp scrum hàng ngày và có thể hoàn thành tất cả trong một sprint.
Nhóm Scrum bao gồm:
- Product Owner: Chịu trách nhiệm tối đa hoá giá trị của sản phẩm và công việc
của nhóm phát triển, là ngƣời chủ yếu chịu trách nhiệm về việc quản lý Product backlog
- Nhóm phát triển: Gồm các chuyên gia làm việc để cho ra các phần tăng trƣởng
có thể phát hành đƣợc cuối mỗi sprint
- Scrum Master: Chịu trách nhiệm đảm bảo mọi ngƣời hiểu và dùng đƣợc Scrum
Các sự kiện Scrum:
Srpint là một khung thời gian thƣờng có thể 1 tháng hoặc ngắn hơn để tạo ra các phần tăng trƣởng của sản phẩm có thể phát hành đƣợc. Một sprint mới bắt đầu ngay khi sprint trƣớc khép lại.
Các sự kiện chính trong quy trình Scrum
- Họp kế hoạch sprint (sprint planning meeting): Họp để đƣa ra kế hoạch chi tiết
cho một sprint
- Họp Scrum hàng ngày (daily meeting): Cuộc họp này đóng khung khoảng 15
phút, để thanh tra công việc đã làm đƣợc sau cuộc họp lần trƣớc, có vấn đề gì phát sinh, dự báo những công việc sẽ đƣợc hoàn thành trƣớc buổi họp lần sau.
- Họp sơ kết sprint (sprint review): Đƣợc tổ chức khi kết thúc Sprint để rà soát lại
phần tăng trƣởng vừa làm xong trong sprint đó, và để thực hiện biện pháp thích nghi nếu cần.
- Họp cải tiến sprint (sprint retrospective): Cuộc họp này là cơ hội để nhóm
Vai trò của kiểm thử viên trong mô hình Scrum
Tham gia vào kế hoạch bàn giao của sprint
Hỗ trợ các lập trình viên kiểm thử đơn vị
Cộng tác với khách hàng và Product Owner để định nghĩa tiêu chuẩn chấp nhận sản phẩm
Cung cấp những phản hồi tích cực từ khách hàng
Phát triển kiểm thử tự động
Nói ra những gì nên đƣợc lựa chọn từ Product backlog cho sprint này để mang đến giá trị cho khách hàng và tạo ra hiệu năng cao hơn.
Ƣớc lƣợng thời gian cần để hoàn thành việc kiểm thử cho mỗi chức năng
Hiểu mục tiêu của sprint là gì?
Tham gia tất cả các cuộc họp để thông báo bạn đã kiểm thử gì, sẽ kiểm thử gì và bất cứ điều gì liên quan ảnh hƣởng đến chất lƣợng
Mang bất cứ Backlog chƣa đƣợc hoàn thành trong sprint hiện tại đến sprint tiếp theo
Chịu trách nhiệm cho việc phát triển các kịch bản kiểm thử tự động
Kiểm tra và báo cáo các kết quả kiểm thử cho khách hàng
Chỉ ra đƣợc điểm mạnh, điểm yếu của sprint hiện tại
Đƣa ra đƣợc những bài học kinh nghiệm 2.2. CHIẾN LƢỢC KIỂM THỬ PHẦN MỀM
Phát triển phần mềm một cách tự nhiên đƣợc chia theo nhiều mức để dễ dàng theo dõi lỗi, đảm bảo một nhánh của hệ thống, thành phần, một thƣ viện vẫn làm việc bình thƣờng, có thể tái sử dụng đƣợc phần mềm, tiết kiệm đƣợc thời gian và chi phí [6].
2.2.1. Kiểm thử đơn vị/ thành phần (Unit/Component Testing)
Nền tảng kiểm thử: Các tài liệu mô tả chi tiết về thành phần, thiết kế chi tiết, mã
(code)
Đối tượng kiểm thử: Các thành phần, các chƣơng trình, chuyển đổi dữ liệu/ các
chƣơng trình chuyển đổi, các mô-đun cơ sở dữ liệu
Mục tiêu kiểm thử: Tìm kiếm các lỗi và kiểm chứng rằng chức năng của các mô-
đun, chƣơng trình, hàm, thủ tục, đối tƣợng, các lớp, … của phần mềm đã đƣợc kiểm thử hết một cách riêng biệt trƣớc khi tích hợp hệ thống. Nó có thể đƣợc thực hiện độc lập, riêng biệt so với các thành phần khác của chƣơng trình, phụ thuộc vào ngữ cảnh của hệ thống và quá trình sản xuất phần mềm.
Các loại kiểm thử: Kiểm thử thành phần có thể bao gồm kiểm thử chức năng và phi
chức năng, chẳng hạn nhƣ hành vi của tài nguyên (ví dụ tìm kiếm sự rò rỉ của bộ nhớ) hoặc kiểm thử mức chịu tải cũng nhƣ kiểm thử cấu trúc (ví dụ quyết định độ bao phủ).
Kiểm thử đơn vị/ thành phần thường:
Chạy kiểm thử trên môi trƣờng phát triển
Sử dụng các stub, driver và simulator để thực hiện kiểm thử.
Thông thƣờng kiểm thử thành phần đƣợc thực hiện bằng cách kiểm tra trực tiếp trong các đoạn mã và đƣợc hỗ trợ bởi môi trƣờng phát triển, chẳng hạn nhƣ “unit test framework” hoặc công cụ debug.
Trong thực tế, kiểm thử thành phần thƣờng do lập trình viên thực hiện.
Nhiều lỗi thông thƣờng sẽ đƣợc sửa ngay khi họ phát hiện đƣợc, mà không cần theo dõi quản lý các lỗi này.
Một cách tiếp để kiểm thử thành phần là chuẩn bị và tự động hóa các trƣờng hợp kiểm thử trƣớc khi thực hiện lập trình. Điểu này đƣợc gọi là phƣơng pháp tiếp cận test-first (kiểm thử đầu tiên) hoặc là phát triển test-driven (kiểm thử theo định hƣớng). Phƣơng pháp tiếp cận này đƣợc lặp đi lặp lại ở mức cao, sau đó xây dựng và tích hợp các mẫu nhỏ của các mã lại với nhau, và thực hiện kiểm thử thành phần với bất kỳ các vấn đề và kết hợp chúng lại cho tới khi chúng vƣợt qua việc kiểm thử
2.2.2. Kiểm thử tích hợp (Intergration Testing)
- Nền tảng kiểm thử: Thiết kế phần mềm và hệ thống, kiến trúc phần mềm, các tiến
trình công việc (workflow), các ca sử dụng (use cases)
- Đối tượng kiểm thử: việc thực thi cơ sở dữ liệu của nhánh hệ thống (sub-system),
cơ sở hạ tầng, các giao diện (interfaces)
- Mục tiêu kiểm thử: Tìm kiếm lỗi trong giao diện giữa các thành phần, tƣơng tác
giữa các thành phần khác nhau trong hệ thống, giữa hệ thống tài liệu (file) và phần cứng, và giữa các giao tiếp của hệ thống.
- Các loại kiểm thử: Kiểm thử chức năng và phi chức năng (ví dụ nhƣ hiệu suất của
phần mềm) có thể đƣợc bao gồm trong kiểm thử tích hợp
- Các loại kiểm thử: Cả phƣơng pháp tiếp cận chức năng (functional) và cấu trúc
(structural) cũng có thể đƣợc sử dụng. Tại mỗi chặng tích hợp, các kiểm thử viên chỉ duy nhất tập trung vào việc tích hợp. Ví dụ, nếu họ tích hợp một mô-đun A với mô-đun B thì họ quan tâm tới việc kiểm tra giao tiếp giữa hai mô-đun này, không quan tâm đến chức năng của từng mô-đun riêng lẻ, chức năng này xem nhƣ đã hoàn thành sau khi thực hiện kiểm thử thành phần.
Mức kiểm thử tích hợp: Có thể có nhiều hơn một mức kiểm thử tích hợp và có
thể có kết quả khác nhau dựa trên các mục tiêu kiểm thử khác nhau.
Kiểm thử tích hợp thành phần: kiểm tra các tƣơng tác giữa các thành
phần của phần mềm, đƣợc tiến hành sau khi thực hiện kiểm thử thành phần
Kiểm thử tích hợp hệ thống: kiểm tra các tƣơng tác giữa các hệ thống khác nhau hoặc giữa phần cứng và phần mềm và có thể đƣợc tiến hành sau khi thực hiện kiểm thử hệ thống.
Các phương pháp tiếp cận tích hợp
Kiểm thử vụ nổ lớn (big-bang): Là một chiến lƣợc kiểm thử hệ thống tiến
hành một lần duy nhất khi đã phát triển toàn bộ các mô-đun và tích hợp thành một phần mềm hoàn chỉnh
Kiểm thử từ dưới lên (bottom-up): Các thành phần ở mức thấp nhất sẽ
đƣợc kiểm thử trƣớc, sử dụng các driver thích hợp để giả lập cho phần còn thiếu. Lặp lại quy trình thay thế các driver bằng các mô-đun cho đến khi thành phần ở đỉnh đƣợc thay thế và kiểm thử.
Kiểm thử từ trên xuống (top-down): Kiểm thử từ trên xuống sẽ bắt đầu từ
đỉnh, tức là kiểm thử với các mô đun ở mức cao trƣớc, sử dụng các stub để giả lập cho các mô đun thấp hơn. Lặp lại quy trình thay thế các stub bằng các mô đun thấp hơn theo từng nhánh cho đến mô đun cuối cùng.
2.2.3. Kiểm thử hệ thống (Sytem Testing)
- Nền tảng kiểm thử: Đặc tả chi tiết yêu cầu của phần mềm và hệ thống, các ca sử
dụng (use cases), bảng mô tả chi tiết chức năng, các báo cáo phân tích rủi ro
- Đối tượng kiểm thử: Hệ thống, hƣớng dẫn vận hành và sử dụng hệ thống, cấu hình
hệ thống
- Mục tiêu kiểm thử: Kiểm thử hệ thống liên quan đến việc tìm lỗi, các hành vi, các
chức năng, phản hồi của toàn bộ hệ thống/sản phẩm. Phạm vi kiểm thử sẽ đƣợc mô tả trong kế hoạch kiểm thử (test plan) ở mức tổng thể và/hoặc từng mức.
- Các loại kiểm thử: Kiểm thử hệ thống nên kiểm tra các yêu cầu chức năng, phi
chức năng nhƣ bảo mật, hiệu năng, tính hữu dụng, ... của hệ thống và các đặc tính chất lƣợng dữ liệu. Các kiểm thử viên cũng cần phải quan tâm đến các yêu cầu không có giấy tờ hoặc không đầy đủ giấy tờ.
- Trong kiểm thử hệ thống, môi trƣờng kiểm thử sẽ đƣợc thiết lập càng giống mục tiêu cuối cùng hoặc môi trƣờng sản xuất càng tốt để giảm thiểu rủi ro về vấn đề môi trƣờng mà chƣa đƣợc kiểm tra.
- Một nhóm kiểm thử viên độc lập có thể thực hiện việc kiểm thử ở mức hệ thống
2.2.4. Kiểm thử chấp nhận (Acceptance Testing)
- Nền tảng kiểm thử: Các yêu cầu ngƣời dùng, các yêu cầu hệ thống, các ca sử dụng,
các quy trình xử lý công việc, các báo cáo phân tích rủi ro
- Đối tượng kiểm thử: Kiểm tra các quy trình xử lý công việc trên hệ thống đã đƣợc
tích hợp đầy đủ nhất, các quy trình vận hành và bảo trì, các thủ tục ngƣời dùng (phân quyền dựa trên ngƣời dùng đăng nhập, …), các form (các màn hình nhập liệu, …), các báo cáo (các bản báo cáo nhƣ phiếu thu để in, báo cáo doanh thu, …)
- Mục tiêu kiểm thử: Mục tiêu của kiểm thử chấp nhận là xác nhận lại sự tin tƣởng vào hệ thống, các đặc tính thuộc về chức năng hoặc phi chức năng của hệ thống. Tìm kiếm lỗi không phải là trọng tâm chính của kiểm thử chấp nhận. Kiểm thử chấp nhận có thể đánh giá sự sẵn sàng của hệ thống để triển khai và sử dụng, mặc dù không nhất thiết phải là mức cuối cùng của việc kiểm thử. Ví dụ, một cuộc kiểm thử tích hợp hệ thống ở quy mô lớn có thể đƣợc thực hiện sau khi đã thực hiện kiểm thử chấp nhận đối với một hệ thống.
- Kiểm thử chấp nhận thƣờng là trách nhiệm của khách hàng hoặc ngƣời dùng của hệ thống
- Kiểm thử chấp nhận có thể xẩy ra vào một vài thời điểm khác nhau trong quy trình sản xuất phần mềm ví dụ nhƣ một sản phẩm phần mềm thƣơng mại có thể đƣợc thực hiện kiểm thử chấp nhận khi nó đƣợc cài đặt hoặc tích hợp.
- Việc thực hiện kiểm thử chấp nhận để kiểm thử tính tiện dụng của một thành phần có thể đƣợc hoàn thành trong lúc thực hiện kiểm thử thành phần.
- Việc kiểm thử chấp nhận để kiểm thử việc cải tiến chức năng mới có thể đƣợc thực hiện trƣớc lúc thực hiện kiểm thử hệ thống.
Có một số loại kiểm thử chấp nhận thông thường như sau:
Kiểm thử chấp nhận người dùng (User acceptance testing): thông thƣờng dùng
để kiểm tra tính phù hợp với ngƣời dùng của hệ thống, công việc này đƣợc thực hiện bởi ngƣời dùng của doanh nghiệp.
Kiểm thử chấp nhận hoạt động (Operational acceptance testing): chấp nhận hệ
thống bởi các quản trị viên hệ thống bao gồm:
+ Kiểm thử phần sao lƣu/ phục hồi hệ thống (backup/ restore system) + Khôi phục lại hệ thống sau khi có sự cố (disaster recovery)
+ Quản trị ngƣời dùng nhƣ phần quyền, … + Các nhiệm vụ bảo trì
+ Các nhiệm vụ tải dữ liệu và di chuyển dữ liệu + Kiểm tra các lỗ hổng bảo mật định kỳ
Kiểm thử chấp nhận hợp đồng và thỏa thuận (Contract and regulation
acceptance testing): kiểm thử chấp nhận hợp đồng đƣợc thực hiện với tiêu chí
chấp nhận một hợp đồng nâng cấp – phát triển phần mềm. Tiêu chí chấp nhận cần đƣợc xác định khi các bên thỏa thuận hợp đồng. Điều lệ chấp nhận thử nghiệm đƣợc thực hiện đối với bất kỳ quy định phải đƣợc dựa vào, chẳng hạn nhƣ quy định của chính phủ, pháp luật hoặc điều lệ an toàn.
Kiểm thử Alpha và Beta: Phát triển cho thị trƣờng đại chúng hoặc phần mềm
thƣơng mại (COTS), phần mềm thƣờng muốn nhận đƣợc phản hồi từ khách hàng tiềm năng hoặc khách hàng trong thị trƣờng của họ trƣớc khi sản phẩm phần mềm đƣợc đóng gói để thƣơng mại.
+ Kiểm thử Alpha: Đƣợc thực hiện tại nơi tổ chức phát triển, khách hàng tiềm năng và các thành viên của tổ chức phát triển đƣợc mời sử dụng hệ thống. Ngƣời phát triển hệ thống sẽ quan sát ngƣời sử dụng hệ thống để lƣu ý những vấn đề của hệ thống. Thực hiện Alpha cũng có thể đƣợc thực hiện bởi nhóm kiểm thử độc lập.
+ Kiểm thử Beta (Beta testing hoặc field testing): Đƣợc thực hiện bởi
khách hàng hoặc các khách hàng tiềm năng tại nơi của họ (khách hàng tải bản Beta và cài vào máy của mình rồi sử dụng). Ngƣời sử dụng gửi những hồ sơ về những sự cố của hệ thống tới tổ chức phát triển nơi mà khuyết tật đƣợc sửa.
2.2.5. Kiểm thử bảo trì (Maintenance Testing)
Hệ thống đƣợc xây dựng thƣờng đƣợc sử dụng cho nhiều năm, thậm chí cho nhiều thập kỷ. Trong suốt thời gian này, hệ thống và môi trƣờng vận hành thƣờng đƣợc sửa chữa, thay đổi hoặc đƣợc mở rộng. Kiểm thử đƣợc thực hiện trong suốt vòng đời này đƣợc gọi là “Kiểm thử bảo trì”.
Quá trình phát triển và kiểm thử cho hệ thống mới về cơ bản là không thay đổi cho mục đích bảo trì. Các bƣớc kiểm thử tƣơng tự sẽ đƣợc áp dụng, và phụ thuộc vào kích thƣớc và rủi ro của thay đổi đƣợc làm. Nhiều mức của kiểm thử đƣợc thực hiện ở giai đoạn kiểm thử bảo trì nhƣ kiểm thử thành phần, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận.
2.3. CÁC LOẠI KIỂM THỬ PHẦN MỀM
Kiểm thử phần mềm đƣợc chia theo nhiều loại để dễ dàng bao phủ đƣợc hết các trƣờng hợp kiểm thử, dễ dàng quản lý lỗi và sửa lỗi. Để phân loại kiểm thử phần mềm, có nhiều tiêu chí để phân loại chúng. Dựa trên tài liệu chuẩn kiểm thử quốc tế [6], kiểm thử phần mềm đƣợc phân loại dựa trên mục tiêu của kiểm thử. Theo tiêu chí này, phần mềm đƣợc phân thành 4 loại: Kiểm thử chức năng, kiểm thử phi chức năng, kiểm thử kiến trúc và kiểm thử hồi quy. Dƣới đây là nội dung chi tiết của những loại kiểm thử này, dựa trên mục tiêu của kiểm thử mà áp dụng loại kiểm thử một cách phù hợp.
2.3.1. Kiểm thử chức năng
Mục tiêu thứ nhất của kiểm thử là kiểm thử chức năng (Functional Testing), nó là việc kiểm thử các chức năng của một hệ thống hoặc thành phần hệ thống, tức là kiểm tra xem “nó làm gì?”. Cái này thƣờng đƣợc miêu tả trong đặc tả yêu cầu, trong