Đảm bảo chất lượng phần mềm

Software Quality Assurance

Đỗ Thị Bích Ngọc
PTIT/FIT/SE
ngocdtb@ptit.edu.vn
 Tài liệu tham khảo
• Daniel Galin. Sofware Quality Assurance – From
Theory to Implemtation. Addion Wesley, 2004.
• Glenford J. Myers. The Art of Sofware Testing -
Second Edition. John Wiley & Sons, Inc, Publication,
2004.
• Kshirasagar Naik and Priyadarshy Tripathy. Sofware
testing and quality assurance: theory and practice.
John Wiley & Sons, Inc., Hoboken, New Jersey, 2008.
• G. Gordon Schulmeyer. Handbook of sofware quality
assurance. Fourth edition, Artech House, 2008.
 Kiểm tra và đánh giá

Hình thức kiểm tra Tỷ lệ Đặc điểm đánh

( Tham khảo ví dụ dưới đây) đánh giá giá
- Đi học đầy đủ (trong lớp gây ảnh hưởng đến người 5% Cá nhân
khác, mỗi lần nhắc nhở trừ một điểm, mỗi buổi nghỉ
học trừ một điểm)
- Tích cực thảo luận (không phát biểu buổi nào sẽ 5% Cá nhân
được 0 điểm, phát biểu 1 buổi sẽ được 4 điểm, sau đó
số buổi học có phát biểu tăng lên 1 thì điểm tăng lên
1)
- Trung bình các điểm bài tập lớn 20% Cá nhân/Nhóm
- Trung bình các bài kiểm tra trên lớp 20% Cá nhân
- Kiểm tra cuối kỳ 50% Cá nhân
 bài tập nhóm
Yêu cầu: (1) viết quyển theo ý hiểu, (2) demo nhỏ,
Or/and dùng tools, and/or thiết kế test cases cho 1
phần mềm...(3) trình bày trước lớp
Danh sách đề tài (mỗi đề tài 5 người)
1. Unit test (* )
2. Control flow testing
3. Data flow testing
4. Domain testing
5. system integration testing
6. system test category
7. funtional testing(*)
8. Test tools?(*)
9. Testing for OOP
10. Game testing
Kỹ năng: Communication
 Customers/ End Users
 Designer/ BA
 Project Manager
 Developer
 QA
 Testers
 Test lead
 Test Manager
 Managers
 Communicator
 Translator

TEAM WORK
 Kỹ năng

Requirement study

Test Plan

Test Design/ Test Matrix/ Test case

Execute Test & Bug log

Re-test and Test Report

Test analysis and Close

 Kỹ năng
1. Đọc, hiểu, phân tch
Requirement
2. Ngoại ngữ tốt

Requirement study

1. Cẩn thẩn, tỉ mỉ
Test Plan
2. Rõ ràng, chi tiết
3. Ngắn gọn, dễ hiếu
4. Trung thực
Test Design/ Test Matrix/ Test case
Kỹ năng:
- viết tài liệu
-lập kế hoạch, khả Execute Test & Bug log
năng bao quát vấn
đề
-Logic, chặt chẽ Re-test and Test Report
IT Background
- Kỹ thuật test
- Phương pháp tạo TC Test analysis and Close
- Sử dụng Tool test
 Kỹ năng
1. Đọc, hiểu, phân tch Requirement
Requirement study 2. Ngoại ngữ tốt

Test Plan 3.Kỹ năng:

- viết tài liệu, lập kế hoạch, khả năng bao
quát vấn đề
Test Design/ Test Matrix/ TC -Logic, chặt chẽ

Execute Test & Bug log

4.Cẩn thẩn, tỉ mỉ. Rõ ràng, chi tiết
- Ngắn gọn, dễ hiếu,Trung thực
Re-test and Test Report

5.IT Background
Test analysis and Close - Kỹ thuật test
- Phương pháp tạo TC
- Sử dụng Tool test
Domains
3. Nhu cầu, Xu hướng Kiểm thử PM

• Nhu cầu

• Xu hướng

• Lý do kiểm thử phần mềm trở thành một

nghề thời thượng
Nhu cầu
Nhu cầu: Tỷ lệ Developer –Tester của Thế Giới/Việt Nam
 Xu hướng

 Xu hướng: “Các doanh nghiệp đều theo hướng đi tm các

thị trường tiềm năng để thuê gia công
 Gia công phần mềm Gia công kiểm thử phần mềm
 Việt Nam hiện nay đang được đánh giá sẽ trở thành con
hổ trong ngành kiểm thử phần mềm châu Á với lượng
nhân công trẻ và nhiều doanh nghiệp đang phát triển
theo con đường này
 TP.HCM thuộc sáu thành phố phát triển nhất thế giới về
ngành này
Các lý do kiểm thử phần mềm trở
thành một nghề thời thượng
 Lý do

1. Không có kiểm thử phần mềm – Không có phần mềm tốt.

2. Giữ được uy tn và tiết kiệm chi phí cho công ty mình (Điểm
mấu chốt).
3. Tạo cơ hội liên tục tiếp cận những điều tốt nhất và mới nhất.
4. Kiểm thử phần mềm đòi hỏi cao về tư duy, phân tch và sáng
tạo.
5. Nhiều người có thể làm, nhưng rất ít người có thể làm tốt
6. Kiểm thử phần mềm là một nghề có phúc lợi tốt với cơ hội
thăng tiến nghề nghiệp nhanh chóng và đa dạng.
 Cơ hội

 Có cơ hội được làm việc với nhiều vị trí khác nhau

 Cơ hội tìm hiểu về lĩnh vực mới, tiếp cận kỹ thuật mới
 Cơ hội đi Onsite
 Cẩn thận hơn, tư duy sắc bén, logic
 Có cái nhìn đa chiều khi đánh giá sự vật, hiện tượng
Định hướng nghề nghiệp
 Cấp độ nghề nghiệp

 Người kiểm thử chưa có kinh nghiệm

 sung sướng với số lỗi mà họ tìm ra
 Người kiểm thử có kinh nghiệm
 cũng tìm ra lỗi nhưng làm việc với người phát triển để chắc rằng
chúng được sửa
 Chuyên gia kiểm thử làm nhiều hơn điều đó:
 Họ làm việc với người phát triển để chắc họ không tạo ra lỗi
 Họ làm việc với người dùng để xác định yêu cầu tốt hơn
 Họ làm việc với chuyên gia an ninh để chắc phần mềm được
kiểm thử về an ninh
 Họ làm việc với người quản lí dự án để nhận diện và giảm nhẹ
rủi ro;
 Họ làm việc với người đảm bảo chất lượng về sự tuân thủ
 Vị trí nghề nghiệp

 Junior Tester
 Senior Tester:
 Test Leader
 Test Manager
 Expert tester
------
Chứng chỉ nghề nghiệp:
- ISTQBs
- CSTE
- …
 Định hướng nghề nghiệp
 Hướng chuyên gia
 Expert testers: Test tools….
 Tham gia training, làm seminar, workshop…
 Viết sách
 …
 Hướng quản lý
 Director
 PM
 Test Manager/ Test Leader
 …
 Hướng khác:
 BA, Sales, QA, BrSE, Dev…
 Chương 1
Đặc điểm của Đảm bảo
chất lượng phần mềm
Đặc trưng của SQA
Khác nhau chính giữa sản phẩm phần mềm
và sản phẩm công nghiệp
1. Sản phẩn phần mềm có độ phức tạp cao
– Vô vàn cách sử dụng sản phẩm phần mềm với dữ liệu
vào khác nhau/Miền dữ liệu vào thường là không giới
hạn
– Cách sử dụng sản phẩm công nghiệp thường được
định nghĩa cô đọng hơn.
• Các tham số sử dụng rõ ràng
• Tiến trình phát triển được định nghĩa rõ, …
– Think about software:
• Các giá trị dữ liệu khác nhau trong vòng lặp có thể dẫn tới
lỗi.
• Thực tế, số đường của sản phẩm phần mềm (không tầm
thường) là vô hạn
Khác nhau chính giữa sản phẩm phần
mềm và sản phẩm công nghiệp

2. Sự vô hình của sản phẩm phần mềm

– Trong sản phẩm công nghiệp, ta có thể quan sát
thấy phần bị thiếu
• Dễ phát hiện nếu sản phẩm không hoàn thiện
• Dễ phát hiện phần bị thiếu
– Ngược lại với sản phẩm phần mềm
• Có thể không bị phát hiện cho tới khi cần dùng tới
Khác nhau chính giữa sản phẩm phần
mềm và sản phẩm công nghiệp
• Xem xét phát triển sản phẩm và quy trình sản xuất với 3
khía cạnh:
1. Với sản phẩm công nghiệp:
– Phát triển sản phẩm –
• Người thiết kế và QA kiểm tra mẫu xem có lỗi không
– Lập kế hoạch sản xuất sản phẩm –
• Quy trình sản xuất và công cụ được thiết kế, chuẩn bị.
• Có thể yêu cầu thiết kế và xây dựng dòng sản phẩm đặc biệt
• Nhiều cơ hội để kiểm tra lỗi bị bỏ sót khi kiểm tra trong suốt quá trình
phát triển
– Sản xuất –
• Áp dụng các thủ tục đảm bảo chất lượng để phát hiện lỗi của sản phẩm
trong quá trình sản xuất
• Có thể sửa bằng cách thay đổi thiết kế hoặc công cụ sản xuất và điều
này sẽ thay đổi cách sản phẩm được sản xuất trong tương lai.
Khác nhau chính giữa sản phẩm phần
mềm và sản phẩm công nghiệp
• Nhận thấy là:
– Chỉ có pha sửa lỗi trong sản phẩm phần mềm thực sự
là pha trong tiến trình sản xuất

• Ta xem xét 3 hành động

– (phát triển sản phẩm, lập kế hoạch sản xuất, và sản
xuất)
• cho sản phẩm phần mềm:
Khác nhau chính giữa sản phẩm phần
mềm và sản phẩm công nghiệp
• Xem xét phát triển sản phẩm và quy trình sản xuất với 3 khía
cạnh:
• 2. Với sản phẩm phần mềm:
• Phát triển sản phẩm– cơ hội tốt nhất để phát hiện lỗi!
– Ta cần tìm các lỗi có trong sản phẩm và hi vọng đạt được một
bản mẫu chấp nhận được.
• Lập kế hoạch sản xuất
– Sản xuất phần mềm không cần pha này
– Các bản copy của sản phẩm được sản xuất/in ấn tự động một
cách đơn giản
– Lỗi phát hiện ở 1 bản copy cũng sẽ xuất hiện ở các bản khác.
End of story!
• Sản xuất
– Sản xuất được được giới hạn ở sao chép sản phẩm/in hướng
dẫn sử dụng.
– Cơ hội phát hiện lỗi hạn chế.
 Cơ hội để phát hiện lỗi:
• Cơ hội tốt nhất để phát hiện lỗi là quá trình
phát triển phần mềm!
• “Nhu cầu về các công cụ chuyên dụng và các phương pháp cho công
nghiệp phần mềm được phản ánh trong các ấn phẩm chuyên ngành
và các chuẩn chuyên dụng cho SQA, như ISO 9000-3, “Guidelines for
the application of ISO 9001 to the development, supply, and
maintenance of software.”
• Khác: ISO 9004-2: “Quality Management and Quality Systems
Elements: Guidelines for the Services.”

• Đặc trưng của phần mềm –

– Phức tạp,
– Vô hình, và
– Ít cơ hội phát hiện lỗi
• Dẫn tới sự phát triển của ISO Guidelines và nhận thức về tầm quan
trọng và cần thiết của phương pháp luận SQA.
Môi trường phát triển
các phương pháp SQA
 Môi trường phát triển
các phương pháp SQA
• Ta hãy xem xét môi trường phát triển và bảo trì phần mềm
chuyên nghiệp
• Đặc điểm chính: (We will look at each of these in turn)
– 1. Điều kiện hợp đồng
– 2. Quan hệ Khách hàng – nhà cung cấp
– 3. Yêu cầu Teamwork
– 4. Hợp tác và phối hợp với các đội khác
– 5. tương tác (interface) với các hệ thống phần mềm khác
– 6. Cần tiếp tục dự án ngay cả khi có sự thay đổi thành viên
– 7. Cần tiếp tục bảo trì phần mềm trong thời gian dài
• Tất cả các hành động trên (là các hình thức khác nhau
của SQA) rất quan trọng để công việc kỹ thuật phần
mềm thành công
 Môi trường phát triển
các phương pháp SQA
1. Điều kiện hợp đồng
– Bao gồm yêu cầu chức năng, ngân sách dự án, thời
gian biểu dự án.

– Điều kiện hợp đồng là lớn nhất! (so với các tham số
khác)

– Cung cấp phần mềm đúng hạn, trong ngân sách, đáp
ứng được yêu cầu chức năng tạo thành lực đẩy và các
yếu tố pháp lý của hợp đồng.
 Môi trường phát triển
các phương pháp SQA
2. quan hệ khách hàng – nhà cung cấp

– Ta cần nhận thức là khách hàng điều khiển quá trình

bằng nhiều cách – thay đổi yêu cầu, đánh giá, kiểm
thử chấp nhận, chấp nhận triển khai, phê duyệt bàn
giao
• Mối quan hệ này phải tốt, nhưng có thể phức tạp kinh khủng!!
 Môi trường phát triển
các phương pháp SQA

3. Yêu cầu Teamwork

• Yêu cầu thời gian biểu – các thành viên của đội làm
việc cùng nhau

• Có nhiều thông tin chuyên môn – thảo luận. Thường

xuyên? Ở đâu? Khi nào?

• Hỗ trợ lẫn nhau và xem xét để nâng cao chất lượng

sản phẩm
 Môi trường phát triển
các phương pháp SQA
4. Hợp tác và phối hợp với các đội khác
– Các tổ chức phần mềm lớn có nhiều đội và việc phát
triển yêu cầu có hợp tác và phối hợp.
– Chuyên gia ở đội khác?
• Có thể mượn người đó?
– Phát triển phần mềm có thể gia công từng phần.
– Đội khác có thể phát triển phần mềm tương tự cho
khách hàng và có thể hỗ trợ cực lớn
– Xung đột
 Môi trường phát triển
các phương pháp SQA
5. Giao tiếp với các hệ thống khác
– Hệ thống đăng ký môn học có thể giao tiếp với hệ thống
lập lịch lớp học và hệ thống thanh toán
– Thông thường, đầu ra của một hệ thống là đầu vào của hệ
thống khác và ngược lại!
– Một hệ thống đăng ký môn học có thể cần ‘interface’ với
một hệ thống thanh toán đã có với các định dạng fle/cơ
sở dữ liệu khác nhau.
– Đôi khi, đầu ra của một hệ thống là đầu vào của nhiều hệ
thống.
 Môi trường phát triển
các phương pháp SQA

Attendance
control
system

Input interface Monthly attendance report,

including overtime calculations
Salary
processing
system

Output interface Money transfers to employees’

bank account accounts
Bank
information
systems
 Môi trường phát triển
các phương pháp SQA
6. Cần tiếp tục dự án ngay cả khi có sự thay đổi thàn
viên
– Rất hay xảy ra, cần tnh trước!
– “The show must go on”
– Fred Brooks: thêm người vào dự án trễ sẽ làm nó trễ hơn.
– Fred Brooks: Giao tiếp với người mới
– Fred Brooks: bắt người mới phải tăng tốc.
– Thành viên của đội rời đi, được tuyển dụng, nghỉ phép,
thuyên chuyển,…
– Hiển nhiên là phiền toái, nhưng sự phát triển cần tiếp tục
– Ta cần tnh toán trước sự thay đổi này
 Môi trường phát triển
các phương pháp SQA
7. Cần tiếp tục bảo trì phần mềm trong thời gian
dài.
– Phần mềm được phát triển để chạy nhiều năm.
• Điều này ảnh hương tới công ty ở mức “đáy”, không phải
công ty phát triển phần mềm, trạng thái là “red”
– Bảo trì là tốt và là nơi các công ty phát triển phần
mềm kiếm tiền
– Nhớ là, khi phát triển phần mềm, công ty ở trạng thái
“red”
– Cần tốn thỜi gian để triển khai và chuyển sang
“black” và tạo doanh thu.