Тестирование проектов без тестировщиков или Как обойтись ресурсами с бенча
•Als PPTX, PDF herunterladen•
0 gefällt mir•392 views
Доклад Игоря Бондаренко на SQA Days-22. 17-18 ноября 2017. Санкт-Петербург, Россия www.sqadays.com
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Mehr von SQALab
Mehr von SQALab (20)
Тестирование проектов без тестировщиков или Как обойтись ресурсами с бенча
- 1. Игорь Бондаренко Тестирование без тестировщиков. Или как обойтись ресурсами с бенча.
- 2. • 10 лет в IT • 7 лет работы в тестировании • Head of Business Development in Neklo
- 5. Необходимо привлечь сотрудника с другого проекта на время
- 8. Сотрудника могут забрать в любой момент
- 9. У менеджера тоже есть другие проекты
- 12. Как решать эти проблемы?
- 14. Зачет в аттестационные цели
- 16. Проект должен быть задокументирован
- 18. Waterfall – плюсы, минусы, подводные камни
- 19. Спиральная модель – стоит ли?
- 22. Unit тесты приносят пользу команде
- 23. Настройте демо сервера для показа продукта
- 24. Автоматизируйте все, что можно автоматизировать
- 25. Сформируйте группы для проведения бета-теста
- 27. 5 простых правил для начинающего
- 28. Спасибо за внимание! Skype: igor.bondarenko1 E-mail: ib@neklo.com
Hinweis der Redaktion
- ДЛЯ КОГО ДОКЛАД?
- Любая ситуация, когда нужно на короткий срок подключить сотрудника с другого проекта- В конце дам советы тестировщику попавшему на такой проект ДАВАЙТЕ РАССМОТРИМ ПРОБЛЕМЫ С КОТОРЫМИ ПРИДЕТСЯ СТОЛКНУТЬСЯ
- Проекты слишком долгоиграющие, по сравнению со сроком пребывания
- - В любой момент тебя могут забрать на другой проект
- - Менеджер такого проекта, чаще всего совмещает активности и уделяет основное внимание основным проектам
- - Плохо задокументированные проекты
- 4. Что мы получаем в результате:- Работа спустя рукава 5. Как со всем этим быть и что делать?
- В первую очередь разберемся с мотивацией сотрудников почему им вообще должно быть интересно работать в таких проектах:
- Если в компании практикуются аттестации, то успехи сотрудника на внутренних проектах должны быть учтены там
- Отличный способ испытания новых технологий и тренировки сотрудников (рассказать про Magento 2 и PHP 7) Обучение новых сотрудников, стажеров, практикантов, джунов
- Проект должен быть хорошо задокументирован, что это дает: Резко уменьшает порог вхождения в проект - Никто не занимается работой, посмотрев на результат которой, заказчик скажет - это не то, чего мы хотели, давайте делать заново - посмотреть примеры хорошей и плохой проектной документации - обязательно делаем то, чему обычно учат только на курсах по тестированию - перед началом разработки тестируем документацию по проекту - Полные и развернутые тест кейсы, с одной стороны где как не здесь учиться их писать в мире чеклистов, с другой стороны, при наличии тест-кейсов можно быть уверенным, в том что если у теста стоит passed, значит предыдущий тестировщик выполнил именно тот набор шагов, который описан.
- 8. Выбор методологии разработки - Главная проблема, никогда не знаешь на какой срок к тебе приходят сотрудники и когда их выдернут на другой проект
- Водопад? Круто подходит для задокументированных проектов, однако этап разработки может затянуться на очень долгий срок. Подходит когда на бенче достаточно людей из которых можно сформировать команду, и заканчивать каждую конкретную стадию целиком и полностью. Иначе, новый сотрудник будет вынужден продолжать работу за предыдущим, что далеко не так удобно.
- - Спиральная модель? Не всегда понятно в какой момент можно остановить разработку. А нужно ли нам уточнять требования? Требует ли размер проекта остановки, для того чтобы оглянуться на сделанную работу?
- Итерационная модель. В нашем случае идеальный вариант и вот почему: -- Каждый этап можно раздробить на несколько (фурс и структура модуля магенто) (Extesion skeleton, DB scheme, Settings, Backend part, Indexer, Observers, Frontend part) -- Любой из них может быть сделан любым разработчиком -- Тестирование можно отложить на самый конец разработки -- Тестирование можно раздробить точно так же и проводить различными людьми
- Немного особенностей, которые мы применяем: -- Работа в ультракоротких спринтах 2-3 дня -- Планирование работы таким образом, чтобы испытывать постоянный дефицит ресурса (то есть в первую очередь разрабатываем то что надо тестировать, таким образом создается дефицит тестировщика, в итоге, как только у нас появляется тестировщик, он может сразу же включаться в работу)
- - Unit тесты для всего кода - тестировщик может вообще не попасть на бенч в обозримом будущем, исключительно по личному опыту, код покрытый юнит тестами, хотя бы проходит critical path тестирование без ошибок
- - Демо сервера для заказчиков - выливайте туда мало мальски работоспособную версию, вне зависимости от того что за продукт, пусть его бесплатно для вас тестируют все кому не лень.
- Автоматизируйте все до чего доходят руки. Тестируете API? Сделайте автотесты. Закончили проект? автоматизируйте регрессию, ведь он уйдет в почти бесконечный support. Закончили тестировать кусок функционала? Напишите на него автотест. С одной стороны это позволит вам потренироваться, с другой сильно упростит жизнь на проекте.
- Неважно продаете вы проекты или делаете для внутреннего пользования - сформируйте группы бета-тестеров. Внутри компании сделать это очень просто. Если работаете на продажу, то предложите бета-тестерам уникальные условия использования. Бета тесты позволят вам получить фидбек, поправить требования, и найти баги в условиях нехватки тестировщиков на проекте Бета тест - это не проект test с пользователем Test_Test и Lorem ipsum в качестве описания всего. Бета тест - это полноценное использование продукта.
- Приемочное тестирование должен проводить Product Owner, с вашей стороны должен быть тест-план и согласованный набор критериев выпуска продукта. С его стороны - клиентское тестирование и одобрение проекта. Не стоит упускать этот момент, сдавать проект надо как только продукт готов, если отложить это дело в долгий ящик, все что вы делали может покрыться толстым слоем пыли и стать никому не нужным продуктом.
- В качестве заключения советы тестировщику попавшему на такой проект: Постарайся определить сроки - Узнай этот проект, это может быть важно - Приоретизируй функционал по важности - Если ты не первый, не повторяй старые тесты, пока не пройдешь новые, это может быть важнее - Автоматизируй все до чего дотянутся руки