dido:public:ra:xapend:xapend.a_glossary:i:integrationtesting
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
dido:public:ra:xapend:xapend.a_glossary:i:integrationtesting [2020/11/15 01:55] nick created |
dido:public:ra:xapend:xapend.a_glossary:i:integrationtesting [2021/10/03 20:53] (current) 51.222.253.20 ↷ Links adapted because of a move operation |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ===== Integration Testing ===== | ===== Integration Testing ===== | ||
| - | [[dido:public:ra:xapend:xapend.a_glossary | Return to Glossary ]] | + | [[dido:public:ra:xapend:xapend.a_glossary:start| Return to Glossary ]] |
| **Integration Testing** is performed to test individual components to check how they function together. In other words, it is performed to test the modules which are working fine individually and do not show bugs when integrated. It is the most common functional testing type and performed as automated testing. | **Integration Testing** is performed to test individual components to check how they function together. In other words, it is performed to test the modules which are working fine individually and do not show bugs when integrated. It is the most common functional testing type and performed as automated testing. | ||
| - | Generally, developers build different modules of the system/software simultaneously and don’t focus on others. They perform extensive [[dido:public:ra:xapend:xapend.a_glossary:b:blackboxtesting|black box]] and [[dido:public:ra:xapend:xapend.a_glossary:w:whiteboxtesting|white box]] functional [[dido:public:ra:xapend:xapend.a_glossary:v:vendorlockin|verification]], commonly known as [[dido:public:ra:xapend:xapend.a_glossary:u:unittesting|unit tests]], on the individual modules. Integration tests cause data and operational commands to flow between modules which means that they have to act as parts of a whole system rather than individual components. This typically uncovers issues with UI operations, data formats, operation timing, [[dido:public:ra:xapend:xapend.a_glossary:a:api | API]] calls, and database access and user interface operation. | + | Generally, developers build different modules of the system/software simultaneously and don’t focus on others. They perform extensive [[dido:public:ra:xapend:xapend.a_glossary:b:blackboxtesting|black box]] and [[dido:public:ra:xapend:xapend.a_glossary:w:whiteboxtesting|white box]] functional [[dido:public:ra:xapend:xapend.a_glossary:v:vendorlockin|verification]], commonly known as [[dido:public:ra:xapend:xapend.a_glossary:u:unittesting|unit tests]], on the individual modules. Integration tests cause data and operational commands to flow between modules which means that they have to act as parts of a whole system rather than individual components. This typically uncovers issues with UI operations, data formats, operation timing, [[dido:public:ra:xapend:xapend.a_glossary:a:api | API]] calls, and database access and user [[dido:public:ra:xapend:xapend.a_glossary:i:interface|interface]] operation. |
| Source: [[https://www.simform.com/functional-testing-types/]] | Source: [[https://www.simform.com/functional-testing-types/]] | ||
dido/public/ra/xapend/xapend.a_glossary/i/integrationtesting.1605423333.txt.gz · Last modified: 2020/11/15 01:55 by nick
