How do you test software updates in SDLC?

The testing scope needs to reflect your company priorities, not simply the collection of UX or back office logic deliveries. Company commitments to privacy of data, data handling, security, API management and more become lowest cost when configuration and functionality are scoped into the testing plan "by default". This often means that your organization has a default scoping guidance or template which is customized and evolved for specific projects. This approach enhances consistency and quality, while reducing the burden on project leaders to "cover" corporate priorities each time.

Test cases are usually defined according to the definition of different scenarios for different situations and using additional analysis documents during product production.

Testing software updates within the SDLC is a 2 fold process. The 1st aspect focuses on the New Functionality added to the codebase, be it a minor or major enhancement or a bug fix. These changes require dedicated testing to ensure they meet the desired objectives and don't introduce new issues. The 2nd aspect is Regression Testing. Every update can potentially impact existing functionalities. Based on an impact analysis, you have to decide between a mini regression, risk-based regression, or a full regression test suite. A mini regression focuses on areas directly affected by the new code. A risk-based regression concentrates on the most critical parts of the application. A full regression is a comprehensive test of all functionalities.

Scope also depends on which product feature is being staged. like it is for POC, demo, Alpha/beta testing or internal use only or available for general availability. based on feature stage you add more and more scope and different types of testing.

Testing scope is dependent upon multiple factors and varies from project to project. Some of the major factors to define the scope are: A. Requirements and Design Signed Off. B. Type of Application to be tested - Web or Mobile C. System Component - UI/UX or Backend D. Performance requirements - Web or API under concurrent user load E. Type of Industries Practices- CSV or CSA Validation in case of Life Sciences F. Type of Regulations - Standards like 21 CRF Part 11 or Annex 11 for Life Sciences, GDPR for data collection,FedRAMP for Government Organisations etc. G. Phases of the project and architecture - System Integration Testing with Integrations, User Acceptance Testing before commissioning, Smoke Testing after Prod Migration. #sdlc

A key focus of modern engineering practices is to automate everything. Manual processes in any engineering or testing effort do not scale. Automate the tests so that people can apply the art of testing to the problem at hand.

The focus from others is "automate" everything which I agree is a good general principle. It doesn't mean don't do any manual testing. Use exploration and critical thinking to examine the delivery for quality. Human made it human uses it human still needs to test it.

In short, mature DevOps processes. Testing should be shifted left as far as possible. Not simply having unit tests, but ensuring that unit tests run in the build and must pass before the new artifact is created. Taking that a step further, enforcing code coverage in your build is a great step in making sure the change is developer-tested.

Unit testing is done by developers by writing scripts or may be manually as an initial level check. Rest of the testing is done by QAs. Mostly they do manual testing initially, as automation comes into picture once the application is stable. Testing methodology depends on what phase we are, what tools and technology is supported by the application for various types of testing, Business needs and time provided for the testing. Also it largely depends on what type of application it is and who is our end user.

Choose testing methods like unit testing, integration testing, system testing, and acceptance testing to ensure comprehensive software validation.

Its also important to have one engineering system or 1ES, where everyone knows where everything is that we need. This system should be generic enough to facilitate the planning and execution of any of the needed test tools. There are great platforms out there to do this from Microsoft and Atlassian that integrate with almost all of the test tools out there on the market.

Testing tools can help to automate and streamline the software testing process throughout the SDLC. For automated functional tests, use Selenium, JUnit, or JMeter. These tools help you quickly identify bugs and performance issues in software updates. By incorporating testing tools into your workflow, you can ensure that updates meet quality standards while not delaying development.

Use testing tools such as Selenium and UFT One for automation, Postman for API testing, and JIRA, ADO, and OpenText ALM for bug tracking and project management.

In the world of complex product development, don't be lulled into the false premise of "best practice". Best Practices only work in a simple environment where there is one best way to achieve some outcome. The reality of all product development is that there is not. You need to use emergent practices that suit the situation at hand and adapt to the changing landscape of the needs of the business. In the world of testing, this means constantly shifting left and freeing the folks with critical testing skill to spend more time on the emergant strategies, processes, and practices that with maximise the value delivered.

Ask yourself two questions - first how are you evaluating and measuring quality? Do you know? How do you know that you are doing "well" and can make a defensible case that your team's quality and testing responsiveness is sufficient? Second, just as important is exception reporting - identifying the inevitable challenge when defects make it past quality gates. Use a tiered model where impact and/or quantity drive a risk based depth of root cause analysis. Impactful misses should drive your team to answer the question: how do we reduce or eliminate the gap where this impacted our business or our clients? The question of "what did we discover" is important in testing. Finding ways to find exceptions may be more so.

Take a pragmatic approach and consider all options. Use that mentality to assume the best methods. Adapt your process based upon what happens to it in practice. Theory crafting an approach will always need to be proven.

Not sure if Best practices is the thing but if testers focus on the Seven fundamental Testing principles this would be a Good way to start testing. Also advanced practices like Risk Based Testing Strategy, Test Driven Development (TDD), Behavior Driven Development etc can be imbibed as a part of the overall Testing culture.

Follow testing best practices like writing clear test cases, automating repetitive tests, maintaining thorough documentation, and performing regular code reviews.

I think documention is missed in many projects thinking its not critical but leaders need to explain the importance of documentation as its an important part of audit too.

One important element in execution is Test reproducibility. As a tester it is very important to know whether the defect is reproducible or is it an onetime observation. This helps us in framing a proper response towards defect resolution. Also, its important to maintain a TRDB (Test Results Database similar to KIDB -Known Issues Database). This can serve as a good reference point for future similar issues and can provide a better ROI (Return on Investment) on testing.

From my experience, I've found that reviewing testing results post-software updates in the SDLC is crucial. Evaluating test cases against expected outcomes, identifying any deviations. Scrutinizing regression testing to ensure existing functionalities aren't compromised. Examine compatibility testing for diverse environments. Analyze security testing results for vulnerabilities. Assess performance testing outcomes, noting any bottlenecks. User acceptance testing ensures alignment with user expectations. A comprehensive review involves identifying and prioritizing defects, ensuring a clear understanding of the update's quality and readiness for deployment.

Software update is best tested by running the automated regression suite. If there is disparity then either the application is broken or time to update the automation script.

Review the testing results by analyzing test reports, identifying defects, ensuring all issues are addressed, and validating that the software meets the quality standards.

In my 25 years in the game, I have found that testing requires careful planning, execution, and documentation. Neglecting proper testing can lead to system failures, security breaches, and damage to an organization's reputation. To ensure the success of software updates, organizations should embrace a comprehensive testing strategy that encompasses unit testing, integration testing, regression testing, UAT, performance testing, and security testing. Implementing automated testing, continuous integration, and user feedback mechanisms can enhance the efficiency and effectiveness of the testing process. By following best practices, organizations can minimize risks and deliver high-quality, reliable software to their users.

Implement software updates by integrating code changes, conducting regression testing, deploying updates to production, and monitoring for any issues post-deployment.

Modern software development lifecycles MUST include automation and more automation. Creating a continuous delivery pipeline enables you to minimise risk, validate your assumption, and maximise the business's potential value flow. The work done by people skilled in testing, coding, analysis, and other necessary practices should feed that delivery pipeline in a way that maximises the quality of the input. The automated pipeline should validate the quality of that input so that the customer can quickly validate the value, and we can reduce the time to learn.

Testing software updates within the SDLC is a nuanced process and requires a tailored approach. Understand the Impact of Change or Updates: Prior to initiating testing, it's crucial to analyze the scope and impact of the changes. This understanding will guide the scale and focus of your testing efforts. Decide on the Strategy: One size definitely does not fit all when it comes to testing updates. For bug fixes, focused regression testing around the fixed components is often sufficient. Minor enhancements may require a more moderate level of testing. Major updates, on the other hand, usually demand a comprehensive testing strategy that spans across multiple test levels.

Base any approach on critical thinking and analytical processes. Never assume. Always check. Show value at all times. Standardise where possible. Testing is about the truth not opinion.

Having a well defined testing strategy, I believe, is the most important part of the work. The strategy should detail the environment for the test, scope of what is to be tested and what is out of scope, the use cases, how results will be stored and verified, and very importantly, documentation.