суббота, 9 апреля 2016 г.

Передача знаний

Всем привет!

Совсем недавно на работе у меня происходил процесс передачи знаний по проекту новым тестировщикам. По итогам хочется поделиться небольшим планом того, какую информацию можно передавать.

1. Список используемых систем и доступ к ним - система управления проектами, тест-менеджмент система, вики, система непрерывной интеграции и другие.
2. Описание используемой документации - преимущественно познакомиться с принципами ведения ТЗ и его форматом (например, ТЗ ведется в виде user story, сценариев использования и др)
3. Описание приложения и особенности его тестирования
- Информация по структуре приложения, взаимодействии его с другими системами и т.д. Вся информация, необходимая для того, чтобы человек получил общее представление о приложении. Это могут быть какие-то схемы, презентации.
- Более подробное описание ключевых частей приложения. Тут лучше составить список основных функциональных блоков приложения в порядке важности и провести демонстрацию работы с этими блоками. 
- Техническое задание
- Особенности тестирвания каждого блока функциональности - на что обращать внимание при тестировании
4. Описание процесса разработки - на словах или в виде регламента.
5. Описание процесса тестирования
Здесь можно предоставить описание процесса тестирования в виде какого-то регламента или на схемах, описать регламент работы с системой управления проектами в части тестирования (какие задачи создаются для каких активностей по тестированию, что описывается в рамках задач, какие комментарии добавлются в процессе выполнения задач и т.д.)
6. Описание работы с требованиями - участвует ли тестировщик в анализе и тестировании требований и каким образом.
7. Описание проектирования системы тестов - здесь можно предоставить шаблоны тест-кейсов/чек-листов, описание регламента работы с тест-менеджмент системой или работы при ее отсутствии, правила описания тест-кейсов, перечень дополнительных активностей - проводится ли ревью чек-листов, составляются ли рекомендации по тест-дизайну и т.д.
8. Описание процесса выполнения тестирования - можно рассказать про оценку времени на выполнение тестирования, процесс совместного выполнения тестирования в тест-менеджмент системе или при ее отсутствии, критерии завершения тестирования фич/релиза, описать процесс регрессионного тестирования.
9. Описание процесса работы с дефектами - предоставить регламент работы с дефектами в баг-трекинг системе (переход по состояниям и ответственным), шаблон оформления дефекта, правила установки важности/приоритета, правила прикладывания дополнительных файлов, логов, рекомендации по организации работы с дефектами в баг-трекинг системе (например, использование фильтров)
10. Описание составления отчетности о тестировании - какие метрики собираются по итогам тестирования, формат отчета, правила заполнения отчета, критерии определения качества тестируемой версии и т.д.
11. Выпуск релиза - необходимо описать, какие активности выполняются после выпуска релиза в продакшн. Это может быть регламент взаимодействия с командой сопровождения, анализ пропущенных в продакшн дефектов и выводы на основе анализа, обновление набора тест-кейсов для регрессионного тестирования и т.д.
12. Выпуск ХФ, патчей - какие активности по тестированию проводятся.
13Список используемых инструментов - браузеры, их расширения, клиенты бд, текстовые редакторы и другие.
14. Общая информация - работа с тестовыми стендами, с системой непрерывной интеграции, список тестовых данных и т.д.
15. Автоматизация тестирования - если она есть, описать процесс автоматизации тестирования на всех уровнях на проекте.

Если вы являетесь тестировщиком на проекте и эта информация нигде не зафиксирована, лучше постепенно это делать. Хотя бы для того, чтобы легче было вводить новых людей в работу.

Всем пока!

P.S. Если будут дополнительные рекомендации, можно указывать в комментариях. С радостью обновлю данный список.

воскресенье, 13 марта 2016 г.

Ростовское IT-сообщество. QA Meetup 12.03.2016

Всем привет!

В городе Ростове-на-Дону, где я живу, существует IT-сообщество. Оно активно развивается, все больше людей к нему присоединяются. Сообщество постоянно проводит митапы по различным направлениям разработки и тестирования. Организуются митапы по следующему принципу - любой специалист заявляет о желании выступить с какой-нибудь темой, затем подбираются еще 3 докладчика (также по желанию) и организуется мероприятие.  В субботу, 12 марта 2016 года, состоялся очередной митап по тестированию. Предыдущий митап проходил год назад. Не очень часто :) Но сейчас ребята поставили по куратору для каждого направления и планируют проводить такие встречи гораздо чаще. Ребята молодцы, спасибо вам!
QA митап состоял из двух частей. В каждой части было по 2 доклада длительностью 20 минут + вопросы. В перерыве - общение и пончики с кофе/чаем.



Лично я очень рада, что у нас в городе проходят такие встречи тестировщиков и у ребят есть желание делиться своими знаниями и опытом. Я была на всех трех прошедших митапах, атмосфера очень доброжелательная. Ниже опишу свое мнение о докладах.


1) “Автоматизированное тестирование UI в мобильных OC”
Даниил Кивенко, QA engineer в Growapp Solutions

Надоело каждодневное ручное тестирование UI элементов приложений? Я расскажу вам про полный цикл автоматизированного тестирования приложений!

Даниил в своем выступлении попытался использовать Фикус - инструмент для интерактивных презентаций. Задумка хорошая. Жаль, не удалась. Во-первых, как я поняла, были проблемы с сервисом. А во-вторых, докладчик предоставил очень мало времени для подключения к презентации слушателям. Про этот инструмент знают далеко не все. И мне кажется, практически никто не понял, чего хотел от них докладчик, за что и как голосовать. В следующий раз лучше до начала конференции предлагать аудитории подключаться к презентации, чтобы в реальном времени можно было голосовать или оставлять комментарии.
В докладе речь шла про фреймворк Appium для автоматизации UI мобильных приложений. Все, что я поняла из доклада - что этот фреймворк выигрывает перед другими. Те, кто никогда не занимался автоматизацией, думаю дополнительно поняли, что такие фреймворки позволяют работать с контролами приложения без участия человека. Никакого руководства про то, как сесть и с нуля работать с этим инструментом, не было. Рассказа про полный цикл автоматизированного тестирования приложений я тоже не услышала. Мне в этом докладе не хватило систематизированного представления информации.
*Примечание: тестировщиков из моей компании, которые автоматизацией не занимались - инструмент заинтересовал.

2) “Scrum глазами тестировщика или как создать стратегию для любой задачи”
Елена Кузнецова, QA engineer в VIAcode
Как я попала в scrum-команду и это изменило мое представление о тестировании и разработке программного обеспечения. Я расскажу как заменить чек-листы стратегиями, что диаграммы связей - это не страшно, почему общаться с клиентом каждый день - здорово, а четкие требования не сделают продукт лучше.

Большую часть времени Елена рассказывала про скрам. Хотелось, конечно, больше услышать именно про стратегии тестирования (насколько я поняла, так называют mind карты) - какие инструменты используются для их создания, по каким правилам они пишутся, каким образом по ним осуществляется тестирование, как отмечаются результаты тестирования, как они анализируются, в какой момент все-таки пишутся тест-кейсы и т.д.. В чем  преимущество стратегий перед чек-листами, тест-кейсами - непонятно. Как начать использовать стратегии в работе - думаю, новичку тоже не совсем понятно. Те, кто раньше не слышал про скрам и по нему не работал - что-то новое узнали, да. 
Для информации, был несколько лет назад хороший доклад про Mind Map от Татьяны Зинченко на онлай-конференции по тестированию ConfetQA.

3) “BDD подход в автоматизации UI тестов”
Перов Алексей, Test Automation Developer в DonRiver
Расскажу о использовании BDD подхода в автоматизации тестирования. Какие инструменты мы для этого используем, и почему данный подход помогает улучшить процесс написания тестов.

Доклад Алексея мне понравился. В докладе был представлен краткий обзор инструмента Cucumber для написания автотестов на языке бизнес-логики - в BDD стиле. Я несколько лет назад на той же  ConfetQA выступала с похожим докладом, только про инструмент SpecFlow (для автотестов на C#). Выступление было хорошо построено, объяснены основы. А дальше - читайте документацию и вперед :) После доклада коллеги-тестировщики с моей работы захотели изучить этот инструмент. Значит, усилия докладчика не прошли даром.

4) "Организация процесса ручного тестирования"
Поплоухина Елена, Руководитель отдела тестирования в Usetech Integration
Расскажу об опыте организации процесса внутреннего тестирования проекта со строго формализованным техническим заданием от момента получения технического задания для тестирования требований до момента передачи релиза на приемочное тестирование.

Последней на митапе выступала я :) Рассказывала про этапы процесса ручного тестирования на проекте. Оценивать себя не буду. Поскольку мой блог, вставлю свою фоточку.


Итог могу подвести следующий. Я рада, что у нас проводятся такие митапы. По организации вопросов нет, все на уровне. Чтобы уровень докладов был выше, нужно приглашать какого-то рецензента. Но, с другой стороны, это все-таки не конференция, а митап.

Всем пока!

суббота, 30 января 2016 г.

Опыт использования тест-менеджмент системы Ситечко

Всем привет!

Прошел примерно год, как мы внедрили в нашей компании тест-менеджмент систему Ситечко. И я хочу поделиться опытом ее использования. Рассказать, почему при выборе системы мы остановились именно на ней, с какими плюсами и минусами столкнулись, как используем систему для осуществления процесса тестирования проектов. Я не ставлю целью раскрыть перед читателем все возможности системы, а только рассказать о нашем опыте работы с ней.

Почему Ситечко


пятница, 4 декабря 2015 г.

Юмор. Тестирование новой функциональности

Всем привет!

Пока я пишу статью об опыте использования тест-менеджмент системы "Ситечко", покажу вам несколько ассоциаций, которые возникают у нас с тестировщиками при словах "тестирование новой функциональности".

В главных ролях:
Белочка - тестировщик
Орешек - баг
Ледниковый период - Проект "Х"

Когда тест-кейсы написаны и ты ждешь, когда можно приступить к тестированию.



Когда можно тестировать и ты быстро посмотрел новую функциональность.



Когда ты завел первый баг по новой функциональности.


Когда первая итерация тестирования новой функциональности завершена.


P.S. За идею спасибо моей сестренке-тестировщику Ане Фалилеевой.
P.S.S. Отредактировано. "Функционал" заменен на "функциональность".

четверг, 5 ноября 2015 г.

Другой взгляд на Severity

Всем привет!

Вчера мы с друзьями ждали мою сестренку с работы из-за того, что она заводила последний баг. А если друзья не сильно знакомы с миром IT, могут возникнуть разные ассоциации со словом "bug".

Мы думали, как назвать бага, если ты "заведешь баг" у себя дома =) Мы учли, что баги бывают разные.

Таким образом, получилась следующая классификация в зависимости от severity бага:

trivial    -  Степашечка
minor    -  Степашка
major    -  Степа
critical  -  Степан
blocker -  Степан Петрович



Всем пятницы! =))

четверг, 29 октября 2015 г.

Инструменты для просмотра веб-страниц при разных разрешениях экрана

Всем привет!

Решила я стряхнуть пыль со своего блога :).
Для начала, я его переименовала. За прошедшие 2 года я переквалифицировалась из автоматизатора в ручного тестировщика (и немного тест-менеджера). Обычно, конечно, случается наоборот. НО - у каждого свой путь. Главное, любить свою работу!

За эти 2 года у меня поднакопилось немного разных статей, которые я писала преимущественно для себя и тестерят со своей работы. Почему бы не поделиться ими? Заодно, сохраню для себя :) Не забывайте, главное для человека - это его "думалка" и то, как он может распорядиться имеющейся у него информацией.

Пусть эта заметка будет первой после перерыва. 

Начну с перечня инструментов для просмотра ваших веб-приложений/веб-сайтов при разных разрешениях экрана. По опыту могу сказать, что при помощи них ловятся не все баги верстки. Но большинство. 
  • Firefox — Firesizer, (начиная с 16-ой версии «Инструменты» → «Веб-разработка» → «Адаптивный дизайн»)
  • Google ChromeWindows Resizer
  • Safari — ResizeMe
  • Internet Explorer — Microsoft Internet Explorer Developer Toolbar (встроен в браузер, начиная с версии 8)
Если кто-то хочет дополнить список или поделиться своим опытом, welcome.