GianCodes

Open Weather
Testing Framework

Overview

Test Reports

Openweather

Zebrunner
Test Reports

The framework is seamlessly integrated with Zebrunner to facilitate the generation of comprehensive test reports. This integration allows for the linking of test cases with their corresponding test scripts and the creation of launchers, streamlining the testing process and enhancing reporting capabilities for a more detailed and organized overview of test results.

Integrating Jira into Zebrunner was a simple process, making reporting bug issues directly from the test reports quicker. Tracking bugs was also easier since Zebrunner displays the bug’s status. 

To avoid wasting time, it was crucial to add important details to my bug issues on Jira, such as preconditions, steps to reproduce the issue, screenshots, and videos. I provided the necessary information to reproduce bugs,  making it easier for software engineers. 

After finishing testing, I successfully identified 2 bugs. One bug can be considered as medium or high-priority for its exposure to sensitive data. Feel free to click on the image for more details or the link to the GitHub issue. 

Test Plan

Openweather

Test Plan

A comprehensive test plan has been incorporated into this project, outlining key aspects such as testing scope, strategy, design, tools, risks, and mitigation measures. For a more in-depth understanding, you can explore the detailed test plan by clicking the image or going to the GitHub repository.

 I did not possess an official Functional Requirement Specification (FRS) document, leading me to take the initiative and craft one myself. This document mimics the details about the upcoming feature to be developed.

After creating the test cases, I learned that understanding the specifics of the feature will guide you to create more effective test cases covering crucial areas that might not been obvious.

The objective was to simulate the real-world experience of crafting and adhering to a test plan, mirroring a professional environment. In the test plan, I included details that would be useful during the Software Testing Life Cycle.

A few examples are:

  • Testing Scope: What the testing process will encompass and equally important, what it will not.
  • Tools: Selenium Grid, Docker, and Carina.
  • Testing Strategy: explaining my approach and techniques for testing, mostly test fundamentals like boundary value analysis.

Engineers leverage test plans as an organizational tool that serves to communicate and enhance the testing process. These documents are useful when onboarding new team members, regaining focus when faced with uncertainty, adapting to unforeseen circumstances, and tracking progress within the STLC.

Test Cases

Openweather

Test Cases

When crafting test cases, I applied fundamental testing principles such as Equivalence Class Partitioning to scrutinize the login page. Specifically, I introduced data representing distinct invalid email formats, exemplified by inputs like “myemail@FAKEemil.com.” This approach led to the discovery of a bug within the registration page – an intriguing outcome of employing these testing methodologies.

All my test cases were meticulously developed, adhering to testing strategies and a deep comprehension of project requirements.

The structure of my test cases encompasses the following key components:

  • Test Case ID: A unique identifier for each test case.
  • Test Scenario: Associating the test case with a specific scenario, such as logging in.
  • Automation State: Indicating whether the test case should be automated.
  • Title: A concise explanation of the test case.
  • Pre-conditions: Necessary conditions preceding the test execution.
  • Action: Step-by-step instructions for executing the test case.
  • Test Data: Inclusion of data essential for feature verification.
  • Expected Result: Anticipated outcomes following the execution of each step.
  • Actual Result: Documenting the real-time outcomes observed during test execution.
  • Priority: Organizing test cases based on the impact of potential failures.
  • Result: Clear indication of whether the test case passed or failed.
  • Comments: Additional information or insights relevant to the test case.

After test case development, I imported them into Zebrunner, a testing management system. However, it’s important to note that a careful review of the documentation is recommended for similar actions. Zebrunner, in particular, requires specific CSV file structuring for accurate information parsing. While TestRails offers a more flexible system for importing CSV files, the Carina Framework integration with Zebrunner proved more efficient.

TestRails may excel in CSV file imports, however, Zebrunner is the preferred choice for this project due to its seamless integration with the Carina Framework, simplifying linking and managing test cases.

Web Tesitng

Openweather

Web Testing

Web application testing using Selenium and TestNG. Proficient in creating data-driven test cases with data providers, utilizing soft assertions for comprehensive validation, implementing the Page Object Model (POM) for maintainable test code, and interacting with web elements for functional testing.

Before creating the web tests, I used the Selenium library, implemented the Page Object Model, utilized stable x-paths, and adhered to Java best practices to enhance readability and maintenance. Once I was finished, I tried to determine what test cases were WORTH automating. I took into consideration what features were the most used or important. The most important for this project were the features that impeded a user from login or logout. Therefore, those features required to be tested the most and ensure that they worked after every update. Automating the testing for these features would save time for engineers and improve quality.

Finally, I was able to start creating web tests using TestNG. As depicted in the images to the right, I included annotations on my web tests for descriptions, tags, data providers, and linking test cases. The descriptions provide details about each test and the tags are used for grouping tests to create test suites such as Regression testing. The test cases inside Zebrunner (test management system) have a unique ID which was necessary to link the tests and provide better traceability. Also, you will notice that a few tests have data providers to execute the same test but with different data.

Each test employs either a hard or soft assert to validate various aspects of a page, whether it involves confirming the correct alert message or detecting an incorrect title. I intended to create tests that simulate or follow the same steps that a user would take.

Mobile Testing

MORE DETAILS
COMING SOON!

API Testing

MORE DETAILS
COMING SOON!

Parallel Testing

MORE DETAILS
COMING SOON!

Multi Browser Testing

MORE DETAILS
COMING SOON!

Encryptor

MORE DETAILS
COMING SOON!