Мыслетрекер

Недавно один мудрый друг рассказал мне притчу:

Как-то раз один мужчина из Владивостока решил купить спелых помидорчиков в Москве, и привезти их семье домой. Не будем уточнять, что сподвигло его на это гениальное решение: сделал и ладно. И вот он приехал в Москву, набрал ящик самых спелых, сочных, аппетитных помидорок, и сел на поезд. Домой. Во Владивосток.

Едет он день, едет два — и видит: помидорка одна начинает сбоку подгнивать. Ну, думает, не успею я её домой довезти — съем пока что. Съел и видит: вторая тоже начинает портиться. Съел и её.

На следующий день он заметил ещё парочку порченных и съел их. Так и подъедал он каждый день подпорченные помидоры, и подъехав к Владивостоку понял, что съел всё, что вёз. И все помидоры, которые он ел, были несвежими.

Какая мораль? Сами думайте, всё как всегда. Но последние недели мне выпали достаточно тяжёлыми, а с тех пор, как я услышала эту притчу, теперь каждый раз, отправляя письмо со словами «Простите, что позднее обещанного…» я чувствую во рту вкус испорченных помидоров.

Жили-были в 2 параллельных вселенных 2 тестировщика: Нина и Гриша. Тестировали они одинаковое ПО в одинаковых командах, и был это калькулятор.

Гриша был раздолбаем редкостным. Кнопки потыкает, что заметит заведёт, и продолжает смотреть fishki.net

А Нина была девушкой гиперответственной. Ходила на курсы, скупала весь ассортимент книг по тестированию на amazon’e, читала статьи, внедряла новое на практике. Старалась ничего не пропустить: везде анализировала классы и границы, выявляла зависимые параметры, комбинировала проверки, готовила себе таблички с тест-анализом, помечала результаты проверок, оценивала покрытие кода, — в общем, делала всё, лишь бы не пропустить ошибки.

Тестировали они тестировали, и вот, наступил день финального тестирования предрелизной сборки. У Нины заранее был подготовлен тестовый набор для проверок: все возможные типы чисел, из различных классов эквивалентности (положительные и отрицательные, целые и дробные, состоящие из разных цифр и разного количества знаков, большие и маленькие). И она стала проверять все эти значения на всех операциях. Результат: всё работает! Довольная, показала это руководству, и продукт ушёл в релиз.

Гриша не знал, как правильно тестировать, да и не очень хотел в это вникать. Потыкал все кнопки — вроде работают. Сложил 2 числа — вроде работает. Умножил 15 на 42 — и получил огромный страшный краш системы. Завёл багу: оказалось, при умножении любого числа на 42 (и только на 42) продукт падает — вот такое пасхальное яичко было от уволенного разработчика. Багу поправили и выпустили продукт.

Чем всё закончилось? Тем, что во вселенной Нины краш нашли пользователи, а во вселенной Гриши критикалов пропущено не было.

Какие выводы?

Жил да был один тестировщик, и звали его не скажу как, а тестировал он сайт покупки билетов, который назывался http://censoredsite.ru.

Он был грамотным опытным тестировщиком, хорошо разбирался в продукте, отлично заводил ошибки, разрабатывал грамотные приёмочные автотесты, дружил с разработчиками и аналитиками.

Как-то раз к нему пришёл тест-менеджер, и сказал: «Нескажукак! Тебе надо писать тесты, чтобы точно описать, что именно нужно проверить, и не пропускать их».

Нескажукак был в шоке. Он хорошо выполнял свою работу, зачем ему эта лишняя бюрократия?

Тест-менеджер, далёкий от жизни нормальных тестировщиков, начал выдумывать всякие странности:

• шаблон тестов
• шаблон отчёта о результатах прохождения
• метрики покрытия, проверявшие наличие тестов на каждый элемент формы, каждое действие в системе и т.д.

Нескажукак был на грани истерики: «Нам нужно работать, а не все эти ваши дурацкие тесты писать!»

Он уже начал искать другую работу, но т.к. заставляли, тесты начал писать. Использовал шаблон, предоставленный ТМом, описывал стандартные проверки для каждого поля.

А потом началось тестирование. Он проверял как любил, он был в потоке, баги сыпались рекой, и все были счастливы. Когда ошибки были исправлены, он ответил «ДА» на священный вопрос: он сказал «да, можно выпускать наш продукт пользователям!».

А потом был релиз. И были пользователи, которые пытались использовать censoredsite. В первый день в техподдержку обратилось 40 человек из 200 посетителей. Оказалось, что при смене адреса после сохранения, неправильно отображались реквизиты. А при вводе слишком длинного емейла, падал весь сайт. И время в одном из полей, о существовании которого Нескажукак даже не знал, отображалось не в правильной часовой зоне…

Все эти ошибки казались сущими пустяками! Но руководство было в ярости, клиенты в шоке, пользователи недовольны.

К депрессирующему Нескажукаку пришёл тест-менеджер. И открыл список тестов. И нашёл там все эти мелкие проверки, которые казались такими неважными, потому и были пропущены.

Для начала, они вместе выпили. И только после этого тестировщик смог признаться: да, поток — это хорошо. Творчество в работе — тоже. Но нужно ещё что-то!

Что?

Я их обожаю!
4 ошибки, не считая стилистики — сразу захотелось купить!
http://www.microsoft.com/surface/ru-ru/surface-with-windows-8-pro/

А вы похвалили всех молодцов этой недели?

Оля написала провокационную статью, которую я не могу не прокомментировать

Автоматизация тестирования — это всегда попытка сэкономить ресурсы, или расширить покрытие за счёт запуска тестов с кучей параметров, или за счёт запусков на разных окружениях. Наше времея всегда ограничено, автоматизировать всё и вся мы не можем, а результаты тестов всегда приходится анализировать вручную, сколь бы хорошими и наглядными ни были ваши логи.

Итак, давайте рассмотрим пример:

У меня есть 2 теста, которые можно было бы автоматизировать. Оба требуют 2 часа для написания и отладки, а вручную оба проходятся за 20 минут. Оба важны и требуют прогонов каждый регрессионный цикл. В одном из них часто бывают баги, в другом — редко.

Если бы я гоняла тесты вручную и не автоматизировала, то у меня бы ушло 200 + 200 = 400 минут на 10-ти запусках. В таком случае, 1-й сценарий автоматизации НЕВЫГОДНЫЙ, а 2-й ВЫГОДНЫЙ.

Итого, мы приходим к следующему: при регрессионном тестировании, в автоматизацию выгодно отбирать наименее «бажные» тесты, чтобы по результатам их запусков не было необходимости в ручных дополнительных телодвижениях.

На днях разговаривала с одним новоиспечённым тест-менеджером. Она очень старательная девушка, впервые руководит командой, и хочет всё сделать хорошо. У неё сразу вопросы:
* где вести вики, чтобы ничего не потерять?
* где вести чек-листы?
* где вести данные по сотрудникам?
* где заводить не-баги?
….

В моей религии, правильный ответ на начале всегда одинаковый: гуглодоки! У меня они есть для всего и вся. Таблички с чек-листами, таблички с сотрудниками, списки по собеседованиям, ЧАВО, и т.д.

Почему так? Потому что сразу очень сложно понять, какой инструмент нужен. Можно долго внедрять, делать, продумывать, потом понять, что инструмент не очень подходит, возиться с ним, допиливать, переделывать… ууфффф!

Сначала всё нужно делать в гуглодоках, что бы вы ни делали. А когда уже есть понимание, каким оно должно стать — искать подходящий инструмент. Внедрять на первых днях работы таск-менеджеры, тест-менеджеры, CRM’ы и вики — не самое хорошее решение.

Во-первых, результат вы сразу не получите, т.к. потратите какое-то время на внедрение (а на начальных этапах важны минуты!)
Во-вторых, пока вы ещё плохо знаете, что именно нужно от инструмента. А когда понимаете, что уже «вырастаете» из гуглодоков — тогда у вас уже будет чёткое понимание, что нужно, и выбирать будете осознаннее.

Сорри за капитанство очевидность, но по опыту знаю, что многие делают не так

Я уже жаловалась, что мои самолёты всегда опаздывают.

Сижу, жду сильно задержанный рейс. Стало интересно, сколько рейсов по этому направлению уходят без задержек. Заметила 2 рейса.

Угадайте, почему они вылетели воремя?

Чуть позже выложу другой скриншот, не подсматривайте

В соответствии с проповедуемой мной религией, одно из самых главных качеств в тестировании — ответственность. Но не всегда понятно  - а что такое ответственность? И что делать, если «мне её не дают»? Не буду делиться банальностями, просто расскажу несколько историй из своего опыта. Read more

В чатике летней школы тестировщиков активная переписка, после которой работать совсем не получается.

Почти все прошлогодние выпускники приедут на школу (некоторые, кхе-кхе, там познакомились и теперь ехать отказываются: видите ли, у них свадьба!).

Новых участников тоже много. Идей, как мы будем с пользой и весело проводить время — ещё больше. Конкурсы и игры, развитие внимания, работа над психоэмоциональным состоянием тестировщиков… О Боже, у нас столько идей!

Я всегда знала, что тестировщики — самые креативные люди в мире!! Ура, часики, тикайте быстрее, школа, я хочу чтоб ты побыстрее началась!!

И если вдруг кто-то ещё может выкроить себе полторы недели полезного отпуска, с обучением и знакомствами с самыми яркими и креативными представителями нашей профессии — велкам! Вдруг, именно для вас ещё осталось местечко?