QA from Point 0

Lots of startups begin developing their products without the involvement of QA in the process. After a while, the time comes (usually when the product needs to be delivered to the customer) when a QA process becomes necessary. Together with the product and its release notes, the customer often demands documentation of the QA process (ATP, STP, STD).

At that point, the company will hire a QA leader, who may work alone at first but will often eventually expand the QA team. The leader must be capable of managing the QA system and implementing QA methodology in the product’s development process.

I would like to suggest some helpful points for the new QA leader who needs to build a QA process from point 0:

·         Learn the product
Depending on the product’s complexity, take 1-4 weeks to study the product. A QA leader should know the product better than the developers (he/she is often the only one who has all the pieces of the puzzle).
Read the user guide and official release notes.

Enlist the help of key people in the product chain to help you understand the product better (Product Owner, CTO, System Architect, Developers, Integration Engineer, Technical Writer and others).

·         Write a basic sanity scenario
Usually the best way to do this is by using the marketing team’s demo. The demo will provide a quick POC for the use of QA, and will inevitably be the first test you will run anyway.

·         Regression backlog

Produce a backlog from the regression. Find out which modules constitute the core of the product and start with that. Remember, it is better to have one module in the plan than two with no coverage.

·         Don't collect debts
Write tests for all the new features so that you will need to write regressions only for older features; otherwise the regression backlog will get bigger and bigger.

·         Be involved in the design
When you get involved in the design, you can prevent the occurrence of bugs. Then, when you prove your worth in this area, you can start talking about TDD .

·         Automation
Try to automate the basic flows of the product. This will make the sanity and regression processes much faster and easier and will free up time for you to explore and cover the new features.

If most of your product’s logic is on the server side (which is the case for most products), it is much faster and more stable to start automating the server side rather than the UI.
From my personal experience, although everyone agrees automation is necessary, in many companies the developer will try to keep the code to him/herself. Solving this matter, in my opinion, involves teaching development teams to trust and even depend on the QA testing process.

One small tip: If you find yourself in a situation like that, contrary to what I mentioned above, begin the automation from the UI. It can be used as a POC for you and will provide the way forward to the server side automation.

And if you decide to go with UI automation, try to identify objects by their IDs (if possible).

JIRA Tips

Like other software companies, we use an issue tracker. There are lots of trackers out there and our company works with JIRA, one of the most common tools in use today. JIRA is modern and intuitive, and even offers an annual practical joke.

Due to recent requests by people from within and without my company to explain how I use JIRA in the testing environment and for the tracking of version status, I will offer a few tips and links that may help you start using JIRA like I do.

Filters and (JQL)

Filters are the basis for a lot of the analysis work you can do in JIRA. They are saved queries that can be run in basic mode (form based) or advanced mode (JQL).

JIRA has its own query language - JQL, don’t be afraid to use it. Its intuitive nature will be much appreciated, especially if you are familiar with different kinds of queries.

In addition, when you become familiar with the JQL mode, you’ll find it much easier and faster to use than the basic mode.

Options for filters include managing them, sharing them with others, keeping them private, cloning them (which can save lots of time), and more.

Regression

A useful checkbox field can be added to each bug to indicate if it is a regression. The quality policy in my company is not to approve a release if a regression exists and every regression must be corrected immediately.

Dashboards and Gadgets

In JIRA, you can create as many dashboards as you want and configure them to suit your requirements. You can also share your dashboards with others or keep them private.

o  “Recently Created Chart”

In my company, we use this chart together with the filter of all bugs found in the tracked version that have a priority higher than major or are marked with “regression”. I expect that as we move closer to the release date, the amount of active bugs will decrease and the columns will appear in green (meaning the bugs were fixed).

o  Tracking a risk area in your project

You can use the pie graph in JIRA to locate problems in the project. For example, you can create a pie graph with statistical information indicating regression. This will help you discover if your project has a problem with its work processes.

As another example, you can use a statistical graph for different system components to determine where most of the bugs in the system occur and why.

Hierarchical trees

Truth be told, this is one of the most important features that JIRA lacks. However, you can work around this by using epics and user stories. In addition, make sure bugs are linked to epics.

Although this may not provide a perfect solution, it does a good job of covering the issue and helps gather all the bugs in one place.

Another option is to use a Structure plugin.

Hierarchical trees

Truth be told, this is one of the most important features that JIRA lacks. However, you can work around this by using epics and user stories. In addition, make sure bugs are linked to epics.

Although this may not provide a perfect solution, it does a good job of covering the issue and helps gather all the bugs in one place.

Another option is to use a Structure plugin.

Plugins

Here are a few plugins you may want to check out:

o  Agile (older name: Green Hopper) - A superb tool for agile teams.

o  Capture (older name: Bonfire) - Great for exploratory testing and the latest word in software testing. If you use this tool, make sure to read about the special annotation in the notes .

o  Zephyr for JIRA - If you can live without hierarchical trees, you may find this tool useful when it comes to managing your manual tests.