It's not clear which repository you are migrating to TFS from? It is also not clear why to use Microsoft technologies (available in view of TFS) when there are repositories that have proven themselves to be excellent? For example GIT, SVN, etc.

But if you really want to use Visual Studio Test Professional, then the Microsoft documentation says that there is such a possibility: https://docs.microsoft.com/en-us/vsts/build-release/test/continuous-test-java

I had a similar situation in one of the projects. A separate test database is created before starting the tests and the structure of the prod database is copied into it and filled with fake data. Then it is removed.

Tests use a mock object to work with a database, where a test database is substituted instead of a prod.

Sometimes you need to run non-destructive tests on existing records in a prod or stage database; or if it is not convenient to update the test data - you can switch the used database.

According to me cases somewhat would be like:

1. Man is using stairs made of concrete to go down (positive)
2. Man is using Stairs made of wood or rope (positive)
3. Man is going down and steps are incomplete (negative)
4. Man is going down via rope and stairs and half way its broken (negative)
5. Man is using rope rope and wood stairs and Rope is not able to hold the weight of man. (Negative)
6. Just a floor above ground no stairs are present (Negative)
7. Man is falling from building (Negative)

I want to be able to resize the Selenium browser window to emulate a phone screen, is there a way to do that? Small enough (340,695)

This is what I have so far, no luck

from selenium.webdriver.common.keys import Keys
from time import sleep

chromedriver_path = '../chromedriver' # Change this to your own chromedriver path!
webdriver = webdriver.Chrome(executable_path=chromedriver_path)
webdriver.set_window_size(340,695) # Makes the chrome browser, mobile viewport
sleep(2)
webdriver.get('https://www.instagram.com/accounts/login/?source=auth_switcher') # Visit Instagram

I had a similar situation in one of the projects. A separate test database is created before starting the tests and the structure of the prod database is copied into it and filled with fake data. Then it is removed.

Tests use a mock object to work with a database, where a test database is substituted instead of a prod.

Sometimes you need to run non-destructive tests on existing records in a prod or stage database; or if it is not convenient to update the test data - you can switch the used database.

It's not clear which repository you are migrating to TFS from? It is also not clear why to use Microsoft technologies (available in view of TFS) when there are repositories that have proven themselves to be excellent? For example GIT, SVN, etc.

But if you really want to use Visual Studio Test Professional, then the Microsoft documentation says that there is such a possibility: https://docs.microsoft.com/en-us/vsts/build-release/test/continuous-test-java

Selenium doesn't have such built-in capabilities. You need to understand that Selenium itself is a kind of wrapper over the JS + Browser API. Any scrolling and pageDown methods are not available from under the box. And you will need to implement them yourself. For this reason, frameworks appear on top of Selenium like EPAM JDI, Selenid, etc.

Manual checks are always safer

Sometimes, when testing a large number of new features, testers forget about even the most important principles in testing and thereby make many strategic and behavioral mistakes in software testing.
In this article, I will remind you of the well-known and basic principles that should not be forgotten when testing any application or new feature.

Basic principles in software testing

Out of the many principles that every tester who is testing software has probably identified for himself, there are the main ones in the opinion of the testers community, which I would like to highlight:

1. Exhaustive testing is impossible by any of the testers. I think that everyone understands that it is simply impossible to test all possible cases and combinations, of course, if this is not a trivial case.
   All cases simply cannot be included in the test suite, as it would take us a very long time and in the end it would not cost us that much effort. If each tester sits down and carefully thinks over all the scenarios and if you give this feature for testing to another tester, then he usually finds a bunch of possible scenarios and cases that can be included. Therefore, in software testing, it is customary to analyze a product or a new feature and then focus testing efforts on more risky and priority cases and areas of our product.

2. Accumulation of bugs. If you take a product and break it down into modules, then during the testing process you will notice that the main part of the bugs lies in one or several product modules, therefore, the effect of the accumulation of bugs can be noted. As a rule, this can be observed in completely different products. In order to effectively test our product, you should distribute your testing efforts according to the real density of bugs in the product modules, but if we are testing for the first time, then in proportion to the expected density. Over time, the bugs accumulation trend can change from module to module. This should be monitored and effort redistributed in further testing.

3. Effectiveness of early testing. It is very important to start testing as early as possible and to anticipate possible mistakes that the developer can make.
   Before developing and testing a particular product, you should find out all the specifics, possible conflicts in the specification, the impossibility of a new feature to interact with another module, make sure that the tester, developer and product owner equally correctly understand how this will be implemented. Remember, the earlier bugs are found, the cheaper it is to fix them.

4. The pesticide paradox. If, after writing test cases, we run them many times, then ultimately these cases will not help us find new bugs. Therefore, there is a practice in testing when the test cases are revised and modernized in order to catch some new bugs. Test cases can become more complex, be versatile so as to cover all the components, modules of our product, which in turn will help us find more interesting and new bugs.

5. Testing depends on our product. There are many programs, products, and each of them should be approached individually in terms of testing. In some, more effort in testing is needed for security, in some for usability. Therefore, you should not row all products with the same brush and test according to any one template.

6. Testing shows the presence of bugs in the product, but not their absence. Many people think that if the new functionality has passed the testing stage, then that's it - there are no more bugs. Therein lies the erroneous judgment. Testing only reduces the likelihood of bugs in the product. Therefore, during the testing process, many bugs can be missed and this does not mean that if the product has been tested, then now this product is 100% working correctly.

7. The product is well tested and there seem to be no obvious bugs, then this is a good product. Sometimes while testing and looking for functional bugs, we forget to look from the other side and ask if the user needs it. If this feature does not meet the user's expectations and needs, then no matter how high-quality our product is, this is not so important.

so the goods and their number may be different. I am trying to write a generic function. that is, we know the products, quantity and prices, parse it from the answer and know that the discount should be 10% for> 3, I'm trying to write a function that would return true or false. just don't know the syntax

I didn't understand your idea. I just need to check that if there are more than three products, a discount is added, right? Why two tests? While pm.test ("The amount is calculated correctly", function () {var jsonData = pm.response.json (); let sum = 0; jsonData.transaction.order.products.forEach (item => {sum + = item.quantity * item.product.price;}); if (jsonData.transaction.order.totalQuantity> = 3) {if (jsonData.transaction.order.totalSum === sum * 0.9) {return true;}} return false;});

I am sending a request to purchase an item. In the body is transmitted for example

    "products":[
            {
                "id":"1",
                "quantity":3
            },
            {
                "id":"5",
                "quantity":2
            }
        ]

In the body of the response:

"order": {
            "id": "",
            "user": {
                "id": ,
                "email": ""
            },
            "products": [
                {
                    "product": {
                        "id": "1",
                        "description": "",
                        "name": "",
                        "price": 100,
                        "iamgeUrl": ""
                    },
                    "quantity": 3
                },
                {
                    "product": {
                        "id": "5",
                        "description": "",
                        "name": "",
                        "price": 500,
                        "iamgeUrl": ""
                    },
                    "quantity": 2
                }
            ],
            "totalQuantity": 5,
            "status": "paid",
            "totalSum": 1170
        }

Objective: using Postman to test that the discount (10% for more than 3 product units) is considered correct. The problem is that the product can be 1, or maybe more and also with quantity. How to write this logic, please tell me?