К основному контенту

Результаты опроса о текущем состоянии тестирования (via QA Intelligence)

Больше 3-х лет назад публиковал у себя ссылку на опрос тестировщиков от www.practitest.com
Относительно недавно они опубликовали результаты опроса тестировщиков 2016. Есть там и на русском языке.

Не буду тут скриншотить интересные цифры, лучше сами посмотрите.

Но давайте попробуем сравнить, что поменялось за прошедшие года (я еще 2015 год глянул) :)

1. Начиная с 2015 в опросе начали фигурировать ответы тестировщиков из России, то есть появился шанс увидеть что-то приближенное к нашей реальности.

2. Немного, но уменьшилось (с 30% до 20%) количество голосовавших работающих в больших (>50 человек) командах.

3. ЗП тестировщиков в USD в России как то не сильно уменьшилась (с 2015 по 2016). Видимо за счет добавления к нам (или нас к ним) ответов из Восточной Европы. Разве что для людей с опытом +10 лет зп меньше стала. Но скорее похоже на снижение за счет того, что другие люди голосовали. А так выглядит странным, учитывая изменение курса рубля в 2 раза.

4. Количество голосовавших тест-лидов увеличилось с 16 до 34% :) Будем надеяться, что это рост тех, кто голосовал в 2013. А не то, что у нас каждый третий тестировщик - лид.

5. Exploratory/ Session based testing по-прежнему самый популярный способ тестирования (больше применяют 87% опрашиваемых).

6. Какая тестовая документация используется: тест-планы (64.5% в 2013 vs 63% в 2016), чек-листы (56% vs 54%), mindmap-ы (34.5% vs 33%). В общем не сильно все поменялось.

7. Навыки необходимые тестировщику. Выросли ожидания по вебу, автоматизации, появилось Big Data testing, навыки программирования.
простите, не удержался :)
8. 86% используют автоматизацию. Многие даже пишут юнит-тесты и BDD-скрипты (43% и 21% соответственно).

9. По-прежнему около 60% используют Word, Excel, Mail как средство контроля за состоянием тестирования

10. Там еще много чего интересного: что еще делают тестировщики кроме тестирования, откуда получаются знания (65% - из соцсетей, блогов, 60% - книги), с какими проблемами приходится сталкиваться, на что обращают внимание на собеседовании и тд.

Полистайте сами :)

Комментарии

Популярные сообщения из этого блога

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе