Một câu hỏi ngây thơ nhưng không đơn giản: Vì sao chương trình phần mềm có bug, bug ở đâu ra?
Ai hỏi câu này?
Tôi nhận được câu hỏi này từ các thành viên trong dự án. Tester và developer đều hỏi câu này dù họ làm phần mềm nhiều năm?
Vì sao phải trả lời câu hỏi này?
Đây là câu hỏi có vẻ đơn giản, nhưng câu trả lời không dễ. Với người ít kinh nghiệm làm phần mềm, họ trả lời "bug là bug". Với người nhiều kinh nghiệm hơn, ẩn ý từ câu hỏi này "bug từ nguồn nào tới để chúng ta/chúng tôi biết cách phòng tránh."
Nói thêm về quy trình phần mềm
Dù chúng ta phát triển phần mềm theo quy trình nào, những khái niệm sau luôn đúng.
- Mỗi công đoạn làm phần mềm trong quy trình đều có đầu vào vào đầu ra cụ thể
- Quá trình test phát hiện ra lỗi nhiều nhất
Công đoạn (chính) nào phát hiện được bug?
- (Các loại) test, như: unit test, function test, regression test, integration test, system test, user acceptance test
- Review (nói chung): Tài liệu, mã nguồn hay các loại input/output nói chung
Đầu vào của công đoạn coding là gì?
Đây là câu hỏi quan trọng hướng tới câu trả lời "bug từ đâu ra" của lập trình viên và tester.
Tùy vào quy trình dự án, một số đầu vào điển hình của công đoạn coding là:
- Tài liệu thiết kế (basic design, detail design)
- Requirement definition
Tùy vào dự án, quy trình, đầu vào là khác nhau
Dựa vào đâu để biết đầu ra đúng hay sai?
"Đầu ra" ở đây được hiểu đơn giản là "mã nguồn", sản phẩm một hay nhiều chức năng phần mềm.
Việc kiểm tra đầu ra đúng hay sai cần dựa trên một cái gì đó đúng. Ta có thể chọn các đầu vào của việc coding làm tài liệu "đúng".
Test thế nào nếu không có "đầu vào" của việc coding chuẩn?
- Free test (test tự do, không theo một kịch bản nhất định. Mức độ test tùy vào kinh nghiệm của người test)
- Test phá (một dạng test tự do, tìm cách làm cho chương trình chết)
Nghĩa là, cứ lần mò mà test
Nếu không có requirements definition hay tài liệu thiết kế rõ ràng) thì test thế nào?
Trả lời: Test phá (agile testing)
Nếu khi test, tôi tìm ra một điểm mới, không biết là đúng sai thì làm thế nào?
Hãy log lại và confirm với toàn team. Đây là cơ hội để cả team review lại kiến thức của họ về hệ thống
Làm thế nào để tìm bug khi không có tài liệu:
Câu trả lời là: Agile testing
Tôi là tester, phải làm gì khi không biết thế nào là đúng/sai?
- Agile testing
- Thật chủ động
- Làm việc chặt chẽ với người hiểu code và hiểu yêu cầu nghiệp vụ
--
Best Regards,
Nguyen Hung Vu [aka: NVH] (in Vietnamese: Nguyễn Vũ Hưng, グェン ヒュン ウー, 阮武興)
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype: vuhung16plus, twitter:
vuhung, MSN: vuhung16.
vuhung's facebook Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt Disclaimer: When posted to social networking groups include, but not limited to Linux Users' Groups, Free and Open Sources forums, mailing lists, the above is my personal opinion and is *not* the opinion of my employer(s), associations and/or groups I join.
