Software performance testing: There is no 'I' in 'team'

"When everyone on the team does his job and works together to support one another the net result is almost always dramatically more desirable"

It makes more sense to think about performance testing and tuning as a team sport in which the following takes place:

• The team works together collaboratively
• The team is informed and involved in the decision-making process about what to test next
• The team generates ideas about how the performance tester can help isolate performance issues using the tools that are exclusively available to him
• The team finds out about performance issues in real time
• The team gets to work together to help find functional errors under load
• The members of the team who best understand the various components of the system under test get to participate in analyzing the results data in real time
• The performance tester gets to sit next to the developer during the tune-retest-retune-retest cycle (frequently shortening that cycle from days or weeks to hours)
  Maybe I should rethink my conference

When everyone on the team does his job and works together to support one another the net result is almost always dramatically more desirable.

Like the guide, then subscribe by entering you mail id to get updates daily
Don't miss any article:Get it by E-mail

Living life as a Software Tester!

Recently I read a very interesting article on “All I Ever need to know about testing” by Lee Copeland.I was so impressed with the concept of our day to day work comparison with the software testing.

I will extract only points related to software testing. As a software tester keep in mind these simple points:

Share everything:

If you are a experienced tester on any project then help the new developers on your project. Some testers have habit to keep the known bugs hidden till they get implement in code and then they write a big defect report on that. Don’t try to only pump your bug count, share everything with developers.

Build trust:

Let the developers know any bug you found in design phase. Do not log the bug repeatedly with small variations just to pump the bug count. Build trust in developer and tester relation.
Don’t blame others:As a tester you should not always blame developers for the bugs. Concentrate on bug, not always on pointing that bug in front of all people. Hit the bug and its cause not the developer!

Clean up your own mess:

When you finish doing any test scenario then reconfigure that machine to its original configuration. The same case applies for bug report. Write a clean effective bug report. Let the developer find it easy to repro and fix it.

Give credit to others for their work:
Do not take others credit. If you have referred any others work, immediately give credit to that person. Do not get frustrated if you not found any bug that later has been reported by client. Do work hard, use your skill.
Remember to flush Like the toilets flush all the software’s at some point. While doing performance testing remember to flush the system cache.

Take a nap everyday:
We need time to think, get refresh or to regenerate our energy.Some times its important to take one step back in order to get fresh insight and to find different working approach.

Always work in teams, team score are always better and powerful than individuals.

Like the guide, then subscribe by entering you mail id to get updates daily
Don't miss any article:Get it by E-mail

V-Model for Testing-A famous interview Question

The V-model is a software development model which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.

Verification Phases:
Requirements analysis:In this phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However, it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the system’s functional, physical, interface, performance, data, security requirements etc as expected by the user. It is one which the business analysts use to communicate their understanding of the system back to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase.

System Design:System engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly.The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing is prepared in this phase.

Architecture Design:This phase can also be called as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in this phase.

Module Design:This phase can also be called as low-level design. The designed system is broken up in to smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudocode - database tables, with all elements, including their type and size - all interface details with complete API references- all dependency issues- error message listings- complete input and outputs for a module. The unit test design is developed in this stage.

Like the guide, then subscribe by entering you mail id to get updates daily
Don't miss any article:Get it by E-mail

The uTest Testing Community: Get Paid for finding Bugs

Found out a pretty interesting new concept uTest, check it out.

By joining uTestTM you will become a member of the world's first online community of software testers and gain access to the uTestTM Testing Platform. As a Tester in our community, you will be the first to try exciting and innovative applications, many of which are pre-released and have yet to be introduced to the public. Our network of testers (whose experience ranges from common consumers to highly trained testing professionals), forms a community from around the globe dedicated to experiencing and helping perfect bleeding-edge technology.

Our Testers enjoy extremely flexible hours - so you can work when you want to and at your own pace. In addition, the uTest Testing Platform can operate on any machine connected to the internet, which means Testers can work anywhere they want: from the comfort of their own home to their local coffee shop.

join utest and earn money.

Like the guide, then subscribe by entering you mail id to get updates daily
Don't miss any article:Get it by E-mail