How to test small projects efficiently

There is no time for proper testing in small projects

When consulting our customers, I repeat the mantra “Everybody is responsible for quality”. With that I mean that quality is not created only by the testing team: with testing, in fact, one can basically judge the quality level of the product, detect what the problems are and suggest improvements. That said, Testing has clearly paramount importance in guaranteeing that a project reaches its quality level objective. The problem with every project is that budget and time constraints do not typically allow for enough testing resources. In small projects, it then exists the risk that testing is reduced to a mere check of the happy-path, i.e. the condition which should not generate any error nor exceptions. But is there a way to avoid this situation, is there a way to ensure small projects get properly tested?

Steps allowing efficient testing of small projects

My answer is: yes, there is, but it’s not easy. There are several aspects, which need to be taken into consideration and examining all of them would be too long for this post. I am therefore going to identify the three steps (plus one ingredient), which, according to me, are fundamental in the “recipe” for efficiently testing small projects:

• Keep the testing team as small as possible.
• Involve testers as of the project’s start.
• Test exploratively.
• Tester’s attitude (ingredient).

Keep the testing team as small as possible

The first step is obvious: to increase efficiency, use the minimum number of resources. Small projects can most likely be tested by a single person. The linked risk is that, if this person falls sick or is unavailable, activities get badly affected. The mitigation measure I suggest is that the tester has continuous and strong interaction with the rest of the project team, involving developers and the customer in testing activities. This way, sudden unavailability is compensated by widespread knowledge in the team, which, in the worst case, facilitates the onboarding of a new tester.

Consider testing activities as of the project’s start

The second step looks like the opposite of efficiency: involving the tester(s) since the very start of the project sounds like wasting time (and money). Actually, the very opposite is true: by involving the testers since the very beginning, precious time is saved, problems can be addressed when it is much cheaper to solve them and team spirit increases. It is at the project start that the tester can importantly contribute to the project’s success by addressing, among others, the following topics:

• Availability of test environments
• Devices, Browsers, Operating Systems on which tests need to be performed
• What needs to be tested, when and how
• Involvement of customers / users in testing activities
• Tools to be used for reporting issues and test results

Moreover, when the tester is involved since the project’s start, she / he will get involved also in writing down the user stories / requirements, thus importantly contributing to the following aspects:

• Keep the documentation to the minimum needed
• Ensure user stories / requirements are written using the user’s point of view
• Involve the customer in defining the requirements, thus ensuring that the customer’s needs and wishes are properly addressed
• Ensure testability of the user stories / requirements
• Ensure also non-functional requirements are addressed.

As a side effect, the tester gets deeply involved in the project, knowing all its aspects, which leads to increased efficiency when testing it.

Test exploratively

The early involvement in the project and the continuous interaction with the project team (especially designers, developers and customer) provide the tester with on one side an in-depth knowledge of the project and its goals and on the other side a profound understanding of the customer’s and user’s needs. That is a very good precondition for conducting exploratory testing, which, according to me, is the most efficient way of testing small projects. 

In the words of Cem Kaner, who coined the term, exploratory testing is "a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project" [1]. In a nutshell, when testing exploratively, the tester does not use a predefined set of tests, broken down into steps and expected results, but rather decides to follow a charter, “visiting” a functionality or area of the test object, “exploring” it and searching for “interesting places” (i.e. special situations, issues, exceptions). 

This way of testing also has important positive side effects: it fosters communication inside the team and encourages continuous learning. By finding situations that are special and whose results aren’t clear, the tester will need to interact with designers, developers and the customer to understand if what she / he found is a defect or not and, at the same time, will learn more about the product, the way it works and the possibility for its improvement.

By testing exploratively, the tester has moreover the chance to easily involve the customer in the testing activities. My personal experience with that involvement is that I have always received great insights and achieved good results, getting valuable feedback and improvement ideas.

The fundamental ingredient: tester’s attitude

The fundamental ingredient for efficient testing of small projects is the human factor: the tester’s attitude. From the previously mentioned steps, it results clear that testing a small project is not a structured nor a predefined process (if we want to keep that testing efficient). Hence the tester will need to have an insatiable hunger for learning, uncommon flexibility to cover different roles, to perform tests “on the fly” and to adapt to circumstances. Moreover, that person shall not be afraid of committing mistakes and be courageous enough to admit them and learn from them (sometimes mistakes are the fastest and best way to learn something). Curiosity, empathy and the capability to stay concentrated even when rapidly switching context are also paramount.

As said before, there are many other aspects, which contribute to efficient testing of small projects (for instance correctly setting up processes, so that they exist but are not invasive; reporting defects in the most efficient way and so on), but I believe that the four mentioned above offer a sound base to also achieve the other ones.

Please get in touch with me, should you need any advice about how to improve your testing activities: gpani@greenliff.com.

--------------------------------------

[1] Cem Kaner, A Tutorial in Exploratory Testing, p. 36.