7 lãng phí trong kiểm thử phần mềm

Bài viết được sự cho phép của vntesters.com

Tựa đề “7 lãng phí trong kiểm thử phần mềm” nghe có vẻ quen quen? Vâng, 7 lãng phí nổi tiếng nhất là 7 lãng phí trong sản xuất tinh gọn (Lean manufacturing). Mình biết đến 7 lãng phí này cũng là sự tình cờ. Chuyện là công ty hiện mình đang làm việc là một công ty sản xuất. Mỗi ngày khi đi ăn trưa mình đều đi ngang qua xưởng sản xuất của công ty và có một tấm bảng được đặt dọc lối đi ngay cạnh xưởng sản xuất đã gây được sự chú ý của mình. Đó là tấm bảng nói về 7 lãng phí trong sản xuất tinh gọn. Đọc qua 7 nội dung thì mình thấy rõ ràng 7 lãng phí đó khá đơn giản, dễ hiểu và về cơ bản là đúng cho cả ngành kiểm thử phần mềm. Tìm hiểu kỹ hơn thì mình biết được rằng việc định ra và loại bỏ 7 lãng phí này đóng vai trò cực kỳ quan trọng trong sản xuất tinh gọn nhưng dường như ít ai quan tâm đến vấn đề này trong phát triển phần mềm cũng như trong kiểm thử. Điều đó đã thúc đẩy mình để thực hiện bài viết về 7 lãng phí trong kiểm thử phần mềm. Bài viết lần lượt đi qua 7 lãng phí trong sản xuất tinh gọn và được liên hệ với ngành kiểm thử phần mềm cùng với đó là những đề nghị giải pháp để loại bỏ hay giảm thiểu những lãng phí này.

Lỗi (Defects)

Trong ngành sản xuất, lỗi được xem là lãng phí. Thực vậy, khi một lỗi xảy ra, chúng ta sẽ tốn nhiều thời gian của Dev để sửa lỗi, sau đó sẽ tốn thêm thời gian cho kỹ sư kiểm thử để kiểm thử lỗi một lần nữa. Tương tự, nếu một bản build bị hỏng (vì có quá nhiều lỗi nghiêm trọng), chúng ta đã lãng phí cả một quy trình, thời gian và công sức để làm lại từ đầu. Dĩ nhiên, lãng phí sẽ còn lớn hơn nếu sản phẩm bị lỗi sau khi đưa ra thị trường. Khi đó lãng phí không chỉ đơn thuần xảy ra ở bộ phận sản xuất mà còn kéo theo lãng phí cả những bộ phận khác trong công ty. Chắc các bạn cũng còn nhớ chuyện Toyota gần đây triệu hồi hàng chục nghìn xe tại Việt Nam và hàng triệu xe trên thế giới vì hàng loạt lỗi nghiêm trọng có thể ảnh hưởng đến sự an toàn của người sử dụng cho thấy mức độ nghiêm trọng của lỗi sau khi đưa ra thị trường. Rõ ràng không những tốn kém cho chi phí từ việc triệu hồi và sửa những lỗi đó mà còn ảnh hưởng không nhỏ đến hình ảnh của Toyota.

Để tránh lãng phí về lỗi, là kỹ sư kiểm thử, ngoài việc tìm lỗi chúng ta cũng nên chú trọng hơn vào vấn đề ngăn ngừa lỗi thay vì tìm lỗi. Việc chúng ta ngăn ngừa được một lỗi xảy ra có giá trị gấp nhiều lần một lỗi nghiêm trọng mà chúng ta tìm thấy vì khi chúng ta tìm thấy lỗi thì đã xuất hiện sự lãng phí. Để ngăn ngừa lỗi tốt hơn, kỹ sư kiểm thử nên được tham gia vào tất cả các khâu của dự án từ phân tích yêu câu, thiết kế đến viết code và càng sớm càng tốt.

Sản xuất thừa (Overproduction)

Trong kiểm thử phần mềm, việc chúng ta dành quá nhiều thời gian và công sức để tạo ra và cập nhật bản kế hoạch kiểm thử (test plan), chiến lược kiểm thử (test strategy), trường hợp kiểm thử (test case) mà thực tế thì nhiều khi chẳng ai hoặc ít ai đọc đến. Bi kịch là chúng ta biết điều đó nhưng vẫn phải làm vì nhiều lí do rất “thuyết phục” như “quy trình nó vậy”, “giờ không cần nhưng biết đâu khách hàng cần”, “như vậy mới pro” hay nhẹ nhàng hơn như “làm nhanh mà”. Các bạn đừng hiểu lầm là việc tạo ra các tài liệu kiểm thử là lãng phí, việc tạo ra tài liệu kiểm thử mà không có giá trị hoặc không cần thiết mới là lãng phí.

Trước khi bạn bắt đầu tạo một tài liệu kiểm thử hãy tự hỏi hay hỏi sếp mình những ai sẽ đọc nó và nó mang lại giá trị gì. Nếu không có câu trả lời hay câu trả lời là mơ hồ hay không rõ ràng thì tốt nhất chúng ta không nên tạo ra để tránh tình trạng sản xuất thừa.

Chờ đợi (Waiting)

Ai đó từng nói “sống là không chờ đợi” ấy vậy mà trong ngành kiểm thử thì việc chờ đợi đã trở nên quen thuộc. Chúng ta đã bao nhiêu lần phải chờ đợi bản build từ đội Dev để kiểm thử, chờ môi trường kiểm thử sẵn sàng, chờ khách hàng kiểm duyệt cho các trường hợp kiểm thử đã tạo ra, chờ tài liệu yêu cầu từ khách hàng gửi sang, chờ khách hàng online để thảo luận, v.v. Lãng phí sẽ còn lớn hơn nếu trong khi chờ đợi và chúng ta không có gì khác để làm. “Tin tốt” là ngày nay sếp ít khi để cho nhân viên của mình nhàn rỗi trong khi chờ đợi và bạn luôn có việc khác để làm. Tin xấu là chúng ta đã tự đặt mình vào tình trạng bị động khi chờ đợi. Nhiều khi những thứ chúng ta chờ đợi lại đến không đúng thời điểm hay khi tất cả những thứ chúng ta đang chờ đợi cùng đến một lúc hay chẳng bao giờ đến. Đó là khi chúng ta chờ đợi 1 build từ đội Dev và gần cuối ngày chúng ta nhận được bản build với yêu cầu từ sếp là phải chạy xong bộ test case…trong ngày.

Hãy kiểm tra lại các khâu trong quy trình kiểm thử xem liệu có tình trạng “nút thắt cổ chai” đâu đó và đề ra giải pháp khắc phục tương ứng. Ứng dụng mô hình phát triển tích hợp liên tục (continuous integration) từ việc coding, triển khai, thực thi kiểm thử tự động, báo cáo kết quả không những tránh được lãng phí do chờ đợi mà còn tận dụng được nguồn lực máy móc một cách tối ưu. Hãy chuẩn bị sẵn cho mình kế hoạch B cũng như tìm ra những kênh liên lạc khác nhau để tránh tình trạng bị động khi phải chờ đợi.

Tồn kho (Inventory)

Việc sản xuất thừa cùng tình trạng chờ đợi ở trên dẫn đến một lãng phí khác là tồn kho. Trong ngành kiểm thử (và cả phát triển phần mềm) thì thuật ngữ “tồn kho” nghe có vẻ lạ lẫm nhưng thực tế thì có tồn tại việc tồn kho. Việc tạo ra quá nhiều tài liệu kiểm thử không cần thiết hoặc quá nhiều thứ đến cùng một lúc (do việc chờ đợi) hay quá nhiều thứ đang đợi để xử lý, dẫn đến tình trạng tồn kho (hay nói cách khác là “lưu trữ”). Ngày nay, với sự hỗ trợ của nhiều công cụ phần mềm cũng như dung lượng lưu trữ của máy tính lớn, chúng ta hầu như không thấy vấn đề về tồn kho trong dự án. Tuy nhiên, về lâu về dài việc tồn kho sẽ gây lãng phí về nguồn lực, thời gian trong quản lí và truy xuất. Ở đây, mình cũng thấy một vòng luẩn quẩn là từ việc chúng ta có hệ thống quản lí tồn kho tốt chúng ta lại vô tình khuyến khích tình trạng sản xuất thừa hay chờ đợi.

Thực tế thì việc tồn kho, quản lí tồn kho là không thể tránh khỏi và cũng không đáng kể trong kiểm thử phần mềm. Tuy nhiên, giải pháp tốt vẫn là tránh sản xuất thừa hay tình trạng chờ đợi ở trên để giảm thiểu việc tồn kho đến mức thấp nhất có thể. Hành động đơn giản mà chúng ta có thể làm ngay là hãy dũng cảm “delete” những tài liệu không cần thiết không những giúp cho kho hàng của bạn nhỏ gọn mà còn giúp bạn tìm kiếm dễ dàng hơn.

Vận chuyển (Transportation) và Hành động thừa (Motion)

Đây là 2 loại lãng phí chuyên biệt trong ngành sản xuất và thật khó để liên hệ với ngành phát triển phần mềm hay kiểm thử. Tuy nhiên, mình xin được phép liên hệ 2 loại lãng phí này với việc lãng phí trong việc phân bổ đội kiểm thử cũng như mô hình kiểm thử trong dự án. Cụ thể hơn, trong kiểm thử phần mềm, thì việc tổ chức sắp xếp các thành viên trong đội kiểm thử hay giữa đội kiểm thử với các đội khác trong dự án không hợp lí dẫn đến lãng phí. Sự không hợp lí này bao gồm cả về mặt địa lí cũng như cấu trúc. Việc đội kiểm thử và đội phát triển cách xa nhau về mặt địa lí (thường thấy trong môi trường outsource) sẽ gây nhiều khó khăn trong việc giao tiếp cũng như trao đổi tài liệu, kết quả kiểm thử. Một số dự án do cách xa nhau về địa lí cùng hệ thống network phức tạp, bảo mật nhiều tầng dẫn đến việc nhận build, cài đặt, kiểm thử, gửi kết quả kiểm thử, debug gặp rất nhiều thời gian và công sức. Việc đưa nhân viên onsite đào tạo hay thăm nom đội dự án giữa 2 bên cũng gây nhiều tốn kém. Ngoài vấn đề khó khăn về địa lí thì việc bố trí đội kiểm thử như là gatekeeper (“người canh cổng”) cho toàn bộ quy trình cũng gây lãng phí nguồn lực. Đội kiểm thử lúc này chỉ đóng vai trò như là người tìm lỗi và tham gia rất ít (hoặc không tham gia) vào quá trình ngăn lỗi. Ngoài những vấn đề nêu trên thì các mô hình quản lí kiểm thử rườm rà phức tạp như quá nhiều vòng kiểm và duyệt dư thừa cho các hoạt động kiểm thử cũng gây lãng phí nhiều thời gian.

Nếu có thể thì nên bố trí đội kiểm thử và đội phát triển “gần nhau” để dễ dàng cũng như giảm thiểu, chi phí trao đổi thông tin. Mô hình phát triển phần mềm linh hoạt (Agile) đã làm rất tốt về mặt này khi góp gần giảm bớt những hoạt động, quy trình không mang lại giá trị và tập trung vào những thứ mang lại giá trị thiết thực cho dự án.

Quy trình thừa (Over-processing)

Một số dự án nhỏ nhưng vì để “bằng chị bằng anh” đã áp dụng quy trình, mô hình quản lí như CMMI, ISO để quản lí dự án. Kết quả là thời gian mà đội kiểm thử dành để tạo, cập nhật tài liệu, báo cáo còn nhiều hơn thời gian thực tế dành cho công việc kiểm thử. Một ví dụ khác có thể nhìn thấy là vấn đề kiểm thử tự động. Nhiều người lầm tưởng là kiểm thử tự động là tiên tiến là hiện đại nên nhất quyết phải kiểm thử tự động cho bằng được mặc dù bản chất của sản phẩm không phù hợp với kiểm thử tự động hoặc chi phí bỏ ra để kiểm thử tự động lớn hơn giá trị thu về. Nguyên nhân dẫn đến tình trạng trên một phần xuất phát từ cái gọi là “quy trình chuẩn” hay “best practice” cùng góc nhìn chủ quan dựa trên những kinh nghiệm thành công trong quá khứ. Những quy trình chuẩn và những thành công mà chúng ta có được với dự án trước, công ty trước không đồng nghĩa là chúng ta sẽ lại áp dụng thành công ở dự án, công ty hiện tại. Vì bản chất dự án là khác nhau, con người khác nhau, thời điểm khác nhau, môi trường văn hóa công ty khác nhau.

Trước khi ứng dụng 1 quy trình, mô hình hay ứng dụng, chúng ta nên cân nhắc xem liệu “chiếc áo” ta sắp mặc vào có quá to so với mình hay không mặc dù nó rất vừa và đẹp với người khác. Tương tự, cũng nên cân nhắc xem liệu chúng ta có thật sự cần những công cụ quản lí kiểm thử như QC, JIRA, Bugzilla, Rally hay nhu cầu thực sự của chúng ta chỉ là 1 file Excel.

Lời kết

Bài viết nói về 7 lãng phí trong kiểm thử phần mềm dựa trên 7 lãng phí trong sản xuất tinh gọn nhưng điều này không có nghĩa là chúng ta chỉ có 7 lãng phí (tất nhiên rồi). Hãy nhìn vào dự án của mình, nhìn vào các hoạt động kiểm thử chúng ta làm mỗi ngày, các quy trình kiểm thử và xem xem liệu chúng ta có đang lãng phí điều gì không. Lãng phí không nhất thiết gây hại cho dự án nhưng việc định ra và loại bỏ những lãng phí là một trong hoạt động quan trọng trong cải tiến quy trình để hướng đến mục tiêu làm việc hiệu quả và tiết kiệm.

Bạn có quan điểm khác về lãng phí trong kiểm thử phần mềm? Rất vui nếu nhận được ý kiến đóng góp của các bạn.

Bài viết có tham khảo:

http://en.wikipedia.org/wiki/Muda_(Japanese_term)

http://en.wikipedia.org/wiki/Lean_manufacturing#Types_of_waste

http://www.proftest.nl/artikelen/LTM_TE_16_12_11.pdf

Bài viết gốc được đăng tải tại vntesters.com

Có thể bạn quan tâm:

• Sử dụng bảng quyết định trong kiểm thử phần mềm
• Cách tự học code web, tìm kiếm công việc dễ dàng và hạnh phúc mỗi ngày
• Từ vựng kiểm thử phần mềm

Xem thêm Việc làm Developer hấp dẫn trên TopDev