As I was looking through some blogs for inspiration about a post, I found this very interesting article called “The path to production: how and where to segregate test environments” by June Jung. It is about segregating test environments into stages in order to streamline continuous integration, as incrementally test along each step of production. She proposes a pipeline in which tests are done first locally by the developer (like on their own machine), then in the CI environment (to see if the developer’s code works within the whole application), then in the shared development environment, then run through the QA team, and finally tested in a staging environment before release. The point of all of this is to run the cheapest, fastest tests first, and as long as they pass to start to move to incrementally slower, more comprehensive, and more expensive tests as the process goes on. This way, all of the smaller bugs are caught far in advance, so valuable time and resources aren’t wasted on building and testing the whole application each time a developer is finished with a single method, but only when absolutely necessary. Smaller errors and mistakes will be caught on the way and can be fixed much more easily, keeping production going.
The more layers there are to the testing (within reason), then generally the more productive the development will be, and the more free the application will be from errors. Each of these stages also requires different types of testing. A single developer may write unit tests to make sure that each part of code they are working on will run when implemented into the larger codebase, while QA teams may be looking at UI testing and making sure that the application itself is usable and works properly in the context it is supposed to. This separation allows layers of abstraction to be added to the testing as well, where the developers get to use white box testing and look through the code, but the QA team doesn’t need to know how the code works in order to do their tests.
This might be common sense, but I never really looked that far into, or thought very much about how this kind of structure in a corporate environment might benefit developers and testers alike. I thought it was just an interesting idea, and they layout that was used in the article was very well thought out and articulated, at least as a jumping off point for the integration of this kind of segregated testing.