DevPro Edu

[Viettel Recruitment]- Dành cho các bạn chưa biết apply vào Viettel chính thống ở đâu.
Viettel có trang tuyển dụng riêng, hiện đăng khá nhiều vị trí với JD, yêu cầu công việc và trang apply đầy đủ.

Một số vị trí: Java Backend Developer, Web Developer, Android Developer, iOS Developer, Tester... và nhiều vị trí khác ở các level khác nhau.

👉 Xem JD và apply trực tiếp tại trang tuyển dụng chính thức của Viettel: https://tuyendung.viettel.vn/recruitment-information/search -2

Các bạn đang tìm việc cứ mạnh dạn mở JD ra đọc. Đủ yêu cầu thì chuẩn bị CV và apply. Chưa đủ thì xem mình đang thiếu kiến thức, kỹ năng hay Project nào để bổ sung đúng phần đó.

Nếu chưa biết bắt đầu từ đâu, inbox DevPro. DevPro hỗ trợ check kiến thức hiện tại, đối chiếu với vị trí bạn muốn ứng tuyển và tư vấn phần cần bổ sung. Biết mình thiếu gì, rồi mới quyết định mình cần học gì.

🎁 ƯU ĐÃI HỌC PHÍ DEVPRO – THÁNG 10/2026.

Trong tháng 10, học viên đăng ký các khóa học tại DevPro được hưởng tổng ưu đãi lên tới 2.400.000đ/khóa học.

QUÀ TẶNG 20/10 DÀNH CHO HỌC VIÊN NỮ.
Tặng thêm 1.000.000đ trừ trực tiếp vào học phí khi đáp ứng đủ 2 điều kiện:
✓ Đăng ký khóa học trước ngày 20/10/2026.
✓ Hoàn thành 100% học phí toàn khóa.
➡️ Tổng ưu đãi lên tới 3.400.000đ dành cho học viên nữ đủ điều kiện.
CÁCH ĐĂNG KÝ
📩 Inbox Fanpage DevPro để được tư vấn khóa học, lịch khai giảng và xác nhận chính sách học phí.
📍 Học trực tiếp tại DevPro, Tầng 3, 147 Phố Mai Dịch, Hà Nội hoặc Online Live.
Đăng ký sớm để DevPro giữ lịch học và áp dụng đúng mức ưu đãi tháng 10.

[XUẤT PHÁT SỚM] – LỘ TRÌNH MANUAL TEST TỪ NỀN TẢNG ĐẾN SẴN SÀNG APPLY 🚀
🧱 Mục tiêu: Xây dựng nền tảng kiểm thử phần mềm bài bản, thực hành trên Project và chuẩn bị kiến thức – kỹ năng cần thiết để ứng tuyển vị trí Intern/Fresher Tester.
Khóa học Manual Test tại DevPro được xây dựng theo 5 chặng, đi từ hiểu nghề → biết cách kiểm thử → thực hành → Project → chuẩn bị CV và phỏng vấn.
Không chỉ học “Tester là gì?”, mục tiêu quan trọng hơn là sau từng chặng, học viên phải biết mình đang kiểm thử cái gì, kiểm thử như thế nào và vì sao phải kiểm thử như vậy.
🔰 CHẶNG 1 – NỀN | HIỂU ĐÚNG VỀ KIỂM THỬ PHẦN MỀM
• Làm quen với quy trình phát triển và kiểm thử phần mềm.
• Hiểu vai trò của Tester trong một dự án thực tế.
• Nắm các khái niệm, nguyên tắc và kỹ thuật kiểm thử cơ bản.
• Làm quen với Requirement, Test Scenario, Test Case, Test Data và quy trình xử lý lỗi.
🔸 Mục tiêu: Không học thuộc khái niệm đơn thuần. Học viên cần hình thành được tư duy kiểm thử và cách đặt câu hỏi trước một yêu cầu phần mềm.
📝 CHẶNG 2 – TEST | TỪ REQUIREMENT ĐẾN TEST CASE
• Phân tích Requirement và xác định những nội dung cần kiểm thử.
• Xây dựng Test Scenario.
• Thiết kế và viết Test Case.
• Chuẩn bị Test Data.
• Thực hành các kỹ thuật thiết kế Test Case trên những tình huống cụ thể.
Quy trình được luyện tập: Requirement → Test Scenario → Test Case → Test Data → Execute Test
🔸 Mục tiêu: Học viên không chỉ biết một Test Case gồm những trường nào, mà phải biết từ một yêu cầu thực tế, mình cần kiểm thử những gì.
🐞 CHẶNG 3 – BUG | TÌM LỖI, GHI NHẬN VÀ THEO DÕI LỖI
Tìm thấy lỗi mới chỉ là một phần công việc của Tester.
Học viên tiếp tục thực hành:
• Execute Test.
• Xác định Actual Result và Expected Result.
• Viết Bug Report rõ ràng để Developer có thể reproduce.
• Theo dõi quá trình xử lý Bug.
• Re-test/Verify sau khi lỗi được sửa.
• Regression Test để kiểm tra ảnh hưởng đến các chức năng liên quan.
🔸 Mục tiêu: Đi hết một vòng kiểm thử thay vì chỉ dừng lại ở việc “em tìm thấy Bug rồi”.
💻 CHẶNG 4 – THỰC CHIẾN | WEB – API – MOBILE – PROJECT
Kiến thức kiểm thử chỉ thực sự có ý nghĩa khi được đưa vào thực hành.
Học viên được tiếp cận và thực hành kiểm thử trên các môi trường phổ biến:
• Kiểm thử Web.
• Kiểm thử API.
• Kiểm thử Mobile.
• Thực hành Test Case và Bug Report.
• Làm Project trong quá trình học.
Từ Requirement, học viên từng bước thực hiện: Phân tích → Thiết kế Test → Chuẩn bị dữ liệu → Execute → Bug Report → Re-test → Test Report
🔸 Mục tiêu: Có trải nghiệm với một quy trình kiểm thử tương đối hoàn chỉnh và có Project thực tế để trình bày trong CV cũng như khi phỏng vấn.
🎯 CHẶNG 5 – APPLY | CV – PHỎNG VẤN – CHUẨN BỊ ĐI LÀM
Học xong kiến thức chưa phải điểm kết thúc.
Ở chặng cuối, DevPro hỗ trợ học viên:
• Check lại kiến thức Manual Test.
• Hướng dẫn xây dựng và chỉnh sửa CV.
• Hướng dẫn cách trình bày Project trong CV.
• Chuẩn bị các nhóm câu hỏi thường gặp khi phỏng vấn Tester.
• Hướng dẫn cách tìm kiếm và đọc JD tuyển dụng.
• Định hướng apply Intern/Fresher phù hợp với năng lực hiện tại.
🔸 Mục tiêu: Biết mình đã có gì – còn thiếu gì – cần chuẩn bị gì tiếp theo trước khi bước vào quá trình ứng tuyển.
📚 HÌNH THỨC HỌC TẠI DEVPRO
🔹 Học trực tiếp tại DevPro hoặc Online Live dành cho học viên ở xa.
🔹 Lịch học ngoài giờ, phù hợp với sinh viên và người đang đi làm.
🔹 Có video bài học để xem lại.
🔹 Thực hành và làm Project trong quá trình học.
🔹 Được hỗ trợ check kiến thức, CV và định hướng ứng tuyển sau khóa học.
📍 DevPro – Tầng 3, 147 Phố Mai Dịch, Hà Nội.
❤️ CỘNG ĐỒNG HỌC VIÊN DEVPRO
Qua nhiều năm đào tạo, rất nhiều thế hệ học viên Tester của DevPro đã bước vào thị trường lao động. Có những anh/chị ngày trước bắt đầu từ những Test Case đầu tiên, những Bug Report đầu tiên; đến nay đã có nhiều năm kinh nghiệm, trở thành Senior, Leader, Manager và trực tiếp tham gia tuyển dụng, đào tạo những thế hệ Tester tiếp theo.
🌸 Anh/chị học viên cũ DevPro đang làm Tester/QA/QC có thể điểm danh dưới comment và chia sẻ một vài dòng về hành trình của mình để các bạn mới tham khảo nhé ❤️
🌸 Các bạn đang học tại DevPro cũng có thể điểm danh lớp mình dưới bài viết.
✅ BẠN ĐANG MUỐN BẮT ĐẦU VỚI TESTER?
Nhắn DevPro để được tư vấn lộ trình và check điểm xuất phát trước khi đăng ký.
Có bạn cần bắt đầu từ nền tảng.
Có bạn đã tự học và chỉ thiếu một số phần.
Có bạn kiến thức đã đủ, DevPro sẽ khuyên tập trung hoàn thiện Project, CV và bắt đầu apply thay vì học lại những gì mình đã biết.
Học đúng phần mình thiếu – thực hành đủ phần mình cần – chuẩn bị cho mục tiêu đi làm.
👉 Inbox Fanpage DevPro để được tư vấn khóa Manual Test – Kiểm thử phần mềm.

CONFIRM REQUIREMENT – CÓ LẼ ĐÂY LÀ MỘT TRONG NHỮNG THỨ TESTER NÊN HỌC ĐẦU TIÊN
Có Requirement. Đọc Requirement. Viết Test Case. Execute Test. Actual Result khác Expected Result thì ghi nhận Bug.

Nhưng đi vào dự án thực tế, câu chuyện không phải lúc nào cũng đi theo một đường thẳng như vậy.

Requirement không phải lúc nào cũng tồn tại dưới dạng một bộ tài liệu đầy đủ, thống nhất và được cập nhật đến phiên bản cuối cùng. Có thông tin nằm trong tài liệu, có thông tin nằm trên ticket, prototype, comment, email, biên bản họp; cũng có những thay đổi chỉ vừa được thống nhất giữa Customer, PO, BA, Dev và Tester.

Và quan trọng hơn: Requirement cũng có thể sai.

Có thể thiếu business rule. Có thể hai tài liệu mô tả hai cách xử lý khác nhau. Có thể UI Design đã thay đổi nhưng Requirement chưa cập nhật. Có thể Acceptance Criteria chưa bao phủ một trường hợp biên. Thậm chí điều khách hàng nói họ muốn ban đầu và điều họ thực sự cần sau khi nhìn thấy sản phẩm cũng có thể khác nhau.

Vì vậy, Tester không thể làm việc với tư duy: Tài liệu ghi thế này thì cứ thế mà Test.
Nhưng cũng không thể: Theo em thì hệ thống phải chạy thế này.
Khoảng giữa hai cách đó chính là một kỹ năng rất quan trọng: CONFIRM.
Ví dụ Requirement chỉ có một câu: Account will be locked after multiple failed login attempts.
Nếu Tester tự mặc định multiple là 3 lần rồi viết Test Case thì Test Case đó đang dựa trên giả định của Tester, không phải Requirement đã được xác nhận.
Một người có kinh nghiệm sẽ bắt đầu nhìn thấy hàng loạt câu hỏi phía sau câu Requirement tưởng như rất đơn giản ấy:

Khóa sau bao nhiêu lần nhập sai? Các lần sai phải liên tiếp hay cộng dồn? Nếu lần thứ ba nhập đúng thì counter có reset không? Counter tính theo account, device hay IP? Account bị khóa trong bao lâu? Tự unlock hay cần Admin? Trong thời gian bị khóa, nhập đúng password thì xử lý thế nào? Thông báo cho người dùng ra sao?

Và còn một câu quan trọng: Ai là người có thẩm quyền xác nhận những câu trả lời này?
Đó mới là bản chất của Confirm Requirement.
Confirm không phải là Tester gặp cái gì cũng quay sang hỏi BA hoặc Developer. Tester vẫn phải đọc tài liệu, kiểm tra các nguồn thông tin hiện có, hiểu business và tự phân tích trước.

Nhưng khi xuất hiện ambiguity, contradiction, missing information hoặc một assumption có thể ảnh hưởng đến Expected Result, Tester cần đưa vấn đề ra để xác nhận với đúng người có trách nhiệm.

Bởi nếu Requirement chưa rõ mà Tester tự hiểu, Developer cũng tự hiểu, rất có thể cả hai đều làm “đúng” theo cách hiểu của mình nhưng sản phẩm cuối cùng vẫn sai so với nhu cầu thực tế.
Và cái giá của một Requirement chưa được làm rõ không chỉ là một Test Case sai.

Nó có thể là Dev phải sửa code, Tester phải sửa Test Case và test lại, BA phải cập nhật tài liệu, cả Team phải regression lại phần liên quan. Một câu hỏi được đặt ra sớm đôi khi tiết kiệm rất nhiều công việc ở phía sau.

Đó là lý do DevPro không muốn người mới học Tester hình thành thói quen chỉ nhìn giao diện rồi tìm xem chỗ nào có Bug.

Trước Test Case phải có Test Analysis.
Trước khi xác định Expected Result phải hiểu Requirement.
Và khi Requirement chưa đủ rõ: Đừng assume. Hãy confirm.
Một Tester có kinh nghiệm không nhất thiết là người hỏi nhiều nhất.
Mà là người biết điều gì có thể tự phân tích, điều gì đang là assumption và điều gì bắt buộc phải được confirm trước khi Team đi tiếp.

Send a message to learn more

Công ty MISA đang tuyển dụng nè các bạn. Mà nghe nói giờ code 1 ngày là xong cả dự án rồi, chắc chỉ cần đến công ty và... lãnh lương thôi 😂 Nhanh tay apply, chứ ad cũng không biết mai còn việc gì để làm không 😆

CHÀO MỪNG TESTER60

19 thành viên, 19 xuất phát điểm khác nhau, nhưng từ hôm nay chúng ta có chung một hành trình: học đúng - thực hành thật - hiểu bản chất - sẵn sàng bước vào thị trường việc làm.
DevPro sẽ đồng hành cùng các bạn trong suốt chặng đường này.
Không chỉ học để biết mà học để làm được và tạo ra kết quả.
Tester60 cùng nhau bắt đầu, cùng nhau tiến bộ, cùng nhau chạm đến một công việc phù hợp 🚀

ĐỪNG HỌC TESTER – NẾU BẠN CHƯA BIẾT MÌNH ĐANG THIẾU GÌ
Một câu hỏi DevPro nhận được khá thường xuyên là: Em muốn làm Tester thì nên học khóa nào?
Nhưng có lẽ trước câu hỏi đó, còn một câu quan trọng hơn cần trả lời: Bạn đang ở đâu trên hành trình trở thành Tester?

Có bạn bắt đầu gần như từ ZERO, chưa hiểu Tester thực sự làm công việc gì. Có bạn đã tự học khá nhiều, biết Test Case, Bug Report nhưng chưa từng làm một Project tương đối hoàn chỉnh. Có bạn đã có kiến thức và Project nhưng CV chưa thể hiện được năng lực. Cũng có những bạn sau khi check lại thì kiến thức đã tương đối ổn, thứ còn thiếu chỉ là chuẩn bị phỏng vấn và bắt đầu apply.
Những điểm xuất phát khác nhau thì không nên mặc định dùng cùng một lời giải.
TỪ ZERO ĐẾN CV TESTER – ĐÓ LÀ MỘT HÀNH TRÌNH
Nếu bắt đầu từ con số 0, một lộ trình Manual Test có thể hình dung như sau: ZERO → FOUNDATION → PRACTICE → PROJECT → CV → INTERVIEW → APPLY

Từ chỗ chưa biết Tester làm gì, người học cần hiểu nghề và những kiến thức nền tảng của kiểm thử phần mềm. Sau đó mới đến việc đọc Requirement, xây dựng Test Scenario, viết Test Case, chuẩn bị Test Data, Execute Test, tìm và báo Bug, Re-test…

Khi phần nền đã hình thành, việc học cần chuyển dần sang thực hành. Không chỉ biết Test Case là gì mà phải tự viết được. Không chỉ biết Bug Report gồm những trường nào mà phải gặp một lỗi thực tế, xác định được Expected Result – Actual Result và mô tả đủ rõ để người khác có thể reproduce.

Tiếp theo là Web, API, Mobile và Project. Đây là lúc những kiến thức rời rạc bắt đầu được nối lại thành một quy trình làm việc. Người học cần biết mình đang kiểm thử cái gì, tại sao kiểm thử như vậy và kết quả công việc của mình được thể hiện ra sao.

Nhưng Project cũng chưa phải điểm cuối của một lộ trình đào tạo nghề. Một sinh viên có thể hoàn thành Project nhưng vẫn chưa biết viết gì vào CV. Có CV rồi nhưng khi được hỏi “Trong Project này em đã làm gì?” lại chưa biết trình bày. Có kiến thức nhưng chưa từng đọc JD để biết doanh nghiệp đang yêu cầu gì ở một Intern/Fresher Tester.
Vì thế, sau Project vẫn còn một đoạn rất quan trọng:
PROJECT → CV → INTERVIEW → APPLY

VẬY 24 BUỔI THỰC SỰ CÓ Ý NGHĨA GÌ?
24 buổi là thời lượng của một chương trình học, không phải giá trị cuối cùng mà người học cần nhận được.
Điều đáng quan tâm hơn là trạng thái của người học đã thay đổi như thế nào: Chưa biết Tester làm gì
→ Hiểu nghề và quy trình kiểm thử
→ Biết viết Test Case
→ Biết Execute Test, tìm và báo Bug
→ Biết kiểm thử Web/API/Mobile
→ Có Project để đưa vào CV
→ Biết trình bày những gì mình đã làm
→ Biết mình còn thiếu gì so với yêu cầu tuyển dụng
→ Chuẩn bị cho Interview và Apply.

Đó mới là lý do DevPro nhìn một chương trình Manual Test như một lộ trình, thay vì chỉ là một khóa học gồm bao nhiêu buổi.

KHÔNG PHẢI AI CŨNG CẦN ĐI TỪ ZERO
Đây mới là phần quan trọng.
Một bạn đã biết Test Case, Bug Report và có nền tảng kiểm thử thì không nhất thiết phải quay lại học mọi thứ từ đầu. Nếu thiếu thực hành, hãy tập trung vào thực hành. Nếu thiếu Project, hãy làm Project. Nếu kiến thức và Project đã ổn nhưng CV yếu, hãy sửa CV. Nếu CV đã ổn nhưng chưa quen phỏng vấn, hãy chuẩn bị phỏng vấn và bắt đầu ứng tuyển.
Nếu check xong thấy kiến thức hiện tại đã đáp ứng tương đối tốt cho vị trí đang hướng tới, thì giải pháp có khi không phải đăng ký thêm một khóa học.

Hãy chuẩn bị CV và đi apply.
Đó cũng là cách DevPro tiếp cận việc tư vấn đào tạo:
1. Check kiến thức và điểm xuất phát hiện tại.
2. Xác định mục tiêu: tìm hiểu nghề, thực tập, Fresher hay chuyển nghề.
3. Đối chiếu với năng lực cần có ở mục tiêu đó.
4. Xác định phần còn thiếu.
5. Bổ sung đúng phần cần thiết.
6. Khi đã đủ điều kiện, chuyển sang CV – Interview – Apply.

Một khóa học chỉ nên xuất hiện ở bước số 5 nếu đó thực sự là phần người học cần.
DevPro không đặt mục tiêu để tất cả mọi người đều bắt đầu ở Buổi 1. Điều quan trọng hơn là xác định đúng bạn đang đứng ở đâu và bước tiếp theo nên là gì.

Nếu đang muốn theo Tester nhưng chưa biết mình thiếu nền tảng, thực hành, Project, CV hay kỹ năng phỏng vấn, có thể nhắn DevPro để cùng check lại trước.

Biết mình thiếu gì, rồi mới quyết định mình cần học gì.