Record and Run in JMeter for Performance Test

JMeter is an open source desktop application available for all. By using Apache JMeter we can perform performance test on a web application. A very short, simple and quick intro available, if you want to check the link.

In this post we will learn how to record a test scenario and run it in Windows. Follow step by step process as describe below,

• Download Apache JMeter.
• Download Java. And install it.
• Unzip Apache JMeter file. And open jmeter.bat.

• Add users by right clicking on the Test plan. Test plan-> Add-> Threads (Users)-> Thread Group.

• Add Thread group name, Number of threads, Ramp up period and Loop count. Remember in JMeter Thread meaning User. Replace thread word with user. Add User group name, Number of users and others. Ramp up period in sec = Ramp up period/ Number of users. Loop count can be forever also. If you use forever loop than you have manually stop the test.

• Go to WorkBench section.

• Right click on Workbench. Add-> Non-Test elements-> HTTP(S) Test Script Recorder.

• Use the Start button at bottom right corner to start recording. And Stop after recording is done.

• In your Mozilla Firefox driver go to Options-> Networks-> Manual proxy. Add localhost in your server field and 8080 in the port number field.

• Add Recording controller. 

• Right click on the Thread group. Add-> Logic controller-> Recording controller.
• Perform the test scenario in the browser.
• After finishing the scenario hit the Stop button in HTTP(S) Test Script Recorder of JMeter.
• Observe that all test steps are added in Recording controller under the Thread group as HTTP requests.

• To view performance results we need to add a report. Listener is report/ output in JMeter.

• Right click on Thread group. Add-> Listener-> Summary report.

• It is a good practice to clear your previous records before saving the test plan. Try to do it every time you save. 
• Save your test plan and hit the play button.
• By hitting the play button you are saying to JMeter, run the recorded test for 50 users. 1 user will be added every second. Running the loop 5 times, that will be 50*5 times for all users.

• After test run process is finish check the Summery report for test data.

Please leave a reply, about this article was helpful or not? Suggestions of improvements are also welcome. Thanks for your time.

Usability hack

User introduction:
I am a facebook user, I spend quality time here. I really enjoy reading blog posts. My friends have same habits like me. I and my friends share share blog posts from various famous blogs to share common interests and interact with each other. Its a regular practice of my to read posts in blogs and share them in facebook for my friends.

User story:
As an user I should be able to view posts which are shared by my facebook friends, in my facebook news feed. When I click on post link it take me to browser which navigate me to that blog post page.

User expectation:
After I click on post link in my facebook news feed I expect it to open in respected application installed in my phone. For example, Business insider blog post should open in installed application of BI android in my phone. But it takes me to browser and then to that link.

User experience findings:
- User uses an Android smart phone
- User have facebook, browser, business insider android applications installed in his/ her phone
- He/ she is a frequent user of internet, smart phone, facebook and business insider
- User goes to blog post from Facebook
- User share posts in Facebook from BI
- User expect better communications between installed applications of his/ her Android phone

User experience report:
- User performing a flow as follows,
  1. Browsing facebook news feed
  2. Going to browse blog post shared in facebook
  3. After reading the post in BI user want to share it in facebook
- User don't like to log in between as its his/ her own phone
- If user performing the full flow in browser with all logged in scenario than user is satisfied
- User finding a bottle neck to perform the full flow within installed applications
- The communication between applications in Android phone need to be improved
- Browser is successful to satisfy the user

Web application testing tool for screen capture

Windows Problem Steps Recorder a very useful tool for web application testing, if you need series of screen shots taken with recorded steps than this is the one you are looking for.

Key features:

1. Record your each and every step
2. Take screen shot of every step taken
3. You can pause and resume your recording any moment
4. You can add comment in your steps
5. 3 different type review system is available thus gives a nice report to understand

Before you start you must tune the setting according to your need. Go to Information drop down menu. Select Settings from following menu,

From Settings set following things according to your need,

• Path to save your recorded file
• Enable/ Disable screenshots
• Number of maximum screen shots allow to take while recording steps

View your recorded steps. It will store as a .zip file when application will save it. Unzip it and it will open in IE with 3 Review options,

1. Review the recorded problem steps
2. Review the recorded problem steps as a slide show
3. Review the additional details

It is a real time savor. Use it, feel free to drop comment if you are facing some problem to use it. I use it daily and it benefits me a lot, specially for test report. It is one of the nice and free tool available around us.

Nascenia IT

My recent blog post on why should we choose Context driven testing approach.

Reporting bugs

This post is on request from one of my fellow colleague come friend, a programmer. And when a programmer is asking a tester to write about bug report than you know it is important. Writing good bug reports is vital let me elaborate you why.

"The true measure of a great tester is that they find bugs, analyze them thoroughly, report them skillfully and end up creating a development team that understands the gaps in their own skill and knowledge." - Dr. James Whittaker(Software Architect @ Microsoft)

Thus a nicely reported bug presents the tester found the bug, analyze it throughly, understand it properly and ready for the debate why it is a bug and why it should be fixed. For your seniors or people in management it represents your ability to think, approach, representation and skills as a tester.

When reporting you can not forget following parameters,

• Summary(Should be nice, clean, simple and self descriptive)
• Description(Steps to reproduce with notes if required for each steps)
• Environment details(Operating system, browser with version, application built number etc.)
• Screenshot(One or more screen shots including indication)

Remember each and every parameters I stated above have its own importance in report. I am considering that first three points need no description of its importance. But I want to add something about the last one, Screenshots. It is more important than you think of it is. Does not matter application developers sitting with you in the same room or in other country. They will refer to the image more than words written in description. Research shows that a human understands 60% more with images rather than descriptive texts.

Feel free to leave a comment. Share your feelings about this post, was it helpful? does it contain ambiguous data? or anything. You are always welcome :)

Selenium simplified tutorial

If you are interested in Selenium Webdriver. Looking for tutorial with good and trusted contents than I have a very special solution for you.

Alan Richardson a very well known tester wrote down a magnificent book called Selenium Simplified. The writer provide a very useful and free course in Udemy and paid course for a more details on Java. Check following links,

Free - https://www.udemy.com/start-using-selenium-webdriver-with-java/

Paid - https://www.udemy.com/selenium-2-webdriver-basics-with-java/

I hope this guideline is helpful for you, feel free to post your comment.

Selenium Test Report

How to see your written scripts of automated Selenium test case results as a report?

You can see a very rich result report by following below instructions. I am assuming you are running Selenium RC(Java) with Eclipse and in Windows. I am also assuming everything is configured thus your environment is ready to roll.

- When running the selenium server write down this code in the terminal
java -jar selenium-server.jar -htmlSuite "<insert_browser_name_here>""<insert_root_domain_here>" "<insert_full_path_to_suite_here>""<insert_a_full_path_to_store_reports_here>"

- For example,
java -jar selenium-server.jar -htmlSuite "*googlechrome""http://www.google.com""c:\ide_scripts\suite.htm""c:\ide_scripts\results.htm"

- After running test cases in the suite you should be able to see following figures(depending on your test cases and results of your suite),

We Agile Testers

There are many types of testings Unit testing, Module testing, System testing, Integration testing, bla bla bla ... ... ... We testers all know what these means and definition, we are always eager to answer what kind of testing means what and we are ready with out armors to fight a war of debates to prove it. A special thanks to ISTQB :) But what happens people found bugs right after the beta release of our tested products? Our manager asking us weird questions, teammates questioning why we missed that, colleagues are blaming and joking, what happens then?

We ask ourselves question, what did I miss? going to our checklists.
- Test cases (Checked)
- Sprint backlogs (Checked)
- Resolved issues (Checked)
- Reopen issues (Checked)
- Unit testing (Checked)
- Module testing (Checked)
- System testing (Checked)
- Integration testing (Checked)
- Load testing (Checked)
- Security testing (Checked)
- Portability testing (Checked) 
...
...
...
and the checklist goes on and if all are checked then we are finding more and more that we have done. Then how do we miss?

We agile testers, are so much concern to test the task or the user story, we often forget to the link between each user stories, how they interact with each other. I am not talking about different units or modules, I am talking about different logic, user stories how they interact, is this what our requirement is or something else?
We agile testers, live in small fragments called sprints and we often forget the whole picture, we often to use our common sense. I am not telling that we cant do that its because of the pressures, we often forgot.

So, what is this post about? its about focusing the whole picture, its about thinking end to end, its about living in the context not in sprints, its not about checking what we have done its about checking what we miss, its not about defects of developers work its about defects in our work, its about us agile testers :)

A simple test case management document

Recently many of my fellow colleagues and friends ask me for a simple test case management document and I gave them. So I thought of this post, lets share it here so if anybody need any information about basic test case management document so they can find here.

Before starting it I want you all to know that this is a very simple syntax, considering only those fields whose are necessary and avoiding others. Though this syntax can vary organization to organization but although it will give you an idea.

A spread sheet can be used to manage your test scenarios/ cases. A test scenario will always have one or more test cases. Its a good practice to break scenarios as small as possible while maintaining a test document.

Each scenario will contain following columns and each row will represent one test case.
- Serial Number(To track down test cases)
- Action(Action need to perform for that particular test case)
- Data(If any data is needed to perform the action of that case)
- Expected Output(Output which is expected for the action)
- Actual Output(Output actually given by the action)
- Result(Can be only Pass or Fail, nothing else)
- Comments(If any comment needed to add for the case)
- Defect(If the result is fail then you should give the link of the reported defect of your issue tracker)

Example:

Test Scenario: Log in

Asking the right question cont.

My previous post was about asking questions, this one is to whom you are asking?

- To know about the business logic more accurately, ask right questions to the Product Owner
- To know about the application behaviors, ask questions to Developers/ Programmers
- To understand what the client need, ask questions to Client/ client representatives
- To understand the budget, time and coverage, ask question to Manager
- What about the question what is tested? why application is doing the right thing? if not then why not?

Whom do you ask these questions? Your senior? Your test manager? Your mentor? or it should be YOU?
To learn and test an application honestly you need to ask questions to your self and give honest answer, don't lie to your self. You will gradually(by time) will become the BEST :)