Любая ситуация, когда нужно на короткий срок подключить сотрудника с другого проекта- В конце дам советы тестировщику попавшему на такой проект
ДАВАЙТЕ РАССМОТРИМ ПРОБЛЕМЫ С КОТОРЫМИ ПРИДЕТСЯ СТОЛКНУТЬСЯ
Проекты слишком долгоиграющие, по сравнению со сроком пребывания
- В любой момент тебя могут забрать на другой проект
- Менеджер такого проекта, чаще всего совмещает активности и уделяет основное внимание основным проектам
- Плохо задокументированные проекты
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, с вашей стороны должен быть тест-план и согласованный набор критериев выпуска продукта. С его стороны - клиентское тестирование и одобрение проекта. Не стоит упускать этот момент, сдавать проект надо как только продукт готов, если отложить это дело в долгий ящик, все что вы делали может покрыться толстым слоем пыли и стать никому не нужным продуктом.
В качестве заключения советы тестировщику попавшему на такой проект:
Постарайся определить сроки
- Узнай этот проект, это может быть важно
- Приоретизируй функционал по важности
- Если ты не первый, не повторяй старые тесты, пока не пройдешь новые, это может быть важнее
- Автоматизируй все до чего дотянутся руки