QA и испытания: подход к пересечению

Question

Я прихожу с запросом советов, советов, путей следования и т. Д.

Точка зрения следующая. Моя цель - разработать QA/область тестирования в компании-разработчике программного обеспечения, чей продукт представляет собой веб-приложение.

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

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

Итак, прямой ответ заключается в реализации автоматизации, я уже знаю о некоторых/многих инструментах для этого, и мы уже это делаем. Однако я хочу пойти еще глубже. С одной стороны, обычно эти инструменты ориентированы на конечный продукт, но я хочу иметь более широкий подход, ориентированный на качество каждого отдельного артефакта, т. Е. Если каждый отдельный строительный блок имеет высокое качество, вероятность наличия высокого качество в системе, построенной путем их объединения, будет увеличиваться. Поэтому моя цель - применить QA к множеству артефактов, которые производят различные области компании, скажем, технический дизайн, реализация/код, могут быть архитектурными артефактами и т. Д. И, конечно, всему продукту.

У меня есть некоторые идеи для некоторых артефактов, но нет идеи для некоторых других. Любые комментарии или критика будут приветствоваться.

Мой план заключается в следующем

Конечный продукт: по умолчанию подход: ручной плюс автоматическое тестирование

Код: Модульное тестирование в сочетании со статическим анализом

Технический дизайн: Формальная спецификация языки, такие как TLA или событие-B

Архитектура artifats: Понятия не имею, мои знания довольно короткий

Помимо навыков, необходимых для его выполнения, мой вопрос в следующем:

• Как вы думаете, что это выполнимо или реально?
• Считаете ли вы, что такой подход может помочь улучшить качество продукта?
• Стоило ли?
• Инструментов рассмотреть ...

Answer 1

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

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

Это неправильно! Автоматизация предназначена для комплимент ваши ручные усилия; не заменяйте их. Да, люди ошибаются, но это должно быть никогда не препятствует вам иметь какой-то подход к ручному тестированию.

Итак, как вы можете это сделать эффективно?

• Unit тесты. Да, это может быть обременительным и раздражающим для разработчиков, но для проверки таких вещей, как уровень обслуживания, уровень доступа к данным или уровень бизнес-логики, это необходимо.

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

• Автоматизированные испытания. Я считаю, что это хлеб-масло вашего поста, и это то, чем я очень увлечен. Мне очень понравилось article, а это well. Но во всей реальности ваш подход к автоматизации будет очень продиктован вашей командой и тем, как они работают. Попросите своих инженеров по качеству опираться на вашу команду QA и разработчиков, чтобы помочь определить, что является лучшим кандидатом для автоматизации и работать с этим.

С точки зрения инструментов, это будет абсолютно субъективная вещь. Для меня лично, поскольку наша компания делает веб-приложения, я использую Selenium/Java и Selenium/C#. Ваши результаты могут отличаться.

EDIT: Я забыл упомянуть при публикации. Не принимайте подход «это должно быть ошибкой при запуске». Это цель, которая просто не может быть достигнута.