Testing is a skill

Пост написан по итогам вчерашней  встречи минских тестировщиков  на тему введения новых людей в проект. Встреча проходила в уже знакомом мне Инкубаторе БГУИР (спасибо организаторам!). Очень удачно был выбран формат круглого стола, это позволяет добавить больше интерактива в подобных встречах. Единственные минус для меня с коллегой - мы опоздали из-за работы до 19.00 и поэтому сели достаточно далеко от экспертов. Кстати, об экспертах - это Александр Барановский из EPAM Systems и Виталий Воробьев из Life:). Ребята молодцы, их опыт очень ценен и интересен. Здорово, что они согласились с нами им поделиться. А теперь о результатах встречи. Как следить за выполнением задач? Как оценивать результаты работы новеньких? Следить за выполнением задач можно с помощью отчетов - ежедневных или даже ежечасовых. Мы выделили 3 техники для выполнения наблюдения за тестированием нового участника команды: Парное тестирование. Когда новенький человек что-то делает, а рядом сидит опытный коллега и помога

В deadline мы вложились. Красиво очень. Т.к. закончить должны были до пятницы, а закончили в середине среды. Были приятные слова от бизнес-пользователей и манагеров. Ради этого стоило прикладывать столько усилий. Четверг мы потратили на ретест занесенных и пофиксенных багов, а так же апдейт наших тест-кейсов. В пятницу было просто дико непривычно работать в расслабленном ритме. Что можно отметить из второй недели Business process testing. Бизнес-пользователям уже надоело наше тестирование. Общаться с ними стало труднее, поэтому пришлось быть еще вежливее, чем на первой неделе. Кроме того, моих ребят после первой недели BPT перевели на другой проект, поэтому все оставшееся время мне пришлось справляться самостоятельно, иногда лишь дергая их вопросами по той части, которую они делали, а я не знаю. В остальном же моя работа заключалась все в тех же действиях. Но после такого утомительного написания тест-кейсов, это был долгожданный увлекательный экшн.

На данный момент я занимаюсь Business Process Testing'ом. Изначально мы долго и мучительно писали End-to-end test cases с кучей ролей и систем, чтоб полностью покрыть измененный процесс. Неделю назад пришло время начать само тестирование. Я внезапно оказалась Main contact person для региона EMEA - Europe, the Middle East and Africa. Сказать, что было страшно начинать - ничего не сказать. Мне боязно общаться с требовательными business users, тем более, что я вообще не понимала, что я должна делать на саппорте и как этот процесс выглядит. Но, как известно, глаза боятся, а руки делают. У меня было 2 test cases, которые я сама лично писала. + я еще немного помогала тем, кто саппортил ASIA region, но совсем немного.  Что же я должна была делать? 1. Работать семафором. Когда ты видишь, что чувак с одной ролью закончил выполненияе своих steps, ты должна достучаться до следующего и сообщить, чтоб он начинал. Потом нужно следить, чтоб нужный человек открыл свой скрипт и никто не залочил

Иногда мне приходят предложения от эйчаров в профессиональных соц. сетях. Т.к. на данный момент я не нахожусь в поиске работы, обычно я просто вежливо отвечаю, что на данный момент эта вакансия меня не интересует. И еще не определилась, что же делать с эйчарами, которые просятся во френды. Вроде сейчас мне они не нужны, но кто знает, чем обернется знакомство дальше? Но не это сподвигло меня написать этот пост. Сегодня мне пришло очередное предложение. В этот раз на вакансию QA Test Engineer. Может быть, я еще не совсем разобралась с разницей между QA и Test Engineer, но объединение двух позиций в одну вызвало непонимание, кого же ищет эта компания? Ознакомившись с описанием, стало очевидно - точно не QA :) К тому, что в большинстве компаний тестировщиков называют QA, я уже как-то привыкла, но вот такое смешение пока выглядит для меня диковато.

Сегодня прошел 3ий день, как мне дали команду из 4х человек - 3 девочки и 1 мальчик. Ребята прошли до меня тренинги по основам тестирования, коммуникациям, учились писать реквайроменты и тест кейсы. И вот мне выпала честь вводить их в проект. Набиваю свои первые шишки, ибо раньше новичков не тренила и не знаю, как организовать процесс грамотно и эффективно. В первый день было договорено, что я просто расскажу ребятам процесс, не сильно углубляясь в системы, чтоб немного растрясти кашу в их головах и не запутать их еще больше. Дальше от высшего руководства через меня к ребятам поступил список документации, которую им необходимо было освоить. И доступ в тестовый энвайромент, где им можно было только смотреть. К концу первого дня стало понятно, что это не очень весело и не сильно эффективно. На второй день ребятам разрешили потыкаться в энвайроменте. А сегодня мы лазили по HP Quality Center'у.  Но все же я допустила ошибки. Да, сейчас я очень занята со своими тасками, но процесс об

С момента написания первой части отчета, появились некоторые дополнительные материалы. Я решила не редактировать предыдущий пост, а вынести в отдельный. На первой части встречи, в процессе обсуждения методик тайм-менеджмента, Антон Столяр рассказал про один интересный алгоритм. На его рисунке это выглядело забавно, но на форуме он мне дал ссылку на более упорядоченный вариант. Итак, диаграмма рабочего процесса: Следуя этой схеме, мы можем рассортировать ежедневные задачи, которые поступают к нам для решения и оптимизировать свое рабочее время. Кстати, в комментах к предыдущему посту   Сергей Атрощенков дал ссылку на такую же диаграмму, только в более подробном и оформленном варианте - тыц . Спасибо ему за это. Далее, я упоминала в первой части отчета про составление характеристики идеального тестировщика в вакууме. Нам остались на память такие фото: На данный момент я их только примерила на себя (особенно интересны были личные качества, некоторых мне явно не хватает) :), а вот до

Вчера состоялась третья официальная встреча минского сообщества тестировщиков ПО. На обсуждение были заявлены 2 темы - "Тайм-менеджмент" с презентацией от Виктории Бутич (за что ей большое спасибо :)) и "Методы оценки работы QA", проведенная в формате круглого стола. Встреча проходила в конференц-руме, любезно предоставленном нам компанией EPAM Systems.

Чем больше работаю в тестировании, тем требовательнее становлюсь к качеству интернет-сайтов. Последние пару недель я периодически мониторю сайт белжд (www.rw.by), чтобы контролировать наличие свободных билетов на поезд на определенную дату. Каково же было сегодня мое удивление, когда, зайдя на сайт, я не увидела привычный интерфейс! Раньше информация о расписании находилась в разделе "Пассажирские перевозки". Поэтому я, естесственно, зашла туда. Открылся дропдаун со значениями, но ни один из них не подразумевал наличие необходимой мне информации. Но я зашла в каждый раздел, мало ли :) не нашла. Потом я просмотрела все менюшки сайта. Нет информации. Потом я заметила поиск и собралась им воспользоваться, но ВНЕЗАПНО глаз наткнулся на то, что мне было нужно. Это был баннер слева вверху. Зачем важную информацию размещать на баннере - непонятно. Тем более, что многие ставят плагины к браузерам, чтобы не смотреть рекламу. P.S. а поиск я все-таки проверила. Чтобы уменьшить колич

На работе готовимся к предстоящему релизу и изучаем те Change Requests, которые будут внедрены. В связи с этим читаю много всяких переписок. И вот покажу на примере, что сегодня улыбнуло (цвет имеет значение, так было в письме, суть разговора не сильно важна): Пишет Damian, в своем письме приводит кусок разговора: SP: уточняет какой-то момент, правильно ли понимает DR:   подтверждает, говорит то же самое своими словами Следующее письмо от Sotha:  Дэмиан, уточни, пожалуйста, написанное красным  Ответ Damiana: Читай то, что написано синим  Письмо Sotha: ок, спасибо за помощь. Ну и дальше скучная переписка ))) P.S. в последнем сообщении нет иронии, там видно было из дальнейшей переписки

В рабочие часы все мы составляем тест кейсы, выполняем их, заносим баги и т.п. Но вот work-day закончен. А останавливается ли на этом наше поведение, как тестировщиков, до следующего рабочего дня? Когда приобретаем новую вещь, что мы делаем? лезем в инструкцию или тыкаем в кнопочки посмотреть, что будет? По дороге домой не высматриваем ли какие-то мелкие детали? А самое интересное, когда вы дома смотрите какие-то свои сайты в интернете и вдруг находите баг - ваши действия? Лично я - честно отправляла несколько раз баг-репорты :)  А если собеседник опечатывается - говорим об ошибке или терпеливо закрываем глаза? Наверное, нельзя быть тестировщиком на работе и не-тестировщиком в свободное время. Работа влияет на нас и наше поведение. Я стала внимательнее, стала задавать более правильные и корректные вопросы в разговорах. Стала объяснять гораздо лучше какую-то информацию другим. И терпеливее относитьсяк тому, когда кто-то исправляет мои ошибки :)

Еще на тренингах, когда я только пришла в компанию и совсем мало знала о тестировании, мне в голову заложили одну хорошую вещь: писать в описании проблемы "ничего не работает" - недопустимо. Сегодня одна девушка, под начальством которой я долгое время работала, попросила помочь ей проретестить один дефект. И она мне переслала письмо, в котором описывалась проблема. Там было несколько строчек и скриншоты. Я прочитала один раз, второй, третий - и все равно не поняла, что же не так! Проблема в том, что есть система и в ней генерится отчет, откуда подтягиваются данные из системы. И ошибка в том, что цифры в отчете и системе - разные. Но это на словах из письма, на деле - одинаковые (под делом я подразумеваю скриншот и приаттаченный отчет из письма). Я сделала те же шаги в тестовом энвайроменте - одинаковые цифры. Отписалась девушке, что непонятно же совсем, что не так. После чего узнала, что они уже провели консилиум из 3х тестировщиков, пришли к тому же выводу "непонятноч

Если мы работаем не в компании одного проекта, то вполне возможное явление - переход/перевод с одного проекта на другой. Так же некоторые проекты имеют свойство заканчиваться, и переход становится неизбежен. Но в данном посте речь будет не об этом. В последние пару недель я столкнулась с ситуацией, когда человека, с которым я вот уже 8 месяцев отработала бок о бок на одном стриме, переводят на другой проект. А я остаюсь. Я никогда не была на другом проекте, только на разных стримах внутри одного. Для меня разные стримы - это гуд, потому что я "пощупала" продукт с разных сторон. А разные проекты? Есть несколько мыслей, я решила их разбить на плюсы и минусы, ведь у каждой медали - 2 стороны. Итак, "за" переход: развитие новых навыков. Ведь на других проектах могут быть новые тулы, по-другому построены процессы, да даже репорты пишутся по-другому :) если на первом проекте вы достигли "потолка", то новый проект как нельзя кстати смена команды (тут можно и

Можно было сразу броситься в бой и начать описывать проблемы, уже полученные знания и просто размышления, но я решила для начала представиться. Меня зовут Лена. Чуть больше года я работаю в компании Allied Testing. Это мое первое место работы в качестве тестировщика. Пока я попробовала себя только в ручном функциональном тестировании, но в планах хочется гораздо большего. Однажды я прочитала статью Натальи Руколь -  Как развиваться начинающему тестировщику . Некоторые пункты уже были в статусе Passed, некоторые я тут же осуществила. И только по одному меня одолевали сомнения - создать свой блог. Казалось бы, ну чем я могу поделиться, когда у самой опыта совсем чуть-чуть? Но время шло, обсуждения на форумах и статьи в рассылках давали пищу для размышлений. Потом я стала одним из членов сообщества минских тестировщиков -  BelQA . Побывала на двух встречах, вопросы снова стали накапливаться, и как-то пришла к тому, что уже недостаточно это обсуждать с коллегами в кабинете. Захотелось ст