How do you test your software's basic functionality before and after major changes?

Each unit test should focus only on a single piece of functionality or behavior. This makes it easier to isolate issues when tests fail and ensures that tests are concise and specific. Ensure that your tests cover both expected (positive) and unexpected (negative) scenarios. This includes testing boundary conditions, error handling, and edge cases. Unit tests should execute quickly to encourage developers to run them frequently. Slow tests can lead to decreased test adoption and slower development cycles. Write clear and descriptive test names that convey the purpose of the test and the expected outcome. A well-named test can serve as documentation for the code.

Before Major Changes: Unit Testing: Test individual components or functions to ensure they work correctly in isolation. Integration Testing: Verify that different components or modules work together as intended. Regression Testing: Re-run previous tests to ensure existing functionality hasn't been broken. After Major Changes: Unit Testing: Re-run unit tests to ensure that the new code hasn't introduced bugs. Integration Testing: Test the interactions between the newly changed components and existing ones. Regression Testing: Re-run a comprehensive suite of tests to ensure existing functionality is intact. Performance Testing: If applicable, test the software's performance to ensure it hasn't degraded due to changes.

Gone are the days when unit testing was only associated with developers. With a more collaborative approach followed these days and using ATDD/TDD framework approach, testers can perform the unit testing in collaboration with developers to test the system efficiently. Doesn’t matter what stage of code change you are in, unit tests are an essential and the stepping stone to dive further into more detailed STLC phases!

Unit testing is a crucial element in the software development process,serving as the first line of defense against bugs and issues.Its importance lies in its ability to meticulously assess individual components or units of code in isolation.By doing so,it enables early detection and rectification of errors, promoting code reliability and maintainability. Unit tests also act as a safety net, guarding against regressions when new code is added or existing code is modified. They enhance developer confidence, facilitating agile development and fostering a culture of continuous integration and continuous delivery (CI/CD).Ultimately, unit testing plays an integral role in ensuring the overall quality, stability, and efficiency of software systems

Unit tests are not a one-time affair; they are an ongoing commitment. Before embarking on any major changes to your software, running your unit tests is a crucial step. This ensures that the existing functionality remains intact. However, it doesn't end there. After implementing changes, it's imperative to rerun your unit tests. This post-change testing serves as a safety net, helping you identify any unintended consequences. It ensures that the alterations haven't disrupted the previously tested units or introduced new issues.

Integration testing is a massive part of the software testing routine. Although each software module is unit tested, defects still exist for various reasons: The software modules' interface with the database might contain errors. External hardware interfaces, if any, can produce errors Insufficient exception handling has the potential to create issues. Errors in the seamless operation of the individual modules. Understanding the architecture design of the application plays a significant role when you prepare the Integration Test Strategy. The modules need to be precisely prioritized, which will help you build an incremental strategy with minimal risks.

When changes involve interactions between different software components, perform integration testing to ensure the seamless operation of these components. Typically, testers develop automated integration tests that can be executed both before and after changes to verify system stability and proper integration flow.

In my opinion, especially when your software is based on microservices architecture, API testing becomes even more crucial. Along with integration testing, API testing is a vital component for evaluating the seamless interaction and data exchange between software components through application programming interfaces (APIs). API testing ensures the reliability of communication protocols, request-response mechanisms, and validation of data integrity.

When organizing integration tests, having a clear understanding of the functionality areas affected by the change can greatly assist in crafting effective test cases.

Integration testing holds a pivotal role in the software development lifecycle by validating the interactions between various components or modules within a system. Its significance lies in the identification of issues that may arise when different units, which work flawlessly in isolation, are integrated. Integration testing helps uncover interface conflicts, data exchange problems, and other compatibility issues early on, preventing these issues from snowballing into critical defects during later stages. This form of testing ensures that the integrated parts of a system collaborate seamlessly, offering a holistic view of the software's functionality.

Always create test environments that closely mimic the production environment, including hardware, software, databases, and network configurations. Keep a detailed record of configurations for your test environments. Document the versions of software, libraries, and dependencies used, as well as any configuration settings. This documentation helps replicate the environment accurately for future testing cycles. Be mindful of data privacy and security concerns, especially when dealing with sensitive data in test environments. Anonymize or pseudonymize sensitive data to protect user privacy and adhere to data protection regulations like GDPR.

Testing before and after major changes is an iterative process, and it's essential to have a well-defined testing strategy, including automated testing where possible, to maintain software quality and reliability.

System tests are the slowest and can be flaky, making them challenging to debug. For example, in a service-oriented architecture, where components may be released separately multiple times a day, it can be difficult to pinpoint when a specific test breaks. Moreover, frequent changes, deployments, and outages in the staging environment can lead to test failures, and these failures are costly due to the resource-intensive nature of system tests. To address these challenges, it's important to keep in mind the software testing pyramid and prioritize other levels of testing. Instead of letting the system test suite grow uncontrollably, consider focusing on lower levels of testing, such as component and unit tests.

System testing is a comprehensive testing phase in the software development life cycle where the entire software application is tested as a whole, rather than individual components or modules. The primary goal of system testing is to evaluate whether the complete software system functions correctly and meets its specified requirements before it is deployed to end-users or clients. System testing is done before Major changes in below forms: 1. Requirements Validation 2. Baseline Performance. 3. Risk Mitigation 4. User Experience 5. Regression Prevention And after Major Changes: 1. Change Validation 2. Stability Check 3. Performance Assessment 4. Compatibility Verification 5. User Experience 6. Regression Testing 7. Risk Reduction

In my perspective, system testing serves as a holistic evaluation of the entire software system, treating it as a single entity. Running system tests before major changes verifies the software's performance and user satisfaction. Post-changes, re-executing system tests is essential to validate the software's sustained quality and usability.

Regression testing on changes is a given. The key lies in how you plan the regression tests. Start with dependency mapping to understand the various forward and backward dependencies of the features there by allowing you to gauge the blast radius of a defect. It will allow you to understand the impact and likelihood of occurrence of the defects and give you an idea of exactly what tests features are impacted and what tests you should be running as a part of your regression tests. Quite often, it is observed as a practice that the entire regression suite is run however that may not be in the best interest of time. Dependency mapping is a smart way to pin point change ripples guiding you to the exact tests that need to be run in regression.

Regression testing definitely helps inspect an application after any major code changes. The first thing is to understand the Impact of the code change and do impact analyses. If you have an automated regression suite available - trigger a run to save some time and do some exploratory testing on the application while your automation suite is being run. If not, switch to manual testing focusing on business critical functionalities of your application and test those as part of your regression. You can also retest the high priority business critical bugs logged earlier in your release to gain some confidence on the changes!

You can be very effective in regression testing without automated tools. The key is to understand what needs to go through regression testing and apply risk-based approach and impact analysis and isolate existing functionality/modules which did not have any underlying code changes and as a result no potential impact. One should understand the difference between full regression testing, limited regressing testing and focused regression testing. Work with developers to understand potential impact of their code changes. Developers knows better than anyone the code their changing and impact of the changes.

Impact analysis is the key and it should not remain restricted to functionality. In my experience we should test it across platforms browsers, devices as per plan. And while developers will definitely tell us what all areas of the application are impacted for us to define our regression test we would know from our knowledge of the application where are the dependencies and also the other important aspect is the test data we use for our the regression tests. It's important to keep a holistic view to the regression tests and thus there is so much focus on automation so that we can do lot of exploratory testing and other aspects manually to ensure complete coverage

Can we agree that regression testing is rather a chronological stage than a type of testing? It is reusing some/all artifacts from the testing types described above. It can follow a protocol like the one Brijesh described in his comment, but it's not a type, per se. If I think of the attention we normally give to it, regression testing is more about what to run now, than how to test.

Design a lean and agile smoke test suite that will give rapid feedback on the stability of the application after a change is deployed. These are good candidates for automation to take over to make them repeatable and consistent.

Smoke tests give you valuable insight on testability of the build. If smoke is failing QA should reject the build, thus avoiding pitfalls of testing on unreliable build

Smoke testing is a critical initial step in software testing, focused on quickly evaluating the software's fundamental functionality. Its primary purpose is to identify major defects that could impede basic operations. By conducting a brief assessment of key features, smoke testing determines if the application is stable enough for further, more detailed testing. It acts as a gatekeeper, preventing the allocation of resources to in-depth testing if significant flaws are detected. This is particularly valuable in agile development, where swift feedback is crucial. Smoke testing helps catch major issues early, reducing the time and cost of troubleshooting later in the development process.

Smoke testing is a preliminary testing method to check whether the basic functionalities of a software application are working properly after major changes. Here's how to conduct it:- Identify Core Functions - Determine the most critical functions of the software Create Smoke Test Suite - Develop a suite of basic automated tests covering these core functionalities. Run Tests Pre-Change & Implement Changes- Execute the smoke test suite. Analyse Results - If the smoke tests pass, proceed with more exhaustive testing. If they fail, halt further tests and address the issues. Continuous Integration - Integrate smoke testing into the continuous integration pipeline to automatically run tests after each change is made.

Definition provided here for Smoke testing is true as per the books. Practically teams have moved on to leveraging select few and critical end to end user journeys as part of smoke testing suites which are mostly automated and executed regularly as part of the pipeline to verify every build and in production. As the application architecture has adopted API driven or microservices driven the focus of smoke testing has also moved towards API which now allows to go beyond few test cases to validate a large number of critical end points using API test automation. The reason for that is you expect a smoke test run to complete in 20 min, with API test automation you can validate all critical end points in that time frame.

User acceptance testing validation is typically taking place manually without any automated tools as participants are business users and stakeholders and not technical or professional testers. The goal is to concentrate more on usability aspect of the application and user experience/user friendliness for the new functionality and enhancements of the release/sprint.

I think it is really important to add the "end user" perspective into the UAT phase rather than allowing development team to derive or contribute. That enables and provides the real feedback.

I agree with what is mentioned in the article and also to add on, the one thing I have found extremely useful in User Acceptance Testing would be the Mock-Ups and the Use Cases as it makes the testing to be at fast pace at the same time the scope of testing is maintained throughout.

Would like to highlight few pointers which are crucial for UAT : 1) Test cases for should crisp, concise and clear.There should be any ambiguity in the expected outcome defined 2) Unit Testing and SIT should be signed off, before deployment on UAT server 3) Stability of environment - Unstable build not only waste QA effort, but extend Testing cycle which results in delay in terms of Go Love

In parallel to verify high level requirement, UAT team must focus on user experience which will assure new function from the customer/user perspective instead of functional testing. This can be achieved more efficiently if UAT team have good Business knowledge and how end user will perceive the new change.

Before deploying changes, start a focused pre-flight checklist highlighting the modification areas. Use a functionality map to pinpoint "change ripples", identifying altered and nearby impacted areas through a regression suite, fostering a vigilant environment with fewer overlooked bugs. Post-deployment, surpass traditional monitoring by adopting a dual strategy: continuous regression tests and real-time monitoring. Utilize techniques such as A/B testing to gauge user reactions to alterations, alongside predictive analytics to foresee potential system strains. Maintain feedback loops with users to perpetually refine the system, embodying a view of software as a continuously evolving entity.

There is a long laundry list of things Testers and Developers do to make sure the product is tested with optimal coverage. Before even you make any changes, requirement analysis is a must step. The team should go through and ask as many questions as they can. Once we have clear requirements, the team can focus on delivering them. Before and during development: - Unit Testing - Integration Testing - Component Testing - Code review - Static code analysis - Virtualisation After Usability Testing Functional & Exploratory Testing Performance Testing Security Testing Documentation analysis Regression Once it is deployed: Production monitoring Tools like ELK, Dynatrace

These are some of the key methods I use for manually testing web pages and applications: - Make sure the page looks good on all screen sizes, browsers, and devices that are available to me. - Run the page through Google Lighthouse to check for issues with performance, accessibility, best practices, and SEO. - Manually check that I can navigate through and use all features of the page using only my keyboard. - Manually check that I can navigate through and use all features of the page using screen reader software.

Before UAT begins, testers should review the functional specifications, requirements and/or User Stories thoroughly to confirm the acceptance criteria for the test cases, especially if the requirements given are too generic, not properly groomed or not well-defined. Test data requirements should also be stated prior to any UAT activity as certain test cases require a very specific set of pre conditions or data which may not be so easily acquired or exists. Ideally, there should also be an established Defect management or triage process in place (using a test management tool such as HPQC/JIRA) where defect duration/ageing can be monitored, RCA given and retested with either closure or failed.

This seems to recommend to cover all the levels of testing. OK. But the most important part is: - performing a impact analysis of the proposed changes, identify the impact areas and classify them / prioritize them. - Identify a Core test suite to be regressed and tested after the proposed change - leverage test automation for regression of existing test repository - Risk based approach can also be used to identify the core areas / basic functions to be tested - Create a Core test repository , a sub-set of the whole test repository and keep augmenting this repository for re-use and trigger automated regression when ever a change occurs.