Chắc hẳn qua hai bài viết về Tầm quan trọng của test case – http://bit.ly/2rvtrM7 và Thành phần của một test case – http://bit.ly/2sCQY2f thì chắc mọi người đã biết viết test case như thế nào rồi phải không ạ.

Tiếp nối phần tìm hiểu về test case đó chính là Tool quản lý test case.

Đầu tiên phải kể đến “Excel – Google sheet”. Đây là tool được sử dụng từ rất lâu và ở nhiều công ty, nhiều project.

Giao diện trực quan, hầu hết mọi người đều biết sử dụng, chỉ cần có thêm xíu skill về excel thì bạn có thể dễ dàng tổ chức bộ test case mình một cách hiệu quả và tiện dụng.

Về phía mình thì nhận thấy Google sheet rất tốt, đặc biệt là những project vừa và nhỏ, team có khoảng 1,2 tester/QA. Với những project lớn, có nhiều tester/QA và phải tạo test run nhiều thì việc quản lý bằng Google sheet khá khó khăn và không rõ ràng.

Vậy nên thì với những project lớn, các công ty thường chọn những tool quản lý test case chuyên biệt.

Trên thị trường hiện tại có rất nhiều tool, có tool free, có tool trả phí, nhưng hầu hết là phải trả phí, tool free thì xài không tiện và giao diện cũng xấu lắm 🙂 Nói chung team lớn, project lớn thì chuyển bỏ ra một khoản tiền để cho test case management cũng không phải vấn đề lớn nên Thu nghĩ cũng thoải mái.

Có hai loại tool chính: một loại chỉ là tool để quản lý test case, một loại là tool nằm trong một bộ phần mềm quản lý project.

Thứ nhất, tool quản lý test case riêng biệt, bạn sẽ tìm hiểu đến nó khi project của bạn muốn dùng những tool riêng biệt cho những mục đích riêng (ví dụ như dùng Git để quản lý code, dùng Jira để quản lý task….):

– Với tool free bạn có thể thử là TestLink…Bạn tự setup trên server công ty và dùng, giao diện hơi “chuối” nhưng nếu cố gắng vẫn dùng được.

– Với tool tính phí thì có nhiều sự lựa chọn, ví dụ như Testrail, Testlodge,…Với mình thì thấy hai tool này khá tiện cho việc sử dụng, nó đáp ứng đủ nhu cầu quản lý test case.

Thứ hai, tool nằm tròng một bộ phần mềm quản lý project. Bạn có thể tham khảo Visual Studio Team Service hay Terik. Hai tool này khá nổi trên thị trường. Mục đích của bộ tool này là “quy tất cả về một mối”, từ source code, test case, document, process, automation test, CI/CD,.. Giá thành thì không cần nói. Nhưng dùng khá tiện dụng. Phần quản lý test case cũng rất tốt.

Đó là tất cả những thông tin về test case management tool, hy vọng qua bài viết này bạn sẽ có một cái nhìn tổng quan về hệ thống các tool có trên thị trường. Tùy vào nhu cầu và kinh phí của công ty mà bạn có thể lựa chọn những tool phù hợp để sửa dụng nhé.

Hi mọi người,

Mình nhận được feedback rất tốt về bài viết trước: Tại sao lại cần test case – http://bit.ly/2rvtrM7

Cảm ơn sự ủng hộ của mọi người ạ ❤

Hôm nay Thu xin chia sẻ về Các thành phần của một test case.

Thật ra thì không có một khuôn khổ nhất đình, tùy vào context của phần mềm bạn đang làm thì sẽ có những “custom” sao cho phù hợp nhất.

Ở đây thì mình sẽ chia sẻ một test case có thể xem là tương đối “đầy đủ” và đáp ứng mọi mong muốn từ team, giúp test case “rõ ràng” hết mức có thể.

– Test case ID: chỉ đơn giản là ID để mình dễ gọi tên nó thôi. Thu thường hay đặt theo kiểu.

Ví dụ như test case của chức năng “Sign Up” thì sẽ là SU_001.

– Test case summary: đây là phần tóm tắt, có thể gọi là tên của test case. Phần này cũng khá quan trọng, giúp cho người đọc nhận diện được mục đích của test case là gì. Một cái tên tốt là cái tên mà chỉ cần đọc vào là biết được mình phải làm gì.

Ví dụ : “Verify that user can sign up with valid data successfully”

– Test case description: phần này để mô tả chi tiết test case dùng để làm gì. Vì phần tên thường không thể mô tả đầy đủ được test case, nên chúng ta sẽ mô tả rõ ở đây. Nhưng theo kinh nghiệm của mình thì phần này thường hao hao giống phần “Test case summary”, nên nếu thời gian hạn hẹp, bạn có thể lượt bỏ phần này.

– Pre- conditions: điều kiện, đây là phần Thu nghĩ không thể thiếu. Không thể cứ mở phần mềm ra là test được liền, bạn cần test data, test data phải thoải một số điều kiện nào đó. Bên cạnh đó là môi trường test, bạn cần phải ở màn hình nào để chuẩn bị để test…. Nói chung là không thế thiếu nhé.

Ví như bạn kiểm tra case sau: “Verify sign in function when there’s no internet connection”

\=> Thế thì Proconditon là : “1. There’s no internet connection on device. 2. User is in sign in screen”

– Test data: Có những test case sẽ cần test data, có những cái không cần. Với những hệ thống phức tạp thì thường sẽ có, bạn phải dùng một account nhất định thì bạn mới có function đó để test hoặc với một số case nhất định như valid data chẳng hạn, mình nên đưa test data để dễ dàng test hơn.

– Reproduce Steps: mô tả lại từng step để thực hiện test case. Phần này là phần cực kì quan trọng và chiếm nhiều thời gian khi viết test case.

Một test case tốt khi phần này được viết chi tiết và rõ ràng. Nhớ rằng “Đừng assume” bất cứ điều gì khi viết nhé, hãy nghĩ rằng bạn là một người không biết gì về phần mềm và đây là lần đầu tiên bạn thao tác nhé. Có thể thì test case của bạn mới rõ được.

– Expected result: tương ứng với một “reproduce steps” bạn viết thì sẽ có một expected result. Không nhất thiết là step nào cũng phải có, nhưng nên là có bạn nhé.

Ví dụ. Trong test case “Verify that user can sign up successfully”. Bạn có steps “Press “Sign In” button” thì tương ứng phải phải có expected result “Sign in successfully. User go to home screen”

– Observed/Actual result: kết quả thực tế. Thường thì phần này bạn sẽ thêm vào khi bạn run test case nhé. Nó giúp bạn biết được thực tế phần mềm đang có gì, bị lỗi gì hay nó làm “work like expected”

– Test case status: hiện trạng của phần mềm, nó là kết quả sau khi bạn “run” một test case. Thường có 4 status: Pass/Fail/Blocked/Skipped

– Bug ID: nếu test case bị failed thì bạn sẽ tạo một ticket bug và thêm bug ID vào cột này nhen. (Thường team sẽ có một phần mềm để quản lý task và bug)

– Environment: môi trường test. Quá trình phát triển phần mềm thường sẽ có nhiều môi trường như Dev, Staging, UAT, Production. Khi bạn run test case, thì nhớ ghi rõ là bạn test trên môi trường nào nhé.

– Notes/Comment: lưu ý hay phản hồi gì đó bạn muốn ghi lại cho người khác dễ dàng thực hiện hơn khi đọc

Đó là tất cả những phần mà test case nên có bạn nhé 😀 Có những phần chỉ sẽ chỉ xuất hiện khi bạn “run” thôi. Nhưng khi thiết kế thì bạn nên để sẵn những cột đó để không bị “miss” bất cứ thông tin gì nhé.

Hy vọng rằng bài viết cùng những ví dụ của mình sẽ giúp ích cho các bạn. Chào thân ái !

Xin chào mọi người, trước giờ mình hay chia sẻ về những thông tin mình tâm đắc nhưng bữa giờ mình lại nhận được nhiều tin nhắn hỏi về những cái “nền tảng” của testing như cách bắt đầu với testing, test case, test plan,.. Nên hôm nay mình sẽ chia sẻ về test case, sẽ có nhiều phần, nhưng phần đầu tiên mình sẽ nói về tầm quan trọng và tại sao cần có test case.

Vậy test case là gì ?

Sau khi có được tất cả requirement, test plan thì một tester/QA đã biết nhiệm vụ của mình là gì. Và việc tiếp theo phải làm là xây dưng bộ test case cho phần mềm.

Mình có một định nghĩa tiếng anh cho test case: A test that (ideally) executes a single well defined test objective (i.e., a specific behavior of a feature under a specific condition). Chưa biết dịch tiếng việt sao cho sát nghĩa nhất, đại loại một test case là một cái thể hiện được một cách hoạt động của một chức năng nào đó mà có mô tả, điều kiện chi tiết rõ ràng.

Chính vì vậy, một test case tốt là một test case làm sao để bất cứ ai đọc vào họ cũng có thể biết làm sao thực hiện/mô phỏng lại nó trên ứng dụng và họ biết chức năng đó đang hoạt động đúng hay sai.

Thế tại sao mình cần test case ?

Nhiều bạn có suy nghĩ (đặc biệt là newbie): Ơ hay, mình test app, mình nhớ hết rồi, cần gì ngồi viết ra, mất thời gian ?

Vâng bạn có thể nhớ, nhưng có chắc bạn có thể nhớ tất cả mọi lúc.

Bộ test case là nơi bạn lưu trữ lại tất cả thông tin về app. Nó có thể được coi như một document hiệu quả cho phần mềm.

Bộ test case như một checklist, mỗi khi test, bạn chỉ cần dựa trên checklist đó, thế là bạn không bao giờ “miss” case nào hết.

Khi bạn không còn tham gia vào project và giao cho một tester khác, test case là một tài liệu cực kì quan trọng. Người mới sẽ dựa vào test case để tiếp tục công việc của bạn => vậy nên việc xây dựng một test case hiệu quả là cực kì quan trọng, khi viết bạn phải chắc rằng mình không “assume” bất cứ điều gì, test case phải chi tiết, chính xác và được update liên tục. Vì không phải ai cũng có cái nền và hiểu hệ thống như bạn.

Việc có bộ test case sẽ giúp cho việc tạo test run dễ dàng hơn và từ đó mình có thể tracking lại quá trình xây dựng phần mềm, progress của project.

Việc có một bộ test case sẽ giúp bạn tracking bug hiệu quả hơn. Vì khi bạn có một checklist cho tất cả các case mình sẽ test, bạn sẽ dễ dàng lọc ra những bug đang có trong phần mềm.

Từ bộ test case bạn có thể biết độ bao phủ của test case (test coverage) đã tốt hay chưa. Nếu bạn đã execute hết bộ test case mà phần mềm vẫn còn bug có nghĩa là bạn biết mình viết test case chưa tốt => mỗi khi phát sinh bug mà flow đó chưa có trong test case thì hãy bổ sung ngay nhé. Không ai có thể xây dựng một bộ test case hoàn chỉnh ngay từ đâu, test case sẽ được bổ sung trong suốt quá trình phát triển phần mềm. Nhưng một người có kinh nghiệm thì test coverage thường sẽ cao vì họ biết được phần mềm thường gặp lỗi ở đâu.

Một lời ích khác nữa là cho cho việc automation, một test case viết tốt thì khi chuyển qua automation, build script sẽ nhanh và tốn ít thời gian hơn. Người viết script chỉ cần follow theo test case, có step đầy đủ và viết, không cần phải suy nghĩ nhiều.

Đó là “công dụng chính” của bộ test case đó. Có thể đọc tới đây thì các bạn có thể hình dung được một test case tốt cần gì rồi nhỉ. Bài viết cũng dài rồi nên mình sẽ gặp lại mọi người ở một bài mới – Cách viết test case tốt, hiệu quả, chuyên nghiệp !

Hy vong bài viết sẽ giúp ích cho cả nhả. Chào thân ái ❤

Jira – Có lẻ ai làm phần mềm cũng từng nghe tới. Một phần mềm cực kì nổi tiếng của Atlassian.

Jira là một “issue and project” tracking tool.

Nhận xét chung về tool này: TỐT.

Có tốn chi phí không ? – Có. Cũng khá cao, đặc biệt là những team lớn, càng lớn giá càng cao.

Mình dùng nó khi nào ? – Không phải vì nó tốt mà lúc nào mình cũng dùng. Tùy vào độ lớn của project.

• Với project vừa và nhỏ (thời gian làm <3th): mình nghĩ nó không phù hợp. Dĩ nhiên dùng vẫn được, nhưng mình sẽ tốn effort để setup, xây dựng ràng buộc. Tuy tool dễ sử dụng nhưng với người chưa từng dùng thì cũng mất thời gian để tìm hiểu về nó. Quy trình làm việc với Jira cũng khá mất thời gian so với 1 số tool đơn giản khác. Và thật sự, với thời gian ngắn như vậy, khó mà thấy được “sức mạnh” của Jira. Nên mình khuyến khích nên chọn một tool khác, ví dụ như Pivotal Tracker, Trello, Redmine,..
• Với project lớn ( thời gian làm > 3th): cũng khó mà đưa ra kết luận chính xác. Vì mình thấy ở các quốc gia như Mỹ, họ “thích” Pivotal Tracker và dùng nhiều. Còn châu Á, châu Âu thì là Jira hoặc VSTS. Nhưng với mình tool có cấu trúc rõ ràng, tường minh nhất đó chính là Jira, sau đó là VSTS. Vì với những project lớn, việc link giữa các ticket là vô cùng quan trọng, và Jira giúp bạn link rất tốt, link giữa ticket và ticket, link giữa ticket và doccument (nếu bạn dùng Confluence). Sau khi link thì cách Jira tổ chức giao diện, cây thư mục cũng tốt, rất dễ nhìn. Bên cạnh đó nó còn giúp mình tracking process cực kì tốt.

\==> Vậy nên để quyết định chọn một tool tracking process thì bạn phải cân nhắc thật kĩ nhé, xác định những ràng buộc cũng như nhu cầu để có sự lựa chọn tốt nhất.

Cách apply Jira vào project:

• Lựa chọn tool: mình muốn giải quyết bài toàn gì và Jira giúp được mình những gì.
• Xây dựng quy trình làm việc (workflow) cho project.
• Giới thiệu và hướng dẫn sử dụng Jira đến team.
• Quản lý quy trình, process, đảm bảo mọi người làm đúng quy trình để đạt được hiệu quả cao nhất.
• ** Note: nói thì dễ nhưng tới khi thực hiện bạn sẽ gặp khá nhiều khó khăn và nhiều bài toán phải giải quyết, đặc biệt là bước 4. Cứ trải nghiệm rồi bạn sẽ hiểu. Nhưng hãy lưu ý 1 điều: hãy chắc rằng người leader của project cũng “muốn” và tin rằng việc việc dùng Jira sẽ hiệu quả thì bạn mới có thể đưa nó vào sử dụng.

Làm việc với Jira thì nên dùng process gì: process thuộc Agile là tốt nhất nhé, đặc biệt là Scrum. Nói đúng hơn là “scrum custom” (mình sẽ chia sẽ chi tiết về scrum trong một topic khác ).

Một cái note hay hay nữa là Scrum có chức năng filter cực kì cool, những câu query mà bạn dùng để tìm ticket có một tên riêng là JQL, cũng select này kia, cool lắm !

———————-

Đây là những điều lưu ý cơ bản khi bạn muốn tìm hiểu về Jira. Bản thân mình không khen chê gì cả, vì tùy vào project. Nhưng chắc chắn rằng đây là ứng cứ viên sáng giá khi bạn đang trong giai đoạn tìm kiếm một tracking tool process !!!!

Hy vọng bài viết sẽ hữu ích cho mọi người. Nếu thấy hay thì hãy cho mình một like và hãycomment những gì bạn còn thắc mắc nếu có nha ❤ Thanks all !

Hi guys,

Lâu rồi mới viết lại, có nhiều chủ đề để nói nhưng trong đầu T nghĩ đến cái này trước nên xin bắt đầu với nó – “Tiếng anh trong testing”

Nhiều bạn hay hỏi: giờ làm ngành gì cũng cần tiếng anh phải không ? Testing có cần tiếng anh không ?

Trước giờ T đều trả lời là “Có” và giờ mình khẳng định là “Có”.

T sẽ không nói về những ngành nghề khác mà chỉ tập trung nói về testing.

Bản thân T, T không phải là một người chuyên anh, khả năng tiếng anh không bờ-rồ. Nhưng T có kiến thức nền tốt (cả một thời thơ bé học tiếng anh), lên đại học thì chủ yếu là nghe và nói chuyện một mình bằng tiếng anh.

Hồi ở trường hay lúc mới đi làm thì ít dùng tiếng anh lắm, cũng ngại nói, nói sợ nta nhìn, kì… Nhưng vẫn luyện tập. Cho đến khi công việc “yêu cầu” mình phải nói, khi người khác hỏi và khi mình có câu hỏi mà không hỏi thì không biết. Thế là nói thôi 🙂

T không biết quá nhiều từ vựng, nhưng cũng đủ để nói chuyện công việc hay khi mọi người nói chuyện cuộc sống thì cũng có thể join vào và chia sẻ với họ.

Bản thân cũng cảm thấy vui khi mình làm được vậy, vui vì họ hiểu mình và bất ngờ vì mình có thể nói “thoải mái” như vậy – giống tự kỉ vậy đó :v

Không những thế, T còn nhận được lời khen từ bạn bè đồng nghiệp, và cả “sếp” của mình.

Cty T có tổng số quốc tịch tính tới hiện tại là 55. Tiếng anh từ nhiều nước, cũng như tiếng việt từ nhiều vùng miền của VN vậy ak. Hic, cũng khó nghe lắm, nhưng rồi mọi chuyện câu đâu vào đó.

Sếp T hiện tại là người Philippines, hồi mới làm việc với cô ấy vài tuần. Một hôm đi ăn, cổ hỏi mình kiểu “Ở VN mình nói tiếng gì, có hay nói tiếng anh không ?” Mình bảo không. Cổ bất ngờ lắm, ánh mắt nghi ngờ, bảo “Oh, vậy sao tiếng anh mình giao tiếp fluently vậy ?” Mình nói chỉ học tiếng anh ở trường thôi và cười. (sếp vẫn giữ ánh mắt nghi ngờ @@ )

Tới đây thôi, nói chung mình thấy chỉ cần bạn chịu luyện tập, không cần phải có nói với bạn, chỉ cần chịu cố gắng là được thôi. Tin T đi

—

Quay lại về testing.

T từng làm qua product cho cả Vietnam và nước ngoài. Và ở đâu, tất cả document của project đều được viết bằng “Tiếng Anh”. Từ test plan, test case, project board, report,..

Khi làm việc, với người Việt thì bạn có thể chat với họ bằng TV nhưng với người nước ngoài thì tiếng anh hoàn toàn.

Nhìn trên thị trường, thấy hầu hết cty đều làm các product của nước ngoài, nên xác suất để làm việc với người nước ngoài rất cao.

Khi bạn làm testing, nếu làm ở VN thì phần lớn thời gian là “text message”, lâu lâu bạn mới call với khách. Thế nên hãy chắc chắn rằng: ít nhất bạn có thể discuss với khách bằng English message nhé.

Cơ mà, mình chắc rằng bạn không thể dừng ở đó được, vì thời gian qua thì “vị trí” và “cơ hội” của bạn cũng tăng lên (tăng bao nhiêu thì phụ thuộc vào bạn). Rồi cũng sẽ tới lúc bạn sẽ làm việc với khách hàng nhiều hơn. Team của bạn không chỉ ở VN, họ ở nhiều nơi trên thế giới. Bạn sẽ có nhiều cuộc họp on call. Và bạn phải “Nói”.

Hãy chuẩn bị kỹ năng thật tốt để khi cơ hội đến với bạn, bạn có thể tự tin nắm lấy nó.

—

Đừng nghĩ rằng chỉ cần bạn giỏi, có kỹ năng, kỹ thuật tốt là đã đủ.

Bạn có thể rất giỏi, nhưng nếu bạn không thể show được skill, idea của mình ra cho họ hiểu thì không ai biết bạn như thế nào. Và bạn sẽ mất nhiều cơ hội.

Túm lại, ngành nào cũng cần tiếng anh, hãy cố gắng luyện tập và T tin rằng ai rồi cũng sẽ làm được nếu cố gắng thật sự. T đã hặp rất nhiều người giỏi tiếng anh trong thời gian ngắn, trong khi trước đó họ thật sự không giỏi tiếng anh. Có thể bạn nói không chuẩn nhưng mình thấy hầu hết là case mình ko hiểu họ nói chứ họ đều hiểu mình nói gì :v Thế nên cứ học và nói thôi.

If developers have techniques to program, testers also have techniques to test. There are five popular techniques to make your testing becomes more effective. – First things first, equivalence partitioning (EP): this is one of the most common techniques that is frequently used, easy to approach and it can be applied at all testing levels. The idea of this is to divide a set of test conditions into groups that can be considerd the same. The principle is not only testing the things that are in our specification, but also thinking about things that haven’t been specified. This helps us to save our time and cover all situations. About designing test case in EP: we have two types: the valid and invalid condition, we can put all valid conditions in one test case and putting one invalid condition per one test case.

– The next technique is boundary value analysis (BVA): this is based on testing at the boundary between partitions. We often use EP and BVA together because they’re closely related. About designing test case in BVA: we should combine all minimum valid boundaries for a group of fields into one test case and also do the same with maximum boundary value.

– The third one is decision tables testing (DTT): this is a good way to deal with combinations of things. This technique is also sometimes alos refferd to as an “cause-effect” table. It focuses on business logics and business rules. But we can meet challenge because the number of combiantions can be huge. How to make DTT: first, indentifying suitable functions: n things to combine and m number of combination (m = 2^n). After that, we put them into a table of True of False for each item. Then we identify the outcome for each combiantion. Finally, we write test case for each of rules in our table.

– The next one is state transition testing (STT): this is used where some aspects of the system can be described in what is called a “finite state machine”. One of the advantages of STT is that the model can be as detailed or as abstract as you need it to be. We have two ways to show the state: state table and state graph.

– The final technique is use case testing (UCT): this is a technique that helps us to identify test cases that exercise the whole system from start to finish.

When we write test cases: we often use STT ans UCT to find all cases, make sure that you can handle all cases in the system then we often use EP, BVA and DTT to identify the situations for each case. We should corporate all techniques to have to best result.

That’s all. I hope that it can help you more in your work.

What do you know about software testing? I think all software engineers learn about software testing subject at university/college, but they always confuse software testing and tester’s role. Maybe it comes from the word “test”. In this post I will show you the different between them.

Almost developers think that testers are responsible for software testing. They also know that software testing includes unit testing, integration testing, system testing, acceptance testing. So they conclude that testers have to know unit testing and their responsible are making unit test. Because of holding this wrong view, that makes a misunderstanding between testers and developers. The developers think that the testers don’t fill their role. Besides that the tester will be upset with the developer’s attitude. When there doesn’t have a mutual understanding in a team, it’s difficult to work effectively.

How to deal with this problem? According to me, there’s one way. Just teaching them about software testing again. We have to focus on testing levels. It will show them the right things, they will understand clearly about their role in software testing.

You can learn about testing levels here. Software testing is one step in making software process. All the developers and the testers play important role in this step. There are four testing levels: the developer is responsible for unit testing, the tester takes part in the rest levels. The final purpose of them is making a good product, meeting the customer’s requirements.

If you solve this problem in your team, I think you will increase your staff efficiency. Good luck !!!

As you can see, the developers and the testers always argue about the bugs. Why this come from? There are a lot of reasons: misunderstanding each other, the developer advocates himself, the testers report the wrong bugs… These problems always happen, but how to avoid it, this post will discuss more about this and I hope that it will give you solutions to solve that or just to improve.

These are some common definitions:

• A developer is a person who builds or develops the application.
• A tester is a person who looks for the defects or the failures in the application.

\=> So they have the different mindset => It’s difficult to work together =>They must have mutual understanding!!!

The programmers are also the testers. They testing their own code to make sure that everything is ok, but it’s so hard because it’s difficult to find their own mistakes. So we need testers.

There are four levels of tester:

• The programmer who wrote the code
• Different programmers
• The Tester
• The testing company

Depending on your level of testing (you can learn more about the levels of testing here), you will choose the right level of tester.

Testers will be happy when finding a good bug, especially it leads to crash the application. But what the others feel?

\=> Maybe the developers will defense it

So how to avoid it?

In my experience,

– The first thing you have to do is checking the bug that you had found carefully, you must assure that you can make that bug again, take note your steps to make it and take a screenshot of it.

– After that, you report that bug to your team, especially the developers. You should focus here, for me, finding a bug is easier than reporting a bug, you can list lots of bugs, but how to make developers fix these, it depends on your bugs and your communication.

+ About the bugs, you have to have experiences in testing that helps you to know which the right bug is – the right bug is the bug that everybody admit, not your thinking. Example: you think that a reading book application should have the landscape mode, just because you use that, but it’s is not a right bug, almost users read books in the portrait mode.

+ What about your communication, the purpose of developers and testers is making a good product according to the user specification. So your communication should be shown that message. The purpose of finding bugs is to show the problem to the developer, not to criticize or complain. So when reporting bugs, you should use “Should change something” instead of “Must/ Have to change something”, “It’s not true” instead of “It’s false/wrong”…. You can use some tools to manage and report the bugs like Trello, Scrumwise…Example, when you use Trello : In your card, the title should be short and show the main idea of that bug; you should give the full description about this bug and how to make this bug step by step in the detail card; attach a screenshot or a gif file about that bug, it will make your bug more clearer; add related members to your card like you, developer, project manager…

If you do all things that I said, I think the developers will pleased when receiving your bug report.

I hope that this post will help you more. It’s helpful for developers, testers, quality assurance…

Thanks for reading ^_

You have heard a lot about test levels from many sources, but what it’s true? This post will help you to learn more about it.

I have learn more about software testing in this official page: http://www.istqb.org/ .If you want to be good at Software testing, you should learn here.

Now let’s talk about test levels. There’re four level of testing: unit testing, integration testing, system testing, acceptance testing.

• First, unit testing: We also call it as component testing, module testing or program testing. Its purpose is searching for defects in software design and data model, verify the functioning of software, performance or robustness testing (system operates correctly in the presence of exceptional inputsor stressful environmental conditions). Unit testing is carried out by a different programmer there by introducing independence like the programmer who wrote the code, or a different programmer in team. Typical target of this level are functional, non-functional and structural testing. Applying this test level, defects are typically fixed as soon as they are found.
• Second, integration testing: It focus on operating system, file system, hardware, interface. We focus on these to test the communication between component. The best choice is to start integration with those interfaces that are expected to cause most problems. Typical target of testing: functional and non-functional, structural testing. It is carried out by specific integration tester or test team.
• Third, system testing: Its purpose is make sure that the system to be delivered meets the specification and its purpose may be to find as many defects as possible. The typical objects of this testing level are risks and/or requirements specification, business processes, use cases, or other high level descriptions of system behavior, interactions with the operating system, and system resources. The typical target of testing: functional and non-functional, structural testing. Who test it? – specialist testers that form a dedicated, and sometimes independent, test team within development; third party team or by business analysts( use black box).
• Finally, acceptance test: After system test has corrected all defects. We transfer it to customers for acceptance test. The typical target of testing: non-functional (usability), functionality, structural testing. User or customer is responsible for testing in this level. The related work product are testing of backup/restore, disaster recovery, maintenance tasks and periodic check of security vulnerabilities.

That’s all. I wish it can help you more, especially the developers. I am a developer too, but when I study it at school, I don’t know clear about it. If you understand it, you will know what you have to do in each level, who is responsible for each level. This help you to make a good plan in making software.

Good luck! Thank you for reading.

Definition: The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

Look at the picture:

Notice that in the first approach, the final output (step

4) is the only version that can be used by a customer.

1,

2, and

3 can not be used by a customer/end user.

However, if you see the second approach, you can clearly make out that the output at each stage is a usable product. First, just two wheels and a board, then a way to stand and hold on to it.. then a way to sit and pedal .. then a way to automate pedaling (motor).. and finally a product that lets you sit and take many co-passengers as well. This is the MVP approach.

Because it’s a useable product, so user can use it. After a long time, you will receive feedbacks from users. The owner will perfect it, correct mistakes, make it more closer to user, meet user’s need.

You can see lots of successful examples about MVP like Dropbox, Zappos,… And I have a big example about IPhone !

No product survives first contact with customers with its original concept intact. Think of the iPhone – Steve Jobs had no idea of the ways it would be used or the market would evolve. The iPhone 6 bears little resemblance to his plan for the original product and the marketplace is very different.

What Apple did successfully, however, was evolve the product – sometimes leading customers, sometimes responding. Modern product managers have learned from this.

Now, rather than spend billions on your idea of a perfect product, a better answer is to do enough to get it into lots of hands and let people see the possibilities and challenges for themselves. From their involvement comes a host of new uses and the product is much more thoroughly tested than any product development team can do on their own.

The start of this process is the minimum viable product – the simplest product you can create which shows people the possibilities without expensively developing capability you may not need.

And it is the start of a customer-driven re-iteration sequence where customer demand drives the company to refine the MVP prioritising the capabilities the customers actually want. This process is never-ending, but it is a lot cheaper and more sure than sawtooth development. Do you really want an air traffic control system only tested on one airfield and one type of plane? No you want one which all airports have had a hand in developing across a wide range of different conditions. Do you want a car which is totally new from the ground up, or one which has a collection of well tested components, but with a new twist?

We used to live in a take it or leave it society. Customers didn’t matter. Companies would arrogantly release what they thought was right and it was years before it was updated. Think cars in the sixties. A big risk for the companies. What if their new product came second in all the magazine road tests. Sales tank – billions worth of work down the drain.

MVPs connect product with customer.

You can see some successful businesses Some successful businesses starting with MVP

Besides that, in market time, you have to know that: A can of cat food is a Minimum Viable Product (MVP) when you are starving, but it’s highly unsatisfying and unlikely to generate a loyal following (of humans). In an increasingly transactional world, growth comes from long-term customer happiness. And long-term customer happiness comes when customers adore your product or service and want you to succeed. You should be thinking about what it will take for customers to love you, not tolerate you. You want to receive feedbacks from users, but how to attract them, how to make them give feedbacks to your product, that’s a big question ! Today, people just focus on what they like – so how to have a good impression if you just only have a MVP product. And you may meet a big problem that someone will clone your idea :).

That’s all my thought about MVP. There are optimistic things and pessimistic things. You have to understand clearly about your product, what you want, your purpose and DECIDE.