Hallo experts,
I work at a firm as a SW Tester/Validater
Our company produce autoamtic machines. Recently we are introducing team foundation server for SW development. As a SW tester my tasks include:
Validation of the functionalities of the machines at the real machines.
Reporting bugs and submitting reports.
We don't do any UnitTesting.
We don't do any code analysis.
I browser the internet and read some related stuffs. My impression on my future testing job after introducing team foundation server could be:
Working only with Testing Center
(Perhaps) installing TFS
(Perhaps) creating virtual environments thru lab center
Writing test cases
Carrying out tests manually
Reporting bugs after implemention by developer
Questions:
Are the virtual enviroments useful for SW tests, which needs communication with PLC?
Are the virtual enviroments created on the computer of SW tester or on the server?
Could SW tester templates for test cases prepare? If yes, how could such work be carried out?
For preparation of test plans which events are usually very important?
What's test impact?
Have you taken a course in order to learn TFS or thru selftaught?
Thanks a lot for your insight in advance.
Best regards,
John
If you use TFS, check out Test Manager and Lab Manager. It supposedly integrates perfectly with TFS and you might find it, at least, interesting to know about.
Related
My question is about API automation execution from CI/CD Platforms like Jenkins/Bamboo/Azure etc.
For API automation, it is important to have control on the machine from which the API’s are triggered as we may need to open Firewall for some API’s or add Certificates to java of that machine.
But if I run my API test from the CI/CD agent machines, I can not have that control as those agent machines are maintained by organizational level team who will not entertain any such modifications for the agent machines as they are used by all other teams.
How to overcome this issue? How is actually done?
If anyone out there, faced the same situation in their own company, I want to hear from them.
Thanks a lot for your support.
For my understanding a QA Server is a testing server ... I would like to know what QA stand for and what is the difference with an Staging/Pre-Production server.
Thanks for your time!
I only can answer half of the question. QA stands for Quality Assurance.
Probably the QA server is suitable for testing, measuring the quality of the software/hardware. Probably unit tests/regression tests are meant to run on this server.
The what-you-call staging/pre-production server, is probably a system running the production code used for regular usage of the software/hardware.
I know this is an old post, but I found this while searching so I thought I'd add in some of my own knowledge in case other people come here wanting more information.
Michel got most of it right, but I'd like to correct a few things, if I may.
Firstly, a QA Server usually refers to a machine that handles the QA process, and runs software that helps create environments that can test different code branches, as part of the QA process. This can range from switching environments and checking out a branch, to rebuilding entire machines that match production environments and deploying code to them.
The basic principle of a QA Server is to help create QA environments for testing.
Staging/Pre-Production environments usually refer to one or multiple environments that match, as closely as possible, the production environment that the code will be deployed to. Again, this could be as simple as a machine with software installations that match the production machine's versions, to a mini web server farm where multiple machines and databases are connected together in a way that matches the production environment. The goal, again, is to have a place that matches production, but is not production, and again, for the purposes of testing and Quality Assurance.
I hope that helps anyone that is still unsure of the original questions answered.
There exists no such clear differentiation between staging/production environment. QA Server environment is a platform, where application is deployed for testing purposes, executing functional, security and performance test cases.
Staging is an environment where application is deployed (again for testing purposes) but its maintained that it matches with production environment as much as possible in terms of OS and specifications.
We are looking for an automated testing software for our web application. We need to come up with a solution or software that our non-it staffs could write test cases as well as the developers.
For example I've run through some of them such as: SmartBear, National Instrument and IBM. Most of these guys are MS Windows based or commercial Linux distros which remove them from our list since we are all Debian based.
Any recommendation or guideline would be much appreciated.
Ps. We don't have any budget limit!
You're going to have a hard time getting tooling for non-technical testers to build test cases if you limit yourselves to Debian OS for developing and running the tests on. There's no reason you couldn't have a few Windows system to manage your test suites from -- those would run against your web site just fine, regardless of what stack it's hosted on. That would open you up to the tools you mentioned (and Telerik's Test Studio, the tool I help promote).
Those Windows systems could easily be run via whatever virtualization host you prefer, so you wouldn't even need physical systems to deal with that. You could easily share the same source control repository as your devs, too, since nearly every decent SCM has Windows clients.
If you're unwilling to consider having a few Windows boxes around for your testing, then you'll need to have a look at getting all your testers proficient in APIs and frameworks like WebDriver and Robot Framework. The Pages gem from Jeff Morgan (#chzy) in Ruby would be another option, as would Adam Goucher's Saunter (in Python).
Say you want to create a new environment for a team of developers to build a large website on a LAMP stack.
I am not interested in the knowledge needed for coding the website (php,js,html,css,etc.). This stuff I know.
I am interested in what you need to know to setup a good environment and workflow with test server, production sever, version control, backups, etc.
What would be a good learning path?
As someone who has lead this process at several companies, my recommendation is to gradually raise the "maturity" of your organisation as a software factory by incrementally consolidating a set of practices in an order that makes sense to your needs. The order I tend to follow (starting with things that I consider more basic, to the more advanced stuff):
Version control - control your sources. I used to work with SVN but I'm gradually migrating my team to Mercurial (I agree to meagar's recommendation for a distributed VCS). A great HG tutorial is in hginit
Establish a clear release process, label your releases in VCS, do clean builds in a controlled environment, test and release from these.
Defect tracking - be systematic about your bugs and feature requests. I tend to use Trac because it gives me a more or less complete solution for project management plus a wiki that I use as a knowledge base. But you have choices galore (Jira, Bugzilla, etc...)
Establish routine Testing practices. Unit tests e.g. by using one of the xUnit frameworks (make it a habit to at least write unit tests for new functions you write and old code you modify) and Integration / System tests (for webapps use some tool like Selenium).
Make your tests run frequently, as a part of an automated build process
Eventually, write your tests before you code (Test-Driven Development) and strive to increase coverage.
Go a step forward in your build/test/release cycle by setting up some continuous integration system (to make sure your build and tests are run regularly, at least nightly). I recently started using Hudson and it is great for our Java/Maven projects, but you can use it for any other build process as well
In terms of testing environments, I agree with meagar's recommendations. We have these layers:
Test at developers workstations (should contain a full setup to run your code)
Staging environment: clone your production environment as closely as possible and deploy and run your app there. We also use VMs.
Production preview: we deploy our app to the production servers with production data but in a different "preview" URL for our internal use only. We run part of our automated Integration tests against this server, and do some additional manual testing with internal users
Production - and keep fingers crossed ;)
In terms of backup, at least for your source code, distributed VCS give you the advantage that your full repos are replicated in many machines, thus minimising the risk of data loss (which is much more critical with centralised repos as is the case with SVN).
Before you do anything else, ask your developers what they want out of a test/production environment. You shouldn't be making this decision, they should. The answer to this depends entirely on what kind of workflow they're familiar with and what kind of software they'll be developing.
I'd personally recommend a distributed VCS like git or mercurial, local WAMP/LAMP stacks on each developer's workstation (shared "development" servers are silly) and a server running some testing VMs which are duplicates of your production environment. You can't ask for more specific advice than that without involving your developers.
I start at a new client on Monday. They’re just beginning to do web development (ASP.NET) and I’m going to help them with setting up a proper development environment.
I don’t think I’ll have a say on what type of machines the developers will be using, so this is more of a backend scenario.
So far the main things I’ve come up with include:
Versioning control system (source control).
Bug Database
Doc Repo / Project Management / Tasks
(They are currently using Base Camp by 37 signals, which is a good sign to me.)*
Dev / QA / Staging / Build servers (web, db)
So far this is what I have come up with. I don’t know what budget they have right now, but in your ideal development environment, what else would you recommend that I propose?
Thanks!
You said you won't have input on the machines, but I'd put dual monitors pretty high on the list as far as productivity goes for web development or just computer use in general.
I think, there is no ultimate answer for this. Because each developer has their own opinion - what software they use for VCS, Bug Tracking, etc...
And here is my opinion :)
Ideal for Microsoft Technologies is TFS (Team Foundation Server), which has all the features you want.
And here my list in case you don't want TFS:
Version control system
SVN
Mercurial
GIT
Bug Database / Project Management / Tasks
JIRA
FogBugz
Developers environment
Dual screen
Powerful PC
Quality chair
Whiteboard
Free coffee
This is all very cheap if you compare it to their salary for six months
Development machine: Visual Studio 2008 + VisualSVN/TortoiseSVN + Resharper
Buildserver: Teamcity
LAN testing server: Webserver with build by buildserver + DB with daily copy of live
QA/Staging depends on the project size.