Testing Open Source for Testers: An All-Rounded Guide

Open Source For Everyone

Common Myth: Open Source is only for developers

Reality: Open Source is for everyone: Developers, non-developers including Testers, UI/UX designers, writers, working professionals, students & even anyone who has a desire to collaborate with communities.

Prerequisites to contribute to Open source projects

• Desire to learn: Anyone who has the desire to learn new technologies or anyone who wants to interact with others in the community including even school/college students or also those who have taken a break in their career. Open source is for people of all ages from all backgrounds be it technical or not. Even a 12-year-old child who has the zeal to learn from the community can contribute to open source.
• Share your knowledge with others: Anyone who wants to share their knowledge/learning with others in the community can contribute to open source.
  Myth: You need to be an expert in your domain; otherwise you cannot contribute anything to the community.
  Reality: It is the urge to learn & give back to the community that only matters.
• Collaboration: If you are interested in collaborating/interacting with people across the world, open source is for you. Github (open source) can be used as a social media platform (for sharing & learning).
• Coding/programming experience NOT required:
  Myth: Those who are not good at coding or non-developers think open source is not for them.
  Reality: No coding experience is required to contribute to open source. You can even share your notes or cheat-sheets to open source communities that you make as a student or even test a project to find out if there are any bugs in it. To read more on why you should contribute to open source projects,
  check the blog here.

Open Source for Testers

• Why Should a Tester Contribute To Open Source?

  • You get confident about your testing skills if you contribute to any project.
  • You tend to improve the open source projects by reporting bugs in them through which you will add value to the community.
  • If you know how to fix a bug or implement a new feature, you can contribute by suggesting the solution. You can even create a tutorial or documentation for a project which in turn will help the community & you will also get a chance to learn something new.
  • You can also help people by just reviewing their contributions which in turn enhances your own knowledge.
  • If you contribute to an open source project, the maintainers/owners of that project will start recognizing you as well as your work, which in turn enhances your network with like-minded people.
  • There are chances that you get employed by the owners of the project to which you contributed. So, open source is good for you from career point of view also.
  • You can showcase your contributions on your resume in the form of a GitHub URL which shows companies that you are capable of collaborating & providing value to the community that makes your resume outstanding.
  • GitHub rewards contributors in the form of achievement badges.
  • You can also win prizes & swags for your contributions.
  • Your soft skills enhance as you interact with people.
  • In short, open source is beneficial for both you (as a tester) & the project/community. You learn & also give back to the community.

• How can testers find good projects to contribute?

  • Pick testing projects

    • Go to Explore tab on GitHub & search for keywords related to testing/test. You will find many projects on testing, out of which select a project by analyzing its activity to check whether their members actively help its contributors. If the project’s community doesn’t help its contributors or is not active on GitHub, then there is no point in contributing to it.
    • Follow the below steps to check if a project is good to contribute: For Eg: I selected facebook/jest & wanted to check if it’s worth contributing to this project or not. To check this, go to its closed Pull Requests section & analyze how often the project maintainers interact with their contributors because if you don’t get help from them, you will not be able to contribute as a beginner.Now, open any one of the closed Pull Requests.Here, you can notice a Pull Request is merged 10 hours ago (as highlighted in the screenshot) & the reviewer has also helped the contributor, so that means this project is active & is worth contributing to.
    • You can also select a project that has a good number of Open issues. For that, just go to Issues & select an issue on which you can work.
    • As a beginner, you can’t just jump on any issue. Just select those issues which have “good-first-issue” or “documentation” labels (Refer the below screenshot).Go to Labels then search for your required labels. “good-first-issue” is the label for those issues that are specifically for beginners. “documentation” label is for issues that require changes in the documentation. As a tester/non-developer, you can mainly go for “documentation” issues.

  • Pick up a good project of any domain & test it

    • You can similarly search a project of any domain from Explore tab as discussed in 2.1.
    • You can also check which Open source projects are trending nowadays by clicking onTrendingtab.Begin your open source contribution journey with Testsigma

• How To Get Started With Testsigma & Make Your First Contribution as a Tester?

  What is Testsigma ?

  It is a powerful open source test automation platform for Web Apps, Mobile Apps, and APIs.

  To know more about Testsigma: https://github.com/testsigmahq/testsigma

  Note: Please go through the README.md,CODE_OF_CONDUCT.md & CONTRIBUTING.md files before contributing to Testsigma.

  Testsigma open source for Testers: How to contribute?

  • 3.1. Write/Update documentation & report mistakes in documentation
  • 3.2. Manually test/review a Pull request
  • 3.3. Test a deployed version of the app and report bugs
  • 3.4. Try to reproduce already reported bugs & add more information
  • 3.5. Write tests to improve test coverage

  • Write/Update Documentation & Report Mistakes In Documentation ?

    • If you find any mistakes (even spelling/grammatical mistakes also) or want to change (improve) Testsigma’s documentation but you are not sure how to implement the change, you can create an issue.
      Note: Before creating a new issue, first search if a similar issue already exists. If a similar issue already exists, don’t create a new one. You can create an issue related to Documentation here. When you click this, you get a page similar to the below screenshot.

      Fill in the Title & describe your issue in the ‘Write’ section. Click on ‘Submit new issue’.

    • If you know how to implement changes (updates) in the documentation, create a Pull Request.
    • If you make any changes to an open source project, you have to request the maintainers of that project to approve your changes, this is called Pull Request.

    Steps to create a Pull Request

    Step-1: Fork Testsigma’s repository:
    • Forking means creating a copy of Testsigma’s code/repository into your own GitHub account, which means when you click on ‘Fork’(as highlighted in the screenshot), it will copy the Testsigma’s code into your GitHub account.

      Fork testsigma repository

    • It now shows a page similar to the one shown in the below screenshot. Click on ‘Create Fork’.

      Create Fork

    • After you click on ‘Create fork’, you can notice a repository named ‘testsigma’ is created on your GitHub account.

      Testsigma repository created

    Step-2: Clone the project
    • Cloning means the whole code of ‘testsigma’ will be copied to your local machine (laptop or PC).
    • Click on ‘Code’ HTTPS copy the URL.

      Cloning

    • Create a new folder on your local machine (laptop or PC) where you want testsigma’s code to be saved. Then open Git Bash/ Command Prompt & run the below command to clone the project: git clone
      git clone https:

      Run command to clone the project

    • After cloning is complete, you should find a folder called ‘testsigma’ inside your newly created folder. The folder ‘testsigma’ contains the code of testsigma’s repository, which means now you have testsigma’s code on your local machine.

      Testsigma’s code in your local machine

    • Now that you have the code on your local machine, it’s time to make changes to the code in order to resolve your chosen issue.
    Step-3: Prepare the development environment
    • Thoroughly read the README.md file to check whether anything needs to be installed on your system so as to run testsigma’s code.
    Step-4: Create a new branch
    • Go to the folder where testsigma’s code is cloned on your system using the following command:
      cd testsigma
    • Now create a new branch before making any changes to testsigma’s code. It is always advisable to create a new branch because if we directly make changes to the main/master branch (default branch), it can even destroy the existing code. Create a new branch using the below command:
      git checkout -b branchname

      create a new branch

    Step-5: Make changes
    • Open the folder that contains the cloned code in VS Code or any other editor & make changes, so as to resolve your selected issue.
    Step-6: Take the changes to the staging area
    • Staging means adding the changes that are ready to be committed(saved).
    • Staging is done before committing.
    • Use the following command to stage the made changes:
      git add

      OR

      git add changed_filename
    • Suppose I made a change in README file & replaced ‘Eliminate’ on line 30 to ‘Eliminates’ & saved my file, then I will run the below command to stage my changes:

      Command to stage the changes

    • You can check the status using :
      git status
      This command will tell you the status of git, such as on which branch are you currently on or what changes you have done so far, are these changes committed or not yet etc.

      Status command

    Step-7: Commit changes
    • Commit the changes using the below command:
      git commit -m“some message here”
      Replace “some message here” with a suitable message clearly stating what changes have you made.

      Commit command

    Step-8: Push the changes from your local machine to your GitHub repository
    • Use this command:
      git push origin branchname
      This branch name is the same as the new branch that you created in Step 4.

      Push the changes from local machine to your Github repository

    Step-9: Go to the testsigma’s repository on your GitHub account & Create a Pull Request
    • Here you can notice that you are getting something similar to this screenshot:

      Compare and pull request

    • This shows ‘aparna2071 had recent pushes 2 minutes ago’ which means the changes that you did on testsigma’s code on your local machine have been pushed onto your GitHub repository.
    • Click on ‘Compare & pull request’, which will then direct you to ‘Open a pull request’.

      Open and create a pull request

    • Mention some details about the changes you are requesting in this Pull Request. Eg: “I replaced the ‘Eliminate’ in line no. 30 with ‘Eliminates’ in README.md file”. Then click on ‘Create pull request’.
    • After you click on ‘Create pull request’, it will ask you to sign a Contributor License Agreement(CLA). This step is not mandatory for all Open source projects, but in the case of testsigma, you first need to sign CLA, then only your PR will be accepted.
    • After that, the Pull Request(PR) is reviewed by the maintainers/owners of the project (testsigma in this case). If the changes(PR) are good enough (resolves the selected issue, is well structured & as per the norms of the project), then they are approved by the maintainers, otherwise, you need to make some changes to your PR.

    Difference between Issue & Pull Request

    • When you report bugs or suggest a new feature without knowing how to debug that error or how to implement the new feature, you should create an issue.
    • If you know how to remove bugs/resolve issues/ implement a new feature, you should create a Pull Request.

  • Manually test/review a Pull request

    Myth: Only the maintainers of the open source project can review the Pull Requests (PR) of others.

    Reality: Anyone can access & check the Pull requests of anyone in the world & can also help them improve their PR. But the changes will be merged into the main repository only by the maintainers (those who have the write-access).

    How to Review Pull requests:

    • Step-1: Go to Pull requests that are Open (refer screenshot).
    • Step-2: Pick a Pull request to review.
    • Step-3: To review, go to ‘Files changed’.Check the code/documentation that has been changed. Verify whether the changes follow the guidelines mentioned in the CONTRIBUTING.md & CODE_OF_CONDUCT files.
    • Step-4: If everything is fine, you can approve the PR, otherwise if anything needs to be changed, you can request changes. This can be done by clicking on ‘Review changes’ button. When ‘Review changes’ button is clicked, it shows three options: ‘Comment’, ‘Approve’ & ‘Request changes’.You can also submit a review for a particular line number in the file by clicking on ‘+’ (refer to the screenshot below).For eg.: If you want to suggest any changes for line 2, you can do so by clicking on ‘+’ & then Start a review.Start reviewing the pull requests for Testsigma Project.

  • Test a deployed version of the app and report bugs

    How to deploy Testsigma:

    • Navigatehere& follow one of the methods of setting up Testsigma
    • After you set-up and signup, you get something similar to the below screenshot.
    • To create a new project, go to ‘Create New’ Project. Then add the name & description of your project.
    • You can also create a new test case.
    • You can also record your test cases.
    • For more details on using Testsigma:https://testsigma.com/tutorials/getting-started/automate-web-applications/
    • Now, you can check the deployed app for bugs.
    • If you find any bugs or want to suggest a new feature, you can create an issuehere.
    • You get something similar to the below screenshot.
    • If you found a bug, go to Get started in ‘Bug report’, similarly, if you want to suggest a new feature, go to Get started in ‘Feature request’.
    • Fill in the necessary details & Submit a new issue.
    • If you know how to debug or want to implement a new feature, you can create a PR (Pull Request) as discussed in 3.1.

  • Try to reproduce already reported bugs & add more information

    • If you find an already reported bug (in Open issues), you can replicate that on your system & add some more information to the already created issue by commenting on it & attaching some screenshots to explain the issue better.
    • E.g.: The below screenshot shows an already existing issue with the label as a bug.
    • You can add some more information to it in the comments section at the bottom.
    Checkout the bugs already reported in the Testsigma Open Source Project.

  • Write tests to improve test coverage

    • A tester can also write test cases to improve test coverage for an open source software & can also create documentation of the test cases which can help new contributors learn how to use the project, and what are some use cases for it. You can create documentation of the test cases by creating a Pull request as discussed in 3.1.

To know more on how to contribute to Testsigma,
check the blog here: https://testsigma.com/blog/how-to-contribute-to-testsigma-open-source/
Checkout the blog that covers the What, Where, Who, Why, When And How Of Open Source For Testers