Dev Is Suspect
I am sorry to all my nice developer friends but when I am testing, I look at developers as suspect. I listen to them very carefully but never trust them without verification.
If searching on web with "Dev vs. QA", you will find out ton of interesting articles. Lots of articles raise discussions about "Should QA reports to dev or dev reports to QA?". Trust me, QA can not earn respects from developers with completely following their orders. The only way to earn their respects is breaking their codes.
Don't Get System Design From Dev
Usually, PM defines goals of a project and discuss with architects and developers to decide design of the system. It may be an easy way to get the system design from developers. But without joining the discussion of the system design, QA lost chance to verify developers understanding to system design. It will cost much more if trying to fix an design issue later.
Developers know the specific function area deeply but QA knows the system widely. QA has better point of view about overall system, should have better knowledge to test compatibility and interoperability with other function areas in same system or other systems.
Create Test Cases Before Code Complete
Don't wait developer to provide a working environment. Yes, it is much easier to try in a working environment and write test case on that but, again, you will loss chance to verify developers' understanding to design.
A good QA should always try to maximum power of team-working. Many companies are outsourcing manual test tasks to offshore team in a third-party company. We are not exception. To help the offshore test team fully understand the new feature, a set of high quality test cases are required.
Traditional Development Model May Not Apply
In the other hand, it is hard to apply traditional development model to testing in Cloud because:
- PM may not have enough time to create detailed design document.
- Multiple new features are developed in parallel and added to same system.
- Feature will be split into small packages. They may be added to different release cycle.
QA team must continually test every small change and make sure the existing features are still working normally. At same time, prepare test cases for the new feature and choose timing to run integrated new feature testing.
Usually, once main part of new feature is completed, there is only limited time remained to QA team. So, QA should join new feature planning meeting and try to put reasonable QA time in schedule table.
Review Test Plan With Dev And PM
Since detailed design document will not be available for most of the projects, it is important to review your test plan and test cases with dev and PM. During the review meeting, below points should be included.
- Detailed functionality and behaviors with specific user operations. For example, how web application behave when end user clicks refresh or back button on web browser.
- List all related existing functionality/features, and confirm with dev and PM how they are impacted with new feature added.
- How many active users are expected?
- What is expectation of performance?
