Kiểm thử phần mềm là một phần của quy trình phần mềm và nó cũng ảnh hưởng theo theo quy trình phát triền phần mềm đã chọn
( Xem thêm, sự liên quan giữa Kiểm thử phần mềm và quy trình phần mềm )1) Đặt vấn đề :
Có rất nhiều quy trình phần mềm được đưa ra và áp dụng , nhưng nhìn chung, vẫn có những hạn chế . Nhất là về mặt thời gian . Một trong những ám ảnh lớn nhất của PM, Dev, QC... chính là vấn đề deadline, phải OT (Overtime) điên cuồng để chạy theo tiến độ dự án tuy nhiên kết quả không khả quan và thường xuyên bị thất bại.Một trong những nguyên nhân chính cho sự việc trên đó là việc khách hàng thường xuyên thay đổi yêu cầu , ảnh hưởng đến một phần hoặc toàn bộ hệ thống , phải thay đổi và lập lại kế hoạch cho quy trình kế tiếp. Khiến cho sản phẩm bàn giao không đúng thời hạn . Vậy vấn đề cấp bách nhất đó chính là hạn chế sự thay đổi quá trình phát triền , vì mọi sự thay đổi sẽ kéo dài thêm thời gian cho dự án, gây mệt mỏi và tốn kém.
2) Giải quyết vấn đề:
Đưa cho khách hàng những gì họ cần một cách nhanh nhất, cấp tốc nhất để họ " không kịp trở tay, không có thời gian suy nghĩ để " đổi chát" , thêm bớt hoặc thay đổi giúp họ quyết đoán hơn với sự lựa chọn ban đầu . Đó chính là cốt lỗi của quy trình phát triền tinh gọn mà ta cùng tìm hiểu dưới đây .3) Tìm hiểu quy trình phát triền tinh gọn
Hạn chế lãng phí một cách tối đa chính là giá trị cốt lỗi mà quy trình phát triền phần mềm tinh gọn hướng tới giúp chúng ta đạt được lợi nhuận tối đa từ phía khách hàng và khách hàng có được những gì họ mong muốn.Ví dụ như :
- Khách hàng yêu cầu : Anh cần tôi làm 1 cuốn tập, bìa gỗ , hình tam giác , 32 trang, chất liệu giấy trắng, tốt , ngoài bìa có dòng chữ " Học kiểm thử phần mềm" , sau sách có lời cảm ơn và một vài hình ảnh vui nhộn cho phần phụ lục .
- Nhân viên phân tích những rủi ro mà khách hàng có thể thay đổi :
- Bìa gỗ ư , gỗ gì , sơn màu gì , to nhỏ, mỏng dày như thế nào ?
- Hình tam giác đều , tam giác cân hay tam giác vuông ?
- 32 trang là cả phụ lục, giới thiệu hay không ?
- Giấy trắng, tốt ấy dày hay mỏng , muốn có ô ly hay không kẻ ô ly , nếu kẻ ô ly thì theo Style nào ?
- Dòng chữ " Học kiểm thử phần mềm" ghi hoa hay thường, canh giữa hay canh trái, canh phải , Style chữ là gì ....?
Sau khi hỏi xong, có câu trả lời là tiến hành làm ngay, trong quá trình làm không thêm hỏi thêm những phần khác làm khách hàng phân tâm và bắt đầu " đòi hỏi" . Kết thúc công việc và bàn giao với những mục nó đã yêu cầu. Nhận lấy tiền và kết thúc dự án. Không để Khách hàng có cơ hội so sánh quyển tập này với quyển tập khác rồi thay đổi yêu cầu. Xây dựng nguyên tắc cho thời điểm đưa ra quyết định , hạn chế lãng phí từ tiến trình .
Một số công ty đã áp dụng quy trình này và đạt thành công vang dội như Microssoft với việc thay đổi hệ điều hành Hoặc IBM với việc cho ra mắt hệ quản trị cơ sở dữ liệu DB2...
4) Quy tắc vàng của quy trình phát triển phần mềm tinh gọn
- Thứ nhất là hạn chế lãng phí : Mọi thứ không tăng thêm giá trị cho khách hàng được gọi là lãng phí , bao gồm :- Mã nguồn và chức năng không cần thiết
- Sự chậm trễ trong quá trình phát triền
- Yêu cầu mơ hồ, không rõ ràng
- Kiểm thử để lặp lại quá trình có thể tránh được
- Những phần việc chưa hoàn chỉnh như Tạo tài liệu, tạo testcase ...
- Những chức năng mở rộng
- Overload thời gian khi bị giao quá nhiều việc trong 1 thời điểm
- Thời gian chờ ( Chờ file thiết kế, chờ bản phân tích, chờ Q&A ( question and Answer)
- Thời gian chuyển giao sản phẩm ( chuyển giao và feedback)
- Defect - những lỗi không được tìm thấy trong quá trình kiểm thử
- Thứ 2 Nâng cap kiến thức :
Mỗi thành viên cần phải học hỏi nhiều nhất có thể để biết được mình làm gì là đúng với yêu cầu khách hàng đưa ra. Tuy nhiên, môi trường phát triển phần mềm không yêu cầu mọi thứ phải hoàn hảo, không yêu cầu chúng ta phải lên kế hoạch và chỉ làm việc theo kế hoạch, không yêu cầu phải thực hiện đúng ngay từ lần đầu tiên…
- Quy trình phát triển phần mềm tinh gọn tập trung vào việc tăng các phản hồi và rút ra bài học từ đó.
- Nguyên tắc thứ 3: Trì hoãn quyết định càng muộn càng tốt
Trì hoãn quyết định là nguyên tắc giúp cho các quyết định trở nên linh hoạt hết mức có thể trong thời gian cho phép trong các trường hợp chưa chắc chắn về yêu cầu khách hàng đưa ra
- Có rất nhiều cách để thực hiện nguyên tắc trên. Ví dụ như:
Chia sẻ từng phần thiết kế hoàn chỉnh
Tổ chức, hợp tác trực tiếp giữa các thành viên cùng mục đích
Xây dựng các yếu tố phát hiện ra thời điểm chính xác để đưa ra các quyết định
Xây dựng các yếu tố hạn chế thay đổi
Sử dụng các bộ kiểm thử tự động
- Thứ tư là Bàn giao nhanh
Càng phát hành sớm các gói sản phẩm, bạn càng nhận lại được nhiều phản hồi sớm hơn về sản phẩm, và chúng có thể được đưa vào các cải tiến trong các phân đoạn tiếp theo của quá trình phát triển. Phân đoạn càng ngắn thì quá trình học tập và giao tiếp càng hiệu quả.
Khách hàng thì luôn đánh giá cao việc chuyển giao nhanh chóng các sản phẩm chất lượng vì chúng
thường giúp gia tăng tính linh hoạt trong hoạt động của họ. Công ty có thể chuyển giao nhanh hơn tốc
độ thay đổi tư duy của khách hàng.
Thứ năm là Trao quyền quyết định cho nhom phát triển
Cách tiếp cận tinh gọn ủng hộ việc “tìm người giỏi và để cho họ làm công việc của riêng mình”, quy trình khích lệ, tìm lỗi, loại bỏ những trở ngại, và không quản lý vi mô. Công việc chính của các cấp quản lí không phải là chỉ cho các nhà phát triển những gì họ phải làm, mà chủ yếu lắng nghe họ, đưa ra các phân tích, lời khuyên và tìm kiếm các cải tiến. Với niềm tin “tất cả là ở con người”, Lean ủng hộ chủ trương động viên và khuyến khích để vươn cao hơn trong công việc của mình. Các nhà phát triển nên được trao quyền tiếp cận khách hàng, các lãnh đạo cung cấp hỗ trợ và giúp đỡ trong các tình huống khó khăn, cũng
Thứ 6: Xây dựng chất lượng
Nếu chúng ta muốn của bàn giao sản phẩm nhanh điều đó phụ thuộc vào việc phản hồi của khách hàng, nếu chúng ta muốn thỏa mãn yêu cầu của khách hàng một cách tối đa thì không thể coi nhẹ chất lượng sản phẩm
Thứ 7 , Có cái nhìn bao quát
Hệ thống phần mềm ngày nay không đơn giản là tổng gộp của các bộ phận, mà còn là sản phẩm của
sự tương tác giữa các thành phần đó. Vì vậy cần thiết phải tính đến các tác động toàn cục khi thực hiện các công việc tối ưu hóa cục bộ. Lỗi trong phần mềm có xu hướng tích lũy trong quá trình phát triển và có liên hệ chặt chẽ với nhau. Cần dừng lại và phân tích các triệu chứng bất ổn khi bắt gặp. Hãy truy nguyên gốc rễ vấn đề. Bằng cách phân rã các nhiệm vụ lớn thành các nhiệm vụ nhỏ hơn, và tiêu chuẩn hóa các giai đoạn phát triển khác nhau, nguyên nhân gốc rễ của các lỗi này cần được phát hiện và loại bỏ.
Tư duy Tinh gọn (Lean Thinking) phải được thấu hiểu bởi tất cả các thành viên của dự án, trước khi triển khai thực hiện trong một tình huống cụ thể, trong thực tế cuộc sống, suy nghĩ. “Hãy suy nghĩ lớn, hành động nhỏ, thất bại nhanh chóng, và học ngay tức thì”. Chỉ khi tất cả các nguyên tắc tinh gọn được tuân thủ đầy đủ, kết hợp với các triển khai phù hợp với môi trường làm việc, chúng ta mới có một cơ sở cho sự thành công trong phát triển phần mềm tinh gọn
-------------------------------
.jpg)
