What types of testing do you use in your SDLC project?

So for example, if we are having two functions as fun1 and fun2 as mentioned below: fun1() { int x=fun2(4); System.out.println(x); } int fun2(int y) { int x=x*y; return x; } so, if fun1 needs to be unit tested then, mock of fun2 will be created and and fun1 will be calling that mock. So, we will check functionality of fun1 is working correctly or not.

In SDLC projects focused on Salesforce, we employ a range of testing methodologies to ensure the robustness of our solutions. These encompass unit testing to validate individual components, integration testing to ensure smooth interactions between various modules, and user acceptance testing (UAT) to confirm alignment with requirements. Additionally, we prioritize thorough regression testing to prevent unintended impacts on existing functionality. Through this comprehensive testing approach, we guarantee that our Salesforce solutions are dependable, user-friendly, and tailored to our client's specific needs.

Pros: 1. Early Bug Detection: Catch bugs in early development stages, reducing later costs. 2. Improved Code Quality: Leads to modular, maintainable code structures. 3. Refactoring Confidence: Provides safety net for code changes and refactoring. Cons: 1. Time-Consuming: Requires effort to write and maintain tests. 2. Incomplete Coverage: May miss edge cases and interactions. 3. Maintenance Overhead: Tests need updating as code evolves.

Oftentimes, unit testing is considered an afterthought but should be considered a core development practice. Start by testing complex logic - avoid overtesting simple getters/setters. Use tests as living documentation of functionality. Leverage mocks/stubs judiciously to prevent dependency issues. Focus testing on high-risk areas rather than 100% coverage of happy paths. Promote a shared mindset of quality ownership across the team - don't silo unit testing. Set up CI/CD pipelines to automate unit testing. Most critically, instill unit testing discipline through upfront design considerations, code reviews, and integration into your overall development cadence. Done right, unit testing enables agility and resilience and reduces defects.

This is an area where most of the code related bugs are identified especially in a highly integrated environment with hundreds of integration points. All these points need to be tested and the QA department has to join synergies with their counterparts of the consumers (upstream and downstream dependencies).

How to perform integration testing? 1. Plan: Identify components to test together and decide the order. 2. Test Cases: Design scenarios covering various interactions. 3. Isolate Dependencies: Use stubs or mocks to manage components not ready for testing. 4. Execute: Start with isolated components, then integrate and test logical groups. 5. Capture Defects: Document and fix issues, communicate with developers. 6. Regression: Re-test after fixes to avoid new problems. 7. Incremental: Integrate components gradually to catch problems early. 8. Automate: Use tools for consistent and efficient testing. 9. CI/CD: Include integration tests in your continuous integration process. 10. Document: Keep records of tests, results, and defects.

Approach is very important to integration testing. You could, 1. Group all units together and test as a whole. While this is fast, it should only be used for small systems, as identifying faults can become tedious. 2. Group from the bottom up or top down. This is incremental testing where few units are grouped at a time. This definitely takes a longer time but it’s a much easier and lighter load, which makes identifying faults easier.

System testing is very important phase almost at the end of development cycle. It is important to ensure the test environment we are using to validate the system is closely match to real product if you are using simulated environment. The parameters used in fine tuning the system is most critical in any system and we have to ensure that using the actual real product parameters while you are performing end testing.

Testing the non functional requirements (usability, reliability, availability and performance) the tricky part as these are often ignored in most of the projects which can cause significant business impacting post production incidents. So, it's important to factor in this phase of testing and be open to discuss the code since many projects don't need this phase but we have to be very judicious in choosing which project needs this phase and this has to be a collaborative decision.

Validation testing, which is testing performed by the actual user is missing from this article. All other forms of testing are performed against the requirements captured by the engineering teams, which might be different from the client expectations.

This phase is also optional but these decisions have to be made after a significant amount of discussions between all the stakeholders.

Common issues at UAT is having users repeat testers done in system test. Instead have them focus on real use case scenarios, ask them what would do for real? Build out high level scenarios but don't make them scripted tone encourage discovery. Lastly time box them to 45 minutes and an hour. Long draw out UAT sessions have less value, bordem sets in and compliancy.

Here comes the moment of truth where the functionality is unveiled and a sneak peek is given to a cross section of experienced users that have the ability to catch errors and anticipate any potential errors in areas such as user experience, performance and functionalities.

Like pointed out below this article missed key pieces of testing phases. It's pivotal to have a test strategy devised and approved during the project design. Test cases, traceability matrices and other test artefacts can be produced later. Another point to remember is frequent audit of these phases by an internal audit teams are a good way to identify issues and also bring in new perspectives.

??This article totally missed critical part of testing: ??Unit Integration Testing ??Accessibility Testing ??Performance Testing ??Concurrent Testing ??Real Time Testing ??Smoke Testing ??Sanity Testing

We include Negative testing suites to try and break /validate robustness of Happy path scenarios to surface potential unconsidered bugs or defects.

I’ve found in projects, development mostly focuses on what the system should do. There are times where the negative scenarios should be implemented on what the system should NOT do. A thorough UAT should highlight if the system is doing something it should not.

E2E testing for both SIT Phase and UAT phase. It’s a kind of release readiness testing based on scope specific to each release. Need to identify the exact scope of the release. Need to identify the components that are contributing to the release.