Travis-ci works with the github.com service, so the first step is to upload your project source code there. Except for minor technical settings (like installing hooks in a repository), the whole process is reduced to describing various options in the .travis.yml file. In it, you need to describe in what language the project is running, which versions of the language you need to use (everything is possible at once), the environment (here is an example of such a file for ruby). This file must be placed in the root of the github repository.

If the configuration is successful, then travis-ci starts continuously testing the project, displaying the current status: red (there were problems during testing), yellow (there are warnings) and green (all tests were successful). In addition to the status, you can see: an error message or a warning if something went wrong; the last commit and its author; build history, etc. In general, the interface is quite informative and understandable. In addition, travis-ci will notify you of problems by email.

This should help u:

from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.by import By

login_btn = WebDriverWait(driver, 500).until(EC.presence_of_element_located((By.XPATH, 'xpath of login button'))) #Waits until the login button is visible.

login_btn.click()

If u don't wanna find the button by its xpath, then u can change By.XPATH to By.ID or By.CLASS_NAME.

When you estimate software testing task you should focus on the following:

• Resources: Resources are required to carry out any project tasks. They can be people, equipment, facilities, funding, or anything else capable of definition required for the completion of a project activity.
• Times: Time is the most valuable resource in a project. Every project has a deadline to delivery.
• Human Skills: Human skills mean the knowledge and the experience of the Team members. They affect to your estimation. For example, a team, whose members have low testing skills, will take more time to finish the project than the one which has high testing skills.
• Cost: Cost is the project budget. Generally speaking, it means how much money it takes to finish the project.

I have used White Framework for automating .net desktop applications. That's a good tool that you can add as a reference to your c# test project. MSTest, NUnit, xUnit are just frameworks for executing the test. You can choose any of them for running on Jenkins.

How to properly launch the required environment for testing?

You should prepare several windows build agents with installed all the software needed to run your app. These agents should be connected to Jenkins to be able to run the tests on them

Is there a difference between testing on a 32- and 64-bit OS?

The difference is very small. It exists for C ++ (although problems arise very rarely), but for Sharp, I can't even come up with a scenario to have problems. In general, in your case, you can probably not bother with this.

If I test a product under, for example, Windows 7, should I also test it with the Service Pack installed?

There is definitely no point in wasting time with a service pack. Even with every system, you don't need to test. Choose 2-3 key systems, let's say the smallest supported by your program, up-to-date, and preferably something in between. For example, WinXP-Win7-Win10.

In other systems, it is enough to simply check for problem areas - for example, in Win8 there is no Start button, for it it is worth making an alternative access to the program group. We checked it once, figured out the specific nuances, then it is not necessary to test it further.

Where can I find ISO images of the required OS versions for testing purposes (virtualization in VMware)?

Only on MSDN, of course. Well, or in some non-kosher places, which we will not name.

Travis-ci works with the github.com service, so the first step is to upload your project source code there. Except for minor technical settings (like installing hooks in a repository), the whole process is reduced to describing various options in the .travis.yml file. In it, you need to describe in what language the project is running, which versions of the language you need to use (everything is possible at once), the environment (here is an example of such a file for ruby). This file must be placed in the root of the github repository.

If the configuration is successful, then travis-ci starts continuously testing the project, displaying the current status: red (there were problems during testing), yellow (there are warnings) and green (all tests were successful). In addition to the status, you can see: an error message or a warning if something went wrong; the last commit and its author; build history, etc. In general, the interface is quite informative and understandable. In addition, travis-ci will notify you of problems by email.

There are 4 typical levels of Testing in Software Testing:

Test Levels

Unit Testing

• a module is the smallest functional part of a program or application that cannot function separately only in combination with other modules. However, after the development of this module, we can already start testing and find inconsistencies with our requirements. Unit testing consists of testing this single unit as part of a program, assuming that it is only a unit.

Integration Testing

• the next level of testing, which is carried out after Unit testing. After we have tested our individual modules, we need to conduct integration testing to make sure that these modules work successfully in conjunction with each other. In other words, we test 2 or more related modules to check that the integration was successful and without obvious bugs.

System Testing

• the testing level in which we test an entire system or application that has been fully developed and is already ready for a potential release. At this level, we test the system, the application as a whole, conduct testing on all required operating systems or systems (if a desktop application) and conduct all the required tests such as functional, security testing, usability testing, performance testing, load testing, etc. ...

Acceptance Testing

• after the complete completion of the System Test, the product passes the level of Acceptance Testing, usually carried out by the customer or any other interested parties, in order to ensure that the product looks as originally required and was specified in the product requirements. Acceptance Testing can also be performed after each of the above test levels.

The problem was with my home router
He simply could not handle such a load.
The problem was solved by replacing the router

I can guess based on the cases that we gave to our testers. (We really wrote a special application for this, with bugs, and gave it to testers, but that's the case). The tester's goal is not to find bugs (strange as it may sound), but to test the functionality. Accordingly, the test case does not have to find a bug (especially if it does not exist), it must check that the entire application works as it is intended. A trivial option for authorization:

• Open authorization
• Drive in the name
• Drive in a digit
• Drive in a name of 70 thousand characters
• Drive in "nothing"

And so on .. There may not be bugs here (and should not be), but the key idea is that the functionality works.

Yes, that's a usual situation. Try to gather more info about new functionality function specification from product owner and developers

Well, if you do not have a fairy godmother, then it is obvious that to cover the project quickly enough with tests - you need either more people or more time if the number of people is constant.

It is necessary to convey to each developer the importance of tests, because as practice shows, not everyone understands that it is vital.

It's just as important to start here. You can start simple - check at least all controllers for 500 errors. It is done very simply and quickly - iterate over the array of routes and see the code returned by the client.

For version 3, we can apply, for example, another option for checking the operation of services, by analogy with controllers. You take vital services from the container, pull public methods and expect not 5 **. (well, for 4 and 5, it is of course also applicable, but with caveats if we want to use mocks)

It is also important, in my opinion, to work out the principles of testing with colleagues so that no one starts doing nonsense. At one time I was engaged in complete nonsense, testing private methods in services through Reflection, being sure that this is directly vital, but not realizing that if such a need arises, then this is a problem in the architecture.

Of course, it makes no sense to talk about maintaining a balance between fanaticism and real testing, because it all depends on the experience and the project.

However, my whole message is that in order to start, you have to start. If we are talking about the community, everyone needs to understand the importance of this event, the main thing, of course, is that the team lead, if there is any hierarchy. You also need to immediately write tests for new code. The main thing is to do it. Culture will come a little later, but it will definitely come.