Functional Vs Non-Functional Testing

 Functional Vs Non-Functional Testing

1. What is Functional Testing?

Functional testing is a type of testing which verifies that each function of the software application operates in conformance with the requirement specification. This testing mainly involves black box testing, and it is not concerned about the source code of the application.

Every functionality of the system is tested by providing appropriate input, verifying the output and comparing the actual results with the expected results. This testing involves checking of User Interface, APIs, Database, security, client/ server applications and functionality of the Application Under Test. The testing can be done either manually or using automation

2. What is Non-Functional Testing?

Non-functional testing is a type of testing to check non-functional aspects (performance, usability, reliability, etc.) of a software application. It is explicitly designed to test the readiness of a system as per nonfunctional parameters which are never addressed by functional testing.

A good example of non-functional test would be to check how many people can simultaneously login into a software.

Non-functional testing is equally important as functional testing and affects client satisfaction.

3. Difference between Functional Testing and Non Functional Testing

Functional Testing	Non-functional Testing
It verifies the operations and actions of an application.	It verifies the behavior of an application.
It is based on requirements of customer.	It is based on expectations of customer.
It helps to enhance the behavior of the application.	It helps to improve the performance of the application.
Functional testing is easy to execute manually.	It is hard to execute non-functional testing manually.
It tests what the product does.	It describes how the product does.
Functional testing is based on the business requirement.	Non-functional testing is based on the performance requirement.

Read More

Unit Test vs Integration Test

 Unit Test vs Integration Test.

1. What is the Unit Test?

Unit Tests are conducted by developers and test the unit of code( aka module, component) he or she developed. It is a testing method by which individual units of source code are tested to determine if they are ready to use. It helps to reduce the cost of bug fixes since the bugs are identified during the early phases of the development lifecycle.

2. What is Integration Test?

Integration testing is executed by testers and tests integration between software modules. It is a software testing technique where individual units of a program are combined and tested as a group. Test stubs and test drivers are used to assist in Integration Testing. Integration test is performed in two way, they are a bottom-up method and the top-down method.

3. Difference Between Unit Test and Integration Test

Unit test	Integration test
The idea behind Unit Testing is to test each part of the program and show that the individual parts are correct.	The idea behind Integration Testing is to combine modules in the application and test as a group to see that they are working fine
It is kind of White Box Testing	It is kind of Black Box Testing
It can be performed at any time	It usually carried out after Unit Testing and before System Testing
Unit Testing tests only the functionality of the units themselves and may not catch integration errors, or other system-wide issues	Integrating testing may detect errors when modules are integrated to build the overall system
It starts with the module specification	It starts with the interface specification
It pays attention to the behavior of single modules	It pays attention to integration among modules
Unit test does not verify whether your code works with external dependencies correctly.	Integration tests verify that your code works with external dependencies correctly.
It is usually executed by the developer	It is usually executed by a test team
Finding errors is easy	Finding errors is difficult
Maintenance of unit test is cheap	Maintenance of integration test is expensive

Read More

Regression testing Vs Retesting

 Regression testing Vs Retesting

1. Retesting

Retesting là một quy trình kiểm tra lại các testcase failed trong lần cuối cùng thực hiện test. Nói chung, tester tìm bug đó trong quá trình kiểm thử và assign lại cho Dev fix. Sau khi Dev fix xong thì đẩy lại cho Tester kiểm tra lại. Quá trình liên tục này được gọi là Re-testing.

Retesting có nghĩa là kiểm tra lại. Khi bạn lặp lại một kiểm thử thì đó chính là retest. Bạn có thể test lại chức năng của phiên bản hiện tại, một bug đã fix, chức năng của phiên bản trước đó hay một test case bạn vừa thực hiện, vv…

Việc re-test này chỉ thực hiện kiểm thử ở chỗ đã xảy ra lỗi trước đó, tức là trước đó lỗi ở đâu thì sau khi sửa mình sẽ test lại đúng chỗ đó.

2. Regression testing

Regression testing – kiểm thử hồi quy: là một loại kiểm thử phần mềm để đảm bảo rằng việc sửa lỗi, hay sửa đổi, cập nhật chức năng không làm sinh ra lỗi mới liên quan đến các phần được sửa đổi đó. Tức là việc này có thể test lặp lại những phần mà trước đây đã từng test rồi, và mục đích ở lần này là để phát hiện liệu phần sửa đổi kia có là nguyên nhân gây ra lỗi hay không.

Thông thường, ta sẽ thực hiện regression testing khi:

• Ứng dụng có thêm một function mới nào đó
• Có yêu cầu thay đổi (Change Requirement)
• Sau khi sửa lỗi
• Sau khi sửa lỗi hiệu năng
• Môi trường ứng dụng thay đổi (VD: Chuyển đổi Database từ MySQL sang Oracle…)

3. So sánh Retesting với Regression testing

REGRESSION TESTING	RETESTING
Kiểm thử hồi quy được thực hiện để đảm bảo các thay đổi không ảnh hưởng đến các chức năng hiện có.	Kiểm thử lại được thực hiện để đảm bảo rằng các test case failed trước đó đã pass khi các bug được sửa
Kiểm thử hồi quy được thực hiện để xác minh xem liệu có chức năng hiện có nào bị ảnh hưởng hay không, liên quan đến sự thay đổi đó.	Kiểm thử lại được thực hiện trên việc bug log trước đó đã được sửa.
Tùy theo tình hình dự án, regressiton testing có thể được thực hiện song song với retesting.	Retesting được đánh giá có độ ưu tiên cao hơn so với regression testing, nên thường được thực hiện trước regresstion testing.
Verify defect không thuộc kiểm thử hồi quy	Verify defect là một phần của retesting.
Ta thường thực hiện kiểm thử tự động với regresstion testing, thực hiện manually có thể tốn nhiều chi phí và thời gian.	Ta không thể thực hiện tự động với những case cần retest.
Regresstion testing được biết đến như là một loại kiểm thử chung chung.	Re-testing là một kiểu kiểm thử có kế hoạch.
Việc thực hiện test này có thể thực hiện trên cả những test case đã từng pass trước đó.	Re-testing chỉ thực hiện trên những test case fail.
Regresstion test case được đưa ra dựa vào mô tả chức năng	Thực hiện re-testing với cùng bộ dữ liệu test, môi trường test.

Read More

Stress Test, Performance Test, LoadTest

 

Stress Test, Performance Test, LoadTest

1. Stress Test là gì?

Stress test là quá trình xác định khả năng duy trì một mức độ hiệu quả nhất định trong các điều kiện không thuận lợi của máy tính, mạng, chương trình hoặc thiết bị. Nói dễ hiểu hơn thì stress test giúp kiểm tra tính ổn định của hệ thống.

Quá trình này có thể bao gồm các bài kiểm tra định lượng được thực hiện trong phòng thí nghiệm, chẳng hạn như đo tần số lỗi hoặc sự cố hệ thống. Thuật ngữ này cũng đề cập đến đánh giá định tính các yếu tố như tính khả dụng hoặc khả năng chống lại các cuộc tấn công từ chối dịch vụ (DoS). Stress test thường được thực hiện cùng với quá trình kiểm tra hiệu suất tổng quát hơn.

Khi tiến hành stress test, một môi trường bất lợi được cố tình tạo ra và duy trì. Các hành động liên quan có thể bao gồm:

• Chạy một số ứng dụng sử dụng nhiều tài nguyên trong máy tính cùng một lúc
• Cố gắng hack vào máy tính và sử dụng nó như một zombie để phát tán thư rác
• Làm tràn ngập một máy chủ bằng các e-mail vô dụng
• Thực hiện nhiều nỗ lực đồng thời để truy cập vào một trang web
• Cố gắng lây nhiễm virus, Trojan, phần mềm gián điệp hoặc phần mềm độc hại khác vào hệ thống.

Tình trạng bất lợi được làm cho xấu dần đi cho đến khi mức hiệu suất giảm xuống dưới một ngưỡng tối thiểu nhất định hoặc hệ thống hoàn toàn ngưng hoạt động. Để có được kết quả hữu ích nhất, các yếu tố riêng lẻ sẽ được lần lượt thay đổi từng cái một. Điều này giúp có thể dễ dàng xác định các điểm yếu và lỗ hổng cụ thể.

Ví dụ,Một máy tính có thể có nhiều bộ nhớ nhưng khả năng bảo mật lại không tương xứng. Một hệ thống như vậy có thể chạy nhiều ứng dụng đồng thời mà không gặp sự cố, nhưng dễ dàng gặp sự cố khi bị tấn công bởi tin tặc.

Stress test có thể tốn thời gian và khá tẻ nhạt. Tuy nhiên, một số người làm nhiệm vụ stress test thích nhìn một hệ thống bị “sụp đổ” dưới các cuộc tấn công ngày càng dữ dội hoặc khi thay đổi những yếu tố khác nhau. Stress test có thể cung cấp một phương tiện để đo lường sự suy thoái, khả năng duy trì chức năng hạn chế của một hệ thống, ngay cả khi một phần lớn của nó đã bị xâm phạm.

Khi quá trình kiểm tra đã gây ra lỗi trên hệ thống, yếu tố cuối cùng của stress test là xác định mức độ hay tốc độ mà một hệ thống có thể phục hồi sau một sự kiện bất lợi.

2. Khi nào sử dụng Stress Test?

Stress Test trên web hay ứng dụng là điều rất quan trọng với những trang web hay ứng dụng về những sự kiện lớn như bán vé cho một buổi hòa nhạc nổi tiếng với nhu cầu cao của người dân. Vì vậy, điều quan trọng là kiểm tra thường xuyên với khả năng chịu tải của hệ thống. Điều này cũng giúp bạn chuẩn bị cho các tình huống bất ngờ, dành nhiều thời gian hơn và nguồn lực để khắc phục bất kỳ sự cố nào.

3. Performance Test là gì?

Performance Test là một loaị kiểm thử để xác định tốc độ của máy tính, tốc độ mạng hoặc thiết bị. Nó kiểm thử hiệu suất của các thành phần của một hệ thống bằng cách truyền các tham số khác nhau trong những kịch bản test khác nhau.

4. Khi nào sử dụng Performance Test?

Performance Test được thực hiện để kiểm tra hiệu suất của máy chủ trang web, cơ sở dữ liệu và mạng. Nếu bạn đang áp dụng phương pháp thác nước, thì điều quan trọng là bạn phải kiểm tra từng lần phát hành phiên bản mới. Tuy nhiên, nếu bạn đang sử dụng cách tiếp cận phát triển phần mềm nhanh, thì bạn cần kiểm thử ứng dụng liên tục.

5. Load Test là gì?

Load Test là quá trình mô phỏng độ chịu tải thực tế của bất kỳ ứng dụng hoặc trang web nào. Nó kiểm thử cách ứng dụng hoạt động trong điều kiện hoạt động bình thường và hoạt động hiệu suất cao. Loại kiểm thử này được áp dụng cho những dự án gần đi đến giai đoạn hoàn thành.

6. Khi nào sử dụng Load Test?

Load Test được thực hiện để xác định hệ thống có thể quản lý, xử lý lệnh của bao nhiêu người dùng. Bạn cũng có thể kiểm tra các tình huống khác nhau cho phép bạn tập trung vào các phần khác nhau của hệ thống. Giống như trang chủ hoặc trang web thanh toán của bạn để thử nghiệm mức tải của web. Nó cũng giúp bạn xác định cách xây dựng và duy trì trong hệ thống.

7. So sánh Performance Test, Load Test và Stress Test

PERFORMANCE TEST	LOAD TEST	STRESS TEST
Bao gồm cả Load Test và Stress Test	Là một loại của Performance Test	Là một loại của Performance Test
Giúp tạo ra thiết lập chuẩn và tiêu chuẩn cho ứng dụng	Giúp nhận ra giới hạn của hệ thống, thiết lập SLA của ứng dụng và kiểm tra hệ thống có khả năng chịu tải như thế nào	Kiểm tra xem hệ thống hoạt động như thế nào khi quá tải và cách hệ thống phục hồi khi xảy ra lỗi
Mục đích của Performance Test là tạo ra hướng dẫn về cách hệ thống hoạt động khi ở điều kiện bình thường	Tạo ra những kịch bản khi hệ thống hoạt động quá tải	Stress Test nhằm đảm bảo rằng khi hoạt động trong điều kiện tải cao trong một khoảng thời gian cố định sẽ không bị crash
Việc sử dụng tài nguyên, khả năng đáp ứng và độ tin cậy của sản phẩm được kiểm tra ở phương pháp kiểm thử này	Các thuộc tính được kiểm tra trong một bài kiểm tra tải là hiệu suất hoạt động lúc cao điểm, số lượng máy chủ và thời gian phản hồi.	Loại kiểm thử này kiểm tra thời gian phản hồi ổn định, v.v.
Trong Performance Test, giới hạn tải bao gồm cả dưới và trên ngưỡng nghỉ.	Trong Load Test giới hạn tải là ngưỡng ngắt.	Trong Stress Test giới hạn tải là trên ngưỡng nghỉ.
Ví dụ: Kiểm tra nhiều người dùng cùng một thời điểm, kết nối HTTP hoặc kiểm tra thời gian phản hồi thích hợp.	Ví dụ : Kiểm tra trình xử lý từ bằng cách thay đổi một phần lớn data, kiểm tra máy in bằng cách truyền dữ liệu nặng. Kiểm tra máy chủ mail với hàng ngàn người dùng đồng thời.	Ví dụ : Đột nhiên tắt và khởi động lại các port của một mạng lưới lớn.
Tại sao thực hiện Performance Test?	Tại sao thực hiện Load Test?	Tại sao thực hiện Stress Test?
Để kiểm tra xem ứng dụng đang hoạt động chính xác hay không	Tìm ra lỗi mà không thể tìm ra với bất kỳ phương pháp thử nghiệm khác. Chẳng hạn như rò rỉ bộ nhớ, lỗi quản lý bộ nhớ, tràn bộ đệm, v.v …	Nó giúp các đơn vị kiểm tra hệ thống khi xảy ra lỗi.
Để phù hợp với nhu cầu hoạt động của doanh nghiệp	Để phù hợp với nhu cầu hoạt động của doanh nghiệp	Để đảm bảo rằng hệ thống có sao lưu dữ liệu trước khi xảy ra lỗi hay không
Tìm, phân tích và khắc phục các vấn đề về hiệu suất	Để xác định độ ổn định của một ứng dụng	Để kiểm tra xem bất kì trục trắc nào làm ảnh hưởng xấu đến an ninh hệ thống hay không
Xác định tất cả phần cứng để đưa ra dự kiến tải phù hợp.	Để kiểm tra xem cơ sở hạ tầng hiện tại có đủ để chạy ứng dụng hay không.
Thực hiện kế hoạch về nhu cầu đáp ứng năng lực trong tương lai của ứng dụng	Số lượng người dùng đồng thời mà một ứng dụng có thể hỗ trợ và khả năng mở rộng để cho phép nhiều người dùng truy cập vào nó

Read More

4 giá trị cốt lõi và 12 quy tắc của Agile

 

4 giá trị cốt lõi và 12 quy tắc của Agile

Trong khi Agile manifesto nói đến 4 giá trị cốt lõi của Agile, thì Agile Principles đề cập đến các định hướng, giúp cho team triển khai dễ hàng hơn hơn khi áp dụng Agile trong công việc. Vậy thì 4 giá trị cốt lõi và 12 quy tắc của Agile là gì? chúng ta cùng đi tìm hiểu

1. Bốn Giá Trị Cốt Lõi

    1. Individuals and Interactions Over Processes and Tools
        Cá nhân và tương tác hơn là quy trình và công cụ

    2. Working Software Over Comprehensive Documentation
        Phần mềm hoạt động tốt hơn là tài liệu đầy đủ

    3. Customer Collaboration Over Contract Negotiation
        Hợp tác với khách hàng hơn là đàm phán hợp đồng

    4. Responding to Change Over Following a Plan
        Ứng phó, phản hồi với các thay đổi hơn là làm theo kế hoạch

2. Mười Hai Quy Tắc Agile

-1-. Customer satisfaction through early and continuous software delivery
    Ưu tiên sự hài lòng của khách hàng thông qua việc trao đổi và bàn giao liên tục Khách hàng sẽ cảm thấy hài lòng khi họ nhận được sản phẩm làm việc đều đặn thay vì chờ đợi thời gian kéo dài giữa các lần releases

-2-. Accommodate changing requirements throughout the development process
    Chào đón việc thay đổi trong suốt quá trình phát triển Tránh sự chậm trễ khi có yêu cầu thay đổi requirement

-3-. Frequent delivery of working software
    Delivery sản phẩm thường xuyên Chuyển giao phần mềm sử dụng được định kỳ, từ một vài tuần đến một vài tháng, với một thời gian ngắn hơn.

-4-. Business people and developers must work together daily throughout the project.
    Khách hàng và đội phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án.

-5-. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    Xây dựng các dự án xoay quanh các cá nhân có động lực. Tạo cho họ một môi trường và hỗ trợ họ những thứ cần thiết và tin tưởng họ để công việc được hoàn thành.

-6-. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    Phương pháp hiệu quả nhất là truyền tải thông tin đến vào bên trong đội phát triển là hội thoại mặt-đối-mặt.

-7-. Working software is the primary measure of progress.
    Phần mềm làm việc là thước đo của quá trình.

-8-. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    Các quy trình Agile thúc đẩy sự phát triển bền vững. Các nhà tài trợ cho dự án, các nhà phát triển và người dùng cuối có thể duy trì một tốc độ vô hạn định.

-9-. Continuous attention totechnical excellence and good design enhances agility.
    Forcus liên tục đến kỹ thuật xuất sắc và sự thiết kế tốt giúp nâng cao tính linh hoạt.

-10-. Simplicity–the art of maximizing the amount of work not done–is essential.
    Tính đơn giản – nghệ thuật tối đa hoá khối lượng công vệc chưa hoàn thành – là điều thiết yếu.

-11-. Self-organizing teams encourage great architectures, requirements, and designs
    Các thành viên trong nhóm có kỹ năng và động lực, có quyền ra quyết định cần trao đổi thường xuyên với các thành viên khác trong nhóm và chia sẻ ý tưởng để cung cấp được sản phẩm chất lượng.

-12-. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
    Ở thời điểm kết thúc sprint, Team nên xem lại làm thế nào để hiệu quả hơn, sau đó đồng thuận Tự cải thiện bản thân, cải tiến quy trình, kỹ thuật của mình sao cho phù hợp

Read More

Sanity Testing Vs Smoke Testing

 Sanity Testing Vs Smoke Testing

1. What is Smoke Testing?

Smoke Testing is a software testing technique performed post software build to verify that the critical functionalities of software are working fine. It is executed before any detailed functional or regression tests are executed. The main purpose of smoke testing is to reject a software application with defects so that QA team does not waste time testing broken software application.

2. What is Sanity Testing?

Sanity testing is a kind of Software Testing performed after receiving a software build, with minor changes in code, or functionality, to ascertain that the bugs have been fixed and no further issues are introduced due to these changes. The goal is to determine that the proposed functionality works roughly as expected. If sanity test fails, the build is rejected to save the time and costs involved in a more rigorous testing.

3. Difference between Smoke Testing and Sanity Testing

Smoke Testing	Sanity Testing
Smoke Testing is performed to ascertain that the critical functionalities of the program is working fine	Sanity Testing is done to check the new functionality/bugs have been fixed
The objective of this testing is to verify the “stability” of the system in order to proceed with more rigorous testing	The objective of the testing is to verify the “rationality” of the system in order to proceed with more rigorous testing
This testing is performed by the developers or testers	Sanity testing in software testing is usually performed by testers
Smoke testing is usually documented or scripted	Sanity testing is usually not documented and is unscripted
Smoke testing is a subset of Acceptance testing	Sanity testing is a subset of Regression Testing
Smoke testing exercises the entire system from end to end	Sanity testing exercises only the particular component of the entire system
Smoke testing is like General Health Check Up	Sanity Testing is like specialized health check up

Read More

Software Life Cycle Models

                     SOFTWARE LIFE CYCLE MODELS

1. Waterfall Model

• Waterfall Model is the oldest SDLC Mode
• It resembles how the water fall flows from up side to down side
• It will proceed Phase by Phase
   All the requirements should be ready to proceed to other next phases
• Testing team is not involved from the beginning stages, hence defect fixing becomes time consuming
• and costly
• Any changes in Requirements, Design or Defects to be fixed, we have to moved back to respective
• phases and again come down
• Takes lot of time to see the working product

Advantages of Waterfall Model

• Quality of the product will be good.
• Since Requirement changes are not allowed , chances of finding bugs will be less.
• Initial investment is less since the testers are hired at the later stages.
• Preferred for small projects where requirements are feezed.

 Disadvantages of Waterfall Model

• Requirement changes are not allowed.
• If there is defect in Requirement that will be continued in later phases.
• Total investment is more because time taking for rework on defect is time consuming which leads to 
• high investment.
• Testing will start only after coding.

2. V-model

•  In the Phase by Phase models, we have to recheck the previous phases if we find any defects in testing which is lately introduced in the SDLC
• V Models solves this problem as Testing is introduced from the beginning itself
• Frequently changed requirements are not addressed in this Model

Advantages

• Testing is involved in each and every phase.

Disadvantages

• Documentation is more.
• Initial investment is more.

3. Spiral Model

Spiral Model is iterative model.

• Spiral Model overcome drawbacks of Waterfall model.
• We follow spiral model whenever there is dependency on the modules.
• In every cycle new software will be released to customer. 
• Software will be released in multiple versions. So it is also called version control model. 

 Advantages of Spiral Model

•  Testing is done in every cycle, before going to the next cycle.
•  Customer will get to use the software for every module.
•  Requirement changes are allowed after every cycle before going to the next cycle.

 Disadvantages of Spiral Model

•  Requirement changes are NOT allowed in between the cycle.
•  Every cycle of spiral model looks like waterfall model. 
• There is no testing in requirement & design phase. 

Read More