Bashiul Alam Sabab

- JMeter has fast execution time which comes to benefit in all phases of STLC - We have the option to design our tests to be executed sequentially so that dependent tests execute one after the other - We can define variables, generate test data during runtime with customised scripts - Response data can be extracted and saved to use in other tests - Using one test plan/script we can run in any of our test environments, i.e: staging, sandbox etc. - JMeter gives us various options in test reporting - We have access to different metrics and analytics to showcase our test results - The same script written for system testing can be reused at the time of performance/load testing

A simple plan to use JMeter for system testing can be: - Identify the core APIs which integrate the whole system and are crucial in running regression/sanity/smoke/UAT tests - Use the regression/sanity/UAT test suite or API checklist to implement the system test - Implement the test cases in a Test Plan with controllers, samplers and listeners and validate them with proper assertions - Design the tests in a way so that all the dependent test data are extracted properly and saved and are used properly across different tests - Maintain a variable list to ensure reusability across the test plan - Also design in a way so that the same test plan can be used for performance/load test - Add necessary logging and reporting to show test results

In aspect of software testing, acceptance criteria and scenarios translate into the successful exit of a business logic/requirement and a use case. For each test scenario or feature to be tested, we need clear and concise acceptance criteria based on which we can say our test have been completed. To create test metrics, it is important to have these criteria properly defined. To prove software validation it is required that the ACs meet the business requirements. Another important aspect for these criteria is the use in automated test implementation, how the test code is going to indicate that it has succeeded.

The following points can be practiced to validate acceptance criteria and scenarios efficiently: - Cross check with the business requirements and the available use cases - Review with the PO/PM, developers, QAs and other stakeholders that the written ACs are on point and everyone has the same understanding from the requirement analysis - Verify that the ACs are simple enough to be implemented in automated tests - The ACs should be structured such a way that a requirement change will not make it complex to modify or update the criteria

We can follow these guidelines to write impactful acceptance criteria and scenarios: - It is important to use simple language, being clear and concise and avoiding ambiguity - The acceptance criteria should be on point about what to check for the test case to pass - Just like test cases, acceptance criteria and scenarios should be written from a user view point, i.e: how a user would expect this to turn out - Must include the happy path, negative scenarios and edge cases - Technical details should be avoided unless critically necessary so that the non-technical team members can also understand it - The acceptance criteria and scenarios should always satisfy the business logic and cover the requirements