On browsing through the
of @Niels van Reijmersdal answer, I found this written in the README
Markovtsev Vadim implemented a very similar analysis that claims to be 20%-6x faster than Git of Theseus. It's named Hercules and there's a great blog post about all the complexity going into the analysis of Git history.
So well lookup Hercules and go through ...
I believe its a very good practice, In my company we do exactly the same, I assume this is only because of historical reasons (in our case) but in general, you will try to have the smallest number of the system possible so for the medium future, it probably makes sense to unify test automation script with the source code as the same version.
You will need 3 things in order to run JMeter test in Jenkins:
JMeter .jmx script itself
If you have JMeter installed on the machine the minimal pipeline would look like:
git branch: 'your_branch', credentialsId: 'your_credentials', ...
Is it too much to ask the non-technical staff to get familiar with the basics of your repo management tools? This would have a few benefits:
They could keep things simple by using branch, checkout, add, commit, push. It's a new skill for them to learn so they may be happy to get that experience.
You (or other techies) could review their pull requests, and, ...
You should never share your credentials with others. Keep those private. Use the tools provided by git(hub) to give others access to your repository.
How to give others access
You can invite users to become collaborators to your personal repository.
Repositories owned by an organization can grant more granular access. For more ...
What kind of automated testing are you doing? Depending on the answer, there may be products that can do this for you (not sure if that's an option, or if you need it all in house). For instance Sauce Labs looks to have everything from Windows 10 down to XP, with multiple versions of the major browsers.
You will need some steps to get there:
Have you repository system to notify Jenkins about the PR.
That will depend on your system. GitHub and Bitbucket have system to do it.
Build the PR branch.
Report the job status.
You can mitigate conflicts using a branching model like Gitflow, so developers can merge more frequently and only send PR without conflicts....
If you've got different test projects you could use different git repos for each, and then push them to the stb-tester ONE depending on which one you're going to be working on. This is straight forward, but limits you to using the device on one project at a time.
One approach is use git's branching model to allow the stb-tester ONE to hold multiple ...
I think what you are asking is "How do I get Jenkins to trigger a test run and execute my TestNG tests when updates are merged to Git". Is this correct? If not please clarify.
It this is what you are looking for, what you would need to do is set up a Jenkins job that monitors your Git repository. This will show you how to set up polling for a Git repo http:/...
What is the best way to make the framework maintainable by the functional testers that are no technical people?
Cucumber is relatively simple so most folks can pick up the Gherkin step writing pretty quickly.
There are two main issues:
1) Who is going to write the step definitions for the actual code calls?
2) Who is going to maintain the test suite so ...
It should be something like this one (might need some adjustments if you use something other than IntelliJ as your IDE and :
# Created by .ignore support plugin (hsz.mobi)
### Java template
# Mobile Tools for Java (J2ME)
# Package Files #
# virtual machine crash logs, see http://www.java.com/en/download/help/...
Step for fix issue:
Remove repo from GitHub Desktop
Logout from your github account [File > Options]
File > Add Local Repository
Repository > Repository Settings and change to https URL [Important tweek]
It started working back for me.
The big advantage of synchronizing both the source code and the test code version is that you can easily go back in time within your VCS by using tags (see e.g. Git or SVN), allowing you to qickly check out the sources and tests for a specific version.
Personally, I am a huge fan of Semantic Versioning, which you can summarize as follows:
Given a version ...
Code merge permission is all about getting the code to JBGE (Just barely good enough) quality quickly and that component Integration is not borked. Stick to things that tell you the "factory" production line is on fire. Don't add tests that tell you if the Canteen is on fire, that's not blocking production.
If your set of automated tests that ...
The main purpose of code review is learning (yes, cross-validation/static testing is secondary).
Considering there no significative difference of knowledge of different parts of the application between the sub-teams:
You could use code review as a static testing tool within the locals teams (increasing feedback speed) and as a learning tool for the remote ...
Based on your question I understood you are in need of test case management tool where you can execute the manual test cases on every sanity checks and if the test case fails it has to be logged in GitHub where your developer has access to open the issue and fix it.
There are so many test case management tool in the market like Test collab, QA Touch, Test ...
Stop using separate branches for your test code. Test automation code is part of the solution, just like the 'real' , product code. The test code will not have its own version. It will have the same version as the product code by definition. No need to sync 2 versions. That's how we do it and we've never done it in another way.
In my opinion, a wonderful idea.
As the version progresses, it will be necessary to make changes and adjustments so that the actual code of the automation will also increase the number of versions.
If there is transparency to customers it looks much better and makes an order.
Update what was decided at the end, interesting :)
Yes git is a good option.
There is nothing like best, it's totally on you how you are implementing it. There are many other open source version control tools available you can consider:
There is a major issue with having a lot of branches (and features) waiting for approval by clients. Mainly if clients do not test immediately and accept the work, the branches will not be merged into the main branch. This is a problem because other features will want to depend on this work and merging branches will become a real drama when your branches ...
I would suggest that you do not use git feature branches for this and instead build this functionality into the application itself.
For controlling deployment you should be using tools such as capistrano and docker and processes such as blue-green deploy.
Your answer doesn't indicate what, if any tools or processes you are following so it's hard to advise ...
Many Test Case Management Systems offer some form of version control.
TestRail is one such tool and offers the functionality
TestRail automatically saves the history of your test cases and you
can see the different changes of a test case via the History tab in
the sidebar of the test case pages. TestRail doesn't currently allow
you to execute ...