Design patterns in Automation Testing

Design Patterns in Test Automation World


Automation testing is a process of developing software to test software. Hence, the test patterns are loosely similar to design patterns that are used in software development.
Design patterns show how to design the test automation test ware so that it will be efficient and easy to maintain. A design pattern provides a general pattern provides a general reusable solution for the common problems occur in software designs.
The basic idea is to speed up the development process by providing well tested, proven development and design paradigm.


What are the advantages of using Design Patterns?


· Low maintenance effort and time
· Low maintenance cost
· Enhanced code re-usability
· Enhanced reliability
· Structured code base which is easy to fix and extend
· Improved communication





Different Design Patterns -


1. Record and play
2. Classical Design
3. Facade Design
4. Singleton Design
5. Page Object Design
6. Modular Design


1.Record and play


Record and playback tools are used in training. Tools let the tester hit record and manually go through the real user actions of pre scripted test case. For example- learning and training, simple play your video, extremely simple web based application functionality, where the code base never changes.


2.Classical Design


It requires the creation of small, independent scripts that represents features, functionality or module of system based on its own managed data source. The process is complex and requires an extra effort to come up with the test data sources. For example- Small application of not more than 100 TC’s, application like data entry/from filling regularly.


3.Facade Pattern


The Facade pattern provides a simple interface to deal with complex code. In the facade pattern, as applied to test automation, we design the facade class which has methods that combine actions executed on different pages. For example- Customer service application, departmental store application


4.Singleton Pattern


A Singleton class means only one instance of it can exist at any time. But why would you need this?
Well it is very useful in a case when you need to use the same object across the whole framework. A Singleton class returns the same instance every time you try to instantiate an instance of the class. Think of it providing global access to a single object, for example, the log file object ,most of the desktop application, test automation, hardware devices automation.




5.Page Object Model


The Page Object Model is a widely used object design pattern for structuring automation test code. Here, pages in the applications are represented as Classes, and various UI elements of that pages are defined as variables. For example- Any enterprise application, retail software, banking application, e-commerce application.


6.Modular Design Pattern


In the current era of digital transformation where Mobile, Cloud, Big data concepts are playing a significant role, Complex design help to design end to end test automation solutions efficiently by integrating. Methodologies, frameworks, accelerators, latest technologies, virtualisation tools and lab management solutions. For example- Mobile application, Enterprise application, Cloud application.

GIT AND GITHUB

The Version Control System – Git and GitHub

What is Git?

  Git is open free source distributed control system designed to handle everything from small projects to large project with speed and efficiency. Git actually create local repository on our computer.

Why should we learn Git?

Git is most popular version control system. Let’s talk about manage our projects files. Project can have so many files like html, xml. Git keep track of every change in our application. If we want to see out code which we have written a month ago then Git is very helpful and we can see what date and time we have made change to our data.

DevOps

What is DevOps?

It is coming up with two words Development and operations. DevOps is not a tool, it is not a software, not a programming language then what it is? DevOps is more over a philosophy, more over a mindset the way how you take your product  or whatever website you are designing and taking that product or website so that million of people can use it. This entire process has variety of ways to go through with it. So DevOps is the concept that is used in application lifecycle management in which both Development and operation team are working in the sink so whatever product and feature you are giving to end user, you can give it to smoothly.

Shift-Left Testing

                                                            SHIFT-LEFT TESTING


Shift lift testing is an approach to the software testing and system testing in which testing is performed earlier in the life cycle.
Firstly, the principle of ‘Shift left’ supports the Testing team to collaborate with all the stakeholders early in the software development phase. Hence they can clearly understand the requirements and design the test cases to help the software ‘Fail Fast’ and enable the team to fix all the failures at the earliest.
Shift Left approach is nothing but involving the testers much earlier in the software development life cycle, which in turn would allow them to understand the requirements, software design, architecture, coding and its functionality, ask tough questions to customers, business analysts, and developers, seek clarifications, and provide feedback wherever possible to support the team.

This involvement and understanding will lead the testers to gain complete knowledge about the product, think through various scenarios, design real-time scenarios based on the software behaviour which would help the team in identifying the defects even before coding is done.











Shift Lift Approach influences Software Development in several ways----


· Shift Left approach focuses on involving testers in all and most importantly the critical stages of the program.
· Shift Left approach gives the opportunity for the Testers to design the tests first,
· IT allows the Developers to take more ownership of their code and increase their responsibilities on testing.
· Shift Left approach also encourages testers to adopt Behavioural Driven development and Test driven Development.
· Shift Left Testing in Agile: Shift Left approach supports forming Agile Scrum Teams which mandatorily includes Testers along with the other roles and includes Testers in regular stand up calls, other interactions, review meetings which has made the testers to have more information related to the program and hence has allowed them to indulge and involve in the detailed analysis of the software and provide rapid feedback which would help in preventing the defects grounded in the software.

Serverless Architecture

SERVERLESS ARCHITECTURE -


Serverless is a cloud computing execution model where the cloud provider dynamically manages the allocation and provisioning of servers.
Serverless applications are event-driven cloud-based systems where application developments rely solely on a combination of third party service and client side and cloud-hosted remote procedure calls.


ADVANTAGES -

1.No server management is necessary
Although 'serverless' computing does actually take place on servers, developers never have to deal with the servers. They are managed by the vendor. This can reduce the investment necessary in DevOps, which lowers expenses, and it also frees up developers to create and expand their applications without being constrained by server capacity.
2.Developers are only charged for the server space they use, reducing cost
As in a 'pay-as-you-go' phone plan, developers are only charged for what they use. Code only runs when backend functions are needed by the serverless application, and the code automatically scales up as needed. Provisioning is dynamic, precise, and real-time.



3.Serverless architectures are inherently scalable
Applications built with a serverless infrastructure will scale automatically as the user base grows or usage increases. If a function needs to be run in multiple instances, the vendor's servers will start up, run, and end them as they are needed, often using containers (the functions start up more quickly if they have been run recently – see 'Performance may be affected' below)..
4.Quick deployments and updates are possible
Using a serverless infrastructure, there is no need to upload code to servers or do any backend configuration in order to release a working version of an application. Developers can very quickly upload bits of code and release a new product. This also makes it possible to quickly update, patch, fix, or add new features to an application
5.Code can run closer to the end user, decreasing latency
Because the application is not hosted on an origin server, its code can be run from anywhere. It is therefore possible, depending on the vendor used, to run application functions on servers that are close to the end user. This reduces latency because requests from the user no longer have to travel all the way to an origin server. Cloudflare Workers enables this kind of serverless latency reduction.
When should developers avoid using a serverless architecture?
There are cases when it makes more sense, both from a cost perspective and from a system architecture perspective, to use dedicated servers that are either self-managed or offered as a service. For instance, large applications with a fairly constant, predictable workload may require a traditional setup, and in such cases the traditional setup is probably less expensive .
Serverless architectures are not built for long-running processes
It is difficult to replicate the serverless environment in order to see how code will actually perform once deployed. Debugging is more complicated because developers do not have visibility into backend processes, and because the application is broken up into separate, smaller functions

Requirement Traceability Matrix

Requirement Traceability Matrix
Requirement Traceability Matrix is a document that maps and traces user requirement with test cases to ensure that for each and every requirement adequate level of testing is being achieved. It captures all requirements proposed by the client and requirement traceability in a single document.
The process to review all the test cases that are defined for any requirement is called Traceability. Requirement Traceability Matrix is the means to map and trace all of the client's requirements with the test cases and discovered defects. It is a single document that serves the main purpose that no test cases are missed and thus every functionality of the application is covered and tested.
A Requirements Traceability Matrix is usually in tabular format as it holds multiple relationships between requirements and test cases.



How To Create A Requirements Traceability Matrix--
To being with we need to know exactly what is it that needs to be tracked or traced.
Testers start writing their test scenarios/objectives and eventually the test cases based on some input documents – Business requirements document, Functional requirement document and Technical Design document (optional). Then according to the requirement, we trace our test cases.


Here is how a simple Traceability Matrix would look for our example:

CI/CD PIPELINE

Understanding the CI/CD Pipeline: What It Is, Why It Matters



Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.
When you have a team of developers, each of whom is responsible for a separate feature, you need to integrate the different features before you’re ready for a release. By integrating so frequently, your team can surface errors earlier. And when those are caught, the amount of backtracking needed to find the cause is also much reduced. Therefore, your team can resolve the integration errors much faster.

Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.





Top of Form

Bottom of Form

How to Practice Continuous Integration
If you want to practice CI, the steps roughly go like this:
1. Developers check out code from the repository to work on it locally. Ideally, they create a new branch for the feature they want to implement.
2. When their feature branch is ready, they run tests locally in their development environments.
3. Once all tests pass, they push the commits to the single source repository.
4. Whenever there are changes on the repository, a CI server checks out the changes and performs a “build and test.” A build and test is when the CI server builds the entire system on the developer’s feature branch and runs all the unit and integration tests.
5. The CI server notifies the team of the integration result. There should generally be four outcomes: failed build, successful build, failed tests, successful tests.
6. If there’s a failure, the team fixes the issue ASAP.
7. When the feature branch is merged to the main branch, they repeat steps 2–6.
8. They continue to develop and repeat the steps 2–6 whenever there’s new code to be checked in to the repository.


.
What’s the Difference Between Continuous Deployment and Continuous Delivery (CD)?
You may be confused by the fact that there’s another term CD can stand for: continuous delivery. So what’s the difference between the two? continuous deployment is about automating the release of a good build to the production environment. In fact, Humble thinks it might be more accurate to call it “continuous release.” On the other hand, continuous delivery is about ensuring that every good build is potentially ready for production release. At the very least, it’s sent to the user acceptance test (UAT) environment. Your business team can then decide when a successful build in UAT can be deployed to production —and they can do so at the push of a button.
To keep it simple, here’s a diagram.

Agile Software Development Process model

                                                                   Agile Methodology

Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.

The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and interaction between them. The rules of Scrum are described throughout this tutorial.

Scrum formal events for inspection and adaptation:

Product backlog: Sometimes known as backlog grooming, this event is the responsibility of the product owner. The product owner’s main jobs are to drive the product towards its product vision and have a constant pulse on the market and the customer. Therefore, he/she maintains this list using feedback from users and the development team to help prioritize and keep the list clean and ready to be worked on at any given time. You can read more about maintaining a healthy backlog here.

Sprint planning Meeting: The work to be performed (scope) during the current sprint is planned during this meeting by the entire development team. This meeting is led by the scrum master and is where the team decides on the sprint goal. Specific use stories are then added to the sprint from the product backlog. These stories always align with the goal and are also agreed upon by the scrum team to be feasible to implement during the sprint.

At the end of the planning meeting, every scrum member needs to be clear on what can be delivered in the sprint and how the increment can be delivered. 

Sprint: A sprint is the actual time period when the scrum team works together to finish an increment. Two weeks is a pretty typical length for a sprint, though some teams find a week to be easier to scope or a month to be easier to deliver a valuable increment. Dave West, from Scrum.org advises that the more complex the work and the more unknowns, the shorter the sprint should be. But it’s really up to your team, and you shouldn’t be afraid to change it if it’s not working! During this period, the scope can be re-negotiated between the product owner and the development team if necessary. This forms the crux of the empirical nature of scrum.

All the events — from planning to retrospective — happen during the sprint. Once a certain time interval for a sprint is established, it has to remain consistent throughout the development period. This helps the team learn from past experiences and apply that insight to future sprints.

Daily Scrum or Stand Up Meeting: This is a daily super-short meeting that happens at the same time (usually mornings) and place to keep it simple. Many teams try to complete the meeting in 15 minutes, but that’s just a guideline. This meeting is also called a ‘daily stand-up’ emphasizing that it needs to be a quick one. The goal of the daily scrum is for everyone on the team to be on the same page, aligned with the sprint goal, and to get a plan out for the next 24 hours.

Sprint review: At the end of the sprint, the team gets together for an informal session to view a demo of, or inspect, the increment. The development team showcases the backlog items that are now ‘Done’ to stakeholders and teammates for feedback. The product owner can decide whether or not to release the increment, although in most cases the increment is released.

This review meeting is also when the product owner reworks the product backlog based on the current sprint, which can feed into the next sprint planning session. For a one-month sprint, consider time-boxing your sprint review to a maximum of four hours.

Sprint retrospective: The retrospective is where the team comes together to document and discuss what worked and what didn’t work in a sprint, a project, people or relationships, tools, or even for certain ceremonies. The idea is to create a place where the team can focus on what went well and what needs to be improved for the next time, and less about what went wrong.