Post #27
176
Опытный тестировшик решает проблему накопившихся тасок
Channel Public Channel
QA - Subscribers
- 94
- Photos
- 21
- Videos
- 1
- Links
- 8
Showing posts older than #28 · Back to latest
Older Posts 10 shown
Post #23
185
Post #22
201
Ребята, совсем забыл рассказать про Heisenbug Moscow - мегакрутое событие для тестеров и не только. Конференция проходила 5-6 декабря. Я поприсутствовать не смог, а вот моя хорошая подруга, Мила, там побывала и сделала несколько фоток для вас.
Что понравилось Миле?
- доклад про Appium от индуса
- доклады про Web Accessibility, про iot, про автоматизацию отдела автоматизации.
Полный список докладов смотрите здесь https://heisenbug-moscow.ru/
И не забудьте поучаствовать в следующем году - это того стоит.
Что понравилось Миле?
- доклад про Appium от индуса
- доклады про Web Accessibility, про iot, про автоматизацию отдела автоматизации.
Полный список докладов смотрите здесь https://heisenbug-moscow.ru/
И не забудьте поучаствовать в следующем году - это того стоит.
Post #21
198
Регрессионное тестирование (Regression testing)
На нашем проекте сейчас начинается, пожалуй, самый рутинный этап для тестировщиков - регрессионное тестирование, то есть проверка того, что раньше работало, но могло сломаться в новой версии приложения.
Что обычно делают тестировщики в первую очередь?
⁃ Актуализируют тест-кейсы, если этого не было сделано ранее (например, по изменениям, которые появились в новой версии)
⁃ В конце спринта фиксируют версии всех компонентов приложения
⁃ Анализируют результаты прохождения автотестов
⁃ Проводят смоук-тестирование
⁃ Проводят регрессионное тестирование
⁃ В случае отсутствия критичных/блокирующих багов готовят релиз-кандидат к передаче в продуктив
Все перечисленное выше - достаточно гибкая штука и зависит от конкретной компании и проекта, но подход одинаков примерно везде.
Традиционно расшифрую терминологию (объясню простым и даже примитивным языком, более верные и полные с академической точки зрения определения лежат где-то в гугле):
Спринт - период времени, в течение которого запланирован выпуск нового релиза (и, получается, должны быть закрыты задачи на разработку и тестирование)
Автотесты - автоматизированные проверки, выполняемые на тестовом стенде без участия человека (сами автотесты пишутся, разумеется, человеком)
Смоук-тестирование - проверка основных функциональностей приложения на предмет отсутствия блокирующих и критичных багов.
А вот и #тестовое_задание подоспело.
В процессе регресса веб-приложения по доставке еды тестировщиками было выявлено два бага:
1) при попытке входа в личный кабинет у пользователя перестал отображаться баланс бонусных баллов, полученных за уже выполненные заказы, воспользоваться баллами из-за этого не получается
2) ранее на странице ввода адреса доставки для полей Город и Улица при вводе символов пользователю отображался выпадающий список с подсказками, соответствующими его вводу. Теперь выпадающий список перестал отображаться.
Являются ли данные баги критичными/блокирующими для этого релиза? Оценку нужно дать каждому багу. Общаемся здесь @qa_chat
На нашем проекте сейчас начинается, пожалуй, самый рутинный этап для тестировщиков - регрессионное тестирование, то есть проверка того, что раньше работало, но могло сломаться в новой версии приложения.
Что обычно делают тестировщики в первую очередь?
⁃ Актуализируют тест-кейсы, если этого не было сделано ранее (например, по изменениям, которые появились в новой версии)
⁃ В конце спринта фиксируют версии всех компонентов приложения
⁃ Анализируют результаты прохождения автотестов
⁃ Проводят смоук-тестирование
⁃ Проводят регрессионное тестирование
⁃ В случае отсутствия критичных/блокирующих багов готовят релиз-кандидат к передаче в продуктив
Все перечисленное выше - достаточно гибкая штука и зависит от конкретной компании и проекта, но подход одинаков примерно везде.
Традиционно расшифрую терминологию (объясню простым и даже примитивным языком, более верные и полные с академической точки зрения определения лежат где-то в гугле):
Спринт - период времени, в течение которого запланирован выпуск нового релиза (и, получается, должны быть закрыты задачи на разработку и тестирование)
Автотесты - автоматизированные проверки, выполняемые на тестовом стенде без участия человека (сами автотесты пишутся, разумеется, человеком)
Смоук-тестирование - проверка основных функциональностей приложения на предмет отсутствия блокирующих и критичных багов.
А вот и #тестовое_задание подоспело.
В процессе регресса веб-приложения по доставке еды тестировщиками было выявлено два бага:
1) при попытке входа в личный кабинет у пользователя перестал отображаться баланс бонусных баллов, полученных за уже выполненные заказы, воспользоваться баллами из-за этого не получается
2) ранее на странице ввода адреса доставки для полей Город и Улица при вводе символов пользователю отображался выпадающий список с подсказками, соответствующими его вводу. Теперь выпадающий список перестал отображаться.
Являются ли данные баги критичными/блокирующими для этого релиза? Оценку нужно дать каждому багу. Общаемся здесь @qa_chat
Post #20
166
#Ролевыеигры
Под этим хэштегом буду рассказывать о взаимодействии тестировщиков с другими членами IT-команды. Начну серию постов с разработчиков - все-таки именно они пишут код, делают его ревью и еще они тоже немного тестировщики - чаще всего именно они пишут Unit-тесты.
Для не очень посвященных вкратце объясню терминологию.
Ревью кода - это проверка одним из разработчиков кода своего коллеги - это позволяет оптимизировать код и улучшить его читаемость, а знания о новых фичах (особенностях) реализации продукта распространяются среди других коллег. Наличие код-ревью на проекте или в компании - это хороший тон, а для тестировщиков, собирающихся устроиться в такую компанию - отличный сигнал.
Unit-тесты - проверки кода на уровне функций, классов, процедур. Выявление ошибок самим разработчиком на самом раннем этапе обходится гораздо дешевле для компании, чем те, которые вылавливают тестировщики или, что еще хуже, обычные пользователи продукта.
И было бы все замечательно, если бы не одно НО: разработчики, помимо кода, создают баги🙂
Естественно, это происходит неосознанно и не специально. Более того, хороший разработчик не только тщательно покроет свой код юнит-тестами, но и напишет комментарии к коду, подготовит краткую документацию или статью для других, но и это не спасет его от наличия багов. Именно поэтому большинство задач разработчиков после ревью кода (рецензирования) переходит на следующий этап - тестирование. Здесь подключаются тестеры, которые получают новую версию приложения от разработчика, устанавливают его на тестовый стенд (сервер) и начинают делать самое интересное: пытаются его всячески сломать самыми изощренными способами.
Пример. Разработчик добавил в приложение поле для ввода электронной почты - поле действительно появилось в приложении и в него можно ввести e-mail. Но тут тестировщик, проверив это, начинает думать: “А что, если я введу почту без @ или без .ru? А что, если в этом поле я укажу только цифры? А если напишу адрес на другой раскладке клавиатуры или укажу китайские иероглифы?”. Наконец, сломав приложение довольный (или не очень) тестировщик идет к разработчику и рассказывает, что когда он вводит 20 и более символов в это поле, то получает в ответ ошибку 500 и приложение перестает работать. Разработчик начинает фиксить проблему, снова передает тестировщику и в этот раз наконец-то все работает корректно: теперь это поле можно будет показывать пользователям.
А вот вам и первое #тестовое_задание.
По спецификации при оформлении заказа в одном российском интернет-магазине пользователь должен ввести в одно из обязательных полей название своего города с большой буквы и на кириллице. Во всех иных случаях пользователю выводится сообщение: “Неверное имя города. Пожалуйста, укажите название вашего города с большой буквы на кириллице, например, “Москва”.
Тестировщик набросал несколько проверок и в случае, когда он ввел “Омcк”, получил то самое сообщение, но к разработчику не пошел🤷♂️. Как думаете, почему?
Под этим хэштегом буду рассказывать о взаимодействии тестировщиков с другими членами IT-команды. Начну серию постов с разработчиков - все-таки именно они пишут код, делают его ревью и еще они тоже немного тестировщики - чаще всего именно они пишут Unit-тесты.
Для не очень посвященных вкратце объясню терминологию.
Ревью кода - это проверка одним из разработчиков кода своего коллеги - это позволяет оптимизировать код и улучшить его читаемость, а знания о новых фичах (особенностях) реализации продукта распространяются среди других коллег. Наличие код-ревью на проекте или в компании - это хороший тон, а для тестировщиков, собирающихся устроиться в такую компанию - отличный сигнал.
Unit-тесты - проверки кода на уровне функций, классов, процедур. Выявление ошибок самим разработчиком на самом раннем этапе обходится гораздо дешевле для компании, чем те, которые вылавливают тестировщики или, что еще хуже, обычные пользователи продукта.
И было бы все замечательно, если бы не одно НО: разработчики, помимо кода, создают баги🙂
Естественно, это происходит неосознанно и не специально. Более того, хороший разработчик не только тщательно покроет свой код юнит-тестами, но и напишет комментарии к коду, подготовит краткую документацию или статью для других, но и это не спасет его от наличия багов. Именно поэтому большинство задач разработчиков после ревью кода (рецензирования) переходит на следующий этап - тестирование. Здесь подключаются тестеры, которые получают новую версию приложения от разработчика, устанавливают его на тестовый стенд (сервер) и начинают делать самое интересное: пытаются его всячески сломать самыми изощренными способами.
Пример. Разработчик добавил в приложение поле для ввода электронной почты - поле действительно появилось в приложении и в него можно ввести e-mail. Но тут тестировщик, проверив это, начинает думать: “А что, если я введу почту без @ или без .ru? А что, если в этом поле я укажу только цифры? А если напишу адрес на другой раскладке клавиатуры или укажу китайские иероглифы?”. Наконец, сломав приложение довольный (или не очень) тестировщик идет к разработчику и рассказывает, что когда он вводит 20 и более символов в это поле, то получает в ответ ошибку 500 и приложение перестает работать. Разработчик начинает фиксить проблему, снова передает тестировщику и в этот раз наконец-то все работает корректно: теперь это поле можно будет показывать пользователям.
А вот вам и первое #тестовое_задание.
По спецификации при оформлении заказа в одном российском интернет-магазине пользователь должен ввести в одно из обязательных полей название своего города с большой буквы и на кириллице. Во всех иных случаях пользователю выводится сообщение: “Неверное имя города. Пожалуйста, укажите название вашего города с большой буквы на кириллице, например, “Москва”.
Тестировщик набросал несколько проверок и в случае, когда он ввел “Омcк”, получил то самое сообщение, но к разработчику не пошел🤷♂️. Как думаете, почему?
Post #14
153
Весомый плюс работы в IT-сфере - возможность работы удаленно. Даже если вы привязаны к офису, то, как правило, несколько раз в месяц, а то и в неделю, сотрудник может поработать из дома.
В каких-то компаниях нужно согласовать с руководителем весомую причину для удаленной работы (обычно это из серии "приболел, но готов поработать по VPN и не идти на больничный"), в других компаниях для удаленной работы достаточно предупредить коллег, а в третьих компаниях люди и вовсе всегда работают удалённо - из дома, коворкинга или сидя в гамаке где-нибудь на Бали.
Обычно я работаю из дома, когда действительно себя неважно чувствую или когда нужно немного абстрагироваться от офиса и полностью переключиться на свои текущие задачи. Эта потребность обоснованна: тестировщики наряду с менеджерами проектов самые общительные в IT-команде (готов поспорить с теми, кто так не думает, в чате канала @qa_chat ;). А продвинутые QA и тимлиды в течение рабочего дня часто переключаются на задачи своих же коллег. В итоге к концу дня может оказаться так, что задачи коллег закрыты, а твои остались нетронутыми до следующего дня) Вот в такие моменты удалёнка сильно выручает.
В каких-то компаниях нужно согласовать с руководителем весомую причину для удаленной работы (обычно это из серии "приболел, но готов поработать по VPN и не идти на больничный"), в других компаниях для удаленной работы достаточно предупредить коллег, а в третьих компаниях люди и вовсе всегда работают удалённо - из дома, коворкинга или сидя в гамаке где-нибудь на Бали.
Обычно я работаю из дома, когда действительно себя неважно чувствую или когда нужно немного абстрагироваться от офиса и полностью переключиться на свои текущие задачи. Эта потребность обоснованна: тестировщики наряду с менеджерами проектов самые общительные в IT-команде (готов поспорить с теми, кто так не думает, в чате канала @qa_chat ;). А продвинутые QA и тимлиды в течение рабочего дня часто переключаются на задачи своих же коллег. В итоге к концу дня может оказаться так, что задачи коллег закрыты, а твои остались нетронутыми до следующего дня) Вот в такие моменты удалёнка сильно выручает.
Post #13
129
К слову, о митапах. На днях ходили с коллегами на обед, и разгорелся у нас спор не на шутку: имеет ли смысл ходить на все эти ивенты, митапы, конференции, или же это пустая трата времени?
Доводы ЗА и ПРОТИВ, по-моему, очевидны, но все же приведу их ниже.
Доводы ПРОТИВ:
- гораздо быстрее нужную информацию можно нагуглить
- тратится время/деньги, особенно, если ивент платный
- кейсы, которые разбираются на таких встречах, достаточно специфичны для конкретного проекта
Доводы ЗА:
- можно расширить свой кругозор, узнать о новых инструментах и техниках
- завести новые знакомства и контакты
- пообщаться с лидерами IT-индустрии
- задать вопросы экспертам вживую
Я склоняюсь к тому, что митапы - это мегаклассная штука. Неформальные встречи с коллегами, знакомства - все это помогает отвлечься от рутины.
Кстати, на митапе Redmadrobot, о котором писал выше, я совершенно случайно встретился с Алиной, своей бывшей... коллегой, которая перешла совсем недавно в другую компанию и теперь занимается там автотестами. С Алиной вы ещё познакомитесь в этом канале - она расскажет про автотесты лучше меня.
Доводы ЗА и ПРОТИВ, по-моему, очевидны, но все же приведу их ниже.
Доводы ПРОТИВ:
- гораздо быстрее нужную информацию можно нагуглить
- тратится время/деньги, особенно, если ивент платный
- кейсы, которые разбираются на таких встречах, достаточно специфичны для конкретного проекта
Доводы ЗА:
- можно расширить свой кругозор, узнать о новых инструментах и техниках
- завести новые знакомства и контакты
- пообщаться с лидерами IT-индустрии
- задать вопросы экспертам вживую
Я склоняюсь к тому, что митапы - это мегаклассная штука. Неформальные встречи с коллегами, знакомства - все это помогает отвлечься от рутины.
Кстати, на митапе Redmadrobot, о котором писал выше, я совершенно случайно встретился с Алиной, своей бывшей... коллегой, которая перешла совсем недавно в другую компанию и теперь занимается там автотестами. С Алиной вы ещё познакомитесь в этом канале - она расскажет про автотесты лучше меня.
Post #12
117
Сходил на митап к роботам, они же Redmadrobot - в IT-сфере, а точнее - в мобильной разработке - ребята известные и работают аж с 2008 года.
Доклады были очень доступные, рассчитаны на QA-джунов и -миддлов.
А вот и сами темы:
- UI-автотесты под iOS для самых маленьких
- UI-автотесты: неочевидные очевидности в планировании и реализации
- No pain, no gain: тестируем голосовые приложения
Меня особенно впечатлил последний из этих докладов: Паша Булич из KODE рассказал о сложностях, которые решала его команда при тестировании голосовых навыков для Алисы. Вообще, тестирование голосовых помощников - тема неизбитая - информации мало, перенять чужой опыт практически не у кого. Но стандартные техники анализа работают, к счастью, и тут: естественно, есть и граничные условия, и классы эквивалентности и т.п. О них обязательно расскажу более подробно в ближайших постах.
Доклады были очень доступные, рассчитаны на QA-джунов и -миддлов.
А вот и сами темы:
- UI-автотесты под iOS для самых маленьких
- UI-автотесты: неочевидные очевидности в планировании и реализации
- No pain, no gain: тестируем голосовые приложения
Меня особенно впечатлил последний из этих докладов: Паша Булич из KODE рассказал о сложностях, которые решала его команда при тестировании голосовых навыков для Алисы. Вообще, тестирование голосовых помощников - тема неизбитая - информации мало, перенять чужой опыт практически не у кого. Но стандартные техники анализа работают, к счастью, и тут: естественно, есть и граничные условия, и классы эквивалентности и т.п. О них обязательно расскажу более подробно в ближайших постах.
Post #2
111
Ура, первый пост! Рассказывать буду о буднях тестировщиков, событиях и митапах, взаимодействии с командой разработки. В общем, располагайся поудобнее - будет интересно)
Channel created