Archive

Archive for August, 2016

Config Cucumber and Selenium with Maven on Eclipse

Hello guys,

Today I will post the link for a project on github that contains a basic setup to run your automation on Selenium and Cucumber with Maven on Eclipse.

https://github.com/rafaelaazevedo/cucumber-maven-selenium

Don’t forget to change the path of the chrome driver, features folder and glue package.

The project is on github, so feel free to clone and use as you want. We usually forget about how to do this first configuration as we just need to do in the beginning of the project. Hope this makes you save some time xD

Risk Analysis when descoping scenarios

Hey hey hey guys, today I will post about how to manage a risk analysis and what type of questions you should ask when descoping scenarios from your regression pack.

Regression testing must cover certain conditions in order to be effective.

Regression coverage isn’t a question of the number of cases as much as covering the conditions that

  1. Ensure functionality works
  2. Bugs found have been resolved
  3. A functional area can handle some amount of negative or destructive behaviour

Regression testing that addresses all three aspects should guide your testing efforts more than focusing on the number of cases.

Assessing coverage by the number of test cases is difficult — one case can cover many conditions or one case could provide coverage of only a single condition. If I provided a response by a metric of one case will cover what is needed, you might be underestimating regression testing that such a response would be potentially dangerous or misleading. So addressing the question how I would plan regression testing might be more practical. The questions you should keep in mind are:

  • Is this feature stable ?
  • Is this feature dependent on other less-stable features ?
  • What will happen if this feature fails in a subtle/medium/catastrophic manner ?

 

You can find some techniques to develop a risk analysis:

  • A close reading of the requirements specification, design specifications, user documentation and other items.
  • Pair-wise, you can use a tool to mix the scenarios with different combinations and reduce the scope of your regression pack.
  • A sequence of one-on-one or small-group sessions with the business and technology experts in the company.
  • A tool built from Six Sigma DMAIC model. You can simply write down each function and it’s permutations in any manner that works for your business. The whole development team provides input, while the QA professional manages the document and detail of the information and input gathered.

If you are in a small company, like a startup, my opinion is: You can write the scenarios for you regression pack and ask for some developer to review it. So, you will have a regression pack built with their product code knowledge and you with your global view. QA ends up with factual data on what areas and functions of the application are most critical.

Finally, you put together a regression pack that focuses the higher priority functions while exercising the lesser functions less in depth. The key is to test the higher risk areas first and frequently, while still testing the lesser risk functions more superficially or via rotating test suites based on priority or risk.

It seems too simple, but it works to improve communication between team members while also documenting application functionality.

Stay updated with the last features, your regression pack needs to be fresh with the scenarios. Each new version will contain some new feature as it also can remove an old one. It’s important to try to execute that final test cycle with the freshest view you can.

 

Resources:

http://istqbexamcertification.com/what-is-risk-analysis/

http://www.growingagile.co.za/2012/12/breaking-down-user-stories/

http://searchsoftwarequality.techtarget.com/answer/Regression-testing-How-to-select-test-cases

http://searchsoftwarequality.techtarget.com/answer/Using-risk-analysis-for-regressive-testing-planning

Web automation strategy

Hey guys, today I will post about one of the approaches for web automation. This is a general strategy, which I always try to follow, but depending of the situation you need to adjust and change some priorities.

 

What should come first ?

 

  1. Critical scenarios

    Critical or basic scenarios should come first, so before you even start to think about if the validation message when you type negative time is working as expected, you should check, for instance, if the login is working properly.

    So, choose the basic/critical scenario which is the MVP first and implement it. After all the basic scenarios are implemented you can start to think about the others.Doing this, it will save time when doing the regression tests. Separate your automation in phases like, first phase, basic scenarios, second phase, second priority scenarios and so on. So, you don’t get annoyed by taking so much time trying to implement one complete feature. You do the basic things, let the automation working and move to the second phase.

  2. Maintainability

    How much effort does it take to adjust test scripts to the changed requirements, interfaces, data structure, accounts, platforms etc ? You should worry about this since the start, but we know that not everybody thinks the same and even that you have aligned this in the beginning it is common that people forget.

    So, this is the time that you can go back and change/add little things to improve your automation. For example, if your scenarios are not independent, you can implement some checks and make them run by themselves. This will save time when you run a single scenario.

  3. Browsers compatibility

    This depends of what is the most used browser by your clients. You can start implement your automation for all browsers or you can focus on the most used browser and then you adjust the automation to run on all the other browsers. If you choose to run the automation on all browsers since the beginning you need to be aware of you will spend more time implementing the same scenario. Your automation will be done for all browsers, but all other scenarios will be behind schedule since you need to spend more time on one scenario.

    So, you need to be aware of what is more important, choose the most used and delivery the automation in a short time or take more time to delivery the automation and it will be ready for all browsers already.In my opinion, I prefer to focus on the most used browsers and then implement other browsers in the next phase. When you are implementing one scenario for all browsers, it could be hard to focus and find the issue, since every time you run, it will be running on different browser instances. Same for mobile browsers, this should be done in another step. But again, this depends of the priorities of your project.

  4. Portability

    Is it easy to test your automation on another environment ? This is one of the things you need to be aware of. It could be an improvement task, since you will already have the automation and this can be implemented in the next phase of your automation.

 

Thank you guys ! See you next week !

Resources:

https://www.atlantbh.com/five-important-aspects-of-successful-test-automation-approach-in-agile/

%d bloggers like this: