Glossary useful terms

• Test-Driven Development (TDD): test-first software development practice in which test cases are defined and created first, and subsequently executable code is created to make those tests pass. The failing tests are constructed to pass as development proceeds and tests succeed
  • Automated tests created before the code is written to validate that we need that code
• Acceptance Test-Driven Development (ATDD): test-first software development practice in which acceptance criteria for new functionality are created as automated tests. The failing tests are constructed to pass as development proceeds and acceptance criteria are met
  • Tests, either automated or manual, that validate business functionality
• Behavior-Driven Development (BDD): agile software development practice adding to TDD the description of the desired functional behavior of the new functionality
  • An automated test that validates a particular behavior that you want your application to have
• Test-AutomationAutomating: tests is not only a way to increase the quality of a product, it also helps to reduce cycle time. If you see test execution as one form of feedback, automated tests help to get this feedback much earlier. This lowers the effort of fixing issues and allows to deliver releasable increments much faster
• Testing in Production: What sounds like a very dangerous approach can help not only to reduce cycle time but also make your tests more reliable. It means to execute various tests right in the production environment. To reduce the risk of affecting production operations with untested and failing functionality, various technologies can be used to make the new functionality only available to the test process or a very small set of users while other users will use the previous functionality. The change will be rolled out to all users once the test was successful. This practice will help you to get rid of various test stages like QA, UAT, Staging etc. And as the tests run in the real production environment, you can eliminate the risk of using a test environment that behaves slightly different from your production environment
• A/B Testing: extends the idea of hypothesis driven development by evaluating two or more different implementations to find out which one works best. Usually this is done by having different implementations and then route a part of our users to each of them. This allows to measure which implementation better supports the expected user behavior. A/B Testing is often combined with Feature Flags and Application Telemetry
• Unit Test: low-level technical test focusing on small parts of a software system that can be executed fast and in isolation. The definition and boundaries of a ‘unit’ generally depends on the context and is to be agreed upon by the Developers
• Smoke Testing is a software testing process that determines whether the deployed software build is stable or not. Smoke testing is a confirmation for QA team to proceed with further software testing. It consists of a minimal set of tests run on each build to test software functionalities. Smoke testing is also known as “Build Verification Testing” or “Confidence Testing.”

In simple terms, we are verifying whether the important features are working and there are no showstoppers in the build that is under testing.

It is a mini and rapid regression test of major functionality. It is a simple test that shows the product is ready for testing. This helps determine if the build is flawed as to make any further testing a waste of time and resources.

• Blue-Green Deployment: is a practice that helps reducing down-times while upgrading the system to a new version. It has other positive effects like fast rollbacks in case of emergency. It uses two identical environments. One environment (called blue to differentiate it from the other identical one) is handling all requests and executing all production operations. The other environment (green) can handle software updates and configuration changes without impacting production. Even tests can be executed on the green environment without risk. Once the green environment is ready, all requests are switched over to this one and it becomes the new blue environment. The previous blue environment at the same time becomes the green one and can be used for the next update
• Architectural Spike, it is a short, timeboxed effort dedicated to “proof of concept” – in other words, checking whether the approach the team hopes to use will work for the project
• Risk-Based Spike, is a short, timeboxed effort that the team sets aside to investigate – and hopefully reduce or eliminate – an issue or threat to the project. These short experiments to investigate risky portions of the project are a key tool for risk management
• Continuous Delivery: a software delivery practice similar to Continuous Deployment except a human action is required to promote changes into a subsequent environment along the pipeline
• Continuous Deployment: a software delivery practice in which the release process is fully automated in order to have changes promoted to the production environment with no human intervention
• Continuous Integration (CI): agile software development practice popularized by Extreme Programming in which newly checked-in code is built, integrated and tested frequently, generally multiple times a day
• Continuous Testing: Traditional approaches of quality assurance are often based on getting all implementation finished before verifying the latest build of the product before delivering it to production. In contrast continuous testing is a practice of integrating testing as a fundamental and ongoing part of development. It helps to identify and fix issues much earlier and so lowers risk drastically. Continuous testing is especially powerful if combined with practices like test automation, clean code and others which help to reduce regression testing efforts