OnPath Testing Blog

Talk the talk - QA jargon and the vocabulary of testing

Written by Ritinder Kaur | Nov 29 2017

Newbies hear QA jargon like “smoke testing,” “sanity testing,” “scrum,” and “sprint” in a software quality assurance environment and are left to wonder, what do all these test terms mean? And, what about terms like “white box ” and “black box testing?”

In this article, we will simplify some terms related to software testing - they are easy enough to pick up as you start getting hands-on experience in the field.

And thereby hangs a tale...of epics, and stories

Themes, epics, features, stories and tasks are part of the Agile Methodology of software development, in which solutions are rapidly achieved through the collaboration of independent  teams working in one- to four-week sprints moderated by a scrum master. Breaking down the business requirements in this way ensures that only such information is communicated to the team members which is crucial for them to do their part.

Agile is different from the previous linear methodology in that it proposes testing in phases of short duration, or sprints. The product is kept market-ready and as the sprint goals are achieved, it can be released.

A theme is the description of the business goal; it may be tangible (such as an e-commerce application) or abstract (such as scalability of the application). A theme is further broken down into epics and stories; this helps management perceive the product in terms of sale-ability. Every feature is a group of related stories which provide a certain functionality to the end-user. A story is a piece of functionality that the user would notice - such as a new button on the page, a new field or a new capability in the application. An epic is simply a logical grouping of stories; a story may belong to more than one epic.  Tasks are activities that the team needs to do in order for that story to happen.

Out with the old, in with the new…

Let’s compare the newer and older software development approaches:

  • Agile Methodology is ideal for today’s rapid release needs and time-critical applications. As discussed above, Agile proposes breaking the application functionality into logical granular chunks, which then easily allow for code changes alongside changing client requirements. Also, since the code is tested often and regularly, bugs can be detected earlier and the code modified accordingly, supporting stable releases during the frequent release cycles

When we talk of Agile, we also talk of Scrum and Kanban.

Where Agile is a methodology on paper, so to speak, Scrum is how you implement it in the workplace by structuring the organization. Scrum sprints are iterative and of short duration, mostly from one to four weeks. Since there is constant to and fro communication between the technical team members, both developers and testers, the sprint goals are achieved in a short time and any changes in client or user-end requirements are also factored in.

Kanban is a workflow method that follows the Agile methodology. It is NOT a parallel process to Scrum. In fact, the principle of Kanban can also be applied to a Scrum environment. As and when a team has the capacity, they will pull the next task off the backlog; the underlying concept is that focus should be on the task at hand and that there should be no bottlenecks in the workflow.

  • Waterfall methodology is an older design process in which software development is done sequentially,  through various phases of requirements, design, implementation, verification, deployment and maintenance.

It was a technique attempting to logically discover the size, cost and timeline of the project at the onset. However, being a linear process, it naturally led to (sometimes massive) overruns in time and budget, and with the advent of personal computing and then the Internet, ultimately could not keep up with the client and users' evolving needs.

The QA jargon of testing methods

The following testing methods are used in QA :

  • White box testing is also known as structural testing or clear box testing. It is a method of testing the internal structure of an application, therefore requiring the test engineer to have close knowledge of the code being written. In current practice, white-box testing is most often performed by developers during their development phase as part of their unit testing.
  • Black box testing is a method of testing the functionality of an application without needing to know its internal code. This is essentially treating the application exactly as a user would approach it, through the user interface, thereby requiring the tester to carefully plan and follow every main permutation of action that is possible in the application. Most software testing tools, from test management tools to automation development tools, cater to this type of test approach.

Testing types

The following types of tests are usually conducted:

  • Regression testing an application involves the verification of  existing attributes and functions of an application after changes have been made to them. Besides the standard black box functional testing, this is often the single most time-consuming AND important activity to perform, since it is not uncommon that a piece of functionality previously signed off on becomes buggy after the current development efforts. Regression testing is the prime candidate for test automation development, since these features need to be re-tested again and again, and a robust automation framework can speed the execution and results reporting tremendously.
  • Sanity testing is surface-level testing to verify that the build released by developers is acceptable for further testing. It is also referred to as acceptance testing, smoke testing, or confidence testing.

Testing levels

There are mainly three levels at which testing of an application is done:

  • Unit testing
  • Integration testing
  • System testing

Unit testing is that part of application development when its smallest testable parts, called units, are tested independently of other components such as units and modules. Because the developers are most closely associated with these individual units, they are typically the ones to perform this sort of testing.

A software application under development is often divided into modules and assigned to separate developers or teams; as the modules are developed, they are combined and tested in turn, which is called integration testing.

After all the modules are integrated to form the complete application, the entire application is verified, which is referred to as system testing or end-to-end testing. Both integration and system testing are typically performed by QA, while the developers turn their attention to the next piece of work.

 

Believe me, the vocabulary of testing grows on you! This is only an introduction of many QA and development terms, whereas plenty of additional ones were not discussed...if you felt this article could be improved with additional definitions and discussions, please let us know!

Recently, I was reading about the performance of actors in a local play. For a moment, I thought they were talking about “performance testing”!