Кейс: «Война миров: программисты и тестировщики. А как же качество?»

Кейс: «Война миров: программисты и тестировщики. А как же качество?».

Обратите внимание, что в файле представлена работа, только на указанную тему.

Перед покупкой убедитесь, что вам нужна именно эта работа! (ОБРАТИТЕ ВНИМАНИЕ, данная работа выложена в магазине, в связи большим спросом на работу высокая уникальность антиплагиата не гарантирована)

Другие мои работы можно найти по ссылке

1. Ситуация

Борис работает ведущим IT-менеджером компании по разработке программных продуктов. Вот его рассказ: «Когда-то я был тестировщиком и в те далекие времена порой был крайне недоволен программистами: вечные сомнительные доводы: «Это не баг, это фича» или «Если это и баг, то незначительный, пусть остается!». Да как же остается, если система колом встает!? Потом я стал программистом. И всё изменилось – меня начали жутко бесить бесконечные возвраты на доработку: То им это не нравится, то тут не работает! Да зачем было вообще в этом окне контекстное меню вызывать и вставлять нечитабельные символы!? Как они вообще до этого додумались!? Бред же, в боевом режиме так ни один пользователь не сделает! Не буду править, пусть остается! В общем, классика – вражда программистов и тестировщиков. А потом я стал IT-менеджером. И понял, что вражда эта губительна для общего дела. К счастью, я хорошо помнил себя и программистом и тестировщиком, что и помогло мне осознать истинную суть проблемы и изменить ситуацию».

Типичная ситуация: Менеджер приходит к программистам и спрашивает «когда?», а они отвечают «не знаем, мы все сделали, спросите у тестировщиков». Менеджер идет к тестировщикам с тем же вопросом «когда?», а они ему отвечают: «Разработчики только утром выдали сборку, мы только сейчас приступили к тестированию, и точно будет возврат – тут багов уже много вылезло, поэтому мы не знаем когда будет выпуск – спросите у программистов». И менеджер начинает ходить по кругу туда-сюда, а релиза все нет и нет. В итоге, терпение менеджера кончается, он собирает программистов и тестировщиков вместе и пытается как-то решить вопрос. Собственно, все решения сводятся к выработке правил взаимодействия между программистами и тестировщиками. И все дальнейшие усилия менеджера направлены на контроль за соблюдением этих правил. Вот некоторые правила, которые сформировались в отделе спустя несколько месяцев изнурительной работы менеджера:

· Совместное планирование. Версия планируется заранее. На планировании присутствуют и программисты и тестировщики. Благодаря этому, все заранее знают, что им предстоит делать. Например, это позволяет тестировщикам заранее начать составлять планы тестирования и подготавливать необходимое тестовое окружение.

· Маленькие версии. Это попытка сократить разработку, ведь это накладные расходы на актуализацию кода и повторное тестирование. Если делать маленькие версии, то можно работать сразу в основной ветке.

· Ничегонеделанье. Ещё одна попытка сократить разработку. Когда накапливается много задач, и разработка сильно убегает вперед от тестирования, то программистам разрешается просто ничего не делать, чтобы ещё больше не убегать вперед.

· Раннее информирование. Например, тестировщик приступил к тестированию задачи. Задача большая, но он уже сразу нашел дефект. Он сообщает об этом программисту сразу при обнаружении, а не в конце, когда все тестирование завершено. Или наоборот, программист ещё во время разработки сообщает тестировщику о нюансах реализации, чтобы тот заранее подготовил тест-план. Это позволяет развести работу программиста и тестировщика.