POCs are an underrated but powerful tool in test automation and development projects. When implemented with a well-defined vision and purpose, they can set a solid foundation by mitigating risks, reducing costs, fostering innovation, and building stakeholder support.
This is step-by-step progression from the initial Proof of Concept (POC) to the more advanced Minimal Desirable Test Automation Framework (MDTAF) in the test automation journey.
I recently had the chance to work in a regulated environment with restrictions on technology, infrastructure, and tools due to security constraints, which is quite understandable.
MIFID regulatory reports did not have any automated tests or framework. Manual testing of all reports is challenging and time-consuming at the same time due to the many moving parts in the data.
Also, Manual testing is prone to human errors due to the large number of reports under MIFID and the importance of achieving data quality for each report is high. In case you missed one step, you have to start over again and test the entire data flow before generating the report(s).
This was my inspiration or problem statement to solve, which led me to plan and execute a proof of concept (POC) for automating MIFID reports based on ETL (extract, transform and load) process. To start building a test automation framework, I needed to have confidence that test automation is possible and will be successful.
POC & MDP
There are two concepts which I find very useful: Proof Of Concept & Minimal Desirable Product. POC & MDP, they both have distinct purposes but could complement each other when planning for the test automation at pre pre-planning stage where you are surrounded with many unknowns like tools, infrastructure, test data etc.
POC is a small-scale, experimental project or prototype designed to test the feasibility of an idea or concept. Its primary goal is to verify whether a particular technology, approach, or concept can work in a real-world scenario.
MVP, on the other hand, is a minimal version of a product that includes only the essential features required to address a specific problem or deliver value to early users. Its primary goal is to test the product in a real market environment and gather user feedback for further refinement. The same concept could be utilized when designing a test automation framework i.e. Minimal Desirable Test Automation Framework (MDTAF), build a framework with essential features and gather feedback for further and continuous refinement.
Proof of Concept
To verify the feasibility or viability of a concept, idea, or hypothesis in a real-world context, a demonstration or experiment is known as a proof of concept (POC).
It is evidence that a specific idea, technology, or approach can function as intended and can be further developed into a complete project or solution.
Once you understand problem statement you trying to solve, With these 3 simple steps, it's easy to approach or plan a POC as:
Readiness (Preparation)
Identity a scenario
Identify Tools
Test data preparation
Dependency in terms of third party tools
Required tools/ Packages/ Libs
CI environment hooks
Implementation & Test Execution
Plan an end to end scenario to automate
Implementation of a scenario
Execution in CI environment
Results & Analysis
Going through the test results/ trends to identify any flakiness due to the environment or any other dependency
A strong foundation is essential to build a solid test automation framework and scripts.
Minimal Desirable Test Automation Framework
The goal of a Minimal Desirable Test Automation Framework is to get started with automated testing quickly while leaving room for future expansion and refinement based on project requirements and feedback.
A Minimal Desirable Test Automation Framework is a pragmatic approach to test automation that balances the need for a quick start with the flexibility to adapt to changing project requirements and grow in sophistication over time. It empowers teams to gradually embrace automation while aligning project goals and feedback.
Here are some key points to elaborate on the goals and benefits of such a framework:
Getting Started
The primary goal is to facilitate the adoption of automated testing by providing a minimal yet the functional framework.
This allows teams to begin automating their tests quickly without the need to invest a significant amount of time and effort up front.
Requirements Gathering
The framework should prioritize requirements gathering, meaning it should be flexible enough to accommodate the specific needs and goals of the project.
Teams can start with a basic set of testing requirements and expand them as they gain a better understanding of the testing landscape.
Room for Future Expansion and Refinement
The framework should be designed with scalability in mind, allowing for future expansion and refinement.
As the project evolves and more testing scenarios and features become necessary, the framework can adapt to incorporate these changes.
Iterative Development:
Teams can follow an iterative development approach, enhancing the framework incrementally based on feedback and changing project requirements.
This iterative process aligns well with Agile methodologies, where software development is continuous and adaptable.
Advanced Features and Integrations
As the project matures and automation gains importance, teams can gradually add more advanced features and integrations to the framework.
These enhancements might include support for different testing types (e.g., unit, integration, end-to-end), integration with continuous integration (CI) pipelines, and reporting capabilities.
Meeting Specific Testing Needs
The framework can be customized to meet the unique testing needs of the project, whether it's a web application, mobile app, or other software.
Tailoring the framework to specific requirements ensures that it remains relevant and valuable to the team.
Efficiency and Consistency
Automated testing helps improve efficiency by executing repetitive test cases quickly and consistently.
A well-designed framework contributes to maintaining consistency across test runs and reduces the likelihood of human error.
Documentation and Training
Alongside the framework, teams should provide documentation and training resources to ensure that team members can effectively use and contribute to the automation efforts.
Conclusion
POC is the starting point of your test automation journey, which is typically a small-scale experiment or pilot project to test the feasibility of automation within a limited scope.
MDTAF evolves from the initial POC into a more advanced and sophisticated approach known as Minimal Desirable Test Automation Framework. MDTAF involves using models to represent the application's behaviour and automating tests based on these models for ongoing, continuous testing.
A Comprehensive Approach which will cover various aspects of automation, including tool selection, script development, environment setup, data management, continuous integration, and maintenance.
In summary, the journey you are planning to undertake in your test automation project, starting with a POC and progressing towards MDTAF and continuous test automation approach indicates that you will address all necessary components for successful automation with continuous feedback.
Kommentare