Testing practices to deliver project in a limited timeline and constrained budget.
Hey folks, We all are working on the very stringent delivery timelines and with a very limited budget. And this especially applied for Testing process and as we all know Testing is still be considered very late during the project planning. This not only affect test planning but also it impacts the deliveries for the project. In order to make sure that we deliver the product within timelines and budget to the stakeholder, we have identified the below practices and have figured out that they provide the best results and with minimum delay/risks.
Before moving to the detailed practices , Below image provides us the process that every project delivery goes through.
With the above diagram, let’s get into the practices that have give us the confidence to deliver/release product within timelines and budget.
Deciding Timelines for delivery:
To decide the timelines, we must ensure proper estimation techniques to be followed. With the advent of Agile practices, it is given that the deliveries must be quick and efficient. One of the techniques we can use and is popular in agile world is poker planning. We can chose this estimation technique because it provides us the details of user stories that are part of the delivery, discussion about them, early query resolution and the opinions/concerns of different experts/team. This also ensure us that all the people from cross-functional team understand the product and provide their estimations based on the understanding. The estimation is decided only after the agreement of all the stakeholders with a proper justification.
Shift Left Approach:
With the prominence of API’s in today’s technology, It has become one of the important factors of the product. Also, most of the products are now backend enabled which means that the product processes the logic at the backend services mostly through API and uses UI merely for representation purpose. With this, it has become very important for the testing team to create test strategy for API services. One of the best strategy is to use “Shift Left Approach”. This means that testing team will start writing the automated tests once the API specification is available. This reduces the dependency with the development and test team can write tests based on the specifications. Since, the API’s are not yet ready and not available for tester to consume for their test execution, we should leverage the open source mocking tools/libraries such that they can used as a placeholder/mocked for those API’s. Once the actual API’s were ready and available for tests, we can simply change our endpoints from mocked services to the actual API’s.
Behaviour Driven Development(BDD):
As part of shift left strategy, we can uses Test/Behaviour Driven Development. As we want to start our testing at an early stage, this approach actually works best. With TDD/BDD, the scenarios are written in plain text which are in a format called GIVEN, WHEN, AND, BUT, THEN. This plain text format is known as gherkin language which is very similar to human spoken language and it provides a clear understanding of different scenarios for that feature. The main benefit with gherkin is it has multi-lingual support and they can be understood by layman. With BDD, we collaborate with business/product owners to guide them with the scenarios and understand any differences/changes we need. This help us to identify issues and concerns at early stages itself. Once they are written, the same scenarios are automated to run against the code. We can write BDD tests in Xray and tag it with the user story for traceability. To automate BDD scenarios, we can use Cucumber as it is open-source and is widely accepted framework for BDD. These automated cucumber tests are executed through jenkins job and mark the scenario as pass or fail in xray jira plugin. This gives a clear representation on the coverage and the tests reports can be viewed directly within JIRA.
Note: To use such web mock servers, we must first comply to our compliance policies.
Continuous Testing:
With the advancement of tools for Continuous Integration(CI) for e.g. Jenkins, It has made possible to follow the continuous testing process as a practice. Continuous testing generally means that we start our tests execution as soon as the code/change is available for tests. Jenkins, Git and other tools like JIRA have enable us to make sure the test suites which are available for execution can be triggered as soon as the change is deployed. Also, most of the tools are open-source and are widely accepted by the community, This helps us to reduce the costs that required to setup the continuous testing . With open-source tools like sonarqube, we can perform static analysis on source code and detects any potential bugs/vulnerabilities that might occur due to the broken coding rules. The tool gets easily integrate with jenkins and git, so this means the developers are enforced with the coding standard. Once the code is reviewed by static analysis tools like sonarqube and jacoco, Code gets deployed to the environment. With jenkins, we can schedule jobs that can trigger tests as soon as deployment gets completed successfully. This will provide us the insights on which tests have been failed and the reason for them to fail. It reduced our time to figure out the flaky, outdated, or need modification tests and also if there are any legitimate failures due to the change. Mostly, it provide us quick test feedback on the features that is available for testing. This enable us to have more confident on the product as the positive/sanity cases gets executed on every build.
Budgeting for QA Testing:
Budget is one of the major concerns product owners have, and this specifically applied on tools that are used for effective project deliveries. With limited budget, it becomes very difficult for QA to onboard any latest technologies/tools that can help to reduce time with quality deliveries. However, open-source tools have emerged with huge community support and with improved documentation. These open-source tools played an important role to bring the efficiency with very limited budget and are very well placed for our qa toolsuite. Selenium and node.js are one of the best open source tools we have for developing Web Automation Test Suite, and RestAssured library can be used for writing API Automation Test Suite, GIT can be used for version control and Jenkins used for continuous testing where the automation scripts can be scheduled to run for each build. For Test Management, we can onboarded Xray which is easily integrated with JIRA at a minimal cost(I hope one day Atlassian will provide the Test Case Management feature within JIRA itself). Xray can be used for writing scenarios in BDD Gherkin language. Integration with automation tools can be made easily without much effort. Overall these whole qa tool suite will help us to ensure the continuous delivery within budget since most of them are open-source and are less expensive than any other third party vendor tools.
Hope you guys follows these basic practices and tools to deliver project in a limited timeline and constrained budget.
