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.

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

Staticas 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.

Dynamicas 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:

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: 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.

Related Articles

Recently I am observing a rise of API Testing in the Job descriptions. I once did Web Services testing using SOAP UI testing tool, i.e. verifying the XML request-response. Thought it would be a good time to refresh the concepts. Anyways it was on my list since I started STS. When we look at the Software Testing trends, API testing is rising in priority & relevance. Let’s deep dive into the world of API Testing…

The concept has been around from a long time. The most famous example of Crowd Sourcing is “Wikipedia”. Wikipedia, the most comprehensive encyclopedia is the result of the information created by writers and editors from the crowd. The various Bug Bounty programs run by Tech giants is a wonderful practical application of crowdsourced testing which reward researchers and software hobbyists for finding software bugs. Beta testing (many apps have beta versions available in play store / app store including WhatsApp Beta program) is also a form of crowdsourced testing where a set of end-users can access the application & provide their feedback.

Exploratory testing, is all about discovery, investigation and learning. It’s like Machine learning, in concept. It empathizes on learning and adaptability. While the software is being tested, the tester learns things that together with experience and creativity generates new good tests to run. It emphasizes on personal freedom and responsibility of the individual tester. Exploratory testing is done without any specific plans and schedules. Test cases are not created in advance but testers check system on the fly. They may note down ideas about what to test before test execution. The focus of exploratory testing is more on testing as a “thinking” activity.

Are you a Manual Tester? A Test Lead? Good in people’s management? Or Planning? Whatever! You still need to know the basics of programming and automation tool. You need not be a framework-developer, but every organization now wants a Software Tester who knows both functional test + automation scripting!

The Defect Severity (Technical) - In simple words, how severe is the defect for the application’s quality? Say you click on the ‘Help’ link and the application crashes. Whoaa! Bing-Bang Craaaashh..! Quite a severe defect, right?

The Defect Priority (Business) - In simple words, what is the precedence, importance or urgency to fix a defect? Say you click on the ‘Help’ link and the application crashes. Whoaa! Bing-Bang Craaaashh..! Quite a severe defect, right? But how many of us really click the ‘Help’ link? Business usage statistics show less than 2%. Now what do you think should be the urgency to fix a defect that impacts just the 2% of the end-users? Yeah! Not ‘High’ obviously. There would be other urgent defects to fix prior to this. Defect Priority defines the order in which defects should be fixed, i.e. its impact to the end-users, the business perspective.

About STS

Software Testing Studio is an attempt to share some incredible knowledge from industry leaders & experts, which should be helpful for anybody to start his/her career in ‘Software Testing’ or to progress it further. Apart from the technical nitty-gritties, one can also find some intellectual posts by industry experts sharing their Wisdom.