Добрый день, уважаемые коллеги!
В этот раз основной темой было обсуждение процессов тестирования в компании «Корпоративные информационные рутины». Компания разрабатывает замечательные программные продукты для медицинских учреждений города Казани и республики.
Отдел тестирования в компании создавался с нуля. И за его работу в компании отвечает Антон Куховаренко. Наш новый докладчик. Антон рассказывал в живой зажигательной манере. Очень весело и задорно. Постоянно общался с публикой в зале. Развернуто отвечал на вопросы, и доскональнейшим образом объяснял все. Молодец Антон! Поэтому у многих не осталось вопросов, как построен процесс тестирования. Как будто сами там все время работали.
Сам Антон до прихода в КИР работал в компании, где были строго формализованы все процессы (CMMI-5!). Но в новой компании этот подход не работал. Компания в стадии развития, появляются новые сложные проекты. И надо было адаптировать процессы, уйти от жесткой формализации. Как это получилось, Антон и рассказал в своей презентации.
Лично мне понравилось, как ребята используют confluence для составления тест-планов и чек-листов. Красочные звездочки-приоритеты, кросс-ссылки на задачи помогают ребятам в работе. Здесь же в confluence накапливаются знания по продуктам, статьи по имеющимся процессам (как записывать ошибки и проч.).
Во второй половине встречи был организован круглый стол, на котором мы попытались обсудить проблемные места у ребят в КИРе и найти решения. К сожалению (судя по отзывам) не все удалось решить и на все дать ответ. Может быть из-за специфики проектов. Возможно, в комментариях к этой заметки более опытные коллеги дадут дельные советы.
1. Тестировщики плохо знаю продукт.
- Продукты сложные. Бизнес-область мало изучена. Аналитик часто занят
- Продуктов много, тестировщики переключаются с проекта на проект
- Последствия здесь очевидные – низкое качество тестирования
Рекомендации здесь были следующие:
- Договориться с ПМом и аналитиком, чтобы тестировщик имел доступ к тем знаниям, что ему необходимы
- Обучать команду тестирования новым разрабатываемым продуктам и предметной области
- Отправлять по возможности тестировщиков на объекты, где система реально работает. Это и полезно, и очень увлекательно
- Тот тестировщик (в терминах доклада «шпион»), что прикреплен к продукт, должен становиться своего рода аналитиком и передавать знания, фиксировать их в том же confluence
- Изучать продукты конкурентов, сравнивать, как у них работает та или иная функция
- Сравнивать новую версию со старыми версиями программы. (Особенно полезно, когда разные версии писались с использованием разных технологий или языков)
- Проводить ревью требований // Но тут у ребят следующая проблема…
2. Требования часто меняются.
- Ситуация знакома многим. И надо сказать вполне нормальная. Относится к этому надо спокойно
- Договориться об информировании команды тестирования об изменениях
- Приоритезировать требования, прорабатывать наиболее важные
- Продумать удобный способ представления требований
- Использовать здравый смысл
3. Разработчики не советуются или не согласуют свои действия с тестировщикками.
- Здесь сложность у ребят заключается еще в том, что тестировщики сидят с разработчики в разных комнатах, на разных этажах, а раньше вообще через дорогу
- Проблему коммуникации надо решать. Опять же - договариваться
- Привлекать ПМов. Обсуждать задачи и цели
- Познакомиться с историей войн
Пока все.
В целом встреча получилась! Мы познакомились с работой новой компании. Было задано много вопросов, и был интерес аудитории. Теперь наступает время готовиться к новой встрече, которая пройдет здесь же в IT-парке в четверг 17 марта.
До новых встреч, Друзья!
Жаль, не получилось придти, были проблемы с машиной. Надеюсь, в следующий раз)
ОтветитьУдалитьНаиль.
В Ауриге был CMMI-4 - до пятого не дотянули, но это все равно было круто :)
ОтветитьУдалить"были строго формализованы все процессы (CMMI-5!)."
ОтветитьУдалитьУжас! Вот ведь оказывается в чем смысл 5-го уровня! :)
Александр, ну это вы уже додумали. :)
ОтветитьУдалить