QA best practices
1.0.0
这是Futurice用途的质量检查实践的摘要，并建议使用。它不应该是详细的描述，有时无法完全使用所有任务，而是最重要的质量质量检查过程和应使用的良好实践列表的概述。
为了清楚起见，本文档无法描述错误或事件过程（即从生产中找到新的错误）。
Futurice团队中的每个人都有质量保证的责任，即使有命名的QA经理或质量保证专家。对于未来的质量保证意味着三件事。
在高级别的质量检查和实践中，可以分为两个过程。
此外，还有其他质量检查。
适用时，Futurice使用TDD和ATDD（接受测试驱动开发）方法。
方法迫使实现遵循体系结构并考虑所使用的模块。实现首先编写自动测试，然后实现通过测试的功能。
Futurice适用时使用对编程方法。这是分享有关正在开发的项目和软件的知识和经验的非常方便的方法。
审查代码可以帮助其他团队成员获取某些功能的信息，并有可能向负责人提供反馈，并确保团队成员之间的知识共享。
手动测试主要是使用探索性测试方法进行的，发现的错误是立即解决的，要么优先考虑并记录到任务/故事/错误管理工具。探索应用程序或服务可以在功能“准备就绪”之后立即启动。
探索性测试是最终测试的非常强大的工具，其中整个系统被测试涵盖。在方法中，测试仪超出了测试案例中可以定义的内容，应用类似用户的思维以及试图通过各种错误方案破坏系统，并且从未通过测试“完成”。
围绕功能要求和测试，通常有非功能性要求，可以测试应用本地化，可用性，性能和负载测试。需求和工具是特定于项目的。为了可用性测试，Futurice具有一个移动可用性实验室供使用。对于性能测试，Futurice已使用基于Web的服务（例如Browsermob）命名一个。对于负载测试，LoadUI和J仪表正在积极使用，以验证流量高的服务功能并找到可能的服务瓶颈。
将发现的问题记录到特定工具或董事会，其中包含优先级，环境（软件和设备信息），复制步骤，预期结果，时间和日期以及屏幕截图等信息。 Jira，Trello，PivoTalTracker，请求跟踪器等工具也被积极用于错误跟踪。
敏捷的原则之一是总体代码分支应该始终具有可能的托运。这意味着它应该始终是生产质量。这是通过以下方式实现的：
每个用户故事（或功能）都是在自己的功能分支中单独开发的。这样做的目的是确保主分支的每个更新同时均为1）尽可能小，2）有可能发挥的完整故事。
在将功能分支合并到主分支之前，它必须通过称为DONE（DOD）定义的动作，要求和实践列表。这是与客户PO和开发团队一起定义的，如果项目需要更改，则可以在项目期间修改。
提议的国防部中的以下物品已被大胆
部署过程是如何将新版本（或主分支中的版本）部署到生产中的过程。对于此过程，有三个相关环境。
连续集成（CI）服务器用于自动测试，并将代码部署到环境中。自动化测试始终是在更新这些环境时运行的。
每当已更新主分支时，CI会自动更新测试环境。这意味着在更新主分支时，自动测试用例也会自动运行。
测试环境是Futurice的主要测试服务器。预计此处已测试的任何版本都可以将其推向质量检查或生产（这取决于项目中使用的术语和集成）。
更新测试时，无需运行手动回归测试用例。在探索性测试上花费的时间经常更有益。但是，最好每次冲刺至少一次进行这些测试是一个好习惯。
质量检查环境应用作接受测试，演示或任何第三方测试或审核（安全，本地化，加载，可用性等）的环境。这不是Futurice的主要测试服务器（测试是）。客户和未来的PM之间始终商定质量检查的更新。
拥有两个测试环境（测试和质量请士）的主要原因是遵守安全和集成要求。测试允许Futurice使用敏捷原理开发服务。 QA允许客户运行其当前质量检查流程的时间和控制。
除非发布在测试环境中通过测试，否则不应更新质量检查。
产品环境是实时现场（生产）的环境。
良好的做法是至少在推送更新之前，至少在QA中部署和运行自动测试。但是，每次部署后都需要检查主要功能。
建议PO还有权将更新推向产品，而无需在QA中进行任何测试（如果在测试中传递版本）。这很重要，更新很小或简单。
最终，在敏捷开发中，当服务正在进行持续开发时，目标是对产品也有许多小型更新。即，部署过程比防弹更苗条，更重要。能够快速进行修复比拥有无错误服务更重要（显然在DOD和自动测试质量时也应该很高）。 Futurice不建议立即从这种方法开始。但是，这应该是两个组织想要去的方向。
每个移动平台都有其特定的SDK，工具集和Futurice的最佳实践。
对于Android https://github.com/futurice/android-best-practices
对于iOS https://github.com/futurice/ios-good-practices
Windows Phone https://github.com/futurice/windows-app-development-best-practices
移动平台在其SDK中提供模拟器。
在实施阶段，开发人员可以使用模拟 /仿真设备来验证更改，但是没有什么可以比实际设备测试来击败整个系统从触摸屏和集成内存到移动处理器的整个系统。
移动浏览器也可以通过Browserstack（例如Browserstack）进行测试。
Futurice在设备库中具有各种不同的设备和操作系统版本，从基本电话到高级平板电脑。
对于大型数据流量应用程序测试和性能验证，Futurice一直使用ELISA测试实验室（ELISA是芬兰移动服务提供商）。在实验室环境中，可以在受控 /隔离的环境中测试不同的负载和速度，而无需安排昂贵的，而不是有效的现场测试。
通常，移动应用程序通过移动网络连接到后端服务。为了充分利用测试，测试仪需要完全控制移动应用程序连接到的后端，以准备和执行不同的端到端测试方案。
在移动设备中，可以完成测试构建安装：通过电缆在本地使用开发SDK工具在本地通过构建配电工具（例如TestFlight或HockeyApp）进行控制。释放框架通常支持崩溃日志收集和版本数据。还可以提供DEV，Alpha和Beta版本，以便在将申请发布到商店之前收集反馈。 Google Play商店可以选择设置Alpha和Beta测试组，其中仅适用于组成员的特定应用
在现代移动应用程序中，分析和数据收集代表了需要测试的关键功能。 Futurice认为这是功能测试的重要组成部分。
由于移动应用程序更新过程与Web应用程序ONE有所不同，因此分析设置需要从第一次尝试中正确或丢失有价值的数据。更新过程是通过应用程序存储过程完成的，但是是否要进行更新取决于用户设置和活动。因此，如果第一个版本错过了一些关键的分析功能，而某些用户从不更新应用程序，那么该数据将被丢失。该解决方案可能会被迫升级，在该应用程序将无法使用，直到用户更新到可用的最新版本，但可能为时已晚。
