Мантра начинающего тестировщика
Я глубоко убежден в том, что в большинстве it-проектов, где вовсю полыхает костер конфликта "тестировщики vs программисты", чаще всего дровишки подбрасывают именно тестировщики. Они не понимают нужды конкретного проекта, по-своему истолковывают требования заказчика. Многие из них даже не в курсе, в чем заключается работа тестировщика вообще. В итоге имеем то, что поднять вопрос о престиже профессии не поворачивается язык даже у самых отчаянных и радикальных их последователей. Никто в здравом уме не идет в тестеры целенаправленно, по призванию или так как с детства мечтал быть тестировщиком. Чаще всего вхождение в тестеры происходит спонтанно, по связям, из-за отсутствия вакансий после окончания вуза, из-за нужды в деньгах, по советам знакомых айтишников или по другим необъяснимым для человека причинам. Короче, случайных людей в тестировании хоть отбавляй. Далее я попытаюсь изложить свои мысли насчет того, с каким настроем бы относился к своей работе, будь я тестировщиком с относительно небольшим опытом работы в какой-либо продуктовой или аутсорсинговой it-компании средней величины.
1) На текущем проекте я призван играть второстепенную роль. Все до безобразия просто: либо снимаю розовые очки и работаю, либо закрываю дверь с той стороны. Отношение ко мне со стороны программистов мерзкопакостное, как к человеку, который получает деньги за просто так, кликеру по формочкам и эксперту по никаким вопросам. Я сейчас не прокачан настолько, чтобы попасть в крутые компании (речь даже не об уровне Microsoft или Google), где тестировщик воспринимается как равноправный человек. Поэтому и веду себя соответствующим образом: выполняю свои непосредственные должностные обязанности, пытаясь уложиться в поставленные начальством сроки. Не строю из себя всезнайку, примадонну, строгого судью, тонкого психолога, способного подловить собеседника на лжи по взмаху его ресниц. В случае зазнайства надо быстро снять корону и положить ее на дальнюю пыльную полку до лучших времен (которые в нынешней конторе вряд ли настанут). Я не потираю ехидно ладошки, когда в состоянии потока в результате часового пиксель-хантинга под IE 6 нашел поехавшую верстку. Наверняка об этом не следует знать никому другому на свете и любой, кто поднимет подобный вопрос, будет исключен из общего чата. Кстати стоит хорошенько задуматься, почему я настолько уныл, что битый час тестирую фронтенд на наличие минорных багов, хотя поручено было проверить функциональность и логику работы программы.
2) Я не вмешиваюсь в работу остальных отделов со своими сверхценными и безусловно полезными советами. Не проявляю бредовых инициатив, не пытаюсь жирафить или лезть в командиры. Если где-то и существует креативная, разносторонняя личность, то это точно не я. Проблема как раз и заключается в существовании синдрома фонарного столба: я ищу там, где светло, а не там, где потеряны ключи. Я, к сожалению, воспринимаю проект только с позиции узколобого тестировщика и не имею полной картины происходящего. Именно поэтому иногда мне чудится, насколько же кардинально можно улучшить наш проект, стоит только чуть побольше внимания уделять тестированию. Разработчикам, без руля и ветрил, сломя ноги надо броситься внедрять TDD, писать до ночи юнит-тесты, обеспечить стопроцентное покрытие кода. Менеджерам наивысшим приоритетом для проекта ставить качество проекта с точки зрения тестировщиков, всегда немедля ни секунды принимать положительное решение об исправлении каждого заведенного мною запроса. Техническим писателям лучше вчитываться в документацию, чтобы искоренить грамматические ошибки. Дизайнеру проверять макеты на предмет того, что можно еще улучшить и думать только об удобстве интерфейса для пользователя. Бизнес-аналитику чаще размышлять над двусмысленными требованиями в техническом задании, интересоваться мнением заказчика о качестве продукта посредством анкетирования, доносить до него мнение отдела тестирования по всем возникающим вопросам. Менеджеру по продажам акцентировать внимание клиента на том, что наша компания сертифицирована по ISO и производит только высококачественные продукты... Все перечисленное звучит вроде правильно, да? Но как известно, благими намерениями дорога в ад выстлана, а лучшее враг хорошего. На самом же деле, я дилетант широкого профиля. Кроме тестирования я по сути ни в чем не смыслю даже поверхностно: ни как грамотно руководить людьми, ни как писать работающий код, ни как делать полную документацию, ни как эффективно продавать продукт, ни как строить переговоры с заказчиком. Менеджер это понимает, поэтому я настолько максимально отстранен от решения реально возникших проблем, насколько это возможно. О моем существовании вряд ли узнает заказчик. Иначе при встрече с ним я на ломаном английском начну нести такую ахинею про бороздящие просторы вселенной космические корабли, что расхлебывать потом будем месяцами, долго и мучительно. Я максимально избегаю философских споров и разговоров ни о чем, на что точно не могу оказать влияния. Я ловлю себя на мысли, когда на собрании тестеровщиков с пеной у рта коллеги спорят о велосипедных будках при проектировке атомных электростанции, — сейчас надо держать свой паршивый рот на замке. Даже если из дерзкого монолога другого коллеги-тестера, который высказывает свое единственно авторитетное мнение, можно собрать bullshit bingo. Не надо так, рубить правду-матку с плеча. В любых организациях значительно безопаснее ошибаться вместе с большинством, чем быть правым в одиночестве.
3) Я начинаю узнавать, что такое тестирование на самом деле. Это не проверка того, соответствует ли программа предъявляемым к ней формальным требованиям, которые прописаны на бумаге. Тестирование — это техническое исследование программы для получения информации о ее качестве с точки зрения заинтересованных лиц. Тестировать — значит ломать чужие иллюзии о том, как работает программа, давать другим участникам проекта информацию о том, с какими проблемами пользователи могут столкнуться при работе с продуктом. Это инженерная специальность, где для успешной работы и дальнейшего роста необходимо знать множество деталей относительно процесса разработки ПО хотя бы поверхностно и быть готовым постоянно учиться. К качеству же я имею весьма посредственное отношение. Качество — это значимость для некоторого человека, чье мнение на проекте играет решающую роль, является определяющим для всех остальных участников. Грубо говоря, если я вдруг в день релиза звоню во все колокола с криком о том, что качество на проекте скатилось ниже плинтуса — это не повод задерживать релиз. Я как тестировщик не обеспечиваю качество. У меня нет на это полномочий. Я не определяю, какие проблемы будут исправлены в следующем релизе, какие фичи более приоритетны, кого надо нанимать, увольнять, кому выплатить премию. Я не приглашен на обсуждение архитектуры нового проекта, не имею права голоса при выборе языка и фреймворков для разработки, не устанавливаю методологию разработки. Это дело менеджмента определять то, какой уровень качества для проекта приемлем. За 80% проблем качества отвечает менеджмент. Когда после переговоров с заказчиком на месяц сокращен срок выполнения проекта при сохранении scope, когда не хватает толковых разработчиков и наспех набирают вчерашних студентов, надеясь вывезти за счет количества — это все намекает о культуре компании и, как следствие, влияет на качество ее продуктов. Я лишь малюсенький винтик, необходимый для создания впечатления заказчику, что на проекте присутствуют люди с лычкой Quality Assurance, следящие за качеством. Я могу предложить улучшить продукт, конечно, как и любой другой человек с улицы, но вообще-то лучше просто тестировать продукт. Усидеть на двух стульях крайне сложно: либо я пытаюсь хорошо протестировать и оставляю суждения о качестве на совести лиц, принимающих решения, либо я заморачиваюсь вопросами качества, хотя мне за это не платят, и из рук вон плохо тестирую продукт. Я должен думать над собстенными профессиональными возможностями, стараться определить пути для их повышения и никогда не действовать вне рамок своих компетенций.
4) Решение об установке приемлемого уровня качества принимают управленцы на основе того, кто и как будет использовать продукт. Риски за принятые решения берут на себя они же. Им за это платят немалые деньги. Мнение технического специалиста о качестве программы подчас не является сколь-либо значимым. Я понимаю, что ужасно не удобен интерфейс, не те шрифты и не сочетаются цвета боковых панелей. Но именно у этого проекта прямо сейчас горят сроки, его надо сдать по ПМИ, стрясти за это деньги с заказчика, отгрузить и навсегда забыть. Да, адаптация красноглазых айтишников к бизнес-нуждам происходит всегда болезненно. У нас коммерческое предприятие, поэтому особенности поведения заказчика, его представления о качестве имеют более приоритетное значение. Люди всегда руководствуются личными критериями качества, которые являются эмоциональными, а не рациональными. Не существует объективного критерия оценки качества, кроме прибыльности. Если смотреть с этой стороны, то универсальным критерием качества продуктов коммерческих предприятий является рентабельность. Если у проекта по бухгалтерской отчетности за некоторый выбранный руководством период есть прибыль — то это качественный проект, если убытки — проект некачественный. И не следует усложнять: многих может смутить, что идеально исполненный с технической точки зрения и протестированный проект, который лично мне ой как нравится, заказчик назовет некачественным. Все просто: мы не уложились в сроки, за прошедшее время у бизнеса изменились требования или положение на рынке, в результате продукт стал никому не нужен, так и не вышел, мы остались в долгах у разбитого корыта. Качество — это не то, что участники проекта вложили в него, а то, что клиент из него извлек. И кстати, если я, находясь в должности рядового тестера, вдруг осознал, что полностью понял хотелки заказчика и единолично готов делать суждения о качестве проекта, то надо налить кружечку зеленого чаю, откинуться в кресле, посмотреть на пейзаж за окном и успокоиться. Должно в течение получаса отпустить. Я просто ошибаюсь по поводу того, какие очередные свистелки и перделки возжелал заказчик; надо годами ежедневно вариться в сфере деятельности заказчика, чтобы понимать нюансы в его предметной области.
5) Когда менеджер обращается ко мне, ему нужна информация о том, существует ли здесь и сейчас невыдуманная проблема, плюс можно ли нам смириться с этим? Все остальные вопросы про метрики, соотношение passed/failed и т. п. — чепуха полная. В ряде случаев целесообразно замерять затраченное на тестирование время, но всецело полагаться в будущем на полученные затраты на проверку я бы не стал. Циферки не говорят ровным счетом ни о чем. Как мы знаем, есть ложь, наглая ложь, и статистика; поэтому важно не то, какие данные были получены по результатам тестирования, а что за человек занимался подсчетом результатов и созданием красивых диаграмм в power point. Можно легко не учитывать ряд проваленных тестов, списав это на несовершенность окружения, можно незаметно подкорректировать в желаемую сторону метрики. Если менеджер говорит со мной только про неинтересные вопросы, то я настолько дискредитировал себя в глазах остальных отделов, что никто не доверяет мне даже предполагать, что является проблемой, а что нет. Мне не доверяют как профессионалу, следовательно, я не могу реализоваться на этом месте работы. Вот пример. Legacy-проект, которому уже лет пятнадцать от роду. Людей, стоявших у истоков, определявших его архитектуру, понимавших общую картину и принципы работы, давно нет с нами рядом. К проекту в течение его жизни приложили руку десятки людей, которые тоже давно пропали из виду. Велосипеды на месте, костыли держат уверенно, — стабильность, одним словом, реальных проблем нет. Но у меня этот проект вызывает ментальное отторжение. Там все плохо, кое-как работает, куча багов. Хотя проектом пользуются и жалоб от заказчика не поступало... Он успешен, так как по-настоящему унылые вещи долго не живут. Так ли надо выяснять у тимлида, почему нельзя все переписать с нуля на Ruby и сделать так, как хочет Его Величество Тестировщик? Программ без ошибок не существует. Это обычное дело, когда до конечного потребителя доходит продукт с некоторым количеством ошибок. В релиз однозначно не должны попадать критичные проблемы, приводящие к невозможности использовать продукт по назначению или большим проблемам в процессе использования. Малозначимые проблемы в частях системы, куда пользователи попадают лишь по ошибке, косметические дефекты в фронтенде, недоработки в наспех сделанной фиче — в определенных ситуациях все это вполне допустимо. Наверное, мой нездоровый перфекционизм здорово вредит экономической составляющей проекта. Поэтому надо выбрать момент, когда разумно остановиться штамповать запросы в баг-трекинг систему и считать качество продукта достаточным.
6) Отдельная песня — источники информации о тестировании. У соседа приколочен диплом ISTQB на стену в кубике — мне немного завидно, так как лень вызубривать терминологию тестирования для его получения по предоплате. Хотя это выглядело бы так же смешно, как у программистов диплом об окончании двухнедельных курсов Java. Принадлежать к организации профессионалов тестирования и быть профессионалом в сфере тестирования — сильно разные вещи. Еще я давно понял, что на форумах и конференциях выступающие заняты самопиаром и продажей себя (или продуктов компаний, в которой они на данный момент работают). Делю на сто смело все их обещания со сцены, что новомодный фреймворк для тестирования спасет планету от нашествия багов, а уникальная методология перевернет мир, попутно решив все мои насущные проблемы. Последние места, куда я лезу в поисках информации о тестировании — это русскоязычные блоги и википедия. Все имеет контекст: что в одной фирме ценится и прекрасно работает, в другой дико не приживется. Играться с технологиями за деньги заказчика было бы увлекательно, но слишком нерационально. Разве станут в открытую для конкурентов трещать о том, что так классно работает? Станут безвозмездно выкладывать на github многолетние наработки, сделанные внутри компании? Скорее всего, доклады и выступления евангелистов сделаны с целью, чтоб я после конференции бросился внедрять принципиально новые идеи в жизнь, попутно натыкаясь на все ошибки и описывая свой опыт для более рациональных коллег, кто решил учиться на чужих ошибках. А в open source попадают частенько достаточно сырые, но разрекламированные поделия для автоматизации тестирования. Должно пройти хотя бы несколько лет, чтобы дела устаканились, появились первые объективные отзывы о достоинствах и недостатках. Поэтому я в речи не употребляю слово «правильно»: что это такое за зверь не знает никто. Вместо него лучше употреблять: подходит для нас в данный момент, наиболее целесообразно в текущей ситуации, приемлемо на этом этапе развития. И вместо слов «бага» и «ошибка», которые имеют негативную эмоциональную окраску, я использую: недочет, проблема, замечание, несоответствие. Не мне решать, что бага, а что нет. Может выясниться, что на самом деле все нормально. Это я сел в лужу, не по инструкции настроив окружение или поправив не те конфигурационные файлы методом copy and paste. А я уж поспешил похвастаться соседям найденным блокером. Мда… Problem exists between keyboard and chair, как говорится. Да и какому программисту понравится, когда радостно тыкают пальцем в монитор, ехидно щурясь, а в глазах так и читается: «бага, ха-ха! Я нереально крут, я нашел ошибки в твоем коде, их много и ничего не работает! И пока ты не исправишь, я не отстану!». Добавлю, разработчиков желательно стараться не отвлекать до самого последнего момента, в разумных пределах. Если появились подозрения в некорректной работе программы, то после тщетных самостоятельных попыток разобраться следует идти к коллегам, далее к тестировщикам старше по должности, тест-лиду, и уже затем к программистам. Сор из избы не выносить не стоит, выставляя себя посмешищем для окружающих.
Напоследок хотел бы заметить, что в тестировании при желании, трудолюбии и терпении можно стать высококлассным специалистом, это вопрос времени. Есть достаточно людей из числа тестировщиков, с которыми приятно иметь дело. К тому же прошлый опыт, например, в бухгалтерии или банковской сфере, может вмиг сделать человека ценным специалистом на проекте из-за специфики предметной области. Я уверен, что с таким настроем, который я описал выше, конфликта при взаимодействии тестировщика с программистами практически не возникнет.
Забыла ноутбук.
Работаю тестировщиком ПО.
Коллега забыла ноут в офисе, собственно вот:
Смеялся я долго)))
На следующий день, я ее трольнул по этому поводу, но она даже не поняла, что не так то написано)))
Вспомнил этот случай из-за этого объявления:
Может конечно это ее объявление)
Хреновый тест
Запускаем новую фичу на тест, ждем всей командой запуска как Новый год. Запустили. Молчание. Один из разработчиков выдаёт:
- Всё верно.
- Откуда ты знаешь, что всё верно?
- Там херня, и тут херня - всё верно.
Отчет о вхождении в специальность. Soft tester. Часть 2.
Часть 1 ,в общем, пишу специально для тебя, @rusggmu,
Ну что же, началу положено. Я смог определиться с тем, с чего начать, не без помощи (а вернее в основном с его подачи) @oOFlyAngelOo, а товарищ @Grammofon, поубавил оптимизма, и надо сказать не зря - выбора как такового и не было.
Решил я податься в тестирование, ну и само собой начать со знакомства с профессией (интернет only).
Первое с чем я столкнулся - язык, всё же, надо учить. Можно надеяться на то, что требовать этого никто не будет, но терминология русифицированная звучит убого и лично мне очень сильно бьет по уху. Да и вопросы на интервью будут возможно не все на русском.
1. Нужно четко понимать на, что ты способен, я для себя выделил несколько направлений в тестировании:
1) "Black box testing" (как я понял тестирование с позиции пользователя, сознательно или несознательно никак не касаясь кода).
2) "White box testing" (тестирование "следуя коду" - это я так для себя уяснил), сразу скажу, что без познаний в "кодировании" мне там делать нечего, как и говорили мудрые люди в предыдущем посту, даже при тестировании сайта на 3,5 инвалида, нужна серьезная подготовка и знания. Люди в этой области особые и тестирование разное бывает.
3) Есть еще специфичные области типа : "Grey box testing", "Тестирование игр", "Тестирование безопасности", "Автоматизированное тестирование" (о нем скажу позже) и другие области, я не заморачивался, в изучении всех их, и оценив свои силы и того, что познаний в коде у меня нигде огромных нет - выбрал Back Box. Хотя люди знающие скажут, что иного пути и нет))
2. Есть у меня знакомый который сменил сферу деятельности (банковский служащий) на профессию тестировщика, и он немного мне помог сделать первое резюме из того, что было - блата никакого, просто показал его своему тимлиду.
вот что вышло
Оно переработанное с ХХ. Понятное дело это был первый шаг. Вердикт - "что за говно ты мне только что показал" "буду держать в голове, глаз ни за что не зацепился в резюме".
Проблема на этом этапе очевидна, не умею делать резюме - не знаю, что хотят видеть рекрутеры. Я смекнул, что неплохо бы озаботиться изучением правил оформления резюме и посмотреть примеры.
3. Честно признаюсь, изучал тему не так долго - за 12 дней на усваивание новой информации потрачено в общей сложности дня три. Длясебя выделил пару книг по рейтингу литературы на тему в интернете: 1. "Тестирование Дот Ком" - Роман Савин
2. "“Тестирование программного обеспечения...." - Сем Канер Дочитаны мною даже не до половины, ибо я распыляюсь, когда изучаю что-то новое. Да и жить на что-то тоже нужно, поэтому отголоски прошлой работы, тоже отнимают много времени.
Не знаю насколько жизнеспособны сейчас видео уроки 12-го года, но мне очень понравились уроки Портнова (рекламировать не буду, сами найдете на ютубе), очень много полезной информации, поправьте меня если есть более полезныые, с удовольствием посмотрю.
4. В общем, кое-как, потихоньку, тема начала раскрываться. Я совсем чуть-чуть познакомился с тестированием GUI и с основными принципами тестирования всего на свете (угодных рекрутерам конечно). Сделав самое простое и до безобразия честное резюме на ХХ, я начал массовую рассылку. И ответ не заставил себя ждать:
Связавшись по Skype, и немного поговорив, мне выслали тестовое задание.
Ссылка на задание. Оно оказалось несколько сложнее чем я предполагал и включало в себя подобные вопросы (выбрал самые для меня сложные):
Sql я ни разу до этого не видел, но целью было ответить в этот же день, хотя оставалось 2 часа. К слову, я так и не успел. Скорее всего неправильно, но это лучше чем написать - я не знаю.
Ну а с логами я вообще никогда не сталкивался.
Подводя итоги: сейчас в ожидании ответа рекрутера, не уверен что все прошло гладко, ибо отвечал честно, но что-то я показать все же смог (ошибки по тесту нашел, отличия вроде тоже все) но эти вопросы, как мне кажется были не основными. Если эта тема будет интересна кому-то, будут последующие посты. Извиняюсь за сумбурность поста.
Кому что интересно - в комментарии, там же хотел бы услышать критику, и кучу советов. Так же, там могу прикрепить скрины остальных ответов на пункты теста.
Спасибо за внимание!
Разыскиваются желающие пройти тестирование
Здраствуйте жители Пикабу)
Меня зовут Оля и я затянула с написанием своего диплома
Но все же прошу помощи. Мне очень срочно нужны программисты для подальшего написания практической части диплома. Пишу о процессах выгорания среди Вас. Соответственно могу позже в пост добавить результаты тестирования (если будет интересно)
На счет анкетирования, в среднем занимает 10-15 минут, анонимное и простое. Оно включает в себя 4 блока. Сначала простой опросник, а дальше 3 теста (на выгорание, общую потребность в достижении цели, а также методика для составления мотивационного профиля)
Ссылка: https://drive.google.com/open?id=1WjLRJlQlRBg8bFH9W4kobpJe1X...
Поднимите в топ,пожалуйста, комменты для минусов оставляю
Пол года в тестировании или взгляд с колоколенки
Почти год назад я спрашивал мнения у вас, ребята, по поводу профессии тестировщика. Было много дельных советов, и не очень, но все они были полезны в коей-то мере. И вот, я уже ровно 7 месяцев как тестировщик. Возможно, что кому-то будет полезен пост. Вероятно, что именно ты задумываешься о том, чтобы начать строить карьеру в тестировании, но пока обременён другими заботами. Я постараюсь максимально простым языком поделиться своим скромным опытом, и возможно, повлиять на твоё решение в вопросе "хочу ли я быть тестировщиком?".В общем, заваривай чайку, хватай печенюги и усаживайся поудобнее. А я беру бокал креплёного и начинаю.
Преамбула.
Войти в Ай-Ти или хлопоты "входа"
Немного цифр. После окончания универа по профилю "Энергетика" я уже окончательно для себя решил, что хочу быть тестировщиком. У меня всегда была тяга к тому, чтобы всё, чем я пользуюсь было идеальным + большое увлечение компами и еже с ними. Небольшой опыт кодинга (говно-кодинга) в конце 10-11 класса школы и первых курсов универа, но со временем всё забылось. После получения заветной корочки и месяца беспросветных кутежей, я составил резюме и начал шерстить вакансии на хх. И вот, первый отклик. Мне выслали тестовое задание, с ним я к сожалению не справился. Как говорится, первый блин комом. Затем почти один за одним были еще 3 ответа к моим откликам. Каждая компания высылала тестовое задание, которые я уже успешно выполнил и впереди у меня состоялись 3 первых в моей жизни собеседования. Первые два я успешно провалил, а на третьем, уже имея некоторый опыт в общении с HR и тестировщиками, успешно его прошел. Спустя приблизительно неделю в один жаркий летний день мне позвонили и сообщили, что с 1 сентября я выхожу на работу. Это была моя маленькая победа. К слову, я даже рад, что в предыдущие места меня не взяли, но об этом дальше.
Ах да, цифры, подытожим - 4 отклика, 4 тестовых задания, 3 собеседования, 1 успешное, затраченное время около 3 недель.
Испытательный срок или оклад за обучение
После оффера (успешного прохождения собеседования и приглашения на работу) я начал усиленно готовиться, читал блоги, смотрел видео, впитывал и вкушал опыт других, бывалых тестировщиков. Первые два месяца я приходил на работу и изучал документацию по продукту, который мне предстояло тестировать, смотрел видео-уроки (записывали их тестировщики из компании). Очень круто, что для лёгкого входа новичков был весь необходимый материал, это очень помогло. В течение месяца я каждый день изучал новое, а два раза в неделю общался с менеджером разработки (член команды, который ставит задачи, общается с заказчиками и вообще, занимается многими организационными вопросами + защищает нас от других команд, которые хотят скинуть свои косяки на нас), рассказывал ему, что нового узнал, отвечал на его вопросы. Честно, я ощущал себя идиотом, который нифига не понимал, но очень хотел и старался вникнуть в процесс. Какие-то непонятные названия, странные слова Agile, Scrum, МР, ПМ, Тим-лид и прочие, уже кажутся такими простыми и примитивными, но тогда, будучи совсем зелёным, я их до конца не мог сложить воедино. Первые три месяца пролетели быстро, но их я запомню на всю жизнь - это самое болезненное время, когда много, просто невероятно МНОГО информации, которую нужно усвоить и научиться использовать.
И вот, наступил декабрь. К этому моменту я успешно прошёл испытательный срок. У нас была даже некая балльная система, по которой по всем критериям у меня было 5/5, что не могло не радовать + положительный отзыв МРа. И в декабре, когда я уже неплохо освоился, состоялась ретроспектива. Ретроспектива - это некое собрание, когда команда обсуждает предыдущий квартал, какие были проблемы, находит пути их решения, подводит итоги и строит планы на следующий квартал. Цель - стать лучше. Одна из задач - разрешить предыдущие проблемы. И на этой ретроспективе я понял, что эта команда та самая, с которой можно свернуть горы и сделать наш продукт очень крутым. Я много читал историй, когда коллектив, мягко говоря - хрень, но в моём случае все более, чем круто сложилось. Ребята, зная, что я совсем зеленый, легко отвечали на все мои самые глупые вопросы, чем я старался не злоупотреблять.
Пошло-поехало
Прошло ровно пол года, как почувствовал, понял, осознал (как это не назови), что тестирование - это моё. Именно спустя пол года я понял, что то, чем я занимаюсь - это призвание. Естественно, что бывают косяки, не тестируемые задачи и прочие грустны вещи, но целая картинка позитивна!
Результат работы
Спустя 7 месяцев я научился и освоил некоторые инструменты и приобрёл скиллы, а именно:
PostgreSQL (СУБД) на уровне, который нужен тестировщику (анализ связей в БД, типов данных, запросы для тестирования и выборки данных);
Консольку Linux для просмотра логов, кода на тестовых стендах, правки "на горячую", всякие curl и прочие мелочи;
Различные техники тест-дизайна;
Буквально в последний месяц начал писать автотесты в связке Ruby+Selenium Webdriver+(всякие гемы аля Browsermob-proxy);
Написание документации (тест-планы, тест-кейсы, чек-листы и пр.);
Ну и всякие мелочи из разряда "деплоить ветку на тестовый стенд", "проверить наличие задач в ветке".
Вывод и скромный совет
Хотел бы обратиться к тебе, читатель. Если ты прочитал до этого места, то тебе в принципе интересно всё о тестировании, даже бредни джуна. Запомни одно - если чувствуешь, что это твоё - "не тормози сни..." не распыляйся и занимайся этим. Тестировщики - это ценные сотрудники, они отвечают за качество продукта, а следовательно экономят деньги заказчикам и делают конечных пользователей чуточку счастливее.
Задавай свои вопросы в комментарии и я с удовольствием отвечу на них.
P.S: Под понятием "тестировщик" я объединил и, непосредственно тестировщиков, и QA, и QC, не будите занудство и не проявляйте проф. деформации :) peace.
Один день из жизни мануального тестировщика
Тестирование -- отличный способ "войти в айти". Но мало из посетителей курсов "научись QA за две недели!" понимает, из чего состоит рабочий процесс тестировщика. Ну, ябрассказал)
На самом деле такие посетители могут не обольщаться -- работа мануального тестировщика довольно монотонна. Если вы думаете, что в игровой индустрии на позиции QA сидят счастливые люди и просто весь день играются в игрушки -- то вы немного лукавите. Потому что большая часть работы QA -- это документация. Но давайте сначала составим план работы(упрощённо. и кстати -- это лишь моё видение, другие QA могут смело меня поправлять(нет))
1)Исследуем спецификацию проекта
2)проверяем её на возможные баги на этапе составления
3)составляем тест-план
4)(если вы главный) распределяете роли в QA-команде.
5)Составляете тестовую документацию(чек-листы и тест-кейсы)
Заметьте, мы пока даже не видим продукт! вся документация составляется НЕ на основе готового продукта, это суровая ошибка! документация составляется на основе другой документации -- потому что в готовом продукте могут быть баги, которые не баги))
6)И вот тут начинается собственно тестирование.
А теперь давайте к заголовку поста. Я расскажу о моём рабочем дне, не по пунктам, а довольно сумбурно, потому что каждый день уникален в своей монотонно-драйвовой гамме.
Перво-наперво я приезжаю на работу, завариваю чашечку вкусного эспрессо, сажусь в кресло Herman-Miller.... Нет) скорее я в пене и мыле прибегаю на работу и отхватываю чашечку вкусных пиз*лин, потому что(такое бывает, но на новой моей работе пока не было со мной) production incident. Соответственно вокруг сплошное поле боя, крики, мат...
На самом деле жизнь любого человека, причастного к созданию ПО, подчинена интервалам под названием Спринт(об Agile системах поговорим позже).
Соответственно, есть дни, когда кодеры усиленно пилят версию, а вы занимаетесь актуализацией доков и параллельно регрессией. Это довольно обыденные дни, команда пишет доки, ходит за кофе, болтает про новинки автопрома и политическую ситуацию.... Короче, рутина. Но есть и светлые дни, есть дни, когда кодеры отдали вам версию на проверку, и вы начинаете Фича-тестинг и регресс-тестинг(проверка уже проверенной функциональности, на которую могли повлиять какие-то действия кодеров).Ну и квинтэссенция всей работы -- есть дни, когда версия идёт в продакшен. Это второй по напряжённости день во всём рабочем процессе. тут вы начинаете всей командой фигачить фулл-тесты, регрессии, проверять перфоманс.... короче суровая напряжённая работа. Но если это второй, то первый? Первый это страх и ужос всея QA отдела. вот зашёл как-то PM на продакшен сервер, начал кликать.... и увидел ЭТО. Как на него из-под кнопочки вылез миленький маленький блокер, и это жопа. Это красная жопа у всего QA отдела. потому что баги на продакшене -- это капец. И вот тут начинается операция "быстро выпусти хотфикс пока не прибежал владелец продукта и не вкатил люлей"
Немного сумбурно, писал в перерыве рабочего процесса. Да и чукча не писатель, чукча манки-тестер)))
Есть вопросы или претензии -- прошу пройти в комментарии)