-
Notifications
You must be signed in to change notification settings - Fork 0
Test Automation
Automated tests are an investment and, as with any investment, they need to be planned and discussed as a team.
We consider ourselves DevOps. This implies that everybody has access to the same code and everybody does testing. Our roles aren't based on different automation engineers, leads or architects or managers. But everyone contributes to the quality of the software, everyone is one of the roles specified.
We understand our tools, we stay transparent with all stakeholders and know when a test scripts needs to be updated.
Benefits of Automation include increased software quality, improved time to market, repeatable test procedures, and reduced testing costs:
- reduced regression testing time
- improved testing productivity
- improved testing quality
- reduced QA costs
- consistent test procedures
- can schedule test runs
- Parallel Execution
We consider that the best communication is through code or wiki. That is why code speaks for itself. If the developer/tester/ops is not able to read/modify code, than what is he really testing? That is why, our test communication is done:
- on wiki's
- on the code itself
Tests scripts are also code. We review test cases, scripts and results with all stakeholders. If the script doesn't create value for the stakeholder, than probably he doesn't need it.
Benefits of reviewing test scripts:
- team transparency
- find issues early
- collective code and test ownership
- universal naming conventions
Just because test runs are passing doesn't mean anything unless the test is maintained properly. Maintenance is an ongoing job, with every build, iteration and release. Tests should be dynamic. We create new test cases and update old tests for each sprint.
Everybody should know the value we produce. It is easy to learn the basic aspects of a tool, but is difficult to master it. That is why, the last day of the sprint is only for demos and retrospectives.
It's not over until the customer uses the services, and even after that. We make sure that any issue or concern that the product has after delivery, we addressed it first in a Test Case, which is automated while and with development. A new release is available as quick as possible. That is why we correlate the MTTR to Test Cases.
A completed Test Script is a script that can be re-used with minimal touch. We report the risk for upgrades by the amount of LOC to the Test Scripts. A test script is not over when it leaves the tester's hands, but when it doesn't have negative input from the Support team.
Jenkins, Maven, Grunt,
We use JUnit, xmlunit, NUnit, Cucumber, Selenium, unittest, Test::Unit, Jasmine.
We use Selenium. Selenium is an Open-Source multi-browser tool for Web UI automation. All browsers, all versions are equally supported. Test script can be developed in any programming languages.