🔉Syam Sasi

My observations on test management are below, organised into levels of competence. I'm hesitant to call them maturity levels. 0. No testers. Developers perform manual and mostly positive tests. The bulk of testing is inadvertently performed by users. A UAT environment is an essential mitigation. 1. Separate test department. Developers still perform manual positive tests, with testers considered a safety net. Siloed testing is build into the organisational hierarchy. Development is delayed by the time to spot issues and the time to perform rework. These cycles may happen multiple times, with multiple handovers. UAT environment still required. 2. Separate test teams. Both testers and developers fall within the same management hierarchy. Testers still considered a safety net. Testing remains siloed, due to requiring a handoff to a separate team. Issues present when using a QA department still remain: this level is a change of management approach only. 3. Testers are dev team members. Dev and test roles remain distinct and independent. Testers may also loosely be part of a test team formed by testers from multiple dev teams. Whilst testers and developers begin true collaboration, it is limited by mostly siloed working. Consequently, there are still handoffs and rework delays. A UAT environment may still be required, but is no longer considered essential. Developers may write low-level tests, or may not. 4. Testers shift left, developers write their own tests. Developers write tests that are closer to the code, such as unit and integration tests. Testers still write system or end-to-end tests. The boundaries of dev and test roles are more flexible. Handovers and rework cycles continue with reduced impedance. Limited opportunities for continuous delivery. 5. No testers. Developers are supported by quality coaches, the former testers. Developers write all the tests. No handovers. Developers take full responsibility for the code they produce, because there is no third party to act as a safety net. No UAT environment needed. Genuine opportunities for continuous delivery. Interested in what you think of this; let me know in the comments!

210

305 Comments

🔍 #Smoke Testing vs #Sanity Testing – Quick Breakdown! Many QA beginners confuse #Smoke and #Sanity testing. Here’s a simple way to remember: ✅ Smoke Testing → “Is the build stable enough to test?” 🔸Performed on new builds 🔸Focuses on basic functionality 🔸If failed → Build rejected ✅ Sanity Testing → “Are the recent fixes working correctly?” 🔸Performed on stable builds 🔸Focuses on specific modules or bug fixes 🔸If passed → Move to regression testing 💡 Fact: Smoke testing is like a doctor’s first checkup, while sanity testing is like a follow-up appointment! #SoftwareTesting #QATesting #SmokeTesting #SanityTesting #AutomationTesting #TestAutomation #Selenium #TestNG #QACommunity

94