Доклад Ирины Винокуровой с онлайн-конференции Fun ConfeT&QA.
…Ты приходишь на работу, получаешь новый билд на тестирование, радостно начинаешь тестировать, предвкушая кучу интересных багов… Но что такое? Первая же стандартная проверка, и приложение падает. Затем вторая, третья… Ситуация не меняется.
…В баг-трекере большое количество багов в статусе resolved. С удовольствием начинаешь перепроверять… Так, стоп. Шаги те же, но система падает. Правда, с другой ошибкой. И на немой укор программистом можно услышать: «Ну есть же ты. Ты и перепроверишь»…
…Весь отдел разработки гудит, что в программу вводится новая функциональность. Все программисты кодят так, что дымятся клавиатуры. Но на просьбу дать ТЗ, тебе отвечают, что пока не время…
Когда такие вещи случаются один или два раза, то это можно воспринимать, как досадную случайность. А что, если они постоянны? И стандартные ошибки, и не перепроверка своих же исправлений, и постоянные разговоры об автоматизации…
Но выход есть – объяснить программистам, чем же мы занимаемся на самом деле. С толком, чувством, расстановкой. Чтобы ребята наконец поняли: мы команда. И некоторые вещи надо делать совместно.
О том, что я рассказывала своим программистам про тестирование, как я это делала, и к чему это привело, я постараюсь рассказать в своём докладе.
Я абсолютно убежден,что подходы и методы тестирования нужно постоянно совершенствовать. В последнее время моя команда стремится к тому, чтобы наши тестировщики тоже разделяли эту позицию. Мы пытаемся этого добиться, разъясняя, что:
Наши нынешние методики – тоже результат многолетней эволюции.
Верить в существование идеальных решений опасно: мы можем упустить куда лучше подходящую нам методику, цепляясь за «передовые методы».
Мы всегда открыты для новых идей и предложений.
Беседуя с тест-аналитиками о совершенствовании наших подходов и внедрении новых техник, я начал задумываться о целях улучшения тестирования. Как мы узнаем, что эта эволюция положительно повлияет на него? Как мы определим, что новая идея действительно улучшила наши процессы?
Я спросил тест-аналитиков, бизнес-аналитиков и владельцев продукта, как измеряется успешность тестирования.
Ниже приведено краткое содержание моих записей, сделанных в процессе общения, и перечислены проблемные места каждой метрики, которые (как я считаю) нужно учитывать при попытке эти метрики применить. Я также постарался изложить свое видение оценки успешности тестирования.
Уже давно ведутся споры о том, стоит ли сдавать ISTQB каждому конкретному специалисту. Особенно много сомнений у опытных тестировщиков, которые видели уже не один проект, посетили не один тренинг и прочли множество информации о тестировании.
BySTQB предлагают оторваться от противоречивых доводов «за» и «против» и бесплатно пройти пробный экзамен ISTQB Foundation Level.
*В бесплатной версии экзамена сертификат не выдается.
Почему стоит попробовать:
1) Не нужно готовиться – интересно же узнать, сдадите или нет просто с текущим уровнем знаний 2) Уже через час после экзамена вы получите результаты 3) Вы увидите не просто, какие ответы были правильными, а получите письменное обоснование, почему именно так 4) В случае не сдачи, вы ничего не теряете, а если вас убедят аргументы из пункта 3, то появится повод ознакомиться с общедоступными материалами подготовки к ISTQB, и повысить свой уровень в нужной теме 5) В открытом доступе будет опубликована итоговая статистика, можно ли сдать первый уровень ISTQB без подготовки и какие результаты получают тестировщики с разными годами опыта.
Для тех, кто уже твердо решил получить сертификат ISTQB, будет возможность совместить полезное с приятным, и сдать официальный платный экзамен.
Сертификация и бесплатный пробный экзамен состоятся в Москве 26 ноября, бесплатный экзамен также возможен в онлайн-формате. Читатели портала software-testing.ru могут сдать платный экзамен ISTQB CTFL по специальной цене – 140 Euro, для этого при регистрации используйте промокод STRU.
Мы уже почти сформировали расписание онлайн-тренингов по тестированию ПО до Нового года. Часть тренингов закончатся в канун новогодних праздников, часть захватит новогодние каникулы и продолжится в новом году. Это позволит тем, кто хочет провести это время с пользой во время длинных новогодних каникул, досдать и доработать предыдущие задания и идти вперед. Тренер будет в новогодние каникулы осуществлять поддержку учеников. А те, кто во время каникул собирается отдыхать, приступят к дальнейшей работе уже после новогодних праздников.
В новый год нужно вступать с новыми целями и задачами, а для этого как нельзя лучше помогают новые знания, поэтому мы приглашаем познакомиться с нашим расписание и выбрать себе подходящий курс.
Ниже представлены онлайн-тренинги с разбивкой по областям тестирования. Каждый тренинг включает в себя качественный теоретический материал, практические работы с обратной связью от тренера, постоянные консультации тренера во время всего срока обучения.
Мы работаем уже больше 6 лет и за это время нам прислали сотни отзывов, по результатам которых наши тренинги постоянно улучшаются.
Когда Ллевелин Фалько учит детей программировать, его "первое правило программирования" дети запоминают накрепко. Оно гласит, что программисты очень ленивые. Например, когда они хотят обратиться к некоторой функции, они не пишут её название полностью. Достаточно ввести две-три буквы, и пусть инструменты выполнят всю остальную работу за вас там, где это возможно.
Я не могу с этим согласиться – насколько я знаю из своего опыта работы, большинство программистов вовсе не ленивы. Программисты автоматизируют рутинную работу, они выявляют задачи, которые регулярно повторяются (или даже потенциально могут повторяться), и превращают их в код. Это требует таких усилий, что лень - далеко не первое качество программиста, которое приходит мне в голову.
Но иногда программисты действительно проявляют такую способность лениться, что это не укладывается у меня в голове. Лень заставляет их думать, что их компьютер – это практически центр вселенной, и подсказывает им знаменитый универсальный ответ «У меня все работает».
Выступление Алексея Петрова на онлайн-конференции для специалистов по тестированию Fun ConfeT&QA.
Даже в небольших командах тестирования объем информации, ежедневно проходящей через нее бывает запредельно высоким. А сколько информации проходит через нас за неделю, месяц, год…
Как не потеряться в этом потоке фактов, чисел, фамилий, проектов?
Мой ответ- вестники тестирования! Вестник тестирования- это стенгазета/электронный журнал, в котором в свободной форме излагаются ключевые аспекты из жизни отдела тестирования. Все это сопровождается толикой образовательной информации и Fun’a, что делает прочтение вестника не только полезным, но и интересным.
В своем докладе я расскажу о том, какие цели и пользу можно получить с помощью подобного креатива. А также поделюсь «кухней» создания таких вестников и полезными советами.
Выступление Натальи Руколь на онлайн-конференции для тест-менеджеров Chief ConfeT&QA.
Как бы вы ни старались «проверить всё», расширяя отдел или увеличивая сроки, времени на тестирование никогда не хватит.
Именно поэтому настоящие джедаи идут другим путём: они делают всё возможное для отбора в тестирование самых важных, самых необходимых тестов, и при этом – в правильной последовательности. И делают они это быстро, точно, применительно к каждой итерации и в разрезе различных областей функционала и типов тестирования.
Как они это делают? Какие световые мечи используют для победы над пропущенными ошибками и затянутыми сроками?
В этом докладе я расскажу вам о ключевых способах приоритизации тестов:
Анализ по приоритетам
Анализ на основе рисков качества
Карта влияний
Матрица изменений
Благодаря этому докладу вы получите в свой арсенал инструменты быстрого и эффективного планирования тестирования. Да пребудет с вами сила!
Недавно я поучаствовал во встрече тестировщиков Лондона и слушал выступление Марка Винтерингэма, который рассуждал о ментальных моделях инструментов тестирования. Содержание его доклада и слайды можно посмотреть здесь: Почему Webdriver - это круто.
Он рассказывал, как Webdriver помогает автоматизировать тестирование/проверки (нет, я не хочу развязывать дискуссию насчет определений в этой статье), и как этот инструмент облегчил его труд тест-консультанта.
Марк также обратил внимание, что инструменты, которые мы используем, определяют наше мышление, поведение и взаимодействие с приложением. Они влияют на то, как мы принимаем решения, как мы общаемся. Иными словами, инструменты начинают определять, как именно мы тестируем - если мы позволим им это.
Он сослался на один из самых ярких докладов конференции Test Bash 3 - "Автоматизация: время менять подходы" Иана МакКовветта (видео доклада можно посмотреть здесь) и сделал вывод, что к выбору инструментов и их использованию для достижения целей тестирования нужно подходить с осторожностью.
В ходе беседы Марк агитировал нас за "полигамию" в отношении инструментов. Чтобы повысить их эффективность, нужно искать новые подходы, пробовать новые инструменты. Если мы ограничиваем себя определенным набором инструментов - мы, в конечном итоге, ограничим свое мышление. Полигамия - это, конечно, забавная, но очень точная аналогия.
Зачем тестировщику-автоматизатору учить теорию? Может быть достаточно освоить какой-нибудь популярный инструмент, например, Selenium или TestComplete? Выучить какой-нибудь язык программирования, например, Java или Python? И никакая теория не нужна.
Но подождите! Раз уж зашла речь о программировании ("выучить какой-нибудь язык") -- давайте посмотрим, как там обстоят дела с теорией.
Обучение программированию начинается с понимания того, что такое алгоритм. Базовые элементы описания алгоритма одинаковы для множества языков программирования. И если человек один раз понял, что такое условие и что такое цикл -- он сможет узнать их под разными масками в разных языках программирования.
После этого, конечно, хорошо бы уже научиться писать на каком-нибудь языке, чтобы эти теоретические знания об алгоритмах применить на практике.
Но через некоторое время оказывается, что помимо алгоритмов языки содержат конструкции для описания классов -- и тогда приходится снова возвращаться к теории, чтобы понять суть объектно-ориентированного подхода. Это тоже достаточно универсальная идея, которая применяется во многих языках программирования, хотя может выглядеть очень по разному.
Освоив принципы работы с классами и объектами, человек получает в руки новый мощный инструмент. Он уже не только алгоритмы пишет, он строит архитектуру приложения. Это позволяет писать более сложные программы.
Но ещё через какое-то время выясняется, что архитектура местами получается какая-то кривая, костыли подпирают её тут и там. И приходится снова возвращаться к теории -- читать книжки про шаблоны проектирования, изучать типовые приёмы, учиться избегать стандартных ошибок проектирования.
И эти колебания от теории к практике и обратно могут повторяться многократно. Потому что есть ещё много интересного, выходящего за рамки отдельно взятого языка программирования.
А когда вы разрабатываете автоматизированные тесты -- к общей теории программирования добавляется ещё и специфическая дополнительная теория.
Онлайн-тренинг Алексея Баранцева, 1,5 месяца занятий, 7.5 часов теории + много практики + постоянные консультации тренера в скайп-чате
Первый запуск – 25 ноября, не пропустите, обычно первая группа самая активная :-)
Можно ли представить себе хорошего линуксового системного администратора, который не знает общую теорию операционных систем и сетей, не подозревает о существовании Windows и MacOS, не умеет пользоваться для настройки системы консолью так же хорошо, как графической оболочкой? Можно ли считать хорошим инженером-строителем человека, который не владеет сопроматом, не знает про современные строительные материалы и особенности их применения, даже если на текущем объекте строительства они не используются? Можно ли признать хорошим актёром того, кто день за днём играет одну и ту же роль, не знает о современных тенденциях в театральном искусстве и не пытается попробовать себя в других амплуа?
Хороший специалист должен обладать достаточно широкими знаниями. Да, он глубоко изучает какую-то одну тему, специализируется в каком-то направлении, но при этом он должен представлять себе общую картину своей профессиональной области. Если он не будет это делать -- мир уйдёт вперёд, его узкая тема окажется устаревшей и невостребованной, а он ничего другого не знает и не умеет.
Умение создавать автоматизированные тесты предполагает владение специализированными инструментами, которые так и называются "инструменты для автоматизации тестирования". Но знания хорошего специалиста должны охватывать всю область автоматизации. Какие вообще инструменты бывают? Для чего они предназначены? В какой ситуации следует (или наоборот не следует) использовать тот или иной инструмент? Как выбрать наиболее подходящий для решения задачи инструмент среди множества похожих?
И конечно же надо уметь делать хорошие автотесты. Да, сначала надо научиться понимать, чем "хорошие" автотесты отличаются от "плохих". А потом -- научиться делать "хорошие". Эти правила являются общими, независимыми от конкретного используемого инструмента.
Для тех, кто хочет расширить свой кругозор и получить общие фундаментальные знания в области автоматизации тестирования мы подготовили этот учебный курс.
Выступление Игоря Хрола на онлайн-конференции Selen ConfeT&QA
UI-автотесты не отличаются высокой надёжностью. Где-то может не хватать синхронизации и тесты будут «падать» время от времени просто так. Или фокус «слетел» и кнопка не нажалась. Эти и другие случаи зачастую делают результаты автотестов непредсказуемыми и не вызвающими доверия.
В докладе хотелось бы поделиться опытом того, как пожертвовав целью 100%-но точной эмуляции действий пользователя, можно добиться надёжных и воспроизводимых результатов от Selenium-тестов. Разговор будет основан на опыте использования данной идеи на одном из проектов, а также будут даны общие рекомендации, применимые для широкой аудитории.
