What questions should we ask before starting performance testing?

Performance testing is little complex need lots of data before we initiate performance testing.

when you start out  Performance Testing can be overwhelming to figure out what you need to do and how to approach things. The best way to learn things is to just ask.

Question 1. 

Why do you want me to do performance testing?

 Before doing any kind of testing, we need to understand the business need for it. In order to define a test that gives back actionable information, we need to know why we are doing this test in the first place.What good is going to come from it?

Why are we running this performance test? This'll help you figure out what loads you might need to generate. And from there that gets you to the next question, which is, What tools do I have available to use? There's a lot of testing tools out there, and performance testing is no different. There's quite a wide variety. Some of the tools are free, and some of them are paid. But once you understand the why of your performance testing you can figure out which tools are actually going to help you accomplish the things that you need to do. You'll need to look at what tools are out there. And consider things like what budget you have and what tools your company might already have access to when trying to figure out what tools to use for the test that you're going to run. 

Now, another question that is good to ask early on in a performance testing project is, How can I get the data that I want? 

When we're setting up tests we need two kinds of data for performance testing. We need the input data that allows us to design the test that we want. So we need to have some way of knowing what kind of load we're going to generate. And that can partly be determined by the why of our testing, and also by understanding the loads on our system. 

But we also need access to the output data. We need some way to get data that lets us decide and know, if our test has passed or failed. Maybe we need server logs from the file.

What is Dev Ops ?

I believe most of us knows now what is Dev OPs and how much Dev Ops culture is valuable . For those who still have question about Dev - Ops ,  below definition might be helpful .

Dev-Ops is the way of thinking, applied in different types of organizations.

The forefathers of DevOps gave us a great acronym to use when defining DevOps:

C-A-M-S, or cams, which stands for culture, automation, measurement, and sharing.


Culture is the result of the way that teams interact.

In DevOps culture, the aim is to have development and operations teams interact in a way that breaks down barriers between the teams and with a clear focus on the roles and responsibilities of each.

With both teams working towards a common goal,everyone wins.

Automation is used to speed up the feedback between teams.

By using tools that enable collaboration and repeatable processes,interaction between development and operations teams can be easily facilitated.

This builds confidence in both teams' ability to successfully deliver a product or solution.

Some key points for automation include revision control with pull requests,continuous integration, and configuration management. 

Measure is used to track improvement. By measuring aspects of development and operations,teams can start to see where there are bottlenecks and take actions to improve them.
For Example Measuring the performance of production systems 

This helps teams to know that deployments have not degraded anything like response time, for example.

Sharing
Sharing allows for cross-pollination of ideas, problems, and solutions between various teams.And not just in development and operations,but throughout the entire organization.

By transferring knowledge, the collective intelligence increases and benefits everyone.

It also contributes to diversity of thought,transparency, and openness, which makes for teams that are more effective.

DevOps Critics and Role of QA

DevOps methodology : 
After going through so many books and blogs i came to conclusion DevOps is still a relatively young method, partly experimental. As such it has received its fair share of negativism. Implementing such method might damage good processes withing organizations ( Sorry to be straight here) or can be easily mislead  

DevOps means that there are no walls, no gates, no transitions, and no ceremony between Development and Operations. They are seamlessly integrated (when viewed from “above”) into a single, value delivering, IT entity. This means  that everyone – from Jr Analyst, to Mid Dev, to Sr. Test, to Director of IT – is equally responsible and accountable for the product from inception through retirement. 

This means the Devs are just as likely to be maintaining the system in Production as the Sys Admins are to be doing configuration testing in the Dev Environment.

Management always stresses faster delivery of product , to achieve that most of them are thinking of Dev ops .

Obviously keeping the software instantly deploy-able  requires a large amount of automation, but it is dangerous to only focus on the tools. The focus should instea be on people coming together and working towards making the entire process rapid – reliable – repeatable. All the way from inception of a feature to deployment to production and everyone in between.

Why so critics abt Dev Ops?

Devops methodology facing resistance in organizations   

DevOps assumes that just about everything, and certainly testing, is completely automated. 

Even working in big organizations automation QA struggle to explain to management , most of managers who has background of industrial automation always things software automation is same which does not need any manual intervention . This leads lots of overall misunderstanding of implementing processes .

As QA knows what scenario's can be automated and what can not be ,which need to clearly communicated to avoid future misunderstanding. 

High degree of low level test automation will free up few automation resources which can be effectively managed for integration and exploratory testing, both pre- and post-deployment.

Testing in Production, which DevOps embraces, may look like an immediate block for industries with high amount of regulation: banking and Heathcare .

 A possible solution to consider is the idea of “Blue-Green Deployment”, where you build up an copy of the production environment, hardware and all, in parallel to the real production environment. Once everything has been tested to satisfaction, deployment becomes mostly a matter of switching a router.

 These criticisms does not mean we can not approach DevOps or we should not . You can approach with Open mind and select bits of work , bring them into greater whole .

Role of QA 

Just like Agile , In a pure DevOps world, Quality Assurance is no longer the gatekeeper between development and operations – the bottleneck. QA is an enabler means Everyone contributes to build product right.

On one side, QA works together with development in trying to push more of their tests into the continuous integration system. Tests must have zero human intervention and generate their own test data

A works with operations to collaborate on monitoring tools; perhaps to continuously run smoke tests in Production. Chances are that operations is developing scripts for backup and restore of production systems, rollback of deploy, or scripts for disaster recovery.

Testing such procedures presents an interesting and perhaps new challenge for QA. Another idea is that test automation should have a higher effort at a lower level: the API.

Assuming the API is doing everything correctly  then the UI is likely having issues. But your back end APIs and Data layer should be fine. 

Concentrating automation efforts on lower levels allows tests to be significantly less brittle. For higher level testing of the UI, which may change much more often, manual exploratory testing is a better use of resources. Any problems discovered can quickly be corrected due to higher deploy frequency. 

Conclusion : QA should contribute to the end product; make or bake  QA test scripts as a deliverable in the final product. Approach with Open mind and select bits of work , bring them into greater whole .

SDLC Models

Every software developed is different and requires a suitable SDLC approach to be followed based on the internal and external factors.

I have added more information for below popular software models 

 Waterfall Model 
 V Model 
 Agile Model


The waterfall model is a sequential design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing,Production/Implementation and Maintenance.

Here are some situations where the use of Waterfall model is most appropriate 

• Clearly defined requirements , no ambiguous requirements.
• Stable Product definition
• Ample resources with required expertise are available to support the product.
• The project is short.

Waterfall Model Pros & Cons

ADVANTAGE

The advantage of waterfall development is that it allows for departmentalization and control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process model phases one by one.

Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order.

DISADVANTAGE

The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-documented or thought upon in the concept stage.

V Model

The V - model is SDLC model where execution of processes happens in a sequential manner in V-shape. It is also known as Verification and Validation model.

V - Model is an extension of the waterfall model and is based on association of a testing phase for each corresponding development stage. This means that for every single phase in the development cycle there is a directly associated testing phase. This is a highly disciplined model and next phase starts only after completion of the previous phase.

The below figure illustrates the different phases in V-Model of SDLC.

Agile Model 

Agile thought process had started early in the software development and started becoming popular with time due to its flexibility and adaptability.

Following are the Agile Manifesto principles

• Individuals and interactions . in agile development, self-organization and motivation are important, as are interactions like co-location and pair programming.
• Working software . Demo working software is considered the best means of communication with the customer to understand their requirement, instead of just depending on documentation.
• Customer collaboration . As the requirements cannot be gathered completely in the beginning of the project due to various factors, continuous customer interaction is very important to get proper product requirements.
• Responding to change . agile development is focused on quick responses to change and continuous development.

                           

QAClub : Concepts of Software testing

All ,

 I started this blog to add more conceptual clarity in our day to day testing life . 


This will help QA professionals to understand software Testing concepts ,processes , Tool evaluations 

Stay Tuned !!!!