Quality product? Software testing.
A high level talk for the QA of a product.
Everyone knows that today’s software products become more complicated while we use new technologies. We use new languages or frameworks that are still in beta. React Native for example still, has not stable version 1.0. Developers are busy knowing the new techniques and implement on time the requirements. Software houses are running to catch the deadlines and pushing to deliver to their customers, so they get paid.
Then, how we guarantee the quality of the product when the developers don’t have the time to test thoroughly? Many products go for testing when go live! Or in better cases, the customer examines what he gets. How then we say to our clients that they’re getting a quality product? And let’s be serious, using an issue tracker software to add some bugs, it’s not a “characterized by careful consideration” business.
A testing strategy for everyone
The right time to organize your testing strategy for a product is …the day one (Test Driven Development). As soon as you start implementing your new sweet code of yours, you initiate the testing procedure too. All the people in the team they have to get involved. And not only them. You have to engage the stakeholders and the some of the plain users if possible. All of them.
As I read in an article recently, the Quality Assurance team doesn’t assure the quality of the product. The code itself guarantees it and the people they write it. So, each line of code from the team either makes the user happy or sad and frustrated. The user experience depends on your developers’ code quality. Certainly, the Quality Assurance team is there to alert everyone in the team about the bugs, the risk and has the open channel with the customer to communicate the problem with the broader organization.
Software teams involve all different kinds of people in the product they make: ops guys, back-end developers, front-end developers, mobile designers and developers, designers and illustrators, testers, the stakeholders and the actual users. Do not leave anyone out without a role for testing the application quality.
The strategy is: from day one until the launch day all the people that are getting involved with the project they test it. It’s a collaborative process.
Make a careful plan and engage all these fellows in.
What role do I have?
Let’s start from the …start.
All developers have to create and use unit tests before writing the lines. Unit test validates small parts of the code, small components in the system. They should exist everywhere in the application to ensure and verify that the individual classes handle the information correctly. They assure that these little components work properly under expected, boundary, and negative cases.
As a product manager or a leader of a small team, you should explain this and “enforce” them to get used to it. Well, maybe you get a: “Holy Jesus in a flaming canoe! What are you saying, dude? We’re not going to catch the fucking deadline.“ But don’t you worry about. It’s a habit. And when they start doing it, after a couple of projects they can’t live without their unit tests. Don’t forget: A developer has to prove the quality of code that she delivers and owns. Developers that write unit tests are better developers.
Front-end guys and gals have to test all their integrations with APIs or/and external services. They have to cooperate with designers and verify that the visual, hover and animation effects are working properly in all required screens. Also, they could do some integration test and ensure that the tested set of components play as they intended to do and work nicely together.
Test Engineers they should get in early in the project and guarantee that they provide early feedback to back-end and front-end people. These are the people that they are going to give a clear eye to the developers when they need a more accurate and critical feedback. These are the fellows that they deliver the issues across the team, on the right time, to the right person, with the right description and guidance.
Test Engineers are a must part of the team if you want to deliver a quality product. They have their methods, and they use all kind of different tools.
They make automation tests with — usually- Selenium. There are some other tools for automation test out there, but 50% of test developers use Selenium. I’m not the expert to tell you if this is the best tool, but it’s free and open source, it has a huge community in 40 countries around the world, and it can be integrated into other developer tools. It’s quite old fashion, and it’s very time intensive to maintain, especially with the agile development methods. But we could leave this on the test engineer choice.
They also have to do a manual test as well. These could be functional or explanatory tests to verify end-to-end scenarios that the users of the product will go through. They have to write down individual flows and procedures and test them thoroughly during the lifetime of the product. They have to test on different operating systems, different screens, and various devices. A painful process but necessary.
Let’s not forget the real people, the manual tests by real humans. They are the real feedback about the User Experience of what you’ve made. Test Engineers, as you already probably understood, are the connection points throughout the product. So in this phase too, they should contact the black box test with users that they have no insight into the product under test. These are the users that they’ll ride the car, and they’ll say: “this feels soo cool!” — or not! Don’t forget that all users are coming in your product as black box testers. The only person to settle the upcoming issues from this exercise and deliver them to the right individuals of the team with the right descriptions and indications are the test engineers.
Conclusion
We all know that we always have to maintain a shippable product. We have to deliver a steady flow of code from the developers’ cave until the user’s home. Deliver often and keep the procedure in all phases. No matter how time-consuming it is. Use as many people of the team as you can in the whole process. Use tools that are around the market for bug tracking or for any other help you need for your procedure.
We as a team use Jira Capture along with Jira bug-tracker software for the whole system. Capture is an excellent solution for the regular users too. You have instant print screens and all technical information you need to start the debugging. In the past, we’ve been through Pivotal Tracker, Trello, Producteev, and some other I can’t recall. Recently I’ve been through Google’s Issue Tracker. Yes! It has one. Well, let’s not stick to the tool. Tools are many for any taste. But the important thing it’s not the tool. It’s the artisan.
Have fun testing your product :)
If you liked this, click the💚 below so others will see this here on Medium.
