Báo cáo TTTN tại doanh nghiệp

báo cáo thực tập thực tế tại Công ty TNHH phần mềm FPT

TRƯỜNG ĐẠI HỌC

KHOA

BÁO CÁO THỰC TẬP TỐT NGHIỆP (tại Doanh nghiệp)

Sinh viên thực hiện:

Lớp:

Người hướng dẫn tại doanh nghiệp:

Giáo viên quản lý:

Thái Nguyên – Năm 2019

TRƯỜNG ĐẠI HỌC

BÁO CÁO THỰC TẬP TỐT NGHIỆP

(tại doanh nghiệp)

Sinh viên thực hiện: ………

Lớp: ………

Người hướng dẫn tại Doanh nghiệp Giáo viên quản lý

(Ký và ghi rõ họ tên) (Ký và ghi rõ họ tên)

Thái Nguyên – 2019

LỜI CẢM ƠN

Trong suốt quá trình học tập, rèn luyện kỹ năng trên ghế nhà trường và sau thời gian 2tháng thực tập thực tế tại Công ty TNHH phần mềm FPT Mặc dù thời gian không dài nhưng đãgiúp em học hỏi được nhiều kinh nghiệm thực tế hài hòa giữa kiến thức lý thuyết vào trong quátrình thực hành Với sự giúp đỡ, quan tâm tận tụy của các thầy, cô giáo, cùng các anh chị nhânviên trong công ty đã giúp em học hỏi được nhiều kinh nghiệm quý báu khi ra trường

Để có được những kiến thức quý báu đó, em xin gửi lời cảm ơn chân thành đến các thầy

cô giáo Trường Đại học Công nghệ thông tin và truyền thông Thái Nguyên nói chung, các thầy

cô giáo trong Bộ môn Công nghệ phần mềm nói riêng, giảng viên hướng dẫn – Tiến sĩ NguyễnVăn Núi đã hết lòng tận tụy, chỉ bảo, hướng dẫn chúng em trong suốt quá tình học tập, gắn liềnkiến thức lý thuyết giảng dạy, cũng như hiểu biết về thực tế trong chuyên ngành để khi chúng em

ra trường nắm chắc được những kiến thức quan trọng, chuẩn bị cho tương lai sau này

Bên cạnh đó, với sự giúp đỡ, chỉ bảo tận tình của Công ty TNHH phần mềm FPT nóichung, chị Nguyễn Thị T và các anh chị trong dự án HKMU_RUST nói riêng, đã chỉ bảo tậntình, tạo mọi điều kiện thuận lợi để em thực hiện tốt đợt thực tập vừa qua Với lòng biết ơn chânthành, em xin chúc toàn thể anh chị trong công ty luôn có một sức khỏe tốt, một tâm thế chiếnbinh để có thể hoàn thành tốt mọi nhiệm vụ được giao

Trong quá trình thực tập và làm báo cáo, do còn nhiều thiếu sót về mặt kinh nghiệm thực

tế nên em rất mong nhận được sự đóng góp và chỉ bảo từ các thầy cô giáo để em có thể hoànthành đợt thực tập một cách tốt hơn

Em xin chân thành cảm ơn!

Thái Nguyên, ngày 18 tháng 1 năm 2019

Sinh viên

Nguyễn Thị B

LỊCH LÀM VIỆC TẠI NƠI THỰC TẬP

dẫn

Mức độ hoàn thành

Nhận xét của người hướng dẫn

1

1

- Học khóa học Dayone, Tìm

hiểu về công ty, cách tổ chức

của công ty

- Làm quen với các công cụ

làm việc trong công ty

- Học cách trao đổi, báo cáo,

làm việc qua email

2

Học các khái niệm về kiểm

thử phần mềm

3 Học testcase của dự án

4 Present testcase của dự án

5 Tìm hiểu về Tool Jira

6 Study log bug bằng Tool Jira.

Thực thi log bug

7 Test Trainning

8 - Thực hiện test tranning

- Báo cáo cuối đợt thực tập

CHƯƠNG I GIỚI THIỆU VỀ TỔ CHỨC TẠI NƠI THỰC TẬP 1.Quá trình hình thành và phát triển

FPT Software là một công ty dịch vụ Công nghệ thông tin và gia công toàn cầu có trụ sở

tại Hà Nội, Việt Nam Đây là công ty con của tập đoàn FPT- tập đoàn công nghệ đa quốc gia,hiện là công ty dịch vụ phần mềm lớn nhất tại Việt Nam Các dịch vụ của FPT Software bao gồmAnalytics, IOT, Mobility, Cloud, Embedded System, Q&A Test, Legacy Migration, Gói triểnkhai, dịch vụ ứng dụng và dịch vụ BPO Có hơn 27 văn phòng tại 16 quốc gia Hầu hết nhân viêncủa công ty có trụ sở tại Việt Nam, chiếm hơn 80% lực lượng lao động Các thị trường chính baogồm Nhật Bản, Mỹ, Châu Âu, Châu Á Thái Bình Dương

FPT Software được thành lập năm 1999 bởi 13 thành viên của tập đoàn FPT, dẫn đầu là

ông Nguyễn Thành Nam (Giám đốc Trung tâm Giải pháp phần mềm của FPT, Chủ tịch kiêmTổng giám đốc Công ty Cổ phần Phần mềm FPT (FSOFT), hiện nay là Công ty TNHH Phầnmềm FPT (FPT Software) Ban đầu được đặt tên là FPT Strategic Unit1 hoặc FSU1, phụ tráchGia công phần mềm Công nghệ thông tin cho thị trường toàn cầu Cuộc khủng hoảng tài chính

và biến động trong nền kinh tế của Việt Nam năm 1997 và 1998 đã khiến nhiều công ty, trong đó

có FPT gặp bất lợi FPT tìm cách vươn ra thế giới, giống như các công ty toàn cầu khác và cungcấp dịch vụ gia công phần mềm Phần mềm FPT được thành lập để phục vụ mục đích này

Năm 2000, Công ty đã mở chi nhánh đầu tiên ở nước ngoài tại thung lũng Silicon, Hoa

Kỳ và Bangalore, Ấn Độ Cả hai đóng cửa sau một năm vì thiếu khách hàng Trước tình hình đó,Hội đồng quản trị của FPT quyết định chuyển sự chú ý sang Nhật Bản Kết thúc tốt đẹp vào năm

2004, công ty mở trung tâm giao hàng tại Thành phố Hồ Chí Minh, rồi Đà Nẵng vào năm 2005.Cùng năm đó, FPT đã mở chi nhánh đầu tiên tại Nhật Bản, sau đó vào năm 2007 tại Singapore,

2008 tại Paris, Pháp và mở lại chi nhánh tại Hoa Kỳ cùng một năm

Năm 2009, FPT Software tổ chức lại thành công ty cổ phần, với CEO Nguyễn Thành

Nam được thăng chức Chủ tịch và bà Bùi Thị Hồng Liên, cựu CEO FPT Ấn Độ và cựu CEOFPT Nhật Bản (một công ty con của FPT và được điều hành bởi FPT Software)

Năm 2012, có sự thay đổi tổ chức lớn đầu tiên, với sự thay đổi về lãnh đạo (Chủ tịch

Nguyễn Thành Nam được thay thế bởi ông Hoàng Nam Tiến, sau đó là Chủ tịch FPT Land vàcựu Chủ tịch Công ty Thương mại FPT; Giám đốc điều hành Bùi Thị Hồng Liên được thay thếbởi Nguyễn Thành Lâm, EVP&MD, FPT Software Hochiminh), mô hình kinh doanh (từ nhiềucông ty con đến trung tâm phân phối và chi nhánh ở nước ngoài) và chiến lược (từ dịch vụ ITOtruyền thống đến dịch vụ định hướng SMAC) Mục tiêu là đạt doanh thu 100 triệu đô la vào năm

2013 (Doanh thu của Fsoft là 60 triệu đô la vào năm 2011, với mức tăng trưởng trung bình là 15% trước đó)

10-Vào cuối năm 2013, FPT Software đã đạt được cột mốc 100 triệu đô la doanh thu và 5000

nhân viên, trở thành công ty dịch vụ CNTT Việt Nam đầu tiên và duy nhất (cho đến năm 2018)đạt được cột mốc đó Mục tiêu của công ty giờ đã thay đổi để đạt doanh thu 1 tỷ đô la vào năm2020

Vào tháng 6/2014, công ty đã mua lại RWE IT Slovakia, một đơn vị kinh doanh CNTT

của RWE, trở thành công ty CNTT Việt Nam đầu tiên thực hiện M&A ở nước ngoài Thỏa thuậnnày giúp công ty Phần mềm FPT truy cập vào lĩnh vực Quản lý năng lượng và bí quyết trong cáccông nghệ của SAP với hơn 400 chuyên gia

Tháng 8/2015, CEO Nguyễn Thành Lâm được thay thế bởi Hoàng Việt Anh, COO&MD,

FSU1, cựu CEO FPT Châu Á Thái Bình Dương

Năm 2016, Phần mềm FPT đã đạt được 2 mốc: 10.000 nhân viên và 230 triệu đô la doanh

thu, đặt nó tương đương với 20 công ty Dịch vụ CNTT hàng đầu Ấn Độ FPT Nhật Bản cũng đạtmốc doanh thu 126 triệu đô la, trở thành chi nhánh đầu tiên của Công ty Phần mềm FPT ở nướcngoài vượt mốc 100 triệu đô la

Năm 2017, được tài trợ bởi Chủ tịch Tập đoàn FPT Trương Gia Bình, công ty đã phát

động các chiến dịch lớn về Chiến lược chuyển đổi kỹ thuật số và săn cá voi Điều này giúp nhómthiết lập quan hệ với hơn 40 tập đoàn lớn trên toàn cầu, trong đó hơn 20 tập đoàn trong FortuneGlobal 500 như Airbus, Siemens, UPS,… Đến cuối năm, công ty có 75 đối tác trong FortuneGlobal 500

Vào tháng 3/2018, Tập đoàn FPT có sự thay đổi tổ chức lơn, nơi 3 công ty con hoán đổi

CEO của họ:

- Phạm Minh Tuấn, khi đó là Giám đốc điều hành của Hệ thống Thông tin FPT và là cựuEVP của Phần mềm FPT, được hoán đổi làm Giám đốc điều hành mới của Phần mềm FPT.

- Hoàng Việt Anh, Giám đốc điều hành của FPT, được thăng chức thành Phó Tổng Giámđốc và Giám đốc điều hành FPT, FPT Telecom

- Nguyễn Văn Khao, Giám đốc điều hành của FPT Telecom, được thăng chức Phố TổngGiám đốc và Giám đốc điều hành của FPT, Hệ thống thông tin FPT

Vào tháng 7/2018, FPT Software đã mua lại Intellinet, một công ty tư vấn có trụ sở tại

Hoa Kỳ với 150 chuyên gia tư vẫn cấp cao với doanh thu 30 triệu đô la Thỏa thuận được ướctính đạt 30-50 triệu đô la Ngày hôm đó, FPT Nhật Bản cũng đạt được lực lượng lao động 1000nhân viên (không bao gồm ở nước ngoài), trở thành công ty Việt Nam lớn nhất tại Nhật Bản vànằm trong số 40 công ty CNTT hàng đầu của Nhật Bản Công ty cũng được chính quyền ViệtNam bật đèn xanh để kiểm tra chiếc xe không người lái của mình trên đường thực tế

2 Cơ cấu tổ chức.

Từ năm 2016, FPT Software được tổ chức thành 2 nhóm riêng biệt: 9 đơn vị kinh doanh(Được đặt tên là Đơn vị chiến lược Fsoft hoặc FSU) và 4 nhóm chi nhánh ở nước ngoài.\

* Danh sách các FSU:

FSU1 Fsoft Strategic Unit 1 Phụ trách và giao hàng cho thị trường nói Tiếng

AnhFSU2 Fsoft Strategic Unit 2 Phụ trách và giao hàng cho các nước Đông Á

(Nhật Bản, Hàn Quốc, Đài Loan, Trung Quốc)DTL Digital Tranformation in

Logistic

Phụ trách phát triển tên miền và Giao hàng choLogistics và Chăm sóc sức khỏe

FSG Finance Services Group Phụ trách phát triển và phân phối tên miền

FGA FPT Global Automotive Phụ trách phát triển và phân phối tên miền cho ô

tô và sản xuấtBPS Business Process

Services

Phụ trách gia công quy trình kinh doanh

thống ERP cho các công ty vừa và nhỏ của NhậtBản

GES Global Enterprise Services Phụ trách giao hàng cho các giải pháp doanh

nghiệpEKB ERP & KPO Business Phụ trách giao hàng cho các dịch vụ ERP & KPO

* Danh sách các chi nhánh ở nước ngoài:

nhân viên

JPG Tập đoàn Nhật Bản

(Japan Group)

Nhật Bản: Tokyo, Sapporo, Shizuoka,

Yokohama, Nagoya, Fuuoka, Osaka,Okinawa

Hàn Quốc: Seoul Trung Quốc: Thượng Hải Đài Loan: Đài Bắc

1.200

Bình Dương (AsiaPacific Group)

Việt Nam: Hà Nội Hồng Kông Thái Lan: Bangkok Myanmar: Yangon Singapore

Malaysia: Kuala Lumpur Philippines: Cebu

Indonesia: Jakarta Australia: Sydney

500

USG Tập đoàn Mỹ (US

Group)

Hoa Kỳ: Chicago, Los Angeles, San

Francisco, Dallas, Denver, Seattle,Atlanta, Minneapolis

3 Sản phẩm tiêu biểu

*Hệ thống dịch thuật tự động:

Hệ thống dịch thuật tự động song ngữ Nhật-Việt được phát triển nhằm hỗ trợ cho các dự

án sản xuất và phát triển phần mềm Hệ thống dịch thuật tự động được phát triển từ công cụ dịchthuật do FPT Software đầu tư phát triển từ trước đây, hệ thống này cho thấy tiềm năng tăng năngsuất lao động cho các thông dịch viên ở FPT Software lên khoảng hai lần

*Project Dashboard:

FSoft Insight (FI) là hệ thống hỗ trợ quản lý dự án phần mềm theo quy trình CMMI-5,được FSOFT phát triển từ năm 2000 và đã phục vụ 1.700 dự án lớn nhỏ ở FSOFT

Test Insight giúp giảm công sức quản lý trong khi đội dự án có thể quản lý requirement,test case, task một cách dễ dàng Việc trao đổi thông tin với khách hàng cũng rất thuận tiện khikhách hàng có thể truy cập vào Test Insight để xem xét sản phẩm và nắm được tiến độ của đội dự

án bất cứ lúc nào

CHƯƠNG II NỘI DUNG CÔNG VIỆC TÌM HIỂU VÀ THỰC HIỆN

I Nội dung nhiệm vụ chính được giao

- Tìm hiểu về công ty và các quy định thông qua khóa học Dayone

- Tìm hiểu các kiến thức về kiểm thử phần mềm

- Học log bug bằng Tool Jira

- Tham gia vào Test trainning

II Nội dung chi tiết

1 Tìm hiểu về Công ty

- Học khóa học Dayone, Tìm hiểu về công ty, cách tổ chức của công ty.

- Làm quen với các công cụ làm việc trong công ty

- Học cách trao đổi, báo cáo, làm việc qua email

2 Các kiến thức về kiểm thử

a- Khái niệm về kiểm thử

Kiểm thử phần mềm có nhiều định nghĩa khác nhau đề xuất bởi nhiều tổ chức hay cánhân khác nhau:

- Định nghĩa của Myer (1979): “ Kiểm thử là quá trình thực thi một chương trình với

mục đích tìm ra lỗi” Theo như định nghĩa này, quá trình kiểm thử bao gồm tất cả các hoạt động

từ kiểm tra mã nguồn được thực hiện bởi trưởng nhóm phát triển, đến việc chạy thử chương trìnhđược tiến hành bởi các đồng nghiệp khác Tất cả các hoạt động trên đều được coi là hoạt độngkiểm thử

- Hai định nghĩa của IEEE (1990):

+ Định nghĩa 1: Kiểm thử phần mềm là quá trình vận hành một hệ thống hoặc một thành

phần của hệ thống với các điều kiện xác định, nhận xét và ghi lại các kết quả tạo ra đánh giá vềnhững khía cạnh của hệ thống hay thành phần hệ thống[1]

+ Định nghĩa 2: Kiểm thử phần mềm là quá trình phân tích các yếu tố phần mềm để phát

hiện những khác biệt giữa chương trình với các điều kiện yêu cầu và đánh giá các đặc điểm củacác yếu tố phần mềm[1]

Theo như định nghĩa 2 việc chạy chương trình như một phần của tiến trình kiểm thử phầnmềm là không cần thiết

- Định nghĩa của Daniel Galin: Kiểm thử phần mềm là một quá trình được tiến hành bởi

một nhóm chuyên viên kiểm thử, trong đó một đơn vị phần mềm, một nhóm các đơn vị được tíchhợp, hoặc cả gói phần mềm được kiểm tra bằng cách chạy các chương trình trên máy tính Tất cảcác bước kiểm tra liên được tiến hành theo các thủ tục kiểm thử và các trường hợp kiểm thử đãđược thông qua[1]

+ Các thủ tục kiểm thử đã được thông qua: Quá trình kiểm thử được thực hiện theo kếhoạch kiểm thử và các thủ tục kiểm thử được thông qua phù hợp với các thủ tục đảm bảo chấtlượng phần mềm được thông qua bởi tổ chức phát triển phần mềm

+ Các trường hợp kiểm thử được thông qua: Các trường hợp kiểm thử được định nghĩađầy đủ trong kế hoạch kiểm thử Không có sự thiếu sót hoặc bổ sung nào được mong đợi xảy ratrong suốt quá trình thực thi kiểm thử

- Định nghĩa tổng quan lại như sau: Kiểm thử phần mềm là quy trình được sử dụng để

đánh giá, kiểm tra chất lượng phần mềm ở nhiều khía cạnh khác nhau dựa trên các yêu cầu củangười sử dụng đối với sản phẩm phần mềm, nhằm đảm bảo phần mềm hoạt động tốt trong cácmôi trường, các trường hợp khác nhau

Có 4 mức độ nghiêm trọng của lỗi trong quá trình kiểm thử:

Lỗi (Error): Con người luôn có thể phạm lỗi Khi lập trình viên phạm lỗi trong lập trình,

ta gọi các lỗi đó là bug Lỗi có thể phát tán Chẳng hạn, một lỗi về xác định yêu cầu có thể dẫnđến sai lầm về thiết kế và càng sai khi lập trình theo thiết kế này Lỗi là nguyên nhân dẫn đến sai

Sai (Fault): Sai là kết quả của lỗi, hay nói khác đi, lỗi sẽ dẫn đến sai Cũng có thể nói sai

là một biểu diễn của lỗi dưới dạng một biểu thức, chẳng hạn chương trình, văn bản, sơ đồ dòng

dữ liệu, biểu đồ lớp, v.v Sai có thể khó phát hiện Khi nhà thiết kế mắc lỗi bỏ sót trong quá trình

thiết kế, sai về kết quả gây ra do lỗi đó là cái gì đó bị thiếu Sai về nhiệm vụ xuất hiện khi vào saithông tin, còn sai về bỏ quên xuất hiện khi không vào đủ thông tin Loại sai về bỏ quên khó pháthiện và khó sửa hơn loại sai về nhiệm vụ.

Thất bại (Failure): Thất bại xuất hiện khi một lỗi được thực thi Có hai điều cần lưu ý

trong định nghĩa này là: một là thất bại chỉ xuất hiện ở dạng có thể được thực thi mà thôngthường là mã nguồn, hai là các thất bại chỉ liên kết với các lỗi về nhiệm vụ Câu hỏi là các thấtbại tương ứng với các lỗi về bỏ thì quên được xử lý thế nào và những lỗi không bao giờ đượcthực thi, hoặc không được thực thi trong khoảng thời gian dài cần được xử lý ra sao VirusMichaelangelo là một ví dụ về lỗi loại này Nó chỉ được tiến hành vào ngày sinh củaMichaelangelo, tức ngày 6/3 mà thôi Câu trả lời nằm ở chỗ: việc khảo sát, tức là phân tích vàduyệt mã, thiết kế hoặc đặc tả có thể ngăn chặn nhiều thất bại bằng cách phát hiện ra các lỗithuộc cả hai loại

Sự cố (Incident): Một khi thất bại xuất hiện, nó có thể hiển thị hoặc không hiển thị, tức

là rõ ràng hoặc không rõ ràng đối với người dùng hoặc người kiểm thử Sự cố nhằm giúp đểnhận biết về sự xuất hiện của thất bại Sự cố là triệu chứng liên kết với một thất bại và giúp chongười dùng hoặc người kiểm thử nhận biết về sự xuất hiện của thất bại này

b- Các nguyên tắc cơ bản của kiểm thử

Có 7 nguyên tắc cơ bản cần chú ý khi kiểm thử phần mềm, đó là:

- Kiểm thử để chứng minh sự có mặt của lỗi và không chứng minh điều ngược lại:

kiểm thử có thể cho thấy sự có mặt của lỗi nhưng không thể chứng minh được ngược lại làchương trình không có lỗi Việc kiểm thử giảm nguy cơ không tìm thấy lỗi trong phần mềmnhưng ngay cả khi không tìm thấy lỗi thì cũng không thể chứng minh được sản phẩm phần mềmđược phát triển hoàn toàn chính xác

- Không thể kiểm thử toàn bộ: Việc kiểm thử không thể thực hiện được cho tất cả mọi

trường hợp kiểm thử Do vậy, thay vì kiểm thử mọi khía cạnh, ta phải tập trung vào kiểm thửnhững yếu tố quan trọng và nhiều rủi ro

- Kiểm thử sớm: Các hoạt động kiểm thử nên bắt đầu càng sớm càng tốt trong vòng đời

phát triển phần mềm, và nên tập trung vào những mục tiêu kiểm thử nhất định

- Phân cụm lỗi: Một số lượng nhỏ các mo-dun phần mềm có thể chứa hầu hết các lỗi

được phát hiện ra trong suốt quá trình kiểm thử hoặc tập trung hầu hết các lỗi vận hành

- Kiểm thử ngược: Nếu một phương pháp kiểm thử được lặp đi lặp lại nhiều lần, các

trường hợp kiểm thử giống nhau sẽ không phát hiện được triệt để lỗi mới Để khắc phục điều này

ta có thể sử dụng nguyên tắc “kiểm thử ngược”, các trường hợp kiểm thử cần phải được xem xét

và duyệt lại một cách đều đặn và việc kiểm thử mới cần phải được viết lại để thực thi những phầnkhác của phần mềm hay hệ thống để tìm ra những lỗi tiềm ẩn

- Kiểm thử phụ thuộc vào ngữ cảnh: Việc kiểm thử được thực hiện trong những hoàn

cảnh khác nhau thì khác nhau

- Sai lầm về việc không có lỗi: Tìm kiếm và sửa lỗi không thể giúp được gì nếu hệ thống

không dùng được hoặc không đáp ứng được yêu cầu và sự mong đợi của khách hàng

c- Các mô hình kiểm thử

Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất cứ lúc nàotrong quá trình phát triển phần mềm Theo truyền thống thì các nỗ lực kiểm thử được tiến hànhsau khi các yêu cầu được xác định và việc lập trình được hoàn tất, nhưng trong Agile (là một tậphợp các phương pháp phát triển phần mềm linh hoạt dựa trên việc lặp đi lặp lại và gia tăng giá trị)thì việc kiểm thử được tiến hành liên tục trong suốt quá trình xây dựng phần mềm Như vậy, mỗimột phương pháp kiểm thử bị chi phối theo một quy trình phát triển phần mềm nhất định

Dưới đây là một số mô hình phổ biến:

+ Mô hình truyền thống (thác nước)+ Mô hình chữ V (V Model) + Mô hình xoắn ốc

+ Mô hình lặp, tăng trưởng nhanh+ Mô hình Agile

+ Mô hình ScrumScrum là mô hình được FPT áp dụng trong quá trình kiểm thử đảm bảo chất lượng phầnmềm

Hình 1 Quy trình scrum

Scrum là một phương thức phát triển phần mềm chỉ ra cách để Team (nhóm phát triển)

làm việc một cách hiệu quả để tạo ra sản phẩm phần mềm Với nguyên tắc chủ đạo là chia nhỏphần mềm cần sản xuất ra thành các phần nhỏ để phát triển (các phần nhỏ này phải độc lập vàRelease được), lấy ý kiến khách hàng và thay đổi cho phù hợp ngay trong quá trình phát triển đểđảm bảo sản phẩm release, đáp ứng được những gì khách hàng mong muốn

Có 3 vai trò quan trọng trong Scrum Testing, đó là: Product Owner, Scrum Master vàDevelopment Team

Hình 2 Vai trò trong Scrum Testing

Product Owner (PO):

+ Là người định nghĩa các yêu cầu của sản phẩm (thông thường là khách hàng)

+ Quyết định ngày release cũng như các tính năng tương ứng cần phải hoàn thành+ Ưu tiên các freature dựa trên giá cả và lợi nhuận

+ Chịu trách nhiệm cho sự thành công của dự án+ Có thể chấp nhận hay hủy bỏ kết quả của công việc

Scrum Master:

+ Quản lý cả team và năng suất của team+ Duy trì block list và loại bỏ những rào cản trong việc phát triển+ Phối hợp các vai trò và chức năng trong dự án

+ Đảm bảo team không gặp những trở ngại, đụng chạm bên ngoài+ Được mời đến các cuộc họp Daily Scrum, Sprint review và Planning meeting

Team phát triển:

+ Team thường gồm 5-9 người, bao gồm: developer, designer và tester,…

+ Team tổ chức và lên kế hoạch cho công việc của mình+ Có quyền làm mọi thứ trong phạm vi project để đạt được mục tiêu của sprint+ Tích cực tham gia các hoạt động hằng ngày của dự án

d- Các mức độ kiểm thử

Hình 3 Các mức độ kiểm thử

*Unit Testing- Kiểm thử mức đơn vị

Kiểm thử đơn vị là việc kiểm thử các đơn vị chương trình một cách độc lập Thế nào làmột đơn vị chương trình? Câu trả lời phụ thuộc vào ngữ cảnh công việc Một đơn vị chươngtrình là một đoạn mã nguồn như hàm hoặc phương thức của một lớp, có thể được gọi từ ngoài,

và cũng có thể được gọi từ các đơn vị chương trình khác Đơn vị cũng còn được gọi là một đơnthể kết hợp sao cho nó có thể thực thi một cách độc lập Đơn vị chương trình cần được kiểm thửriêng biệt để phát hiện lỗi trong nội tại và khắc phục chúng trước khi được tích hợp với các đơn

vị khác Kiểm thử đơn vị thường được thực hiện bởi chính tác giả của chương trình (lập trìnhviên), và có thể tiến hành theo 2 giai đoạn: kiểm thử đơn vị tĩnh và kiểm thử đơn vị động

*Intergration Testing- Kiểm thử tích hợp

Mức kế tiếp với kiểm thử đơn vị là kiểm thử tích hợp Sau khi các đơn vị chương trình đểcấu thành hệ thống đã được kiểm thử, chúng cần được kết nối với nhau để tạo thành hệ thốngđầy đủ và có thể làm việc Công việc này không hề đơn giản và có thể có những lỗi về giao diệngiữa các đơn vị, và cần phải kiểm thử để phát hiện những lỗi này

*System Testing- Kiểm thử hệ thống

Kiểm thử mức này được áp dụng khi đã có một hệ thống đầy đủ sau khi tất cả các thànhphần đã được tích hợp Mục đích của kiểm thử hệ thống là để đảm bảo rằng việc cài đặt tuân thủcác yêu cầu được đặc tả của người dùng Công việc này tốn nhiều công sức, vì có nhiều khíacạnh về yêu cầu người dùng cần được kiểm thử

*Acceptance Testing- Kiểm thử chấp nhận

Khi kiểm thử hệ thống đã được hoàn tất và sản phẩm cần kiểm thử thỏa mãn các yêu cầucủa đặc tả phần mềm hệ thống, sản phẩm đó vẫn chưa sẵn sàng để đưa vào sử dụng Lý do làphần mềm cần kiểm thử cần trải qua giai đoạn kiểm thử chấp nhận để kiểm tra xem sản phẩm cóđáp ứng các yêu cầu của khách hàng Kiểm thử chấp nhận được thực thi bởi chính các kháchhàng nhằm đảm bảo rằng sản phẩm phần mềm làm việc đúng như họ mong đợi

Có 2 loại kiểm thử chập nhận: kiểm thử chấp nhận người dùng, được tiến hành bởi ngườidùng; và kiểm thử chấp nhận doanh nghiệp, được tiến hành bởi nhà sản xuất ra sản phẩm phầnmềm.

e- Các phương pháp và quy trình kiểm thử

Ta phân loại kiểm thử dựa vào các yếu tố: chiến lược kiểm thử, phương pháp kiểm thử và

kỹ thuật kiểm thử

Dựa vào các chiến lược kiểm thử, ta có thể phân chia kiểm thử thành hai loại: kiểm thửthủ công và kiểm thử tự động Theo phương pháp tiến hành kiểm thử ta chia kiểm thử thành 2loại: kiểm thử tĩnh và kiểm thử động Dựa vào kỹ thuật kiểm thử ta có thể phân chia kiểm thửthành 3 loại: kiểm thử hộp đen, kiểm thử thử hộp trắng và kiểm thử hợp xám

* White box testing- Kiểm thử hộp trắng

Kiểm thử hộp trắng (được biết đến như là kiểm thử tính rõ ràng của hộp, kiểm thử hộpkính, kiểm thử hộp trong suốt và kiểm thử cấu trúc) giúp kiểm thử được cấu trúc nội bộ hoặchoạt động của một chương trình, như tương phản với chức năng được bộc lộ của người dùngcuối Một góc nhìn nội bộ của hệ thống trong kiểm thử hộp trắng giống như là các kỹ năng lậptrình được sử dụng để thiết kế ra các tình huống kiểm thử Các tester lựa chọn yếu tố đầu vào đểthực hiện đường dẫn thông qua các mã và xác định được kết quả đầu ra thích hợp Điều nàytương tự các nút kiểm thử trong một mạch, ví dụ như kiểm thử thông mạch

Hình 4: Kiểm thử hộp trắng

Trong khi kiểm thử hộp trắng có thể được áp dụng tại đơn vị, tích hợp hệ thống và cáccấp độ của quá trình kiểm thử phần mềm, nó thường được thực hiện ở cấp đơn vị Nó có thểkiểm thử đường dẫn trong một đơn vị, liên kết giữa các đơn vị trong quá trình tích hợp, và giữacác hệ thống con trong một hệ thống Mặc dù phương pháp này thiết kế kiểm thử có thể pháthiện ra nhiều lỗi hoặc các vấn đề, nó có thể không phát hiện các phần chưa thực hiện của các đặcđiểm kỹ thuật hoặc yêu cầu thiếu sót.

Các kỹ thuật được sử dụng trong kiểm thử hộp trắng, bao gồm:

+ Kiểm thử API (giao diện lập trình ứng dụng) – kiểm thử ứng dụng có sử dụngcác API công cộng và cá nhân

+ Kiểm thử bao phủ mã – tạo ra các bài kiểm thử để đáp ứng một số tiêu chí củabảo hiểm mã (ví dụ, các nhà thiết kế kiểm thử có thể tạo ra các bài kiểm thử để làm tất cả các câulệnh trong chương trình được thực hiện ít nhất một lần)

+ Phương pháp chèn lỗi – cố tính đưa ra những lỗi lầm để đánh giá hiệu quả củacác chiến lược kiểm thử

+ Phương pháp kiểm thử đột biến+ Phương pháp thử tĩnh

Các công cụ bao phủ mã có thể đánh giá đầy đủ của một bộ kiểm thử đã được tạo ra bằngphương pháp bất kỳ nào đó, bao gồm cả kiểm thử hộp đen Điều này cho phép nhóm nghiên cứuphần mềm kiểm thử các bộ phận của một hệ thống mà hiếm khi được kiểm thử và đảm bảo rằngcác điểm chức năng quan trọng nhất đã được kiểm thử Bao phủ mã giống như một phần mềmmetric có thể báo cáo tỷ lệ phần trăm cho:

+ Bao phủ chức năng: dựa vào các báo cáo của chức năng này thực hiện+ Bao phủ câu lệnh: dựa vào các báo cáo về số lượng các dòng được thực hiện đểhòan thành kiểm thử

100% bao phủ câu lệnh đảm bảo rằng tất cả các đường dẫn mã, hoặc các nhánh (trongđiều kiện của luồng điểu khiển) được thực hiện ít nhất một lần Điều này hữu ích trong việc đảm

bảo đúng chức năng nhưng không đủ kể từ khi các mã tương tự có thể thực hiện tiến trình xử lý

dữ liệu đầu vào khác nhau dù đúng hoặc không

* Black box testing - Kiểm thử hộp đen

Kiểm thử hộp đen coi phần mềm như là một “hộp đen”, kiểm thử chức năng mà khôngcần bất kỳ kiến thức về cấu trúc và hành vi bên trong phần mềm Các Tester chỉ biết về những gìphần mềm phải làm mà không biết là nó làm như thế nào Phương pháp kiểm thử hộp đen baogồm:

+ Phân vùng tương đương+ Phân tích giá trị biên+ Bảng chuyển đổi trạng thái+ Kiểm thử bảng quyết định+ Kiểm thử chéo

+ Kiển thử dựa trên mô hình

Hình 5 Kiểm thử hộp đen

* Grey box testing - Kiểm thử hộp xám

Kiểm thử hộp xám liên quan đến hiểu biết về cấu trúc dữ liệu bên trong và các thuật toáncho mục đích của các bài kiểm thử thiết kế Khi thực hiện những bà i kiểm thử với User hoặcmức độ hộp đen, Tester không nhất thiết phải truy cập vào mã nguồn của phần mềm Ta có thểthao tác với dữ liệu đầu vào và đầu ra rõ ràng ở bên ngoài của “hộp đen” mà chúng được hệthống gọi ra trong quá trình kiểm thử Sự phân biệt này là đặc biệt quan trọng khi tiến hành kiểm

thử tích hợp giữa hai module được viết mã bởi hai nhà phát triển khác nhau, mà ở đó chỉ có cácgiao diện được bộc lộ ra để kiểm thử.

Tuy nhiên, các kiểm thử mà yêu cầu thay thế một kho lưu trữ dữ liệu back-end như một

cơ sở dữ liệu hoặc một tập tin đăng nhập không xác định như hộp xám, người dùng sẽ khôngthay đổi các kho lưu trữ dữ liệu trong khi sản phẩm vẫn đang hoạt động bình thường

Kiểm thử hộp xám cũng có thể bao gồm kỹ thuật đảo ngược để xác định đối tượng, giá trịbiên hoặc các thông báo lỗi

Hình 6 Kiểm thử hộp xámKhi biết được những khái niệm cơ bản về cách thức các phần mềm hoạt động như thếnào, Tester thực hiện kiểm thử phần mềm từ bên trong tốt hơn so với bên ngoài Thường, mộtTester hộp xám sẽ được phép thiết lập một môi trường kiểm thử bị cô lập với các hoạt động nhưgieo một cơ sở dữ liệu Các kiểm thử viên có thể quan sát trạng thái của sản phẩm được kiểm thửsau khi thực hiện hành động nhất định giống như việc thực hiên các câu lệnh SQL đối với cơ sở

dữ liệu, và sau đó thực hiện truy vấn để đảm bảo rằng những thay đổi dự kiến đã được phản ánh.Kiểm thử hộp xám thực hiện kịch bản kiểm thử thông minh, dựa trên thông tin hạn chế Điều này

sẽ đặc biệt áp dụng cho các kiểu xử lý dữ liệu kể cả xử lý ngoại lệ và cứ thế

* Quy trình kiểm thử

Tùy vào từng tổ chức, hệ thống, ngữ cảnh, mức độ rủi ro của phần mềm mà quy trìnhkiểm thử phần mềm có thể gồm nhiều bước khác nhau Nhưng nhìn chung, mọi quy trình kiểmthử đều có những bước cơ bản như quy trình dưới đây:

f- Độ ưu tiên và độ nghiêm trọng của bug trong quản lý bug

Trong kiểm thử phần mềm thì 2 khái niệm Độ ưu tiên (Priority) và Độ nghiêm trọng(Severity) là những khái niệm cơ bản trong quản lý bug Nó đã trở nên quá quen thuộc và phổbiến, tuy nhiên đôi khi chúng ta vẫn nhầm lẫn và không phân biệt được ý nghĩa cũng như sựkhác nhau giữa hai khái niệm đó Mặc dù độ ưu tiên và độ nghiêm trọng của bug không phải lànhưng yếu tố quan trọng nhất, nhưng một khi xác định một cách đúng đắn sẽ giúp chúng ta làmviệc hiệu quả, tiết kiệm thời gian, có thể đánh giá đúng tiến độ cũng như chất lượng của sảnphẩm

* Độ ưu tiên (Priority) của Bug

Độ ưu tiên của bug xác định thứ tự sửa bug Thực tế thì đội phát triển không thể fix hếttất cả các bug của sản phẩm cùng một lúc, do vậy sẽ cần dựa vào độ ưu tiên của bug để xác địnhbug nào sửa trước, bug nào sửa sau

Tương tự mức độ nghiêm trọng, mức độ ưu tiên cũng như ý nghĩa của chúng có thể sẽkhác nhau ở những sản phẩm, dự án khác nhau Thông tường mức độ nghiêm trọng của bug đượcchia thành 3 mức cơ bản nhất:

+ P1- High: Bug phải được sửa ngay lập tức sau khi phát hiện ra bug+ P2- Normal: Bug có thể được sửa trong lần cập nhật phiên bản sau+ P3- Low: Bug không cần sửa ngay, có thể sửa sau khi bug High và Normal đãđược sửa hết

Vậy chúng ta sẽ dựa vào đâu để xác định độ ưu tiên? Bug nào sửa trước, bug nào sửa sau(hoặc không sửa)? Chỉ cần dựa vào độ nghiêm trọng của bug Bug nào nghiêm trọng nhất, tácđộng đến người dùng nhiều nhất thì sẽ được ưu tiên sửa trước Bug nào ít nghiêm trọng hơn sẽđược sửa sau Đúng, nhưng không phải lúc nào cũng đúng Nó còn tùy thuộc vào nhiều yếu tố.Giả sử chúng ta tìm được một bug làm sập hệ thống hoặc chức năng chính không hoạt động