Как начать работать тестировщиком

 

Так получилось, что этот блог я уже почти забросил. Отчасти, потому что, все то, про что хотел бы написать уже написано в интернете и книгах. Отчасти потому, что медленно, но верно начинаю мигрировать в другие области управления - например применение практического психоанализа в бизнесе (о чем даже завел свой телеграмм канал "Бессознательное в организации")

Но я все еще связан с тестированием, и даже помогаю как ментор на менторов GetMentor. В связи с тем, что увеличился поток новичков в ИТ (а значит и в профессии инженеров в тестировании) я создал небольшую страницу, которой делюсь с теми, кто ко мне постучался.  Думаю, имеет смысл перенести текст этой страницы сюда. 

Далее мои ответы на частые вопросы о том, как же ворваться в профессию тестировщика, и не очень сильно ушибиться.

Что сначала?

Ответить на вопрос - зачем это вообще тебе надо :)

Сначала надо понять - почему это “интересно”, потому что с мотивацией учиться и работать гораздо легче. Ответ "это просто из-за денег" чреват последствиями. Работа предстоит напряженная, легко не будет. Мотивация кроме материальной может очень сильно помочь.

Каким тестировщиком хочешь стать?

Это следующий вопрос. Надо определиться в какую область хочется пойти. 

В зависимости от ответа будет понятно какой стек технологий надо будет прокачивать. Я бы выделил несколько основных направлений:

1. Ручной тестировщик графического интерфейса (еще можно выделить web, мобайл, десктоп)
2. Тестировщик геймдева
3. Тестировщик бэкенда
4. Автоматизатор

Я больше про enterprise и сталкивался со всем кроме мобайла и геймдева. Мой опыт говорит мне, что нужно сфокусироваться на чем-то одном, прокачаться, и только потом изучать остальное. Сначала фокус и глубина - потом широта экспертизы.

Начинать легче с ручного тестировщика графического интерфейса. Поэтому рекомендации с некоторыми оговорками будут про эту профессию. Остальные не то чтобы сложные - просто требуют дополнительных навыков и соответственно - времени

С какими интернет ресурсами можно или нужно познакомиться?

• https://www.software-testing.ru/ - самый известный, наверное, портал про тестирование в русскоязычной аудитории
• Конференция SQA Days - можно подчерпнуть много интересного материала с выступлений https://sqadays.com/ru/index
• Где изучать тестирование (актуально на 2021) https://proglib.io/p/gde-izuchat-testirovanie-v-2021-godu-17-resursov-dlya-nachinayushchih-inzhenerov-po-qa-2021-06-07
• Список телеграмм каналов сообщества тестировщиков и близких к ним:
• Большой чат: https://t.me/qa_ru
• Резюме: https://t.me/qa_resumes
• Финансы: https://t.me/qa_fin
• Слухи и отзывы о компании: https://t.me/qa_bad_company
• Флуд: https://t.me/qaflood 

Как подготовиться к интервью? Что спросят? 

Есть несколько заметок про вопросы на собеседованиях:

• https://seljava.blogspot.com/2009/08/sqa.html
• https://habr.com/ru/post/254209/

Что почитать?

Все упоминают Савкина. Как первая книга это нормально. Но потом нужны другие материалы. Делюсь теми книгами и статьями, которые считаю важными: Все книги доступны тут: https://cloud.mail.ru/public/w9Nd/wXtKbAhfM

В какой последовательности читать? Я бы предложил так (от простейшего к более глубокому):

• Тестирование Дот Ком: https://cloud.mail.ru/public/9S45/9vViAzJbW
• Software testing - base course (svyatoslav_kulikov): https://cloud.mail.ru/public/RVUn/VCm2DCFsz
• A Practitioners Guide To Software Test Design https://cloud.mail.ru/public/ChJp/qBz3w3WGa (это самая важная для вас книга, но к ней переходить нужно после того как поймете про то что такое тестирование)
• Тестирование ПО Кем Канер (можно пропустить если прочитали 2 верхние, но книга оч старая и очень первая, и ее название хотя бы знать неплохо) https://cloud.mail.ru/public/kivU/72DsL8MsV
• Software Testing Foundations ~ A Study Guide for the Certified Tester Exam 2nd Edition https://cloud.mail.ru/public/akFr/r3SkVQkbi (поможет закрепить терминологию)
• Agile testing. A practical guide: https://cloud.mail.ru/public/dYta/DuWGWfY6p
• Metrics And Models In Software Quality Engineering https://cloud.mail.ru/public/8H7i/gYa3gCVLG
• Lessons_Learned_in_Software_Testing: https://cloud.mail.ru/public/2uny/1tb2rbWjM

Потом можно почитать и статейки: https://cloud.mail.ru/public/7KYk/sB6QVeoAU

А потом окунуться в океан информации и найти что-то полезное для себя (материал на английском, сори): https://www.lisihocke.com/p/testing-and-quality.html

Где найти помощь?

Я бы посоветовал еще найти ментора в области, в которой вы хотите развиваться.

Где найти? Есть несколько мест, например https://getmentor.dev/. В этой социальной сети можно найти даже бесплатного на несколько встреч человека, который вам поможет сделать несколько первых шагов.

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

Несколько историй, как ребята заходили в тестирование и зашли:

• https://teletype.in/@skaynet1996/nY6dYVp170g
• https://habr.com/ru/company/plarium/blog/561454/
• https://rb.ru/opinion/testirovschik-po/
• https://mymonday.by/from-pizza-courier-to-qa-specialist
• https://teletype.in/@skaynet1996/qKYB_vK3oWU

Как зайти в компанию:

• Через стажировку: https://habr.com/ru/company/netologyru/blog/674336/ 

Как ищут и нанимают тестировщиков (посмотреть на вас со стороны работодателя):

• https://software-testing.ru/library/around-testing/management/3804-how-to-hire-a-software-tester
• https://journal.tinkoff.ru/list/qa-trainings/

Где потренироваться тестированию:

• https://askerweb.by/sajty-s-bagami-dlya-testirovaniya/

Что еще посоветую:

• Практика - постоянно ищите что и как протестировать. Сайты, приложения на компьютере и в телефоне.
• Советы бывалых - слушайте и спрашивайте тех, кто в этой области уже больше чем вы.
• Постоянные собеседования и сбор обратной связи - вам нужно отталкиваться от того, чего вы не знаете и нужно понимать, что еще вы не умеете и должны изучить.
• Заводите знакомых в областях, в которых хотите развиваться. Через знакомых ГОРАЗДО легче найти ХОРОШУЮ работу. 
• Теплый чай и поддержка близких. И котики, лисички или песики - питомцы очень помогают )).

И главное - не бойтесь учиться и ошибаться. Просто получайте от процесса удовольствие!

Удачи вам в новом интересном пути!

Чтобы помнили: 5 веховых книг по тестированию

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

Если ошибки, события и люди - достаточно уникальны и ситуационны, то что касается книг - этим добром как раз можно делиться.

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

Немного с опозданием, для 9 Сентября - Священного Дня Первого Жука предлагаю свой список "особенных" книг.

Чтобы помнили.

Образы и концепты практикующего тест менеджера

Одна картинка заменяет 1024 слова

Я часто мыслю образами. Картинками. Концептами.  Во время разговора обычно черчу на листочке схемы, картинки, которые, потом использую как отчет о беседе. Иногда люди с которыми беседую эти листочки забирают - наверное все таки полезное что-то черчу.

Инфографика меня таки просто завораживает.

А еще бывает, проходя мимо коллег и видя там таблицы с данными, с трудом сдерживаюсь чтобы не нагнуться и не спросить а-чо-тут-такое-интересное-нарисовано-и-как-это-у-вас-получилось?...

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

Тема заметки - красивые картинки. Просто образы, картинки, концепты... Они таки иногда приносят "вкусные" идеи. 

Хочется просто поделиться, и в очередной раз заметить, что работа тестировщиков не только тестировать, но и анализировать, и - упрощать, и - презентовать.

Если работа тестировщика некрасивая - она неправильная.

Tester Bill of Rights

Какая замечательная вещь этот биль о правах тестировщиков...

• You have the right to bring up issues related to testing, quality, and process at any time.
• You have the right to ask questions of customers, programmers, and other team members and receive timely answers.
• You have the right to ask for and receive help from anyone on the project teams, including programmers, managers, and customers.
• You have the right to estimate testing tasks and have these included in story estimates.
• You have the right to the tools you need to perform testing tasks in a timely manner.
• You have the right to expect your entire team, not just yourself, to be responsible for quality and testing.

Agile Testing. A practical Guide for Testers and Agile Team. Lisa Crispin, Janet Gregory

Лайф хак: требования как теги

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

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

Новое Поколение T

Cын научился использовать тач пад, колесико на мышке, наводить курсор, кликать и раскрашивать героя на компьютере. Растет. Теперь, чтобы прогнать - требуется приложить максимум дипломатии, обещаний, авторитета и сладостей ))).

Новое поколение растет, и, конечно, я не настаиваю, что он тоже станет тестировщиком, иначе будет как в комиксе 

Оригинал


но все таки, знаете, надежда теплиться...

Смертные грехи тестировщика: темные стороны и самоэкзорцизм

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

Поскольку  "смертные грехи" это, как правило, следствие определенных событий, а не сознательная деятельность (предпочитаю считать, что люди совершают плохие поступки, просто потому, что это лучшее, что они видели), я также попытался в данной заметке подумать  и на тему - почему эти грешки прорываются в людях, и что с этим делать (извечный русский вопрос - хех).

Обед с Майклом Болтоном

Я оказался одним из 23 сотрудников нашей компании, которым посчастливилось посетить тренинг "Rapid Software Testing" Майкла Болтона . Если учесть, что Майкл посещает Россию третий раз в жизни, и в этот раз именно ради нашей компании, то можно понять, насколько мне повезло.

Очень живой, интересный тренинг. Единственная проблема была, что первый день занятий был в воскресенье. Я не могу советовать всем посетить его, ровно потому, что очевидно в следующий раз Майкл появиться в наших просторах не скоро. Но если появиться - сделайте все возможное (но разрешенное законодательством), чтобы там побывать.

Я бы хотел поделиться тем, что получил: идеями, результатами, задачами и позитивным настроем.

Wiki как информационный гарант безопасности

История одного Ф1.

Начну с небольшого жизненного случая.

В проекте разрабатывается функционал средней тяжести Ф1. Изначально приоритет был ниже плинтуса , ровно потому, что бизнес сказал: "Можно не торопиться". 

Вас, привлекли в середине первого цикла тестирования (тогда вы еще не знали, что он первый) и стали вторым тестировщиком. Первый цикл закончился тем, что фича Ф1 вернулась в доработку фиксить баги.

Между тестированием фичи Ф2 и Ф3 вы (поскольку первый тестировщик переключен на другие проекты) решаете, что у вас достаточно времени протестировать Ф1 еще раз (разработка рапортует об успешном исправлении ошибок). Этот цикл заканчивает нахождением регрессионных багов.

Для следующего цикла вы обучаете третьего тестировщика и менторите его. Опять регрессионные ошибки.

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

В середине последнего цикла к вам приходит менеджер и заявляет - приоритеты изменились, нужно закончить работу вчера. Выяснилось это только вчера вечером, а сейчас нужно дать ответ почему тестирование ведется так долго (с августа по октябрь) и почему мы никак не можем финализировать тест пак? 

У вас осталось 30 минут, чтобы написать письмо с ответом.

В идеальном мире вы конечно же держите руку на пульсе и каждую из Н-цать фич знаете, как свои пять пальцев. В идеальном мире вся документация и все письма и все общение заносится в Jira/Mantis/BugZilla/выбери свою систему. В идеальном мире менеджер общается с бизнесом не раз в месяц, а постоянно. В идеальном мире менеджер не делает вид, что ничего не понимает,  и решает организационные проблемы команды сам. В идеальном мире нет багов, а слово "тестировщик" нарицательное.

Но мы с вами здесь и сейчас. И у нас осталось 29 минут.

The software testing timeline

Наткнулся в сети на интересную ссылку The software testing timeline. а также The Software Testing Timeline

Часто встречал историю языков программирования, но по истории тестирования вижу впервые. И интересно и гордость просыпается за профессию.

Планирование и отслеживание тестирования для отдельно взятого небольшого проекта

Введение

Разные проекты имеют разные подходы, технологии и методы в оценке трудоемкости и планировании. В данной заметке я предложу подход, который выработался в ходе развития одного проекта.  Не случайно в заголовок добавлено "отдельно взятого" - любой проект имеет свою историю, свою методологию, свой опыт и свои ошибки. Каждый проект планирует по своему. Это не хорошо и не плохо - так есть. Другое дело, что некоторые советы могут быть полезны в других отдельных проектах, которые отличаются и количеством и качеством. И — некоторые советы могут быть вредны в других отдельных проектах, которые несколько похожи.

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

Чек лист процесса: Initiation - Planning - Execution - Finalization - Closure

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

У нас активно внедряется связка Kick off - Test Plan - Daily Report - Sign off - Lesson Learn, которую можно перевести на более абстрактные уровни: Инициация - Планирование - Выполнение - Окончание - Подведение итогов и анализ (Initiation - Planning - Execution - Finalization - Closure). Каждый из этапов имеет свои тонкости и на самом деле их слишком много, чтобы мне запомнить. Но помня, что чек листы облегчают мне жизнь, я создал небольшой список который вырос в достаточное развесистое большое дерево.

Небольшое замечание - предлагаю не столько пример, сколько идею.

Мексиканские мотивы: использование приоритетов при построении карты сценариев регрессионного тестирования

Недавно был соучастником спора тестировщиков - спорили о том, с каких сценариев нужно начинать регрессию. Это, кстати, один из краеугольных камней тестирования - как начинать и когда заканчивать тестирование. У каждого тестировщика с n-летним стажем найдется масса советов и достаточное количество достоверных жизненных ситуаций в подтверждение именно своей точки зрения (замечено, что страдают подобным подходом не только тестировщики). Я в свое время для себя уяснил одно: если мой опыт восстает против слов оппонента - значит может быть и так как говорю я, и так как говорит оппонент, и еще как-то другому.

В споре одни утверждали: нужно в первую очередь прогонять тесты, которые были больше затронуты изменениями. Правильное направление, утверждали они, нужно и обязательно обсуждать с разработчиками - ибо они есть корень всего зла.

Другие - предлагали прогонять сначала тесты, в которых были найдены баги в предыдущих релизах. Высока вероятность, что данные тесты снова будут успешны (успешным тестом мы считаем тот, который находит баг), замечали они.

Третьи рассказывали о профессиональном чутье тестировщика и опыте, ибо только опыт отличает тестировщика от Тестировщика...

Общее в профессии ученых и тестировщиков

О том как описывать баги, сказано уже очень много. О правилах поведения при встрече с багами на пальцах показал Cartoon Tester Andy Clover. О том, как баги искать, не менее убедительно расскажет любой человек, который их когда либо искал ;).

Моя следующая книга для метро "Дзен и искусство ухода за мотоциклом" заставила задуматься о формализации процесса поиска багов. Конечно же книга не о багах, как таковых, но меня тронуло то, что форма  решения задач у ученого и тестировщика в чем то схожа:

Об ученых:

(1) постановка проблемы, 

(2) гипотеза, касающаяся причины проблемы, 

(З) эксперименты, предназначенные для испытания каждой гипотезы, 

(4) предсказанные результаты экспериментов,

(5) наблюдаемые результаты экспериментов, 

(6) заключения из результатов экспериментов.

О тестировщиках:

Баг - по сути - это проблема.  

Мы выдвигаем гипотезы, о том как воспроизвести баг.

Как только мы сталкиваемся с неправильным поведением приложения, вполне очевидно мы должны его попытаться воспроизвести и найти кратчайший путь: мы ставим эксперименты. 

 Предсказанные результаты -> наблюдаемые результаты -> заключение в виде описанного бага в багтрекинг системе.

Оказывается любой тестировщик это ученый, поскольку: 

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

Занятная мысль: каждый день мы ставим научные эксперименты! - еще один камень на нашу чашу весов в выборе профессии ж).

Как бы я приготовил и протестировал омлет

Идея описать процесс приготовления и тестирования омлета у меня возникла по одной непростой причине.

Мне сейчас приходиться собеседовать людей в проект. Я не очень люблю это занятие. Приходиться тратить и без того "золотое" время. Приходится отказывать людям в трудоустройстве, и порой отказывать не потому что специалист плохой, а потому что сомнения закрались о том - как мы сработаемся. Непростой еще и потому, что к собеседованию нужно готовиться. Если я получаю резюме - то как минимум полчаса я потрачу на то, чтобы узнать как этот конкретный специалист "наследил" в интернете. ВКонтакте, Одноклассники, Линкедин и просто старый добрый Гугль.

Омлетная тема: как приготовить и протестировать амлет - это как раз один из тех вопросов, что я задаю на финальном этапе, называемых мной "странные вопросы".  

Основную массу тем для разговоров я беру из своего старого допросника. Также использую стандартные тесты своей компании, и в конце собеседования, задаю "глупые" задания-вопросы:

- Возможно ли сдвинуть гору Эверест. Если нет - то почему. Если да - то почему.

- Протестировать ручку.

- Подсчитать количество настройщиков роялей в мире.

- Прочая лабуда, и, в том числе, лабуда про омлет.

Поскольку я задаю это задание другим, соответственно я должен иметь четкое представление - как это задание решать. Это и есть основная причина, по которой я собирался написать заметку. Себе и тем, кто когда нибудь со мной встретиться )).

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

Почему?

Так почему же я так поступаю с людьми? Почему я такой монстр?! Что за проблемы с психикой у меня, что я отрываюсь на других? Кто мой психиатр???

На самом деле я очень белый и пушистый. Просто очень много читал в свое время литературы, в которой указывался именно этот способ проверки (один из способов!) соискателей.

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

Еще я ищу людей, которые читают и готовятся к собеседованию.  Если ты решил сменить место работы, пожалуйста, будь любезен, освежи свои познания. Прочитай модные книги. Пробегись глазами по блогам. Вспомни кто такой Джоэл Спольски. ТАМ ОБ ЭТОМ ПИШУТ. Если человек читает - это только в плюс. Я в месяц читаю уже не 5 технических книг, как раньше, но 1-2 книги точно. И специалист, которые не читает, если честно, меня настораживает.

ИТ специалист обязан читать. И обязан читать много.

А еще я делаю это, потому, что я люблю играть. Честно. Все кто меня знают, отличают это - я даже в резюме пишу, что обладаю поистине замечательным качеством хорошего специалиста - "чувством юмора". Можно конечно поспорить - есть ли у меня чувство юмора, и насколько оно хорошее. Но я считаю, что есть и поэтому предлагаю забавные вопросы, чтобы увидеть - способен ли человек улыбаться. Протестируй ручки, выключатели, свою любимую маму  - не выходя из дома. А лучше в компании друзей. Это забавно - проверено Селяевым ;).

Как задавать вопросы? 

Я не задаю вопросы подобные "омлетному" в начале собеседования.  

Любая смена работы, любое собеседование, любая беседа в которой тебя оценивают (экзамен например) - это стресс. Люди должны успокоиться!

К тому же перед заключительными этапом я уже на 80% уверен - подходит человек или нет. Во время беседы я шучу, улыбаюсь, задаю вопросы не только о работе, но и о жизни. Я стараюсь, чтобы человек расслабился. Почувствовал себя в своей тарелке. Так человек будет гораздо ообразительнее. И вот, в конце беседы, начинается последняя стадия. Вопросы на сообразительность и на смекалку. "Странные вопросы".

Подозреваю, что постановка вопроса - это то, над чем должен работать человек проводящий собеседование. Вопрос должен заранее подразумевать, что сейчас будут проверяться навыки и сообразительность, опыт в разработке ПО, опыт управления и участия в программных проектах. В моем случае я считаю вопрос должен был (я к сожалению совсем недавно понял это) должен звучать так:

Представьте, что в ваш ресторан поступил заказ приготовить омлет. Как бы вы, используя ваш опыт в разработке  (используя навыки управления программными проектами) и тестировании ПО приготовили и проверили бы омлет?

Главная обязанность того, кто проводит собеседование, поддерживать непринужденную беседу. Кивать. Улыбаться. Шутить. Ни в коем случае собеседуемый не должен чувствовать себя неуютно. Пусть лучше он подумает, что вы глупый и неадекватный, чем вы сломаете человеку желание искать работу дальше. Может быть и в другой компании.

Чего я жду?

Во первых я жду вопросов. 

Тестер должен задавать вопросы - это его прямая обязанность. Тестировщик не должен оставлять белых пятен на выпускаемом продукте. Белые пятна в продукте - это черные пятна на его репутации.

Вопрос звучал об абстрактном заказе омлета. Чтобы не получилось все как в известной картинке

я бы стал задавать вопросы:

1. Как приготовить? Рецептов амлетов до кукуя. Если у нас есть только один в меню, следует напомнить об этом клиенту. Если клиент хочет свой способ - спросить и уточнить у повара (обратная связь! - мы может случиться  и приготовить не сможем).
2. Количество порций (может статься, что клиентов несколько на один вид заказа - можно сэкономить время и приборы: сковорода, масло и т.п.)
3. Количество яиц (близко к вопросу 1)
4. Количество молока (близко к вопросу 1)
5. Соль, перец и другие с специи (близко к вопросу 1)
6. Другие ингредиенты (близко к вопросу 1)
7. На какое время рассчитывает клиент.
8. Уточнить сумму, на которую рассчитывает клиент...

Ну конечно же, если наш омлет коробочный продукт - нечего распинаться: пусть устанавливает в своем желудке то, что мы ему продадим по указанной в прайсе сумме.  :))) Но мы то с вами понимаем, что даже у коробочных продуктов услуги по сопровождению и лицензиям ох какие разные. Так что чтобы человек вместо омлета со спаржей

 

не получил гигантский омлет из книги рекордов Гиннеса

 

тестировщик должен задавать вопросы, даже если до него потрудился бизнес аналитик.

Во вторых я жду описание техпроцесса

Перевожу на язык тестировщика - я хочу детальный тест план.

Если у нас известны требования, то мы с вами можем обсудить технологический процесс приготовления продукта. Продукт у нас омлет. Что я хочу от описания техпроцесса:

- хочу услышать какие вещи нам понадобятся: ложки, поварежки, кастрюли, помещение, печка ...

- хочу услышать фразы "если": Если у нас n яиц, то мы берем сковородку номер 666. Если у нас стандартный заказ - сыпем на n яиц соли и перца в пропорции столько-то грамм на количество молока+яйца. Если у нас заказ не стандартный - то у нас есть таблица что-с-чем-можно-смешать-в-каких-пропорциях. Либо нам эту таблицу нужно создать.

- хочу услышать шаги: 1. берем глубокую тарелку достаточную для количества яиц и остальных ингредиентов (см. таблицу что-с-чем-можно-смешать-в-каких-пропорциях). 2. По определенному порядку смешиваем продукты. 3. Разогреваем сковородку..... - ну вы как будто никогда не читали рецептов ж).

- еще я хочу услышать, что человек будет делать после того, как приготовит омлет, а именно: уберет кухню, спросит у клиента вкусно ли (обратная связь!), сделает выводы - как можно улучшить тех процесс.

Если человек скажет, что неплохо весь этот процесс взять сфотографировать и задокументировать, то этому комраду я готов пожать руку, поскольку новички должны знать, что им предстоит делать в будущем. Об этом я уже упоминал в Newcomer Checklist.

Какие выводы я делаю?

Как я уже упомянул, к данному этапу "странных вопросов" я на 80% процентов уверен - позитивный фидбек я напишу об этом специалисте или нет. Но эти вопросы помогают мне определить зрелость специалиста. Дают возможность специалисту поднять свой рейтинг в моих (пусть не всегда объективных) глазах. Дают мне возможность понять - насколько человек понимает, что такое процесс производства продукта. Ну и конечно этот вопрос иногда стреляет. Один из собеседуемых ответил мне тремя предложениями:

1. Разбить яйца.
2. Приготовить.
3. Попробовать.

Очень информативно, не правда ли?

Заключение

Я бы хотел подвести итог текущей заметке и еще раз выделить свою мысль, касательно "неадекватных", "непонятных", "некорректных с точки зрения собеседования" вопросов:

1. Эти вопросы нужны, поскольку позволяют проверить насколько человек может абстрагироваться от знакомых ему вещей.
2. Эти вопросы нужны, поскольку позволяют проверить - готовиться ли человек к смене работы и читает ли человек околотестировочную литературу.
3. Эти вопросы нужны поскольку позволяют проверить зрелость человека (насколько детальными будут описания техпроцесса).

Несколько уточнений:
1. Я никогда не оценивают (и вам не советую этого делать) человека только по этим вопросам. Это только опция.
2. Человек не должен испытывать неудобство во время собеседования, иначе эти вопросы просто его добьют. Итог будет неутешителен и для вас и для собеседника.
3. Вопрос должен подразумевать, что специалист должен использовать свои знания в разработке программных продуктов.

И еще - я никогда не стал бы готовить омлет, так как описал в заметке. Потому что это бред ;).  Приготовление омлета для меня и моей семьи не требует техпроцесса, опроса клиентов и документирования. Моя семья съест именно то, что я приготовлю. Потому что другого я готовить все равно не умею ;)).

QA NewComer Checklist

Адаптации нового сотрудника в новой (ом) компании\проекте\команде. 

Более быстрый и более дешевый ввод в проблемную область нового специалиста.


Как можно быстрее, и как можно качественнее обучить новичка...

Это именно те задачи, с которыми рано или поздно сталкивается любой менеджер, те кого называют наставниками и сами новички.

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

В одной заметке, конечно же, сложно полностью охватить нелегкий вопрос обучения/ адаптации нового сотрудника к условиям выживания в новой компании/проекте. Более того , мне кажется, выводить один общий унифицированный подход к этому вопросу сложно. Компании разные, проекты еще более разные, а уж люди какие бывают  непохожие (по знаниям,  опыту,  возрасту, весу и вероисповеданию). Сложно все причесывать одной гребенкой. Поэтому в этой небольшой статье мне бы хотелось упомянуть одну из best-practice "на местах": Newcomer Checklist.

Собственно я столкнулся на своей новой работе с так называемым Newcomer Checklist. До этого мне приходилось читать, в потом и создавать официальные документы. Плюсы от таких документов конечно же есть, но были и минусы: подписать один документ своим начальником, зам ГД по кадрам + генеральным директором - дело не одного дня. А вот  Necomer CheckList это страница в wiki подобной системе, в которой просто по пунктам указано:

1. Программы, аккаунты, права доступа и соответственно процедуры получения программ, аккаунтов, прав доступа.

2. Общие процедуры: оформление отпуска или отгула, ведение календаря или табеля учета времени, внутренние ссылки.

3. Процедуры и процессы (например, в моем случае, по обеспечению качества), шаблоны (тест планов/спецификаций/тестовых сценариев), руководства пользователя и линки на информацию по проблемной области.

Уместилось в три пункта, но новичку для того, чтобы полностью пройти чек лист нужно около месяца (с учетом проблемной области может понадобиться и больше времени).

После выполнения всех пунктов чеклиста, я немного расширил страницу и добавил ответвление: QA Necomer Checklist, но смысл остался примерно тот же самый.

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

Сложного ничего нет. Нужно  просто обновлять страницу по мере необходимости. Информация же не меняется сразу и вся ;)

Форма чек листа помогает настроить новичка на нужную волну и отслеживать, как продвигается его адаптация.

Wiki подобная система ликвидируют ограничения формальных письменных документов.

Собственно сплошные плюсы проекту.

Как говорил мой преподаватель философии: "Это нужно обдумать".

Идеальная автоматизированная система управления качеством программных продуктов

Если бы вы могли получить то, что хотите, какую бы идеальную систему для управления процессом обеспечения качества, вы бы пожелали?

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

Думая об автоматизации процесса обеспечения качества, я все чаще размышляю о том же, о чем думал уже почти три года назад, когда работал в группе, которую можно было бы назвать отделом АСУ, если бы нас не было всего два человека. Мы пытались централизовано управлять автоматизацией, в то время как каждое подразделение предприятия считало своим долгом делать это самостоятельно.

Когда я только пришел на работу, централизованно можно было только собрать совещание. Когда я уходил, проектировщики могли выгружать из своей системы данные технологам в их систему. Наши экономисты уже автоматически формировали отчетность, в том формате которую требовали бухгалтеры и финансисты. Централизовано работала электронная почта с одним доменом и службой Active Directory. Централизованно же мы закупали ПО и лицензии. Пытались влиять, опять же централизованно, на закупку/распределение компьютеров. На внутреннем веб-сайте с использованием IIS+IE+Active Directory   работала система одного окна для поисковых систем по архиву, внутренним базам данных. Было чем гордиться. Почти  пять лет я потратил на автоматизацию и объединение разрознненых систем и процессов.

И вот то же самое начало я вижу и сейчас (про то же самое я, кстати, читал и в How We Test At Microsoft): отсутствие централизации в процессе обеспечения качества, и самое главное - отсутствие единого продукта для автоматизации работы специалистов  по обеспечению  качества (и тестировщиков).

Что же мы имеем:

Excel - незаменим при построении тестовых roadmap-ов, собственно тестов и даже для создания документов.

Word - тоже полезен для создания документов. Отчеты, спецификации,... (если бы не корпоративные политики давно бы использовал только Open Office Write и Calc, кстати говоря).

Jira - наше все: баг трекинг, трекинг фич, планирование релизов, оценка времени и регистрация информации по проектам, накопление статистики, формирование репортов. Наверное Jira можно использовать и как систему хранения документации (версии, история), но это, как мне кажется, тяжелое решение.

MS Project - диаграмму Гантта никто не отменял.

HP Quality Center - хранить тесты, планировать регрессионные тесты...ну хоть что то же нужно автоматизированно готовить - хотя бы регрессионные тесты.

Confluence/TWiki/Sharepoint/ - коллективный разум должен хоть что-то после себя оставлять в виде файлов, ссылок, статей и картинок.

Тузлы для автоматизации, программирования, статического анализа, хранения кода... Это уже детали.

А как же все это связано? Специалистами. Вся эта кирпичная крошка густо замешана на опыте, знаниях, воспоминаниях специалистов.  Плюс еще конечно техзадания, спеки, тест планы. Но сколько храниться в головах специалистов...А сколько еще предстоит узнать...

А что бы я хотел иметь?

Я бы хотел иметь систему. Одну. Чтобы я мог сам построить workflow.  Чтобы я видел версию документа не в SharePoint, а мне приходило оповещение, поскольку я в роли тестировщика указан в данном проекте.

Хочу полноценную систему документооборота с архивом.

Хочу систему управления требованиями в том же виде, что и в Word или Wiki, но если я помечаю абзац как требование - это требование начинает жить своей жизнью: с версионностью, историей изменений, приоритетами и подтверждениями.

Хочу чтобы эти требования без циничного копи-паста оставляли свой след в системе разработки тестовых сценариев. Т.е. хочу чтобы существовала система для создания тестовых сценариев. Похожая на Excel таблицы, но каждый тестовый сценарий мог бы существовать своей, особой жизнью и также - с историей, версионностью и обратной связью к требованиям. Как это прекрасно получать traceability matrix автоматически... 

 А представьте, как прекрасно выглядят деревья тестовых сценариев с различными тегами (или категориями, или ярлыками).

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

А если вам нужно узнать среднее время для прохождения помеченных вами или выбранных системой автоматически тестовых сценариев '=sum(...' уходит в прошлое. Ведь для этого есть специальная колонка!

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

О да, моя система могла бы многое. Если бы вы спрашивали о фиче1, вам бы предлагали фичи, который рассматривались с этой фичей раньше (фича66, фича121).

Моя бы система на вопрос о environment ошибке предлагала бы контакты суппортеров и workaround. Более того, она сама бы рассылала сообщения суппортерам. Ты звонишь по контакту, а он, какое чудо, занимается твоей проблемой уже почти три минуты.

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

Моя бы система умела считывать данные из системы версионного контроля и присылать свое мнение, почему данная фича должна быть протестирована в первую очередь.

Моя система сама рассылала бы QA Daily Report и табель.

Моя система сама бы расчитывала показатели: сколько багов найдено и пофикшено, сколько багов пофикшено в текущем релизе, сколько багов на душу населения команды мы прос...ли и получили outages от бизнеса.

Моя система была бы идеальна...

Именно поэтому бы ее никто и не смог использовать.

Каюсь, для меня идеальный процесс - это горизонт. К нему нужно стремиться, но дойти не удаться. Можно в любом, сколь  угодно, идеальном процессе найти сбой и бутылочное горлышко. Любой процесс живет и нужно чутко реагировать, менять "серебрянные пули", подходы и, к сожалению, в некоторых случаях людей. Поэтому идеальная система для построения идеальных процессов - это зло. Лучшее - враг всего хорошего. Хотя, чувствую, здесь я могу и ошибиться.

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

И все таки, если уж понеслась такая ярмарка...

Моя система управления процессом обеспечения качества была бы OpenSource.

Моя система была бы модульной и позволяла бы внедрять себя поэтапно. Строилась как конструктор.

Моя система могла бы расширяться пользователями и иметь свой собственный язык программирования, либо позволяла дописывать себя на любом языке, либо встраивать плангины. Либо позволяла делать и то и другое и третье.

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

100 спартанцев из QA-QC....

ПОТОМУ ЧТО МЫ ТЕСТЕРЫ!!!!!

Ну как то так можно начать обзор моего первого опросника на тему "Кем вы были в прошлой жизни"

Собственно я решил остановиться на цифре в 100 проголосовавших и на дней до голосования в 105. Кругленькие цифирки меня радуют (где бы нормального психолога найти чтобы спросить: чего со мной такого в раннем детстве случилось, что меня на кругленькое тянет).

Удивляет пункт [Другое] = 30%. Т.е. 30 % заходивших ко мне в гости до тестирования были людьми не связанными с IT. Бездумно добавил в опросник [Не IT -шник].  Каюсь. И если суммировать, то среди тестировщиков и прочих специалистов по качеству окажется 39! Не знаю как к этому относиться если честно.

Еще кое что удивляет [Со студенческой скамьи]= 33%. Т.е. 33+39+6 (непостоянных не IT -ов) = 78% людей вышли на желтую дорогу качества программного обеспечения не имея глубоких познаний в IT! Можно же и так эти циферки повернуть?

И получается что  всего 40% (меньше половины) до тестирования были более или менее глубоко (а может и не очень) знакомы с процессами IT\softo-делания и пр.

PS. Выборка конечно не слишком репрезентативная - всего 100 спартанцев...ээээ тестировщиков, но все таки информация достаточно забавная. Понятно, что суммировать тоже так как я сделал нельзя. Но статистика вообще наука ложных выводов, так что если добавить туда еще немного, никто и не заметит.

Удачных выходных. А мне еще до выходных в поезде - ту ту!

Почему люди всегда любят - в массы?

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

Лично я против толпы.

Пугает меня толпа.

Поэтому на праздники городов, салюты и прочие массовые собрания не люблю ходить. Массы людей очень инертные. Толкни в любую сторону - поползут, побегут, заорут, затопчут... бррр.

То что можно сделать с толпой на площади, впрочем, реально повторить и в интернете. Заведите себе комьюнити. Нет, честно. Заведите. Если вы более или менее успешны, известны и пр. Постарайтесь, заведите - столько всякого интересного и полезного для себя можно сделать за +5 баллов к рейтингу.

Ого-го-го-го +5 балов! - и индивидум бежит разбрасывая слюну и вопли...

Собственно заметка задумывалась как реклама ресурса http://community.software-testing.ru, получилась антиреклама. Скатился в мрачное брюзжание о собственном глубоко индивидуальном Я (индивидуальность - куда без нее).

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

И к тому же материал на ресурсе сырой. Нет Канеров, Майерсов, Блэков... Баг тут вот нашел, там нашел, тут вот мыслишка пробежала... Хотя ругать себя конечно это прогрессивно, но безрезультативно. Нужно плодить монументальные творения (было бы о чем ).

Теперь взгляд с другой стороны.

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

Пора заканчивать брюзжание.

Есть коммьюнити. Перспективное (надеюсь). Многочисленное (наверное будет). Главное, что там собираются тестировщики - а это поверьте очень веселые и умные ребята (те кто со стажем больше моего ;)) .

Вы хотите тестов? - их есть у меня...

На днях услышал байку. Про тестировщиков. Про русский менталитет и стремление к идеальному, индийскую смекалку и понимание клиента.

Чтобы не раскрывать всякие коммерческие секреты именую всех просто: pападный хозяин (клиент), работник в русском офисе (русский значит), индийские аутсорсеры.

Было у русского работника 200 тест кейсов. Хороших, продуманных тест кейсов. Хозяин возьми и скажи ему: "А сделай в два раза больше тест кейсов и - за неделю".

Русский работник привык все делать хорошо и продумано. Поскольку времени на прогон тестов не увеличивали, то зачем создавать новые тесты, rогда времени на поддержание старых хватало впритык? Что именно расширять русский работник знал, но требовала эта работа месяц - не меньше.

В это время на западного хозяина обратили внимание индийские аутсорсеры. И, в качестве задания, хозяин выдал им: "Вот вам 200 тестов, нужно еще 200, и протестировать их надо за неделю".

Индийцы: "Да, не вопрос".

Через неделю 400 тестов протестированы силами двух индийцев.

Русского сотрудника ругают и переводят в другой проект. Индийцам перепадает проект и перспектива более близкого будущего отношения.

А что собственно сделали индийцы...

Во-первых они разделили 200 тестов на 400. Грубо каждый тест на два.

Во-вторых они протестировали не 400 тестов, а 100 - в случайном порядке.

И казалось бы. Правила индийцы не нарушали: вы хотели 400 тестов - вот они. Клиент остался доволен (хотя и в небольшом неведении). В принципе, оценку приложения, какую никакую, даже по 100 тестам можно провести. И теперь, на зарплату одного русского кормятся три индийца.

Намечается парадокс.

1. В заданных строгих условиях индийцы проявили смекалку и гибкость, за что получили проект.

2. Русский проявил упорство и настойчивость (поскольку думал как нужно делать правильно), но получил нагоняй.

Есть конечно вопрос о профпригодности заказчика (ну или его представителей). Но задача была поставлена - кто с ней справился, то и герой.