How loadUI works:

LoadUI consist of building blocks called Components that you drag from the Component Toolbar to the Project you’re working on. These components connect to each other by wires and there is no limit for how many components that you can create and connect.

This way of drag-and-drop testing is especially useful during the test, since you can do complex load tests. The overview that you get makes it easier to try different combinations during the actual test and react to them immediately. In loadUI, Instant feedback is king.

Creating load tests in loadUI:

In order to run a test in loadUI you need at least two components (and an empty Project to work in);

- A generator
Which creates load, for example 100 requests per second.
- A Runner
That runs a certain type of test, for example a web test.

So let’s do it; drag out a Fixed Rate Generator and a Web Page Runner.
You can’t run them yet though first you need to connect them. You do this by connecting the nodes, or terminals, located above and below the components to each other with connections.

So now connect the Fixed Rate Generator to the Web Page Runner.

Now that everything is connected you should enter what website you want to load test into the Web Page Runner. Your test is now ready to run! Click the play button in the top menu to make your generator start sending requests to your site.

You can now follow, in real-time, how the test is going by clicking the Results Workbench button. Once there, double click on your Current Run and, from the left hand menu, drag out Response Time to the rack.

Congratulations! You have now created your first load test in loadUI. Play around with the widgets you have on your dashboard, experiment by adding some more, and try tracking other values in the Results Workbench. A good next step would to add an Assertion component and connecting it to the Web Page Runner. Then you can, for example, test how many times you your requests come through while following certain rules you set up (like taking less than 10 milliseconds).

Pro Tips:

Let a manager test!
This is the modern way of gorilla testing.  Let someone less proficient do the testing for you and see what breaks your service. It will also create an understanding and passion for testing within the management. A usual comment is “This is fun! But hard…”

It’s interactive, use it!
LoadUI is highly interactive and configurable in real-time, so take advantage of that.

Create a second test in real time against the same server with a different Generator and see if the system shows weaknesses when exposes to chaotic, life-like, behavior. Change this in real time and experiment.

Record your tests
Since loadUI is so interactive, reproducing the tests can be difficult. Use a screen recorder like Wink (which is free) to be able to replay your tests and see what caused the service to crash.

Work structured
LoadUI has support for test cases. Break up your tests into smaller test cases; you can always start them all at once.

Don’t double-work
If you have created functional tests in soapUI, you can simply run these in loadUI with the soapUI component. This way you don’t have to redefine the test another time in loadUI.

Write your own component
LoadUI is not only free; it’s open-source, too. That means that you can write your own components, in Groovy, if you wish. Only you set the limits for what is possible in LoadUI! Read more about creating your own components here.

Read more about loadUI, and download it here: Latest loadUI version

**********************************
This is a guest article by Henrik Olsson.
About Author:
Henrik is a software developer for loadUI from Stockholm, Sweden with an academic background in Distributed Systems and a passion for usability. He is experienced in teaching and thinks that most things can be easily explained, if well modeled and accurately targeted.

Editor’s Note:
I’m glad to share this open source load testing tool with my readers. LoadUI and soapUI are the best open source software testing tools from trusted company eviware (now SmartBear). If you are thinking to introduce load testing tool on your project try loadUI and soapUI (functional testing tool).  Also I personally used soapUI  for many projects and will soon cover it in a separate article. I love the power and beauty of these open source tools!

If you used this tool and have some tips to share, please do it in below comment section. Also we would be happy to hear and answer your queries on loadUI.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Load Testing Using loadUI – A Free and Open Source Load Testing Tool

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

There are some important and critical factors related to this major activity.Let us have a bird’s eye view of those factors first.

a. Test Cases are prone to regular revision and update:

We live in a continuously changing world, software are also not immune to changes. Same holds good for requirements and this directly impacts the test cases. Whenever, requirements are altered, TCs need to be updated. Yet, it is not only the change in requirement that may cause revision and update to TCs.

During the execution of TCs, many ideas arise in the mind, many sub-conditions of a single TC cause update and even addition of TCs. Moreover, during regression testing several fixes and/or ripples demand revised or new TCs.

b. Test Cases are prone to distribution among the testers who will execute these:

Of course there is hardly the case that a single tester executes all the TCs. Normally there are several testers who test different modules of a single application. So the TCs are divided among them according to their owned areas of application under test. Some TCs related to integration of application, may be executed by multiple testers while some may be executed only by a single tester.

c. Test Cases are prone to clustering and batching:

It is normal and common that TCs belonging to a single test scenario usually demand their execution in some specific sequence or in the form of group. There may be some TCs pre-requisite of other TCs. Similarly, according to the business logic of AUT, a single TC may contribute in several test conditions and a single test condition may consist of multiple TCs.

d. Test Cases have tendency of inter-dependence:

This is also an interesting and important behavior of TCs that those may be interdependent on each other. In medium to large applications with complex business logic, this tendency is more visible.

The clearest area of any application where this behavior can definitely be observed is the interoperability between different modules of same or even different applications. Simply speaking, wherever the different modules or applications are interdependent, the same behavior is reflected in the TCs.

e. Test Cases are prone to distribution among developers (especially in TC driven development environment):

An important fact about TCs is that these are not only to be utilized by the testers. In normal case, when a bug is under fix by the developers, they are indirectly using the TC to fix the issue. Similarly, where the TCD development is followed, TCs are directly used by the developers to build their logic and cover all scenarios, addressed by TCs, in their code.

So, keeping the above 5 factors in mind, here are some tips to write test cases:

1. Keep it simple but not too simple; make it complex but not too complex:

This statement seems a paradox, but I promise it is not so. Keep all the steps of TCs atomic, precise with correct sequence and with correct mapping to expected results, this is what I mean to make it simple.

Now, making it complex in fact means to make it integrated with the Test Plan and other TCs. Refer to other TCs, relevant artifacts, GUIs etc. where and when required. But do this in balanced way, do not make tester to move to and fro in the pile of documents for completing single test scenario. On the other hand do not even let the tester wish you had documented these TCs in some compact manner. While writing TCs, always remember that you or someone else will have to revise and update these.

2. After documenting Test cases, review once as Tester:

Never think that the job is done once you have written the last TC of the test scenario. Go to the start and review all the TCs once, but not with the mind of TC writer or Testing Planner. Review all TCs with the mind of a tester. Think rationally and try to dry run your TCs. Evaluate that all the Steps you have mentioned are clearly understandable, and expected results are in harmony with those steps.

The test data specified in TCs is feasible not only for actual testers but is according to real time environment too. Ensure that there is no dependency conflict among TCs and also verify that all references to other TCs/artifacts/GUIs are accurate because, testers may be in great trouble otherwise.

3. Bound as well as ease the testers:

Do not leave test data on testers, give them range of inputs especially where calculations are to be performed or application’s behavior is dependent on inputs. You may divide the test item values among them, but never give them liberty to choose the test data items themselves. Because, intentionally or unintentionally, they may use same test data and some important test data may be ignored during the execution of TCs.

Keep the testers eased by organizing TCs according to the testing categories and related areas of application. Clearly instruct and mention which TCs are inter-dependent and/or batched. Similarly, explicitly indicate which TCs are independent and isolated so that tester may manage his overall activity at his or her own will.

4. Be a Contributor:

Never accept the FS or Design Document as it is. Your job is not just to go through the FS and identifying the Test Scenarios. Being a quality related resource, never hesitate to contribute. Suggest to developers too, especially in TC-driven development environment. Suggest the drop-down-lists, calendar controls, selection-list, group radio buttons, more meaningful messages, cautions, prompts, improvements related to usability etc.

5. Never Forget the End User

The most important stakeholder is the ‘End User’ who will actually use the AUT. So, never forget him at any stage of TCs writing. In fact, End User should not be ignored at any stage throughout the SDLC, yet my emphasis so far is just related to my topic. So, during the identification of test scenarios, never overlook those cases which will be mostly used by the user or are business critical even of less frequent use. Imagine yourself as End User, once go through all the TCs and judge the practical value of executing all your documented TCs.

Conclusion:

Test Case Writing is an activity which has solid impact on the whole testing phase. This fact makes the task of documenting TCs, very critical and subtle. So, it should be properly planned first and must be done in well-organized manner. The person who is documenting the TCs must keep in mind that, this activity is not for him or her only, but a whole team including other testers and developers, as well as the customer will be directly and indirectly affected by this work.

So, the due attention must be paid during this activity. “Test Case Document” must be understandable for all of its users, in an unambiguous way and should be easily maintainable. Moreover, TC document must address all important features and should cover all important logical flows of the AUT, with real time and practically acceptable inputs.

What’s your test cases writing strategy? Share your tips with our readers and also put your queries in comments below.

Further reading: How to Write Effective Test Cases

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Tips for Writing Test Cases

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

Do we know what it actually means when we say ‘Thinking out of the Box’?

As per Wikipedia:

“Thinking outside the box is to think differently, unconventionally or from a new perspective. This phrase often refers to novel or creative thinking”

But the above definition could be extended when we relate it to our field, Software Testing.

When we step into the field of software testing the first thing we are taught or we learn are the Two Boxes, a white box and a black box. Since then all we do is either black box or white box testing. This has limited our mind from thinking beyond the boxes. Did we ever think that going beyond these could help us in gaining a higher pace towards a solid career in software testing?

Below we will be discussing a few techniques which I follow and many of my Mentors follow as well,

Rapid Fire Test Case Creation:

This technique, as the name suggests is about rapidly creating test cases. The first thing that comes to our mind when we talk about test case creation is a Requirement Document, an Excel Sheet and some guidelines provided by the organization. For once keep aside all the things, get an idea about what you think you are about to test , Pick up a Pen and a Paper and write as many scenarios you can write within 60 seconds. Repeat the process till you are not able to think of more scenarios or ideas and finally review them.

You will definitely be surprised by the number of ideas you already have without looking into the requirement document.

Cross Testing Ideas(Analogy):

While testing an application, treat it like an entirely different application which you have used before and then start testing. Doing this you might come across issues which are not part of the requirements but is just a common/generic feature which should be present and often overlooked.

For Example: If you are testing a portal, use it like you use your E mail program or any application which you worked on before and see how the application behaves.

I remember exploring a critical defect using this technique. I was testing a secure login of a finance application and tried altering the URL and navigating to a different page (which was a defect in my last tested application). By doing this I was able to bypass the login mechanism using Secure ID and this was neither a test case nor any other team member thought that this could be one of the scenarios.

Reverse or Backward Testing Ideas:

What is the normal work flow you follow while testing?  Isn’t it the exact same steps which were used while developing the application, Requirements >> Unit Cases >> Integration Testing >> System Testing or any other approach?

The minds of the people working on the development of an application are bound to think in the direction which will cover more positive testing. The End User might not do the same every time that is the reason why Production Defects or UAT Defects exists even after extensive rounds of Unit Tests, Integration test and System Tests.

For Example: Requirement says you can upload a file which does not exceed file size of 10 MB. The most testers will follow uploading a 1MB, 2MB, 3 MB and so on till 10 MB is reached or error message is displayed. Why not start with 10MB and then try 11MB and then 9 MB. This example is nothing but a BVA but how many of us have tried using BVA in scenarios other then an input box.

Questioning:

Ideally every QA engineer should know the purpose of a requirement. Putting up questions will help a QA Engineer to refine his purpose of testing. If a QA Engineer is good at questioning he/she will be good at testing by default. You need to make sure none of the questions how so ever small or silly is ignored.

And in turn questioning will also enhance the domain knowledge of the person performing the testing.

Researching:

Researching proves to be very beneficial before starting the testing, just be aware of the issues which other people faced while doing similar assignment. Say you have to start a cross browser testing as one of your assignments. Before starting the tests researching the issues which other people encountered while using the same browser will help you find defects before starting the actual testing.

Pause: an ice breaker

Testing sometimes could be a monotonous process and the ideas may begin to saturate, you might start feeling that none of the solutions are working out or you might even run out of ideas. In such cases an effective Pause can do a lot of wonders and could help you kick start from where you left.

A Pause could be a Coffee or simply gazing out of the window.

Apart from being Creative, timing, speed of implementation of ideas and their execution are of high importance. You might get an excellent idea but what if it is too late to implement it.

Listed above are just a few ideas which will help you generate more ideas in turn.

*****

This is a guest post by Mohit Khatri. Author is specialized in testing Banking Applications, Automation Testing Frameworks and Security Testing. If you want to guest post on this blog, read the guidelines here.

If you have more creative techniques which you think have helped you at any point feel free to share below.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Thinking Out of the Box While Testing Software!

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

Basically we have four different trump suits for you, namely:
Diamonds: For Yourself
Clubs: For Co-Tester you work with
Hearts: For New Tester
Spades: For QA Manager

(Each of the four suits is a different theme, and the software testing ideas get harder as you get towards the Ace)

You can select any trump suit applicable to you. Then read software testing tips from each card and ask yourself if you posses that skill or do you follow that software testing practice. If you have acquired that skill or follow the mentioned testing process then it’s your trump card. Count the number of trump cards from each suit you select. The more number of trump cards you have, the more advance you are in software testing field. You should have at least 10 trump cards from the suit you select to be considered advanced level tester.

You are free to select other trump suits as well. If you are a new tester, obviously you will select suit named “Hearts: For New Tester”. But go on exploring other suits as well and you will get idea what other software testing skills you have, which software testing practices you follow and which skills you have to learn yet.

From each suit you will get 13 valuable software testing tips that you should apply in your daily testing activities.

Here is the ranking of the cards
2 3 4 5 6 7 8 9 10 J Q K A

Starting of the cards will have obviously simple testing skills/practices which gets harder as you get towards the Ace.

Click on your trump suit to get started:
Diamonds: For Yourself
Clubs: For Co-Tester you work with
Hearts: For New Tester
Spades: For QA Manager

So, what’s your score?

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Software Testing Tips from the Game of Cards

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

Each bug listed in this resource can lead to serious software vulnerabilities if not fixed. The top 25 security bugs list will help programmers to avoid some common but serious coding mistakes. For software testers list will be useful as a security testing checklist for Internet as well as for testing desktop application.

Here are few top security vulnerabilities discussed in detail in this article:

•  Improper input validation
•  Improper escaping of output or encoding
•  SQL injection
•  Cross-site scripting
•  Race conditions
•  Information leak in error messages
•  Error while transmitting sensitive information
•  Memory leak
•  External control of critical data and file paths
•  Improper initialization
•  Improper authorization
•  Client side security checks

I think, the most common security vulnerability mistake developers make is “Client side enforcement of server side security”.

Check out below article so that you can at least help developers for improving their code standards

Top 25 common programming Errors

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Top 25 common programming bugs every tester should know

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

Here is the recap of some popular posts from year 2008. I know it’s very difficult to select few posts to show here. Still these are some most popular posts, in random order, you can enjoy. Don’t forget to bookmark this page

How to get your all bugs resolved without any ‘Invalid bug’ label?
I hate “Invalid bug” label from developers for the bugs reported by me, do you? I think every tester should try to get his/her all bugs resolved. This requires bug reporting skill. Check out this article to know what troubleshooting you need to do before reporting any bug.

Software testing questions and answers
This was a very successful article on reader’s queries on software testing. Read the answers and ping me if you have any questions.

Learning basics of QTP automation tool and preparation of QTP interview questions
This post is in continuation with QTP interview questions series. These questions will help for preparing interview as well as learning the QTP basics.

Developers are not good testers. What you say?
Developers test their own code. Then why testers needed? What are the drawbacks of developer testing his own code? Why can’t it be a success? If developer testing is always not sufficient testing then what things developers should test and what the test team should? To know answers to these questions read on.

Top 20 practical software testing tips you should read before testing any application.
This is a collection of top 20 practical testing tips for testing any product or web based application I learned over time. I wish all testers read these software testing good practices and try to implement them in your day to day software testing activities.

Global Software Testing business to reach $13 Billion – Good news for Indian software Testers
The most frequently asked questions to me till date are – What is the future of software testing business?, Should I consider software testing as my career option? – Now you don’t need to ask these question to me any more. See what was the good news in this post.

Tips to design test data before executing your test cases
I have mentioned importance of proper test data in many of my previous articles. Tester should check and update the test data before execution of any test case. In this article I will provide tips on how to prepare test environment so that any important test case will not be missed.

Check your eligibility for CSTE certification. Take this sample CSTE examination
CSTE testing certification is the basic certification to check testers skill and understanding of software testing theory and software testing practices. If you are applying for CSTE certification check if you can answer at least 75% of the test questions mentioned in this post.

What you need to know about BVT (Build Verification Testing)
Build Verification test is a set of tests run on every new build to verify that build is testable before it is released to test team for further testing. Read on to know how to perform BVT effectively.

Manual and Automation testing Challenges
Software testing is full of challenges. Testers face many challenges in manual as well as automation testing. Tester who manages to address these challenges effectively can become successful tester. In this article I have included most of the testing challenges you need to overcome.

Smoke testing and sanity testing – Quick and simple differences
Despite of hundreds of web articles on Smoke and sanity testing, many people still have confusion between these terms and keep on asking to me. Here is a simple and understandable difference that can clear your confusion between smoke testing and sanity testing.

An approach for Security Testing of Web Applications
How to make sure your web application is secure before release? Web site security testing is important part of software testing life cycle like other functionality and performance testing. This article will guide you with different type of attacks on web applications and information on how to test web application for security.

Some Interesting Articles on Software Testing Career:

How to prepare for software testing interview
This article will help for preparation of software testing interview for freshers as well as working testing professional who want to switch their current job. Know the key areas you need to prepare and how to keep yourself updated on testing methodologies.

Career options for Software Test Professionals
See what are the career options for software testing professionals. Great article showing all the possible career paths for software tester.

Software Testing Advice for Novice Testers
Novice testers have many questions about software testing and the actual work that they are going to perform.  As novice testers, you should be aware of certain facts in the software testing profession.  The tips mentioned here will certainly help to advance you in your software-testing career

Money making, software testing career and secrets of a richest tester
These days a lot of people who pass out of engineering and science colleges are interested about software testing as a career. Also today there isn’t a huge difference between what testers and developers get paid. How can testers make more money than what they have been making.

How to keep motivation alive in software testers?
The title says all about the post content. Know what are the different ways to keep motivation alive in software testers.

How to build a successful QA team?
There are plenty of things to be considered while building successful software testing team. After reading this article look at your team and question yourself “Are you working in great test team” or ” Will you make every effort to build great test team”.

Apart from software testing articles we also covered some topics on soft skills for testers:

How to ask for promotion and salary raise in this appraisal?
Yearly performance appraisal review is the key process to major employee performance and reward him/her by promotion or salary raise based on the performance. If you think you are eligible for this reward then read this article to know on what basis your performance is majored and how to put your best efforts to get salary raise and promotion.

How to keep good testers in testing positions?
Here I have answered one interesting reader’s question “how to keep good testers in testing positions?” Nowadays due to high compensation packages it’s really hard to keep good testers in testing. Many of the really skilled testers are always looking for switch. Here are some ideas on how to keep good testers in testing positions.

Top Three Tips to Survive in this Recession – Economic Downtime
Everyone is talking about recession. Many of your close friends might have experienced this. Everyday we hear news about pink slips, reduction in IT recruitment, bleak prospects etc. How software testers can survive in this recession? Here are three simple and effective tips to survive in this recession.

How to crack the GD (Group Discussion). 10 simple ways with ppt on GD
Software tester needs to communicate with project members like team members, developers, managers and customer. For an effective team player you should have command over communication and interpersonal skill. Read the top 10 simple ways to crack the GD.

Soft Skill for testers: How to improve communication skill
Good communication skill is a must for software testers. You might have seen this line in every job requirements especially openings in QA and testing field. As a tester you need to communicate with different project team members including clients, communication skill plays important role. Read this post if you want to improve your communication skill.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Best software testing articles of 2008

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

Know Your Application
Don’t start testing without understanding the requirements.  If you test without knowledge of the requirements, you will not be able to determine if a program is functioning as designed and you will not be able to tell if required functionality is missing.  Clear knowledge of requirements, before starting testing, is a must for any tester.

Know Your Domain
As I have said many times, you should acquire a thorough knowledge of the domain on which you are working.  Knowing the domain will help you suggest good bug solutions.  Your test manager will appreciate your suggestions, if you have valid points to make.  Don’t stop by only logging the bug.  Provide solutions as well.  Good domain knowledge will also help you to design better test cases with maximum test coverage.  For more guidance on acquiring domain knowledge, read this post.

No Assumptions In Testing
Don’t start testing with the assumption that there will be no errors.  As a tester, you should always be looking for errors.

Learn New Technologies
No doubt, old testing techniques still play a vital role in day-to-day testing, but try to introduce new testing procedures that work for you.  Don’t rely on book knowledge.  Be practical. Your new testing ideas may work amazingly for you.

You Can’t Guarantee a Bug Free Application
No matter how much testing you perform, you can’t guarantee a 100% bug free application.  There are some constraints that may force your team to advance a product to the next level, knowing some common or low priority issues remain. Try to explore as many bugs as you can, but prioritize your efforts on basic and crucial functions.  Put your best efforts doing good work.

Think Like An End User
This is my top piece of advice.  Don’t think only like a technical guy.  Think like customers or end users.  Also, always think beyond your end users.  Test your application as an end user.  Think how an end user will be using your application.  Technical plus end user thinking will assure that your application is user friendly and will pass acceptance tests easily.  This was the first advice to me from my test manager when I was a novice tester.

100% Test Coverage Is Not Possible
Don’t obsess about 100% test coverage.  There are millions of inputs and test combinations that are simply impossible to cover.  Use techniques like boundary value analysis and equivalence partitioning testing to limit your test cases to manageable sizes.

Build Good Relations With Developers
As a tester, you communicate with many other team members, especially developers. There are many situations where tester and developer may not agree on certain points.  It will take your skill to handle such situations without harming a good relationship with the developer.  If you are wrong, admit it.  If you are right, be diplomatic.  Don’t take it personally.  After all, it is a profession, and you both want a good product.

Learn From Mistakes
As a novice, you will make mistakes.  If you don’t make mistakes, you are not testing hard enough!  You will learn things as you get experience.  Use these mistakes as your learning experience.  Try not to repeat the same mistakes.  It hurts when the client files any bug in an application tested by you.  It is definitely an embracing situation for you and cannot be avoided.  However, don’t beat yourself up.  Find the root cause of the failure. Try to find out why you didn’t find that bug, and avoid the same mistake in the future.  If required, change some testing procedures you are following.

Don’t Underestimate Yourself if Some of Your bugs Are Not Fixed
Some testers have assumptions that all bugs logged by them should get fixed.  It is a good point to a certain level but you must be flexible according to the situation.  All bugs may or may not be fixed.  Management can defer bugs to fix later as some bugs have low priority, low severity or no time to fix.  Over time you will also learn which bugs can be deferred until the next release.  Read article on ‘How to get all your bugs resolved‘.

Over To You:
If you are an experienced tester, what advice do you like to give to novice testers?

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Software Testing Advice for Novice Testers

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

How to improve testing by maximizing code coverage – A practical approach.

Article Summary:

As a white box tester your first goal should be maximizing code coverage!

Increasing code coverage is the route to improved testing. Code coverage is always a critical testing path and creating good test data for maximum code coverage is another difficult task.

Testers need to balance the need for complete coverage with only limited time to test. The key challenge here is to be more efficient and more effective.

Should 100% code coverage be the testing goal?

According to Huw Price, 90% code coverage would be the maximum that can be expected. A more effective and realistic goal, however, is a 100% functional coverage.

How to create test data for code coverage testing?

Here are the three approaches discussed in detail:

• Creating the data using the application
• Searching for data that matches your criteria: Copy production data to development and testing environment.
• Hacking existing data: Just go and edit the existing data to fit to your test cases.

This white paper discusses some techniques and tools to build the most accurate input to tests and also the practical methods and tools of creating the data to run these test. Simply building an optimized set of inputs is just the start of a solution.

Huw Price has explained code coverage and test data creation methods with simple examples. I can only say, a nice article for white box testers.

Download this white paper from following link:
Code coverage testing

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Practical approaches to improving your testing by maximizing code coverage [White paper for download]

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

Here are some of the best testing practices I learned by experience:

1) Learn to analyze your test results thoroughly. Do not ignore the test result. The final test result may be ‘pass’ or ‘fail’ but troubleshooting the root cause of ‘fail’ will lead you to the solution of the problem. Testers will be respected if they not only log the bugs but also provide solutions.

2) Learn to maximize the test coverage every time you test any application. Though 100 percent test coverage might not be possible still you can always try to reach near it.

3) To ensure maximum test coverage break your application under test (AUT) into smaller functional modules. Write test cases on such individual unit modules. Also if possible break these modules into smaller parts.
E.g: Lets assume you have divided your website application in modules and ‘accepting user information’ is one of the modules. You can break this ‘User information’ screen into smaller parts for writing test cases: Parts like UI testing, security testing, functional testing of the ‘User information’ form etc. Apply all form field type and size tests, negative and validation tests on input fields and write all such test cases for maximum coverage.

4) While writing test cases, write test cases for intended functionality first i.e. for valid conditions according to requirements. Then write test cases for invalid conditions. This will cover expected as well unexpected behavior of application under test.

5) Think positive. Start testing the application by intend of finding bugs/errors. Don’t think beforehand that there will not be any bugs in the application. If you test the application by intention of finding bugs you will definitely succeed to find those subtle bugs also.

6) Write your test cases in requirement analysis and design phase itself. This way you can ensure all the requirements are testable.

7) Make your test cases available to developers prior to coding. Don’t keep your test cases with you waiting to get final application release for testing, thinking that you can log more bugs. Let developers analyze your test cases thoroughly to develop quality application. This will also save the re-work time.

8 ) If possible identify and group your test cases for regression testing. This will ensure quick and effective manual regression testing.

9) Applications requiring critical response time should be thoroughly tested for performance. Performance testing is the critical part of many applications. In manual testing this is mostly ignored part by testers due to lack of required performance testing large data volume. Find out ways to test your application for performance. If not possible to create test data manually then write some basic scripts to create test data for performance test or ask developers to write one for you.

10) Programmers should not test their own code. As discussed in our previous post, basic unit testing of developed application should be enough for developers to release the application for testers. But you (testers) should not force developers to release the product for testing. Let them take their own time. Everyone from lead to manger know when the module/update is released for testing and they can estimate the testing time accordingly. This is a typical situation in agile project environment.

11) Go beyond requirement testing. Test application for what it is not supposed to do.

12) While doing regression testing use previous bug graph (Bug graph – number of bugs found against time for different modules). This module-wise bug graph can be useful to predict the most probable bug part of the application.

13) Note down the new terms, concepts you learn while testing. Keep a text file open while testing an application. Note down the testing progress, observations in it. Use these notepad observations while preparing final test release report. This good habit will help you to provide the complete unambiguous test report and release details.

14) Many times testers or developers make changes in code base for application under test. This is required step in development or testing environment to avoid execution of live transaction processing like in banking projects. Note down all such code changes done for testing purpose and at the time of final release make sure you have removed all these changes from final client side deployment file resources.

15) Keep developers away from test environment. This is required step to detect any configuration changes missing in release or deployment document. Some times developers do some system or application configuration changes but forget to mention those in deployment steps. If developers don’t have access to testing environment they will not do any such changes accidentally on test environment and these missing things can be captured at the right place.

16) It’s a good practice to involve testers right from software requirement and design phase. These way testers can get knowledge of application dependability resulting in detailed test coverage. If you are not being asked to be part of this development cycle then make request to your lead or manager to involve your testing team in all decision making processes or meetings.

17) Testing teams should share best testing practices, experience with other teams in their organization.

18) Increase your conversation with developers to know more about the product. Whenever possible make face-to-face communication for resolving disputes quickly and to avoid any misunderstandings. But also when you understand the requirement or resolve any dispute – make sure to communicate the same over written communication ways like emails. Do not keep any thing verbal.

19) Don’t run out of time to do high priority testing tasks. Prioritize your testing work from high to low priority and plan your work accordingly. Analyze all associated risks to prioritize your work.

20) Write clear, descriptive, unambiguous bug report. Do not only provide the bug symptoms but also provide the effect of the bug and all possible solutions.

Don’t forget testing is a creative and challenging task. Finally it depends on your skill and experience, how you handle this challenge.

Over to you:

Sharing your own testing experience, tips or testing secrets in comments below will definitely make this article more interesting and helpful!!

If you are not regular reader of this website then highly recommend you to sign up for our free email newsletter! Sign up just providing your email address below:

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
Top 20 practical software testing tips you should read before testing any application.

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.

These days a number of web sites are deployed in multiple languages. As companies perform more and more business in other countries, the number of such global multi-lingual web applications will continue to increase.

Testing web sites supporting multiple languages has its own fair share of challenges. In this article, I will share seven tips with you that will enable you to test the multi-lingual browser-based applications in a complete way:

Tip # 1 – Prepare and use the required test environment

If a web site is hosted in English and Japanese languages, it is not enough to simply change the default browser language and perform identical tests in both the languages. Depending on its implementation, a web site may figure out the correct language for its interface from the browser language setting, the regional and language settings of the machine, a configuration in the web application or other factors. Therefore, in order to perform a realistic test, it is imperative that the web site be tested from two machines – one with the English operating system and one with the Japanese operating system. You might want to keep the default settings on each machine since many users do not change the default settings on their machines.

Tip # 2 – Acquire correct translations

A native speaker of the language, belonging to the same region as the users, is usually the best resource to provide translations that are accurate in both meaning as well as context. If such a person is not available to provide you the translations of the text, you might have to depend on automated web translations available on web sites like wordreference.com and dictionary.com. It is a good idea to compare automated translations from multiple sources before using them in the test.

Tip # 3 – Get really comfortable with the application

Since you might not know the languages supported by the web site, it is always a good idea for you to be very conversant with the functionality of the web site. Execute the test cases in the English version of the site a number of times. This will help you find your way easily within the other language version. Otherwise, you might have to keep the English version of the site open in another browser in order to figure out how to proceed in the other language version (and this could slow you down).

Tip # 4 – Start with testing the labels

You could start testing the other language version of the web site by first looking at all the labels. Labels are the more static items in the web site. English labels are usually short and translated labels tend to expand. It is important to spot any issues related to label truncation, overlay on/ under other controls, incorrect word wrapping etc. It is even more important to compare the labels with their translations in the other language.

Tip # 5 – Move on to the other controls

Next, you could move on to checking the other controls for correct translations and any user interface issues. It is important that the web site provides correct error messages in the other language. The test should include generating all the error messages. Usually for any text that is not translated, three possibilities exist. The text will be missing or its English equivalent will be present or you will see junk characters in its place.

Tip # 6 – Do test the data

Usually, multi-lingual web sites store the data in the UTF-8 Unicode encoding format. To check the character encoding for your website in mozilla: go to View -> Character Encoding and in IE go to View -> Encoding. Data in different languages can be easily represented in this format. Make sure to check the input data. It should be possible to enter data in the other language in the web site. The data displayed by the web site should be correct. The output data should be compared with its translation.

Tip # 7 – Be aware of cultural issues

A challenge in testing multi-lingual web sites is that each language might be meant for users from a particular culture. Many things such as preferred (and not preferred) colors, text direction (this can be left to right, right to left or top to bottom), format of salutations and addresses, measures, currency etc. are different in different cultures. Not only should the other language version of the web site provide correct translations, other elements of the user interface e.g. text direction, currency symbol, date format etc. should also be correct.

As you might have gathered from the tips given above, using the correct test environment and acquiring correct translations is critical in performing a successful test of other language versions of a web site.

It would be interesting to know your experience on testing multi-language web sites.

---------------------
I just wanted to thank you for subscribing to SoftwareTestingHelp.com. This blog is a success because of you and your support. Here's to your success!

As always, I appreciate your valuable comments. Visit below link to post your comment:
7 basic tips for testing multi-lingual web sites

Thank you so much! ---------------------
Recommended: TestLodge - Online test case management tool - Web based test case management software allowing you to manage your test plans, requirements, test cases and test runs with ease.