Thomas Edison was the first person to call a technological defect a ‘bug’ back in 1877.He was implying that an imaginary insect was the cause of all the trouble he was having while creating a new telephone design. Many years later, the first software bug was found - and this time, it was an actual bug! On September 9 of 1947, a team of computer scientists reported the first software bug in the form of a moth trapped in one of the computers at Harvard University. Fascinating, right? Somewhere along the line, people realized that these bugs needed to be dealt with, and so software testing has taken quite a journey over the years. Let’s take a look!
Before 2000's
1. Code de-bugging line-for-line
Software testing is not hundreds of years old, but its history might go back further than you would think.
The first software test team was formed in 1958 by Gerald M. Weinberg while working as a manager for Project Mercury, the first human spaceflight program in the United States.
By 1967, the topic was starting to pick up and IBM published a white paper with the title "Evaluation of the Functional Testing of Control Programs". This was one of the first calls for a disciplined approach to software testing and probably stemmed from the frustration of spending hours debugging code by inspecting it line for line.
2. The start of manual testing
The NATO Science Committee was quick to follow in 1968 with a topic of discussion at the Software Engineering Conference: quality assurance for software products.
Testing took place but not necessarily in a planned or sequential way.
In 1976, the focus shifted to reducing the cost of maintenance and fixes
3. Basic test documents and exploratory testing
In 1983, the first version of the IEEE 829 Standard for Software Test Documentation was published. It included documents intended for use across eight defined stages of software testing and at the time it was an incredibly exciting development.
After-2000s
1. Continuous Integration and scripted manual testing
In 2000, Martin Fowler wrote the first version of the paper Continuous Integration: a groundbreaking moment in software testing history. Fowler was already discussing topics such as self-testing code, automated build scripts, and the importance of automation in order to find integration errors as quickly as possible.
2. Context-driven testing, Saas, and Agile
The third wonderful thing from 2001 was the publication of the Agile Manifesto. We don’t need to tell you how popular the Agile software development and delivery approach is. From here, a community of devoted users grew that embraced Agile principles and continues to do so today.
3. Test-driven development
In 2002, another buzzword in software testing was created when Kent Beck published his book Test Driven Development (TDD). It outlined the software development technique in which tests are written before the functionality is coded.
2003 saw the foundation of theAssociation for Software Testing, and by 2005,SoapUI was released to SourceForge as a tool for web service testing.
2007 introduced another software testing standard, ISO 29119.
2009 saw the First Agile Testing Days conference and a strengthened testing community.
In 2012, the first Let’s Test Conference was held, and in 2013 the Society for Software Testing was founded.
Why does the necessity for test automation arise?
In terms of traditional software development, testing is completed at the end of a development cycle. However, in today’s software landscape, we see more companies moving to a continuous delivery model. As a result, the software is constantly in development and must always be deployed continuously. That’s where continuous testing comes in to ensure quality at every stage.
Ensuring high quality is the most crucial part of this continuous testing model. The speed at which development and testing also occur matters if something fails; it slows down the release of new products/features. Test automation can help save time and manage those testing needs, including the different tests covered and optimizing testing activities to deliver faster.
Automation testing is a game-changer; the ability to run many test cases automatically and conduct so many validations makes it a critical weapon for any QA Engineer. Although automation is here to help testers focus on other activities such as Exploratory testing or creating efficient test cases, the intention is not to replace testers. Instead, we need to consider it a powerful ally during our agile testing.
The rise of Test automation tools and frameworks
1. Selenium
Selenium is primarily a framework for automating web applications for testing purposes but not limited to just that, compelled by Selenium Web driver, Selenium IDE, and Selenium Grid; it is one the most popular for web automation.
2. Selenium Web Driver
The heart of Selenium uses browser automation APIs provided by browser vendors to control the browser and run tests. It is as if a real user is operating the browser.
3.Selenium IDE
It records the users’ actions in the browser for you, using existing Selenium commands, with parameters determined by the context of that component.
4. Selenium Grid
The parallelism of Automation allows you to test in different machines across different platforms. Able to run tests in parallel on multiple machines and manage different browser versions and browser configurations centrally
5. Cucumber
Cucumber is a cross-platform that reads executable specifications written in plain text and validates that the software does what those specifications say. The specifications consist of multiple examples or scenarios. Then, Cucumber verifies that the software conforms with the specification and generates a test report indicating the status of every scenario. Cucumber uses Gherkin grammar rules to pursue these validations that make simple text structures (Given, When, Then) for Cucumber to know the scenarios.
Conclusion
Test Automation is a necessity in today’s Agile environments. Whether you work for a tech company or a highly regulated government entity, as we mentioned initially, I prefer the dreams of the future to the history of the past. Still, we need to know the past to reshape our present and future. It does not matter if you use an open-source Test framework or some codeless testing tools. The idea is to perform Test Automation smarter.