How to Understand Testing in the Development Lifecycle

Most people treat testing in CI/CD pipelines like a checkbox. Build it. Run a few unit tests. Ship it. But if you have ever run production at scale, you know that testing is not a step; It is the architecture that holds your release process together. Here is the breakdown I wish someone had walked me through years ago: 𝟏. 𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐦𝐞𝐧𝐭 -> This is where we test our code in isolation. -> Unit tests are your safety net. Local UI tests make sure you are not breaking basic visuals. 𝟐. 𝐐𝐀 -> Now the pieces come together. -> Functional and integration tests validate the workflow, not just the parts. -> And those UI tests? Now they are independent. They test what the user will actually see. 𝟑. 𝐒𝐭𝐚𝐠𝐢𝐧𝐠 -> This is where we turn up the heat. -> Load testing simulates real traffic. System testing checks if everything plays well together when it matters most. 𝟒. 𝐔𝐬𝐞𝐫 𝐀𝐜𝐜𝐞𝐩𝐭𝐚𝐧𝐜𝐞 -> Forget formal scripts. -> Here it is all about the vibe check. Does the app feel right? Is the core functionality smooth? Ad hoc smoke tests give early signs. 𝟓. 𝐏𝐫𝐨𝐝𝐮𝐜𝐭 𝐀𝐜𝐜𝐞𝐩𝐭𝐚𝐧𝐜𝐞 -> You simulate a disaster before a real one happens. -> Can your team recover fast? Can your system self-heal? -> You do not want to find that out in production. 𝟔. 𝐑𝐞𝐥𝐞𝐚𝐬𝐞 -> Now we go live. -> But it is not the end; it’s just another loop. -> A/B testing for user behaviour -> Pen testing for security -> System monitoring for peace of mind Testing is not a technical formality. It is how you earn trust in every release. Would love to hear where in this pipeline your team still struggles or skips. Or if you are leading teams, which of these steps changed the game for you? Let’s talk in the comments.

What if testing didn’t wait until the end but happened continuously throughout development? Continuous Testing (CT) brings tests into every stage of the software lifecycle. Where Continuous Integration focuses on code merges, CT ensures a constant stream of feedback—on functionality, performance, security, and beyond. It’s a natural extension of CI/CD pipelines, shifting testing left so problems get caught early. Instead of separate testing phases, you have incremental validations with each new feature or fix. CT can involve automated unit tests, performance checks, security scans, and even dynamic test environments for on-the-fly exploration. The result? Fewer late surprises, more confident releases, and a culture that treats quality as everyone’s responsibility.

Don’t Focus Too Much On Writing More Tests Too Soon 📌 Prioritize Quality over Quantity - Make sure the tests you have (and this can even be just a single test) are useful, well-written and trustworthy. Make them part of your build pipeline. Make sure you know who needs to act when the test(s) should fail. Make sure you know who should write the next test. 📌 Test Coverage Analysis: Regularly assess the coverage of your tests to ensure they adequately exercise all parts of the codebase. Tools like code coverage analysis can help identify areas where additional testing is needed. 📌 Code Reviews for Tests: Just like code changes, tests should undergo thorough code reviews to ensure their quality and effectiveness. This helps catch any issues or oversights in the testing logic before they are integrated into the codebase. 📌 Parameterized and Data-Driven Tests: Incorporate parameterized and data-driven testing techniques to increase the versatility and comprehensiveness of your tests. This allows you to test a wider range of scenarios with minimal additional effort. 📌 Test Stability Monitoring: Monitor the stability of your tests over time to detect any flakiness or reliability issues. Continuous monitoring can help identify and address any recurring problems, ensuring the ongoing trustworthiness of your test suite. 📌 Test Environment Isolation: Ensure that tests are run in isolated environments to minimize interference from external factors. This helps maintain consistency and reliability in test results, regardless of changes in the development or deployment environment. 📌 Test Result Reporting: Implement robust reporting mechanisms for test results, including detailed logs and notifications. This enables quick identification and resolution of any failures, improving the responsiveness and reliability of the testing process. 📌 Regression Testing: Integrate regression testing into your workflow to detect unintended side effects of code changes. Automated regression tests help ensure that existing functionality remains intact as the codebase evolves, enhancing overall trust in the system. 📌 Periodic Review and Refinement: Regularly review and refine your testing strategy based on feedback and lessons learned from previous testing cycles. This iterative approach helps continually improve the effectiveness and trustworthiness of your testing process.

One of the common practices followed in software testing is to allocate 25-30% of the development effort towards testing. However, this method can at times mislead us, particularly when we face seemingly minor changes that unfold into complex challenges. Take, for instance, an experience I had with a retail client aiming to extend their store number format from 4 to 8 digits to support business expansion. This seemingly straightforward task demanded exhaustive testing across multiple systems, significantly amplifying the testing workload beyond the initial development effort—by a factor of 500 in this instance. 💡 The Right Approach 💡 1️⃣ Conduct a thorough impact analysis: Understand the full scope of the proposed changes, including the affected components and their interactions. 2️⃣ Leverage historical data: Use insights from past projects that are similar in nature to make informed testing estimates. 3️⃣ Involve testing experts early on: The sooner they are in the loop, the better they can provide realistic perspectives on possible challenges and testing needs. 4️⃣ Adopt a flexible testing estimation model: Move away from the rigid percentage model to a dynamic one that takes into account the specific complexities of each change. Has anyone else experienced a similar situation? How do you navigate the complexities of testing estimations in your projects? Your insights are appreciated! #softwaretesting #qualityassurance #estimation

If I wanted to crack a QA role at Amazon, Google, or Microsoft with a non-tech background. Here’s exactly how I’d do it, because I’ve done it myself. Yes, I come from an engineering background. But my journey started with a non-tech KPO role, doing work no engineer wants to do. Today, I’m a QA II (L5) at Amazon. So if you’re feeling underqualified for the role, I know how it feels. So here’s what I’d do if I had to start from scratch in 2025: Step 1: Understand how QA actually works Start with the basics: → What is the software development life cycle (SDLC)? → What’s the difference between manual and automation testing? → How do companies test real products? Resources: - https://lnkd.in/dX_g_6BX Step 2: Learn the tools companies expect No one tells you this, but tools > theory in interviews. Start with: → Manual testing tools: TestRail, Jira (for test case management and bug tracking) → API testing: Learn Postman – start testing public APIs like Spotify, FakeStore, etc. → Automation basics: • Learn Playwright or Selenium (start with Playwright, easier syntax) • Use JavaScript or Python — pick one and stick to it • Learn how to write test scripts, selectors, and assertions Resources: https://lnkd.in/d2q5ppnE https://lnkd.in/dMUpuyVd Step 3: Build proof of work Anyone can say they know testing. You need to show it. → Pick any website (e.g., Amazon, Swiggy, BookMyShow clone) → Test key flows like login, checkout, or search → Write test cases in TestRail or Excel → Log bugs in Jira → Use Postman to test APIs → Try automating one simple flow with Playwright Document this on GitHub or Notion. Include screenshots, bug IDs, and videos if possible. Recruiters LOVE seeing real work. Step 4: Add a QA mindset, not just skills The best QAs don’t just follow checklists. They: → Think like users → Catch hidden risks → Question ambiguous specs → Collaborate across teams Practice: Read feature releases from Zomato, Amazon, etc. Ask: What could go wrong? What edge cases would I test? Start building intuition. Step 5: Own your story in interviews Say this proudly: “I come from a non-tech background, but I’ve upskilled myself in testing workflows, tools, and automation.” Talk about your proof-of-work projects. Show you understand user impact, not just test scripts. You don’t need a CS degree to be a great QA. You need: → Product thinking → Tool fluency → Curiosity → And the consistency to start from where you are That’s how I made it to Amazon. That’s how you can do it too. Repost this to help someone who wants to be a QA. P.S. DM me if you want to become a QA with a non-tech background and want a clear roadmap.

Bugs exist in all phases of the software development lifecycle. They become more concrete and less fluid the later we are in the cycle, and the way we observe evolves from pure thought experiment at the beginning to directly manipulating conditions and observable product in the end. There are opportunities early on to prevent propagation of a bug, or physical creation of it by addressing a problem before we lock it into a later phase. Applying relevant rules, guidelines, standards to idea generation and design specification we can remove problems before someone builds them in. Testing early involves far more ambiguity and demands a lot of imagination. You don't have the luxury of trying something to see what happens. At the point of creation, bugs become concrete. We transition from observing them in idea form to observing them in product form. We have to imagine their behaviors early on; we can watch them behave from creation forward. We have to speculate what might happen with an idea, we can know what really happens when the bug has been born of creation. Testing likewise becomes far more concrete. We can directly observe what is happening, manipulate testing conditions, manipulate the system under test. At the same time, the scope of what we can test becomes far larger, and the problem domain rapidly expands toward ambiguity again. There is an important, fuzzy transition between bugs in creation and bugs in product. During creation we observe bugs in the individual parts and pieces as they are built and come together. This is usually the fastest, most efficient mode of testing, with the narrowest lens possible. After the product is assembled, we observe bugs in the whole system running at once. Efficiency flips from working on tiny, small parts to taking advantage of as much happening at once as possible. The feedback loop slows down as the bugs we find are more severe, elusive and consequential. The useful thing is to recognize the potential for finding bugs at all phases of the software development lifecycle, and to know how to change one's testing approach based on the phase. #softwaretesting #softwaredevelopment

Your AI Agent passed all the dev testing -> But your users disagree? 🫣 Most teams treat evaluation as a one-time checkpoint before deployment. But agents degrade silently, dashboards show green on latency and error rates while the agent quietly picks wrong tools and giving subtly wrong responses. 𝗘𝘃𝗮𝗹𝘂𝗮𝘁𝗶𝗼𝗻 𝗶𝘀𝗻'𝘁 𝗮 𝗽𝗵𝗮𝘀𝗲. 𝗜𝘁'𝘀 𝗮 𝗰𝗼𝗻𝘁𝗶𝗻𝘂𝗼𝘂𝘀 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗲. - In 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁: Evaluate at every level: outputs, tool selections, reasoning paths                             - In 𝗖𝗜/𝗖𝗗: quality gates with score thresholds before anything deploys - In 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻: sample live traffic, score it against the same evaluators, detect drift before it compounds. Two practical guides on how to keep consistent standards across the entire lifecycle: 1. Strands Evals: Open-source framework for online/offline evaluation, hierarchical assessment, and simulated multi-turn testing: https://lnkd.in/eVQK5j7A 2. Bedrock AgentCore Evaluations - Managed service for on-demand + continuous production evaluation with drift detection and CloudWatch observability: https://lnkd.in/edfqaEeg Shoutout to my co-authors on these amazing blogs: Ishan Singh Bharathi Srinivasan Jack Gordley Samaneh Aminikhanghahi Osman Santos Jonathan Buck Po-Shin Chen Smeet Dhakecha and our reviewers Maíra Ladeira Tanke Vivek Singh Evandro Franco Mark Roy

Non-tech PMs often struggle with testing concepts. But understanding TDD and BDD has saved me countless hours of rework and team conflicts. ↳ Test-Driven Development (TDD) is: - Writing the test first, then building just enough to pass it. - Like saying "I want to verify payment amount doesn't exceed account balance" when developing payment app. ↳ Behavior-Driven Development (BDD) is: - Creating real-life stories about how people will use your product.   - Like saying "When a user with $100 balance attempts to send $150, they should see an insufficient funds message" 𝗪𝗵𝗲𝗻 𝘁𝗼 𝘂𝘀𝗲 𝘄𝗵𝗶𝗰𝗵 𝗮𝗽𝗽𝗿𝗼𝗮𝗰𝗵? ✅ TDD works best when: → You need precise technical validation → Working with unit and functional testing → Developers or QA write the tests using programming languages Example TDD unit test in JavaScript: ('𝘴𝘩𝘰𝘶𝘭𝘥 𝘳𝘦𝘫𝘦𝘤𝘵 𝘱𝘢𝘺𝘮𝘦𝘯𝘵 𝘪𝘧 𝘢𝘮𝘰𝘶𝘯𝘵 𝘦𝘹𝘤𝘦𝘦𝘥𝘴 𝘣𝘢𝘭𝘢𝘯𝘤𝘦', () => {   𝘤𝘰𝘯𝘴𝘵 𝘢𝘤𝘤𝘰𝘶𝘯𝘵 = 𝘯𝘦𝘸 𝘈𝘤𝘤𝘰𝘶𝘯𝘵(100);   𝘦𝘹𝘱𝘦𝘤𝘵(() => 𝘢𝘤𝘤𝘰𝘶𝘯𝘵.𝘮𝘢𝘬𝘦𝘗𝘢𝘺𝘮𝘦𝘯𝘵(150)).𝘵𝘰𝘛𝘩𝘳𝘰𝘸('𝘐𝘯𝘴𝘶𝘧𝘧𝘪𝘤𝘪𝘦𝘯𝘵 𝘧𝘶𝘯𝘥𝘴'); }); ✅ BDD shines when: → You need stakeholder alignment → Testing user journeys or workflows → Non-technical team members need to understand tests The best part? BDD tests can be written by analysts, PMs, or POs as part of requirements: 𝘚𝘤𝘦𝘯𝘢𝘳𝘪𝘰:  𝘜𝘴𝘦𝘳 𝘢𝘵𝘵𝘦𝘮𝘱𝘵𝘴 𝘱𝘢𝘺𝘮𝘦𝘯𝘵 𝘸𝘪𝘵𝘩 𝘪𝘯𝘴𝘶𝘧𝘧𝘪𝘤𝘪𝘦𝘯𝘵 𝘧𝘶𝘯𝘥𝘴                   𝘎𝘪𝘷𝘦𝘯 𝘵𝘩𝘦 𝘶𝘴𝘦𝘳 𝘩𝘢𝘴 𝘢 𝘣𝘢𝘭𝘢𝘯𝘤𝘦 𝘰𝘧 $100                   𝘞𝘩𝘦𝘯 𝘵𝘩𝘦𝘺 𝘢𝘵𝘵𝘦𝘮𝘱𝘵 𝘵𝘰 𝘴𝘦𝘯𝘥 $150                   𝘛𝘩𝘦𝘯 𝘵𝘩𝘦𝘺 𝘴𝘩𝘰𝘶𝘭𝘥 𝘴𝘦𝘦 𝘢𝘯 "𝘐𝘯𝘴𝘶𝘧𝘧𝘪𝘤𝘪𝘦𝘯𝘵 𝘧𝘶𝘯𝘥𝘴" 𝘦𝘳𝘳𝘰𝘳 As a PM, involving your team in BDD can dramatically improve requirements clarity and reduce rework! ⁉️ Which testing approach do you currently use in your projects?

The Agile Testing Process Workflow is a critical part of modern software development. It's an iterative approach to testing that helps to ensure high-quality software is delivered quickly and efficiently. 𝗛𝗲𝗿𝗲'𝘀 𝗮 𝗯𝗿𝗲𝗮𝗸𝗱𝗼𝘄𝗻 𝗼𝗳 𝘁𝗵𝗲 𝗔𝗴𝗶𝗹𝗲 𝗧𝗲𝘀𝘁𝗶𝗻𝗴 𝗣𝗿𝗼𝗰𝗲𝘀𝘀 𝗪𝗼𝗿𝗸𝗳𝗹𝗼𝘄 𝗮𝘀 𝗱𝗲𝗽𝗶𝗰𝘁𝗲𝗱 𝗶𝗻 𝘁𝗵𝗲 𝗶𝗻𝗳𝗼𝗴𝗿𝗮𝗽𝗵𝗶𝗰: Product Backlog: This is where all the features and functionalities of the software product are listed. User stories are prioritized here to determine what will be included in each sprint. Sprint Planning: In this phase, the team collaborates to define the goals and deliverables for the upcoming sprint. User stories from the product backlog are selected and added to the sprint backlog. Sprint Backlog: This contains a refined set of user stories that will be worked on during a particular sprint. Test Design: Testers design and create test cases to ensure the user stories meet the defined acceptance criteria. Test Execution: During this stage, testers manually execute the designed test cases to identify bugs and defects. Test Automation:  Automated tests are created to save time and resources during regression testing. Regression Testing:  Throughout the development process,  regression testing is performed to identify any bugs introduced by new code. Defects: Throughout the testing process, defects are reported and logged.  The development team then works to fix them. 𝗕𝗲𝗻𝗲𝗳𝗶𝘁𝘀 𝗼𝗳 𝘁𝗵𝗲 𝗔𝗴𝗶𝗹𝗲 𝗧𝗲𝘀𝘁𝗶𝗻𝗴 𝗣𝗿𝗼𝗰𝗲𝘀𝘀 𝗪𝗼𝗿𝗸𝗳𝗹𝗼𝘄: Improved Software Quality: By continuously testing throughout the development lifecycle, the Agile Testing Process Workflow helps to identify and fix bugs early on. Faster Time to Market:  By prioritizing features and working in sprints, Agile Testing helps to deliver software faster. Enhanced Customer Satisfaction: By ensuring high-quality software is delivered quickly, Agile Testing leads to happier customers. 𝗗𝗼 𝘆𝗼𝘂 𝗵𝗮𝘃𝗲 𝗮𝗻𝘆 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲 𝘄𝗶𝘁𝗵 𝘁𝗵𝗲 𝗔𝗴𝗶𝗹𝗲 𝗧𝗲𝘀𝘁𝗶𝗻𝗴 𝗣𝗿𝗼𝗰𝗲𝘀𝘀 𝗪𝗼𝗿𝗸𝗳𝗹𝗼𝘄? Please share your thoughts—your insights are priceless to me.

Already using #TDD for #OperationsResearch projects? You're ahead of 90% of teams. But if you're starting, you need to consider that different kinds of tests have different implications. Let's see a layered pyramid that represents several important aspects of a testing strategy, like: 🕐 Quantity & frequency: Typically, you have more tests at the bottom of the pyramid and fewer as you move up. Lower-level tests run more frequently during development. ⚡ Execution speed: Tests at the bottom are faster to run (milliseconds to just a few seconds) while tests at the top can take minutes or hours. 🔍 Scope & isolation: Lower tests focus on isolated components, while higher tests evaluate entire systems. 🏗️ Cost of creation & maintenance: Tests at the bottom are relatively inexpensive to create and maintain, while comprehensive tests at the top require significant investment. 🔄 Feedback speed: Lower-level tests provide immediate feedback during development, while higher-level tests might run only in nightly builds or pre-release phases. Start implementing from the bottom of the pyramid and work your way up. This approach builds confidence in your foundational components before tackling more complex concerns.