- Ở giai đoạn khởi điểm - phân tích yêu cầu (có thể do designer/developer hay khách hàng đưa ra), requirement của 1 software bao gồm: draft document, use cases... Giai đoạn này tester sẽ phối hợp với designer/developer review qua để phát hiện các sai sót hay vấn đề không phù hợp để hiệu chỉnh. Những lỗi được phát hiện trong quá trình này - gọi là Inception - thường được gọi là Review Defect.
- Giai đoạn kế tiếp - thường gọi là Elaboration - là giai đoạn hình thành requirement hoàn chỉnh, bao gồm tập hợp các Use Case, Design model, database model, non-technical document (mô tả các business rule khác), các document hỗ trợ việc theo dõi, đánh giá tiến độ của project cũng bắt đầu được hình thành. Giai đoạn này tester cũng phải đưa ra được Test Plan (kế họach test) ghi rõ những tiêu chí test, flatform, criteria.... Tất cả các document này cũng được những thành viên có liên quan review để tìm issue (Review Defect) và hoàn chỉnh với sự thỏa thuận với khách hàng. Sau đó developer thường sẽ phát triển 1 bản thử nghiệm (gọi là prototype hay demo) dựa trên 1 số use case, tester sẽ dựa trên đó test bản thử nghiệm và tìm ra các Testing Defect/Bug, các lỗi này sẽ được tập hợp thường kì, đánh giá độ nguy hiểm, khả năng sửa, ... để hỗ trợ đánh giá tính hiệu quả của product theo từng giai đoạn . Đồng thời thiết lập 1 hệ thống để lưu trữ các lỗi tìm được, mô tả rõ ràng để developer vào đó theo dõi và sửa.
- Sau đó, là giai đoạn phát triển thật sự sau khi hầu hết các document gần như hoàn chỉnh (ngoại trừ use cases cần hiệu chỉnh trong suốt chu trình sống của project). Giai đoạn này thường đươc gọi là Construction - nó sẽ được chia nhỏ làm nhiều giai đoạn con (phase hay iteration) để tiện cho việc quản lý và theo dõi, mỗi giai đoạn con sẽ cần hoàn thành 1 lượng use cases nhất định và cuối mỗi phase là 1 bản build của sản phẩm ( các bạn chú ý trong hầu hết các ứng dụng chuyên nghiệp chưa hoàn chỉnh thường trong phiên bản có ghi vd như: phiên bản 5.6 build xxxxxxxx ...định dạng các số xxx và ý nghĩa thế nào tùy thuộc người sản xuất). Tester sẽ dựa trên Test Plan, Use cases trong phase và 1 số qui định/chuẩn để thực hiện test trên build, gọi là System Test hay Build Test, tức là kiểm tra xem các feature của sản phẩm có chạy đúng như những gì use case đưa ra, có đúng như business rule hay ko...
Developer trong giai đoạn này cũng có vai trò của 1 tester, đó là review lại code của mình có phát triển đúng coding convention ko, có dư biến, dư bộ nhớ không ..., đồng thời khi hoàn thành 1 feature cũng tham gia test sơ xem có chạy được không trứơc khi tạo build. Tương tự trên, các lỗi được tìm thấy sẽ được tập hợp thường kì, đánh giá độ nguy hiểm, khả năng sửa ... để hỗ trợ đánh giá tính hiệu quả của product theo từng giai đoạn.
- Giai đoạn cuối cùng của chu trình sống của 1 phần mềm thường là Transition, hay là kiểm tra và giao sản phẩm cho khách hàng. Giai đoạn này công việc của developer giảm xuống vì hầu hết các chức năng đã hoàn thành ở các giai đoạn trước, nhưng công việc của tester sẽ nặng hơn vì phải tập trung kiểm tra chất lượng mọi mặt của sản phẩm trước khi đến tay khách hàng. Developer liên tục theo dõi trên hệ thống lưu trữ lỗi để tìm giải pháp sửa và thông báo cho tester kiểm tra lại.
Cuối cùng khi phía phát triển và tester hoàn thành sản phẩm không còn 1 lỗi nghiêm trọng nào, sản phẩm sẽ được đóng gói (tạo setup kit, installation guide) và giao cho khách hàng. Khách hàng sẽ kiểm tra lại lần cuối cùng - gọi là Acceptance Test - trước khi quyết định hoàn tất (Release) sản phẩm.
Hệ thống lưu trữ và theo dõi bug của tester sẽ tập hợp, phân tích chu trình sống của sản phẩm theo bug/defect, tức là trong giai đoạn nào số lượng lỗi bao nhiêu, sao với các giai đọan khác tăng giảm bao nhiêu, tính hiệu của của developer trong việc sửa lỗi ... Những thống kê như vậy sẽ được tập hợp và dùng như là kinh nghiệm để đánh giá các sản phẩm mới sau này.
(Sưu tầm)
- Giai đoạn kế tiếp - thường gọi là Elaboration - là giai đoạn hình thành requirement hoàn chỉnh, bao gồm tập hợp các Use Case, Design model, database model, non-technical document (mô tả các business rule khác), các document hỗ trợ việc theo dõi, đánh giá tiến độ của project cũng bắt đầu được hình thành. Giai đoạn này tester cũng phải đưa ra được Test Plan (kế họach test) ghi rõ những tiêu chí test, flatform, criteria.... Tất cả các document này cũng được những thành viên có liên quan review để tìm issue (Review Defect) và hoàn chỉnh với sự thỏa thuận với khách hàng. Sau đó developer thường sẽ phát triển 1 bản thử nghiệm (gọi là prototype hay demo) dựa trên 1 số use case, tester sẽ dựa trên đó test bản thử nghiệm và tìm ra các Testing Defect/Bug, các lỗi này sẽ được tập hợp thường kì, đánh giá độ nguy hiểm, khả năng sửa, ... để hỗ trợ đánh giá tính hiệu quả của product theo từng giai đoạn . Đồng thời thiết lập 1 hệ thống để lưu trữ các lỗi tìm được, mô tả rõ ràng để developer vào đó theo dõi và sửa.
- Sau đó, là giai đoạn phát triển thật sự sau khi hầu hết các document gần như hoàn chỉnh (ngoại trừ use cases cần hiệu chỉnh trong suốt chu trình sống của project). Giai đoạn này thường đươc gọi là Construction - nó sẽ được chia nhỏ làm nhiều giai đoạn con (phase hay iteration) để tiện cho việc quản lý và theo dõi, mỗi giai đoạn con sẽ cần hoàn thành 1 lượng use cases nhất định và cuối mỗi phase là 1 bản build của sản phẩm ( các bạn chú ý trong hầu hết các ứng dụng chuyên nghiệp chưa hoàn chỉnh thường trong phiên bản có ghi vd như: phiên bản 5.6 build xxxxxxxx ...định dạng các số xxx và ý nghĩa thế nào tùy thuộc người sản xuất). Tester sẽ dựa trên Test Plan, Use cases trong phase và 1 số qui định/chuẩn để thực hiện test trên build, gọi là System Test hay Build Test, tức là kiểm tra xem các feature của sản phẩm có chạy đúng như những gì use case đưa ra, có đúng như business rule hay ko...
Developer trong giai đoạn này cũng có vai trò của 1 tester, đó là review lại code của mình có phát triển đúng coding convention ko, có dư biến, dư bộ nhớ không ..., đồng thời khi hoàn thành 1 feature cũng tham gia test sơ xem có chạy được không trứơc khi tạo build. Tương tự trên, các lỗi được tìm thấy sẽ được tập hợp thường kì, đánh giá độ nguy hiểm, khả năng sửa ... để hỗ trợ đánh giá tính hiệu quả của product theo từng giai đoạn.
- Giai đoạn cuối cùng của chu trình sống của 1 phần mềm thường là Transition, hay là kiểm tra và giao sản phẩm cho khách hàng. Giai đoạn này công việc của developer giảm xuống vì hầu hết các chức năng đã hoàn thành ở các giai đoạn trước, nhưng công việc của tester sẽ nặng hơn vì phải tập trung kiểm tra chất lượng mọi mặt của sản phẩm trước khi đến tay khách hàng. Developer liên tục theo dõi trên hệ thống lưu trữ lỗi để tìm giải pháp sửa và thông báo cho tester kiểm tra lại.
Cuối cùng khi phía phát triển và tester hoàn thành sản phẩm không còn 1 lỗi nghiêm trọng nào, sản phẩm sẽ được đóng gói (tạo setup kit, installation guide) và giao cho khách hàng. Khách hàng sẽ kiểm tra lại lần cuối cùng - gọi là Acceptance Test - trước khi quyết định hoàn tất (Release) sản phẩm.
Hệ thống lưu trữ và theo dõi bug của tester sẽ tập hợp, phân tích chu trình sống của sản phẩm theo bug/defect, tức là trong giai đoạn nào số lượng lỗi bao nhiêu, sao với các giai đọan khác tăng giảm bao nhiêu, tính hiệu của của developer trong việc sửa lỗi ... Những thống kê như vậy sẽ được tập hợp và dùng như là kinh nghiệm để đánh giá các sản phẩm mới sau này.
(Sưu tầm)