Where we learn technology

Month: March 2018



JMeter is one of the most popular, open source performance testing tools among the software testing professionals around the world. There are number of reasons for JMeter to be popular. We shall share some of the reasons in this post.

Scripting knowledge is not required to build test plans

Test scripting is not essential to build performance testing test plans. Test plans can be built by adding and configuring  available components in JMeter IDE. This allows beginners to create effective performance test plans without any scripting.
Learning or mastering a tool is not sufficient for a successful performance testing projects. Good understanding of the context, test planning, test design, test execution and test reporting is essential for a successful performance testing project.

JMeter supports multiple scripting languages 

JMeter do support the scripting. Advance users can use the scripting (example Java, Groovy, BeanShell scripting) to extend the ability of JMeter.
JMeter support number of scripting languages out of the box. It can support JSR223-compatible languages not configured with default settings. There are other languages supported than those that appear in the component drop-down list. Others may be available if the appropriate jar is installed in the JMeter lib directory

JMeter is free and open source

JMeter is an Apache project. The source is available to the community. JMeter source code can be modified and built for specific needs if required.

It can run on any platform 

JMeter is developed using Java. Java applications can run on any platforms. Hence JMeter can be used on Windows, Mac , Linux or any other operating system when compatible JVM is available. 

Free support 

There is a huge community around the tool. There are active user groups in LinkedIN, Facebook , StackOverflow etc. Questions are answered within acceptable time period. The users can rely on the community for support questions.
There are organizations who provides commercial support too. 

Customized reports can be generated 

Reporting is one of the poor feature available in open source tools as compared to the commercial tools. Fortunately JMeter supports various reporting formats through available listeners and plugins. Also the test results can be upload to external reporting tools and generate commercial grade elegant reports.
There are number of listeners available out of the box for saving the test results. Test results can be loaded into the listeners to view the test results later too. 
The test results can be loaded into third party tools (example blazemeter ) and generate the test reports.
There are number of plugins available for reporting.

Real world workloads can be simulated

It is possible to simulate various workloads using ThreadGroups, timers ,Logical controllers and config elements. Different users’ dynamic thinking timing can be simulated using wide range of available timers and third party plugins 
User concurrency ,number of virtual users can be simulated using thread groups.
Throughputs ,

JMeter supports many protocols

Jmeter supports not only the web applications.  It supports wide range of applications, protocols and servers. Here is the list extracted from the official site.
  • Web – HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, …)
  • SOAP / REST Webservices
  • FTP
  • Database via JDBC
  • LDAP
  • Message-oriented middleware (MOM) via JMS
  • Mail – SMTP(S), POP3(S) and IMAP(S)
  • Native commands or shell scripts
  • TCP
  • Java Objects

Easy to create the test plans

Test plans creation can be started with recording feature available with JMeter. Also BabBoy software can be used for exporting the recorded flows into JMeter test plans. Some commercial tools based on Jmeter can be used for creating the JMeter scripts easily. Fore example Blazemeter’s Chrome plugin.

Distributed Testing 

JMeter can be used for simulating large number of users accessing the system concurrently or simultaneously. Virtual users will have to be distributed among few load agent as one machine may not be able to create all required threads (virtual users)

Mobile application testing is supported 

JMeter can be used for recording the requests sent from the device to the servers through its proxy configuration. Hence JMeter can be used to record the requests from mobile applications and web applications running on Android and iOS devices.

Comprehensive documentation 

JMeter has comprehensive documentation available online. It covers from installation, configuration, creating basic test plans , components reference, best practices , extending JMeter and much more. 
Component references, function references etc can be accessed readily from context menu, shortcuts or menu. A copy of user manual and api documentation is shipped with the installation and available for offline access.

User friendly IDE 

JMeter GUI is very user friendly. Components can be added by just right clicking a node in the test plan. Components can be configured easily by filling the placeholders (input boxes ). 
GUI can be customized further for user need by configuring the properties ( in bin/JMeter.properties file). For example toolbar  display, look and feel, proffered GUI language can be customized by updating the respective properties in the property file.

Free learning material

A beginner can start with JMeter through self 
There are good collection of free online documentation , blogs , Q&As and videos available. There are paid online and public training programs available around the world.

Third party plugins

JMeter capabilities can be extended through pluggable components (samplers , timers , listeners etc). Free custom JMeter plugins can be accessed from https://jmeter-plugins.org/. The plugins can be managed (install, uninstall) easily through the plugin manager interface.
User has access for commercial plugins covering custom features. For example UBIK Load Pack Plugins. https://ubikloadpack.com/. UBIK also do custom JMeter plugin development on demand too. 

Highly customizable

Please follow and like us:

Have QA testers lost respect?

Have QA testers lost respect?

With the increase in the need for speed to market and the popularity of more flexible agile software methodologies, the large QA team has largely disappeared over the past 20 years. Those 50-to-100-person QA teams—with separate management, directors, and full testing cycles—are mostly gone.
Large teams still exist in some cases, but they’re mostly in businesses that are highly regulated, where QA testers help verify that requirements and quality processes are met.
For the rest of us—the QA software testers who are now part of development teams—the change has been interesting. In many of today’s leading technology companies, the shift away from more formal QA software testing practices is widespread.
Is the QA profession losing respect or being replaced in the name of speed and efficiency?

No respect lost: It’s about productivity

Overall, the change from large, independent QA teams to QA team members as coders, or as testers within a development team, is not due to a loss of respect for the QA profession. It’s a cost and efficiency improvement.  
Does any company hire a QA tester first? No. It hires developers and product managers first. Is that a lack of respect? No, it’s realistic. After all, the application has to be developed and exist before QA testing is even necessary. Granted, the sooner the QA testing starts, the more time testers have to learn the system as it’s being developed.  
In today’s reality, if a QA tester is hired at all, it’s typically right before an application is set to initially release. Perhaps that’s a loss of respect for the business value of a QA tester. But consider that the company has hired a QA software tester, and that act alone—regardless of the timing—means management believes there is value in QA testing.  

Testing pro wanted: What’s in a job description?

Over the course of my career, I’ve experienced both working on large QA teams and being an independent QA tester assigned to one or more agile development teams. I wholeheartedly prefer the latter. 
The QA professional is a software development team member who performs manual, feature, and functional testing. The QA pro who focuses on QA—as in auditing compliance with regulatory requirements—is a separate function.
Large software companies such as Google, Facebook, and Microsoft use SDETs—software development engineers in test—to create unit and automated tests at the code level. Any additional testing, for features and functionality, is performed manually. Software testing is also largely done continuously these days, rather than during a defined test cycle.
Exploratory testing is the modern manual testing technique most used in practice. It is valuable for regression testing, as well as for testing features (requirements or acceptance criteria for stories), and for general system functional testing.

Why large teams fail

Large QA testing teams fail because they’re simply not efficient or effective. Software testing is an integral part of development, not a separate function. Politics among managers, leads, and QA members means that leadership, QA processes, and functions are constantly changing to the point of consistent chaos within large teams. 
No one QA tester can keep up with testing and the need to learn and apply automated testing, along with the constant change of QA process requirements and demands to keep up with manual testing simultaneously. What happens in large QA teams is that every team member forges his or her own path.
In other words, you develop a personal test methodology that best suits your understanding of the application, personal integrity, and ability to work constructively with development. You function inside the team, but every QA is marching to his or her own drum, attempting to focus on testing rather than the persistent, chaotic static from large QA team management.  
Today’s application development companies are focused on efficiency, costs, and results. Testing effectiveness is hard to prove, but proving that testing is worthwhile is not difficult. The QA profession losing respect is less about testing being unnecessary and more about being effective at finding relevant defects quickly and continuously.
QA respect is literally bound into results. How many and what types of bugs are found? How is QA helping developers create successful features? How often does a QA ask questions about the application design before or during development? QA respect is gained by proving QA testing is a worthwhile cost to the company.

Who needs testers?

Development and testing are separate functions, but they can be combined, as they often are, when a QA professional becomes an SDET. SDETs create code-based automation scripts and likely code when needed, and they test manually as necessary. The problem with relying solely on developer-based testing is that developers design code, test their code, and merge the code into a build.  
Developers generally tend not to use the application as an end user but focus on how the code executes in the background. Same with automated test developers. In practice, it becomes more important to management to meet deadlines, and over time, it is more important that unit and automated tests pass so the application can release, rather than verifying that the end-user experience performs as expected.  
The missing piece is an independent test of the application functionality performed by a resource who did not create it and isn’t responsible for making sure the automated and unit tests pass.   

Tips for proving a QA tester’s worth

Being the QA tester on a development team ensures that you’ll need to prove your worth by testing with an end-user perspective—not by counting defects entered or reported by customers, but rather by becoming an active, integrated team member focused on testing for the end user. In order to prove that QA testing is valuable, you need to find workflow or integration defects in the application and be able to constructively work with developers to correct them.  
The psychology of testing comes into play when you feel threatened, or less than others. Start by dropping the ego. Let go of the need to be the most important resource in the company, and be secure in your knowledge and your function as a tester. Ask questions of everyone on the team when you don’t understand a story, a fix, or even the acceptance criteria. Bring it up when there are contradictions in the story, or when you see that a developer and a business analyst or product manager are not on the same page. Focus on protecting the end user from defects, regardless of the cause.
QA testers must be courageous and secure with their professional worth. It’s okay if you’re wrong. You’ll gain more by asking questions, dumb or otherwise, then you will by worrying about whether your role is respected. Don’t stop at asking questions; listen to the response, fully and completely. By asking and listening, you’re respecting your team members’ knowledge and encouraging a work rapport. Respect is earned over time. QA testers gain respect by preventing end-user defects.  
Improve your QA testing worth by not avoiding difficult testing tasks. Don’t be the QA who only tests the surface of the application repeatedly. Stretch your abilities, and tackle the hard, brain-pounding items with enthusiasm. Take opportunities to expand your skills and understanding.  
I often see QA testers avoid a story or project that’s difficult—whether it’s the developer doing the work or the subject matter. QA respect is gained from hard work and perseverance. Remember to let go of your ego, set your priorities, and test. Ask, listen, and learn, and don’t fear being honest when you don’t understand. Respect is earned over time and by not being afraid to tackle difficult testing tasks.  
QA testers who lose professional respect are those who:
  • Sit back and let others do the work.
  • Surf the Internet or waste time while they wait for stories to come through, rather than continuing to test or testing continuously.
  • Don’t stretch their abilities and only want the easy items.
  • Restrict how many tests they’ll execute.
  • Are always afraid to bring up questions and concerns or to express ideas.
  • Blame the developer, business analyst, or product manager for defects.
Do the profession a favor: Test your heart out, tackle anything, and let your ego go, so you can work with other team members at a quick, constructive pace and provide the highest business value. That’s how testers will continue to command respect.

Naveen AutomationLabs
Please follow and like us: