Tester Công ty CP Đầu tư và Phát triển Ứng dụng

Vị trí tuyển dụng

Tester

Chức vụ

Nhân viên

Số năm kinh nghiệm

1 năm

Ngành nghề

IT phần mềm

Yêu cầu bằng cấp

Cao đẳng

Hình thức làm việc

Toàn thời gian cố định

Yêu cầu giới tính

Nữ

Địa điểm làm việc

Hà Nội

Yêu cầu độ tuổi

Không yêu cầu

Mức lương

Thỏa thuận

Số lượng cần tuyển

3

Mô tả công việc

- Hiểu biết về quy trình phần mềm và các giai đoạn kiểm thử.
- Có khả năng thiết kế Test case, test script, test scenario.
- Có kinh nghiệm sử dụng các công cụ quản lý lỗi.
- Sử dụng tiếng Anh tốt (Đọc hiểu).
- Có khả năng đọc hiểu các tài liệu nghiệp vụ, tài liệu thiết kế; Có khả năng nắm bắt nhanh dự án & các yêu cầu của dự án.
- Nhiệt tình, có trách nhiệm với công việc, cẩn thận, chăm chỉ, chủ động trong công việc.
- Làm việc nhóm, giải quyết các vấn đề, trình bày, và tổ chức thảo luận nhóm.
- Tư duy logic tốt, nhận thức nhanh, làm việc có sáng tạo & góp ý cho sản phẩm
- Sẵn sàng làm việc ngoài giờ khi cần thiết

Quyền lợi được hưởng

• Được làm việc trong một môi trường cởi mở, năng động
• Mức lương hấp dẫn dựa trên năng lực và kinh nghiệm
• Có cơ hội phát triển nghề nghiệp, hưởng chế độ đãi ngộ tốt
• Chế độ: Lương hàng tháng / Bảo hiểm Lao động / Thưởng dự án và thưởng cuối năm, Các quyền lợi khác của Bộ luật Lao động hiện hành.
• Có cơ hội tham gia các dự án outsource với các đối tác lớn.

Yêu cầu khác

Không có

Hồ sơ bao gồm

- Các ứng viên quan tâm có thể nộp hồ sơ trực tiếp, gửi kèm file hay trực tiếp đến tại công ty
- CV hoặc Resume kèm ảnh mới chụp trong thời gian 6 tháng (Tiếng Việt hoặc tiếng Anh) gửi về địa chỉ Email: tuyendung@viajsc.com. Tiêu đề email ghi rõ: Họ và tên _ Vị trí ứng tuyển

Hạn nộp Hồ sơ

31/10/2014

Hình thức nộp hồ sơ

Trực tuyến

Người liên hệ

Mr Tuấn

Địa chỉ liên hệ

P1811, tòa HH2 Bắc Hà, Tố Hữu (Lê Văn Lương kéo dài), Hà Nội

Email liên hệ

tuyendung@viajsc.com

Điện thoại liên hệ

0466863026

Người tìm việc cảnh giác khi có bất kỳ yêu cầu thu phí từ phía nhà tuyển dụng

Tên công ty

Công ty CP Đầu tư và Phát triển Ứng dụng Thông Minh Việt

Địa chỉ

P1811, tòa HH2 Bắc Hà, Tố Hữu, Hà Nội

Website

www.viajsc.com

Điện thoại

0466863026

Giới thiệu

Công ty CP Đầu Tư & Phát Triển Ứng Dụng Thông Minh Việt (VIA) là doanh nghiệp hoạt động trong lĩnh vực CNTT. Với sứ mệnh tạo lên những phần mềm, giải pháp, ứng dụng thông minh hữu ích cho các doanh nghiệp, gia đình. Hướng tới 1 cuộc sống hiện đại với nhiều ứng dụng thông minh hữu ích.
VIA đang từng ngày xây dựng đội ngũ nhân viên công ty trẻ trung, đầy nhiệt huyết, với nền...

Xem thêm

Công ty CP Đầu Tư & Phát Triển Ứng Dụng Thông Minh Việt (VIA) là doanh nghiệp hoạt động trong lĩnh vực CNTT. Với sứ mệnh tạo lên những phần mềm, giải pháp, ứng dụng thông minh hữu ích cho các doanh nghiệp, gia đình. Hướng tới 1 cuộc sống hiện đại với nhiều ứng dụng thông minh hữu ích.
VIA đang từng ngày xây dựng đội ngũ nhân viên công ty trẻ trung, đầy nhiệt huyết, với nền tảng là vững mạnh về công nghệ, đa dạng về kiến trúc thông tin – giải pháp toàn diện, tiên phong về các nền tảng nội dung số.
Chúng tôi đã và đang áp dụng những kiến thức, kinh nghiệm của mình để xây dựng phát triển thành công các dự án cho khách hàng trong nước cũng như các đối tác nước ngoài: Mỹ, Úc, Canada, Anh… về các lĩnh vực như: Tài chính – ngân hàng, quản trị dịch vụ, dịch vụ giải trí, ứng dụng trong nông nghiệp, quản lý bán lẻ….
Nhằm đáp ứng nhu cầu sản xuất kinh doanh, chúng tôi cần tìm kiếm và tuyển dụng những nhân viên cũng như quản lý có năng lực vào các vị trí sau: Kỹ Sư Phát Triển Phần Mềm (.NET, SharePoint, PHP, Java, UI, iOS, Android), Chuyên viên Kiểm Thử (Tester), Chuyên viên Quản Lý Chất Lượng (QA), Chuyên viên Thiết Kế (Designer), Quản lý Dự Án (PM).

Thu gọn

Quy mô công ty

Từ 10 - 24 nhân viên

Học tester nên bắt đầu như thế nào?

Mình nghĩ rất nhiều bạn đã và đang học công nghệ thông tin. Muốn tìm hiểu về ngành kiểm thử phần mềm nhưng lại ko biết bắt đầu từ đâu, bắt đầu như thế nào. Và hẳn bây giờ đang rất rối trí xem mình nên fai như thế nào, trong khi tài liệu thì có nhiều quá trời mà mình lại ko biết làm gì với nó :D. Hôm nay mình chia sẻ chút kinh nghiệm của mình nhé. Chỉ có 1 chút kinh nghiệm nhỏ nhoi thôi :)
- Trước tiên bạn nên tìm hiểu về 1 số khái niệm về kiểm thử phần mềm như thế nào là kiểm thử hộp đen ( black-box testing), thế nào là kiểm thử hộp trắng (whit-box testing).
- Các kỹ thuật kiểm thử, các mức kiểm thử. Các loại test....
- Tự tìm hiểu 1 số mẫu test case cơ bản trên mạng, xem họ viết test case như thế nào
- Tự tìm hiểu và viết test case cho form Login hoặc form bất kỳ, form đơn giản thôi. Rồi dần dần tự viết được những cái khó hơn chút
- Lên diễn đàn tester để hỏi/ để học xem họ làm những cái này như thế nào. Đừng ngại hỏi, vì ai cũng từng là người ko biết gì rồi mới trở thành expert chứ.
- Lên các diễn đàn về kiểm thử phần mềm, nghe các bạn ấy hỏi, đó cũng là 1 cách giúp các bạn tư duy...
- Nếu các bạn muốn tìm hiểu sâu hơn chút thì tìm hiểu về ISTQB, tài liệu tiếng anh, đọc hơi khó chút cho các bạn có tiếng anh ko tốt nhưng google translate để làm gì cơ chứ ^^
Trên đây chỉ là 1 số chia sẻ của mình thôi :). Các bạn cứ bắt đầu thử như thế xem.

Trả lời câu hỏi cho mục Interview Question on Mobile Testing.

Trả lời câu hỏi cho mục Interview Question on Mobile Testing.

Câu 1 : What is the difference between Mobile Testing and Mobile Application Testing ?

Mobile Testing means the complete testing of mobile in System level + Application level

Generally there are 3 catgories:
1. Mobile Protocol stack testing. (using network simulators)
few examples are below:
* Stack supports 4 bands EGSM,PGSM,GSM-850,DCS.Mobile originating and mobile terminating call in all those bands.
*cell selection reselection
*cell bar
*All types of handover
*frequency hopping
*Coding schemes etc
2. Multimedia testing
* Midi polyphonic tones ringer and player
* MP3 as ringer and player &other supported formats
* Camera
* Video Conferencing etc
3. Feature testing
*Phonebook
*SMS
*Supplementary calls
*Security
*Calculator
*Gaming
*Fast dialing etc

 Mobile Application testing deals with only the features and multimedia part. But Mobile testing deals with all three categories above.

Interview Question on Mobile Application Testing

Interview Questions on Mobile Application Testing!!!…well I know very well, many of you must have been in search of this thing since so long.Starting from a beginner in this domain to an expert, everyone  is very keen to know what are the different question they may come across  in there interview.Here in my post I have shared some interview questions which me or my friends have come across in there interviews for the post of Mobile Software Testers. I hope this will help you:-

1. What is the difference between Mobile Testing and Mobile Application Testing ?
2. What is your approach while Testing Mobile Applications?
3. Have you ever written a Test Plan?What are the things specific to Mobile Application would you emphasis on while writing test plan for Mobile Applications?
4. Do you know Facebook?Tell me what are the High level test cases for Facebook Web Application and for Facebook Mobile Application?
5. Can you please let me know,the devices you have worked upon?
6. Testing of Mobile Application on Emulators.Can you let me know your view?
7. Have you ever worked on any automation tool for Testing Mobile Application?
8. Please tell me about your project.What kind of Mobile Applications have you worked upon?
9. Do you have Idea about Mobile Operating Systems?
10. Blackberry Devices have which Operating system?
11. What is current iOS (iphone OS) version?
12. You have two cases. 1st you can not disconnect your call and 2nd you can not send SMS from your devices.Tell me Severity and Priority in both the cases?
13. What are different Mobile Platforms/OS?
14. What are the different way you can install a Mobile Application?
15. Have you ever worked on Device Anywhere?Do you have experience of working on it?
16. Do you have Idea about application certification program like True Brew Testing(TBT),Symbian Signed Test Criteria,Java Verified Program?
17. See this application(Interviewer is given a Handset with a Mobile Application installed).Tell me what are the bugs in this Mobile application/Game.?
18. Have you ever worked on LBS Application ?
19. How will you test a Location Based Mobile Application?
20. How will you perform Performance Testing for a Mobile Application?

Well there are lot more Mobile Application Testing  Interview Questions to be added.I will incorporate rest of the questions in My Next Post.Till then Have a Nice Time  :)

Thông báo khai giảng khóa đào tạo Tester tại Hà Nội

Thông báo khai giảng khóa đào tạo Tester tại Hà Nội

Nhằm đáp ứng nhu cầu học Tester mình mở lớp với mong muốn truyền đạt những kiến thức, kinh nghiệm của bản thân cho các bạn sinh viên đã, đang và sẽ trở thành những kiểm thử viên trong tương lai. 

Đối tượng học : Tất cả các bạn là sinh viên công nghệ thông tin/ không phải sinh viên công nghệ thông tin có niềm đam mê với kiểm thử phần meemf

Nội dung khóa học :

Buổi 1 : Giới thiệu về Software testing, các kỹ thuật kiểm thử, quy trình kiểm thử...

Buổi 2 : Giới thiệu về cách viết test case. 

              Viết Test case mẫu cho form Login

              Thực hành viết TC cho form đăng ký

Buổi 3 : Viết test case cho trang quản lý tin tức

Buổi 4 : Thực hành viết test case cho web quản lý

Buổi 5 : Thực hành viết test case cho web bán hàng

Buổi 6 : Thực hành viết test case cho phần mềm quản lý

Buổi 7 : Thực hành test web quản lý & Log bug

Buổi 8 : Thực hành test website bán hàng & Log bug

Buổi 9 : Thực hành test và Log bug cho phần mềm quản lý

Buổi 10 : Thực hành test và log bug cho phần mềm ứng dụng

Trong quá trình học mình sẽ lồng ghép những câu hỏi mà các nhà tuyển dụng hay hỏi để các bạn đỡ bỡ ngỡ khi đi phỏng vấn. Đăng ký ngay hôm nay thôi !!!!!!!!!

Hình thức học : học online qua skype, 1 lớp khoảng 4-5 học viên

Học phí : 1.500.000đ

Liên hệ : Ms Huyền. 
SDDT liên hệ : 01689.954.259

Skype/ Yahoo : phaletrang_thapsangnjemtjn

Email : tthuyen1204@gmail.com

Quy trình kiểm thử phần mềm

Mặc dù có nhiều biến thể tồn tại trong các tổ chức, nhưng đều có một qui trình chung cho việc kiểm thử phần mềm. Như qui trình mẫu dưới đây là qui trình phổ biến giữa các tổ chức sử dụng mô hình thác nước (Waterfall).

* Phân tích yêu cầu: Việc kiểm thử thường sẽ bắt đầu từ pha lấy yêu cầu trong quy trình phát triển phần mềm (software development life cycle – vòng đời phát triển phần mềm). Trong pha thiết kế, các tester làm việc với các DEV để xác định phần nào của thiết kế có thể test và các thông số mà test sẽ làm việc (ví dụ test ở môi trường nào, dữ liệu ra sao…).
* Lập kế hoạch test: Mô tả nhiều việc như chiến lược test (test strategy), test plan, tạo test case... Khi có nhiều hoạt động sẽ thực hiện trong lúc test thì cần phải có kế hoạch.
* Phát triển test: Viết các test procedure, test scenario, test case, test dataset và test script để sử dụng cho việc kiểm thử phần mềm (testing software).
* Thực thi test: Các tester thực thi phần mềm dựa trên kế hoạch và các tài tiệu test (thường là spec và test case, có thể có những dự án sẽ kèm theo nhiều tài liệu qui định khác) sau đó báo cáo lỗi tìm thấy cho nhóm DEV .
* Báo cáo test: Khi việc kiểm thử kết thúc, các tester sẽ điền kết quả test vào test case và tạo báo cáo kết quả test của họ và cho biết phần mềm đã test có sẵn sàng cho phát hành (release) hay chưa (việc này là ứng với system test, còn đối với những cấp nhỏ hơn thì việc “phát hành” được hiểu như là màn hình hoặc modul đã test là sạch bug).
* Phân tích kết quả test: Hoặc còn gọi là phân tích lỗi được thực hiện bởi nhóm phát triển dự án của khách hàng, để quyết định lỗi nào sẽ được sửa và lỗi nào sẽ không sửa (nghĩa là xây dựng phần mềm hoạt động bình thường) hoặc sẽ hoãn lại (sẽ sửa sau này ở version khác chẳng hạn).
* Test lại lỗi: Sau khi một lỗi (defect) đã được nhóm phát triển phần mềm (DEV) xử lý xong, thì nó cần phải được test lại bởi nhóm test.
* Test hồi qui: Kiểm thử hồi qui thường để tạo một chương trình kiểm thử nhỏ được xây dựng từ một tập hợp các test (trường hợp kiểm thử), cho sau mỗi lần tích hợp phần mới, cập nhật sửa đổi, hoặc fix lỗi, để đảm bảo rằng việc release (phát hành phần mềm) mới nhất sẽ không bị bất cứ lỗi gì, và tổng thể sản phẩm phần mềm vẫn còn hoạt động chính xác.
* Kết thúc test: Khi test đã đáp ứng được điều kiện dừng, thì các hoạt động như chụp một số kết quả chính (chụp evidence kết quả test theo từng test case hoặc gộp lại theo từng nhóm hoặc theo màn hình), rút ra các bài học kinh nghiệm, kết quả, log, tài liệu liên quan đến dự án được lưu trữ và sử dụng để tham khảo cho các dự án tiếp theo.

How Much Testing is Enough? - Kiểm thử bao nhiêu là đủ?

This can be difficult to determine. Most modern software applications are so complex, 
and run in such an interdependent environment, that complete testing can never be done. 
Common factors in deciding when to stop are:

Deadlines (release deadlines, testing deadlines, etc.)Test cases completed with certain 
percentage passedTest budget depletedCoverage of code/functionality/requirements 
reaches a specified pointBug rate falls below a certain levelBeta or alpha testing period 
ends
Đối với 1 phần mềm, chúng ta không thể nói được rằng nó không còn lỗi nữa, perfect rồi, 
- Thứ 1 đó là dựa vào hạn release sản phẩm
- Số lượng test case hoàn thành so với phần trăm test case pass
- Ngân sách dành cho kiểm thử đã hết
- Độ bao phủ code/chức năng/yêu cầu đều đã đạt được điểm yêu cầu.
- Tỷ lệ bug thấp hơn mức cho phép 
- Các phiên bản thử nghiệm beta hoặc alpha đã kết thúc

bàn giao cho khách hàng thôi. Có thể những lỗi các bạn phát hiện ra, 
fix và ko còn hiển hiện nữa nhưng còn những
 lỗi tiềm tàng thì sao? Các bạn có chắc chắn rằng mình có thể cover hết được các tình huống 
có thể xảy  ra đối với phần mềm của mình hay không? Câu trả lời là không. 
Vậy thì kiểm thử như thế nào là đủ? 
Cái này cũng rất khó có thể xác định. Như có ai hỏi các bạn có bao nhiêu tiền thì cảm thấy đủ, 
chẳng ai trả lời đc. Càng có nhiều lại muốn có nhiều hơn nữa kia. 
Ta quay lại vấn đề, kiểm thử bao nhiêu là
 đủ. 

Các nguyên tác trong kiểm thử phần mềm

Các nguyên tắc
Một số nguyên tắc kiểm thử đã được đề nghị từ 40 năm về trước và đã đưa ra một số phương châm chung phổ biến cho kiểm thử phần mềm, bao gồm các nguyên tắc sau:

Nguyên tắc 1 – Kiểm thử đưa ra lỗi
Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi, nhưng không thể chứng minh rằng phần mềm không có lỗi. Kiểm thử làm giảm xác suất lỗi chưa tìm thấy vẫn còn trong phần mềm, thậm chí là không còn lỗi nào, nó không phải là bằng chứng của sự chính xác.

Nguyên tắc 2 – Exhaustive testing is impossible
Kiểm thử mọi thứ (tất cả các tổ hợp của điều kiện input đầu vào) là không thể thực hiện được, trừ phi nó chỉ bao gồm một số trường hợp bình thường (ít trường hợp tổ hợp thì có thể test toàn bộ được). Thay vì kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên sự mức độ ưu tiên chúng ta có thể tập trung việc kiểm thử vào một số điểm cần thiết.

Nguyên tắc 3 – Kiểm thử sớm
Để tìm được bug sớm, các hoạt động kiểm thử nên được bắt đầu càng sớm càng tốt trong qui trình phát triển (vòng đời phát triển) phần mềm hoặc hệ thống, và nên tập trung vào các hoạt động đã định trước.

Nguyên tắc 4 – Sự tập trung của lỗi
Nỗ lực kiểm thử nên tập trung một cách cân đối vào mật độ lỗi dự kiến và lỗi phát hiện ra sau đó trong các mô-đun. Một số ít các mô-đun thường chứa nhiều lỗi không phát hiện ra trong lúc kiểm thử trước khi phát hành (release), hoặc chịu trách nhiệm cho hầu hết các lỗi hoạt động của phần mềm.

Để hiểu rõ hơn nguyên tắc này, ta cần xem xét 3 điều sau:
1. Nguyên tắc tổ gián: chỗ nào có 1 vài con gián thì ở đâu đó xung quanh nó sẽ có cả tổ gián -> có rất nhiều gián >>> chỗ nào có 1 vài con bug thì xung quanh, gần gần chỗ đó sẽ có nhiều bug.
2. Nguyên tắc 80/20: thông thường 20% chức năng quan trọng trong một chương trình có thể gây ra đến 80% tổng số bug phát hiện được trong chương trình đó.
3. Exhaustive testing is impossible (nguyên tắc thứ 2): do đó cần phải ananlysis (phân tích) + priorities (tính toán mức độ ưu tiên) để quyết định tập trung vào test chỗ nào.

=> Test kỹ chức năng quan trọng => found bug => test những gì liên quan + những chức năng gần nó để tìm ra bug nhiều hơn.

Nguyên tắc 5 – Nghịch lý thuốc trừ sâu
Nếu việc kiểm thử tương tự nhau được lặp đi lặp lại nhiều lần, thì cuối cùng sẽ có một số trường hợp kiểm thử (ca kiểm thử - test case) sẽ không còn tìm thấy bất kỳ lỗi nào mới. Để khắc phục "nghịch lý thuốc trừ sâu" này, các trường hợp kiểm thử cần phải được xem xét và sửa đổi thường xuyên, và cần phải viết các test case mới và khác nhau để thực hiện nhiều phần khác nhau của phần mềm hoặc hệ thống để tìm ra lỗi tiềm ẩn nhiều hơn nữa.

Nguyên tắc này giống như việc trừ sâu trong nông nghiệp, nếu chúng ta cứ phun một loại thuốc với nồng độ giống nhau trong một khoảng thời gian dài thì có một số con sâu sẽ quen dần và cuối cùng việc phun thuốc giống như là tắm chúng vậy (bị lờn thuốc) => lúc đó chúng ta không thể diệt sạch chúng được. Do vậy, để diệt sạch sâu một cách hiệu quả, người ta thường thay đổi loại thuốc trừ sâu, mỗi loại chỉ dùng trong khoảng thời gian ngắn.

Nguyên tắc 6 – Kiểm thử theo các ngữ cảnh độc lập
Nguyên tắc này là việc testing phụ thuộc vào ngữ cảnh, test trong nhiều ngữ cảnh khác nhau.
Để hiểu rõ hơn chúng ta xem ví dụ sau:

Ví dụ, cũng với một chương trình calculator có rất nhiều chức năng, nhưng:
- Nếu test chương trình này cho mẫu giáo thì chỉ cần test cộng trừ là OK
- Nếu test chương trình này cho cấp 2 thì cộng trừ nhân chia
- Nếu test chương trình này cho đại học thì tích phân, đạo hàm, v.v....

Nguyên tắc 7 – Sự sai lầm về việc không có lỗi
Việc tìm và sửa chữa lỗi sẽ không giúp được gì nếu hệ thống được xây dựng xong nhưng không thể dùng được và không đáp ứng được nhu cầu và sự mong đợi của người dùng. (Nghĩa là nếu sau khi code, test rồi fix bug, làm đủ tất cả các trường hợp và cuối cùng cho ra một sản phẩm không như mong đợi hoặc không đáp ứng được nhu cầu của khách hàng thì dự án phần mềm đó coi như thất bại mặc dù đã được test xong)

Thực tập Tester Công ty CP Giải pháp Tối Ưu Số - Hà Nội

Thực tập Tester Công ty CP Giải pháp Tối Ưu Số - Hà Nội

Vị trí tuyển dụng

Thực tập Tester

Chức vụ

Nhân viên

Số năm kinh nghiệm

Dưới 1 năm

Ngành nghề

IT phần mềm

Yêu cầu bằng cấp

Cao đẳng

Hình thức làm việc

Thực tập

Yêu cầu giới tính

Nữ

Địa điểm làm việc

Hà Nội

Yêu cầu độ tuổi

18 - 24 tuổi

Mức lương

Thỏa thuận

Số lượng cần tuyển :2

Mô tả công việc

- Test các dự án phần mềm, phối hợp với các bộ phận liên quan để đảm bảo chất lượng dự án/sản phẩm;
- Quản lý, phân tích, theo dõi và báo cáo kết quả test;
- Các công việc khác theo sự phân công của Quản lý trực tiếp.

Quyền lợi được hưởng

Được đào tạo thực tế và phát triển chuyên môn, nâng cao kinh nghiệm.
Được làm việc trong môi trường làm việc trẻ trung, thân thiện
Được tham gia vào các hoạt động “Tinh thần” của công ty

Kết thúc thực tập được xem xét trở thành nhân viên chính thức của công ty

Được hỗ trợ tiền ăn trưa, thưởng dự án khi được tham gia vào dự án của công ty.

Yêu cầu khác

Không có

Hồ sơ bao gồm

Đơn xin việc và CV bằng tiếng Việt hoặc tiếng Anh nêu rõ sở thích cá nhân, điểm mạnh, điểm yếu …
- Bản sao các văn bằng chứng chỉ
- 02 ảnh 3*4 mới nhất

Hạn nộp Hồ sơ

30/09/2014

Hình thức nộp hồ sơ

Qua Email

Người liên hệ

Nguyễn Thị Tường

Địa chỉ liên hệ

Tầng 4 TTTM Vân Hồ, 51 Lê Đại Hành, Hai Bà Trưng, Hà Nội

Email liên hệ

tuongnt@dos.com.vn

Điện thoại liên hệ

0462972709

Độ ưu tiên, Độ nghiêm trọng trong quản lý bug

Trong kiểm thử phần mềm thì hai khái niệm Độ ưu tiên (Priority) và Độ nghiêm trọng (Severity) cũng không quá xa lạ, đặc biệt là trong quản lý bug. Hai khái niệm trên đã trở nên quá quen thuộc và phổ biến đến nỗi chúng ta hầu như không phân biệt được ý nghĩa cũng như sự khác nhau giữa hai khái niệm đó. Mặc dù hai yếu tố này không phải là yếu tố sống còn trong quản lý bug nhưng việc hiểu đúng sẽ giúp chúng ta tiết kiệm thời gian cũng như làm công việc hiệu quả hơn.

Độ nghiêm trọng

Mức độ nghiêm trọng của một con bug thường chỉ mức độ tác động của con bug đó đến sản phẩm/ người dùng. Mỗi dự án hay sản phẩm có tiêu chí đánh giá độ nghiêm trọng khác nhau nhưng thông thường sẽ có 4-5 mức độ khác nhau từ nghiêm trọng nhất đến ít nghiêm trọng hơn:

• Mức độ 1: Hệ thống sập, dữ liệu bị mất, ứng dụng không cài đặt được v.v.
• Mức độ 2: Chức năng chính của sản phẩm không hoạt động
• Mức độ 3: Chức năng phụ của sản phẩm không hoạt động
• Mức độ 4: Bug nhỏ, không quan trọng
• (Mức độ 5): Yêu cầu cải tiến sản phẩm, thêm chức năng

Cũng nên lưu ý việc định nghĩa mức độ nghiêm trọng phụ thuộc vào sản phẩm khác nhau, mang tính tham khảo và tương đối.

Việc xác định được độ nghiêm trọng của con bug giúp nhà quản lí dự án, chủ sản phẩm có cái nhìn tốt hơn và thuận lợi hơn về tình hình chất lượng của sản phẩm. Số lượng bug là chưa đủ để đánh giá tình hình. Việc đội kiểm thử tìm được 50 con bug trong 1 tháng cũng không nói lên nhiều về tình hình chất lượng của sản phẩm. Tuy nhiên, nếu biết được trong 50 con bug đó có đến hơn 1 nửa là bug với độ nghiêm trọng ở cấp độ 1 và 2 sẽ hữu ích hơn nhiều. Ngoài ra, với góc độ của kỹ sư kiểm thử, độ nghiêm trọng cũng giúp “quảng cáo” cho con bug của mình từ đó sẽ gây được sự chú ý của mọi người và tăng cơ hội con bug đó được sửa.

Có một thực tế không lấy gì vui vẻ là việc xác định độ nghiêm trọng của con bug không hẳn lúc nào cũng mang tính chất trắng-đen và tuyệt đối. Sẽ không có gì ngạc nhiên nếu chúng ta cho rằng vấn đề này là nghiêm trọng trong khi chủ sản phẩm, nhà quản lý dự án lại không nghĩ như vậy. Không hẳn là họ đang cố tình “dìm hàng” chúng ta mà cũng có thể cách chúng ta cung cấp thông tin không thể hiện được đầy đủ mức độ nghiêm trọng của vấn đề. Hãy phân tích và cung cấp thêm thông tin để cho thấy tác động nghiêm trọng của con bug đối với sản phẩm cũng như người dùng cuối như thế nào như xảy ra trên nhiều môi trường; lặp đi lặp lại; có khả năng ảnh hưởng đến các thành phần, chức năng khác; hình ảnh thương mại của công ty v.v. Và dĩ nhiên, nếu vấn đề không thực sự nghiêm trọng, chúng ta cũng không có lí do gì để làm cho lớn chuyện. Việc hiểu rõ sản phẩm, người dùng cùng khả năng phân tích, suy luận sẽ giúp chúng ta làm tốt khâu này.

 Độ ưu tiên

Như chúng ta đã biết nếu đã là bug thì sẽ phải sửa. Tuy nhiên, có một thực tế là đội phát triển khó có thể sửa hết tất cả bug một lượt cũng như không đáng để sửa hết tất cả các bug. Do đó, đội phát triển sẽ phải cần đến độ ưu tiên của con bug để biết được bug nào cần được sửa trước bug nào sau. Độ ưu tiên của con bug cũng thường được chia thành 3-4 cấp độ:

• Mức độ 1: Cao – Bug sẽ phải sửa ngay lập tức
• Mức độ 2: Trung bình – Bug sẽ sửa trong bản cập nhật lần tới
• Mức độ 3: Thấp – Bug không cần sửa trong bản cập nhật lần tới, có thể sửa nếu có thời gian

Tương tự mức độ nghiêm trọng, mức độ ưu tiên cũng như ý nghĩa của chúng có thể sẽ khác nhau ở những sản phẩm, dự án khác nhau.

Thế chúng ta sẽ dựa vào đâu để xác định độ ưu tiên? Bug nào sửa trước bug nào sửa sau (hoặc không sửa)? Quá dễ, dựa vào độ nghiêm trọng của bug. Bug nào nghiêm trọng nhất, tác động đến người dùng nhiều nhất thì sẽ được ưu tiên sửa trước. Bug nào ít nghiêm trọng hơn sẽ được sửa sau. Đúng…nhưng không phải lúc nào cũng đúng. Giả sử chúng ta tìm được một bug làm sập hệ thống. Quá tuyệt đúng không nào. Chúng ta đánh giá mức độ nghiêm trọng ở Mức độ 1 (rất là nghiêm trọng) và độ ưu tiên 1 (cần được sửa gấp). Nhưng hôm sau, độ ưu tiên của bug đó được điều chỉnh xuống thấp trong khi con bug bắt lỗi chính tả của thằng bạn lại được đánh giá có độ ưu tiên cao để sửa. Chúng ta buồn rầu, thất vọng, khó chịu và quyết phải hỏi cho ra lẽ và được giải thích rằng “Mặc dù bug đó làm sập hệ thống nhưng khả năng người dùng bị lỗi đó là rất thấp do để làm ra bug đó bạn phải trải qua vài chục bước hay bug đó chỉ xảy ra trên một môi trường cụ thể cũng như rất ít người dùng chạy sản phẩm trên môi trường đó”. Suy cho cùng đó là một quyết định liên quan đến kinh doanh và hầu như chúng ta không thể thay đổi được quyết định đó. Có một thực tế phải thừa nhận là kỹ sư kiểm thử chúng ta biết rất ít hay thậm chí không thể biết được khối lượng công việc của đội phát triển, chi phí của dự án cũng như những quyết định kinh doanh mang tính chiến lược của nhà đầu tư, quản lý dự án hay chủ sản phẩm. Điều đó cũng không có gì là quá tệ đối với một kỹ sư kiểm thử. Nó chỉ liên quan đến vai trò và trách nhiệm công việc của kỹ sư kiểm thử. Xác định độ ưu tiên được khuyến khích đối với kỹ sư kiểm thử nhưng không phải bắt buộc. Đó là lí do tại sao ở một số dự án thậm chí kỹ sư kiểm thử được yêu cầu không xác định độ ưu tiên cho con bug và độ ưu tiên chỉ được xác định sau buổi họp đánh giá bug. Điều này cũng không có gì là vô lí.

Lời kết

Trách nhiệm và vai trò của kỹ sư kiểm thử là cung cấp thông tin về chất lượng sản phẩm càng nhiều càng chi tiết càng tốt cho các nhà quản lí dự án, cho chủ sản phẩm những người sau đó sẽ đưa ra những quyết định kinh doanh cho sản phẩm dựa vào những thông tin đó. Độ ưu tiên và độ nghiêm trọng chỉ là hai trong số rất nhiều thông tin quan trọng khác chúng ta cần phải cung cấp như môi trường của con bug, mức độ lặp đi lặp lại, các bước mô tả con bug, phạm vi của con bug v.v. Tuy nhiên, việc hiểu đúng về mức độ nghiêm trọng, độ ưu tiên của sản phẩm cho thấy chúng ta thực sự hiểu rõ và quan tâm đến chất lượng sản phẩm cũng như thể hiện sự chuyên nghiệp của một kỹ sư kiểm thử

Kinh nghiệm đoán lỗi

Mình cũng mới làm tester chỉ được một năm thôi, nên nói về kinh nghiệm thì không nhiều lắm. Chủ yếu mình vẫn đang học hỏi kinh nghiệm từ nhiều bạn khác trên đây, và mình tìm hiểu theo câu hỏi của các bạn hỏi, vì khi mình trả lời thì có bạn sẽ chỉnh chỗ sai cho mình, như vậy ngày qua ngày mình sẽ khá hơn.

Nói về đoán lỗi thì mình chia sẻ những gì mình biết nha, kỹ thuật này đòi hỏi kinh nghiệm là chủ yếu, vì sau quá trình mình làm việc nhiều, mình đã gặp nhiều trường hợp, gặp nhiều qui trình xử lý công việc rồi nên khi gặp một dự án mới, một phần mềm mới, mình sẽ biết được dạng phần mềm này hay loại màn hình này (ví dụ màn hình search, màn hình login, màn hình thêm mới, edit, delete,...) thì thường gặp những lỗi gì. Hoặc sau khi thực hiện một vài thao tác thì kết quả phải xảy ra như thế nào,...

Ví dụ:

Đối với màn hình search:
+ Thường xảy ra lỗi search cả những record đã bị xóa (del_flg = 1) vì vậy khi viết test case và test màn hình search thì nên thêm vào test case này (gán del_flg = 1 cho một số record rồi thực hiện search, nếu những record này được hiển thị trên màn hình thì sai).
+ Tiếp theo, nhập điều kiện sao cho khi search được 0 record thì không hiển thị được màn hình mà lại báo lỗi "Null pointer" do trong code không xử lý khởi tạo list chứa danh sách các record search được.
+ Phần phân trang, thường thì mong muốn là: (giả sử phân trang là 20 records - một trang chỉ chứa được 20 dòng)
. ++ Search được 0 record thì chỉ hiển thị header (phần datagrid chỉ hiển thị header)
. ++ Search được 20 records thì hiển thị header và 20 dòng này trên 1 trang
. ++ Search được 21 records thì hiển thị header và 20 dòng này trên trang 1 và 1 dòng trên trang 2.
. ++ Search được 50 records thì hiển thị header và 20 dòng này trên 1 trang và 20 dòng trên trang 2 và 10 dòng trên trang 3
Nhiều khi DEV quên xử lý phân trang thì khi search được nhiều hơn số record chứa trong 1 trang thì bị lỗi hoặc hiển thị tất cả trên 1 trang.
Trong trường hợp đang hiển thị nhiều trang thì click Next và Prev để kiểm tra xem có qua lại giữa các trang được không nhé vì cũng hay bị lỗi chỗ này nếu là control này do mình tự viết (thường thì dùng component của framework nhưng trong ADF thì thường tự viết bằng java để dễ kiểm soát)

Đối với màn hình Login:
+ Chú ý phần bảo mật: Đôi khi DEV code thì gán user name là "admin" và pass là rỗng hoặc là "123" vì vậy mình nên thử trường hợp này.
+ Thử thử các trường hợp SQL injection
+ Để user name và pass rỗng rồi enter. (nhiều khi DEV không xử lý action enter cho login mà phải click button login)
+ Bạn cũng có thể sử dụng việc copy paste nếu như Dev đã chặn việc nhập

Đối với màn hình Thêm Xóa Sửa:
+ Ở loại màn hình này thường xảy ra lỗi là khi thêm mới vào lần thứ 2 trở đi thì bị báo lỗi exception (lý do: do cách xử lý ID khi thêm mới, thêm lần thứ 2 thì bị trùng ID với lần trước nên DB server không cho insert thêm => lỗi, theo nguyên tắc thì sau khi thêm mới thì load lại data nhưng nhiều DEV không làm đúng như vậy)
+ Những record đã bị xóa thì không được hiển thị lên danh sách xóa - sửa (tương tự màn hình search - vì khi load danh sách là search all)
+ Nếu chương trình có yêu cầu xử deadlock thì thường xảy ra lỗi khi 2 người ngồi trên 2 máy khác nhau cùng sửa trên 1 record cùng lúc.
Cách test: mở 2 màn hình thêm xóa sửa giống nhau bằng 2 browser khác nhau. sau đó sửa trên browser 1 rồi lưu lại (thành công); Tiếp theo sửa trên browser 2 rồi lưu lại, xử lý đúng là hiển thị thông báo lỗi "record này đã được sửa bởi người khác" nghĩa là không cho mình sửa nữa, muốn sửa thì refresh lại màn hình hoặc làm sao đó để load lại data rồi sửa. Xử lý sai là không hiển thị thông báo lỗi mà cho sửa luôn.
Hoặc bạn cũng có thể làm như sau : Với màn hình xóa. Bật 2 browser lên, với 2 user cùng tao tác trên 1 màn hình. User 1 thực hiện xóa record và Save. User 2 thục hiện edit record và Save sau. Có hiển thị thông báo lỗi hay không?
(Tình huống của việc này như sau: 9h sáng, Trưởng phòng và Giám đốc cùng mở màn hình xét thưởng, tại một thời điểm nào đó 2 người cùng click vào sửa field thưởng tháng 13 của nhân viên A. Giám đốc cho giá trị 300đồng, rồi lưu lại và nghĩ là nhân viên A sẽ được thưởng 300đồng. Trong khi đó Trưởng phòng cũng mở nội dung thông tin của nhân viên A, và cho field thưởng tháng 13 là 350đồng, và click button Save sau Giám đốc một xíu xiu (ví dụ < 1s) thì giá trị "thưởng tháng 13" của nhân viên A là 350đồng. Như vậy thì chương trình đã vô tình làm cho con người thao tác sai, Nếu chương trình tốt thì phải hiển thị thông báo lỗi khi Trưởng phòng click save. Vì data lúc đó đã khác so với data trước khi load lên để sửa.
Sưu tầm & Edit - From testngvn

Các lỗi thường gặp khi test website

I.Một số lưu ý về Bug 

I.1. Khi log Bug,bước xác định rất quan trọng

·         What -Bug này là bug gì,độ nghiêm trọng của nó như thế nào?

·         Where -Xác định lỗi ở đâu,trên môi trường nào (web thì browser nào,app thì trên hệ điều hành nào)

·         When -Bug xảy ra khi nào (nghĩa là thực hiện những bước nào thì xảy ra Bug)

·         How -Hướng sửa Bug đó như thế nào? (expected result)

·         Who – Bug do code của ai gây ra

I.2.Tìm ra Bug của phần mềm là chưa đủ, cần phải xem Bug đó đã được fix hay chưa và đặc biệt : việc fix Bug đó không gây ra Bug mới.

I.3.Không phải tất cả các Bug tìm ra đều được fix : Cần phải đánh giá độ quan trọng của Bug xem Bug nào cần phải fix,nên fix và bug nào không cần fix.

II.Các lỗi thường gặp trong quá trình Test Web

II.1.Lỗi về chức năng (Function Bug)

BUG	Priority
Link từ trang này đến trang khác không hoạt động	High
Link từ trang này đến trang khác bị sai	High
Lỗi khi nhập các thẻ HTML,kí tự đặc biệt,kí tự mở rộng…và các ô Textbox	Medium
Không check các trường nhập liệu liên quan quan đến ngày tháng	Medium
Không hiển thị hoặc hiển thị sai các thông báo lỗi khi xảy ra lỗi nhập liệu trên màn hình	Medium
Dữ liệu cũ được thực hiện nhiều lần :browser back,F5..	Medium
Có thông báo thực hiện xong chức năng nhưng dữ liệu không được ghi vào DB	High
Đưa vào một lượng lớn dữ liệu làm chương trình không chạy được	High

II.2.Lỗi về bảo mật(Security Bug)

BUG	Priority
Từ một trang hiện tại,thay đổi một số thuộc tính trên link thì có thể đến một trang khác mà người dùng không có quyền truy cập	High
User đã out khỏi hệ thống,browser back nhưng vẫn có thể thực hiện các chức năng	High

II.3.Lỗi giao diện(Interface Bug)  

BUG	Priority
Cách trình bày website không đồng nhất : font chữ,màu sắc,..	Medium
Kích thước các ô textbox bị hạn chế(fix cứng) các giá trị trong các ô đó không được hiển thị đầy đủ	Medium
Layout bị hỏng khi mở lên các môi trường (browser) khác nhau	High
Các câu thông báo sai chính tả	Medium
Button không chuyển sang màu xám khi bị disable	Medium
Tên các button,link….mang tính kĩ thuật,không dễ hiểu với người dùng	Medium

II.4.Lỗi khác (Others Bug)

·         Khi có nhiều user cùng truy cập thì hệ thống không đáp ứng được yêu cầu (performance).

·          Thiếu kí tự * bên cạnh các trường bắt buộc.

III.Kết luận

Web Application hay bất cứ ứng dụng nào khác đều có những đặc thù riêng đòi hỏi Tester phải hiểu rõ yêu cầu của hệ thống và tìm ra các Bug để ứng dụng đáp ứng được nhu cầu của người dùng(khách hàng).