While these were powerful AI features powered by Postbot, they were disconnected actions within the Postman app and it didn’t feel like you were talking to “one expert AI assistant.” As the set of capabilities grew, having multiple entry points quickly became untenable. Users needed help knowing where to find Postbot and what they could do with it. This also coincided with the rise of chat as a popular way to interact with AI-enabled systems.
Postman Flows, is a visual tool to create API workflows. You can use Flows to chain requests, handle data and create real world workflows right in your Postman workspace.
You create flows in a workspace. Use workspaces to organize your API projects and collaborate with your team.
To create a new flow, do the following:
Flows.
Create a new Flow > Create new Flow.
View more actions > Rename.Use the String block to define text, which you can send to another block.
To add a String block, do the following:
Block.
String. You can also search for the block by entering String in search.In the next procedure, you'll connect this block to a Display block to display your text.
When you connect two blocks, you connect one block's input to another block's output. Inputs are on the block's left side and outputs are on its right side. The Display block displays incoming data, such as the String block's string value.
To connect a Display block, do the following:
Output. You can also search for the block, by entering Output in search.From the canvas toolbar, select 
Run.
Once the GraphQL schema is defined, the teams working on frontend and backends can do their work without further communication since they both are aware of the definite structure of the data that’s sent over the network.
Frontend teams can easily test their applications by mocking the required data structures. Once the server is ready, the switch can be flipped for the client apps to load the data from the actual API.
GraphQL allows you to have fine-grained insights about the data that’s requested on the backend. As each client specifies exactly what information it’s interested in, it is possible to gain a deep understanding of how the available data is being used. This can for example help in evolving an API and deprecating specific fields that are not requested by any clients any more.
With GraphQL, you can also do low-level performance monitoring of the requests that are processed by your server. GraphQL uses the concept of resolver functions to collect the data that’s requested by a client. Instrumenting and measuring performance of these resolvers provides crucial insights about bottlenecks in your system.
As we are moving towards Agile [ even PMP is adapting to Agile on 2021], we tend think Waterfall model, V model as stone age methodologies. But as I work more and more on Agile I couldn't shake the feeling of similarity on V model. Especially from a QA / Tester point of view.
Traditional V model
 |
| V Model |
Verification is the comparison of software to its technical specification. This effort is typically led by a systems analyst.
Validation is the comparison of software to its business requirements. This effort is typically led by a business analyst.
Left side of the traditional “V” portrays various upfront and comprehensive business and technical documents.Right side mirrors the corresponding levels of testing.Top-down, the testing levels are satisfaction assessment, acceptance testing, user testing, system testing, integration testing, and unit testing.The top 3 levels provide validation while the lower 3 verification.
Agile V Model
Agile V Model
Left Side of the agile “V”1. Business Need – states the business direction in the form of cost savings, revenue increase, conformance to laws, industrial standards, or an executive edict2. With a statement of business need, the stakeholders scope the Product Vision of the solution by creating a list of prioritized software features. Led by a business analyst, the stakeholders attend a facilitation session where they brainstorm ideas, construct AS-IS and TO-BE models, conduct a gap analysis, and finally rank the product features of the software solution along with their benefits. Note the stakeholders most likely also identify associated process improvements.3. Together with the stakeholders, the agile team elaborates on the Product Features via user stories consisting of conversations and matching test confirmations with constraints (business rules) and environmental conditions (e.g., system performance, capacity, usability, security, etc.). The team then estimates the work required for each feature in story points for velocity planning. Velocity is the average of story points a team can address in an iteration4. For each iteration, the agile team breaks down selected product features into Functional Tasks (e.g., input, store, retrieve, calculate, transmit, print, etc.) and estimates the work required in hours. This is called commitment-driven iterative planningRight Side of the Agile “V”As in the traditional V-Model, the right side of the “V” mirrors the progressive definition side with matching testing levels. Again starting at the top:1. Business Case Assessment consists of economic indicators that confirm that benefits stated in the Business Need are realized.These indicators range from payback period, benefit-cost ratio (BCR), return on investment (ROI), net present value (NPV), to internal rate of return (IRR). Note benefits need to be on a feature basis since the product owner will approve features incrementally. This allows the product owner to update the business case as soon as the benefits are realized. This is a real economic benefit of the agile approach; the quicker the features are moved to production, the higher the NPV. Note if the business case is motivated by a conformance issue, the benefits are in the compliance rather than economics.In the traditional V-Model, the matching test level of Business Need is a satisfaction assessment rather than a business case assessment. The satisfaction assessment is typically a user survey providing solution feedback such as solution errors, enhancements and lessons learned. Due to the continuous involvement of the product users in agile, the satisfaction assessment is redundant.2. Product Owner Testing is when upon reviewing completed features of the current release/iteration, the owner of the solution decides if the quality of the Product Vision features are “fit for use” for an incremental move to production. This is in contrast to the traditional V-Model where the quality definition of “conformance to written and approved requirements” is applied by the product owner using the formal Business Requirements Document (BRD).3. Regression Testing, also known as continuous integration testing or automated testing, is a suite or series of testing to ensure all acceptance criteria for developed features are still working (no errors). This level of testing also includes solution environmental conditions as stated in the Product Features.4. Test-Driven Development (TDD) is the
1) development of functional tests prior to coding, 2) coding, 3) test execution and 4) refactoring of the Functional Tasks; see the process model in Figure 3. Refactoring is “cleaning” up code for efficiency and/or maintainability (yes, documentation), not adding or changing tasks; sometimes referred to as technical debt.
SUMMARY
Like the traditional V-Model, the proposed V-Model for agile development testing highlights both validation and verification. Although, by nature, the agile V-Model is simpler (fewer test levels), it is just as thorough. The agile V-Model maintains and truly enhances the test-driven development concept. And most important, it completes the test life cycle with the business case assessment.
 |
| API Calls interaction |
