Test labs 2016. QA в тотальном аутсорсеSasha Soleev
Мы привыкли работать с информацией от заказчиков, от разработчиков, с документацией. Но что делать, когда вы оказались в ситуации информационного вакуума? Как продолжать работать и развиваться, как мотивировать команду и себя, а также какие бонусы можно найти в такой обстановке – всё это мы обсудим в рамках данного доклада.
Автор: Ольга Пронина
Как оценить время на тестирование. Александр Зиновьев, Test Lead SoftengiSoftengi
Презентация Александра Зиновьева, Test Lead компании Softengi, на семинаре "Оценка в жизни тестировщика" от тренинговой центра QAS Training Center, который прошел 27 ноября в пространстве Циферблат, Киев.
Мы обсудим основные виды тестовой документации, зачем и почему они нужны, кратко поговорим о том почему нужны тест планы и в каком виде. Узнаем для каких задач какую тест документацию стоит выбрать. Поговорим об эффективных принципах и подходах к построению наборов тест-кейсов и чек-листов. Затронем тему отчетности и, конечно же, поговорим о типичных ошибках.
Test labs 2016. Пренебрежение лучшими практиками тестированияSasha Soleev
"Лучшие практики" тестирования, чем они хороши, примеры;
Что плохого в их несоблюдении;
Когда можно ими пренебречь, риски нарушения;
Примеры: нивелирование рисков тестирования в Agile-подходе.
Автор: Григорий Сенин
Test labs 2016. QA в тотальном аутсорсеSasha Soleev
Мы привыкли работать с информацией от заказчиков, от разработчиков, с документацией. Но что делать, когда вы оказались в ситуации информационного вакуума? Как продолжать работать и развиваться, как мотивировать команду и себя, а также какие бонусы можно найти в такой обстановке – всё это мы обсудим в рамках данного доклада.
Автор: Ольга Пронина
Как оценить время на тестирование. Александр Зиновьев, Test Lead SoftengiSoftengi
Презентация Александра Зиновьева, Test Lead компании Softengi, на семинаре "Оценка в жизни тестировщика" от тренинговой центра QAS Training Center, который прошел 27 ноября в пространстве Циферблат, Киев.
Мы обсудим основные виды тестовой документации, зачем и почему они нужны, кратко поговорим о том почему нужны тест планы и в каком виде. Узнаем для каких задач какую тест документацию стоит выбрать. Поговорим об эффективных принципах и подходах к построению наборов тест-кейсов и чек-листов. Затронем тему отчетности и, конечно же, поговорим о типичных ошибках.
Test labs 2016. Пренебрежение лучшими практиками тестированияSasha Soleev
"Лучшие практики" тестирования, чем они хороши, примеры;
Что плохого в их несоблюдении;
Когда можно ими пренебречь, риски нарушения;
Примеры: нивелирование рисков тестирования в Agile-подходе.
Автор: Григорий Сенин
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
Тест-план и исследовательское тестированиеVasiliy Burov
В своем докладе я расскажу как мы в своей работе совмещаем тест-план и исследовательское тестирование. С первого взгляда, может показаться что это не совсем совместимые вещи. Исследовательское тестирование ассоциируется с методом свободного поиска, а тест-план наоборот – следование заданному порядку. Как совместить эти сущности и ничего не потерять – я попытаюсь рассказать.
Techleads Meetup #1
Мобильный веб: назад в будущее"
Виталий Шароватов, Mobile Web Team Lead и Руслан Байрамкулов, Senior Mobile Web QA Engineer (Badoo)
Описание:
Количество пользователей мобильных устройств уже давно превысило количество пользователей стационарных компьютеров и ноутбуков. В свою очередь мобильный веб — это самая быстрорастущая мобильная платформа (по данным comScore, 2015). И если будущее не за этой платформой, то как минимум, она будет его заметной частью.
Давным-давно для Мобильного веба в Badoo были «тёмные времена». Использовались дизайны нативных платформ и эмитировалось их поведение. Даже релизы случались раз в неделю-две. Около года назад ситуация начала меняться в лучшую сторону. Мобильная веб версия Badoo догнала по количеству фич остальные платформы и показала существенный рост по всем показателям. Теперь мобильный веб релизится каждый день.
В докладе мы расскажем о том, что неправильного происходит с процессами внутри и снаружи команды. Для примера возьмем как собственные грабли, так и чужие, но такие распространённые ошибки организации работы.
О том, что не помогло, рассказывать не будем, а о том, что сработало, ничего не утаим. Эта информация поможет вам работать в удовольствие. В ассортименте истории о том:
— как один автоматизатор всю регрессию покрыл;
— как подружились продакты-дизайнеры с командой разработки;
— как жадные программисты забрали себе всю ответственность;
— пуркуа QA любит сидеть с девелоперами плечом к плечу;
— зачем нужно не спускать глаз с багов, ломающих автоматизацию, и как заканчивать фичу после того, как закончили фичу.
Управление компанией с использованием метода критического цепи (МКЦ)Евгений Пикулев
Частная презентация, рассказывающая о недостатках метода критического пути, и о достоинствах метода критической цепи. Полезна для собственников и руководителей компаний.
Поплоухина Елена, Руководитель отдела тестирования в Usetech
https://vk.com/lena_flower
Расскажу об опыте организации процесса внутреннего тестирования проекта со строго формализованным техническим заданием от момента получения технического задания для тестирования требований до момента передачи релиза на приемочное тестирование.
Шаги, необходимые для старта DevOps-трансформации:
1. Выбрать сервис
2. Выявить, кто имеет отношение к сервису
3. Построить Value Stream Map
4. Создать временную команду
5. Поставить задачу
6. Вернуться к пункту 1
Similar to евгения фирсова нерелизное тестирование (20)
2. Когда релизы – это слишком медленно
Большим релизам – нет:
• Процессы в разработке:
• объём работ – до 70 новых задач в месяц;
• распараллеливание – до 10 потоков
одновременно.
• Организационные особенности:
• периодическая смена приоритетов;
• календарные ограничения релизов.
Нерелизное тестирование
4. Куда идёшь, путник?
Фиксируем цели для ОТ:
• Адекватный задаче выбор
требуемого уровня качества.
• Минимизация времени
на подготовку релизов.
• Совместное с разработкой планирование.
Нерелизное тестирование
5. Оценка переданного в ОТ релиза
Критерии готовности:
• окончательность постановки;
• вероятность незапланированных
изменений после начала тестирования;
• полнота сборки пакета;
• ожидания по каждой задаче;
• планируемое перетестирование.
Нерелизное тестирование
6. Оценка переданного в ОТ релиза
Параметры релиза:
• приоритет, срочность, дедлайны;
• вероятность, что релиз будет отложен;
• обязательность/наличие тест-плана;
• доступность оптимального ресурса
(в ОТ и разработке);
• нетестируемый функционал:
• если тестирование невозможно;
• если тестирование не нужно.
Нерелизное тестирование
7. Что тестируем на самом деле?
Подлежит проверке:
• типизация изменений: логические,
интерфейсные, …;
• реализация, меняющая глобальное
поведение компонент;
• «рубильники», способы выкладки и отката;
• предчувствия и сомнения разработчика.
Нерелизное тестирование
8. Пора начинать?
Выбор момента для начала тестирования:
• рассчитывая длительность тестирования:
• опыт аналогичных задач;
• скорость закрытия багов;
• процессы в реальном времени;
• асинхронные процессы;
• длительность регрессионного тестирования;
• как можно ближе к дате возможной выкладки.
Нерелизное тестирование
9. Остановиться и подождать
Тестировщики могут ждать:
• готовность релиза;
• и релизов всех связанных компонент;
• наличие необходимых ресурсов
(люди, сервера, настройки, деньги, …);
• исправление найденных ошибок;
• помощь в воспроизведении проблем;
• экспертная оценка источника проблем;
• выкладки.
Нерелизное тестирование
10. Считаем цыплят
Результат тестирования:
• основание для смены постановки;
• отмашка на выкладку;
• список багов;
• отдельно неисправленные в данном релизе;
• тест-план для регрессионного тестирования.
Нерелизное тестирование
11. За счёт и вопреки
Стоимость скорости:
• перетестирование:
• если пакет устарел;
• после рефакторинга;
• перед выкладкой;
• отсутствие/написание «задним числом» тест-планов;
• частое переключение между релизами;
• частичная передача проверок разработчикам;
• наконец, скорость тестирования.
Нерелизное тестирование
