Software projects require a significant investment in testing to improve quality and efficiency throughout the development process.
This is extremely important in an agile environment where testers and developers are rapidly interfacing new and existing features.
It’s critical new features don’t break what has already been built.
Test engineers will run manual or automated tests to make sure bugs and broken source code is not released into production.
Manual Vs. Automation Testing
Manual testing is performed by a human sitting in front a computer carefully going through the application clicking through links and buttons, filling out forms, trying various input combinations, comparing the expected behaviors and recording results. It is repeated frequently during agile development cycles, but is often slow, inefficient and critical bugs are missed. These oversights can be very costly.
Automation testing executes pre-recorded and pre-defined actions to ensure fast, frequent testing. Once created, automated tests can be run over and over again at no additional cost and are much faster than manual tests. This type of testing environment compliments the agile development process. New test cases are generated continuously and can be added to existing automation in parallel to the development of the software.
An example of this would be a team is building a new product from scratch. For each development iteration, you have to verify new requirements and implement new features while ensuring what you built in prior development cycles continues to work properly. This is where automation testing shines; it not only acts as a safety net between old features and new software bugs, but more importantly, it frees up developer time so they can focus more effort on the building of the product.
Once automated tests are created they can be extended to perform tasks impossible with manual testing.
Selenium:
In 2004, Selenium was introduced. Selenium allows you to automate what an actual user does within the application. It opens a browser (Chrome, Firefox, or IE), navigates to a page, click links and buttons and fills out forms. It automatically executes every task you can imagine a real user would perform.
Here is one of the example C# codes used with Selenium. This code will perform the following tasks:
1. Open Chrome
2. Navigate to Google
3. Type a search phrase into the text field
4. Submit a form
5. Wait 5 seconds to see if the correct page displays
using System.Threading;
using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;
using System;
namespace SeleniumSample
{
class Program
{
static void Main(string[] args)
{
IWebDriver driver = new
ChromeDriver(AppDomain.CurrentDomain.BaseDirectory);
driver.Navigate().GoToUrl("http://www.google.com/");
IWebElement element = driver.FindElement(By.Name("q"));
element.SendKeys("Google");
element.Submit();
Thread.Sleep(5000);
driver.Quit();
}
}
}
When an automation test fails you can quickly identify and correct the error. Less time finding bugs, more time fixing them.
Conclusion:
Automation is a great way to build a more efficient and scalable testing environment, but it is definitely not a set it and forget solution. Instead of relying 100% on one or the other, use a combination. For example, if an automation test fails you’ll need to manually identify the cause, implement a fix and run the test again.
Automation will not find all the bugs and cannot be a complete replacement for manual testing.
When deciding what tests to automate first, their value vs. the effort to create them needs to be considered. Test cases with high value and low effort should be automated first. Test cases with frequent use, changes, and past errors – requiring low to moderate effort setting up the test environment – are good candidates for automation.
Automation is typically feasible on larger more complex projects. Automation cuts execution time, while additional resource costs are absorbed into the scope of the project.