Development and QA have always shared the same goals but used different tools, management systems, and mindsets. That’s no longer the case. Today, not only are development and QA departments collaborating more, they are doing so much earlier in the development process. As a result, they now need to use a similar set of tools, work under the same methodologies, possess the same skills and adopt the same mindsets in order to succeed. The lines between these two groups are blurring.

This convergence (which I’ll elaborate on more below) has significant implications on software development, so it’s important to understand why it’s occurring and how it will evolve further in the years to come. But furthermore, this convergence represents a major shift in how we develop code, from inception to release. It will require us to fundamentally rethink the how, who, what, where and when of testing, and this is why we founded SeaLights.

Why is it happening now?

We are witnessing a fundamental change in our day to day lives. Almost every service is going through a digital transformation. There is an application for almost every service. As Marc Andreessen stated, “Software is eating the world”. This digital transformation has a huge impact on how software is being developed and delivered.

If we were to attribute this change to a single word, it would be “speed.” Agile Development, Continuous Delivery, DevOps and other methodologies (as well as the tools that support them) are a big part of this culture of speed. At the same time, quality is still of the utmost importance, so testing must now be done far earlier in the process (test design, planning, and automation should start earlier at the requirement phase, and test execution should start in tangent with code development). Also, faster and more frequent software releases demand multiple short iterations, to receive fast feedback and response.

To support shortening QA cycles, early execution of test automation is critical. Test-Driven Development (TDD) is one methodology that enables software development engineers to do just that, in addition to its other advantages. One of the major outcomes of practicing TDD well is that you attain a comprehensive design of your application/components/services and built-in tests to validate your design and user stories (In a future post we’ll elaborate on how we practice TDD at SeaLights). This allows software development engineers to write automated tests first, Unit Tests, Component Tests, MicroServices, etc, and then write the application code. Ensuring that any application code written is testable. As automated tests are written fast and early in the process, their execution time is relatively short and easy to maintain. Just remember to keep test codes simple otherwise, you’ll end up writing tests to test the test.

Learn what your tests DO NOT cover | Download >>

Software Development Engineers vs QA: Who Tests What and When?

Typically, a developer will be responsible for the development of a single component or an element that is critical to the functionality of a larger component (i.e.: MicroService). Tests created by a developer will usually be limited to the unit level. Unit tests are an important factor of any quality equation, as failures on that level will disqualify a release with a defect as early as possible in the SDLC. But quality isn’t just about one unit or feature working as expected, it’s about the quality and functionality of the entire system while ensuring that user scenarios are performing correctly from end-to-end.

This is where QA teams come in. They, have and will always be concerned with quality on a holistic level. Their world often consists of end-to-end testing, integration testing, functional testing in real-world scenarios, and other tests that are exceptionally difficult or impractical to automate. More importantly, unlike the developers who only test their own code, QA teams test code written by multiple people.

That said, QA teams are at a distinct disadvantage compared to developers. CI/ CD and TDD have contributed greatly to developers abilities to keep up with the rising frequency of releases, and to an extent have also ensured quality on the unit test level. However, their impact on QA teams is negligible and even indirectly adverse. They are still writing and executing the same tests as before, in shortening time frames, with the exact same tools and methodologies. The result of which is at best, lack of confidence in the level of quality, and at worst decaying quality.

Where is Testing Going?

Testing needs a breadth of fast automated tests that can be executed early in the development process, and cover more than unit tests. And in order to enhance quality coverage from unit test coverage to functional and user stories coverage, a different mindset is required.

Developers need to adopt a more comprehensive view of quality that encompasses the entire system, not only to include end-to-end user scenarios but also the product business value for the end user. An individual component mindset just doesn’t cut it. To achieve this, developers ( not just development team leaders) will need to collaborate with product teams to understand the customer benefits, expectations, and user scenarios. Documenting and completely understanding user stories is a must. BTW good QA engineers, are all about user stories, customer value and end-to-end testing of the product!

On the other end, QA engineers and testers need to develop new skills in the realm of coding so that they can start testing the code as it is being developed in order to enhance quality coverage by adding lots of automated tests (small, deterministic and easy to maintain). While these aren’t hard-fast requirements yet, it’s important for organizations to get ahead of the curve and to start implementing these practices now. We’re already starting to see an industry trend in this regard, as some organizations are placing a considerable premium on QA engineers who can code.

This convergence of skills and mindsets is the Continuous Testing revolution. An evolution that will place higher value on speed without sacrificing quality.

How are We Going to Get There?

SeaLights is the first cloud-based Continuous Testing platform. Our mission is to bring together development and QA teams, software development engineers and managers in a single cohesive platform that enables high quality while increasing release speed. To do this we’re building the next generation quality management platform that will make quality measurable across all tests, tools, technologies, and environments.

SeaLights is now accepting beta users. So if measuring functional test code coverage, tracking build quality metrics and test statuses, preventing untested code changes from reaching production, and analyzing quality analytic are challenges in your organization, signup today.