Forem: Moaaz Adel

What Makes a Good QA Engineer Part 2: Effective Communication Skills 🗣️💬

Moaaz Adel — Sat, 28 Sep 2024 21:31:07 +0000

This is the Part 2 of the Series (What Makes a Good QA Engineer)
Here is Part 1: QA-Mindset

In the world of software development, the ability to communicate effectively is just as important as technical skills. A good QA Engineer not only tests software, but also acts as a **bridge **between various teams. Let’s dive into the key aspects of effective communication for QA Engineers.

Key Components of Effective Communication:

Active Listening 👂

Understand requirements and concerns from developers, product managers, and other stakeholders.
Encourage an open dialogue to clarify misunderstandings and gather comprehensive information.

Clear Documentation 📄

Create detailed and comprehensible test plans, cases (When needed), and reports.
Use visual aids (like charts or flow diagrams) to enhance understanding, especially for complex processes.
Personal recommendation: I encourage you to check out MindMaps to visualize your work. Some tools like Xmind, and [MindMeister]. (https://www.mindmeister.com/)(Will have an article on how to use MindMaps as a QA Engineer soon).

Tailoring Communication Style 🎯

Adjust your communication based on your audience (technical vs. non-technical).
Use concise language for busy stakeholders and provide in-depth explanations when necessary.

Providing Constructive Feedback 🛠️

Offer actionable insights rather than just pointing out problems.
Frame feedback positively to foster a collaborative environment.

Facilitating Cross-Functional Collaboration 🤝

Work closely with developers and other team members to ensure alignment on quality objectives.
Promote a culture of quality throughout the development process.

Conflict Resolution ⚖️

Address disagreements diplomatically and find common ground.
Use problem-solving techniques to navigate challenges and keep the team focused on goals.

Remember💡
QA is a CRITICAL part of the development process, We're all developing the Software, but everyone has his own way. (A developer is not a only a Coder). 🤷‍♂️

Conclusion

Effective communication is crucial for a QA Engineer's success. It not only enhances team collaboration but also ensures that quality is prioritized throughout the development lifecycle.

See you in part 3 ;)

Thanks for reading, and happy testing! ❤️❤️😃

🚀 Github Actions: A simple way to trigger workflow from another workflow

Moaaz Adel — Mon, 03 Oct 2022 13:51:21 +0000

GitHub Actions is a neat and tidy way of automating the workflow in your development environment.

Actions let you define and run simple commands in your development environment using a single interface.

You can write your script as a simple bash file, but defining it as a GitHub action will make it even easier to run (and maintain).

In this article, we will learn how to trigger a workflow from another workflow in a simple and easy way.

Prerequisites:

**
To trigger a workflow from another workflow we need the following:

A repository with an action defined inside it (repo_01).
Another repository that needs the action to be triggered (repo_02).
Personal Access Token (PAT) that will be added at "Secrets".
Simple Command to authorize the other workflow's PAT to call the repository's PAT to initiate the workflow, which will call the repo_01's action to execute the command.

Now after we knowing what we need to make it works, let's make it works :D

Generating PAT:

To generate Personal Access Token for a user account we need to navigate to user profile tab > and in dropdown menu select "Settings" option > Personal access tokens.

New choose "Developer settings"

Click on "Generate new token"

Provide a descriptive note (or leave it empty) and select the desired scopes of the PAT:

Note: PAT is secret and should not be shared; this is to prevent unauthorized access to your account and other repos.

We need to add the PAT to the secrets section of the repo_01 repositories permissions.

Navigate to "Settings" tab from the top navigation menu.

From the left navigation panel, click on "Secrets" then choose "Actions"

Now choose "New Repository secret"

Type "ACTIONS_KEY" as the secret name and enter the "PAT" in the "Secret" field.

Creating workflows:

Now we will create the workflow for the two repos.

First navigate to "Actions" of the first repo and click on "New Workflow".

You can choose between "Set up a workflow yourself" or using one of the suggested workflows depending on your need.

Do the same steps at the repo_02 repository to create the second workflow.

Last but not least, we need to configure the two workflows to interact with each other by calling one from the other.

Use the following script at repo_01 (The trigger flow).

Replace userName with the Girhub userName and repoName with the actual Repository name name and the related url to the repository.




name: workflow_01
on:
  workflow_dispatch:
     inputs:
      workflow_02:
        description: 'ًWorkflow 2 which will be triggered'
        required: true
        default: 'workflow_02'

      workflow2_github_account:
        description: 'GitHub Account Owner'
        required: true
        default: ':userName'

      workflow2_repo_github:
        description: 'repo-name'
        required: true
        default: ':repoName' 

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - name: Test
        run: |
          curl -X POST https://api.github.com/repos/:userName/:repoName/dispatches \
          -H 'Accept: application/vnd.github.everest-preview+json' \
          -u ${{ secrets.ACTIONS_KEY }} \
          --data '{"event_type": "Trigger Workflow", "client_payload": { "repository": "'"$GITHUB_REPOSITORY"'" }}'
      - uses: actions/checkout@v3

And at repo_02, add the follwoing code to the actions file:



name: workflow_02
on: [repository_dispatch]
jobs:
  cypress-run:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Triggering Wokflow 2"
      - name: Checkout
        uses: actions/checkout@v2

Finally, let's try it :D

Navigate to repo_01 > Actions > workflow_01 > run workflow

And Tada! we made it

Workflow_02 is now being triggered by workflow_01

workflow_01

Workflow_02

That's all folks! 🎉

To learn more about github triggeres and events:
https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows

References:

GitHub
LetsDevOps

What makes a good QA Engineer Part 1: Tester Mindset

Moaaz Adel — Wed, 20 Apr 2022 19:04:17 +0000

In this series, we will discover in a nutshell and straightforward points what makes a good Quality Assurance Engineer that rocks.

The name of the series is inspired by this song What makes a good man, which I encourage you to listen, it's really a good one. :D

So without long intro, let's go ahead and start with the part 1 and the most important skill (in my opinion), which is The Tester Mindset.

The following 10 skills are what shapes the mindset of a good QA Engineer:

Critical thinking: having an open mindset instead of clinging onto prejudices. Thinks, challenges, explores, investigates and questions rather than just accepts, checks, validates and verifies.
Curious about learning and exploring.
Evaluating the possibility of failures.
Aiming to NOT just find bugs, but prevent them.
Flexible: able to switch between big-picture (which could also be called business-oriented) and detailed analytical mindsets at need.
Making sure the app doesn’t do what it isn’t supposed to do (which is different than making sure it does what it is supposed to do) but in an efficient manner.
Being able to spot patterns and inconsistencies.
The more time testers spend doing manual tasks like documenting test cases, the less time they have to do value-added activities like finding defects
Don’t focus on the overall defect count (Focusing on quantity over quality is a mistake).
Everyone must be focused on creating the best experience possible for the end-user.

Conclusion:
The most important skill that shapes a good QA Engineer is the mindset, that will difference between being an OK QA engineer and good one.

See you in the part 2.
Thanks for reading and happy testing ❤️ ❤️ 😃
Feel free to reach out on Linkedin.

Screan Driven Development (A Mixed Approach Scrum & Lean)

Moaaz Adel — Thu, 13 Jan 2022 12:26:57 +0000

Are you a developer, tester, manager? Whatever your rule is in the company, you absolutely don’t want to fail any sprint for any reason.

If you have been involved in a failed sprint before, then this article is for you, you will see what can make a Sprint fail and how to avoid that in future, and if you have never failed a Sprint, then perfect! I guarantee that you will find it interesting to learn a new methodology to try.

Hidden Wastes!

Let me tell you a story:

Once upon a Sprint in a company that follows a Scrum Approach, the scrum master told the team "the sprint is running out of time and there are still some features that weren't finished yet, and there were also unresolved bugs still opened".

The Development Team was in a hurry to finish the remaining features and solve the bugs, QA members were trying to finish the testing tasks, the time was tight, new bugs were reported, new code merged, fixed bugs reopened, the team tried hard, but sadly,

“The Sprint FAILED!!!”

Scrum master said that on the last day of the sprint after the 2 weeks passed and the team was waiting for the Retrospective meeting to discuss what happened during the sprint.

All team members were mature enough at development, testing, and estimation almost accurate all the time, so what went wrong to fail the sprint?

What Went Wrong?!

Image Credit(shorturl.at/byLPS)
In the Retrospective Meeting:

At the “What went wrong?” question in the Retrospective, those answers came up from the team members:

1- “Some Stories were NOT clear enough and many scenarios were not mentioned, we spent a lot of time waiting for answers”.

2- “There were many Bugs and they needed a lot of time to be resolved and retested” “QA Engineer”

From those points, we can conclude common issues that are related to a broader Concept that is (Waste)!!!

Now after this short story, let’s explain what "Wastes" really meant, what can introduce wastes in the Development process, consequences, and how to avoid them leading to sustainable development.

The Lean Approach

Lean Development is an agile framework based on optimizing development time and resources, eliminating waste, and ultimately delivering only what the product needs.

Waste

image credit (shorturl.at/swAV5)

“Waste” is any action or step in a process that does not add value to the customer.

There are 8 types of wastes identified by the Lean Approach, we will discover them one by one and show when they can occur and how to avoid them:

Overproduction/ Extra features
- Problem: More is produced than is required
- Solution: Only focus on what is needed now, prioritize the backlog, and take ONLY the highest priority features and consider the team's velocity.
Over-processing: adding extra steps with no added value
- Problem. Need Approvals of more people than is necessary
- Solution: Reduce the steps required and remove the unnecessary ones that add no value to the feature and delay delivering it.
Motion
- Problem: Moving tasks more than necessary when doing work. Each time a deliverable is handed off, there is a potential knowledge loss.
- Solution: Having Cross-functional teams with generalizing specialists (T-shaped people), face to face communication, shortening feedback loops, and having a variety of useful documentation types for the feature (API doc, user guides)
Inventory/ Partially done work
- Problem: Developers should not leave incomplete work. A feature is considered partially done if it has not:
  - Documented
  - Deployed
  - Tested
- Solution: Redefinition of Done to include the previous 3 points, apply the Kanban methodology limit Work In Progress (WIP) that any stage (Column/status) can hold for pulling new work only if capacity is available.
Transportation/ Task switching
- Problem: Unnecessary task switching, each time a person working on a task switches between other tasks, there is amount of time being wasted to refocus on the working tasks.
- Solution: Reduce the task switching to the minimum and prioritizing work to be done
Talent Utilization:
- Problem: Lose the Team members creativity due to ineffective allocation of responsibilities and tasks.
- Solution: Always empower team members, encourage them, and pay attention to the allocation of the members.
Defects
1. Problem: Defects are producing additional rework which is considered a Waste.
2. Solution: Try to reduce the number of Bugs produced at each Sprint by applying Bug Prevention approaches, Shift Left for early bugs detection, and applying TDD.
Waiting:
1. Problem: Any process that stops the project activity like inputs, delays in reviews, approvals, and testing.
2. Solution: Reduce the waiting times to the minimum by instant messaging, regular feedback, and applying test automation.

The Combination of Scrum and Lean

The main issue with scrum is that the problems are not properly identified.

After each sprint, during the retrospective meeting, the team states what went wrong without knowing the root cause, so we can face the same issues repeatedly.

The gap filling between both approaches can be achieved by applying a new approach (Screan).

Firstly, as mentioned the importance of waste reduction following the Lean Approach alongside with Scrum, we can achieve that by:

Mapping the Sprint Problems to the related wastes.
After identifying the problems, start working on reducing the waste in your next sprint.
Repeat the process at each Sprint's Retrospective to reach the optimum method that eliminates waste.

Conclusion:

Imagine what we can achieve when reducing the previously mentioned wastes by mixing Lean Development alongside with the Scrum Approach, we will achieve stunning results through Sustainable Delivery of Value to the customers without having obstacles of wastes that impede the continuous delivery.

Give it a try in your next sprints and I’m looking forward to hearing that it helps you.

References:

Your contribution is highly appreciated.
Thanks for reading and happy improvement ❤️ ❤️ 😃
Feel free to reach out on Linkedin