Việc biết nhiều về UI/UX sẽ có lợi như thế nào cho công việc kiểm thử ??

Hôm nay , topic " chia sẻ kinh nghiệm, thủ thuật về kiểm thử phần mềm " của blog Học kiểm thử phần mềm tự động sẽ cùng tìm hiểu về những vấn đề liên quan đến UX, UI.

Các bạn thân mến, nếu như với một  Designer -Vấn đề UI là vấn đề cốt lỗi. Việc design một giao diện Website đẹp, bắt mắt ,thân thiện, dễ sử dụng là vô cùng quan trọng thì đối với 1 tester - nhìn, nhận xét , đánh giá ," soi mói"  và tìm lỗi thì vấn đề UI cũng là một vấn đề cốt lỗi của các member chuyên vạch lá tìm sâu đó nhé. 

Tương tự vậy, đối với các Developer , việc tạo ra sản phẩm với UX , UI hài hòa, chuyên nghiệp , thu hút người dùng là công việc thường nhật  thì đối với 1 Tester, công việc thường nhật cũng chỉ là việc tìm bug trong quá trình sử dụng và nói lên cái bất hợp lý nếu có trong quá trình thiết kế.

Vậy làm thế nào để có những testcase " thần thánh" , độc lạ nhưng hợp tình hợp lý, không gây " chia rẻ " nội bộ và " thù hằn" dân tộc thì việc Tìm hiểu UX, UI là việc cần thiết và cấp bách nhất !

1) Kiểm thử viên phần mềm (Tester) chỉ việc test theo yêu cầu có sẵng có  cần quan tâm đến UX/UI hay không?

Bạn là người kiểm thử phần mềm - là đại diện cho người sử dụng , mục đích cuối cùng cũng là hướng tới điều tốt nhất, hài lòng nhất cho người sử dụng , Bạn cảm thấy khó khăn khi sử dụng thì chắc chắn, người dùng - hoàn toàn xa lạ với ứng dụng của bạn cũng có cảm giác như thế.

Ví dụ nhé : Từ facebook cho đến google, menu icon trong ứng dụng mobile thường để biểu tượng 

, thường nằm ở header , góc bên trái hoặc bên phải . Đột nhiên ứng dụng của bạn , Menu là 1 icon của Exit hoặc 1 biểu tượng khác, nằm ở body của ứng dụng mỗi khi click vô trang nào đó, làm người dùng bối rối và dễ gây hiểu lầm, đương nhiên sẽ không tốt. Designer ... có cái lý riêng của họ , muốn độc đáo , khác lạ chẳng hạn hoặc khách hàng muốn thế và họ chỉ việc làm theo trong khi khách hàng. 

Còn developer  là người code từng dòng của product đó, dĩ nhiên sử dụng được tốt. Nhưng nếu cho 1 user ở bên ngoài vào thử, mọi chuyện sẽ hoàn toàn khác. Vậy đó, tester là người đánh giá sản phẩm, có thể nói lên cảm nhận của mình ở khía cạnh người dùng về sản phẩm, có thể góp ý điều hướng như thế nào cho hợp lý nhất. 

Bản thân mình cũng từng gặp một số ứng dụng, Client gửi Design bị sai so với đặc tả trong tài liệu , mà Coder thì làm theo design nên dẫn đến việc sản phẩm cuối cùng sắp lên thớt , sau khi đưa QC test và feedback với Client vẫn phải thay đổi lại design cho phù hợp 

Vậy câu trả lời cho câu hỏi " QC/Tester có cần phải quan tâm UX, UI không?" đã có câu trả lời rồi đó . Không làm ra sản phẩm nhưng để nhận xét, đánh giá đúng sản phẩm phải có kiến thức về nó . Kiến thức đó là sự tích lũy của những kinh nghiệm từ các sản phẩm đã làm, đang làm và sẽ làm , đang vọc phá, đã vọc phá và dự định sẽ vọc phá , những thói quen cá nhân cho 1 sản phẩm  cũng phải được chú ý  .... Đó là nguyên tắc của 1 tester 

2)  Không biết về UX/UI  sẽ ảnh hưởng như thế nào đối với công việc kiểm thử phần mềm

- Bạn sẽ dễ dàng bỏ qua những sai sót nhỏ chẳng hạn màu sắc, tỉ lệ giữa các element ...

- Bạn sẽ không hiểu ý đồ và không có cái nhìn tổng quan cho từng phần trong thiết kế

- Bạn sẽ cảm thấy - miễn chạy tốt chức năng , có thể chấp nhận việc tùy biến design hoặc tùy biến chức năng , dẫn đến việc sản phẩm cuối cùng không giống như đặc tả mà chỉ hao hao giống ...

- Bộ testcase của bạn sẽ nghèo nàn nếu không hiểu được thói quen người dùng cho từng chức năng của giao diện đó .

Một ví dụ rất hay xảy ra là khi các bạn designer làm xong phần design, đưa cho coder thì bạn coder hay comment là design như thế này khó quá, không thể làm được và yêu cầu thay đổi design để code dễ hơn. 

Tuy nhiên, không phải cứ dễ code hơn là hay hơn. Vì bạn coder không hiểu về UI/UX nên không hiểu vì sao design nó cần như thế,  Và Tester lại thấy Coder làm như vậy là hợp lý, không quan tâm nhiều đến Design , gây ảnh hưởng đến sản phẩm cuối cùng.

3) Việc biết nhiều về UI/UX sẽ có lợi như thế nào cho 1 tester và công việc kiểm thử phần mềm và xây dựng bộ script cho kiểm thử phần mềm tự động 

Nó sẽ giúp bạn suy nghĩ theo hướng làm thế nào để user dễ sử dụng nhất, từ đó làm chủ sản phẩm.

và sẽ cho ra những testcase " thần thánh".Nhưng nên nhớ là đừng có " thần thánh " cao siêu , những  trường hợp kiểu thử vô lý và " không giống ai" nhé,  sẽ bị gạch đá và bị nguyền rủa không thương tiếc đó . Nên nhớ nghề Tester cũng là một trong số những nghề " nguy hiểm" ak . hehe

4) UI là gì ? 

 4.1. Định nghĩa UI : User Interface - Giao diện người dùng , UI là cái mà người dùng nhìn thấy.

Các nhà thiết kế website, nhà phát triển ứng dụng và kinh doanh thương mại điện tử dành nhiều quan tâm đến việc hiểu được yêu cầu của người dùng và thói quen của người dùng– chẳng hạn như họ muốn điều hướng như thế nào, menu yêu cầu có những gì – trước khi đi vào thiết kế UI cho ứng dụng của họ.
 Toàn bộ quá trình thu thập yêu cầu người dùng, đặt những yếu tố khác nhau của phần mềm và tạo ra một giao diện người dùng hiệu quả được gọi là thiết kế giao diện người dùng (UI design).

4.2. Nguyên tắc để đánh giá 1 UI tốt 

 - Biết đối tượng sử dụng sản phẩm của bạn  để họ thấy rõ ràng những thông điệp có sẵn phù hợp với họ 

- Mượn các hành vi, thói quen sử dụng quen thuộc của người sử dụng 

- Tính trực quan , ngắn gọn, dễ hiểu  

- Tập trung vào các vị trí tỷ lệ vàng, , tỉ lệ 1/3 ...Chúng ta thường bị thu hút bởi các khu vực chuyển động hơn là các khu vực tĩnh. Những thay đổi tại khu vực động sẽ được phát hiện dễ dàng. Các con trỏ văn bản là một ví dụ của một đối tượng hấp dẫn mắt. Thay đổi hình ảnh của nó có thể là những báo hiệu thay đổi trạng thái khác nhau và hữu ích.

 - Nguyên tắc ngữ pháp , sử dụng ngôn ngữ của người dùng 

- Hiểu được các trợ giúp mà người dùng cần

- Hãy để cho người dùng tự tin bằng cách tạo dựng một hệ thống an toàn

- Một số nguyên tắc khác 

Như vậy , UI càng đơn giản, gọn nhẹ  và làm nổi bật cái mà người dùng muốn ( mục đích sử dụng ) và cái mà người dùng cần cộng với phù hợp với thói quen người sử dụng thì đó là một UI tốt . Tất nhiên nếu tất cả các đều đó cộng thêm một chút " đẹp, hài hòa , lạ mắt" nữa thì quá tốt.

Thử nhìn lại một số giao diện đặc trưng cho mô tả trên nhé , tiêu biểu nhất là Trang web của gã khổng lồ Google.com. 

Ta có thể dễ dàng nhận ra, yêu tố đơn giản, dễ sử dụng mà google đã khai thác triệt để, ai cũng có thể sử dụng dễ dàng, chỉ là 1 ô tìm kiếm với nút search . Kết quả trả về cũng vô cùng rõ ràng, thân thiện .

5. UX là gì ?UX là cách người dùng sử dụng, các chức năng của chương trình đó  (User Experience)

( Click vào hình để xem rõ hơn ) 

---------------------

Học kiểm thử phần mềm tự động 

Xem Chi tiết

Để trở Thành 1 QC " Pro" !

Hoàn cảnh:

Sau khi đã Deli 1 sprint của dự án và nhận được Feedback từ khách hàng ,Dev + QC ngồi tám và vạch tội nhau (lưu ý chỉ là feedback thôi, có thể là có bug , có thể là change request, hoặc thảo luận về các vấn đề nãy sinh - nhưng thấy feedback về nhìu là lòng dạ bất an rồi ) 
-----------------------------------------------------------------------
+ Dev- ( sờ ta tút của hắn ta là " Củm thấy thất zọng”)  : Thật sự buồn vì QC tệ quá, cách test chẳng Pro, không biết tại quy trình hay tại ....? Dự án của mình thấy QC post toàn bug chi chi mô mô ( để mẹc buồn )
+ QC- ( no any status) : Thiệt hả zu , Zu củm thấy zậy á , buồn ak nha( nghĩ thầm - chắc hắn đang muốn gây chiến đây, lại chọc zô nỗi trăn trở của mềnh - âm thầm chịu đựng trả thủ sau vậy ) 

+ Dev-  ( sờ ta tút: Đang nghiêm túc) : Thiệt chứ, thấy QC chẳng Pờ rồ gì hết á, bị nó feedback cả mớ kìa, sót bug từa lưa

+ QC  : Hjc, QC làm sao mà Pờ rồ được , Pờ rồ là dành cho dev - Programer hoặc dành cho  PM thôi - Project-manager.

( đang cảm thấy hơi giận nhưng không muốn trở thành người cố chấp. lật feedback ra dòm và kiểm định)

------------------------------------------------------------------------
Thực sự là mình cũng ngờ vực bản thân đã làm không tốt . Mình chấp nhận  và không cảm thấy xấu hổ về  điều đó .  Bởi vì sao ư, một người lúc nào cũng vỗ ngực tự tin " Tôi giỏi, Tôi Pro, tôi chẳng bao giờ để lọt 1 cái bug nào dù là nhỏ nhất trong bất kỳ dự án phần mềm" và gạt qua mọi lời góp ý, đổ lỗi cho mọi lỗi lầm thì đó mới là điều nguy hiểm nhất.
Nếu trương họp bạn bị chê như vậy ( bâng quơ và xuất phát từ yếu tố chủ quan cả khách quan nữa) , bạn sẽ như thế nào ?

Câu hỏi đặt ra, làm sao để trở thành 1 QC /QAgiỏi , (có thể hoành hành ngang dọc , gây tiếng vang trong giới giang hồ ). Sau đây là một số bí quyết tham khảo:

1) Hiểu rõ bản chất công việc của mình.Nhiều người trong nghành Kiểm thử phần mềm còn lẫn lộn danh xưng . Phân biệt Tester, QC, QA ? 

Hiểu rõ công việc , nhiệm vụ của mình giúp ta xác định được sẽ cải thiện kỷ năng nào, hạn chế những khiếm khuyết nào gây ảnh hưởng đến công việc, Nhờ đó, về lâu dài, các kỹ năng cần thiết sẽ được phát huy và đáp ứng tốt cho công việc, 

- Tester: Thử nghiệm, kiểm thử hệ thống phần mềm nhằm tìm các lỗi phát sinh cho 1 dự án phần mềm. Công việc bao gồm lập kế hoạch kiểm thử và thực thi kiểm thử. 

Ở một số công ty như công ty game, tester chủ yêu là ngồi chơi hết các level của game và báo cáo kết quả ( lỗi, những chức năng khó sử dụng, hoặc góp ý, nhận xét, đánh giá Game đó... ) Và ở một số công ty, Tester chỉ thực thi những testcase có sẵn 

- QC: Kiểm soát,đánh giá, đảm bảo,bảo trì chất lượng sản phẩm phần mềm theo đúng đặc tả yêu cầu và đảm bảo không có lỗi trong quá trình hoạt động của một phần mềm nhất định.

-QA:  Đặt ra những quy chuẩn nhất định, những quy trình nhằm chắc chắn các công đoạn sản phẩm đã đạt yêu cầu về chất lượng trong suốt quá trình thực hiện dự án. 

Ví dụ nhé : Sản xuất 1 sản phẩm nước đóng chai , QA là bộ phận quy định nước đóng chai sau khi hoàn thành phải đảm bảo , chất lượng nước phải đạt độ tinh khiết 100%, chưa những chất gì và không chứa những chất gì , điều kiện bảo quản , thời hạn sử dung....QC sẽ tiến hành các khâu kiểm tra trong suốt quá trình sản xuất sản phẩm xem trong quá trình ấy, có xảy ra sai sót gì không, Đảm bảo mọi thứ sẽ đạt được đúng như chất lượng đề ra ( từ QA) . Sau khi sản phẩm đã hoàn thành, Tester là người thử trước , sản phẩm có thực sự như vậy chưa trước khi tung sản phẩm ra thị trường .

 Như vậy, QA chỉ quan tâm : 

- Các công đoạn sản xuất sản phẩm được đảm bảo đúng quy trình 

- Chất lượng sản phẩm đúng quy định ( sản phẩm đã hoàn thành ) 

Còn QC sẽ đảm bảo : 

- Thành quả cho từng công đoạn sản xuất là không có lỗi 

-  Hàng loạt kiểm tra để chứng minh chất lượng sản phẩm đã đúng như yêu cầu 

Kết luận:  QA là bộ phận chỉ huy, chịu trách nhiệm toàn bộ về tiêu chuẩn, quy trình kiểm tra để đảm bảo chất lượng. QC là bộ phận thi hành những quy định, hướng dẩn của QA trong việc kiểm tra, phân loại chất lượng sản phẩm.

Tuy nhiên, phần lớn các công ty ở Việt Nam, việc đưa ra vị trí và phân chia công việc vẫn còn mơ hồ, chưa được cụ thể. 

2) Cần Technical skill : Nghề Kiểm thử phần mềm không đòi hỏi bạn phải tạo ra một sản phẩm cũng không cần bạn có những ý tưởng lớn lao nhưng nếu biết về công nghệ để tạo ra những sản phẩm lớn lao thì đó là một lợi thế đối với bạn. 

Vâng, tôi đang muốn nói đến việc nắm bắt một ngôn ngữ lập trình nào đó để nắm bắt cấu trúc của hệ thống phần mềm ( sơ bộ thôi, ai trong chúng ta cũng đều được học nếu là dân CNTT, nếu không phải, tìm hiểu sơ bộ cũng được, quan trọng là hiểu nó hoạt động như thế nào , cấu trúc ra sao) 

-  Công việc kiểm thử phần mềm sẽ rất là thuận lợi  nếu bạn Vọc phá ,sử dụng thành thạo nhiều nền tảng khác nhau như hệ điều hành, các trình duyệt , các sản phẩm từ  Iphone, Ipad , Android ...Window , Linux, Mac OS.

Có thể dùng các chương trình ảo , Emulation để vọc ( Iphone , Ipad không phải muốn vọc là có vọc , hehe) . Các kiến thức về mạng, client - server , quá trình lưu trữ dữ liệu hoặc một số công nghệ như 3G, GPRS, Wifi ...thiết bị phần cứng ...sẽ rất giúp ích cho bạn trong việc kiểm tra sự tích hợp, vận hành sản phẩm ở những môi trường khác nhau .

- Không ngừng tìm hiểu, học hỏi các công cụ kiểm thử tự động (Selenium Webdriver , QTP , Jmeter ...) , các công nghệ mới hỗ trợ cho công việc .

Đương nhiên việc áp dụng các công cụ kiểm thử tự động sẽ giúp việc kiểm thử sẽ trở nên nhanh chóng, hiệu quả. Vậy tại sao bạn không thử học kiểm thử tự động nhỉ, với bản chất tò mò , thích khám phá, bạn chắc chắn sẽ control dự án của mình thật tốt, hạn chế tối đa lỗi 

3) Kiến thức đặc thù cho từng dự án : Việc bạn biết thêm một số kiến thức liên quan đến lĩnh vực dự án đang thực thi giúp ích rất nhiều trong việc kiểm thử phần mềm đó

Bạn đang làm về game thể thao bóng chày, nhưng không biết luật chơi, không biết quy định thì khổ rồi ! 

Nếu bạn có kiến thức về kế toán, việc giải quyết công nợ, giấy tờ, số sách, hóa đơn , báo cáo tài chính, cân bằng quyết toán ...thì việc kiểm thử một phần mềm Kế toán sẽ dễ dàng hơn rất nhiều . 

Cho nên, dù ở lĩnh vực nào . Không ngần ngại tìm hiểu sâu hơn chút, kỹ hơn chút sẽ rất tốt . 

4) Kỹ năng mềm trong kiểm thử phần mềm :

 Ngoại ngữ là yếu tố quan trọng nhất đó , kỷ năng giao tiếp là yếu tố quan trọng thứ hai .  

Kỷ năng giao tiếp tốt giúp bạn trình bày vấn đề mạch lạc , dễ hiểu, giúp Developer và QC tránh những mâu thuẫn phát sinh vì mục đích chung không phải là có bug hay không có bug, cần phải sửa lại một vài thứ hay cứ giữ nguyên mà là dự án hoạt động tốt, khách hàng happy.

 Hợp tác , nhúng nhường, quyết đoán và cư xử một cách thông minh là những tố chất nên có của một QC giỏi bởi lẻ  mỗi người có cách nhìn nhận vấn đề  và phán xét theo cái lý riêng của họ và cần tôn trọng cái lý riêng ấy của mỗi người . 

Ở mỗi góc nhìn khác nhau, vấn đề đó khó có thể đúng sai rạch ròi . Với những người cố chấp, càng cãi lại, họ càng đinh ninh rằng họ đúng.Chỉ cần dùng hành động chứng minh , nhận ra hay không nhận ra đó là do ở mỗi con người .

Nhìn nhận lại mình và rút kinh nghiệm nếu sự chê bai đó đúng và một lời xin lỗi rồi phân trần khéo léo nếu sự chê bai đó là " cố ý dìm hàng - phản bác sự thật " mình thấy sẽ tốt hơn.

5) Kỹ năng đặc biệt trong kiểm thử phần mềm  :  

Có lẽ đây là kỹ năng quan trọng nhất, đặc biệt nhất và đặc trưng nhất của QC ,đó chính là : 

 - Bản thân yêu thích, khám phá , vọc , tìm tỏi 1 ứng dụng phần mềm 

-  Bất chấp tất cả để tìm ra lỗi, có thể áp dụng mọi " thủ đoạn" ( ghê quá - hehe) , mọi phương pháp, hoặc thậm chí hy sinh tình cảm và  hình tượng tốt đẹp , gương mẫu trong mắt đồng nghiệp để trở thành kẻ phá đám đáng ghét , bị " nguyền rủa" , bị " hăm dọa", bị đá đểu và xỉa xói ( hehe) 

-  Cảm thấy bực mình, vướng mắc vì một thứ rườm rà, khó hiểu, khó sử dụng và tự nhủ rằng , nếu là mình ấy, mình sẽ làm như thế này nè và mọi thứ có phải là tốt hơn không ( hơi chủ quan nhưng nếu lên ý kiến và chấp nhận sai còn hơn cứ lơ tơ mơ trong mớ hỗn loạn ) 

-  Cảm thấy thông cảm với khó khăn và vướng mắc của lập trình viên ( kẻ chuyên nguyền rủa mình ) nhưng cũng không quên rằng, sản phẩm này là cho người dùng. Và trách nhiệm chung là phải hợp tác 

 - Biết tranh cãi và nhận lỗi , biết thuyết phục và tìm bằng chứng để bảo vệ quan điểm của mình, với mục tiêu sản phẩm sẽ đạt một level cao hơn về tính thân thiện và làm người dùng yêu thích 

- Là 1 kiểm thử viên phần mềm, không chỉ tìm lỗi mà còn phải đảm bảo tính đúng đắn của phần mềm . Vì thế, đừng buồn khi tìm hoài mà không thấy bug hoặc sao bug ít quá, Cố gắng tìm thật nhiều bug linh tinh để tính thành tích và khoe mẽ là việc không nên làm.

 - Hãy lên tiếng. Một quy trình không tốt, cách làm việc chưa phù họp hoặc gặp trục trặc làm trở ngại công việc của bạn mà bạn không biết làm sao để tốt hơn. Hãy mạnh dạn bày tỏ quan điểm với " sếp". Dù bạn có bị đánh giá thấp hoặc không được thông cảm cũng không sao .Biết khả năng của mình tới đâu vẫn tốt hơn. 

Còn rất rất nhiều kỹ năng nữa trong bạn, trong tôi, trong tất cả mọi người đã , đang, và sẽ gắng bó với nghề Kiểm thử mà chưa khám phá hết. 

Hãy yêu công việc và cười với nhau mỗi ngày nhé ! 

----

Học kiểm thử phần mềm 

https://www.facebook.com/groups/1549328495322684/

https://www.facebook.com/KiemThuPhanMemVvn

Xem Chi tiết

Kiểm thử phần mềm : Danh sách email hợp lệ và email không họp lệ

I.Việc Check Email trong kiểm thử 

Hầu như phần lớn các ứng dụng phần mềm, Website và cả Mobile app. Check email luôn xuất hiện ở các test case trong kiểm thử phần mềm. Với email, ta chỉ cần test 2 trường họp : Email valid ( họp lệ) và Email invalid (không hợp lệ). Thế nhưng câu hỏi đặt ra là email như thế nào là hợp lệ và như thế nào là không hợp lệ.

1. Email hợp lệ 
Định dạng email có dạng:  Local-Part@Domail Name 
Các điều kiện quyết định email có hợp lệ hay không : Có các điều kiện sau:

1) Email hợp lệ có chứa Local-Part như : kiemthuphanmem@yahoo.com, kiemthu-phanmem@gmail.com
2) Và chứa Domain name
3) Ký tự @ nằm giữa Local-Part và Domain name
4) Tối thiểu 1 dấu chấm nên có . Ví dụ kiemthuphanmem@yahoo.com.vn
5) Dấu gạch "_" được cho phép . Ví dụ : Kiemthu-phanmem@gmail.com
6)  Email chứa dấu chấm với tên miền phụ ở domain

2. Email không hợp lệ :
Email được gọi là  không họp lệ nếu có 1 trong các trường hợp sau :
1) Sai định dạng
2) Local-Part toàn bộ là tự đặc biệt hoặc có chứa khoảng trắng ( kiem thuphanmem@gmail.com)
3) Tên miền không hợp lệ như : Kiemthuphanmem@sdghnhghgsdsfdsffgdsds
4) Thiếu @ hoặc @ không nằm giữa Local part và Domain name Ví dụ kiemthu&yahoo.com
5) Vượt 3 dấu chấm . Ví dụ kiemthuphanmem.com.vn.en ( trừ khi domain là dãy IP và sub domain)
6) Tên miền chứa ký tự đặc biệt trừ khi domain là dãy IP . Ví dụ kiemthuphanmem@^%$##.com

II. Một số ví dụ về Email hợp lệ và email không hợp lệ trong kiểm thử phần mềm

1- Email hợp lệ

email@domain.com : Chuẩn định dạng
Firstname.lastname@domain.com: Không vi phạm định dạng
email@subdomain.domain.com : Email chứa dấu chấm với tên miền phụ ( điều kiện 6 - email hợp lệ )
firstname+lastname@domain.com: Hợp lệ vì không vi phạm trường hợp  2 của email không hợp lệ
email@111.111.111.111 : Ngoại lệ của điều kiện 5
email@[111.111.111.111 : Ngoại lệ của quy tắc 6 ( Cái này mình tham khảo một số anh chị trên công ty thì được liệt là email không hợp lệ , mọi người chú ý cho case này nhé, mình cũng cảm thấy vậy , nếu khách hàng chấp nhận có thể không tính email dạng này là hợp lệ)
email"@domain.com: hợp lệ vì không vi phạm trường hợp 2
1234567890@domain.com : hợp lệ -không vi phạm trường hợp 2
email@domain-one.com
email@domain.name
 email@domain.co.jp
 firstname-lastname@domain.com là những email hợp lệ , có thể chấp nhận.

2-Email không hợp lệ : 
Do sai định dạng hoặc vi phạm các điều kiện email hợp lệ và nằm trong các trường hợp email không hợp lệ:

Kiemthuphanmem : Thiếu @và domain  ( Sai định dạng)
#@%^%#$@#$@#.com 
@domain.com
QC NAME<email@domain.com>
email.domain.com
email@domain@domain.com
.email@domain.com
email.@domain.com
email..email@domain.com
&#12354;&#12356;&#12358;&#12360;&#12362;@domain.com
email@domain.com (Joe Smith)
email@domain
email@-domain.com
email@domain.web
email@111.222.333.44444
email@domain..comn 

Đây là một số trường hợp mình sưu tầm được. Tuy không đầy đủ nhưng cũng hy vọng sẽ giúp ích pà kon trong nghề . Hihi.

Note quan trọng: Hiện nay một số page follow theo định dạng chuẩn của các nhà cung cấp lớn như google, yahoo, outlook... và những email từ những nhà cung cấp này đã chặn một số ký tự đặc biệt  trong email như email"@domain.com, firstname+lastname@domain.com ...
 Cho nên tùy vào yêu cầu của từng dự án mà có các định dạng email hợp lệ và không hợp lệ  khác nhau , đây chỉ là danh sách tham khảm chứ không phải luôn luôn đúng

Chúc các bạn thành công !

------------------------------------------

Học kiểm thử phần mềm 

Face: https://www.facebook.com/KiemThuPhanMemVvn

G+: https://plus.google.com/u/0/b/117542284818070877723/117542284818070877723/about

Xem Chi tiết

BUG ải BUG ai?

 I.Test escape hay Leaked bug trong Kiểm thử phần mềm :

- Có một thực tế hết sức phủ phàng mà hầu hết các kỷ sư kiểm thử phần mềm đều gặp phải đó là gần như chắc chắn là bạn không bao giờ tìm hết tất cả các lỗi của sản phẩm phần mềm . Bạn đã nắm được rất kỹ- rất có kinh nghiệm trong kiểm thử chức năng (Functional Testing)  hay Kiểm thử tự động (Automaiton testing) ,  đã test rất kỹ càng trước khi bàn giao nhưng vẫn bị khách hàng tìm thấy trong quá trình sử dụng và nó được gọi là test escape hay leaked bug .

Gì chứ hả, bug nữa á 

- Một vấn đề mà tester thường xuyên gặp phải như sau: 

+ Sau khi kiểm thử một Website / Application cho khách hàng - Chỉ yêu cầu test những chức năng của Website đó.  Tôi dùng cả 2 kỷ thuật function testing và Automation testing, kiểm thử tự động cover được những test case chính và đã passed tất cả . Những case khác, tôi đã thử tất cả các trường họp có thể xảy ra và tìm được rất nhiều bug. Khi tất cả các bug này được Fixed - và thực hiện kiểm thử chấp nhận (Acceptance Test) cũng đã Passed. Sản phẩm được bàn giao cho khách hàng và nhận được feedback, tôi mới ngạc nhiên vì có rất nhiều bug từ người dùng.

+ Nghiên cứu, đọc và thực hiện lại các mô tả lỗi của khách hàng để tìm kiếm nguyên nhân (root cause) tại sao tôi lại để sót những bug này và nguyên lý sinh ra bug - tôi mới thấy rằng , cách suy nghĩ, sử dụng và tương tác với sản phẩm phần mềm của người dùng cuối khác khá nhiều so với cách suy nghĩ và tinh thần của người phát triển phần mềm - ngay cả với testcase của Kiểm thử viên phần mềm - 

Vì sự chủ quan đảm bảo tất cả các chức năng hoạt động đúng như thiết kế mà vô tình quên đi những thói quen người dùng, những tương tác khác ( không có trong thiết kế) vô tình tạo ra lỗi hoặc Có thể tại thời điểm này, các chức năng của phần mềm hoạt động hoàn toàn đúng và chính xác nhưng ở một số trạng thái(states), luồng dữ liệu và điều khiển(control) vấn có một số đụng độ với webserver hay hệ điều hành hay trình duyệt....gây ra những lỗi không đáng có . 

Vậy đó, với tư duy " Biết quá nhiều " những công nghệ, những thủ thuật cao xa và những thao tác phức tạp  đã khiến cho các nhà thiết kế phần mềm, các nhà phát triển phần mềm và cả các kiểm thử viên phần mềm  quên đi mục đích tạo ra sự tương tác thân thiện, dễ hiểu, dễ thực hiện cho người dùng- những khách hàng của bạn. Qúa chú trọng vào những bug " bự" mà vô tình bỏ qua những điều nhỏ nhặt nhưng lại vô cùng quan trọng trong việc đánh giá chất lượng sản phẩm phần mềm của bạn.

Qua đây, tôi chỉ muốn lưu ý các bạn tester (có cả tôi ) phải chú ý những điểm quan trọng sau:

1) Kiểm thử phần mềm phải luôn đứng và suy nghĩ như một người dùng thực sự, để mindset của bạn giải phóng khỏi những ràng buộc cũng như lối tư duy " Biết quá nhiều" của những nhà phát triển sản phẩm 

                           

2) Kiểm thử phần mềm phải luôn làm giàu (enrich ) bộ testcase của bạn - từ những case đơn giản, trưc quan nhất đên các case dự đoán là sẽ tìm ẩn nhiều bug nhất , từ tình huống đến dữ liệu kiểm thử phải có tính hệ thống và hướng đến người dùng

 

3) Kiểm thử viên phải luôn note lại cho mình những trường họp mà người dùng gặp phải, những case lạ , những phát hiện mới mẻ trong quá trình tìm bug sẽ giúp bạn có kinh nghiệm hơn, testcase phong phú và chất lượng hơn , đó như là sự tích góp, năng nhặt chặt bị để vào vai người sử dụng một cách tròn trĩnh và xuất thần 

Có thể đây chỉ là những chú ý đơn giản  nhưng để thực hiện nó vào dự án thực tế không hề đơn giản, bạn cần bĩnh tĩnh, tự tin , lạc quan và có sự tưởng tượng phong phú , nghiền ngẫm các spec , tài liệu thiết kế, thi thoảng phải chậm lại chút và quan trọng hơn cả là phải luôn để ý đến điều này sẽ giúp bạn hài lòng với những gì mình đã làm được .

Một vài chia sẻ nho nhỏ hy vọng sẽ giúp ích cho bạn đọc 

Chúc các bạn thành công 

-------------------------------------------

Face: https://www.facebook.com/KiemThuPhanMemVvn

G+: https://plus.google.com/u/0/b/117542284818070877723/117542284818070877723/about

Xem Chi tiết