14

Systems testing is often performed against the whole platform, and treats the environment as a black box. system integration testing however, acts upon a subset of the whole system, and may mock other platforms, interact with databases, network sockets etc to evoke appropriate responses from the parts being validated. The objectives of system testing is to ...


9

I've read that if a requirement can't be verified by black-box testing or inspection, then it's not a requirement, but a design specification. I don't think that's true. There are plenty of requirements which are difficult-to-impossible to test with black-box techniques; for example, a client-server application might have a requirement that all ...


8

I totally agree with milinpatel17. There is no specific answer for this. It is up to an individual or a team to decide which format will get their job done in better way for them.


5

There are tools that support this. SmartBear's TestComplete does - you can configure to continue after a failure or to stop after a failure - you'll find some details below about how the team at my previous employer handled dependent tests with TestComplete. I don't consider it a terrible idea - I've worked mostly with large, complex applications where it's ...


5

I prefer to test in isolation, test should not be depended of each other in order to be able to run them on their own. This makes testing a smaller part of the application easier for developers. Also if each test has its own environment to run in you can run tests in parallel without tests conflicting each others runs. There will be some extra overhead in ...


5

In your comment you asked Lets say we have a system C which is combination of A and B (A + B = C). Now i can check perform Integration tests for A, Integration tests for B. After this i need to perform System tests on C which is the result(whole system). Where exactly will SIT come in here? In testing C, but I believe you won't learn much from short ...


4

In my vocabulary system testing would be testing one complete product ( http://en.wikipedia.org/wiki/System_testing ) and system integration testing would be testing combination of products ( http://en.wikipedia.org/wiki/System_integration_testing ). As always, it's good to make sure others are using terms in the same way and in an interview point out that ...


4

It sounds as if you want to avoid giving QA a build that falls apart right away. One way to address this is to add a smoke test to the development cycle. There are other SQA questions that cover smoke testing, e.g. Smoke testing by Dev team. I won't try to repeat that information here. One goal of smoke-testing is to encourage developers to deliver QA ...


4

Personally, as the "service test" is the end-to-end test and the expensive one, I'd just put in some simple values that I know are good. As this is a single test with fixed parameters, I'd just pick some numbers. I'd likely pick different numbers than in lower level tests if they had fixed values, just for the slight increase in coverage. (Though ...


3

Seems that you want to have a tool which can translate requirements/test cases (written by business people with no experience in programming) into executable code. In our practice FitNesse is not that tool. We started with FitNesse, and keep maintaining existing tests and even adding new when feasible, but these tests are written by developers, not business ...


3

The short answer (as others have said) is by any method that works for you. The longer answer is that there are no best practices, only practices that are better or worse in any situation. Some things you can consider: Use version control and maintain branches or labels that match the versioning of the code you're testing. One method I've used ...


3

In testing, there is no such thing as best practice. There is also a good/better/appropriate practice. To manage tests and link them to the requirements, you can do it in several different ways. Mind mapping your test ideas/cases against requirements. Use xmind, freeplane, etc. Make metrics in excel spreadsheets. Use test management tools like TestLink. ...


3

With any kind of framework or database upgrade like this, after I'd covered system sanity and critical path regression, I would go through the release notes looking for any changes likely to impact my application and test around each of those. I'd be particularly careful with these areas, in this approximate order of priority: Breaking changes Deprecated ...


3

Hopefully your interviewer understood that there are no universal definitions for those terms. Here is one interpretation. A system test exercises an entire system, focusing on common workflows rather than edge conditions. Sometimes people refer to individual parts of a system test as an end-to-end test. An integration test exercises interactions between ...


3

Here's my perspective: Unit Testing tests a single unit - usually at the routine level (that is, only one unit of code such as a function is tested). Unit tests are typically code-based, written by developers, and executed whenever the application is compiled or built. Module Testing tests a single chunk of functionality in isolation, such as testing the ...


3

Would you use the same test data as used in the service test, because you have the expected results already available, or would you deliberately choose different test data in order to implicitly test the business logic more thoroughly The short answer: No The longer version: If the business logic is not being tested at the unit test level, then I'd look at ...


2

A good explanation can also be found in this slide: System Test: As soon as an integrated set of modules has been combined to form your application, system testing can then be performed. System testing verifies the system-level reliability and functionality of the product by testing your application in the integrated system. Note: QA team performs System ...


2

System Testing is performed on completed software or application. Integration Testing happens in 2 places - Before System Testing and After System Testing. Integration Testing can be split as Integration and Testing which means you are integrating the unit or components and testing the handshakes between these modules. Once the integration testing is done ...


2

The way I would test this software will be focusing on different areas: unit testing or library: I am not sure whether you will have access to the code or the developers have done some unit test on the components in the software. In this phase, you can test out the functionality of the components in the software easily (without the interaction of the UI, ...


2

If we take a look at the definition of BVT we can't find the statement that BVT belongs to white box testing approach. Just "a short set of tests, which exercises the mainstream functionality of the application software". And for system testing -- "testing conducted on a complete, integrated system to evaluate the system's compliance with its specified ...


2

Does the presented style of cascading tests violate the "one assertion per test" principle? Yes, it does. While the style is quite clean, a disadvantage to your solution is that it becomes harder to run test_login and test_write_post with a different user, for example with one that is already registered. I personally find a better solution is to have ...


2

I realize this question is 4 months old, but given what it's about, I figured I'd add my thoughts as you may still be working on putting this team together and determining roles and all. So it sounds from what you described like the dev team does black-box testing and then the QA team does white-box testing, yes? If that's the case, I see this middle team ...


2

What we currently use in our continuous integration system is the multiple layered environments, which may also cater for your needs. Let me describe it a bit. Dev Environment - Mostly Dev`s localhost setup in which code gets build and unit tested. What we learned here is that involving a tester early on to help with the scenarios helps a huge deal. System ...


2

User246 is right, smoke testing by dev team should give QA team more stable product to test. But I am concerned about your whole approach. You cannot "assure quality by more testing". Better approach (better use of time of all the people involved) is to realize that quality has to be build in, and it is everyone responsibility, not only QA. QA provides ...


2

Copying from the linked issue, you could override type to always return 1 when asked about git. functions --copy type builtin_type function type # mock if test "x$argv" = "x-fq git" return 1 end builtin_type $argv # call original end This should work across a variety of environments, and not depend on where git is installed, nor ...


1

I would proceed in this order: Happy Path Negative Test Cases Edge Cases Implicit Requirements Happy Path: These are based on the functional requirements as described by the requirements doc or the person requesting the feature. This is the most basic ruleset that must govern the system. If this set of rules doesn't work, either the developer or tester ...


1

I guess it depends on what exactly you're trying to get out of the test, but if the time element is merely a trigger for a particular behavior you might see if it can be mocked or stubbed out. So instead of waiting for the actual time to elapse, you could call some mock object to return the expected behavior after the time limit is reached without actually ...


1

The main difference between Acceptance and System testing is that Acceptance testing should be (in ideal world) defined before coding started. It is a suite of requirements/use cases agreed with customer, which must be passed to accept product. It is a part of "business". System test - it is a part of personal responsibility/quality of project QA. So, you ...


1

Try vdbench, it is very flexible and powerful. There are many other file system load generators each with its own ups and downs and with different features, try googling for them.


1

According to me terminologies in testing do not matter much provided the communication between the testers and other stakeholders goes successful. That is, the other stakeholders understand the reports delivered by tester and the tester understands their needs and that of the software correctly. For example build verification testing could also mean to ...


Only top voted, non community-wiki answers of a minimum length are eligible