Author Archives: Ivan Neverov
According to Dictionary.com, “agile” is defined one way as “quick and well-coordinated in movement; lithe.” It’s a great way to describe an acrobat or athlete, but the term also applies to business. Within software development, the definition’s important because “agile” must happen quickly but also be well planned. Agile’s core tenets are to pull teams together in a collaborative, simple, transparent, and flexible manner, so they can work together to produce quality work on deadline.
Agile involves all of the stakeholders in the process (including customers) to put in their “two cents” during production. A crucial part of this process is testing because it needs to be conducted during every stage of the development. The point of this repeated testing is to gather feedback from all of the stakeholder groups, so the final project will best reflect all of their needs and expectations.
Some debates are not easily resolved. Kanban or Scrum? Vim or Emacs? In the world of software, many technical engineering debates are created but never settled. True, most engineering debates can be emotional or reductionist; however, they often have little to do with actual engineering benefits, but everything to do with opinion. So it raises the question: Which testing method is the best?
One thing we can all agree on is that developers of monolith applications (of varying skill levels) have all at some point updated and patched programs, introduced complex logic, which has caused performance inefficiencies, dead code, and piles of technical debt. It makes things that much harder to change or work with, it creates inefficiencies, and naturally, reworking costs more time.
When you write tests against a web page, you need to refer to elements within that web page in order to click links and determine what’s displayed. But if you write tests that manipulate HTML elements directly, your tests will be sensitive to changes in the UI.
A page object pattern wraps a page — or part of a page — with an API allowing to manipulate elements without directly accessing HTML elements.
The cost of maintaining and making even minor changes to your monolithic systems are just far too high, especially with the amount of options we have nowadays. This is why more organizations have considered moving from a single monolithic codebase to more scalable, easier to manage microservices.
Software development companies are under constant pressure to deliver new applications that will satisfy every user’s needs across all devices and locations, preferably at high speed and low cost. Automated testing has become a way to ensure applications are error-free, cost-efficient, and quickly delivered.
Automated testing takes place on several levels of the project:
- Unit testing: Usually performed by developers, the main goal of these tests is to make sure that the app’s components match in terms of functional requirements. For example, a unit test could involve an OOP class or function.
- Component testing: Usually performed by developers, the “component” being tested is a part of the high-coupled logic. For example, authorization, payment processing, and order submission could all be components.
Automated testing has become standard industry practice, saving quality assurance engineers the time and effort required of manual testing while enhancing overall code efficiency and accuracy. It also allows companies to reduce costs while speeding up product release times. These benefits can become especially apparent when developers are testing web applications that have long life cycles like those in the financial industry.
When working on these continuously expanding projects, SDETs (Software Development Engineers in Test) must implement the testing infrastructure and automated tests in such a way that the state of the system can be checked at certain designated intervals. In a sense, these engineers must travel in virtual time. This process can be quite complex and problematic. To avoid testing-related issues when working on projects with long life cycles, SDETs can follow several approaches as detailed in this article. These approaches are implemented in Ruby, but they can easily be converted to any programming language.