How to get involved in a new project and some thoughts on testing
Blog Category:
About how to get involved in a new project
- 1. For a new project, I must first understand the product from the user's point of view. If possible, I will use the product as a user with my own account and personal data. I try to make myself experience a complete user experience. Once you have your own real data in it, your expectations for a product will change completely. After you have the user mentality, I will do the following things
- Understand the product from beginning to end. Whether it is the overall design document or the design document of the main function, I will read it. As long as there is a document, I will read it
- After digesting these documents, I started to pay attention to the status of the project, especially the quality status. I would go to understand the number of bugs, how the issues are grouped, the types of bugs that have been reported, the longest outstanding bugs, the type of some recent bugs Wait, I'll also take a look at the find-fix ratio. Only when you're familiar with the whole picture of the team can you really work effectively
- 2. I'll also check the application's codebase. For each larger class, I'll look for the associated unit tests, and run those tests to see if they pass. Are the test cases valid? Are they complete? Are there integrations or side Are there end-to-end test cases? Are they still passing? What is the historical pass rate? Are these test cases just basic scenarios, or do they also cover edge cases? Which packages in the codebase have changed the most? Which ones haven’t changed in a long time? Is the documentation effort on the test side very casual
- 3. I also review all automated tests. Are there any automated tests? Are they still running and passing? Either way, I'm going to review the test code, understand each test step, see if they're complete, see if they're relevant The assumptions, pass and fail points are correct and valid. Sometimes, automated tests cover only simple tests. Sometimes, automated test suites contain complex user scenarios (a very good sign)
- 4. I will understand how the team communicates and what they expect from testers. Asking about their expectations for testing will help uncover what the development team has not tested
- 5. Next, get down to business. The first thing is to decompose the application into reasonable functional modules. It does not matter if there is a little overlap. The decomposition should not be too fine, so as not to be entangled in the details. and function
- 6. With functional modules in place, it is time to prioritize tests. Which part is the most risky? At this point, I'll check the bug library again. This time by grouping bugs by module. This will speed up existing bugs It is easier to expose recurring problems, reducing repeated bugs.
- 7. Next, I will go through all modules in more detail in priority order to create user stories. For those features that require detailed step-by-step instructions to absolutely pass/fail, test cases are usually written and linked to the corresponding module's user story
- 8. I look at different types of tests to check coverage: security, compatibility, integration, heuristic, regression, performance, load, etc.
- 9. With the above basic materials, my job is usually just maintenance and updates. Update test cases, add documentation for new features, update screenshots or videos of changed modules. Finally, observe which bugs are missed to production environment, will tell We test coverage gaps.
About test work
- When I candidly point out that some components or areas should not be tested by me, but by them, development takes my work more seriously. A lot of testers try to avoid self-promotion and public discussion that they don't test , worry that doing so will make people underestimate the value of testing. But in my experience, the opposite is true, and development will respect you for it
- I think the exit criteria for testing should be: you have enough confidence that the remaining bugs belong to those modules with low usage rate and low impact on users after a problem. This is why the application should be handled according to a certain priority Various functions and environment support
- I'll explain why a feature doesn't go live or the entire release doesn't go live in terms of impact on users
- When SET doesn't know where to start implementing tests or tools, I'll show where testing is most needed and back it up with bug data
About how to get involved in a new project
- 1. For a new project, I must first understand the product from the user's point of view. If possible, I will use the product as a user with my own account and personal data. I try to make myself experience a complete user experience. Once you have your own real data in it, your expectations for a product will change completely. After you have the user mentality, I will do the following things
- Understand the product from beginning to end. Whether it is the overall design document or the design document of the main function, I will read it. As long as there is a document, I will read it
- 在消化了这些文档之后,我开始关注项目的状态,特别是质量状态.我会去了解bug数量,问题的分组方式,已经报告的bug类型,最长时间未处理的bug,最近一些bug的类型等,我还会看一下发现-修复比例.只有熟悉了团队的全貌,才能真正有效地开展工作
- 2. 我还会去检查应用的代码库.对于每一个大一点的类,我会寻找关联的单元测试,并且运行这些测试查看是否能够通过.这些测试用例是否有效?是否完整?有集成或端到端的测试用例吗?他们仍然通过吗?历史通过率是多少?这些测试用例只是基本场景,还是也覆盖到了边界情况?代码库哪些包变化最多?哪些已经很长时间没有变更了?开发人员在测试方面的文档工作是否非常随意
- 3. 我还会评审所有的自动化测试.有自动化测试吗?是否还在运行且能运行通过吗?不管怎样,我都要去检查测试代码,理解每个测试步骤,看他们是否完整,看相关的假设,通过和失败点是否正确,是否有效.有时,自动化测试只覆盖了简单的测试.有时,自动化测试集包含了复杂的用户场景(这是一个非常好的迹象)
- 4. 我会了解团队的沟通方式和对他们对测试人员的期望.询问他们对测试的期望,会帮助发现开发团队没有测试过的内容
- 5. 接下去开始干正事.第一件事是把应用分解为合理的功能模块,有一点重叠没有关系.分解不能太细,以免纠缠于细节.也不能太粗,必须细致到可以罗列子模块和功能
- 6. 有了功能模块,就可以排列测试的优先级了.风险最大的是哪部分呢?到这里,我会再次检查bug库.这次是按模块对bug进行分组.这将加快已有bug的查找,减少重复的bug,更容易暴露不断重现的问题.
- 7. 接下来,我会按照优先级顺序更加细致地遍历所有模块,创建用户故事.对于那些需要详细的步骤说明才能绝对pass/fail的特性,通常会编写测试用例并链接到相应模块的用户故事
- 8. 我会查看不同类型的测试,检查覆盖情况:安全,兼容性,集成,探索式,回归,性能,负载等.
- 9. 有了以上基础材料,我的工作通常只是维护和更新的.更新测试用例,增加新特性的文档,更新变化了的模块的截屏或视频.最后,观察哪些bug遗漏到了生产环境,会告诉我们测试覆盖上的不足.
关于测试工作
- 当我坦诚地指出某些组件或领域的测试不应该由我负责,而应该由他们负责的时候,开发反而更加看重我的工作了.很多测试人员试图避免自我宣传,避免公开讨论他们不会测试的东西,担心这样做会使人看轻测试的价值.但在我的经验里,事实恰恰相反,开发会因此而尊重你
- 我认为测试的退出标准应该是:你有足够的信心,剩下的bug都属于那些使用率较低,出问题之后对用户影响也较低的模块.这就是为什么要按照一定的优先级处理应用的各种功能和环境支持
- 我会从对用户产生的影响的角度来说明为什么一个功能不能上线或整个发布都不能上线
- 当SET不清楚从何处开始实现测试或者工具时候,我会展示最需要测试的地方并以bug数据做支持