Day10: Delete an automated check from your current check and share why you chose the one you deleted


Although the topic is about "Delete one automated check...", when I think about it, I just realise some checks could be deleted. 
In general, I'd delete some low-level risk of failure or fewer impact checks when doing automation tests, such as:
1, In the test of clicking on a button to open a drop-down menu and then choose an option from the menu, I'd delete the check of the drop-down menu.
2, In the test of navigating to some further page, I'd delete the check of the page navigated to if it's normally rarely failed.
3, similar to 2, in the test of acting with some pop-up windows, I'd delete the check that if the pop-up window is displayed. 

The reason why I'd delete them is that they are all low failure risk and impact checks, and even they fail the further test steps will fail, which means the failure can be caught. But if all these kind of checks are done every time, the whole test will consume quite a long time and then will result in a not very efficient testing. So I prefer to delete them.

Day9: Find, use and share your thoughts on an API testing tool


I've used two API testing tools: Postman and SoupUI. I prefer SoupUI between these two.

Although SoupUI Pro is a commercial version, SoupUI itself is an open source and its UI is just simple and user-friendly.

SoupUI is powerful at API testing. I only used it to do functional testing for both rest and soap APIs, but its functionality covers more than that. Its core features include:
  • Web services inspection
  • Web services invoking
  • Web services development
  • Web services simulation and mocking
  • Web services functional, compliance and security testing

As an API testing tool, it's easy to learn and use it and have fun, So I look forward to learning further in it:-)


Day7: How do you choose which tools to use in your testing?


Before answer this question(how, which?), we may ask: why do we need tools in our testing? Once we get the answer to the 'why' question, we might also get answers to the 'how' and 'which'.

 Generally saying, only when the benefits of introducing a tool in testing are more than the risks of it, we'll consider to choose it. So, I think that always understanding the requirements of the project deeply and assessing the Return On Investment based on those requirements thoroughly could be helpful when we try to choose the most suitable tools in our testing. There're also some detailed key points as following we can consider:
  • Support your project environment? for Web, Desktop or MobileApps?
  • Ease of developing and maintaining test scripts? ease of test execution for your test team member?
  • Support to testing approaches which your team are using,e.g BDD, Key-word-driven, Data-driven, etc?
  • Produce test report?
  • Support to the languages your team are using, like Java, C#, etc?
  • Support to multi-browser or multi-OS where your project need to be tested? 
  • Time that your team will spend on being familiar with the tool?
  • Costs of using the tool? 
  • ....
Anyway, using tools for testing will be definitely helpful and useful if your choice is suitable. So, go for it with the right assessment and good luck:-)

Day6: Share what skills a team needs to succeed with automation in testing


I think that as a team if you want a great success with automation in testing, some skills should be essential, like:

1) General testing logical mind.
2) General knowledge about automation testing process and strategies.
3) Being able to build a practical Automation Framework with suitable automation tools.
4) Being able to design reporting facilitated, easy troubleshooting, easily maintainable and up-to-date automation tests.
5) On-time communication between the team.

Day5: Find, use and share your thoughts on a web UI testing tool


The web UI testing tool I've been using currently is Selenium WebDriver.

First of all, Selenium WebDriver is an open source tool. Anybody can download and use it at free cost.

Secondly, it can be used with many popular programming languages to write test scripts(It supports C#, Java, Python, PHP, Ruby, etc.), so it's easy to use. I use it with C# and Java.

Third, it automates web browsers and supports all popular browsers, such as Chrome, FireFox, Safari, etc. , so it's great to use it to do a web UI testing.

Fourth, it supports cross-browser testing.

Fifth, it supports various Operating Environment to implement tests, such as MS Windows, Linux, Macintosh etc.

Sixth, it supports parallel testing.

Seventh, it supports various test framework like NUnit, XUnit, JUnit, TestNG, etc.

Eighth, it has a good community to share knowledge. Testers can easily get answers to their questions about Selenium from online.

Ninth, it can integrate with some build automation tool like Maven.


Day4: What types of testing can automation support you with?


Automation can support many types of testing, generally saying, such as:

1) Unit test. Especially in a DevOps development model using CI/CD, every build would be followed by an automation unit test.

2) Regression testing. When a software or its environment is changed, a regression testing should be implemented to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. Regression testing is competitive, and so could be boring and time and cost consuming. That would be great to automate those regression testing.

3) Sanity/Smoke testing. During these testings normally only a small set of but critical and basic test cases would be executed, and then further complete functional testing could be done based on the results of these testing. It means normally the same test suite will be executed and the result is expected to obtain soon. So automation can make these testing be done effectively and efficiently.

4) Performance testing. It's hard to do manual testing in some performance testing, e.g. a great number of users access an application in a few seconds. In this case, a tester can write automation code to drive a performance testing tool to do this test.

5) API testing. When testers test the public interfaces to some classes, modules or libraries, those we call as API testings. In this area, automation can also support testing.
Subscribe to: Posts (Atom)