[Day 4/5] APIvsUI Testing - What is your ideal API testing process?
I hope you enjoy the conversations we are having at the API Testing vs UI Testing competition. The UI Team has a bit more points at the moment. However, I’m sure you can easily catch them! Participate in today’s conversations or in the previous ones. Also, remember that you can earn +2 points if you invite your colleague to the conversation or share the event on Twitter. Find more details in the description of bonus tasks below.
>> Track the current score
Day 4 Task:
Describe how an ideal API testing process should look like
Here is what you can cover in your reply:
Describe the process you have at work.
Is there anything you would like to change in your process?
What steps should a successful testing process have?
Do you use any KPIs to measure your testing process? Which ones?
Leave your comments here.
If you’ve just joined the event, feel free to complete the tasks for the previous days.
Accomplish any of the bonus tasks to earn more points:
- +2 points - Invite your colleague to the competition.
Mention a nickname of this person by using @ in the competition’s daily topics. You can invite as many people as you wish. NOTE: A person you invite should be a new Community member registered after the event start.
- +2 points – Make a post on social media about your participation in the competition.
Your post should contain: @SmartBear, the #APIvsUITesting hashtag and the link to your comment in the Community.
- Leave your comments on a conversation of the day. 1 comment = 1 point to the team score.
- The competition will be held on March 25-29.
- Join the competition any day and participate in any daily conversations.
- Feel free to leave comments for any teams.
- Rewards! A team with the biggest score will win. Active participants from each team will be rewarded.
SmartBear Community and Education Manager
In my daily software testing life cycle, I am using below approach before I start testing any AUT:-
- Gathering the requirement to test any modeules.
- Breaking the application under test into smaller modules.
- Writing the testcases.
- Making the testcases available before the developer starts coding.
- Grouping the testcases for regression testing.
- Maximizing the test coverage.
- Conversation with the developers.
- Don't let the developers to test their own code. unless, it is unit testing.
- Use the bug reporting tool sich as Rally, JIRA, HP-ALM
- Write clear, descriptive and unambigous bug report.
Basically, I change the testing process everyday based on the testing requirements.
And when it comes to measurement of testing process. We and the team use SalesForce for this purpose. It allows you to build personal dashboard for a business as a whole or every single employee in your business.
If you want to make sure that every team members stay focussed on the most important business metrics, there is no better solution than salesforce.
@nmrao I mean to say here is, the developers can test their own code using UNIT testing. Whatever they do. After that all the other types of testing should be done by testers only.
And, I have changed the sentence.
And also, Developers normally work with the developer mindset of "how to make this work?". A good tester is thinking about "how to break this?" - a very different mindset. Unit testing and TDD does teach developers to change hats to some extent. Moreover, there can be a possibility of misunderstanding requirements. Therefore final acceptance tests should be conducted by someone as close to the client as possible.