После очередной уборки на сервере выяснили, что у нас осталось несколько неопубликованных докладов со старых онланй-конференций. Те доклады, информация в которых еще не устарела постараемся выложить в ближайшее время.
Выступление Алексея Лянгузова на онлайн-конференции для специалистов по тестированию ConfeT&QA.
То о чём я хочу поведать, приемлемо в случае, если тестовая команда параллельно тестирует несколько проектов, с более-менее жёстким распределением по этим проектам. Представьте такой диалог между руководителем тестирования двух проектов А и Б (ЛидА и ГлеБ): ЛидА: Глеб, выручай у нас релиз на носу, нужны бойцы, не успеваем, зашиваемся. ГлеБ: Сколько людей надо? На какое время? Когда? ЛидА: Вчера надо. А сколько дашь? Мне вообще на денек-другой, может на недельку. ГлеБ: На недельку %) Ладно, так, дам тебе Тугодумова, Раздолбаеву и … ЛидА: з-э, только не Раздолбаеву… … Далее либо договорятся, либо придет Босс и скажет кому и куда идти. Знакомо? Я расскажу о своем подходе, как можно минимизировать данный хаос и затраты на переключение между проектами и максимально продуктивно и позитивно использовать тестировщиков, работающих на других проектах. И нет, это не постоянная ротация. Подход называется “Интенсивный Тестовый Цикл” и предлагает спланировать аврал заранее. Как? Об этом я и расскажу. Данный подход опробован не на одном проекте и зарекомендовал себя как работающий и полезный.
Перевод и адаптация: Кристина Журавлева (ПрактиТест)
Многие слышали, что разработчики не могут быть хорошими тестировщиками.
Хотелось бы все-таки разобраться почему. В этом мне поможет англоязычная статья Джоэля Монтвелиски. Конечно перевод будет вольным с небольшими отступлениями и моими мыслями на эту тему.
Правда, что вы можете научить собаку нескольким трюкам, но вы уж точно не сможете научить ее летать.
Давайте рассмотрим несколько пунктов по которым разработчикам не суждено стать тестировщиками в привычном понимании этого слова.
1. “Родительские чувства” к коду
Разработчики привязаны к тому, что они пишут. Может быть это прозвучит глупо, но очень сложно оценивать объективно то, что ты создаешь.
2. Акцентирование на позитивных моментах
Работа разработчика основывается на позитивных сценариях и их реализации в продукте. Чтобы работать тестировщиком нужно иметь диаметрально противоположный склад ума, так как тестировщики всегда акцентируются на негативных сторонах продукта нежели чем на позитивных. Следовательно разработчику нужно поменять склад ума, чтобы стать тестировщиком, а это не кажется столь реальным на мой взгляд.
3.Работа на основе принципа упрощения сложных вещей
Рассматривание сложных сценариев с целью нахождения багов является одной из составляющих процесса тестирования. В двух словах мы берем простую вещь и придумываем как ее можно усложнить.
Разработчики поступают ровно наоборот. Они берут сложный процесс или проект и разбивают его на более мелкие компоненты с целью найти решение проблемы.
Практически каждая крупная организация нанимает в свой штат разработчиков программного обеспечения. При этом только треть из них заняты непосредственно в бизнесе, связанном с ИТ. Но вне зависимости от того, где они работают: в фармацевтической компании, образовательной или рекламной сферах, они остаются программистами.
Работа в команде – ответственное занятие, поскольку в этом случае люди отвечают не только за себя, но и за окружающих, они общаются, помогают друг другу. Как бы это ни было банально, ключом к продуктивному общению между людьми всегда является вежливость и взаимоуважение. Однако все же есть определенный список фраз, которые – даже когда они звучат вежливо и корректно – не стоит употреблять в разговоре с разработчиками и тестировщиками, если вы их коллега, заказчик, «владелец» или руководитель проекта.
1. «Можешь закончить тестирование поскорее?»
Тестирование должно проводиться вдумчиво и тщательно, чтобы не пропустить критичные недоработки. Хорошее тестирование – залог качественного продукта. Разумеется, есть инструменты для ускорения процесса (вот несколько туториалов по автоматизации тестов, предложенные резидентами Stack Exchange), однако, даже автоматизированные тесты приходится поддерживать и постоянно модифицировать.
В идеале тестирование начинается еще на этапе проектирования продукта и продолжается до самого релиза, а дизайнеры и разработчики плотно взаимодействуют с тестировщиками. Если в вашей компании происходит иначе, то, поздравляем, вы узнали рецепт задержек, ошибок и недостатка бюджета (вот еще несколько вещей, которые не любят слышать тестировщики).
В трансляцию блогов регулярно добавляются новые блоги. Их количество уже давно перевалило за отметку 100. Ну а мы продолжаем знакомить Вас с новыми блогами.
Мы - IT-профессионалы: разработчики, тестировщики, автоматизаторы, менеджеры, специалисты по продажам. Сотрудники ведущих компаний, тренера, консультанты, участники международных конференций.
Цель нашего сообщества - создать единую СНГ площадку для эффективного общения всех IT-специалистов в контексте автоматизированного тестирования.
У вас будет возможность:
услышать доклады ведущих IT-профессионалов и поделиться своим опытом
бесплатно участвовать в “промо”-версиях топовых IT-конференций стран СНГ
регулярно встречаться лично, на тематическом форуме, в “филиалах” сообщества в социальных сетях и мессенджерах
IT в Беларуси является одной из самых перспективных и стремительно развивающихся профессиональных сфер. Она привлекает все больше специалистов, порой из совершенно неожиданных областей.
В нашем блоге мы регулярно публикуем не классические истории активистов нашего сообщества, пришедших в IT, нашедших свое призвание в этой интереснейшей области, истории успеха.
Мы рады новым знакомствам, всегда открыты к общению, присоединяйтесь, будет интересно
В конце мая этого года в Санкт-Петербурге прошла конференция SQA Days 19. Записи некоторых выступлений с конференции уже появляются в открытом доступе.
По мере их публикования мы сделаем подборки докладов по основным темам в тестировании.
Начать решили с подборки докладов, где авторы рассказывают о методах развития команды. Ниже Вы можете найти видео докладов с конференции и просмотреть презентации.
В связи с выходом новой версии JMeter 3.0. мы решили полностью переписать наш тренинг Тестирование производительности. До 12 июля на этот тренинг действует старая цена.
Запустили новый тренинг НЛО: найти, локализовать и оформить ошибку. Это практический курс для тестировщиков по локализации и оформлению баг-репортов + советы по поиску багов, который научит описывать баг-репорты так, чтобы их понял даже вернувшийся после лоботомии разработчик.
Добавили новую опцию в курс Школа тест-менеджеров v. 2.0. Раньше мы брали на курс начинающих менеджеров, у которых есть своя команда и проект. Сейчас прийти может даже тот, кто только думает о карьере тест-менеджера. В этом случае, мы предоставим ему проект и поможем собрать команду на время прохождения курса.
Вышел июньский выпуск рассылки портала Software-Testing.RU, в котором собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.
После очередной уборки на сервере выяснили, что у нас осталось несколько неопубликованных докладов со старых онланй-конференций. Те доклады, информация в которых еще не устарела постараемся выложить в ближайшее время.
Последнее время область мобильных приложений становится все популярнее. Чего только стоит приложение Angry Birds, количество загрузок которого уже давно превысило цифру в 10 миллионов!
Существует 3 основных типа Android приложений:
Native
Web
Hybrid
За 20 минут я успею показать, как автоматизировать Native Android приложения при помощи инструмента Robotium, так чтобы голова не болела.
В мае вышла новая версия JMeter 3.0. Концептуальных изменений в ней нет, однако поменялся интерфейс, изменились названия некоторых элементов, а также появились новые элементы.
Помимо адаптации к JMeter 3.0, программа обновленного тренинга претерпела и другие изменения. Учтены замечания в отзывах участников, больше времени мы уделили моментам, которые казались ученикам сложными, максимально уплотнив материал лекций. Лекции разбиты на небольшие фрагменты до 20 минут для удобства просмотра и навигации.
Дата начала работы первой группы – 29 июля.
Поэтому если Вы планировали начать осваивать тестирование производительности, не откладывайте это в долгий ящик и запишитесь в текущую группу, чтобы получить новую версию тренинга по старой цене.
В обеспечении качества различают верификацию и валидацию. Верификация отвечает на вопрос, правильно ли мы создаем продукт, а валидация – на вопрос, а то ли мы вообще создаем, что нужно. Некоторые люди проводят водораздел между обеспечением качества и тестированием, исходя именно из этих определений.
С моей точки зрения, использование терминов "верификация" и "валидация" может привести к ложным дихотомиям. Для меня тестирование – это деятельность, связанная с дизайном, и поэтому покрывает довольно широкую область. Я верю, что тесты могут стать неким "общим языком". Я верю, что тесты могут напрямую кодировать спецификации и требования. И я верю, что тесты – это источник знаний об области или продукте. Слишком большой упор на разницу между верификацией и валидацией – это неэффективный и не результативный способ понять, как именно тестирование дополняет обеспечение качества.
С моей точки зрения, неспособность воспринимать тестирование и обеспечение качества, как два различных, дополняющих друг друга процесса – это восприятие, которому явно не хватает некоторого изящества.
На самом деле я согласен, что различия между верификацией и валидацией вполне оправданы. В конце концов, эффективность – это способность делать что-то правильно. Результативность, с другой стороны – это способность выдавать правильный результат. Эффективность сфокусирована на процессе и нацелена на доведение его до конца, а результативность – на продукте (то есть, собственно, на результате этого процесса). Можно сказать и так: эффективность концентрируется в первую очередь на том, чтобы избежать ошибок, а результативность – на успехе вне зависимости от количества промахов, допущенных по пути.
Однако мне кажется, что есть способ различать эффективность и результативность, который куда лучше понимания разницы между верификацией и валидацией. Ведь тестирование прямо-таки требует гибкости и инноваций.