Thursday, 6 September 2012

IMPROVE YOUR TESTER PERFORMANCE

Many Companies don’t have resources or can’t afford to hire the required number of testers on the project. So what could be the solution in this case?

The answer is simple. Companies will prefer to have skilled testers instead of a army of testers!

So how can build skilled testers on any project?
You can improve testers performance by assigning him/her to the single project.
Due to this the tester will get the detail knowledge of the project domain, Can concentrate well on that project, can do the R&D work during the early development phase of the project.
This not only build his/her functional testing knowledge but also the project Domain knowledge.

Company can use following methods to Improve the Testers performance:

1) Assign one tester to one project for long duration or to the entire project. Doing this will build testers domain knowledge, He/She can write better test cases, Can cover most of the test cases, and eventually can find the problem faster.

2) Most of the testers can do the functional testing, BV analysis but they may not know how to measure test coverage,How to test a complete application, How to perform load testing. Company can provide the training to their employees in those areas.

3) Involve them in all the project meetings, discussions, project design so that they can understand the project well and can write the test cases well.

4) Encourage them to do the extra activities other than the regular testing activities. Such activities can include Inter team talk on their project experience, Different exploratory talks on project topics.
Most important is to give them freedom to think outside the box so that they can take better decision on Testing activities like test plan, test execution, test coverage.
If you have a better idea to boost the testers performance don’t forget to comment on!

FIND BUGS IN APPLICATIONS

A very good and important point. Right? If you are a software tester or a QA engineer then you must be thinking every minute to find a bug in an application. And you should be!

I think finding a blocker bug like any system crash is often rewarding! No I don’t think like that. You should try to find out the bugs that are most difficult to find and those always misleads users.

Finding such a subtle bugs is most challenging work and it gives you satisfaction of your work. Also it should be rewarded by seniors. I will share my experience of one such subtle bug that was not only difficult to catch but was difficult to reproduce also.
I was testing one module from my search engine project. I do most of the activities of this project manually as it is a bit complex to automate. That module consist of traffic and revenue stats of different affiliates and advertisers. So testing such a reports is always a difficult task. When I tested this report it was showing the data accurately processed for some time but when tried to test again after some time it was showing misleading results. It was strange and confusing to see the results.

There was a cron (cron is a automated script that runs after specified time or condition) to process the log files and update the database. Such multiple crons are running on log files and DB to synchronize the total data. There were two crons running on one table with some time intervals. There was a column in table that was getting overwritten by other cron making some data inconsistency. It took us long time to figure out the problem due to the vast DB processes and different crons.

My point is try to find out the hidden bugs in the system that might occur for special conditions and causes strong impact on the system. You can find such a bugs with some tips and tricks.

So what are those tips:

1) Understand the whole application or module in depth before starting the testing.

2) Prepare good test cases before start to testing. I mean give stress on the functional test cases which includes major risk of the application.

3) Create a sufficient test data before tests, this data set include the test case conditions and also the database records if you are going to test DB related application.

4) Perform repeated tests with different test environment.

5) Try to find out the result pattern and then compare your results with those patterns.

6) When you think that you have completed most of the test conditions and when you think you are tired somewhat then do some monkey testing.

7) Use your previous test data pattern to analyse the current set of tests.

8) Try some standard test cases for which you found the bugs in some different application. Like if you are testing input text box try inserting some html tags as the inputs and see the output on display page.

9) Last and the best trick is try very hard to find the bug ;-) As if you are testing only to break the application!


Meantime you can comment out more tips here.

Sunday, 2 September 2012

TESTING WEEKLY STATUS REPORT

Writing effective status report is as important as the actual work you did! How to write a effective status report of your weekly work at the end of each week?

Weekly report is important to track the important project issues, accomplishments of the projects, pending work and milestone analysis. Even using these reports you can track the team performance to some extent. From this report prepare future actionables items according to the priorities and make the list of next weeks actionable.

So how to write weekly status report?

Follow the below template:
Prepared By:
Project:
Date of preparation:
Status:
A) Issues:
Issues holding the QA team from delivering on schedule:
Project:
Issue description:
Possible solution:
Issue resolution date:
You can mark these issues in red colour. These are the issues that requires managements help in resolving them.

Issues that management should be aware:
These are the issues that not hold the QA team from delivering on time but management should be aware of them. Mark these issues in Yellow colour. You can use above same template to report them.

Project accomplishments:
Mark them in Green colour. Use below template.
Project:
Accomplishment:
Accomplishment date:

B) Next week Priorities:
Actionable items next week list them in two categories:

1) Pending deliverables: Mark them in blue colour: These are previous weeks deliverables which should get released as soon as possible in this week.
Project:
Work update:
Scheduled date:
Reason for extending:

2) New tasks:
List all next weeks new task here. You can use black colour for this.
Project:
Scheduled Task:
Date of release:

C) Defect status:

Active defects:
List all active defects here with Reporter, Module, Severity, priority, assigned to.

Closed Defects:
List all closed defects with Reporter, Module, Severity, priority, assigned to.

Test cases:
List total number of test cases wrote, test cases passed, test cases failed, test cases to be executed.
This template should give you the overall idea of the status report. Don’t ignore the status report. Even if your managers are not forcing you to write these reports they are most important for your work assessment in future.

Try to follow report writing routine. Use this template or at least try to report it in your own words about the overall work of which you can keep some track.

Do you have any better idea for this routine work? Comment it out!

TIPS TO HANDLE ANY JOB INTERVIEW SUCCESSFULLY

Interviews have always been a nerve racking experience. A situation where you are judged on your performance for a job. Everybody gets the jitters when it comes to interviews. Relax! Don’t panic. You need to overcome the nervousness.

Job Interview Tips and advice Applicable for Any Job Seeker Looking for a Dream Job.

No matter which career path you want to choose below are the best tips to help you land your dream job.

1. Always do your homework well before walking into an interview. Make sure you have complete knowledge about the company and the role.

2. Know yourself. Remember first impression is the last impression. Demonstrate your capabilities and qualities and how well you can serve them. Don’t be overconfident and aggressive.


3. You should know your competency and transferable skills. Competency skills are the skills matching your job profile and transferable skills which you acquired through other jobs, personal activities.

4. Social networking sites like Facebook, Orkut, Linkedin can be used for work opportunities and conversing with other people improving your interpersonal skills.

5. Be clear about what you want to achieve in life and about your career objective. It will keep you focused. You don’t have to do anything for the heck of it.

6. Your CV is vital for a successful interview. Never bluff, include all your skills and experience to give you a competitive edge.

7. Prepare well for an interview. You can make notes of interview questions which are most likely to be asked. Practice your answers. This will boost your confidence.

8. Work on your communication skills. Remember having a good technical knowledge without effective interpersonal skills will not take you anywhere. Be expressive and a good conversationalist. Dazzle the interviewers with eloquent speech.

9. Make sure you can support your strengths by giving examples. You can prepare before but don’t falter while talking. It will not create a good impression.

10. When asked about your weaknesses acknowledge them. If you are not able to describe, it signifies that you lack self awareness. You can’t be perfect in everything.

11. Always be presentable while dressing for the interview. Your attire should be according to the role, culture and yourself. Please no tacky and brash clothing and accessories. You don’t need to be glammed up.

12. Spend time on personal grooming. This will keep you calm. You don’t have to present yourself as a person full of nervous energy and fidgets.

13. On the D day, relax. Be comfortable and wear a smile. And Voila! You will definitely crack the interview.

14. Your body language is very important. Your facial expressions, hand movements, posture, voice and pace should send the same message.

15. Don’t forget to make an eye contact. Your voice should be enthusiastic and do not stammer. Lack of enthusiasm will put off the interviewers.

16. Keep all your documents well organized in a folder. Also be on time, preferably 15 minutes before so you get time to settle down and calm your nerves.

17. Interview manners are very important. Bad manners will definitely be a turn off. Don’t bang the door, shake handily firmly, ask if you can take a seat, sit up straight and do not slouch.

18. When asked about remuneration. You don’t have to be blunt. Instead you can say that you expect a fair raise in terms of qualifications and experience proportionate with peers.
Now that you have some good interview tips. Be confident, gear up and don’t let yourself down.

Remember this is not the end of life if you don’t get through to the process. It’s just an interview. Good Luck!

Saturday, 1 September 2012

TRICKY QUESTION

Define the following along with examples
a. Boundary Value testing
b. Equivalence testing
c. Error Guessing
d. Desk checking
e. Control Flow analysis

Answer:
a) Boundary value Analysis: -
A process of selecting test cases/data by identifying the boundaries that separate valid and invalid conditions. Tests are constructed to test the inside and outside edges of these boundaries, in addition to the actual boundary points. or A selection technique in which test data are chosen to lie along “boundaries” of the input domain [or output range] classes, data structures, procedure parameters, etc. Choices often include maximum, minimum, and trivial values or parameters.
E.g. – Input data 1 to 10 (boundary value) Test input data 0, 1, 2 to 9, 10, 11

b) Equivalence testing: -
The input domain of the system is partitioned into classes of representative values, so that the no of test cases can be limited to one-per-class, which represents the minimum no. of test cases that must be executed.
E.g.- valid data range: 1-10 Test set:-2; 5; 14

c) Error guessing: -
Test data selection technique. The selection criterion is to pick values that seem likely to cause errors Error guessing is based mostly upon experience, with some assistance from other techniques such as boundary value analysis. Based on experience, the test designer guesses the types of errors that could occur in a particular type of software and designs test cases to uncover them. 

E.g. – For example, if any type of resource is allocated dynamically, a good place to look for errors is in the de-allocation of resources. Are all resources correctly deallocated, or are some lost as the software executes?

d) Desk checking: -
Desk checking is conducted by the developer of the system or program. The process involves reviewing the complete product to ensure that it is structurally sound and that the standards and requirements have been met. This is the most traditional means for analyzing a system or program.

e) Control Flow Analysis: -
It is based upon graphical representation of the program process. In control flow analysis; the program  graphs has nodes which represent a statement or segment possibly ending in an unresolved branch. The graph illustrates the flow of program control from one segment to another as illustrated through branches .the objective of control flow analysis is to determine the potential problems in logic branches that might result in a loop condition or improper processing .

INCREMENTAL INTEGRATION AND TESTING

When you are testing a system, you should always adopt an incremental approach where you gradually integrate components from different teams and providers. Sometimes, you develop the overall structure of the system and then add components to it. This is called top-down integration. Alternatively, you may first integrate infrastructure components that provide common services, such as network and database access, then add the functional components. This is bottom-up integration. In practice, for many systems, the integration strategy is a mixture of these, with both infrastructure components and functional components added in increments. In both top-down and bottom-up integration, you usually have to develop additional code to simulate other components and allow the system to execute.

You use an incremental approach to integration to make it easier to discover interaction errors that occur. There are complex interactions between system components and, when an anomalous output is discovered, you may find it hard to identify where the error occurred. Initially, you should integrate a minimal system configuration and test this system. You then add components to this minimal configuration and test after each added increment.

In the example shown in below figure, A, B, C and D are components and T1 to T5 are related sets of tests of the features incorporated in the system. T1, T2 and T3 are first run on a system composed of component A and component B (the minimal system). If these reveal defects, they are corrected. Component C is integrated and T1, T2 and T3 are repeated to ensure that there have not been unexpected interactions with A and B. If problems arise in these tests, this probably means that they are due to interactions with the new component. The source of the problem is localised, thus simplifying defect location and repair. Test set T4 is also run on the system. Finally, component D is integrated and tested using existing and new tests (T5).


UNIT TESTING

Unit testing deals with testing a unit   as a whole. This would test the interaction of many functions but confine the test within one unit. The exact scope of a unit is left to interpretation. Supporting test code, sometimes called scaffolding, may be necessary to support an individual test. This type of testing is driven by the architecture and implementation teams. This focus is also called black-box testing because only the details of the interface are visible to the test. Limits that are global to a unit are tested here.

In the construction industry, scaffolding is a temporary, easy to assemble and disassemble, frame placed around a building to facilitate the construction of the building. The construction workers first build the scaffolding and then the building. Later the scaffolding is removed, exposing the completed building. Similarly, in software testing, one particular test may need some supporting software. This software establishes an environment around the test. Only when this environment is established can a correct evaluation of the test take place. The scaffolding software may establish state and values for data structures as well as providing dummy external functions for the test. Different scaffolding software may be needed from one test to another test. Scaffolding software rarely is considered part of the system.

Sometimes the scaffolding software becomes larger than the system software being tested. Usually the scaffolding software is not of the same quality as the system software and frequently is quite fragile. A small change in the test may lead to much larger changes in the scaffolding.

Internal and unit testing can be automated with the help of coverage tools. A coverage tool analyzes the source code and generates a test that will execute every alternative thread of execution. It is still up to the programmer to combine these test into meaningful cases to validate the result of each thread of execution. Typically, the coverage tool is used in a slightly different way. First the coverage tool is used to augment the source by placing informational prints after each line of code. Then the testing suite is executed generating an audit trail. This audit trail is analyzed and reports the percent of the total system code executed during the test suite. If the coverage is high and the untested source lines are of low impact to the system's overall quality, then no more additional tests are required.