Ngành kiểm thử phần mềm đang trở nên hot hơn bao giờ hết. Và không có gì ngạc nhiên khi càng ngày càng có nhiều người muốn trở thành Tester. Tôi thường xuyên nhận được Email chia sẻ về việc các Tester đã hứng thú như nào với công việc Test của họ.

Tôi rất vui và mừng cho họ .

Thật không may, tôi cũng nhận được những lời phàn nàn về việc không thực sự thích cái nghề này. Họ cảm thấy như họ đã chọn con đường sai lầm và họ đang lãng phí thời gian của họ cùng với việc Testing sau vài tháng từ khi bắt tay vào làm.

Tại sao chuyện này lại xảy ra??? Chẳng phải họ đã từng rất hứng thú và hào hứng ngay từ khi bắt đầu ? Có một vài lý do giải thích cho chuyện này nhưng theo tôi có một lý do lớn nhất đó chính là: Vỡ mộng

Họ nghĩ Testing rất eazy và thực tế thì chứng minh không phải như vậy.

Họ nghĩ rằng Software Testing chỉ là việc tìm tìm bugs. Còn bây giờ họ nhận ra rằng có rất nhiều công việc liên quan mà họ không thích làm hằng ngày. Họ đang cảm thấy không chắc rằng liệu Testing có phải là con đưòng sự nghiệp đúng đắn để theo đuổi hay không .

Thật là tồi tệ khi chuyện này xảy ra. Tuy nhiên, bạn có thể tránh được những tình huống như vậy bằng cách biết được rằng thực chất Testing là như thế nào, các hoạt động thử nghiệm nào đang chờ bạn ở phía trước để quyết định xem bạn có muốn đi cùng với nó... ngay từ đầu hay không ?

Đó chính xác là những gì tôi muốn chia sẻ với các bạn ở tại bài post này.

Note: Hãy lưu ý giúp tôi rằng, hoạt động kiểm thử không dừng lại ở những điều mà tôi đề cập ở bài viết này . Dựa vào king nghiệm , tôi sẽ cố gắng liệt kê ra một vài điều nhưng tôi không chắc là nó chỉ dừng lại ở đấy. Vì thế, tại thời điểm này, hãy chú ý rằng có thể các công ty sẽ sử dụng các term khác để refer đến những điều mà tôi cung cấp trong danh sách.

1) Read documents

https://images.viblo.asia/de1f461c-7b6b-48ab-9db4-82817cdde62a.jpg

Cuối cùng , bạn đã làm được. Bạn đã được thuê sau một vài vòng phỏng vấn cùng một vài khó khăn và những câu hỏi tốt ( thỉnh thoảng cũng có thể là không tốt ) nhưng nó không quan trọng nữa rồi. Hiện tại bạn đủ trình độ cho vị trí và bạn trở thành Tester .

Hãy thử tưởng tượng ngày đầu tiên làm việc của bạn. Quản lý của bạn sẽ giới thiệu bạn với member trong team. Nếu bạn may mắn được join trong team cởi mở, từng người trong team sẽ tự giới thiệu lại. Sau màn chào hỏi, bạn sẽ cảm thấy phấn khích khi được giao cho những task đầu tiên.

"Này em, đây là tài liệu của dự án. Hãy đọc chúng nhé !!! " Quản lý nói

Okay. Tôi có vẻ phóng đại một chút nhưng về cơ bản bạn sẽ được giao task đọc tài liệu như tài liệu mô tả, hướng dẫn.. để bạn nắm được hệ thống mà bạn sẽ test.

Trong khi bạn đang mơ mộng trở thành một ngôi sao nhạc rock nơi mà bạn tìm được rất nhiều bug thì tôi phải nói rằng đọc tài liệu để có hiểu biết về hệ thống là một trong những những điều bạn cần làm trong dự án.

Vì vậy, hãy tận dụng cơ hội này để đọc và hỏi càng nhiều câu hỏi càng tốt về hệ thống bạn sẽ kiểm tra. Nếu dự án của bạn không có bất kỳ tài liệu nào, hãy hỏi người quản lý của bạn về cách biết thêm về hệ thống.

Sau khi bạn kết thúc việc đọc tài liệu, bạn có thể phải trình bày những gì bạn đã đọc và cách bạn hiểu mọi thứ cho các thành viên nhóm / người lãnh đạo. Người ta gọi đó là output. Bạn cũng có thể sử dụng kiến thức bạn có để bắt đầu các hoạt động thử nghiệm khác như các trường hợp kiểm tra thiết kế mà tôi sẽ nói sau này.

Hoạt động này kéo dài bao lâu?

Nó tùy thuộc vào dự án của bạn như thế nào. Có một vài dự án nhỏ chỉ cần 2-3 ngày để đọc . Một vài dự án lớn, số ngày bạn cần sẽ nhiều hơn.

Hoạt động này thú vị như thế nào ?

Không. Nó khá là nhàm chán. Tôi chưa từng được nghe bất kỳ Tester nào nói rằng họ thích thú việc đọc tài liệu. Nó thậm chí còn nhàm chán hơn khi bạn không thể truy cập vào hệ thống trong lúc đọc tài liệu. Điều này có nghĩa là bạn sẽ đọc tài liệu và tưởng tượng xem hệ thống và các thành phần trong nó sẽ làm việc cùng nhau như thế nào.

Hoạt động này có quan trọng không ?

Rất quan trọng. Mặc dù hoạt động này xem như rất buồn chán nhưng nó thực sự quan trọng. Việc bạn càng hiểu nhiều về hệ thống sẽ giúp cho việc viết testcase và tìm ra bug càng hiệu quả hơn.

2) Test case design or test case writing

Nếu dự án của bạn là dự án truyền thống folllow theo các mô hình phát triển phần mềm truyền thống và bạn bắt đầu join dự án từ đầu thì việc thực hiện hoạt động này là một điều chắc chắn . Hoạt động này có tên là design hoặc viết testcase

Tôi giả định rằng bạn đã biết về khái niệm design testcase. Hãy lưu ý rằng luôn có sự đa dạng trong các viết hoặc trình bày test case của bạn . Bạn có thể xây dựng checklist, mindmap, hoặc một cái kịch bản kiểm thử có đầy đủ các bước...

Điều đó nghe có vẻ choáng ngợp nhưng đừng lo lắng. Thông thường ,người quản lý của bạn sẽ cung cấp cho bạn một số loại hướng dẫn về cách thiết kế trường hợp thử để bạn có thể follow dễ dàng.

Một hoạt động khác của design testcase là : Reviewing testcase

Vì bạn là người mới, bạn thường được quan tâm nhiều hơn. Điều đó có nghĩa là những việc bạn thường làm được đánh giá bởi lead của mình hoặc những người cùng làm với bạn.

Khi bạn đã hoàn tất testcase , leader / đồng nghiệp của bạn sẽ ngồi lại với bạn để xác minh và xác thực các trường hợp kiểm tra của bạn để đảm bảo bạn làm đúng việc và làm việc đó đúng. Nếu bạn làm đúng ngay lần đầu tiên, thật tuyệt vời, nhưng thường xuyên hơn bạn phải quay lại và chỉnh sửa testcase từng chút một.

Đừng coi đây là một điều không hay. Luôn luôn là tốt nếu có một ai đó xem xét những việc bạn làm, đưa ra ý kiến của họ và làm cho bạn tốt hơn. Đây cũng là cơ hội tuyệt vời để bạn đặt câu hỏi và làm rõ mọi thứ để bạn biết thêm về hệ thống.

Mặc dù việc design testcase không phải là một công việc vui vẻ, nhưng nó cũng không quá nhàm chán. Một số Tester tôi biết họ rất yêu thích công việc này họ có cơ hội sáng tạo trong cách họ muốn thử nghiệm hệ thống.

3) Test execution/regression

Mỗi khi bạn có một bản build mới để kiểm tra, bạn cần phải chạy lại các trường hợp thử nghiệm đã được viết. Chúng tôi gọi đó là hoạt động kiểm tra hồi quy.

Nếu bạn có 10 Testcases cho một chức năng , bạn cần chạy lại tất cả 10 Testcases này.

Nếu bạn có 100 Testcases cho hệ thống , bạn cần chạy lại tất cả 100 Testcases này.

Kiểm tra hồi quy rất có ích cho việc testing nhưng nó gặp phải vấn đề đó là : Update testcase

Khi bạn chạy lại testcase ở bản mới , bạn nhận ra rằng có một vài Funtions trong hệ thống bị thay đổi và kịch bản bạn viết trở nên lỗi thời. Và bạn cần phải xem lại testcase và chỉnh sửa chúng mới nhất và sau đó là chạy chúng. Sẽ không có vấn đề gì nếu như những thay đổi này là nhỏ và chỉ có vài case cần chỉnh sửa. Tuy nhiên nó sẽ trở thành vấn đề nghiêm trọng nếu như chức năng chính thay đổi dẫn đến hàng trăm testcase cần update. Thật là không vui vẻ gì ...

Nhưng đừng lo lắng, hệ thống thì không phải luôn thay đổi . Một ngày tốt đẹp nào đó, bạn phải làm công việc này, biết đâu đấy bạn có thể thậm chí tìm được những bug quan trọng bằng cách chạy test case @@

Hoạt động Regresstion test này thú vị như nào ?

Câu trả lời là : Cũng bình thường.

Nếu bạn chỉ cần chạy một vài vòng hồi qui, bạn không sao. N hưng nếu chu kỳ hồi quy của bạn ngắn và bạn cần phải lặp lại toàn bộ bộ thử nghiệm của mình, điều này có thể trở nên nhàm chán. Tuy nhiên, như tôi đã nói ,thử nghiệm hồi quy là thực sự quan trọng, vì vậy, dù muốn hay không, sớm hay muộn, bạn sẽ phải làm điều đó.

4) Exploratory testing

Hầu hết các hoạt động thử nghiệm khá nhàm chán nhưng với tư cách là người kiểm thử thì tôi chắc chắn bạn sẽ thích hoạt động này: kiểm thử khám phá (hoặc thử nghiệm đặc biệt nếu bạn muốn gọi)

Đây là lúc bạn tỏa sáng. Đây là cơ hội để bạn sử dụng mọi kiến thức về hệ thống, kỹ năng tìm lỗi của bạn để tìm lỗi trong hệ thống.

Hãy bỏ qua nếu bạn đang follow theo kỹ thuật dựa trên phiên để khám phá hoặc bạn mới chỉ thực hiện free test phiên , tôi phải thừa nhận thật thú vị khi thực hiện hoạt động này. Bạn sẽ tìm thấy các lỗi không được đề cập trong các trường hợp thử nghiệm theo kịch bản của bạn. Bạn sẽ mở ra sự sáng tạo và trí tưởng tượng của bạn để suy nghĩ về các tình huống mà người dùng cuối sẽ sử dụng hệ thống và làm thế nào mọi thứ có thể đi sai.

Vì thử nghiệm thăm dò là một hoạt động quan trọng và thật thú vị, tôi luôn khuyên chúng ta nên lên lịch một khoảng thời gian tốt cho loại thử nghiệm này trong dự án. Nó thực sự hữu ích.

5) Bug reporting

Nếu bạn là người thử nghiệm, sớm hay muộn bạn sẽ tìm thấy lỗi và bạn cần báo cáo lỗi đó. Về cơ bản, nó chỉ là một hoạt động để bạn nói cho mọi người biết vấn đề bạn đã tìm thấy, đưa chúng ra và sửa chúng.

Việc này có khó không ???

Thông thường, nhóm của bạn cũng có một bộ hướng dẫn hoặc định dạng để bạn theo dõi. Follow theo và apply vào rồi bạn sẽ ổn thôi.

Việc này có buồn chán???

Không hẳn. Tôi không biết bạn nhưng viết báo cáo lỗi khá thú vị với tôi. Không chỉ vì đó là một cách để "thể hiện" kết quả thử nghiệm của tôi mà còn giúp tôi thực hành kỹ năng viết. Nếu tôi có thể viết một báo cáo lỗi tốt, mọi người có thể hiểu vấn đề một cách nhanh chóng và mức độ nghiêm trọng của nó như thế nào.

Nó quan trọng? Câu trả lời là rất quan trọng. Xin lưu ý rằng khi bạn làm thử nghiệm, bạn không chỉ thử nghiệm mà còn cung cấp dịch vụ và công việc của bạn là cung cấp càng nhiều thông tin về hệ thống đang được kiểm tra càng tốt và báo cáo lỗi là một trong số đó. Làm đúng, mọi người sẽ thấy giá trị của bạn.

Một số cạm bẫy cần lưu ý:

1. Tránh báo cáo lỗi trùng lặp

2. Tránh báo cáo lỗi không hợp lệ

3. Tránh báo cáo lỗi không thể tái hiện

4. Tránh đổ lỗi cho ai đó vì nguyên nhân gây ra lỗi

5. Tránh thiếu thông tin quan trọng trong các lỗi như tiêu đề, mô tả, bước để tái sản xuất, v.v.

6) Meetings

https://images.viblo.asia/41fdff56-1d0b-4566-81c2-e675ba9be19e.gif

"Oh lại meeting" ... có một sự thật không đẹp về các cuộc họp, nhưng có thích hay không, cuộc họp là không thể tránh khỏi trong các dự án.

Có nhiều loại cuộc họp khác nhau xảy ra trong suốt thời gian hoạt động của dự án. Dưới đây là một số thông thường:

Daily meeting:

Nếu nhóm của bạn đang làm việc theo quy trình Scrum, cuộc họp hàng ngày được coi là bắt buộc. Trong cuộc họp này, mỗi thành viên trong nhóm sẽ thay phiên nhau cập nhật tiến trình làm việc bằng cách trả lời ba câu hỏi sau:

• Ngày hôm qua bạn đã làm gì?

• Ngày hôm nay bạn sẽ làm gì?

• Có vấn đề gì bạn gặp phải không ?

Nếu bạn không theo mô hình Scrum, cuộc họp hàng ngày cũng rất quan trọng trong trường hợp bạn có một nhóm lớn và các thành viên trong nhóm không có liên lạc thường xuyên.

Cuộc họp gỡ lỗi / phân loại lỗi

Trong cuộc họp này, các thành viên trong nhóm, leader và / hoặc manager sẽ xem xét các lỗi được nhóm kiểm tra báo cáo (có nghĩa là: bạn) và thảo luận các lỗi đó để:

Làm rõ một số lỗi không rõ ràng hoặc yêu cầu thêm thông tin từ người kiểm thử

Quyết định cái nào cần sửa trước, cái nào cần sửa sau

Mọi người không thích cuộc họp nói chung. Tuy nhiên, nếu dự án là lớn, phức tạp hoặc nhóm của bạn không đồng vị trí, một cuộc họp thường xuyên có thể tăng cường giao tiếp nhóm. Vì vậy, nhân cơ hội này để đặt câu hỏi hay để biết thêm về dự án, hệ thống đang được thử nghiệm, kế hoạch của dự án. Bạn càng biết càng nhiều thì bạn có thể kiểm thử hệ thống càng tốt.

7) Reporting your testing progress

Nếu nhóm của bạn không thường xuyên có cuộc họp hàng ngày hoặc bạn là thành viên của nhóm làm outsource , bạn có thể cần phải báo cáo tiến trình thử nghiệm của mình, kết quả kiểm thử . Bạn có thể báo cáo tiến độ thử nghiệm của mình qua email hoặc cuộc họp hoặc… cả hai. Điều này có thể được thực hiện trên cơ sở hàng ngày hoặc hàng tuần tùy thuộc vào nhóm của bạn và vai trò của bạn.

Đừng đặt thấp hơn giá trị của báo cáo thử nghiệm. Việc chia sẻ tiến trình thử nghiệm của bạn, kết quả kiểm tra hoặc sự cố mà bạn quan sát được sẽ giúp người quản lý có thông tin và dữ liệu để đưa ra quyết định tương ứng.

Tóm lại, trên đây là những gì bạn có. Tôi đã chia sẻ với bạn một số hoạt động thử nghiệm phổ biến mà bạn nên biết trước là người thử nghiệm.

Tôi đã nói trước đó và tôi muốn nhấn mạnh nó một lần nữa, đây là những hoạt động tôi đã trải qua không phải tất cả các hoạt động ngoài kia. Ngoài ra, những gì tôi chia sẻ ở đây dựa trên quan điểm của tôi, cảm nhận của tôi và các dự án của tôi. Tuy nhiên, việc biết điều này có thể giúp bạn tìm hiểu về những gì có thể đang chờ bạn phía trước. Việc biết điều này có thể giúp bạn trả lời câu hỏi nếu đây là những hoạt động bạn có thể làm ... đôi khi mỗi ngày. Trong thực tế, bạn sẽ hoặc sẽ không làm các hoạt động chính xác giống như tôi chia sẻ ở đây. Chỉ cần lấy nó làm tài liệu tham khảo. Đôi khi, bạn cần phải thử nghiệm và xem mọi thứ thông qua góc nhìn của bạn.

Refer source: http://www.asktester.com/7-common-software-testing-activities/