Component focused QA vs Feature focused QA
I am a recently hired QA manager at a <50 engineer startup company. While QA Manager is my official title, we are only two testers for 30 developers but we shall start to hire. My problem is that the developer team leads want more feature oriented QA resources and they claim that they need to ensure that the quality of each component is tested (unit tests and integration tests mainly) but our main quality problems has been that features are not working perfectly from end-to-end.
In my previous QA experience we have always been working with a component focused view on QA (We make sure that our component follows a specification and that the interfaces are working as expected.) This has worked OK I guess but I want to try a new approach with this feature focused QA, that verifies that the functionality is working as expected and let the team mainly worry about the component quality. This is also a step towards a feature based dev team similar to how they work at i.e. Spotify.
Idealy you would want both, some resources focusing on the component quality and some on the feature, but since we are a startup and I get to hire 1-3 resources, I think we can get a higher product UX and quality by letting the QA focus on the features.
Any experience in this? Any feedback? Currently almost no testing is going on in any steps in the dev process but work is ongoing to start with unit tests and integration tests?
Can QA resources have a divided responsibility, feature areas oriented and one of our 3-4 components? Any input for you more experienced guys?
Most of the QA teams I've worked with have focused on both feature testing and testing the individual components depending on what needs to be tested at that particular time.
I think your key issue is in your first paragraph: "our main quality problems has been that features are not working perfectly from end-to-end". It sounds to me that your best strategy is to first make sure that the components and interfaces are working correctly (since the end-to-end testing will obviously fail if the components aren't working correctly), then test the end to end process to make sure that communication between components is working correctly.
If you can, it helps to work closely with the developers so you know what their unit tests and integration tests contain (this frees your team from needing to exhaustively test internal module logic - a good set of unit tests around say email address validation means you don't need multiple tests of email address validation: you can reduce those to a simple smoke test of a valid format versus an invalid format). Good integration tests mean you don't need to exhaustively test the basics and can focus on the interactions between modules and the edge cases.
Where possible, your developer tests will benefit from having a tester's input into what makes a good test: developers tend to focus more on testing that their code does what they expect it to do, where testers tend to look more at whether it can be made to do something odd, whether the code will fail gracefully if it's given bad input, and so forth.
Above all, don't be afraid to experiment. Experimentation and exploration are often where the most valuable insights happen.
Mostly QA teams focus both on both feature & components, with a very high focus on features.
The reason for a high focus on feature is: Primary objective of achieving high-quality is to have a "working" feature (or achieve a business objective). Components usually are designed based on required business feature and it is more technical.
Focus on both can be achieved by having a test design, such as:
1. Prioritizing functional & workflow (or end-to-end) tests for testing of features &
2. Having a test grouping that enables testing of internal / external workflows across components.
Now, you can do further groupings to cover the UI, functional, validations separately and do much more prioritization based on the primary business risks.
All of the above can be put into a test strategy, which would have the blessings of the business heads, management heads & implemented by the QA team.