Chuyển đến nội dung chính

Định nghĩa của ISTQB về tester trong mô hình phát triển phần mềm Agile

Định nghĩa của ISTQB về tester trong mô hình phát triển phần mềm Agile.

Bài dịch từ đại cương của chuẩn ISTQB về mô hình phát triển phần mềm.

1. Thế nào là mô hình phát triển phần mềm Agile?

a. Nền tảngcủa Agile
Vào năm 2001, một nhóm cá nhân độc lập đã thuyết trình một phương thức phát triển phần mềm mới, nhanh gọn và họ đồng ý với tuyên bố chung lập ra bốn nguyên tắc (như khẩu huyết) của mô hình phát triển Agile:
1) Cá nhân và cộng tác còn hơn là quy trình và công cụ (tools - công cụ hỗ trợ đo lường, quản lý...).
2) Phần mềm chạy được còn hơn là tài liệu thông suốt.
3) Cộng tác với khách hàng còn hơn là đàm phán hợp đồng.
4) Nhận được các thay đổi còn hơn là vòng vòng theo kế hoạch.

Với 4 nguyên tắc trên từ đó nó được gọi là Bản tuyên ngôn của Agile. Sau đây là phân tích và diễn giải ý nghĩa.

1) Cá nhân và cộng tác

Agile là mô hình hướng con người làm trung tâm, đòi hỏi các cá nhân phải cộng tác liên tục: giao tiếp, trao đổi... hơn là nói chuyện qua email, phần mềm chat chít quy trách nhiệm thì nhiều mà năng xuất thì kém.

2) Phần mềm chạy được

Cái mục đích cuối cùng của khách hàng là có phần mềm để chạy cả ngàn trang tài liệu dài hiệu quả không bằng một chức năng làm việc được. Với định hướng này hơi thực dụng nhưng có thể thấy rằng nó giúp cải thiện hiệu quả làm việc của phần mềm và có thể giúp tiến hóa chức năng hình ảnh trên phần mềm. Cho khách hàng thấy cái mà mình muốn là giúp họ định hình tốt hơn về ý muốn của mình.

3) Cộng tác với khách hàng 

Khách hàng là thượng đế, hợp đồng dĩ nhiên là quan trọng cứ ký kết bình thường nhưng cộng tác nhiều hơn vì họ sẽ cho ra nhiều vấn đề, kinh nghiệm và giải pháp hơn ta tưởng. Mặc khác việc cộng tác cho ta cơ hội hiểu rõ hơn người khách hàng đang muốn gì hơn là bước đi trong đêm tối với một ngọn đèn mang tên 'Hợp đồng'.
Tự luận: Trở lại trường hợp một công ty làm sản phẩm phần mềm chưa có trên thị trường có cái gì gọi là khách hàng? - Ông sếp hay người dùng sử dụng phần mềm là khách hàng? Ta sẽ cộng tác với ai? - Cộng tác với ông sếp, và chính những người làm, họ cũng là khách hàng trong tương lai.

4) Nhận được các thay đổi

Các thay đổi yêu cầu là việc thường xuyên xảy ra trong quá trình phát triển phần mềm. Và tốt nhất khi ta nhận được càng sớm để làm việc thì còn hơn là cứ vòng vòng theo đuôi mãi kế hoạch (trong tương lai) mà không bao giờ đạt đến.


Nhận xét

Bài đăng phổ biến từ blog này

Hướng dẫn test negative (Test tiêu cực, test không hợp lệ, test ngược ...)

Hướng dẫn test negative Link tham khảo: Guru99.com Test tiêu cực - Dịch chuối quá - nên mình quyết định dùng từ gốc là: Negative testing. Bài hướng dẫn sẽ gồm các phần sau: Định nghĩa - Negative testing là gì. (What) Negative testing có quan trọng không? (Is) Làm như thế nào? (How) Ưu và nhược điểm! (Pros. & cons.) Định nghĩa negative testing! Để đảm bảo hệ thống chạy trơn tru và ổn định, chúng ta chỉ test những trường hợp bình thường và hợp lệ là chưa đủ. Vì vậy, để đảm bảo hệ thống chạy có thể xử lý được những trường hợp ngoại lệ ta cần test thêm những ngữ cảnh không hợp lệ! (negative testing). Làm được việc này thì hệ thống sẽ có kinh nghiệm xử lý khi các ngữ cảnh này xảy ra bất thường. ví dụ:  Thực tế đời sống: Xe buýt chở được 20 người. Ta cho 20 người cho xe chở bình thường. Nhưng chuyện gì sẽ xảy ra nếu nó chở 21 hoặc 30 người? Xe bị đổ, nghiêng, lún, lái khó ...=> Đây là negative case. Phần mềm: Email field có thể chứa đến 50 ký tự => Đ...

Bảy nguyên tắc cơ bản của Kiểm thử phần mềm

Nội dung: nói và diễn giải về bảy nguyên tắc cơ bản trong testing software. Bài này là bài lý thuyết bổ sung và tester phải nắm được nằm lòng các nguyên tắc này! Bảy nguyên tắc (như khẩu huyết trong võ công): Kiểm thử tất cả mọi trường hợp là không thể được. ( EXHAUSTIVE testing is not possible ). Giải thích như sau: Một form có textbox cho phép nhập từ 1 -> 1.000.000.000.000. Nếu để kiểm thử nhập liệu cho textbox này ta phải kiểm thử 1k tỷ lần. Mỗi thao tác nhập cho là 1 giây, và phép toán kiểm tra nhập liệu là 0.1 giây nữa thì ta phải mất xấp xỉ 1k tỷ giây là khoảng 31k năm để thực thi nó. Đời người chỉ khoảng một trăm năm, vậy phải mất cả mấy nghìn đời để thực thi kiểm tra một textbox mà chưa kể đến nhiều đối tượng khác cho nên mới nói điều này là không thể làm được! (Chi phí nuôi nghìn người và giá trị bỏ ra là không xứng). Để xử lý thì ta: dùng kỹ thuật phân vùng tương đương, Phân nhánh nghiệp vụ, chia lớp xử lý... (Sẽ nói chi tiết sau). Kiểm thử là chỉ ra sai sót đang có ...

Hướng dẫn cơ bản về chẩn đoán mã lỗi OBD 2 trên ô tô

OBD2 - DTCs    1) Diagnostic Trouble Code (DTC) là gì? DTC hay còn gọi là mã lỗi là những mã được lưu trữ trong máy tính của xe hơi. Mỗi xe hơi hiện đại từ 1994 trở đi đều được trang bị một hộp đen có chứa máy tính, máy tính này có nhiệm vụ chẩn đoán tình trạng hiện tại của xe nhằm đảm bảo xe được vận hành an toàn không gây nguy hiểm cho người sử dụng (Ví dụ: nếu máy tính này phát hiện thắng xe đang có lỗi nó sẽ cảnh báo và không cho người dùng sử dụng xe). Mỗi mã được lưu trữ mang một ý nghĩa nhất định và chỉ ra nơi đang gặp vấn đề trong xe. Kỹ sư ô tô dựa vào đó để tìm và sửa lỗi. Mã lỗi này có thể đọc được bằng cách dùng thiết bị đọc mã lỗi do các bên thứ ba phát hành. Hiện tại trên thị trường có rất nhiều loại thiết bị đọc mã lỗi với các tính năng khác nhau. 2) DTC có đáng tin cậy không? Câu trả lời là: Có và không! Có vì nó chỉ ra những mã lỗi một cách dã chiến nhất theo ý hiểu của máy tính (Cá nhân tôi gọi là ngu ngốc). Ví dụ: nếu một bộ phận cảm biến nà...