Testing: A Multi-Meaningful Word From a Tech Team Perspective

Testing is concept that almost every person in a tech company is doing. But if everyone is doing it, is everyone doing same thing?

Actually no. Test is a generic word and different people are doing different things under different concepts. ( I can not say that I am the ultimate test person and knowing every piece of it. But I have ideas)

This article will have 2 main parts.

1. I will try to group and classify different tests and concepts
2. I will focus one step closer to PMs roles in test concept during product development lifecycle

Ever Tried. Ever Failed. No matter. Try again. Fail again. Fail better.

This quote above is a famous one from Samuel Beckett. I find it useful but if you are on the literacy. If you are on the software development or product management, you probably want to not fail at some point.

Testing is actually a general concept. Very generically it means, there is a desired situation and there is a process checking that your product or process is suitable with desired situation. But that process differs from different teams perspectives.

Testing: Different Concepts of Testing

Software tests or Writing Tests

Writing tests is usually heard from software teams. It is the concept of testing and being sure that a software is working "ok" during or after development. Most of the time, that this of tests are software development teams' responsibility. We can add several subcategories under this category.

• Unit testing: Process of adding scripts that automatically testing the individual functions in the system
• Regression tests: This is the process of being sure that new functionality is not breaking existing functionality. ( Simplified example: You made a field non-mandatory in an API. But a service that using this API requires that field and otherwise gives error. This test supposed to find the situation and team need to solve it. Make it non mandatory or update service depends on the required solution.)
• Performance tests: It is the type of test that is checking the request - response times of services. Stability is important when sistem is loaded. So it should be tested and improved if it is necessary. ( For example if you are managing a bank app and your response time is not good enough, your customers may not be happy. Because they can not do their financial actions on time)
• Canary Release: This is actually a release technique. It is based on step by step deploying the new feature to a small set of user base. ( For example, your new feature will be available to 1%of your user base, you observe user behavior, system response times etc, if looks ok, relese to 5%, 10% and so on until 100% is completed. I like considering this risk reducing technique as a test concept. Because step by step, team tests, learns, and continues.

I am sure there are more testing concepts and even more advance methodologies. But I tried to summarize most common ones that I experienced during my projects with developers.

Testing: Be Sure "It" is Working

Testing as I summarized above is a concept. There is a condition and a person or a software tests the product for that condition is satisfied. I want to take a look at different tests of different teams:

UI Tests: Before launching a product or a new feature, flows of the app, screens, buttons, visual components should be checked. For example if a sign up button is left behind another component or a disabled checkout button is a red flag. This tests can be done by PMs, Fronet end devs or QAs

Acceptance Testing: It is the process of manually or automatically testing that new software or product is meeting the acceptance criterias.

For example: Acceptance Criteria: During registration step, user should complete all required fields and upload ID card to be able to continue. Otherwise, Continue button should be disabled.

During the test, PM or QA should test the behavior if user does not fill some of the fields. If user fills an deletes fields what's happening? After these and any other combinations of behaviour, if product behaves ok, should give ok to this test.

Security Testing: This tests are usually conducted by independent teams or external parties. Aim is to be sure that no security risks exist, no customer data is leaking etc. It is important to securely operate and keep your customers safe.

So all in all we can say that there are tests that software teams apply during their development activities to deliver the software without bugs or errors. There are also tests that PM or team can be sure that software or feature is working ok.

In addition to these we can say there are a few more type of tests:

Concept testing: When there is an idea or concept, teams prefer to test this idea. You can create a mock-up or representative model to test the idea. For example if you have an idea to rent your apartment when you are on business trips. Before building a whole website, reservation services, payment provider integrations etc, you can build a simple website and collect offers. After some tests, if you believe your idea has a potential you can invest on building the real flow.

A/B testing: This concept is actually used for UI components too. As I see, marketing teams can use it too for performance marketing materials. In modern digital world, there are a lot of customer segments and they have different preferences. Even same customer during different flows, prefer different options. So to optimize your performance, it is a good idea to prepare multiple options and test their performances on different ad campaigns.

Google adwords A/B testing: https://support.google.com/admanager/answer/7661678?hl=en

Product Manager's Role About Testing

We mentioned different test types above. Actually they are all parts of product development. For developing a successful product you need to test your concept, you need to build your product without bugs, you need to prioritize better test your visuals ( A/B), you need to be sure your flows are suitable with your user stories.

So at each step product manager need to have an involvement.

1. During creation of PRD, having clear requirements is a key. It helps to design the solution better. I know it is hard to make project requirement on day 1 but still if you have it it is better.
2. Create clear user stories and acceptance criteria. If you have clear PRDs, you can divide them into user stories. And you have clarity, you can put acceptance criteria clearly.

For that first 2 step, a PM need to have:

• A product vision. Product ideas should be in line with the company strategy and goals.
• PM need to have ( preferably better than good enough) domain expertise so it can help to prevent clashes with existing features, projects etc.
• Product team need to have a good discovery process. If there are uncertainties ( there always are), good questions, good processes helps a lot to clear them.

These are important to give clarity to development team and QA team. So they know what to build and how to test it.

If you have any additional idea, please feel free to share.