So, up until now, we've seen how important testing is in current development practices and we've seen all kind of aspects that revolve around development itself from a project managing point of view, but still we don't know what's needed to become a good tester.
Finding developers knowledgeable about testing is particularly difficult, and there are a lot of talks online that address this problem: if that's so difficult, can't we do better? How do we get developers to become testers in the first place, especially when what you really want is to make developers responsible for the quality of the code they ship since the very beginning?
I tend to agree with the general idea that a tester, or a developer knowledgeable in testing, requires three basic things: mindset, skillsets, and knowledge.
So how do you get into acquiring or improving these three basic aspects?
Even if you can read all the books and listen to all the podcasts on testing, although these will give you a good amount of skillsets on how to test things and how the various testing suites and frameworks work, you won't be able to become a tester simply with that.
Of course, practice can help you a lot, but, all in all, the quality mindset and the knowledge of what to test are probably the hardest to acquire.
The knowledge part comes from a higher view of the product, both from the technical side and the business end. Introducing project breakdowns and pitches for the features that are going to be introduced in our software can be a starting point in this process.
The quality mindset can be the trickiest of them all, as it ends up being baked into all sort of aspects of software development from the technical point of view and requires a proactive participation from all the parties involved, first of all starting with the developer.
As previously said, there isn't a fixed definition of what you can achieve in terms of quality. There's no upper limit on how much quality you can put into your project. Hence, there's no limit on how much testing you can do in any project.
From what I've witnessed, there are two requirements that can speed up the process of becoming a good tester on top of being a good developer: one of these comes from the environment, the other comes from us.
The environment bit in my opinion is the one that could potentially cut the deal to acquire the right testing mindset that we are talking about, and getting there should probably be the priority of any company that decides that quality has value, and a measurable one.
Surely, having someone that can do mentoring on testing has always worked the best: learning by imitation and debating are probably the best team-oriented tools around. Even if you don't have a tester in your team, you might have noticed that in development, practices such as paired programming or code reviews can go a long way to keep the team up to speed with the practices and knowledge required.
Let's have a closer look at what this would mean in practice, keeping in mind that there is no silver bullet in terms of applied practices and methodologies, and it's your task to experiment and adapt based on what you have at hand.
In this series of practical examples on how to introduce testing in a team or project, we are going to assume a couple of requirements that are indispensable in getting you somewhere.
In this specific instance, we're going to assume you're working in a team. The ideal situation is to have a team of at least three people.
Note
If you're working with less than three people, or you're a lone developer, most of the techniques and practices tend to have a cost which might be higher than the perceived benefit.
A test plan and a sound organization of your workflow (trying to keep things simple) will not only provide a solid ground for working in a larger team if needed, but also grant you the instrument to deliver quality at speed.
First of all, you need support from the business and your direct managers; speaking of direct and indirect experience, without that you won't get anywhere. The business side of the company needs to understand what testing is, in the way that is has been described at the beginning of this chapter, the value of testing, and all the good things that this can bring. There is plenty of documentation online for you to build a business case.
Secondly, you need to have some skillsets in testing. This book should cover that part—hopefully quite well—and there are plenty of others that can teach you more theoretical aspects of testing for programmers and engineers, without considering the amount of online resources available on the topic.
Note
A few good articles you can find online are as follows:
Unit testing: Why bother? available at http://soundsoftware.ac.uk/unit-testing-why-bother/
Testing at Airbnb available at http://nerds.airbnb.com/testing-at-airbnb/
Once you've got this, you can start moving into action.
One of the situations most might find themselves in is that there is no testing culture whatsoever. Here you have two choices: either take the bottom-up approach, and get yourself familiar with TDD as a starter, or take the top-down one, where you'll take the higher perspective.
Either way you need to start having a compact test plan to adhere to. Taking as an example the approach of ACC, you start by breaking down the application/project/library into modules (components), each of them will be composed of features (capabilities). Each feature will be denoted with a particular attribute. From there you should have a compact enough representation of what you're trying to achieve. On top of this, you can start assigning a relative risk level, which you will use to give priority for your testing approach defining what and how much to test.
The resulting test plan should be signed off by all the stakeholders and updated as frequently as possible, defining the aim of the project itself. The more this document is official the better it is, as it will be considered the business card of the project.
As highlighted by many, the immediate aim is to start planting the culture of testing in developers. Define the scope of your work, both in terms of testing and development, proceed with caution and evaluate both risks and costs, and leverage on those to take a decision on how to approach tests.
Thankfully, if you're finding yourself working with Yii and Codeception, you should be spared a bit of headaches putting together different frameworks and wasting a bit of time experimenting a working solution.
Team-wise, when the experience in testing is not widespread nor solid, additional practices can be introduced that can help avoid bottlenecks or have all the knowledge trapped in a single person, such as paired programming and code reviews.
Some companies, like Atlassian, introduced test engineers that could help the teams, both from a mentoring perspective and a mere quality assurance side. Their interventions in the development cycle ended up being confined to a more restricted participation, at the very beginning and before completing the task. Their role is, nonetheless, fundamental, as they became the guardians of the testing infrastructure, the tools, and the practices to be adopted, while the developer grew to become a fully fledged tester who can cover almost any aspect of testing without much support.