被采访为Java Dev，但被聘为首席质量检查官。没有质量检查经验。我该怎么办？

#1 楼

其中一些与新雇用的软件开发人员没有什么不同：



了解公司如何赚钱。了解产品解决了什么问题，人们如何付款，如何部署（您是运送还是托管？）。

向每个人介绍自己。通过主动向所有人介绍自己并询问他们的所作所为，可以产生很多善意。您不必对此进行深入的研究，但是知道以后每个人的问题都会对每个人的高层都有帮助。而且您将需要这种善意，因为最终您将要求其中的某些人（尤其是开发人员）做他们可能不想做的事情。

从高层次理解产品。请高级人员为您白板产品。了解主要组成部分，它们之间的通信方式以及在为企业赚钱方面最重要的部分。

阅读文档。可能没有太多的文档，但是请阅读可用的内容。

亲自尝试该产品。有些产品比其他产品更容易试用，但您可以做得到。记下您无法尝试的部分，因为这些部分可能很难测试。

在错误跟踪系统中进行挖掘。如果没有错误跟踪系统，请尽快设置一个。如果有一个，请检查错误。查找容易出现故障的区域。查找存在大量积压错误的区域。

询问质量问题。问几个人，因为您可能会得到不同的答案。询问开发商。问经理。询问客户支持人员。

找出现在进行什么样的测试。哪些区域经过测试，哪些区域没有测试？什么很难测试？没有足够的测试？如何测试事物：多少手动，多少自动化，哪些工具，记录在案的内容，刚刚从内存完成的工作？测试整件事需要多长时间？发布会花多长时间进行测试？

随着学习的更多，您将开始了解应该如何测试软件的变化。对于某些事情，唯一的变化就是您将进行测试。您可能会决定按照以下顺序执行某些操作，而无需按特定的顺序进行操作：



编写面向测试人员的文档。您可能会编写测试用例，高级文档或其他内容。写东西可以检验您的理解，也可以帮助您雇用的人。

思考自动化。您是软件开发人员，因此对如何编写软件以测试软件有一定的了解。您可能没有使用过一些开发人员可用的测试工具，例如Selenium用于UI测试，JMeter用于性能测试。您可能想知道它们的作用，但不一定必须使用它们。这将由优先级决定。

列出您要更改的内容。您作为公司（和质量保证）新手的身份为您带来了巨大的优势：您的观点是，没有其他人会这样做，并且您不认为今天的工作方式就是他们应该如何工作。

还有很多其他的东西，但是您在学习时会发现它们。如果某些事情看起来不正确，请记录下来。随着清单的增加，您可能会对需要的其他资源有所了解，无论是工具，人员还是时间。

#2 楼

在某家小型软件公司中没有正式QA经验的人从头开始创建QA部门的任何技巧，其产品仍在尝试了解所有知识？

我将传递一些技巧，但首先让我问：您是在没有任何讨论的情况下宣布为质量检查的吗？如果这反映了组织/经理的工作方式，则可能会令人担忧。认真考虑是否要在这里度过一些职业。现在，如果您进行搜索，还有很多其他机会。

但是，鉴于此，我将推荐以下内容：


学习并成为冠军质量保证最佳实践。
关注实际用户以及他们与软件的交互方式
关注“悲伤”的路径（例如，有错误的表单），因为软件开发人员倾向于将大部分精力放在幸福的道路
，如果您使用的是敏捷开发过程，请学习“敏捷测试-测试人员和敏捷团队的实用指南”一本关于如何在敏捷环境中进行质量检查和测试的现代奇妙书籍。http：// lisacrispin.com/agile-testing-book-is-now-out/

了解可用性。在美国，请参阅http://www.usability.gov/what-and-why/index.html

对于网页，了解有关可访问性，第508节（如果是美国）和WC3建议。 br />请参阅https://www.w3.org/standards/webdesign/accessibility

了解开发人员的个性，并弄清楚如何提供积极的建议和改进建议，而不是消极的建议。
了解您所处的业务领域，以及您所工作的公司的目标是什么，以及对高级管理人员而言意味着什么“质量”。从增加收入，增加客户群到提高日常使用的客户满意度，这都有所不同。

了解测试的四个象限：

Integrated   Performance

Unit         Exploratory

>
了解测试的三角形，成百上千的单个单元测试支持一些高级功能UI测试。

     UI
 Integrated
Unit Testing

确保有一种简便的方法质量检查人员将问题记录在问题跟踪系统中，并且该质量检查人员有权执行此操作。然后应记录记录的问题，例如在每周的sprint检查期间进行检查（敏捷）。

在以下方面要充满激情和更加持久：


间歇性错误
可用性问题
最佳实践

您经常需要长期关注这些问题，并且需要不断为它们辩护。

参与整个过程，包括设计，审查和定期状态会议。
从一开始就致力于嵌入式质量。这意味着与开发人员一起制定测试计划，使用静态分析工具并在编码时推动质量计划。一旦将所有内容写入并编写完成，并且更改的成本要高得多（花费时间，遇到阻力等），就可以通过流程而不是质量保证手动测试来思考质量工程。向团队解释这种区别。我的经验是，大多数组织仍从质量保证的角度看待质量，而不是质量工程。
了解公司产品和行业的信息
，请参阅https://sqa.stackexchange.com/a/ 17677/8992了解详细信息。