Tag Archives: system

System Testing and End to End Testing

Posted on by
Reply

 

Software Testing And End To End Testing

What’s the difference between system testing and end to end testing? This sometimes shows up on a list of common software testing questions, so it must occasionally be asked in interviews. It’s a bad question though, because in most organizations, system testing and end to end testing mean the same thing.

If you are asked this question during an interview, how should you answer?

First, define system testing. System testing is testing of the entire, complete application to ensure the finished, integrated application meets the functional and system requirements.

Second, explain that in most organizations (perhaps including the ones you’ve worked at previously), end to end testing means exactly the same thing.

Finally, explain that there is another meaning for end to end testing, but this is less commonly used. This second meaning is testing an individual workflow in the application from beginning to end. For example, in an email application, this might mean logging in to the app, opening a new email, responding the email, and closing the app.

In summary: when asked about the difference between system testing and end to end testing, explain that system testing is the testing of the completed, integrated application to ensure its compliance with requirements. End to end testing is usually just another name for this process.

Types of Software Testing

Posted on by
1

Types of Software TestingWhat are the different types of software testing?

If you’re asked this software testing question during an interview, first list some of the different categories headlined below. Be prepared to explain a little bit about each of the different types of software testing to show the interviewer you have a broad knowledge of software testing.

White Box vs. Black Box Testing

These are probably the two most famous types of software testing.

The difference between them is the level of insight that a tester has into the program under test.

White box tests mean that the tester has some insight into the inner workings of the program. In general, this means access to the code, but it could just be access to API’s or a description of system internals.

Black box testing is testing without this kind of access. In general, this means you know what the program is supposed to do, and you have to check that the program actually does what it should by feeding in input and looking at the output.

Unit vs. Integration vs. System Testing

The difference among the three categories is the level at which the tests are performed.

Unit testing is done at a very low level: typically individual methods or functions.

Integration testing is done at an intermediate level. Imagine that a part of your program has to read in and process an Excel file to represent it in some internal format. A second part of your program takes the internal representation of the Excel file, and does some computation based on it. Both of these parts can be internally complex (for example, consisting of multiple classes), but they are not the whole of your program. Testing that both of these pieces work together as expected would be an example of an integration test.

System testing is done at the system level: making sure that the system as a whole actually does what it should.

Regression vs. Acceptance Testing

The distinction is the objective of the tests (though also when the tests are performed).

Regression testing checks whether a new change broke something that used to work (so the program regresses to an earlier state with worse functionality). In order to test for regressions, you need to have a body of tests that are run regularly (let’s say, daily, or after every code change), and to compare the outputs.

Acceptance testing is performed to check whether the completed program satisfies the specifications as given by the customer. Preliminary acceptance testing is first performed internally by the developers or by a testing team. A second (and hopefully final) step is user acceptance testing, in which the user or customer goes through the program and validates that the program meets the requirements.

Functional vs. Non-Functional

The distinction is whether you are testing what the program does (functional) or how it does it (non-functional).

Functional testing means testing program correctness: the program should do the right thing (and not crash, or give a wrong result).

What other things might you care about besides correctness? Some answers are resource usage, security, and usability. These are all examples of non-functional testing.

Stress vs. Load vs. Performance Testing

Not much distinction here. Generally all three refer to working the system to check how it behaves and whether it might crash, become unusably slow, or eat up crazy amounts of resources.