Стартапы и QA [закрываются]

Я твердо верю в гибкую и бережливую разработку программного обеспечения. Пожалуйста, найдите здесь после некоторых цитат из сказочной Мэри Поппендик о дефектах:

• «Осмотр для поиска дефектов - это ОТХОДЫ. Осмотр для предотвращения дефектов имеет важное значение»
• «Задача тестирования не для найти дефекты, задача тестирования - предотвратить дефекты »
• « Качественный процесс обеспечивает качество в коде. Если вы обычно обнаруживаете дефекты во время проверки, ваш процесс неисправен. "

И последнее:

• « Если у вас есть отдельные циклы тестирования и исправления, вы тестируете слишком поздно ».

Итак, чтобы ответить на ваши вопросы, моя точка зрения следующая:

• ] Задача QA - создать среду, управляемую тестированием, которая делает дефекты практически невозможными. Таким образом, QA предшествует разработке, а не следует за ним . Итак, да , начните QA как можно раньше.
• В идеале, включите тестировщиков в команду разработчиков продукта. Пусть они поработают над тестированием во время итераций. Старайтесь поставлять полностью работающий и протестированный инкремент на каждой итерации.
• Для достижения этой цели вам потребуются очень опытные люди. Им необходимо освоить большинство областей тестирования и связанных с ними инструментов: создание планов тестирования, написание (автоматических) приемочных тестов, настройка тестовых данных, в конечном итоге выполнение нагрузочного тестирования и т. Д. Знание BDD является большим плюсом, поскольку исполняемые спецификации высоко ценятся командами разработчиков.

Обычно QA не требуется до версии 1.0, и у продукта есть поток доходов.

Он просто должен «работать».

Контроль качества может быть полезен, но до тех пор, пока у вас нет финансирования, чтобы гарантировать, что продукт будет готов, добавление тела только для тестирования рискованно. Если добавление нового разработчика поможет гарантировать, что продукт будет готов до того, как закончится финансирование, тогда вам, возможно, придется изменить приоритеты и найти нового разработчика.

Разработчикам может потребоваться QA, но если это так, то человек, который

Возможно, вы захотите, чтобы ваш QA-специалист также отвечал за сборку непрерывной интеграции, например, поэтому ему, возможно, придется надеть несколько головных уборов, поскольку каждый в команде также будет носить несколько шляп. Найдите кого-нибудь, кто может быть очень гибким, чтобы помочь разработчикам освободить их для разработки.

По моему мнению, ответ следующий:

относительно первого вопроса, QA должен быть задействован во время анализа требований. Таким образом, QA может сидеть с программистом, чтобы обсудить с системным инженером, чтобы полностью понять требования. В этом процессе QA будет иметь четкое представление о требованиях и, следовательно, записывать тестовые примеры, когда программист переходит к кодированию.

В результате программист и QA завершат свою работу одновременно.

Что касается второго вопроса, QA должен иметь достаточно хорошее знание среды, в которой он должен работать, методологий тестирования, а также базовые знания автоматизации тестирования. Если это стартап, у него будет время поработать над автоматизацией и, следовательно, автоматизировать тесты регрессии и работоспособности.

Как только ваша компания станет достаточно большой и прибыльность, чтобы позволить специализацию.

Большинство малых фирм требуют, чтобы люди были универсальными и носили более одной шляпы.

Здесь нет волшебного ответа, но ключевым моментом для малого бизнеса является то, что каждый человек должен приносить больше дохода, чем ему платят; кратные лучше, чем приращения. Это факт, независимо от того, насколько ИТ-специалистам нужны независимые тестировщики.

Я ' Я представляю, что небольшим фирмам, возможно, придется проявить творческий подход и делать такие вещи, как просить друзей тестировать альфа-версии подарочных карт вместо денег или работать с доверенным клиентом.

Существует множество ресурсов, касающихся QA, тестировщиков и т. Д., И на ваш вопрос (очень хороший) нет простого ответа. Не существует волшебной формулы для определения того, когда, сколько, где и как рано они участвуют в процессе и т. Д.

Вероятно, первое, что вам следует выяснить, - это ваши реальные потребности. Большинство людей (к сожалению) приравнивают QA к простому тестированию. Тестирование - это лишь один из аспектов команды QA. Большинство людей начинают с преданных тестировщиков, прежде чем вырастут в «настоящую» команду QA.

Обеспечение качества больше связано с профилактическим обслуживанием, а тестирование - с поиском фактов.

Вам нужны тестеры или что-то еще?

] Что касается навыков тестировщика, навык номер один - это быть экспертом в области продукта. Все остальное вторично.

Перед тем, как у вас есть QA, у вас есть менеджер по продукту с видением и организацией, и у вас есть разработка. Перед тем, как нанять первого специалиста по контролю качества, менеджер по продукту должен надеть шляпу по контролю качества и уметь определять требования и приступить к работе с исходной структурой тестирования. Затем, когда проект выйдет из младенческого состояния, вы можете нанять QA, чтобы начать брать на себя задачи по управлению проектом от менеджера проекта. Важно нанять достаточно квалифицированного менеджера по контролю качества и менеджера по продукту, чтобы при разработке не пришлось надевать шляпы по контролю качества или дизайну.

Как единственный разработчик стартапа, позвольте мне высказать свое мнение:

1. Когда? Как только вы сможете себе это позволить. Я бы предпочел специального тестировщика прямо сейчас, а не второго разработчика. Я плохо тестирую собственные приложения. Я подсознательно знаю точный метод выполнения задач, поэтому мне всегда не хватает вариантов того, как реальный пользователь использует приложения.
2. Навыки? Чем больше, тем лучше, я бы согласился, чтобы тело проходило контрольный список, вручную запускающий приложение. Все помогает

Как инженер по обеспечению качества по профессии, я бы сказал, что было бы хорошо иметь специализированного QA, как только вы можете это сделать. Во время начального цикла разработки QA привнесет другую перспективу в планирование функций - насколько быстро это должно выполняться? Насколько велик масштаб? Сколько пользователей может поддерживать одна установка одновременно?

Хороший инженер по обеспечению качества постоянно находит новые способы поломки. Сосредоточиться на этом с самого начала всегда лучше, чем вовлекать QA позже в процессе, деморализуя разработчиков, которые думали, что у них все хорошо, до тех пор, пока новые QA-специалисты не свалиют на них сотни отчетов об ошибках, которые затем необходимо отсортировать (это это даже ошибка? Если бы QA был задействован с самого начала, они бы знали, что это предполагаемое поведение! и т.д.), а затем фактически исправили.

И давайте будем честными ... если мы говорим о стартапе, они не собираются писать планы тестирования или производить полезную автоматизацию. Планы тестирования прекрасны, если у вас есть стабильный продукт и вы уверены, что весь пользовательский интерфейс не изменится, а автоматизация отлично подходит для выявления регресса, но на начальном этапе разработки не будет никаких регрессов, потому что вы еще не выпустили ничего, из чего можно было бы регрессировать.

На самом деле, важные навыки, которые нужны хорошему инженеру по обеспечению качества, - это коммуникация, упрямство и способность быстро набирать обороты. Если QA находит ошибку, но не может четко и кратко объяснить, как она произошла, что они делали и как ее воспроизвести, их полезность быстро снижается.

В большинстве стартапов, с которыми мне довелось работать, редко есть специалист по контролю качества / тестированию на полную ставку.

Один из вариантов, как уже упоминалось, - найти кого-то, кто может носить разносторонние шляпы. 12111] Другой вариант - нанять их в качестве подрядчиков или фрилансеров по мере необходимости.

Также существует идея краудсорсингового тестирования, чтобы рассмотреть или найти кого-то, кто может работать удаленно, если это соответствует вашей бизнес-модели.