SUBSCRIBE TO MY CHANNEL

Five Test Automation Mistakes to Avoid - Must watch for testers!

How to be successful QA leader? - Future leaders, QA Leads and Managers

LATEST THINKING

Wednesday, June 22, 2016

Master API Test Automation in 10 Minutes!

6:20:00 PM Posted by Prashant Hegde 14 comments


Postman is a Google Chrome app that helps you to create, save, send HTTP requests and test the response data.  It helps to automate the process of making API requests and testing API responses, allowing testers to establish a very efficient workflow. Most programmers and testers are familiar with Postman. However, many use it just to check the response for the services that they are working on. They are unaware of the powerful features that postman offers like: Collections, Tests and pre-request scripts. In this article, I would like to give a quick overview of the test snippets provided by Postman.
Postman is a real time saver making it easier for developers to develop and test APIs. Postman drastically reduces the pressure of regression testing from the QA team. API automated tests are far less time consuming than UI automated tests. The major advantage of API automation is that we can access the application without a user interface. This provides an early evaluation of its overall build strength before running GUI tests.
By integrating the API automated tests to the build server, the QA team can provide a quick feedback on the health of the application as soon as it is deployed. This is achievable with Newman, a command-line collection runner for Postman. It allows you to easily run a Postman collection directly from the command-line, and integrate it with your continuous integration server.
The main reason I like Postman is because of its powerful automation capabilities. Moreover, the learning curve for using it is very low and the app provides a very clean and intuitive user interface to test your server requests. These tests will validate every single time if the response is correct. Writing tests in Postman is made easy by JavaScript and inbuilt snippets, allowing any inexperienced tester to write an efficient test.
Click on the link below to know more:

Thursday, June 2, 2016

6 Lessons from a 6-Month-Old QA Engineer

1:00:00 AM Posted by Prashant Hegde 4 comments

GUEST POST FROM URIDAH SAMI


It’s my 7th month as a Quality Assurance Engineer and I started this blog a couple of months ago. My first post was Diving into QA which was about how/why I started a career in Quality Assurance. For a few weeks now, I have been struggling to write another post but everything I come up with is disregarded (by me, of course!) because there are so many more experienced, much smarter and way better QA writers out there who have already covered what I want to talk about and maybe what I write wouldn’t stand out as I want it to. But recently, I just stumbled upon this idea that to keep things fresh and real, why not share my lessons from my short journey so far. So, here is a list of things that I have picked so far:
  • Pre-requisite for a QA Engineer: Good Communication Skills
This is the first point because this is the most important skill, a tester or any professional for that matter, has to have.
“Communication is everyone’s panacea for everything.” – Tom Peters
No matter how good a tester you are, you are not going anywhere without good communication skills. Everything you do, you are going to have to utilize those communication skills if you want your work to matter, whether you are writing a bug report or just discussing an improvement with your developer.
  • Developers and QA Engineers are not rivals
Commonly, we are led to believe that developers/software engineers and testers/QA engineers are rivals. To be honest, it sounds natural and right because one makes and the other breaks. But that is NOT true. It’s one of those tricky cases where you think one thing is right but actually the opposite of it is right. Although, it also depends on the way work is done in an organization.
In Agile environment, developers and testers work together closely to create a better quality product. Both of them are involved throughout the SDLC and can cooperate better to ensure that their time and energy is spent towards the betterment of the product or the solution being built.
  • The more detail-oriented you are, the better it is
In my opinion, it is very beneficial if a QA Engineer is detail oriented. I wouldn’t call it a must-have skill, but it definitely improves the work a lot. It all basically boils down to how in-depth your exploratory testing is. Detailed exploratory testing results in better knowledge of the system for the QA Engineer and when you have more knowledge, you can automatically test better since you know how different features are linked, what are the different ways in which a functionality works and hitting where might lead you to a potential bug and what its cause might be.
  • Spending more time pays off later
Here comes our famous “Time is Money” quote. And consider it as an investment instead of saving, here. I believe you have to invest time to do good testing. The more time you invest, the more probability of a better output you have. Just to clarify, this doesn’t mean running time-consuming test cases. It means spending time on exploring the system and testing as many features as you can and ensuring maximum coverage.
  • Making the choice between Manual or Automated testing
Learning to make the right choice between manual or automated testing is the key to efficient testing. I am using the word efficient here because your testing should be good and quick (in comparison). Some test cases would take less time if you automate them, especially the ones you know are going to run again and again for regression or smoke testing. Then, there are some test cases which SHOULD NOT be automated. There is no replacement for an actual human being and that is why we NEED manual testing. It is better if you manually test critical functionalities and observe how things work. Moreover, there are some tests that just become more time consuming if they are automated.
  • Testing is a skill
It’s a general misconception that testing needs mere common sense and anybody can do it. Testing is a proper skill which can be learned and polished. I’d like to quote one of James Bach’s amazing metaphors here:
“It’s like somebody trying to fly a helicopter saying “I keep crashing it and I don’t understand.“ “Have you taken any Helicopter:How to fly classes?” “Well, No! But you know it should be just common sense” “
Similarly, testing is not that easy. You have to understand different types of testing, you have to develop an understanding of the system or solution, you are testing and then you might also have to trace a bug back to its root cause. It takes a lot more than just common sense to achieve that. Also, I believe you also have to have a “testing mindset”. You need to have a mindset where you try out all options and question everything to ensure maximum coverage. I like to call it ‘playing around’. You have to play around and try and make as much of a mess as you can, to the point that no more mess can be made.
And there you have it! These are some of the things most QA Engineers, globally, irrespective of their company domain will find themselves learning when they start out. If you are an aspiring QA Engineer, keeping these points in mind will definitely help you on your testing journey!

ABOUT THE AUTHOR


Uridah works as a Software Quality Assurance Engineer and thoroughly enjoys the madness associated with it. She blogs about her testing endeavors to clear misconceptions about SQA as a career and testing itself and to give the reader an experience of the frenzy that is Quality Assurance.



Follow Uridah at


Blog: https://qafrenzy.wordpress.com/

Popular Posts

Total Pageviews