Continuing on our tryst with Bollywood’s Karan-Arjun, let’s read about some more important duos in the field of Software Testing!
Preventive & Reactive approach
Preventive – Tests are designed at an early stage, i.e. finding infinite ways to test and break your software before it goes to production. Identify or forecast the risks early & plan accordingly.
Responsive – as in tests are designed after software development is completed. You react as & when the problem (defect) occurs.
Regression Testing & Retesting
Regression: It’s like checking for side-effects. The code is developed >> Build is deployed >> Sanity is performed >> Full testing is done >> Defects are logged, fixed & retested. What else? Yeah! Truth is stranger than fiction, and so is the Software. You never know a change in one function (defect fix or enhancement or change request) can impact multiple areas of the software. It’s our duty as a Test team to ensure everything (apart from the change) impacted is working as expected.
Retesting: What do you do in testing? Obviously find & log defects. After that? Yeah! Developer will fix the defect. As a Test team you need to verify that the defect fix is working fine, in other words you need to ‘retest’ the defect based on its steps to reproduce.
SDLC & STLC
SDLC: Software Development Life Cycle, SDLC for short, is a well-defined, structured sequence of stages in software engineering to develop the intended software product. Phases involve: Requirement gathering and analysis >> Design >> Implementation & Coding >> Testing >> Deployment >> Maintenance.
STLC: How do you identify what’s wrong? Software Testing Life Cycle, popularly known as STLC is a well-defined process with different structured sequence of phases to test the intended software. Phases involve: Requirement Analysis >> Test Planning >> Test Design >> Test Environment setup >> Test execution >> Test Closure >> Post-implementation support.
Smoke & Sanity
Smoke Testing: It’s like the general health check-up. Smoke testing is the preliminary testing to reveal simple failures severe enough to reject a prospective software release. In other terms you can call it as ‘Confidence testing’ or the ‘Build verification testing’. Smoke tests cover the MOST CRITICAL functionalities.
Sanity Testing: It’s like specialized health check-up. After every change in a build Sanity testing is performed to ascertain that the particular changes are working as expected post which detailed tests are performed. If sanity test fails, the build is rejected to save the time and costs involved in a more rigorous testing.
Software Testing & Quality Assurance
Software Testing: To make it right, you first need to identify what’s wrong. And when it’s about finding the wrong in software, we call it “Software Testing”!
‘Software Quality Assurance’ – a set of administrative and procedural activities (e.g. process implementation, training, auditing, etc.) implemented in software engineering processes so that requirements and goals for a software will be fulfilled.
Static & Dynamic Testing
Static as in immobile – the code is not executed. Rather than the code, requirements, design and other documents are manually reviewed to find errors (such as code flaws or potentially malicious code) before the test cases are actually executed to verify the functionality.
Dynamic as in active – the code is executed. How? By exercising the different functional or non-functional flows of the AUT in run-time environment from the User interface (e.g. webpage). The objective – to confirm that the AUT is working in accordance with the client requirements.
Test Design & Execution
Test Design: Simple put – writing the test cases based on client requirements. But it’s not as simple as it sound. A proper process has to be followed for Test Design to ensure that none of the client requirement is missed and we have an optimum test coverage before advancing to the Test execution phase. Steps involve:
- Derive high-level Test Conditions from the requirements
- Write, review, rework & get sign-off for Test scenarios (based on above identified Test conditions)
- Write detailed Test cases (steps) covering ‘how’ to test different aspects of the application-under-test
- Identify the Test data to be used
- Update the Requirement Traceability Matrix (RTM) — an industry-accepted format where each test case is mapped with the requirement
- Automation Test scripts (if in-scope)
Test Execution: The next step after writing the test cases would be to execute those against the application-under-test. Just do it. Go on to execute the Test cases to find defects. If required, do some ad-hoc tests as well. The bottom line is – To find defects!
Test Plan & Strategy
Test Strategy: Before commencement of any Testing project the management first devises a Test Strategy document covering the Methodology, Test Approach, Scope of testing, Types of testing to be covered, Environment details, Resource requirements, Test Cycles, RAID (Risk, Assumption, Issues & Dependency), etc.
Test Plan: The Test Plan document list your Test approach & all the details included in the Test Strategy – together with the timelines. What will be the timelines in case you follow agile methodology? What if it’s Waterfall model? When will each test phase start & end? What will be the deliverables at each phase & corresponding reporting structure?
Test Scenarios & Test cases
Scenarios: ‘What’ is to be tested? As the name says Test scenarios cover the different situations / set-ups / states that need to be tested in order to sign-off the application. It is important to cover optimum scenarios to test an application effectively. Test scenarios are derived from the requirements or use-cases.
Cases: ‘How’ to be tested. A set of conditions or variables under which a tester will determine whether an application, software system or one of its features is working as per the requirement. It details out the steps to be executed, expected and actual results as well. Test cases are derived from Test scenarios and one Test scenario may result in multiple test cases.
Verification & Validation
Verification: In simple terms – ‘Are we building the product right?’ And how to ensure that? Simple – just verify the intermediary products (like documents) at each phase adhere to the guidelines or requirements imposed at the beginning of the project. Verification is more inclined towards development best-practices and conformance to requirements.
Validation: In simple terms – ‘Are we building the right product?’ And how to ensure that? Software Testing. A verified product is of no use if it’s not defect-free, or cannot be used by end-users. Validation ensures that the product is fit for use and satisfy the business needs. Validation is more inclined towards Testing and end-user perspective.
Trivia: Directed by Rakesh Roshan, Karan-Arjun is a 1995 Indian action thriller drama film starring, Shahrukh Khan and Salman Khan. The film was the second highest grossing Hindi film of 1995 after Dilwale Dulhania Le Jayenge.