How To Speak So That People Want To Listen - TED Talk by Julian Treasure

Or why how we speak is as important as what we speak.

 

How to build a test automation framework from scratch

This tutorial will cover the steps for building a fully functional and complete Java test automation framework with Serenity, Cucumber and Selenium WebDriver for Front-end testing capabilities and with JUnit and RestAssured for Back-end testing capabilities.

As prerequisites, you need IntelliJ IDEA and Java Development Kit 8 or higher installed.
As learning examples we will be testing https://pokeapi.co/, a RESTful API that returns Pokémon data and https://en.wiktionary.org/wiki/, the online dictionary built by the Wikimedia Foundation.

1.  Create the Maven project using the Serenity Cucumber Archetype.

As seen, it comes with the predefined structure and a test example.

2. Add the WebDriver.

The WebDriver controls the browser that will be used during testing. In this example, the geckodriver was added, this is used for the Firefox browser. You first need to make sure that the version of the WebDriver is compatible with the version of your browser, e.g. compatibility for chromedriver.

3. Update the Serenity and Cucumber dependencies.

Keeping the Maven dependencies up to date is important so that you benefit from all new features and stability improvements.

4. Setup the Cucumber reporting.

The resulting class will be:

@RunWith(CucumberWithSerenity.class)
@CucumberOptions(
features = "src/test/resources/features/consult_dictionary/",
plugin = {"html:target/cucumber-html-report", "json:target/cucumber-json-report.json"})
public class DictionaryTestSuite {}

5. Run the Front-end test suite.

As seen, you can check the test results either using the Cucumber reporting feature for a brief summary or the more detailed and screenshot abundant Serenity reporting feature.

 6. Refactor the test scenarios and make them easily extendable over time.

Using Scenario Outlines makes it easy to maintain the tests and to add or change the test data over time.

7.  Extend testing on multiple scenarios.

At this point, the framework is up and running with Front-end testing capabilities. In the next 4 steps we will add the Back-end testing capabilities.

 8. Add the JUnit and RestAssured dependencies.

9. Implement a basic GET request.

The resulting class will be:

class RestClientTest {

@Test

void testPokemonJson() {

RestAssured.baseURI = "https://pokeapi.co";

given().log().uri().when().get("/api/v2/pokemon/2").then().statusCode(200);

}

}

10. Add tests for the returned payload.

As seen, each value from the returned JSON can be straightforwardly tested.

11. Extend testing on multiple cases.

As shown, JUnit 5 offers the possibility to easily load test data as a .csv file.

And there you have it, the test automation framework is fully functional.
You can also use the Jenkins Serenity plugin to execute such test suites remotely and periodically.

Mirror Neurons - TED-Ed Talk by VS Ramachandran

Or how a small group of neurons shaped human culture and civilization as we know them.

How to setup a performance test suite with Apache JMeter

The Apache JMeter™ application is open source software, a 100% pure Java application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions

To run JMeter you need Java Development Kit 8 or higher installed.
In this tutorial we will be testing https://pokeapi.co/, a RESTful API that returns Pokémon data.

1. Start by adding a Thread Group, through this component you will be able to control the number of threads, how they start and other aspects.

2. Implement a basic GET request for returning data about a certain Pokémon and add a Listener component to visualize the results.

3. Add Assertions on the response. 

As shown in the video, you can check the basic elements like response code and message or go in-depth and extract other values from the payload with regular expressions (useful tool for working with regex here).

At this point the test is strongly hardcoded and hard to maintain over time. For example, if there were 100 tests in this suite and the server or the endpoint would change, you would have to manually update each one. So in the next step let's parametrize the test and keep the variables in a central component.

4. Centralize the variables in Config elements.

5.  Extend the testing for multiple Pokémons.

6. Add a Summary Report and start testing on multiple threads.

A number of threads of 100 with a ramp-up period of 10 seconds means that each 100 milliseconds a new thread will be opened.

You can use the Jenkins Performance plugin to execute such test suites remotely and periodically.

The Testing Pyramid

Ever worked in a company where developers wouldn't write unit tests for the code they implemented, where there was little to no automated tests for the back-end part of the application, where the majority of automated tests were focused on the front-end part and there was a huge volume of manual repetitive testing?
If your answer is yes, then you worked with an ice-cream cone testing anti-pattern:

This is very inefficient (d'oh!?😃) and unusable in the CI/CD world of today.
What can be done? Keep the order and change the proportions, shape it into a pyramid:

This pyramid testing model is most efficient because it saves time and money, the more you go to the top of the pyramid - the more time consuming and expensive it is to perform and maintain the tests, while the more you go to the bottom of the pyramid - the more faster to execute the tests and the cheaper to maintain them it is.

Basically, the test categories in the pyramid can be grouped into two major sections - Business Facing Tests and Technology Facing Tests:

Why is it important to have all types of testing?

• Automated Unit Tests → these should be implemented by developers and can discover problems very fast and early in the development process. This interesting article from Martin Fowler's website about Apple's famous "goto fail" bug and OpenSSL’s “Heartbleed” bug makes more than a compelling case about their importance.

"Hand washing alone does not a doctor make, nor a patient save, but we would not trust a doctor who didn’t wash his or her hands. As software developers, we should assume a similar duty of care on behalf of our users. No one should trust software developed without unit tests."

• Automated Back-end Tests → if the application's API is sufficiently documented, QA engineers can completely handle this point. From my experience, SwaggerUI is the bee's knees and makes an exceptional job in exposing and documenting APIs. Two reliable and efficient solutions can be used for Back-end test automation: Java with the RestAssured library or Apache JMeter, with the second solution bringing the advantages of having an easily understandable user interface and the ability to switch from functional to performance testing on hundreds of threads simultaneously with the flick of a button.

• Automated Front-end/End-to-end Tests → these should cover the main use cases of the application with the smaller edge cases already being covered by the two above points. The standard and widely accepted solution to use here is Selenium WebDriver with Java and Serenity BDD for easily understandable test definition and reporting (Gherkin's Given-When-Then).

• Manual Exploratory Testing → because Quality Assurance is much more than just test automation, it also involves critical thinking, observation and experimentation - human skills that technology cannot yet bring to the table (AI is a hot topic also in this field so in the upcoming decade things might change). I recommend this article from Bas Dijkstra which in my opinion debunks the "silver bullet" myth of test automation.

"If you're a tester and all you do is execute and check off scenarios that were defined by someone else and yell 'pass' or 'fail' at the end of each scenario, then you might indeed be in trouble. But as we all know, that's not what proper testing looks like. Testing encompasses many other activities, and most of them cannot be automated. Risk analysis, communication and mitigation. Determining whether the product provides value to people who matter (the definition of 'quality' as it is given by James Bach and Michael Bolton, based on an earlier definition by Jerry Weinberg). Critical thinking. And the list goes on. All part of testing, all inautomatable."