Hello, readers!
I’m a QA specialist in Uptech, a Design & Development company that builds mobile and web apps. It’s essential to have a QA department in a development team, as bugs won’t find themselves, huh? But turns out that simply knowing QA is not enough: establishing QA processes is as important.
In this article, I’ll share our experience on how to create QA processes in a company from scratch.
About QA department in Uptech
A couple of facts about the QA department in Uptech:
- Was created in 2016
- During this time the department grew from 1 to 4people
- Consists of 2 Manual QA specialists and 2 General (Manual + Automation) QA Specialist
- Our specialists have experience of working with 20 projects from various spheres
- Because of the diversity of projects we need to constantly test something new
What problems did we face while creating QA processes?
For the first couple of months after the company was established, there was no QA processes flow. That’s why after we started to implement them, it was something new and unusual for the developers. Here’s the list of the problems we faced:
- Where to store the test documentation?
Since one QA can work on up to 3 projects at a time, the main problem was to store all the test documentation. At first, we’ve been keeping all the documentation on Google drive but as the number of projects and team members grew, it became inconvenient. We decided to transfer all our test cases to all current projects in TestRail.
Why TestRail? We had 2 basic needs: low price and the ability to integrate with Jira. Having looked through plenty of tools we chose TestRail.
- We need a Cookbook!
Later, we realized that the department will grow and new people will come. The most convenient solution was to create a knowledge base in the format of a cookbook. It contains the information about how we work in a QA department, what tools we use, what problems we faced, our best practices, the description of a QA flow on projects. When a new person joins our team he/she will be able to find the necessary information in one place. Now we are constantly adding new chapters to the cookbook.
- We do not need QA Checklists
After one year of work, we decided to use test cases instead of QA checklists. Why? Of course, because of bad experience: we had QA checklists on one project which was small. After we transferred this project to a new QA specialist, he didn’t know the steps on how to test the functionality of the app. With test cases, this problem won’t appear anymore.
- Understanding the product or a specific functional
After the case with checklists, we realized that if someone tests a big project and goes on vacation or leaves the team, this project will be transferred to another person who will have no idea about what’s going on with the app testing.
To eliminate this trouble, we decided to create a Mindmap for each project using Xmind tool. After that, we began to create the structures of projects. Why? It helps to learn the product better, and anyone will be able to understand the essence of the project.
An example of Mindmap for Signup functionality:
What tools are we using in our daily work?
The tools we use on each project:
- Xmind — We use Xmind to create a mindmap for a project, or for a big functionality. Creating such documentation lets us better understand how the application should work and how to test it.
- Google docs — For now we store almost all project documentation (except test cases) here: test plans, checklists, test data, etc.
- Jira — It’s our main bug tracking tool. We can see kanban boards, tickets and other necessary stuff for the project.
- TestRail — We store test cases here because the tool is simple and easy to use.
- Zeplin — We receive design docs from our designers mostly in Zeplin.
- Draw.io — If we need to create some cool diagrams for our documentation or reports, we use this tool.
- Insomnia/Postman — We use these tools to test API’s.
- Jmeter (Optional) — We use Jmeter to do Load Testing, for example. Also, this tool can be used for various testing strategies but for now we use Jmeter only for Load testing. It’s cool that in the future we can use Jmeter for API testing and Functional testing with different scenarios.
- QA Automation (Optional) — If we have a request on Automation tester, we are using Java/Selenium/Appium/Cucumber tools.
- Trello (Optional) — Sometimes we use Trello as a bug tracking tool with different tickets for the project but it’s optional and depends on Client needs.
Some of them are optional as we adjust to specific customers’ requests. For example, we don’t need API testing or Load testing. Also, not all customers need Automation.
About QA cookbook and Best Practises
For now, we already have sections about:
- Web, Mobile automation
- Git flow for QA
- Xmind tool overview
- Types of testing
- Test Artifacts for software testing
- Test Summary report
- Testing process
- Time estimation
- To be continued…
Also, we plan to transfer all documentation to Confluence which we think is the most optimal solution.
QA flow on the project
On many projects, we have the same workflow. Here’s the scheme:
On most of the projects, we work with 2-week sprints. There are no problems in communication with the team, as there are constant rallies and work planning.
How QA’s and Devs work together in our company?
In most big development companies, developers and QA are separated into different departments. Communication between departments goes only via Jira or other bug tracking tools. UPTech is a small team of 40 people and we work in an open space, which lets our developers and QA communicate more in person. Sometimes it’s super useful. For example:
- You can always come to the developer and say: “Hey, this build crashes on boot, I cannot do anything.” You can receive a new build in 30 sec. on your phone.
- Developers can better explain technical moments and functionalities.
- Developers can come to a QA department if they don’t understand the issue or how to reproduce it.
- The work goes faster because you can communicate with the people directly and the question can be resolved very fast.
- QA specialist always attends meetings together with developers. It helps to better understand an application and what a client wants to get. QA specialist can ask developers about some predicted testing scenarios and add suggestions for the product from the UI/UX side.
In fact, we still have a lot to do to develop the QA department in Uptech and establish the process of testing the product. Thank you for your attention, 👏 if you have learned something new and subscribe not to miss the updates!