báo cáo thực tập automation and manual qc

Kỹ thuật kiểm thử này được sử dụng để kiểm tra cácnhiệm vụ lặp đi lặp lại và các nhiệm vụ thử nghiệm khác khó thực hiện thủ công.Manual testing là quá trình kiểm thử phần mềm được thực h

GIỚI THIỆU CÔNG TY THỰC TẬP

Giới thiệu công ty

Contemi là một thương hiệu đang phát triển nhanh chóng, cung cấp các giải pháp hệ thống CNTT cho các công ty bảo hiểm ở Châu Á và Scandinavia Được thành lập vào năm 2001 tại Na Uy và Vương quốc Anh, bởi các doanh nhân thành đạt trong lĩnh vực bảo hiểm, những người muốn thương mại hóa hệ thống và kiến thức chuyên môn mà họ đã sử dụng để thành công.

Contemi Việt Nam là thành viên của các công ty tư nhân 100% vốn thuộc Tập đoànContemi có trụ sở tại Vương quốc Anh, Na Uy và Việt Nam Chuyên cung cấp sự kết hợp phong phú của các dịch vụ kỹ thuật, bảo hiểm và kinh doanh phù hợp với hầu hết các doanh nghiệp bảo hiểm Contemi hiện đang phụ trách phát triển, triển khai và quản lýCNTT cho một số doanh nghiệp bảo hiểm ở Châu Âu và Châu Á Contemi Việt Nam đang phát triển nhanh chóng để đáp ứng nhu cầu mở rộng Tập đoàn, đặc biệt là tại các thị trường Châu Á.

 Tài sản và quản lý tài sản

Giải pháp Contemi Wealth Intelligence (WIN), một bộ các front, middle và back office mô-đun được tích hợp đầy đủ, cung cấp cho các nhà quản lý đầu tư và tài sản sử dụng tất cả các công cụ cần thiết để phục vụ và giữ chân khách hàng hiện tại, đảm bảo các yêu cầu tuân thủ và tự động hóa các quy trình đầu cuối Tính linh hoạt của hệ thống đảm bảo rằng hệ thống được định cấu hình theo nhu cầu của khách hàng và có thể hỗ trợ nhiều loại hình kinh doanh bao gồm tư vấn, chỉ thực thi, khách hàng cá nhân và hoạt động tổ chức.

Hệ thống Contemi Wealth Intelligence đáp ứng các nhu cầu văn phòng bao gồm, tìm kiếm khách hàng tiềm năng, giới thiệu, quản lý vòng đời của khách hàng, quản lý danh mục đầu tư, đo lường hiệu suất, giao dịch, quản lý đơn đặt hàng, lưu ký và thanh toán, hành động của công ty và phân tích & báo cáo kinh doanh.

 Ngân hàng và thị trường vốn

Các giải pháp công nghệ tích hợp và có khả năng mở rộng cao để đơn giản hóa việc tuân thủ, minh bạch và quản lý rủi ro cho các bên tham gia thị trường vốn.

Các giải pháp thị trường vốn Contemi cung cấp một loạt các chức năng để hỗ trợ giải quyết, sổ sách và hồ sơ, bảo dưỡng tài sản, quản lý và kiểm soát hoạt động, truy cập dữ liệu thời gian thực và kế toán hành chính, đối chiếu và xử lý hành động của công ty, v.v. Các giải pháp end-to-end giúp các công ty xử lý hiệu quả hơn dòng chảy toàn cầu ngày càng tăng của họ và loại bỏ các quy trình thủ công, phi tiêu chuẩn trở thành lực cản cho doanh nghiệp và rủi ro hoạt động.

 BANCASSURANCE – Phân phối bảo hiểm qua kênh ngân hàng

Mô hình phân phối Bancassurance đang phát triển khi ngày càng có nhiều công ty bảo hiểm và ngân hàng thành lập các liên minh mới trên toàn cầu Một dự án bancassurance có lợi nhuận đòi hỏi các hoạt động hiệu quả đối với ngân hàng, công ty bảo hiểm và khách hàng Việc tích hợp liền mạch với các sản phẩm bảo hiểm hiện có và các ứng dụng ngân hàng lõi là cần thiết để làm cho mối quan hệ bancassurance thành công.

Giải pháp Bancassurance của Contemi được thiết kế cho các tổ chức tài chính cung cấp dịch vụ bancassurance và một kênh phân phối bảo hiểm trên các thị trường khác nhau.

Nó bao gồm toàn bộ hành trình của một khách hàng bảo hiểm mua lại, bán, dịch vụ và quản lý quan hệ chỉ số đo lường, hỗ trợ và tự động hóa các quy trình kinh doanh cần thiết cho tổ chức tài chính.

 Nhà môi giới bảo hiểm

Một bộ giải pháp có thể cấu hình và linh hoạt cao được xây dựng dành riêng cho Nhà môi giới bảo hiểm.

Các công ty môi giới có nhiều hình dạng và quy mô Có thể là một tuyên bố táo bạo khi nói rằng Contemi có một giải pháp phù hợp cho tất cả các nhà môi giới để đáp ứng tất cả các nhu cầu của họ - nhưng Contemi tin rằng chúng tôi có các mô-đun sẽ phục vụ hầu hết và bất kỳ điều chỉnh cụ thể nào một nhà môi giới có thể cần.

 Nhà khởi nghiệp bảo hiểm

Các công ty khởi nghiệp mới đang thiết lập các dịch vụ Bảo hiểm mới với các giải pháp CNTT linh hoạt Các giải pháp của Contemi được phát triển để đáp ứng các nhu cầu trong tương lai đối với Bảo hiểm P&C (Property & Casualty) Thành công trong thời đại mới là đặt khách hàng lên hàng đầu, tạo ra lòng trung thành và cung cấp các giải pháp phù hợp cho khách hàng của bạn Với Contemi là đối tác, bạn sẽ nhận được giải pháp Bảo hiểm P&C hiện đại được phát triển cho thị trường bảo hiểm trong tương lai.

1.1.3 Khách hàng và đối tác của công ty

Contemi luôn tự hào bởi sự thành công của khách hàng trên toàn thế giới Với công nghệ tiên tiến, các giải pháp tiên tiến nhất, đội ngũ sáng tạo và các đối tác công nghệ đáng tin cậy, Contemi trao quyền cho khách hàng của mình để trở thành những người dẫn đầu trong thế giới ngày càng phát triển của các nền tảng đám mây và kỹ thuật số Contemi tin tưởng vào việc hình thành các mối quan hệ đối tác kinh doanh và công nghệ có ý nghĩa để thúc đẩy hoạt động kinh doanh của khách hàng và giúp họ phát triển trong không gianFinTech mới.

- Các khách hàng của Contemi:

Hình 2: Các khách hàng của Contemi

- Các đối tác đáng tin cậy:

Hình 3: Các đối tác của Contemi

Vị trí thực tập – Automation and Manual Testing

Automation Testing là một kỹ thuật kiểm thử phần mềm để kiểm tra và so sánh kết quả thực tế với kết quả mong đợi Automation Testing được thực hiện bằng cách viết các kịch bản thử nghiệm và sử dụng công cụ Kỹ thuật kiểm thử này được sử dụng để kiểm tra các nhiệm vụ lặp đi lặp lại và các nhiệm vụ thử nghiệm khác khó thực hiện thủ công.

Manual testing là quá trình kiểm thử phần mềm được thực hiện bằng tay mà không sử dụng công cụ tự động hoặc kịch bản tự động Người kiểm thử thực hiện các thử nghiệm theo các bước được xác định để đảm bảo rằng ứng dụng hoạt động đúng và đáp ứng đúng với các yêu cầu Phương pháp này giúp phát hiện lỗi và đánh giá trải nghiệm người dùng một cách chặt chẽ

Mô tả công việc: Các kỹ sư đảm bảo chất lượng phần mềm làm việc với các nhà phát triển phần mềm để cải thiện các sản phẩm phần mềm trong quá trình phát triển Họ chạy các bài kiểm tra (cả thủ công và tự động hóa) trên phần mềm hoặc ứng dụng và phân tích

10 các khiếm khuyết để cải thiện sản phẩm Hầu hết các nhà tuyển dụng yêu cầu bằng cử nhân trong một chủ đề liên quan.

1.2.2 Yêu cầu vị trí thực tập

- Đã tốt nghiệp hoặc sinh viên năm cuối tại các trường học về ngành Công Nghệ Thông tin

- Có kinh nghiệm, kiến thức về quy trình kiểm thử và các phương pháp kiểm thử

- Hiểu biết về các test case, test plan, test report

- Có kiến thức về automation testing và sử dụng những công cụ hỗ trợ liên quan (Selenium, Katalon, TestNG…)

- Có kĩ năng lập trình, tư duy tốt có thể làm việc trên các ngôn ngữ lập trình java, javascript

- Tinh thần làm việc nhóm tốt và trách nhiệm cao

- Kĩ năng nghiên cứu và giải quyết vấn đề tốt

- Có kiến thức về Agile – Scrum là một lợi thế

- Tiếng Anh tốt là một lợi thế.

KIẾN THỨC – KỸ NĂNG ĐÃ ĐƯỢC TẬP HUẤN

Kiểm thử thủ công – Manual Testing

Manual testing là một loại kiểm thử phần mềm trong đó người kiểm tra thực hiện chạy test case một cách thủ công mà không dùng bất cứ một công cụ tự động nào Manual Testing là kiểu test nguyên thủy nhất trong các loại kiểm tra giúp tìm ra lỗi trong hệ thống phần mềm Bất kì ứng dụng nào cũng đều phải được kiểm tra một cách thủ công trước khi có thể thực hiện test tự động Manual Testing đòi hỏi nhiều nhân lực hơn nhưng nó là cần thiết để kiểm tra tính khả thi của tự động hóa.

3.1.2 Các loại kiểm thử phần mềm

 Unit testing ( Kiểm thử đơn vị)

Unit test là cấp độ kiểm thử thấp nhất trong các loại kiểm thử phần mềm Với unit test, nhiệm vụ của tester là kiểm thử các phần riêng lẻ của phần mềm như: hàm (Function), phương thức (Method), lớp (Class), thủ tục (Procedure) Hình thức kiểm thử này thường được áp dụng trong giai đoạn phát triển, khi các phần code được cô lập để kiểm tra tính chính xác của các đơn vị riêng biệt Unit test nói chung khá rẻ để tự động hóa và có thể được chạy rất nhanh bởi một máy chủ tích hợp liên tục.

Integration Testing (Kiểm thử tích hợp) Đúng như tên gọi của nó, việc kiểm thử tích hợp có tác dụng xác minh xem các mô- đun (modules) khác nhau của ứng dụng của bạn có hoạt động tốt cùng nhau Ví dụ: kiểm thử sự tương tác với cơ sở dữ liệu hoặc đảm bảo rằng các microservices hoạt động cùng nhau như mong muốn Việc thực hiện loại kiểm thử này tốn kém hơn vì chúng yêu cầu nhiều phần của ứng dụng được thiết lập và chạy cùng nhau.

 Functional Testing (Kiểm thử chức năng)

Việc kiểm thử chức năng sẽ tập trung vào các yêu cầu nghiệp vụ của một ứng dụng. Đôi khi có sự nhầm lẫn giữa các kiểm thử tích hợp và kiểm thử chức năng Vì cả hai hình thức kiểm thử này đều yêu cầu nhiều thành phần của hệ thống tương tác với nhau Sự khác biệt là kiểm thử tích hợp có thể chỉ đơn giản xác minh rằng bạn có thể truy vấn cơ sở dữ liệu Còn kiểm thử chức năng sẽ mong muốn nhận được một giá trị cụ thể từ cơ sở dữ liệu như được xác định bởi các yêu cầu sản phẩm.

 End-to-end testing (Kiểm tra từ đầu đến cuối)

Kiểm thử end-to-end tái tạo hành vi của người dùng với ứng dụng trong một môi trường ứng dụng hoàn chỉnh Hình thức này giúp xác minh rằng các luồng người dùng (user flow) khác nhau hoạt động như mong đợi Hành vi này có thể đơn giản như tải một trang web hoặc đăng nhập, hoặc các hành vi phức tạp hơn nhiều như: xác minh thông báo qua email, thanh toán trực tuyến, v.v Việc kiểm thử đầu cuối rất hữu ích trong các loại kiểm thử phần mềm, nhưng cũng rất tốn kém để thực hiện và có thể khó duy trì khi chúng được tự động hóa Bạn nên có một vài thử nghiệm đầu cuối quan trọng và dựa nhiều hơn vào các loại thử nghiệm cấp thấp hơn (kiểm thử đơn vị và tích hợp).

 Acceptance Testing (Kiểm thử chấp nhận)

Kiểm thử chấp nhận là các kiểm tra chính thức được thực hiện để xác minh xem hệ thống có đáp ứng các yêu cầu nghiệp vụ của nó hay không Chúng yêu cầu toàn bộ ứng dụng phải được thiết lập và chạy và tập trung vào việc tái tạo các hành vi của người dùng. Nhưng ta có thể tiến xa hơn, đó là đo lường hiệu suất của hệ thống và từ chối các thay đổi nếu các mục tiêu nhất định không được đáp ứng.

Hình 4: Các loại kiểm thử phần mềm

 Performance Testing (Kiểm thử hiệu suất)

Cách kiểm thử này kiểm tra các hành vi của hệ thống khi nó đang phải chịu lượng tải(loading) lớn Kiểm thử hiệu suất không mang tính chức năng và có thể có nhiều dạng khác nhau để hiểu độ tin cậy, tính ổn định và tính khả dụng của phần mềm Ví dụ: kiểm thử quan sát thời gian phản hồi khi thực hiện một số lượng lớn yêu cầu hoặc xem hệ thống hoạt động như thế nào với một lượng lớn dữ liệu Hình thức này về bản chất là khá tốn kém để thực hiện và chạy, nhưng lại có thể giúp bạn hiểu liệu các thay đổi mới có làm suy giảm hệ thống của bạn hay không.

Smoke Testing (Kiểm thử khói)

Kiểm thử khói là các bài kiểm tra cơ bản giúp kiểm tra chức năng cơ bản của ứng dụng Mục tiêu của kiểm thử khói là đảm bảo rằng các tính năng chính của hệ thống của bạn đang hoạt động như mong đợi Cách kiểm thử phần mềm này được thực hiện ngay sau khi một bản dựng (build) mới được thực hiện để quyết định xem bạn có thể thực hiện các hình thức kiểm thử đắt tiền hơn hay không Kiểm thử khói cũng có thể diễn ra ngay sau khi triển khai để đảm bảo rằng ứng dụng đang chạy đúng cách trong môi trường mới được triển khai.

Bug và vòng đời của bug trong kiểm thử phần mềm

Hình 5: Bug và vòng đời của bug

Bug hay còn gọi là Defect là vấn đề xảy ra đối với một sản phẩm phần mềm khi developer xử lý một dòng hoặc một đoạn code bị lỗi ,mà kết quả đưa ra khác với yêu cầu của khách hàng hoặc người dùng.

3.2.2 Template của một con bug

Một Bug Report là một tài liệu chi tiết về lỗi tìm thấy trong các ứng dụng phần mềm. Báo cáo lỗi bao gồm từng chi tiết về lỗi như title, step thực hiện ra lỗi, expected result, actual resutl, môi trường tìm thấy lỗi, tên người kiểm tra đã tìm thấy lỗi, tên nhà phát triển đã sửa lỗi, v.v Báo cáo lỗi giúp xác định các lỗi tương tự trong tương lai để có thể tránh

22 được lỗi đó 1 bug report thường được viết theo 1 template cố định của dự án, thông thường sẽ bao gồm các nội dung sau:

Title bug : Viết ngắn gọn về lôi đã xảy ra để mọi người nhìn vào có thể hình dung được nó là lỗi gì.

Linked issues: Mục này có thể có hoặc không Nếu có thì thường sẽ là một thông tin, một link nào đó để có thể reference tới spec của KH.

Reproduce steps : Các step cụ thể để developer fix bug có thể nhìn vào và tái hiện lại bug.

Actual result : Là kết quả lỗi hiển thị ra sau khi thực hiện lại các step ở trên.

Expected result : Là kết quả cần phải hiển thị theo đúng spec khi người dùng thực hiện các step trên.

Evidence : Có thể là hình ảnh hoặc video để có thể rõ hơn về lỗi đó.

Testing Environment: Là môi trường nơi tester thực hiện test cùng với các thông tin về nó

Status : Có thể là new, inprogess, testing hoặc done.

Milestone : là khoảng thời gian tìm thấy bug.

Assignee : Là tên của developer thực hiện sẽ fix bug.

Reporter : Tên của tester phát hiện ra bug.

Priority : Mức độ ưu tiên - Có thể cao/ trung bình/ thấp dựa trên mức độ khẩn cấp của tác động mà tại đó lỗi cần được khắc phục tương ứng

Hình 6: Template của một con bug được tạo trên Jira

3.2.3 Vòng đời của bug trong kiểm thử phần mềm

Hình 7:Sơ đồ vòng đời của bug

Mô tả chi tiết từng trạng thái của Bug xuyên suốt 1 vòng đời

Khi tester thực thi test case và đầu ra của test case đó không đúng như kết quả mong đợi, thì họ sẽ gọi đó là bug Nghĩa là có sự khác biệt giữa kết quả mong đợi và kết quả thực tế thì gọi là bug Do đó bug này cần phải được fix Nhưng tester không phải là người fix bug mà là lập trình viên sẽ fix nó.

→ Khi tester tìm thấy bug thì nó sẽ có trạng thái là NEW.

Lỗi được log lên bởi tester Team lead cần xác minh lại bug đó xem có đúng là bug hay không, thì bug có trạng thái OPEN.

Một bug được đánh dấu là Rejected khi bug đó không hợp lệ Nghĩa là thỉnh thoảng tester có thể hiểu sai chức năng và có thể đánh dấu chức năng là bug Trong trường hợp này, bug sẽ bị reject sau khi team lead kiểm tra lại.

Nếu bug là hợp lệ, thì sau đó team lead sẽ kiểm tra xem lỗi đó đã được log người khác hay chưa Nếu đã có người khác log nó, thì team lead sẽ đánh dấu nó là DUPLICATE Còn nếu nó chưa được báo cáo bởi tester khác thì team lead sẽ thực hiện tìm kiếm nó trong scope.

Nếu bug không bị duplicate, nhưng lại không thuộc bản release hiện tại thì sẽ được đánh dấu là Deferred Nghĩa là giả sử bạn đang làm theo mô hình agile, và họ chia yêu cầu dự án thành các sprint, ví dụ chia thành 10 sprint: sprint 1, sprint 2, , sprint 10 Hiện tại đang ở sprint 1, nhưng bug bạn tìm thấy lại có liên quan đến tính năng sẽ được phát triển ở sprint 2, thì bug này sẽ được đánh dấu là DEFERRED. Deferred bug là một bug, nhưng nó sẽ được sửa chữa trong bản release tương lai.

→ Khi một bug là một phần của bản release tương lai thì nó sẽ được đánh dấu là DEFERRED.

Khi bug tìm thấy là hợp lệ, duy nhất và thuộc bản release hiện tại, thì team lead sẽ gán bug đó cho developer.

Khi nhận được bug từ team lead, developer sẽ thực hiện thay đổi để fix bug cho đúng với yêu cầu, và đẩy lại cho tester kiểm tra lại lỗi đó.

Sau khi fix xong bug, và chức năng/tính năng đã sẵn sàng để kiểm thử, thì tester sẽ thực hiện lại những test case lỗi và xác minh lại xem nó đã chạy đúng hay chưa. Việc này gọi là RE-TESTING.

Khi bug đã được fix, đã được kiểm thử lại và nó chạy đúng như yêu cầu thì tester sẽ đánh dấu nó là CLOSED.

Có 2 tình huống mà chúng ta cần phải re-open lại bug:

- Tình huống 1: Khi developer fix bug và tester thực hiện test lại nó, nhưng sau khi re-test, bug đó vẫn xảy ra thì tester sẽ RE-OPEN lại bug và assign cho developer.

- Tình huống 2: Có trường hợp lỗi đã fix và được close xuất hiện lại Trong trường hợp này, tester cần RE-OPEN lại bug đã close và gán nó cho developer.

Kiểm thử tự động – Automation Testing

Trong lĩnh vực kiểm thử phần mềm, thì kiểm thử tự động hay còn gọi là Automation testing đóng một vai trò quan trọng góp phần nâng cao năng suất kiểm thử, giảm thiểu lỗi cũng như sự nhàm chán với việc kiểm thử bằng tay trong một thời gian dài hoặc lặp đi lặp lại.

Kiểm thử tự động là một quá trình xử lý tự động các bước thực hiện một test case. Kiểm thử tự động được thực hiện bởi phần mềm kiểm thử tự động - hay còn gọi là Automation Testing Tool Một số phần mềm kiểm thử tự động nổi tiếng hiện nay như:

- Selenium: Công cụ thử nghiệm Ứng dụng web Cung cấp nhiều hỗ trợ trình duyệt.

- Junit và Nunit: Công cụ chủ yếu được sử dụng để kiểm tra Unit tests.

- QTP: Công cụ cho các ứng dụng không phải web

- Sikuli: Công cụ mã nguồn mở để kiểm tra GUI.

- Soap UI: Công cụ kiểm tra API.

- Rest Assured: Công cụ kiểm tra API.

- Appium: Công cụ hỗ trợ kiểm tra ứng dụng di động.

- Jmeter: Công cụ được sử dụng để kiểm tra hiệu suất.

- Test NG: Test NG không phải là một công cụ tự động hóa, tuy nhiên, nó cung cấp hỗ trợ tuyệt vời cho các tự động hóa được xây dựng bằng selen, appium, v.v

3.3.2 Ưu, nhược điểm của Automation Testing so với Manual Testing

Hình 8: Ưu nhược điểm của Automation testing

- Độ tin cậy cao: công cụ kiểm thử tự động có sự ổn định cao hơn so với con người, đặc biệt trong trường hợp nhiều test cases, nên độ tin cậy cao hơn so với kiểm thử thủ công.

- Khả năng lặp: công cụ kiểm thử tự động ra đời là để giúp cho các tester không phải lặp đi lặp lại các thao tác (ví dụ: nhập dữ liệu, click, check kết quả…) một cách nhàm chán với độ tin cậy và ổn định cao.

- Khả năng tái sử dụng: với một bộ kiểm thử tự động, người ta có thể sử dụng cho nhiều phiên bản ứng dụng khác nhau, đây được gọi là tính tái sử dụng.

- Tốc độ cao: do thực thi bởi máy nên tốc độ của kiểm thử tự động nhanh hơn nhiều so với tốc độ của con người Nếu cần 5 phú để thực thi một test case một cách thủ công thì có thể người ta chỉ cần khoảng 30s để thực thi một cách tự động.

- Chi phí thấp: nếu áp dụng kiểm thử tự động đúng cách, người ta có thể tiết kiệm được nhiều chi phí, thời gian và nhân lực, do kiểm thử tự động nhanh hơn nhiều so với kiểm thử thủ công, đồng thời nhân lực cần để thực thi và bảo trì scripts không nhiều.

- Khó mở rộng, khó bảo trì: trong cùng một dự án, để mở rộng phạm vi cho kiểm thử tự động khó hơn nhiều so với kiểm thử thủ công vì cập nhật hay chỉnh sửa yêu cầu nhiều công việc như debug, thay đổi dữ liệu đầu vào và cập nhật code mới.

- Khả năng bao phủ thấp: do khó mở rộng và đòi hỏi nhiều kỹ năng lập trình nên độ bao phủ của kiểm thử tự động thấp xét trên góc nhìn toàn dự án.

- Vấn đề công cụ và nhân lực: hiện nay cũng có nhiều công cụ hỗ trợ kiểm thử tự động khá tốt nhưng chúng vẫn còn nhiều hạn chế Ngoài ra nhân lực đạt yêu cầu(có thể sử dụng thành thạo các công cụ này) cũng không nhiều.

Cucumber

Cucumber, testing framework hỗ trợ Behavior Driven Development (BDD), cho phép người dùng định nghĩa hành vi hệ thống với ngữ nghĩa tiếng anh thông qua cú pháp Gherkin Cucumber hướng tới việc viết test “as cool as cucumber” mà bất kỳ ai cũng có thể hiểu cho dù họ không có chuyên môn kĩ thuật Ví dụ như các nền tảng quen thuộc như Selenium thì thường chỉ người viết test hoặc có kĩ năng lập trình mới hiểu được những gì đang test, còn khác hàng hoặc các bên liên quan thì không đọc ngay code để hiểu mà họ cần hiểu qua tài liệu.

Trong BDD, người dùng (business analysts – người phân tích nghiệp vụ, product owners – người sỡ hửu sản phẩm) sẽ viết kịch bản(scenarios) hoặc acceptance test ( kiểm thử chấp nhận) mô tả hành vi của hệ thống từ quan điểm của khách hàng trước và trong giai đoạn phát triển Cucumber và BDD giải quyết hạn chế rất hay gặp trong các dự án phần mềm: mỗi người hiểu hệ thống một cách khác nhau.

BDD có khả năng tạo ra các kịch bản test dựa trên góc nhìn của bên phát triển cũng như góc nhìn của bên khác hàng Ngay từ ban đầu, các thành viên dự án sẽ thảo luận để tạo ra các kịch bản trước, sau đó sẽ cài đặt dựa trên kịch bản đó, tất cả kịch bản test gần gũi với ngôn ngữ tiếng Anh, do đó nó đóng luôn vai trò của tài liệu.

3.4.3 Quy trình làm việc BDD

Hình 9: Quy trình làm việc BDD

Sau khi kịch bản test chạy, Cucumber sẽ đọc mã Gherkin từ file feature, sau đó nó sẽ tìm đoạn mã trong file step definition mô tả đúng với hành động trong file feature và thực hiện đoạn code, ở bước chạy code Cucumber có thể kết hợp với các framework khác như Ruby on Rails, Selenium, Spring,

Selenium

Selenium là một bộ công cụ phần mềm chuyên dụng được dùng để kiểm thử tự động (Automation

Testing) các ứng dụng web và có khả năng hỗ trợ chạy trên trình duyệt với nhiều nền tảng như Windows,

Với Selenium, bạn có thể viết test script bằng nhiều loại ngôn ngữ lập trình khác nhau, một số ngôn ngữ phổ biến Selenium hỗ trợ bao gồm: Java, C#, Ruby,

Python, Perl, PHP và JavaScript.

3.5.2 Các thành phần của Selenium

Selenium là một trong những khái niệm chung để miêu tả một phần mềm chuyên dụng trong automation Mà ở đó, mỗi loại trong nó sẽ đáp ứng được các yêu cầu testing khác nhau Còn về cơ bản thì Selenium bao gồm 4 thành phần chính là:

- Selenium IDE (IDE là từ viết tắt của Integrated Developer Environment): là một plug-in nằm trên trình duyệt Fire-fox, ta có thể sử dụng để record và play lại các thao tác đó dựa theo một quy trình hay một test case nào đó

- Selenium RC: Selenium Remote Control, Selenium server sẽ khởi chạy và tương tác với các trình duyệt web

- WebDriver: Selenium WebDriver có nhiệm vụ gửi lệnh khởi chạy rồi thực hiện tương tác trực tiếp với các trình duyệt mà không cần thông qua bất cứ server như Selenium RC

- Selenium Grid: Selenium Hub được sử dụng để khởi chạy nhiều các test thông qua các máy cũng như các trình duyệt khác nhau tại cùng một thời điểm nhất định Selenium team đã quyết định gộp Selenium RC và WebDriver lại với nhau để có thể khởi tạo ra các Selenium 2 với các tính năng mạnh mẽ hơn và hiện nay thì hầu hết các Selenium Project đều sử dụng chúng.

3.5.3 Các tính năng nổi bật

 Selenium là một công cụ mã nguồn mở/ framework để kiểm tra web, website phiên bản di động

 Selenium IDE hỗ trợ tính năng playback giúp bạn có thể sử dụng các bài test của người khác và không cần phải biết ngôn ngữ script

 Selenium là một nền tảng kiểm thử dựa trên cloud giúp tester có thể lưu lại thao tác và xuất ra dưới dạng script đơn giản, dễ hiểu.

 Selenium hỗ trợ nhiều hệ điều hành, ngôn ngữ và trình duyệt khác nhau.

 Giúp bạn có thể chạy cùng lúc nhiều bài test để giảm thời gian và tăng hiệu quả

 Selenium có thể tích hợp với các framework khác như Ant và Maven để biên dịch mã nguồn

 Quá trình kiểm thử của Selenium hao tốn ít tài nguyên và yêu cầu cấu hình thiết bị thấp hơn các công cụ khác.

 Selenium WebDriver không yêu cầu cài đặt server, test script của bạn sẽ trực tiếp tương tác với trình duyệt.

 Selenium Remote Control kết hợp với WebDriver API để trở thành phiên bản Selenium 2.0 hỗ trợ những trang web động và Ajax

Hình 11: Selenium kết hợp Javascript

JavaScript là một trong những ngôn ngữ lập trình được sử dụng rộng rãi theo khảo sát hàng năm của Stack Overflow 2020 Vì vậy nên việc sử dụng nó với tự động hóa web Selenium sẽ rất hợp lý! Vì hầu hết các nhà phát triển đã quen thuộc với JavaScript, họ sẽ dễ dàng viết các bài kiểm tra tự động hóa bằng JavaScript và nhận được phản hồi nhanh chóng.

Hình 12: Bảng xếp hạng các ngôn ngữ lập trình sử dụng rộng rãi của Stack Overflow 2020

Xray – Công cụ quản lý kiểm thử phần mềm

Xray là Ứng dụng quản lý kiểm thử tự động & thủ công số 1 để đảm bảo chất lượng tại Jira Đó là một công cụ đầy đủ tính năng live bên trong và tích hợp liền mạch với Jira Mục đích là giúp các công ty cải thiện chất lượng sản phẩm thông qua thử nghiệm hiệu quả Có thể lập kế hoạch, thực hiện và theo dõi thử nghiệm với khả năng truy xuất nguồn gốc các yêu cầu đầy đủ

Xray hỗ trợ cả kiểm tra thủ công và tự động, bao gồm cả BDD sử dụng Cucumber bên cạnh JUnit, NUnit, Robot và các loại khác Bao gồm toàn bộ vòng đời thử nghiệm: lập kế hoạch thử nghiệm, test specification, tổ chức thử nghiệm theo flat hoặc phân cấp, thực hiện thử nghiệm và báo cáo thử nghiệm Sử dụng các loại vấn đề Jira đặc biệt, vì vậy bạn có thể sử dụng tất cả các lợi ích của Jira mà bạn được sử dụng bên cạnh việc tạo sự linh hoạt để tổ chức trong cùng một dự án hoặc trên nhiều dự án, để tách biệt rõ ràng các mối quan tâm.

Tích hợp với công cụ phổ biến được yêu thích, bao gồm cả Bamboo và Jenkins, thật dễ dàng bằng cách sử dụng các tiện ích bổ sung miễn phí của Xray hoặc thậm chí thông quaAPI REST tích hợp của nó.

Jenkins

Jenkins là một công cụ tự động hóa có mã nguồn mở được viết bằng Java kết hợp với nhiều Plugin, Jenkins có mục đích chính là tích hợp liên tục (hay còn gọi là CI- Continuous Integration) Công cụ này được sử dụng để xây dựng và kiểm tra các dự án

Hình 13: Biểu tượng Xray phần mềm liên tục, giúp các nhà phát triển tích hợp các thay đổi vào dự án một cách dễ dàng hơn.

Jenkins là một ứng dụng dựa trên máy chủ và đòi hỏi phải có một máy chủ web như Apache Tomcat để chạy trên các nền tảng khác nhau như Windows, Linux, macOS, Unix, Để sử dụng Jenkins, bạn cần tạo các đường dẫn gồm một loạt các bước mà một máy chủ Jenkins sẽ nhận Tích hợp liên tục là một công cụ mạnh mẽ bao gồm một bộ công cụ được thiết kế để lưu trữ, giám sát, biên dịch và kiểm tra mã hoặc các thay đổi mã.

 Máy chủ tích hợp liên tục, ví dụ như: Jenkins, Bamboo, CruiseControl, TeamCity,

 Công cụ kiểm soát nguồn, ví dụ như: CVS, SVN, GIT, Mercurial, Perforce, ClearCase và các công cụ khác

 Công cụ xây dựng, ví dụ như: Make, ANT, Maven, Ivy, Gradle và các công cụ khác

 Framework kiểm tra tự động hóa, ví dụ như: Selenium, Appium, TestComplete, UFT và những thứ khác

Phát triển phầm mềm theo mô hình Agile-Scrum

- Agile là phương pháp phát triển phần mềm linh hoạt để làm sao đưa sản phẩm đến tay khách hàng càng nhanh càng tốt, là một hướng tiếp cận cụ thể cho việc quản lý dự án phần mềm.

- Scrum là một dạng của mô hình Agile và là Framework phổ biến nhất khi thực hiện mô hình Agile Scrum là mô hình phát triển lặp đi lặp lại Những khoảng lặp cố định thường kéo dài 1,2 tuần được gọi là Sprint hoặc Iteration.

Vai trò và kỹ năng của từng bộ phận: Phân biệt rõ sự khác biệt giữa về công việc, trách nhiệm giữa các vai trò trong Scrum và các kỹ năng cần thiết ở từng vị trí Trong Scrum, đội ngũ tham gia phát triển phần mềm được phân chia ra 03 vai trò với trách nhiệm rõ ràng để đảm bảo tối ưu hóa các công việc đặc thù Ba vai trò này bao gồm:

 Product Owners: là người chịu trách nhiệm về sự thành công của dự án, người định nghĩa các yêu cầu và đánh giá cuối cùng đầu ra của các nhà phát triển phần mềm.

 Scrum Master: Là người có hiểu biết sâu sắc về Scrum và đảm bảo nhóm có thể làm việc hiệu quả với Scrum Họ phải đảm bảo các sprint được hoàn thành đúng mục đích, bảo vệ đội làm việc và loại bỏ các trở ngại.

 Development Team (BA, Dev, Tester…): Một nhóm liên chức năng (cross- functional) tự quản lý để tiến hành chuyển đổi các yêu cầu được tổ chức trong Product Backlog thành chức năng của hệ thống.

Scrum định nghĩa quy tắc cho bốn sự kiện chủ chốt (các cuộc họp) nhằm tạo môi trường và quy cách hoạt động và cộng tác cho các thành viên trong dự án.

- Sprint Planning (Họp Kế hoạch Sprint): Nhóm phát triển gặp gỡ với Product Owner để lên kế hoạch làm việc cho một Sprint.

- Daily Scrum (Họp Scrum hằng ngày): Scrum Master tổ chức cho Đội sản xuất họp hằng ngày trong khoảng 15 phút để Nhóm Phát triển chia sẻ tiến độ công việc cũng như chia sẻ các khó khăn gặp phải trong quá trình phát triển phần mềm suốt một Sprint.

- Sprint Review (Họp Sơ kết Sprint): Cuối Sprint, nhóm phát triển cùng với Product Owner sẽ rà soát lại các công việc đã hoàn tất (DONE) trong Sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi cần thiết cho sản phẩm.

- Sprint Retrospective (Họp Cải tiến Sprint): Dưới sự trợ giúp của Scrum Master,nhóm phát triển sẽ rà soát lại toàn diện Sprint vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng như bản thân sản phẩm.

MÔ TẢ CÔNG VIỆC VÀ DỰ ÁN THỰC HIỆN

Dự án Seamless

Seamless là phần mềm bảo hiểm kỹ thuật số một cửa tự nhiên trên đám mây dưới dạng nền tảng dịch vụ (SaaS) Nó nhằm mục đích giải quyết các công việc mang tính số hoá thấp lại có chi phí cao trong ngành bảo hiểm Nền tảng này được xây dựng dựa trên việc quản lý khách hàng toàn diện và bán hàng đa kênh Với kiến trúc microservice, nó cho phép phù hợp tối ưu với nhu cầu kinh doanh của các công ty bảo hiểm.

Seamless hiện là sản phẩm chính trong dây chuyền phát triển phầm mềm của Contemi tại Việt Nam với các tính năng về bảo hiểm luôn được cập nhật xuyên suốt từ các dự án đã làm theo yêu cầu từ khách hàng

4.1.2 Các công việc đã tham gia

Danh sách các công việc:

 [INPR-464] Cấu trúc lại code cho tính năng nhập thông tin khách hàng

 INPR-472] Viết Automation script cho tính năng chỉnh sửa thông tin bán hàng

 [INPR-495] Viết Automation script cho tính năng tìm kiếm (search) và tạo bộ lọc (filter) các khách hàng tiềm năng Đặc điểm chung của các công việc: Vì đang trong quá trình thực tập và mới bắt đầu vào công việc để ứng dụng những kiến thức đã học nên mức độ của các công việc ban đầu trong dự án xoay quanh các tính năng cơ bản, làm quen với framework cũng như quy trình làm việc với độ khó tăng dần.

4.1.2.1 [INPR-464] Cấu trúc lại code cho tính năng nhập thông tin khách hàng

- Mô tả tính năng: Là một người quản lý, tôi có thể thêm thông tin khách hàng của mình vào hệ thống để theo dõi, quản lý các thông tin bảo hiểm của họ ( khách hàng có thể là một công ty bảo hiểm, một đại lý bên thứ ba – company, hoặc một khách hàng cá nhân – person)

-Mô tả các yêu cầu:

 Đảm bảo đầy đủ các trường thông tin cần lưu trữ trên form

 Tính năng hoạt động đúng trên 2 lựa chọn dành cho khách hàng “person” và khách hàng “company”

 Nhập đầy đủ các thông tin hợp lệ theo yêu cầu

 Sau khi tạo khách hàng thành công, hệ thống hiển thị đúng thông tin khách hàng trên danh sách, trên form chỉnh sửa, trong bảng các dịch vụ dành cho khách hàng.

 Hiển thị khách hàng vừa tạo trên đầu danh sách với đúng thông tin.

 Tạo mới lại các hàm nhập thông tin vào form khách hàng theo hướng tách nhỏ ra mỗi thông tin nhập sẽ tạo một hàm nhỏ cho cả 2 lựa chọn “person” và

 Định nghĩa lại các BDD bằng cách thay các hàm cũ trước đó (gộp nhiều input vào một hàm) thành từng hàm vừa tạo mới để thuật tiện cho việc sử dụng lại các project sau khi các thông tin đầu vào thay đổi

 Thiết lập chạy testcase trên Jenkins

 Tạo mới các hàm input theo từng trường dữ liệu để thay thế hàm trước đó (một hàm lớn để input tất cả các trường)

//#region input data into Account person form for each field public async inputOrganizationAccountPersonForm(Organization: string) { try { await this.driverService.waitUntilElementLoaded(this.cmbOrganizationPersonForm); await waitUntilHorizontalProgressBarLoaded_v2(this.driverService, 10); await this.driverService.setText(this.cmbOrganizationPersonForm,

Organization); await waitUntilHorizontalProgressBarLoaded_v2(this.driverService); await selectDropdownOption(Organization, "", this.driverService); return true;

} catch (error) { console.log("inputOrganizationAccountPersonForm"); console.log(error); return false;

} public async inputNINBasicInformationAccountPersonForm(NIN: string) { try { await this.driverService.waitUntilElementLoaded(this.txtNIN); await waitUntilHorizontalProgressBarLoaded_v2(this.driverService, 10); if (await this.driverService.canBeSetText(this.txtNIN)) { await this.driverService.setText(this.txtNIN, NIN);

} catch (error) { console.log("inputNINBasicInformationAccountPersonForm"); console.log(error); return false;

 Định nghĩa lại bước “User inputs valid account data from csv file {string}”

When("User inputs valid account data from csv file {string}", async (filename: string)

=> { const rows = loader(convertPathFileDataToDataRegression(filename)); if(!typeLead){ typeLead = rows[0].TypeLead;

} const Organization = rows[0].Organization; if (typeLead.localeCompare("person") === 0) { let NIN = rows[0].NIN; if (!NIN) {

NIN = randomModulus11ForSSN(); //get random NIN with length = 11 dataTestcase.push(new ValidateField("OrgNoAccount", 0, true, [NIN], []));

} const firstName = rows[0].FirstName; const lastName = rows[0].LastName; expectedName = firstName + " " + lastName; expectedNIN = NIN; if (Organization) { let temp = await accountForm.inputOrganizationAccountPersonForm(Organization); logFailTestcase(temp, "Input incorrect Organization");

} if (NIN) { let temp = await accountForm.inputNINBasicInformationAccountPersonForm(NIN); logFailTestcase(temp, "Input incorrect NIN");

} if (firstName) { let temp = await accountForm.inputFirstNameBasicInformationAccountPersonForm(firstName); logFailTestcase(temp, "Input incorrect first name");

 Testcase “Tạo khách hàng cá nhân” hoàn chỉnh

Scenario: [TC_Regression] [Accounts] Create person account successfully

Given User navigates to Account list

And User opens create new person account form

When User inputs valid account data from csv file "./SAAS-19370_data_account_person.csv"

And User inputs valid contact data from csv file "./SAAS-19370_data_contact_person.csv"

Then System shows new person account in the Account list "./SAAS-19370_data_account_person.csv" And User opens Edit account form "./SAAS-19370_data_account_person.csv"

And User verifies info on Edit account person form "./SAAS-19370_data_account_person.csv" And System shows new person account in account detail "./SAAS-19370_data_account_person.csv"

 Kết quả khi chạy testcase “Tạo khách hàng cá nhân”

Hình 15: Report sau khi chạy testcase của task [INPR-464]

4.1.2.2 [INPR-472] Viết Automation script cho tính năng chỉnh sửa thông tin bán hàng

- Mô tả tính năng: Là một người giám sát, tôi có thể chỉnh sửa thông tin của một hoạt động bán hàng trên form bán hàng đã tạo

-Mô tả các yêu cầu:

 Đảm bảo đầy đủ các trường thông tin cần lưu trữ trên form

 Khi mở form bán hàng đã tạo phải hiển thị đúng các thông tin cũ

 Sau khi chỉnh sửa các thông tin, cần đảm bảo hiển thị đúng thông tin đã chỉnh sửa trên danh sách bán hàng, trên form chỉnh sửa bán hàng, trong chi tiết đơn hàng

 Hiển thị đơn hàng vừa chỉnh sửa trên đầu danh sách với đúng thông tin.

 Viết BDD cho tính năng chỉnh sửa thông tin đơn hàng

 Tạo các hàm xác minh các thông tin chỉnh sửa trên form, trên danh sách

 Định nghĩa các bước trong BDD bằng các hàm vừa tạo.

 Thiết lập và chạy testcase trên Jenkins.

 Viết được hàm xác minh các giá trị hiển thị đúng trên chi tiết thông tin bán hàng public async validateValueSaleDetail(expectedValue: string, nameOfField: string, isUsedForSearch: boolean = false) { try { await this.driverService.waitUntilElementLoaded(this.lblDtAccountName); await waitUntilHorizontalProgressBarLoaded_v2(this.driverService, 100); logWarningMessage(`Validate value at filed "${nameOfField}":`); let actualValue = "N/A"; switch (nameOfField) { case "Account": { actualValue = await this.driverService.getText(this.lblDtAccountName); break;

} case "Sales Rep.": { actualValue = await this.driverService.getText(this.lblDtSaleRep); break;

{ actualValue = await this.driverService.getText(this.lblDtKAM); break;

{ const temp = By.xpath(`//div[contains(@class,'tab-pane') and contains(@class,'active')]//app-sale-details-left-side//div[contains(@class,'card- body')]//label[text()='${nameOfField}']//following-sibling::*[self::*[text()]]`); actualValue = await this.driverService.getText(temp); break;

} if (isUsedForSearch) { return actualValue.toLowerCase().includes(expectedValue.toLowerCase()); } else { return await this.driverService.validateRecord(`Validate field $

} catch (error) { console.log("validateValueSaleDetail"); console.log(error); return false; }}

- Định nghĩa các step “System shows company sale in Sales detail from csv file {string}”

Then("System shows company sale in Sales detail from csv file {string}", async (fileName)

//Định nghĩa step sửQ dụng hàm validateValueSaleDetail đểQ xác minh các giá trị });

- Testcase chỉnh sửa thông tin bán hàng hoàn chỉnh

Scenario: [TC_Regression] [Sales] Edit company sale successfully

Given User navigates to Sales list

When User updates a company sale from precondition steps from csv file "./SAAS- 7085_data_sale_company_edit.csv"

Then System shows updated company sale in the Sales list

And System shows company sale in Sales detail from csv file "./SAAS-

7085_data_sale_company_edit.csv"

-Kết quả chạy testcase “chỉnh sửa thông tin bán hàng”

Hình 16: Report sau khi chạy task [INPR-472]

4.1.2.3 [INPR-495] Viết Automation script cho tính năng tìm kiếm (search) và tạo bộ lọc (filter) các khách hàng tiềm năng

- Mô tả tính năng: Là người dùng hệ thống, tôi chỉ muốn tìm một hoặc nhiều khách hàng tiềm năng trong danh sách Khách hàng tiềm năng thông qua tính năng Tìm kiếm và bộ lọc -Mô tả các yêu cầu :

 Chỉ nhập một trường rồi nhấn "Tìm kiếm" -> Trả về chính xác 1 kết quả

 Chỉ nhập một trường rồi nhấn "Tìm kiếm" -> Trả về nhiều kết quả

 Nhập nhiều trường rồi nhấn "Tìm kiếm" -> Trả về đúng 1 kết quả

 Nhập nhiều trường rồi nhấn "Tìm kiếm" -> Trả về nhiều kết quả

=> Sau khi kết quả trả về, phải xác minh sự khớp giữa dữ liệu đầu vào với kết quả trên danh sách Khách hàng tiềm năng hoặc form Khách hàng tiềm năng

=> Với trường hợp trả về nhiều kết quả, chỉ xác minh dữ liệu khớp cho các dòngđầu tiên và dòng cuối cùng trong trang 1.

2 Clear – xoá dữ liệu trên form đã tìm kiếm

 Nhấn "Clear" -> Dữ liệu trong form được làm sạch

 Người dùng lưu dữ liệu tìm kiếm và tạo một bộ lọc rồi chọn nó -> Xác minh kết quả trả về.

 Viết testcase BDD cho tính năng tìm kiếm và tạo, xoá bộ lọc

 Viết các hàm nhập giá trị vào form, xác minh các form đã sạch dữ liệu khi nhấn

 Xác minh các kết quả trả về, số lượng kết quả trả về khi tìm kiếm đúng với yêu cầu

 Định nghĩa các BDD và sử dụng các hàm

 Thiết lập testcase để chạy được trên Jenkins

 Viết và định nghĩa code của BDDs của testcase “Tìm kiếm khách hàng tiềm năng” và “làm sạch dữ liệu form tìm kiếm”

Scenario: [TC_Regression] [Lead] Search and Filter exactly a lead

Given User navigates to Lead list

And User opens Search and Filter form

When User inputs to Search and Filter lead form with valid data from csv file

"./data_hogs/SAAS-13051_data_search_filter_lead.csv"

Then System shows a list of leads on lead list

Scenario: [TC_Regression] [Lead] Search and Filter multiple leads

When User inputs to Search and Filter lead form with valid data from csv file

"./data_hogs/SAAS-13052_data_search_filter_lead.csv"

Then System shows a list of leads on lead list

Scenario: [TC_Regression] [Lead] Clear the Search and filter lead form successfully

When User inputs data to Search and Filter lead form "./data_hogs/SAAS-

13053_data_search_filter_clear_lead.csv"

And User presses "Clear" button on Search & Filter form

Then Data in Search and Filter lead form is cleaned

 Viết và định nghĩa code của BDDs của testcase “Tạo bộ lọc tìm kiếm khách hàng tiềm năng”

Scenario: [TC_Regression] [Lead] Check filter on select filter field when save "Private" filter #Login as a user with "user 1"

When User inputs data to Search and Filter lead form "./data_hogs/SAAS-

13054_data_filter_form_lead.csv"

And User presses "Save" button on Search & Filter form

And User inputs Filter Name form "./data_hogs/SAAS-13054_data_filter_form_lead.csv"

And User presses "Save" button on Filter Name form

And User inputs data to select filter field "./data_hogs/SAAS-

Then At "user 1", System shows a filter on dropdown of Select filter field "./data_hogs/SAAS- 13054_data_filter_form_lead.csv"

And System shows a list of leads on lead list

#Login as a user with "user 2"

Given User logs out if already logged in

And User inputs login information "./data_hogs/SAAS-13054_data_user_2_search_filter_lead.csv" And User clicks "Login" button

And User navigates to Lead list

When User inputs data to select filter field "./data_hogs/SAAS-

Then System does not show a filter on dropdown of Select filter field "./data_hogs/SAAS- 13054_data_filter_form_lead.csv"

 Kết quả chạy các testcase tìm kiếm bằng Jenkins tích hợp trên Jira - Test passed 100%

Hình 17: Kết quả chạy task [INPR-495] trên jenkins

Dự án Atlas

Atlas là dự án được đặt tên theo tên khách hàng của Contemi – Công ty Atlas Dự án này làm về lĩnh vực hoạt động thứ 2 của Contemi Việt Nam đó là Guarantee [1] Atlas là một giải pháp hiện đại đang rất cần cho Hệ thống quản lý đảm bảo trong đó hầu hết các quy trình đều được kỹ thuật số và tự động hóa và tồn tại sự tích hợp tốt giữa các bên khác nhau để cho phép con nợ, đại lý và người vận chuyển rủi ro thực hiện công việc kinh doanh của họ một cách hiệu quả.

Cổng thông tin khách hàng cho phép con nợ hoặc các bên liên quan có thể đăng nhập và quản lý các khoản bảo lãnh của họ Quy trình đăng ký là kỹ thuật số và cho phép khách hàng có thể đăng ký và nhận được trả lời trong một khoảng thời gian ngắn Một hệ thống phụ trợ mạnh mẽ cho phép chủ sở hữu hệ thống xem các ứng dụng, phê duyệt và quản lý chúng Các tài liệu được duy trì bằng kỹ thuật số Số liệu thống kê và báo cáo sâu vào dữ liệu cung cấp cái nhìn toàn cảnh về hoạt động kinh doanh.

Các thuật ngữ chuyên ngành:

[1] Guarantee là một lời hứa pháp lý được thực hiện bởi một bên thứ ba (người bảo lãnh) để đảm bảo nợ của người vay hoặc các loại trách nhiệm pháp lý khác trong hợp đồng được hoàn trả hoặc thực hiện Các khoản vay được đảm bảo bởi một bên thứ ba được gọi là các khoản vay được đảm bảo.

[2] Frame Agreement : là một thoả thuận, hiệp định khung mà bên thứ 3 ( tức bên cung cấp guarantee) sẽ thoả thuận số tiền tối đa theo các điều khoản bảo lãnh mà họ có thể chi trả cho các guarantee của công ty mua guarantee từ họ

[3] Application : trước khi có được một guarantee chính thức, sẽ tạo một application cam kết số tiền bảo lãnh cũng như điều khoản được chi trả từ Frame Agreement Qua các quá trình thảo luận, chỉnh sửa application, application được duyệt sẽ tạo thành guarantee.

[4] Document: có thể là các bản hợp đồng tự động tạo ra từ các thông tin cung cấp, các điều khoản bảo đảm, các tài liệu cung cấp bằng chứng được người dung tải lên.

4.2.2 Các công việc tham gia

Danh sách các công việc:

 [SAAS-13414] Viết Automation script : Tạo và chỉnh sửa Guarantee [1]

 [SAAS-13417] Viết Automation script: Kiểm tra thông tin các tài liệu (document) [4] được tạo ra trong quy trình tạo guarantee

 [SAAS-13418] Viết Automation script Thêm mối quan hệ cha - con của khách hàng (công ty) và xác minh các hợp đồng được chia sẻ từ khách hàng (công ty) cha – con. Đặc điểm chung của các công việc: Giai đoạn thử việc và được phân công chính thức vào dự án Atlas nên các công việc đòi hỏi cách test nhiều bước hơn, và đảm nhiệm

46 toàn bộ một nhiệm vụ (bao gồm nhiều testcase) thay vì tham gia hỗ trợ vài bước như ở dự án Seamless Đồng thời việc viết code phải mang tính dễ mở rộng, có thể sử dụng lại được ở những tính năng liên quan Khi hoàn thành từng task (nhiệm vụ) cần demo trước team và hoàn thiện những chỉnh sửa, góp ý sau đó trước khi đưa vào sử dụng.

4.2.2.1 [SAAS-13414] Viết Automation script : Tạo và chỉnh sửa Guarantee

- Mô tả tính năng: Là một người dùng, tôi có thể tạo một guarantee [1] từ một công ty (account) và chỉnh sửa nó nếu muốn chỉnh sửa thông tin, hệ thống sẽ tự động tính giá tiền cũng như các khoản phí trong quá trình này.

- Mô tả các yêu cầu:

 Từ một bản nháp (application [3] ) khi được duyệt phải tự động tạo ra guarantee [1]

 Các thông tin trên guarantee [1] phải hiển thị đúng với bản nháp cuối cùng ở danh sách các guarantee

 Các thông tin trên guarantee phải hiển thị đúng với bản nháp cuối cùng ở chi tiết form guarantee tab “Original guarantee”

 Xác minh các thông tin thanh toán, số tiền trả góp, thời hạn trả góp của một guarantee [1] hiển thị đúng

 Sau khi chỉnh sửa, kiểm tra trạng thái hiển thị guarantee đã được chỉnh sửa, các thông tin chỉnh sửa hiển thị đúng trên danh sách và trên form ở tab “Lasted information” và tab “Amendments”

 Xác minh các khoản phí phát sinh cũng như khoản thanh toán thay đổi khi chỉnh sửa guarantee [1]

 Viết BDDs cho testcase và định nghĩa các bước trong BDD, tạo các hàm liên quan

Scenario: [TC] [Auto] [Guarantee] Create, Amend Guarantee successfully

And User searches account with valid data from csv file "./data_atlas/SAAS-

And User opens an account from precondition steps "./data_atlas/SAAS-

Given User navigates to Frame Agreements List

When User inputs valid frame agreement for one phase product from csv file

"./data_atlas/product/product_3/SAAS-16051_data_create_frame_agreement.csv"

Then System shows new record in the Frame Agreement in the list

"./data_atlas/product/product_3/SAAS-16051_data_create_frame_agreement.csv"

And User opens Create Application Options form

And User inputs valid data into Create Application Options form

"./data_atlas/product/product_3/SAAS-15995_data_application_options.csv"

And User presses "Create" button on "Create Application Options" form

And User inputs valid data into Create Application form "./data_atlas/product/product_3/SAAS- 16019_data_create_guarantee.csv"

When User calculates price on Create Application form

And User presses "Preview" button on "Create Application" form

And User presses "Create" button on "Create Application" form

And User presses "Yes" button on "Confirmation" form

Then System shows correct information at detail application page

"./data_atlas/product/product_3/SAAS-16019_data_create_guarantee.csv"

And User presses "X" button on "Application Detail" form

And User navigates to Application List

And System shows correct information at application list "./data_atlas/product/product_3/SAAS- 16019_data_create_guarantee.csv"

Given User navigates to Application List

And User opens first application at application list

When User presses "Approve" button on "Application detail" form

And System changes status of the application to "Approved" at application list

And User navigates to Guarantee List

And System shows correct information at guarantee list "./data_atlas/product/product_3/SAAS- 16019_data_create_guarantee.csv"

And User opens first guarantee at guarantee list

And System shows correct information at "Original guarantee" tab on detail guarantee page

"./data_atlas/product/product_3/SAAS-16019_data_create_guarantee.csv"

And System shows correct information at detail guarantee page tab Documents

And User presses "X" button on "Guarantee Detail" form

And User navigates to Frame Agreements List

Then System shows new record in the Frame Agreement in the list

"./data_atlas/product/product_3/SAAS-16019_data_check_frame_agreement.csv"

And User navigates to Instalment List

And System shows correct information at Instalment list "./data_atlas/product/product_3/SAAS- 16019_data_create_guarantee.csv"

And System shows correct information at Instalment form "./data_atlas/product/product_3/SAAS- 16019_data_create_guarantee.csv"

Given User navigates to Guarantee List

And User opens first guarantee at guarantee list

When User presses "Amend" button on "Guarantee detail" form

And User inputs valid data into Create Amendment form "./data_atlas/product/product_3/SAAS- 16020_data_amend_guarantee.csv"

When User calculates price on Create Amendment form "./data_atlas/product/product_3/SAAS- 16020_data_amend_guarantee.csv"

When User presses "Preview" button on "Create Amendment" form

Then System shows correct information at "preview" amendment page

"./data_atlas/product/product_3/SAAS-16020_data_amend_guarantee.csv"

When User presses "Create" button on "Create Amendment" form

Then System shows correct information at "detail" amendment page

"./data_atlas/product/product_3/SAAS-16020_data_amend_guarantee.csv"

And User presses "Approve" button on "Application detail (Amendment)" form

And System changes status of the application to "Approved" at application list

And System changes status of the guarantee to "Amended" at guarantee list

 Testcase chạy passed trên Jenkins ngày 08/06/2022 - Test passed 100%

Hình 18: Kết quả chạy task [SAAS-13414] trên Jenkins 4.2.2.2 [SAAS-13417] Viết Automation script: Kiểm tra thông tin các tài liệu (document [4] ) được tạo ra trong quy trình tạo guarantee

-Mô tả tính năng: Là một người dung, tôi có thể xem và tải về các bản document [4] được tự động tạo ra trên hệ thống sau khi tạo các bản hợp đồng, trả lời các câu hỏi, cung cấp thông tin trên hệ thống, cập nhật các file bằng chứng trong quá trình tạo một guarantee [1] v v

 Một bản hợp đồng với version 1 được tạo ra khi tạo Frame Agreement [2] hiển thị đúng thông tin, tên, ngày giờ tạo ra

 Một bản hợp đồng với version 2 được tạo ra khi chỉnh sửa Frame Agreement [2] trên cần hiển thị đúng thông tin, tên, ngày giờ chỉnh sửa

 Các tài liệu minh chứng được tải lên cần hiển thị đúng trên tab document của Application [3]

 Sau khi duyệt một application [3] , cần đảm bảo guarantee được tạo ra phải hiển thị ở tab document có các file hợp đồng guarantee được tạo ra và file minh chứng được tải lên từ application.

 Ở tab documents chung của công ty, hiển thị tất cả các document [4] được tạo ra và tải lên trong quá trình tạo Frame Agreement [2] , Application [3] và Guarantee [1]

 Kiểm tra hệ thống tạo document mới khi chỉnh sửa một guarantee

 Viết được các BDDs, sử dụng lại một vài bước và viết các hàm kiểm tra thông tin, trạng thái download hệ thống, định nghĩa các bước theo testcase

Scenario: [TC] [Document] Check document after create frame agreement successfully

And User searches account with valid data from csv file "./data_hogs/SAAS-

And User opens an account from precondition steps "./data_hogs/SAAS-

When User inputs valid frame agreement for one phase product from csv file

"./data_hogs/SAAS-16051_data_create_frame_agreement.csv"

Then System shows new record in the Frame Agreement in the list "./data_hogs/SAAS-

16051_data_create_frame_agreement.csv"

And System shows new document at "Version 1" in Frame Agreement detail

And User downloads a valid document in Frame Agreement detail

And System downloads document successfully

And User is on Document list Guarantee

And System shows new "Frame Agreement" document in the Document list Guarantee

And User downloads a valid "Frame Agreement" document in Document List

Scenario: [TC] [Document] Check document after add more product in frame agreement

When User add more product to the frame agreement from csv file "./data_hogs/SAAS-

Then System shows new document at "Version 2" in Frame Agreement detail

And User downloads a valid document in Frame Agreement detail

And System shows new "Frame Agreement" document in the Document list Guarantee

And User downloads a valid "Frame Agreement" document in Document List

Scenario: [TC] [Document] Check document after create application successfully

And User inputs valid frame agreement for one phase product from csv file

"./data_hogs/SAAS-16053_data_create_frame_agreement.csv"

And System shows new record in the Frame Agreement in the list "./data_hogs/SAAS-

And User opens Create Application Options form

And User inputs valid data into Create Application Options form "./data_hogs/SAAS- 15995_data_application_options.csv"

And User presses "Create" button on "Create Application Options" form

And User inputs valid data into Create Application form "./data_hogs/SAAS-

When User calculates price on Create Application form

And User presses "Preview" button on "Create Application" form

And User presses "Create" button on "Create Application" form

Then System shows correct information at detail application page "./data_hogs/SAAS- 15995_data_application.csv"

And System shows new document on document list in detail form "./data_hogs/SAAS-

And User downloads a valid document in detail form

And System shows new "Application" document in the Document list Guarantee

And User downloads a valid "Application" document in Document List

Scenario: [TC] [Document] Check valid document after upload document in application details Given User navigates to Application List

When User uploads a valid document in "Application" detail form "./data_hogs/SAAS- 16054_data_upload_application.csv"

Then System shows new document on document list in detail form "./data_hogs/SAAS-

And System shows new "Other application" document in the Document list Guarantee

Scenario: [TC] [Document] Check valid document after create guarantee successfully

Given User navigates to Application List

When User opens and approves the application

Then System shows new record in the Guarantee list

And System shows new document on document list in Guarantee detail form

And System shows new "Guarantee" document in the Document list Guarantee

And User downloads a valid "Guarantee" document in Document List

Scenario: [TC] [Document] Check valid document after upload document in guarantee details Given User navigates to Guarantee List

When User uploads a valid document in "Guarantee" detail form "./data_hogs/SAAS-

And System shows new "Other Guarantee" document in the Document list Guarantee

Scenario: [TC] [Document] Check valid document after amend document in guarantee details Given User navigates to Guarantee List

When User amends the guarantee in Guarantee List

And User inputs valid data into Create Amendment form "./data_hogs/SAAS-

When User calculates price on Create Amendment form "./data_hogs/SAAS-

And User presses "Preview" button on "Create Amendment" form

# And User presses "Yes" button on "Confirmation" form

And User presses "Create" button on "Create Amendment" form

And System shows new "Application" document in the Document list Guarantee

And User downloads a valid "Application" document in Document List

 Kết quả chạy testcase hoàn chỉnh trên Jenkins ngày 08/06/2022 - Test passed 100%

Hình 19: Kết quả chạy task [SAAS-13414] trên Jenkins 4.2.2.3 [SAAS-13418] Viết Automation script Thêm mối quan hệ cha - con của khách hàng (công ty) và xác minh các hợp đồng được chia sẻ từ khách hàng (công ty) cha – con.

-Mô tả tính năng: Là một người dung, tôi có thể thêm mối quan hệ cha – con giữa hai công ty để hưởng những lợi ích cũng như những điểu khoản liên quan

-Mô tả các yêu cầu: Đảm bảo các yêu cầu sau

 Tên các mối quan hệ hiển thị trên thông tin của công ty (khách hàng) khi thêm mối quan hệ cho chúng

 2 công ty Cha – con có thể chia sẻ Frame Agreement [2] cho nhau: o Một khi đã chia sẻ Frame Agreement [2] , không thể xoá mối quan hệ cha/ con

Nếu không chia sẻ nữa mới có thể xoá được. o Một khi đã chia sẻ Frame Agreement [2] , bên công ty con có thể tạo Application [3] và guarantee [1] từ Frame Agreement của cha.

TỰ ĐÁNH GIÁ – NHẬN XÉT

Qua khoảng thời thực tập tại Contemi Vietnam là 12 tuần Sinh viên có tự đánh giá bản thân như sau:

 Không gặp các khó khăn trong việc giao tiếp với các thành viên làm việc chung

 Với lượng kiến thức tích trong 3 năm học đại học giúp ích rất nhiều trong việc hiểu nhanh các vấn đề cơ bản hay nâng cao trong công việc

 Không có khó khăn trong việc đọc tìm hiểu nghiên cứu các tài liệu tiếng anh, nhưng cần được cải thiện hơn.

 Cần cải thiện quy trình làm việc, ghi chú công việc đầy đủ, hỗ trợ rất nhiều cho tính bất cẩn.

 Quản lý thời gian chưa tốt hay làm những việc, vấn đề cảm thấy có hứng thú và đặt mức độ ưu tiên cho công việc chưa tốt Cần tập trung và đặt mức độ ưu tiên cho công việc hợp lí hơn

Ngoài ra nói về công việc được giao và sản phẩm tham gia phát triển thì dù là thành viên phát triển sản phầm ít nhưng cũng tạo ra các lợi thế cho việc phát triển bản thân như:

 Được giao và nhận trách nhiệm vào các công việc cần tự nghiên cứu nhiều hơn, giúp việc tích lũy kiến thức hay học hỏi các kiến thức mới dễ dàng hơn

 Công việc không quá áp lực vì có đủ thời gian để nghiên cứu, thảo luận và đưa ra giải pháp tốt nhất cho vấn đề

 Đặc biệt với sản phẩm về insurance và guarantee đã được phát triển từ lâu cho nên khi tham gia vào phát triển các về logic của sản phẩm không quá đè nặng và có đủ thời gian để thành viên mới tự nghiên cứu tìm hiểu sản phẩm.

Tiêu đề	Báo Cáo Thực Tập Automation And Manual Qc
Tác giả	Đỗ Hoàng Long, Trương Nhật Tiến
Trường học	Trường Đại Học Công Nghệ Thông Tin
Chuyên ngành	Công Nghệ Phần Mềm
Thể loại	Báo Cáo Thực Tập
Năm xuất bản	2023
Thành phố	TP. Hồ Chí Minh

Định dạng
Số trang	64
Dung lượng	3,08 MB