Header image

Giới Thiệu Về API Là Gì?

22/04/2022

1.61k

Giới Thiệu Về API

Xin chào các bạn, mình là Thắng, thành viên team QC của SupremeTech. Trong bài viết này, mình sẽ giải thích cho các bạn về một khái niệm rất quen thuộc trong kiểm thử nói riêng mà còn trong ngành IT nói chung, đó là API.

Mình nhớ khoảng thời gian đầu tiên khi mình bắt đầu nhận việc trong một dự án với yêu cầu chỉ có API; lúc đó mình còn chưa có đủ kiến thức và kinh nghiệm cùng với sự tự tin về mảng này. Có rất nhiều câu hỏi trong đầu mình như phải tìm hiểu thế nào? Kiểm thử ra sao? Và sau đó mình đã cố gắng học hỏi và thực hành rất nhiều, sau cùng mình nhận ra API không quá khó như lúc đầu mình nghĩ, ít nhất mình đã có được kinh nghiệm và kiến thức để tự tin áp dụng vào trong dự án.

Ở đây, mình sẽ chia sẻ lại cho các bạn những gì mình đã tìm hiểu, đã áp dụng vào thực tế, để mọi người có góc nhìn khác khi một tester nhìn vào API thì sẽ như thế nào nhé.

API là gì?

API là viết tắt của cụm từ Giao diện lập trình ứng dụng (Application Programming Interface). API cung cấp khả năng truy xuất đến một tập các hàm hay dùng. Và từ đó có thể trao đổi dữ liệu giữa các ứng dụng. Một cách dễ hiểu thì API là một trung gian phần mềm cho phép hai ứng dụng giao tiếp với nhau.

Ví dụ về API trong thực tế

Tưởng tượng bạn bước vào một nhà hàng, bạn đặt món, nhân viên phục vụ sẽ tiếp nhận yêu cầu của bạn và đưa vào nhà bếp, sau đó sẽ mang ra món ăn đúng với yêu cầu của bạn. Trong ví dụ trên, API là nhân viên phục vụ, đã giúp bạn và đầu bếp giao tiếp với nhau.

Bây giờ hãy nghĩ về một trường hợp ứng dụng API trong thực tế nhé. Giả sử bạn đi du lịch, bạn sẽ vào trang web của các hãng hàng không nhằm kiểm tra chuyến bay, giá cả, số ghế,… Nhưng vấn đề ở đây là có quá nhiều hãng hàng không và bạn lại không muốn mất thời gian cho những việc thế này, thay vào đó, bạn có thể sử dụng các dịch vụ trực tuyến trung gian nhiều tiện ích như Traveloka hay Expedia. Những dịch vụ đó sẽ tương tác với API của các hãng hàng không để hiển thị cho bạn các thông tin liên quan không chỉ của một mà còn của nhiều hãng bay khác nhau, từ đó giúp cho bạn tiết kiệm được rất nhiều gian và công sức. API thật tuyệt vời đúng không!

what is an API

HTML là gì?

Khoảng thời gian sau khi World Wide Web (WWW) được ra đời vào cuối những năm 1980, nhu cầu trao đổi dữ liệu giữa các thiết bị điện tử trở nên phát triển hơn bao giờ hết. Vào thời điểm đó, các tập tin siêu văn bản HTML được đưa lên web và người sử dụng có thể đọc được nội dung một cách dễ dàng.

HTML là viết tắt của từ HyperText Markup Language – Ngôn ngữ Đánh dấu Siêu văn bản. Đây là một loại ngôn ngữ nhằm định dạng trang web thông qua các thẻ (tag) nhằm giúp cho máy tính hiểu được bố cục và cấu trúc của trang web và hiển thị trang web đó. Tuy nhiên lập trình viên chỉ có thể sử dụng những tag được quy định sẵn trong HTML khiến cho việc mở rộng hay tạo ra những nội dung mới trên website khá khó khăn.

Một vấn đề khác nữa là HTML chỉ đơn thuần là ngôn ngữ trình bày nội dung, nó không có chức năng lưu trữ hay trao đổi dữ liệu giữa các máy tính với nhau, nghĩa là các hệ thống không thể tương tác với nhau như cập nhật giá cả hàng ngày chẳng hạn.

XML là gì?

Do đó XML – Extensible Markup Language được ra đời với sứ mệnh tạo ra các tài liệu web cho cả người và máy tính đều có thể dễ dàng đọc được, khiến Internet thực sự trở thành một mạng lưới liên kết đúng nghĩa thật sự. XML được phát triển bởi mười một người đóng góp tại W3C vào năm 1997.

XML, đúng như tên gọi của nó (Extensible – mở rộng), đã giải quyết được một vài vấn đề của HTML như thay vì sử dụng các tag có sẵn thì XML cho phép các lập trình viên tự tạo ra các tag của chính mình, từ đó cho phép họ thể hiện được nhiều nội dung hơn trên website, và đặc biệt là XML cho phép gói dữ liệu vào trong nội dung văn bản và trao đổi giữa các hệ thống với nhau.

Trước khi XML ra đời thì các hệ thống vẫn có thể trao đổi dữ liệu với nhau nhưng đó là một quy trình rất phức tạp và phải thống nhất rất nhiều quy tắc, dẫn tới việc nếu trao đổi dữ liệu lớn thì sẽ xảy ra tình trạng bị mất dữ liệu trong lúc chuyển đổi. Với XML, lập trình viên có thể khai báo trước các tag của mình và các hệ thống đều có thể đọc được và tương tác với nhau dễ dàng hơn.

Mình sẽ lấy một ví dụ đơn giản cho bạn dễ hiểu nhé. Trong HTML có một thẻ tag là <title> nhằm khai báo tiêu đề trang web. Cấu trúc sẽ như thế này:

<!DOCTYPE html>
<html>
  <head>
    <title>Supremetech blog</title>
  </head>
  <body>
  </body>
</html>

Trong khi đó, với XML bạn có thể tự khai báo thẻ tag <title> với nhiều mục đích khác nhau như tiêu đề trang web và tiêu đề một quyển sách hiển thị trên trang web đó mà không lo bị lỗi:

<?xml version="1.0" encoding="UTF-8"?>
<page>
  <head>
     <title>Book store</title>
  </head>
  <body>
    <library>
      <book>
        <title>Harry Potter</title>
        <author>J.K Rowling</author>
      </book>
      <book>
        <title>Sherlock Holmes</title>
        <author>Conan Doyle</author>
      </book>
    </library>
  </body>
</page>

Các bạn có thể thấy thẻ tag <title> nằm trong thẻ <head> sẽ được máy tính hiểu là tiêu đề của trang, còn thẻ <title> nằm trong thẻ <book> sẽ được hiểu là tiêu đề của quyển sách.

SOAP và RESTful

Sau khi hiểu được API là gì, các bạn sẽ thấy API vô cùng quan trọng trong thời đại số như hiện nay. Và như một điều hiển nhiên, mọi thứ sau khi phát triển một thời gian sẽ hình thành những quy tắc chung. Sau đây mình sẽ giới thiệu 2 chuẩn phổ biến là SOAP là RESTful.

SOAP

Sau khi XML ra đời, một vài kỹ sư tại Microsoft đã phát triển SOAP. SOAP là một tiêu chuẩn dựa hoàn toàn vào XML để chuẩn hóa việc giao tiếp giữa server và thiết bị (client), từ đó giúp cho việc phát triển API tốt hơn. Sau khi SOAP xuất hiện, đặc biệt vào năm 2000, SOAP đã được Microsoft và IBM thúc đẩy và trở nên phổ biến. Một số công ty và các tập đoàn lớn đã sử dụng SOAP như HP hay Oracle cho các chương trình của họ.

Một vấn đề khá lớn của SOAP là có quá nhiều quy tắc phải tuân thủ khiến cho lập trình viên thấy nó quá khó để sử dụng. Mặc dù việc có nhiều quy tắc cũng là một ưu điểm của SOAP bởi vì nhờ đó các lập trình viên có thể tạo ra các hệ thống độc lập nhưng vẫn giao tiếp tốt với nhau. Từ khả năng giao tiếp tốt đó, các hệ thống lớn gồm nhiều hệ thống liên quan sẽ được quản lý và phát triển một cách dễ dàng hơn.

RESTful

Một nhà khoa học máy tính tên Roy Fielding đã nhìn ra vấn đề đó và giới thiệu tiêu chuẩn REST trong luận văn tiến sĩ của mình với mục đích duy nhất: tạo ra tiêu chuẩn giúp cho các server đều có thể giao tiếp được với nhau. Nếu như SOAP sử dụng XML để tạo request và response thì RESTful có thể tạo request với một URL đơn giản đi cùng với các phương thức (method) như GET, POST, PUT, DELETE và response trả về cũng được viết ở nhiều dạng như JSON hay CSV. Bạn hãy nhìn vào ví dụ dưới đây về request và response của API dùng để xem giá cả nếu được viết dưới dạng XML theo tiêu chuẩn SOAP:

  • Request
<?xml version="1.0"?>

<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">

<soap:Body>
  <m:GetPrice xmlns:m="https://www.w3schools.com/prices">
    <m:Item>Apples</m:Item>
  </m:GetPrice>
</soap:Body>

</soap:Envelope>
  • Response:
<?xml version="1.0"?>

<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">

<soap:Body>
  <m:GetPriceResponse xmlns:m="https://www.w3schools.com/prices">
    <m:Price>1.90</m:Price>
  </m:GetPriceResponse>
</soap:Body>

</soap:Envelope>

Source: W3C

Rất là rắc rối và phức tạp đúng không nào. Trong khi đó nếu ta cũng dùng API gọi thông tin về giá sản phẩm theo RESTful thì chỉ cần gửi request tới URL (https://www.w3schools.com/prices), chọn method là GET thì sẽ có response dưới dạng JSON như sau:

{
    "Apple": "1.90"
}

Nhìn vào API theo tiêu chuẩn RESTful bạn cũng nhận ra nó đơn giản và dễ dùng hơn SOAP đúng không? Đó là lí do mà vì sao RESTful được sử dụng rất nhiều vào ngày nay.

Một lí do khác là vào thời điểm những năm 2000, Internet phát triển cực kì mạnh mẽ, đặc biệt là mảng thương mại điện tử. Rất nhiều tập đoàn lớn lúc đó đã phát triển API của mình để nhiều bên có thể truy cập vào dữ liệu sản phẩm của họ. Lúc đó Salesforce là một trong những người tiên phong cung cấp API của mình dưới tiêu chuẩn SOAP nhưng lại không được nhiều lập trình viên ưa chuộng vì tài liệu hướng dẫn sử dụng hơn 400 trang.

Trong khi đó, Ebay, mặt khác lại cung cấp API theo chuẩn RESTful và đã đạt được sự thành công đáng kể so với đối thủ là Salesforce lúc bấy giờ khi mà nhiều bên cảm thấy API theo chuẩn RESTful dễ truy cập và dễ sử dụng. Kể từ đó là thời kì phát triển mạnh mẽ của RESTful API, nhiều ông lớn đã đi theo Ebay như Amazon, Flickr,… Dưới đây là sơ đồ thống kê mức độ phổ biến các chuẩn API vào năm 2014:

API

Source

Dưới góc độ kiểm thử và sự phổ biến của RESTful nên mình sẽ nói kỹ hơn về chuẩn này nhé.

RESTful API

Hình ví dụ ở trên minh họa một cách đơn giản về nguyên lý hoạt động của API theo tiêu chuẩn RESTful. Hãy lấy lại ví dụ ở phần trước đó về việc bạn sử dụng Traveloka để xem thông tin về chuyến bay nhé. Bạn vào mục tra cứu chuyến bay trên web Traveloka, sau bước này thì website – client sẽ gửi request theo giao thức HTTP tới server của hãng bay. Tùy thuộc vào phương thức – method bạn gửi thì server sẽ có những xử lý tương ứng. Trong RESTful sẽ có 4 phương thức cơ bản sau đây:

  • GET (SELECT): Trả về một Resource hoặc một danh sách Resource.
  • POST (CREATE): Tạo mới một Resource.
  • PUT (UPDATE): Cập nhật thông tin cho Resource.
  • DELETE (DELETE): Xoá một Resource.

Những phương thức hay hoạt động này thường được gọi là CRUD tương ứng với Create – Tạo, Read – Đọc, Update – Sửa, Delete – Xóa.

Ví dụ ở đây bạn muốn xem thông tin về chuyến bay thì method client dùng sẽ là GET nhằm lấy về danh sách các chuyến bay theo yêu cầu của bạn. Sau khi server nhận được request của Client sẽ tiến hành trả về dữ liệu phù hợp response. Dữ liệu trả về thường được viết dưới dạng JSON hoặc XML tùy thuộc vào tính chất của dự án. Dữ liệu trả về gồm có cấu trúc như sau (mình sẽ để dưới dạng JSON nhé):

{
    "status_code": 200,
    "data": [
        {
            "name": "LH370",
            "Time": "Mar 29, 2022",
            "City": "DNG"
        },
        {
            "name": "LH370",
            "Time": "Mar 29, 2022",
            "City": "HCM"
        }
    ],
}

Các bạn có thể thấy ở response có dòng “status_code”, biến này sẽ cho chúng ta biết được trạng thái của response trả về. Các mã sẽ được phân thành các nhóm như sau:

  • 2xx: Successful responses / Phản hồi thành công:
  • 200 OK – Trả về thành công cho những phương thức GET, PUT, PATCH hoặc DELETE.
  • 201 Created – Trả về khi một Resource vừa được tạo thành công.
  • 204 No Content – Trả về khi Resource xoá thành công.
  • 3xx: Redirects / Điều hướng
  • 304 Not Modified – Client có thể sử dụng dữ liệu cache.
  • 4xx: Client errors / Lỗi phía client
  • 400 Bad Request – Request không hợp lệ
  • 401 Unauthorized – Request cần có auth.
  • 403 Forbidden – bị từ chối không cho phép.
  • 404 Not Found – Không tìm thấy resource từ URL
  • 5xx: Server errors / Lỗi phía máy chủ
  • 500 Server Error: domain, hosting hết hạn, hoặc dừng server đột ngột để test
  • 502 Bad Gateway
  • 503 Service Unavailable

Web services là gì? Phân biệt API và web services

Và lúc này khái niệm web services trở nên phổ biến. Giờ chúng ta tìm hiểu thêm một khái niệm mới nhé.

Nói một cách khái quát, web services là những tài nguyên có sẵn trên internet, là dịch vụ cung cấp một số chức năng mà các ứng dụng khác có thể sử dụng. Chức năng này có thể bao gồm xử lý thanh toán, đăng nhập và lưu trữ cơ sở dữ liệu. Cả API và web services đều đóng vai trò giúp cho các ứng dụng giao tiếp được với nhau. Điểm khác biệt cơ bản giữa API và web services đó là web services giúp các ứng dụng giao tiếp với nhau trên Internet nhưng API có thể giúp các ứng dụng giao tiếp với nhau mà không cần Internet. Chúng ta có thể nói tất cả web services là API nhưng không phải API nào cũng là web services.

Hơi rắc rối đúng không nào, mình sẽ lấy một ví dụ cho bạn dễ hình dung nhé:

Hầu như trong cuộc sống ngày nay chúng ta luôn có sẵn ứng dụng Facebook trên điện thoại của mình. Khi bạn bắt gặp một khoảnh khắc nào đó và muốn chụp một bức hình để chia sẻ cho bạn bè cũng xem, bạn sẽ bấm vào biểu tượng máy ảnh trên Facebook và nó sẽ mở màn hình chụp ảnh cho bạn. Lúc này Facebook sẽ gọi API máy ảnh của điện thoại để sử dụng máy ảnh ngay trên ứng dụng mà không cần phải mở app chụp ảnh mặc định của điện thoại, và việc gọi API này thì không cần mạng. Ở một trường hợp khác, khi bạn vào xem thông tin một địa điểm nào đó trên Facebook thì sẽ thấy bản đồ chỉ đường tới địa điểm đó đúng không? Lúc đó Facebook sẽ gọi API (web services) từ Google Map để lấy thông tin bản đồ về và thao tác này chắc chắn cần mạng mới có thể làm được.

Cho tới hiện tại, việc tranh cãi SOAP hay RESTful tốt hơn vẫn chưa hề kết thúc. Tùy thuộc vào tính chất của dự án và sở thích của lập trình viên mà chúng ta sẽ lựa chọn chuẩn phù hợp. SOAP có thể phức tạp, phải tuân thủ nhiều quy tắc nhưng đôi khi nó lại dễ sử dụng trong một số trường hợp, còn đàn em của nó là RESTful nổi lên như một giải pháp thay thế mới mẻ song vẫn có những vấn đề của riêng nó.

Bài viết giới thiệu về API của mình đến đây là hết, mình rất vui vì một phần nào đó đã giúp các bạn có thêm những kiến thức mới. API theo chuẩn RESTful rất phổ biến, do đó kĩ năng kiểm thử API theo chuẩn này rất cần thiết với tester. Những bài viết tiếp theo mình sẽ giới thiệu cho các bạn về những công cụ thường được sử dụng trong việc test API như Postman, Charles,… Hẹn gặp lại các bạn lần sau!

Reference

  • W3schools (no date) W3schools.com, W3Schools Online Web Tutorials. Available at: https://www.w3schools.com/xml/xml_soap.asp (Accessed: 04 October 2024).
  • Jay (2023) Soap and rest at odds, The History of the Web. Available at: https://thehistoryoftheweb.com/soap-rest-odds/ (Accessed: 04 October 2024).
  • Harrington, D. (2024) The history of rest apis – readme: Resource library, ReadMe. Available at: https://readme.com/resources/the-history-of-rest-apis (Accessed: 04 October 2024).

Author: Thang Tran

Related Blog

Our culture

+0

    Tour “Đại lộ QC” – Hành trình khám phá nghề kiểm thử cùng ST

    Chào mừng bạn đến với series “Chuyện ngành chuyện nghề - Team QC”, nơi chúng mình kể lại những câu chuyện thật nhất về hành trình làm nghề, những niềm vui và… những pha “dở khóc dở cười” phía sau mỗi bản build. Để bắt đầu nghề QC thì không khó, nhưng để trở thành QC giỏi không phải điều dễ dàng. Trước khi lên đường khám phá, hãy cùng mình “bóc tem” một vài hiểu lầm kinh điển về nghề QC nhé! Có phải bạn đã từng nghĩ rằng: - Ai cũng học QC được? - Ai cũng làm QC được? - QC chỉ cần bấm bấm test test và report bug? Vậy thì hôm nay, hãy cùng gặp gỡ hướng dẫn viên du lịch - Nguyễn Quang Vũ (QC Team)  - người sẽ đưa các bạn tham quan một con đường huyền thoại mang tên “Đại lộ QC”. Thắt dây an toàn, cầm vé trên tay và chúng ta sẽ xuất phát ! Km 0 – Cổng “Khởi Đầu” Trước khi trở thành “người gác cổng chất lượng”, mỗi QC đều bắt đầu bằng giai đoạn… bấm mọi thứ có thể bấm. Đây là lúc bạn làm quen sản phẩm, hiểu người dùng, và tập làm bạn với bug. Bạn sẽ cần mô phỏng hành vi người dùng, bấm - nhìn - ghi để xem sản phẩm có chạy đúng như mong đợi. Tưởng đơn giản mà không hề đơn giản: phải quan sát và đặt câu hỏi đúng chỗ. ❓ Vì sao ai cũng nên dừng ở đây? - Đây là nơi hình thành tư duy kiểm thử và hiểu quy trình phát triển. Như học lái xe: nắm vững gương, đèn, phanh rồi mới tính chuyện đổ đèo. 💡 Mẹo sống còn: - Học cách viết test case rõ ràng. - Biết phân biệt bug vs feature (phao cứu sinh tình bạn với dev). - Ghi chép gọn gàng, ảnh/chụp màn hình là tem visa cho mỗi phát hiện. 🔌 Trạm tiếp năng lượng:  Kiểm thử các luồng “hơi đời” như mất mạng, pin 2%, nhập emoji vào ô số, đổi ngôn ngữ giữa chừng. Đây là nơi rất kích thích sự tò mò của các bạn! Km 10 – Ngã rẽ “Phát Triển” Ở Km 10, bạn chọn đường mình muốn đi, miễn đi sâu một nhánh: ⬅️ Nếu bạn chọn làn trái: Automation Test, nơi còn gọi là “Làng Code”. Bạn sẽ nhận được: - Bản đồ: biết code và tư duy code để tự động hoá những thứ lặp lại. - Điểm check-in: Script chạy qua đêm, CI/CD, báo cáo xanh lè sáng sớm. - Quà lưu niệm: Khả năng đọc API, log, mock data, dựng pipeline nhoáng cái là xong. ➡️ Còn nếu bạn chọn làn phải: Performance Test, được ví như “Thung lũng Hạ Tầng”. Bạn sẽ có 1 chuyến trải nghiệm thú vị khác: - Bản đồ: cần hiểu hệ thống, kiến trúc, infra logic; đo độ bền, độ tải, độ chịu nhiệt. - Điểm check-in: JMeter/K6, profiling, bottleneck, tuning database. - Quà lưu niệm: Biểu đồ đẹp như tranh, nơi có lời giải cho câu hỏi vì sao “chạy một mình thì nhanh, có người xem livestream thì… khựng”. 📍 Nguyên tắc vàng của Km 10:  “Biết nhiều một chút, nhưng phải biết sâu một phần.” Có chiều rộng để phối hợp, có chiều sâu để gánh trách nhiệm.  Ở đoạn đường này, QC không chỉ tìm lỗi mà còn đề xuất cải tiến, thiết kế trải nghiệm, góp phần tạo ra chất lượng toàn diện. Related Blogs: > Must-Have Tools for Business Analyst > How to Step Out of the “Forwarder” Shadow? Km 25 – Quảng trường “Tư Duy Làm Chủ” Sau một thời gian quen tay với việc test bug và viết test case, bạn sẽ nhận ra: QC không chỉ là người tìm lỗi, mà còn là người giúp sản phẩm tốt lên từng ngày. Đây là lúc bạn bắt đầu bước ra khỏi “vùng kiểm thử” quen thuộc để nhìn sản phẩm ở góc độ rộng hơn: người dùng đang cần gì, team đang gặp khó ở đâu, và giá trị thực mà sản phẩm mang lại là gì. Bạn bắt đầu làm gì? - Điều phối nhịp sprint, push tiến độ, sắp hàng ưu tiên, nhìn rủi ro bằng ống nhòm và nói chuyện người dùng như hàng xóm thân. ❓ Để ở lại quảng trường này lâu, bạn cần: - Hiểu quy trình từ yêu cầu → phát triển → phát hành. - Nắm sản phẩm & người dùng hơn cả tên thú cưng nhà mình. - “Thấu” team sản xuất: dev cần gì, design lo gì, PM sợ gì, khách hàng kỳ vọng gì. Bài học đường dài: QC giỏi có “la bàn hệ thống” - biết hướng về giá trị người dùng, không chỉ về “màu xanh của report”. Km 40 – Ghé thăm đặc khu “ST QC”  và Về đích  Sau khi băng qua những chặng đường đầy bug và deadline, mời bạn ghé trạm dừng chân tại đặc khu “ST QC”. Đây là nơi những người làm kiểm thử thật sự trưởng thành và tìm thấy hướng đi cho riêng mình. Tại đây, bạn sẽ được “đi tour” qua đủ mọi cung đường nghề QC. Từ Manual Test đến Automation hay Performance Testing, thử sức để biết bản thân phù hợp với hướng nào. Ở ST luôn được khuyến khích học hỏi, có mentor tận tình chỉ đường, và rất nhiều ngã rẽ nghề nghiệp cho bạn mở rộng: từ QA, QC Technical Lead, cho đến BA hay PM. Chúng mình tin vào văn hoá “đi thực chiến trước, giáo trình hoá sau”. Nghĩa là không học để biết, mà học để dùng, để làm cho sản phẩm tốt hơn mỗi ngày. Vé VIP cho người mới Mentor thâm niên luôn đồng hành cùng bạn.Starter Kit “xịn”: test template, bug report, release checklist, sample pipeline.Nhớ câu thần chú:  “Chất lượng là thói quen mỗi ngày, không phải phép màu cuối sprint.” Phụ lục cho hành khách yêu khám phá. Trên “Đại lộ QC”, bạn sẽ bắt gặp những biển báo quen thuộc: ⚠️ Cảnh báo dốc: Thiếu kiên trì, kỷ luật hay tư duy hệ thống rất dễ tụt dốc.🆘 Làn khẩn cấp: Khi hoang mang, hãy quay lại acceptance criteria và dữ liệu gốc.🏥 Trạm y tế: Nếu burnout, dừng lại nghỉ, xem lại ưu tiên và xin hỗ trợ đoàn mình không ai bị bỏ lại. Combo “Túi đồ nghề QC” Checklist / Test Case, Mindmap risk, Template Bug Report, Common Edge Case, Script tiện tay. Trang bị đủ hành trang để bạn tự tin băng qua mọi sprint nhé. “Đại lộ QC” không phải đường cao tốc thẳng tắp, mà nó còn có dốc, có đèo, có khúc cua tay áo. Nhưng đổi lại là một hành trình đáng nhớ: sản phẩm chạy mượt, người dùng mỉm cười, team tin tưởng nhau hơn. Con đường này dễ xuất phát nhưng khó về đích. Vì thế hãy  luôn vững tin với chiếc vé mang tên kiên trì, kỷ luật, tư duy hệ thống, chúng sẽ giúp bạn đến được nơi mình muốn. Nếu bạn đã sẵn sàng, mời lên xe chuyến sau. Hướng dẫn viên “trái ngành” vẫn ở đây, tay trái cầm bản đồ, tay phải cầm… checklist. Hẹn gặp bạn ở một cột mốc mới trên Đại lộ QC!

    12/11/2025

    43

    Our culture

    +0

      Tour “Đại lộ QC” – Hành trình khám phá nghề kiểm thử cùng ST

      12/11/2025

      43

      Knowledge

      Others

      +0

        Must-Have Tools for Business Analyst

        In today’s fast-evolving tech world, working smart has become even more crucial than working hard. In IT environments — and in any modern business — managing a growing amount of complex work can’t rely solely on memory, scattered emails, or individual Excel sheets. One of the most effective ways to boost productivity intelligently is through the use of supporting tools.This isn’t just a trend anymore — it’s quickly becoming the standard in many companies. For Business Analysts (BAs), the right tools don’t just make you more efficient — they make you more professional. Let’s explore some essential tools every BA should have in their toolkit 👇 1. Draw.io A free, intuitive diagramming tool to visualize processes, systems, data, or ideas.It’s ideal for modeling workflows and mapping business logic. Key Features: Free and no registration required — just go to diagrams.net.Flexible storage — save files locally or to Google Drive, OneDrive, GitHub, GitLab.Rich icon library — supports UML, BPMN, flowcharts, network diagrams, and more.UML & BPMN ready — perfect for use cases, activity diagrams, and business flows.Easy collaboration when stored on shared drives.Cross-platform — available on web, desktop, and as a VS Code extension. Limitations: Real-time collaboration isn’t as strong as tools like Figma.Performance may drop with very large or complex diagrams. 2. Miro Miro is an online collaborative whiteboard designed for teams to brainstorm, plan, and visualize ideas in real-time. Key Features: Infinite canvas — visualize projects without space limits.Real-time collaboration — comment, vote, and co-edit instantly.Rich templates — includes user story maps, journey maps, mindmaps, Kanban boards, and wireframes.Integrations — connects with Jira, Confluence, Slack, Teams, Google Drive, and more.Great for mapping processes, use cases, roadmaps, or even UI mockups. Limitations: Free plan limits the number of boards.Large boards with many assets may slow down performance. 3. Trello Trello is a Kanban-based task management tool that helps teams visualize and track progress easily. Key Features: Simple drag-and-drop interface.Highly customizable boards, lists, and cards.Each card can include checklists, attachments, labels, due dates, and assignees.Seamless integration with Google Drive, Slack, Jira, GitHub, and others.Real-time updates across all team members.Works on web, desktop, and mobile. Limitations: Free plan limits the number of integrations (Power-Ups). 4. Jira Jira by Atlassian is the industry-standard project management tool for Agile teams. Key Features: Built for Scrum and Kanban teams.Highly customizable workflows, fields, and automation rules.Transparent tracking of tasks, blockers, and progress.Integrates with hundreds of DevOps, CI/CD, and testing tools.Scales from individual tasks to enterprise-level project portfolios. Limitations: Steep learning curve for beginners.Can be costly for large teams.Requires experienced admins for setup and maintenance.May run slower on large, complex projects. 5. Typescale A handy tool for generating consistent typography systems (font size, line height, spacing) for web or app design. Key Features: Automates type scale creation.Multiple presets and flexible customizations.Preview and export CSS directly.Ensures responsive and accessible typography. Limitations: Not suitable for all design systems or content types.Limited control over detailed responsive behavior. 6. Adobe Color An intuitive color palette generator to create harmonious and accessible color schemes. Key Features: Easy-to-use color wheel with real-time updates.Auto-generates color harmonies based on color theory.Supports HEX, RGB, and CMYK formats.Integrates seamlessly with Adobe tools like Photoshop, Illustrator, and XD.Community palette sharing and inspiration gallery. Limitations: Contrast still needs manual checking for accessibility.Some auto-generated palettes may need manual tweaking.Colors can look different on various screens. 7. Contrast Checker A simple but vital tool to ensure readability and accessibility by checking text and background contrast per WCAG standards. Key Features: Simple interface — input colors and get instant feedback.Ensures compliance with accessibility guidelines.Real-time updates as you adjust colors.Bridges design and development — everyone can validate contrast easily. Limitations: Doesn’t reflect results accurately for complex backgrounds.Doesn’t account for font size, spacing, or user testing conditions. Why Use These Tools? Transparency: Everything — from tasks to deadlines — is clearly tracked. For example, Trello helps answer questions like “Who’s doing what?” and “What’s the current status?”Visualization: Tools like Draw.io help transform abstract logic into clear, easy-to-understand diagrams.Collaboration: Integrating tools like Miro, Jira, or Slack ensures everyone stays aligned and reduces miscommunication. Tips for Getting Started Start small: You don’t need every tool at once. Begin with Jira or Trello, then expand.Build shared habits: Tools only work when the whole team uses them consistently.Learn by doing: Explore free trials and tutorials, then apply them directly in your current projects.Stay updated: Tools evolve fast — keeping up helps you stay ahead. Using tools isn’t just about having more software — it’s about changing the way we work.They make our processes more transparent, our teamwork more seamless, and our output more efficient. For Business Analysts, these tools are not just “nice-to-have” — they’re what turn you from a task executor into a strategic enabler for your team. Read more related articles from SupremeTech!

        31/10/2025

        139

        Sang Ngo

        Knowledge

        +1

        • Others

        Must-Have Tools for Business Analyst

        31/10/2025

        139

        Sang Ngo

        Knowledge

        Others

        Our culture

        +0

          How to Step Out of the “Forwarder” Shadow?

          Have you ever, as a Comtor or Business Analyst (BA), felt like… a messenger? Every time the client asks something, you turn to the team, copy their answer, translate it, and send it back — just passing messages instead of actually owning the conversation. At SupremeTech, our BA team jokingly calls this role the “Professional Forwarder.” Through many “lost in translation” moments, we’ve learned valuable lessons on how to step out of that shadow — to become real connectors between the client and the team. Let’s hear from our BA team as they share practical tips to help you move beyond being a “forwarder” drawn directly from real project experience. Signs You Might Be Forwarding Too Much 1. The classic line: “Let me check with the team.”It’s not wrong — but if you’re saying it too often, it might mean you don’t fully understand the issue. 2. Lack of confidence in meetings: Many new BAs struggle with open-ended questions. When you don’t fully understand the product, you can’t confidently answer questions from both the client and your internal team. The PM asks about progress, you look at the Sprint Backlog full of numbers — and still don’t know where to start. 3. Avoiding technical talk: The moment you hear technical terms, you “pass the ball” to the PTL — without really understanding what’s being discussed. 3 Steps to Escape the “Forwarder Manager” Role So, how can you move from being a Forwarder to becoming a true communicator — someone who understands, connects, and leads discussions effectively? Here are three simple but powerful steps you can start practicing right away: 1. Before Forwarding, Ask Yourself: Do I understand at least 70% of this content?Have I tried to reproduce the bug, test the feature in the DEV environment, or explore the possible cause myself?If I were the dev/tester receiving this message, would I have enough context to understand it?Can I classify the issue — is it about UI/UX, logic, data, or business flow?Can I try to answer part of it first, then confirm later? 👉 This habit helps you learn something new every day, instead of just finishing tasks every day. 2. In Every Meeting – Observe and Lead What is the team really discussing? Do I understand the big picture?If the conversation is technical, how does it relate to the overall context?Is anyone confused? Can I help clarify? If you find yourself unsure about all three — take notes, take notes, and take notes.Meeting minutes and your own notes will help you retain details and follow up later for deeper understanding. 3. Build Strong Foundations Whether you’re a Comtor, BA, or PO, a solid foundation in product knowledge, business logic, and basic technical understanding helps you make better decisions — and lead your team effectively. Don’t get stuck thinking “that’s not my task.” Instead, learn actively by: Reading about technical keywords used in your project.Redrawing the business flow yourself to truly understand it.Asking devs, QCs, PTLs, and clients for their perspectives.Finding a technical advisor who can review your understanding and answer your tech-related questions. Every time you’re about to forward a message, pause for a minute — dig a little deeper.Each pause adds to your knowledge and analytical mindset. These small daily efforts will sharpen your skills and confidence — helping you grow not only as a professional BA, but also as a potential Project Leader who truly adds value to the team.

          31/10/2025

          151

          BA Team

          Knowledge

          +2

          • Others
          • Our culture

          How to Step Out of the “Forwarder” Shadow?

          31/10/2025

          151

          BA Team

          Team Người Việc: Winning with AI-Assisted Development at SupremeTech

          AI

          AI-assisted development

          +0

            How Team Người Việc Won SupremeTech’s AI Hackathon 2025 with AI-Assisted Development and Agile Thinking

            24 hours. 10 teams. Countless lines of code. One team claimed the spotlight and took half of the 100 million VND prize pool. SupremeTech’s first-ever AI Hackathon was more than just a competition, it was a test of endurance, creativity, and teamwork. For one intense day and night, our participants pushed the limits of AI-assisted development, turning raw ideas into functioning prototypes under extreme time pressure. Among them, three teams rose above the rest. Their solutions not only showcased strong technical execution but also revealed how AI hackathon use cases can bring real business value in areas such as customer experience, automation, and data-driven decision-making. These top three use cases highlight the future potential of AI and the passion of SupremeTech’s people to turn vision into reality. Brought home the Top Prize - Team Người Việc stood out for their sharp strategy and teamwork. Their winning project solved a familiar yet complex issue in the tourism industry: managing group travel efficiently while ensuring every participant enjoys a seamless experience. Presented in clear business logic, executed with agile methodology, and powered by AI-assisted development, their solution proved that innovation thrives when technology meets human insight. Introducing the Team: Small but Strong Team Người Việc brought together a crew of four: Hung Dinh, Huy Nguyen, and Dung Nguyen as front-end engineers, and Khanh Nguyen as the business analyst. While other teams had five members, this smaller team turned their size into strength. With Khanh shaping the business logic and user journey, and the three engineers transforming those ideas into a functional product, they created a strong link between business insight and technical execution. Each member brought a distinct perspective: one focused on monetization and business value, another on operational flow, and others on technical quality and user experience. Together, they created a strong team that has both business insight and technical execution. Khanh shared that: “Everyone respected each other’s opinions. We weren’t chasing perfection, we were building something real, something that worked”. The Challenge: Turning Hot and Heavy Topic into Opportunity When the AI Hackathon began, the participating teams didn’t get to choose their challenge. Each team drew a topic randomly from a pool of three, and fate handed team Người Việc a challenge that was both broad and complex: Destination and Experience Management System for Tourism. Instead of seeing it as an obstacle, the team saw great potential in this topic: “It’s actually very close to what SupremeTech does,” one member shared. “Tourism and service coordination are among the industries where our clients face similar pain points. If developed further, this could even become a real product for the company”. For most teams, tackling something this wide in just 24 hours would be overwhelming. But for Người Việc, it became the perfect opportunity to combine business logic, agile thinking, and AI-assisted development into a single solution. Dũng, one of the front-end engineers shared: “We didn’t see it as just a travel problem. It’s a coordination problem that every company faces because of too many people, too little time, and too many things to track.” The Idea: Transforming Tourism Coordination with AI Manual planning and coordination often create time-consuming processes, lack of feedback, and fragmented communication across travel agencies, corporate HR departments, and trip participants. To solve this, Người Việc envisioned an end-to-end platform that connects all stakeholders, from travel agencies and corporate planners to event organizers and trip participants.The system enables users to: Create and customize travel itinerariesConnect directly with travel agencies through a marketplace modelTrack schedules via QR codeProvide instant feedback during the trip. In short, it bridges the gap between demand and supply in hospitality, creating a more transparent, interactive, and seamless travel experience. The Process: From Brainstorming to AI-Assisted Development What set Người Việc apart was their strategic mindset before touching a single line of code. Instead of rushing to use AI tools right-away, the team began with a face-to-face brainstorming session, mapping out what a real group trip looks like from start to finish: from planning and agency communication to real-time updates and user feedback. To validate their ideas, they even called friends working in hospitality to understand pain points from the field such as: how agencies handle client requests, where information gets lost, and what travelers actually expect. Only after this discovery phase, the team moved into design and development. They first created clear user stories and workflows on their own, then applied story-based prompting by feeding those stories into ChatGPT and Copilot to generate database schemas, API endpoints, and code snippets. This structured use of AI helped them align technical output with business logic and speed up development. Their approach became a model of how AI-assisted development and agile methodology can complement each other, keeping logic clear while boosting speed. Their mantra throughout the process was simple yet powerful: Think first, then use AI smartly. This mindset kept their workflow focused, turning AI into a productivity multiplier instead of a shortcut, and became a highlight in their AI hackathon journey.Without a QC member, the team stayed flexible and shared responsibilities across roles. Each member could take on multiple tasks when needed, but they still kept a clear structure in how they worked. The PTL and BA stepped in as real users, testing features and giving feedback from a user’s point of view. After defining their user roles and business logic, Team Người Việc translated their ideas into a working prototype. Their platform acts as a bridge between corporate planners and travel agencies, creating a space where requests, itineraries, and feedback flow seamlessly in real time. The system’s core features included: Trip creation and customization: HR or operation teams can build itineraries, adjust timelines, and submit requests tailored to their needs.Agency collaboration: Travel agencies receive those requests, update details, and negotiate directly through the platform, no more back-and-forth emails or lost messages.Participant tracking: Each trip generates a public QR code, allowing members to follow updates, view schedules, and send instant feedback during the journey.Transparency and engagement: The platform closes the communication loop, giving every stakeholder a clearer view of the process. With these key flows completed, the team delivered a functional MVP, a product with clean logic, smooth handoffs between roles, and enough structure to be reused or scaled for other industries. Modern Tech Stack Built for AI-Driven Innovation To bring their concept to life within 24 hours, Team Người Việc designed a tech stack that was modern, lightweight, and AI-friendly. Every layer from frontend to deployment was chosen to balance speed, scalability, and maintainability. Frontend Layer: Fast and Built for Clarity The team developed the user interface using Next.js 15 to handle both page rendering and API routes. Combined with TypeScript, it provided type safety and consistency across all modules, reducing human errors in the rush of development. For styling and components, they used Tailwind CSS and shadcn/ui, which allowed them to quickly create a clean, responsive design without spending time reinventing basic UI elements. Despite the tight schedule, the frontend still delivered a cohesive experience from trip creation to QR-based tracking, proving that with the right stack, agility doesn’t mean sacrificing structure. Backend Layer: Structured Logic and Data Flow Behind the interface, the team used Prisma ORM to manage the database layer. Its schema-first approach, paired with TypeScript integration, helped them maintain data consistency while iterating rapidly. The backend services were also written in Next.js, utilizing server functions to keep everything unified and easy to deploy. This setup gave the team clear control over their data models and allowed them to focus on the business logic, ensuring that trip creation, feedback collection, and participant interactions all flowed smoothly without manual handling. Infrastructure & Deployment: Stability under Pressure To keep their development-to-demo pipeline fast and reliable, Người Việc deployed their system on AWS using Dokploy - a self-hosted CI/CD solution that automates Docker-based deployments. This environment allowed them to push code, test changes, and release updates seamlessly without dependency conflicts. By using Docker containers, they replicated production conditions from the start, ensuring that the MVP remained stable and demo-ready throughout the hackathon. The setup was simple enough for rapid iteration yet robust enough to be scaled for real client use. AI Tools: A Smarter, Not Faster, Way to Build AI played a key role in the team’s workflow but only after the foundation was set.ChatGPT acted as their assistant for ideation and logic design, helping refine user stories, define acceptance criteria, and clarify user flows. Meanwhile, GitHub Copilot served as their pair programmer, generating clean snippets, suggesting improvements, and handling repetitive coding tasks. Instead of using AI as a shortcut, Người Việc used it as an accelerator by integrating it at the right moments to enhance productivity while keeping control of direction and logic. >>> Read more related articles: AI-Assisted Ecommerce Solution Wins Third Place at SupremeTech AI Hackathon 2025How Human Intelligence and AI Capabilities Can Redefine Software Development | Featuring The 1st Runner-Up of SupremeTech AI Hackathon 2025 Judges’ Feedbacks Business Perspective From a business perspective, the judges saw Team Người Việc as a perfect example of practicality and vision. Their solution showed how AI-driven development can address real client needs, especially in industries like travel and hospitality. However, the judges also provided constructive feedback for future improvement. While the idea covered a broad scope from sales to operations, they suggested narrowing the focus to one specific stage in the travel management cycle. By doing so, the solution could achieve higher feasibility and faster adoption in real-world scenarios. The judges also encouraged documenting the team’s AI-assisted project management workflow as a reference for future AI hackathon journeys within SupremeTech. The final presentation showcased all the best qualities of their teamwork. The judges highlighted Người Việc’s clear storytelling, strong time management, and smooth demo delivery that effectively illustrated how their system worked. The team’s confident, structured presentation left a lasting impression and perfectly captured the spirit of SupremeTech’s AI Hackathon. Technical and Engineering Perspective From a technical point of view, the judges recognized Người Việc as a team that combined strong engineering skill with thoughtful use of modern tools. They developed their product on a well-defined code base with clear development standards, following a structured flow from analysis and design to implementation, which is remarkable under the time pressure of a 24-hour hackathon. The highlight of their approach was the story-based prompting technique, which kept the project’s logic coherent from start to finish. By crafting prompts around user stories rather than isolated tasks, the team ensured that every AI-generated piece of code served a real business purpose. This balance between automation and human reasoning became one of the defining features of their success. Teamwork: Staying Calm When Things Went Wrong No hackathon story is complete without chaos and Người Việc had their moment too. Just before the final presentation, disaster happened: the team’s slide suddenly became inaccessible because their shared drive was locked by the judges. With only minutes left, they borrowed a laptop, rebuilt the slides from scratch, and walked onto the stage calm and composed delivering a confident demo that looked effortless to the audience. The team recalled “After 22 hours of coding, what stayed with us wasn’t exhaustion. It was that moment when everyone looked at each other and said: We'll make it work, no matter what.” Voices from the Winners For Team Người Việc, winning the hackathon was not just about the prize, it was about learning how humans and AI can truly collaborate. Reflecting on the experience, Dũng shared: “We realized that AI isn’t just a tool, it’s a real teammate, if you know how to ‘talk’ to it. Each team used AI differently: some for brainstorming, some for UI design, others for presentation. But the prompts we gave were never the same, and that’s why the results were so different. AI only shows its real power when people know how to guide it.” As winners, the team also offered advice for those who will join future hackathons: “Prepare everything you can beforehand: boilerplate code, deployment setup, tools, and your fighting spirit. Once the event starts, every minute counts. And above all, trust your team” Conclusion Team Người Việc proved that real innovation is not only about technology, but about people working together with purpose. By combining business insight, teamwork, and the smart use of AI, they turned a difficult 24-hour challenge into a real achievement. For SupremeTech, this victory is more than just a competition result. It’s a reminder that the future of development starts with clear thinking, strong teamwork, and the courage to explore new ways of building with AI. Appendix: 1. How the Team Applied AI Throughout the Project StageApproachAI Application/ Tools UsedAnalysis & DesignThe whole team brainstormed together, role-playing as real users to map out workflows and features.No AI used — this was the most human-driven stage focused on critical thinking.User Story writingConverted rough ideas into logical workflows, defined goals, and acceptance criteria.ChatGPT acted as a virtual BA, turning brainstorm notes into professional User Stories and Acceptance Criteria.Coding (User Story Based)Developers implemented each User Story while communicating directly with the AI assistant for suggestions and refactoring.GitHub Copilot served as a coding partner, reading stories, suggesting code, refining syntax, and accelerating implementation.Testing & ReleaseThe PTL and BA acted as real users to test the product, identify bugs, and refine the UX before release.No AI used — manual testing for real-user validation. 2. Team Tech Stack LayerTech StackFrontend & Backend (Fullstack)Next.js 15 (App Router)UI Libraryshadcn/ui + TailwindCSSAI AssistantChatGPT + GitHub CopilotInfra / DeployAWS + Dokploy 📩 Read more articles about us here: SupremeTech’s Blog

            22/10/2025

            283

            Quy Huynh

            AI

            +1

            • AI-assisted development

            How Team Người Việc Won SupremeTech’s AI Hackathon 2025 with AI-Assisted Development and Agile Thinking

            22/10/2025

            283

            Quy Huynh

            Customize software background

            Want to customize a software for your business?

            Meet with us! Schedule a meeting with us!