Ngành nào cũng cần những kỹ năng mềm, nó giúp chúng ta làm việc hiệu quả hơn, chuyên nghiệp hơn. Ngành CNTT cũng vậy, đều cần phải có những kỹ năng mềm. Trong ngành CNTT thì QA là những người càng cần phải có những kỹ năng mềm nhất định. Hôm nay mình xin giới thiệu các bài viết sưu tập được về các kỹ năng mềm cần có trong CNTT và các kỹ năng đó được áp dụng với QA như thế nào trong quá trình làm việc, cụ thể là report bug, một công việc mà hàng ngày QA đều làm.

A. Kỹ năng mềm trong IT#

Kỹ năng công nghệ là cần thiết cho bất kỳ vị trí CNTT nào (công nghệ thông tin). Tuy nhiên, nhân viên CNTT cũng cần kỹ năng mềm, đôi khi được gọi là kỹ năng giao tiếp. Các chuyên gia CNTT cần có khả năng tương tác thành công với khách hàng và nhà cung cấp, quản lý các phòng ban và truyền đạt ý tưởng của họ cho người khác.

Dưới đây là những kỹ năng mềm hàng đầu cần thiết cho hầu hết các công việc CNTT. Phát triển những kỹ năng này và nhấn mạnh chúng trong ứng dụng và phỏng vấn xin việc của bạn sẽ giúp bạn vượt lên trên sự cạnh tranh thị trường việc làm.

Cách sử dụng Danh sách kỹ năng

Bạn có thể sử dụng các từ kỹ năng được liệt kê dưới đây khi bạn tìm kiếm việc làm. Ví dụ, bao gồm một số thuật ngữ trong sơ yếu lý lịch của bạn, đặc biệt là trong mô tả về lịch sử công việc của bạn và tóm tắt sơ yếu lý lịch của bạn.

Bạn cũng có thể kết hợp chúng vào thư xin việc của bạn. Đề cập đến một hoặc hai trong số các kỹ năng được đề cập ở đây và đưa ra ví dụ cụ thể về các trường hợp khi bạn thể hiện những đặc điểm này trong công việc trước đây.

Bạn cũng có thể sử dụng những từ này trong cuộc phỏng vấn của bạn.

Mỗi công việc sẽ yêu cầu các kỹ năng và kinh nghiệm khác nhau, vì vậy hãy đảm bảo bạn đọc kỹ mô tả công việc và tập trung vào các kỹ năng được liệt kê bởi người sử dụng lao động.

10 kỹ năng mềm hàng đầu trong CNTT

1. Giao tiếp

Với số lượng email, đề xuất và tài liệu thiết kế mà một chuyên gia CNTT viết, việc giao tiếp bằng văn bản là rất cần thiết.

Giao tiếp bằng lời nói cũng quan trọng không kém. Là một nhân viên CNTT, bạn thường phải giải thích các quy trình kỹ thuật bằng các thuật ngữ rõ ràng, dễ hiểu cho khách hàng và nhà tuyển dụng. Bạn cũng cần phải có khả năng giải thích ý tưởng của bạn theo cách như vậy để làm cho người khác muốn hỗ trợ và tài trợ cho các dự án của bạn.

2. Sáng tạo

Các chuyên gia CNTT không ngừng tìm kiếm tương lai, dự đoán và phát triển các giải pháp cho các vấn đề và nhu cầu công nghệ tiềm năng.

Kiểu suy nghĩ về phía trước này đòi hỏi rất nhiều trí tưởng tượng và giải quyết vấn đề sáng tạo. Người sử dụng lao động do đó tìm kiếm các chuyên gia công nghệ cao, những người có thể nghĩ ra các giải pháp độc đáo.

3. Sự quyết tâm

Một số gian hàng của các dự án CNTT do nhiều vấn đề khác nhau - vấn đề tài chính, vấn đề với các nhà cung cấp, thiếu tinh thần đồng đội, v.v.

Điều quan trọng là chuyên gia CNTT phải tập trung vào mục tiêu cuối cùng và tiếp tục làm việc theo hướng đó. Bắt đầu một dự án với một thời gian và ngân sách rõ ràng và thực tế có thể giúp bạn đạt được mục tiêu cuối cùng của mình. Chủ nhân của bạn sẽ bị ấn tượng với khả năng của bạn không chỉ lên kế hoạch cho một dự án mà là để xem nó cho đến hết.

4. Mềm dẻo

Các chuyên gia CNTT thường phải đối mặt với những thất bại hoặc những thay đổi bất ngờ, từ một vấn đề kỹ thuật với dự án của họ đến một vấn đề vào phút chót với một nhà cung cấp. Bạn cần phải học cách linh hoạt, chấp nhận những thay đổi này và ngay lập tức tìm kiếm các giải pháp sáng tạo. Người sử dụng lao động sẽ đánh giá cao sự linh hoạt này trong một nhân viên.

Tương tự như vậy, bạn phải mở cho các đề xuất và phản hồi, cho dù từ một chủ nhân hay khách hàng. Hãy chăm chú lắng nghe bất kỳ phản hồi nào bạn nhận được và cởi mở để thực hiện những thay đổi cần thiết để cải thiện sự hài lòng.

5. Khả năng lãnh đạo

Ngay cả khi bạn không ở trong một vị trí quản lý, bạn sẽ thường được yêu cầu quản lý một dự án hoặc một nhóm, nếu chỉ trong một thời gian ngắn.

Là người quản lý dự án đòi hỏi kỹ năng giao tiếp mạnh mẽ, khả năng giao nhiệm vụ và tập trung liên tục vào mục tiêu cuối cùng. Là một chuyên gia CNTT, bạn cũng có thể tham gia quản lý nhà cung cấp. Điều quan trọng là bạn biết cách giao tiếp với các nhà cung cấp để đảm bảo nhu cầu của công ty bạn đang được đáp ứng hiệu quả.

6. Lắng nghe

Các chuyên gia CNTT không chỉ cần truyền đạt ý tưởng của riêng họ mà còn cần phải chủ động lắng nghe những người khác. Bạn cần phải chặt chẽ với những gì khách hàng hoặc chủ lao động của bạn muốn để bạn có thể cung cấp cho họ chính xác những gì họ đang yêu cầu. Đừng ngại đặt câu hỏi làm rõ để đảm bảo bạn hiểu người khác.

7. Mentoring (hướng dẫn / giảng dạy)

Các chuyên gia CNTT thường thấy mình có kỹ năng giảng dạy, hoặc cho người sử dụng lao động, nhân viên mới hoặc người dùng sản phẩm. Người sử dụng lao động sẽ đánh giá cao một nhân viên có thể thành công trong việc đi qua một quy trình kỹ thuật với sự rõ ràng và kiên nhẫn.

8. Đàm phán

Bất kể vị trí của bạn trong lĩnh vực CNTT, bạn sẽ cần một số kỹ năng đàm phán, từ việc ra quyết định thuê để cộng tác với các nhà cung cấp hoặc nhà thầu để bán ý tưởng của bạn cho một tổ chức. Việc có thể đạt được thỏa thuận thỏa mãn cả hai bên là một kỹ năng mềm tuyệt vời sẽ giúp bạn nổi bật, đặc biệt nếu bạn muốn được thăng chức lên vị trí quản lý.

9. Trình bày

Một bài thuyết trình có thể là bất cứ điều gì từ một cuộc trò chuyện trực tiếp đến một cuộc họp của bộ phận hay là một bài giảng. Dù là hình thức nào, bạn cần trình bày để có thể bày tỏ rõ ràng ý tưởng của bạn cho người khác. Ngay cả khi ý tưởng của bạn là tuyệt vời, không ai có thể đánh giá cao chúng nếu bạn không thể truyền đạt chúng hiệu quả. Làm việc trên khả năng tiếp cận của bạn, giao tiếp bằng lời nói và sự quen thuộc của bạn với các công cụ trình bày sẽ giúp bạn tăng cường kỹ năng thuyết trình của mình.

10. Làm việc theo nhóm

Các dự án CNTT thường là công việc của một nhóm các chuyên gia hơn là một cá nhân. Do đó, tinh thần đồng đội là điều cần thiết; bạn cần có khả năng truyền đạt ý tưởng của bạn và lắng nghe các đề xuất của người khác, và biết khi nào cần đảm nhận vai trò lãnh đạo và khi nào là một người chơi đồng đội.

B. 7 kỹ năng báo cáo lỗi quan trọng nhất mà mọi nhân viên QA cần có

Một thời gian trước, có người hỏi tôi: "Thomas, tôi cần những kỹ năng nào khi theo dõi lỗi và tham gia nhóm QA?"

Tôi ngạc nhiên bởi câu hỏi và quan trọng hơn, khá thất vọng khi tôi không thể đưa ra một câu trả lời tuyệt vời.

Nhưng nó làm tôi nghĩ. Và nó đã đẩy tôi làm một số nghiên cứu và trao đổi ý tưởng với những người khác trong thế giới báo cáo lỗi.

Và hôm nay, tôi rất vui và sẵn sàng trả lời câu hỏi này. Dưới đây là các kỹ năng báo cáo lỗi quan trọng nhất mà bạn cần có.

Kiến thức, quy trình công việc và kỹ năng.

Báo cáo lỗi và theo dõi lỗi yêu cầu một bộ kỹ năng cụ thể khác với những kỹ năng cần thiết trong các lĩnh vực khác như thiết kế hoặc phát triển.

Qua nhiều năm, chúng tôi đã học được rất nhiều về quy trình công việc báo cáo lỗi, công cụ và khung làm việc tuyệt vời, nhưng không có nhiều người đã chạm vào câu hỏi về kỹ năng báo cáo lỗi.

Tất cả trong một.

Lý do QA yêu cầu một loại hồ sơ đặc biệt là nó là một phần nằm ngay giữa ma trận phát triển phần mềm, làm việc với và giữa các nhà phát triển, nhà thiết kế, người quản lý sản phẩm, người dùng và khách hàng.

Nếu bạn nghĩ về vai trò của QA và báo cáo lỗi, bạn có thể nghĩ về một người đàn ông trung gian. Người đàn ông trung gian là người liên lạc với người thử nghiệm alpha và beta. Những người trong QA và thử nghiệm là những người phải yêu cầu nhà phát triển web thay đổi (sửa) code của họ.

Và khi tình hình kêu gọi nó, họ cũng là những người nói với các nhà thiết kế web rằng thiết kế của họ không đủ trực quan cho người dùng cuối.

Họ liên lạc với nhóm sản phẩm và đảm bảo họ đang đi đúng hướng để sửa các lỗi hiện có. Tất cả những người này có các chương trình nghị sự khác nhau và tùy thuộc vào nhân viên QA để đảm bảo rằng mọi người đều phù hợp và biết cần phải làm gì.

Những người QA, người kiểm thử hoặc những người báo cáo lỗi (cho dù bạn gọi họ là gì) cần nói nhiều hơn một ngôn ngữ. Về cơ bản họ phải hiểu các hoạt động đằng sau toàn bộ sản phẩm (ở một mức độ nào đó).

Vì vậy, một số kỹ năng báo cáo lỗi tuyệt vời mà bạn nên có là gì?

1. Bạn cần phải có một số kỹ năng công nghệ tuyệt vời

Là người kiểm thử, bạn được thuê để nhấn một số phần mềm hoặc sản phẩm nhất định. Bạn là người đang theo dõi từng bước nhỏ, mọi gợi ý nhỏ. Bạn đang truy tìm lỗi. Bạn là Sherlock Holmes.

Điều đó thực sự cần một số kỹ năng công nghệ và phát triển tuyệt vời để tìm lỗi, ghi lại chúng và cung cấp một mô tả toàn diện về cách làm cho chúng có thể tái hiện được. Bạn nên có ít nhất, một chút quen thuộc với các ngôn ngữ lập trình khác nhau được sử dụng để phát triển sản phẩm và với cấu hình cơ bản của các hệ thống đang sử dụng.

Tôi không nói rằng bạn phải là một nhà phát triển thiên tài, chắc chắn là không. Nhưng bạn cần phải có một sự hiểu biết cơ bản về giao diện người dùng và công nghệ phụ trợ. Bạn cần sự hiểu biết này để có thể nói chuyện với các nhà phát triển chịu trách nhiệm khắc phục các vấn đề bạn đã phát hiện.

2. Bạn cần giỏi giao tiếp

Rất nhiều tiền đã và đang bị mất do giao tiếp kém.

Thật dễ dàng để hướng dẫn một nhóm phát triển sai hướng bằng cách đơn giản là không phù hợp về thuật ngữ hoặc quản lý kém so với kỳ vọng.

Điều đó nói rằng, khi một người QA hoặc người kiểm thử cuối cùng có một số thông tin, họ phải sẵn lòng hỏi người phát triển các câu hỏi khi có câu hỏi cần được hỏi.

Sự quản lý mơ hồ là chìa khóa

Nếu không hỏi, bạn sẽ phải cố gắng xác định hoặc tạo lại lỗi. Điều đó cũng có nghĩa là một nhân viên QA tốt không bận tâm liên hệ với mọi người và tham gia vào một cuộc trò chuyện cởi mở.

3. Bạn cần phải ngoại giao

Tìm kiếm những sai lầm của người khác và giúp họ sáng tỏ vấn đề luôn luôn là một điều khó khăn để làm. Làm việc với tư cách là người kiểm thử hoặc người báo cáo lỗi có nghĩa là bạn phải có khả năng làm việc cùng với những người này một cách hiệu quả. Nó cũng có nghĩa là có thể hoàn thành công việc ngay cả khi phải đối phó với một chút kháng cự và sự cáu kỉnh ở đây và ở kia.

Không ai thích lỗi và không ai thích chúng được tìm thấy. Thiết lập một nền văn hóa cởi mở và thử nghiệm là lỗi là từ khóa thuần túy ở đây.

Nó không phải là để chỉ ra một số lỗi hoặc sai lầm nhất định cho những người phát triển. Nó chỉ đơn giản là không hoạt động.

4. Bạn cần phải là một nhà thương lượng tốt

Nghe có vẻ không trực quan, nhưng thương lượng là một phần trong cuộc sống hàng ngày của QA.

Để hoàn thành công việc trong một thời gian hợp lý, kỹ năng đàm phán là rất quan trọng. Đây là lý do tại sao.

Nhóm phát triển bận rộn với công việc phát triển của họ, vì vậy họ sẽ phải dành thời gian để sửa lỗi.

Điều đó có nghĩa là sẽ có rất nhiều sự trao đổi qua lại giữa QA và người phát triển để biết khi nào và những gì nên được thực hiện. Đây là trường hợp nhỏ hơn với các vấn đề nhỏ nhưng có thể là một yếu tố quan trọng với các vấn đề lớn hơn.

5. Bạn phải giỏi trong việc kiểm thử

Được rồi, tôi đoán điều này là hiển nhiên. Đây là công việc của bạn. Bạn hoàn toàn cần phải kiểm thử tốt. Có một sự hiểu biết tốt về các khái niệm thử nghiệm khác nhau, quy trình công việc, công cụ và kỹ thuật là một điều bắt buộc phải có.

Nếu bạn không có điều đó, bạn không phải là người phù hợp với vai trò này.

6. Bạn cần phải là một thợ lặn sâu

Khi bạn nói về các lỗi, hãy nghĩ rằng bạn hiểu vấn đề, không bao giờ tốt bằng cách thực sự hiểu được những gì đang xảy ra. Nếu không, hướng dẫn của bạn chắc chắn sẽ mơ hồ và chắc chắn sẽ làm tăng chi phí.

Đó là lý do tại sao bạn phải có một mức độ tò mò nhất định.

Là một người báo cáo lỗi, bạn đã dành rất nhiều thời gian cho bản thân sản phẩm và bạn đang tìm hiểu các chi tiết của sản phẩm. Hãy chuẩn bị để đi sâu vào sản phẩm của bạn và cơ sở công nghệ của nó.

7. Bạn cần hiểu sản phẩm của mình từ góc độ người dùng cuối

Phần mềm phải hoàn thành một chức năng nhất định. Hiểu các yêu cầu về sản phẩm và cách chúng giúp người dùng là chìa khóa để có thể giao tiếp tốt với mọi người. Nó đặc biệt quan trọng để có thể giao tiếp với người dùng cuối.

Khi trình báo cáo lỗi cần thông tin bổ sung từ người dùng, nó không thực sự giúp giao tiếp về mặt kỹ thuật.

Khi điều này xảy ra, người báo cáo lỗi phải hiểu cách sản phẩm hoạt động từ quan điểm của người dùng cuối và họ đang cố gắng làm gì. Nó cũng sẽ giúp phân biệt các vấn đề quan trọng từ những vấn đề không quan trọng.

Không có gì tệ hơn là có một người báo cáo không hiểu mức độ nghiêm trọng của một lỗi và dường như không chỉ định một mã ưu tiên thích hợp cho một lỗi.

C. Phương pháp báo cáo chỉ số 5W và 1H

1. Áp dụng W đầu tiên cho nó - "What / Cái gì"

• Ý nghĩa của "defect" là gì?
• "defect" có ý nghĩa gì đối với dự án?
• "defect" có ý nghĩa gì đối với khách hàng và bản phát hành?
• Dữ liệu nào được yêu cầu để thu thập "defect" đó?
• Công cụ nào là cần thiết để thu thập "defect"này?
• Các bên liên quan khác nhau sẽ làm gì với "defect"?
• Định nghĩa về "defect" theo tiêu chuẩn của khách hàng và dự án là gì?
• Các biến thể phân loại "defect" là gì?
• Đánh dấu băng ghế dự bị cho "defect" là gì?

2. Áp dụng W tiếp theo - "Why / Tại sao"

• Tại sao "defect" lại quan trọng đối với các bên liên quan khác nhau?
• Tại sao "defect" liên quan đến kết quả kinh doanh của dự án?
• Tại sao "defect" được ánh xạ tới thành công của dự án / phát hành?
• Tại sao "defect" cao hay thấp?

3. Áp dụng W thứ ba - "When / Khi"

• Khi nào "defect" được đo?
• Khi nào "defect" được xem là quan trọng?
• Khi nào "defect" có thể thay đổi vượt quá giới hạn?
• Khi nào giá trị "defect" có thể đưa dự án rơi vào rủi ro?

4. Áp dụng W thứ tư - "Who / Ai"

• Tất cả những ai quan tâm đến "defect"?

5. Áp dụng W thứ năm - "Which \ Cái nào"

• Yếu tố nào là gây ra "defect"?
• Yếu tố nào có thể ảnh hưởng đến "defect"?

6. Bây giờ áp dụng câu hỏi cuối cùng - H "Cách nào"

• "defect" được theo dõi như thế nào?
• "defect" được đo lường như thế nào trong hệ thống?
• "defect" sẽ tác động như thế nào đến quy trình downstream?
• "defect" sẽ ảnh hưởng như thế nào đến các bên liên quan?
• "defect" được tính toán và xác định như thế nào?

Sử dụng phương pháp 5W-1H, người ta có thể lấy được các câu hỏi khác nhau và đưa ra chỉ số và cách giải thích / tính thích hợp của nó cho dự án. Hy vọng bài viết sẽ giúp ích các bạn trong một số kỹ năng QA và report bug để tránh bị DEV vặn vẹo. )

Nguồn: https://usersnap.com/blog/7-bug-reporting-skills/ http://www.infosysblogs.com/testing-services/2010/05/the_5w_and_1h_methodology_of_m.html https://www.thebalancecareers.com/top-information-technology-it-soft-skills-2063781