Тестирование черного и белого ящика

Ссылка на youtube

Черный ящик (black box testing)

Тестирование черного ящика — это когда мы не знаем, как система устроена внутри. У нас нет доступа к коду или мы не умеем его читать. Поэтому ориентируемся только на внешнее поведение или ТЗ.

Это начинающий автомобилист. Заглянуть под капот? Ой, там слишком страшно, будем верить приборам и точка.

Это основной вид тестирования, с которого все начинают. Перед тем, как залезть в код, стоит научиться писать тесты на основе сценариев использования и знаний про тест-дизайн и классы эквивалентности.

Слушать нельзя указывать. Эдгар Г. Шейн

Ссылка на OZON

Честно говоря, своих денег не стоит, имхо. Есть более полезные книги на тему менеджмента или переговоров.

Начало очень неплохое. Автор рассказывает о том, как важно уметь задавать вопросы. И делать это правильно, а не абы как. Это меня воодушевило, так как в тестировании все то же самое. На моих курсах мы учим студентов задавать вопросы, но до совершенства еще ой как далеко!

Я даже хотела отдельный курс на эту тему делать, но вряд ли у тестировщиков он будет пользоваться спросом. В общем, мне стало очень интересно, как можно на эту тему целую книжку написать, пусть и небольшую!

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

Как поднимали тестирование с нуля в Dodo плюс Feature toogle Яндекса

Ссылка на youtube

Сложно дать название блог-посту, когда понравилось несколько докладов 
Мне кажется, название «Dodo Pizza QA Meetup» не раскрывает сути, так что получилось длинновато.

Не уверена, где именно был этот митап, вроде в Москве. Жаль, что не попала вживую, довольно интересно получилось! Ребята молодцы, что всех собрали и поделились своим опытом. Мне видео порекомендовал нам PM посмотреть, сказал, что интересно. Подтверждаю, интересно!

Основных доклада два:


Алиса в стране QA. Как мы меняли регресс, чтобы сделать его быстрым и качественным
Юлия Ковалева, DoDo

Прикольный рассказ! Юлия не стесняется говорить о тех проблемах, о которых предпочитают молчать. Когда отдельно есть команда разработчиков и аналитиков, и отдельно — команда QA, которая не ходит на митинги, планирования, и вообще не в теме того, что нынче важно для Заказчика. Кажется таким очевидным, что так быть не должно, но ведь так и есть. До сих пор, во многих компаниях. И вот им как раз этот доклад очень поможет.

Работа в HFLabs

Команда ЕК

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

Мы ищем людей:

• на внедрение (второго Никиту);
• на тестирование (вторую меня);
• на поддержку (а это нечто среднее ツ).

Список вакансий

Давайте я расскажу вам, что на работе делаю я. И что вообще значит «работать в ХФЛабс».

Ты сам решаешь, что делать

Приходя на работу, я выбираю задачи, которые буду делать сегодня. Конечно, есть список моих задач в релизе, но чем именно я буду заниматься сегодня, решаю сама. Хочу, пишу доку, хочу, автотесты делаю в ЕК, а хочу, в Факторе меппинги фигачу.

Конечно, так как я работаю на внедрениях и поддержке, мои планы могут измениться. Например, я хотела спокойно дописать автотесты на core-функционал, но приходит внедренец и говорит «Я тут поле новое добавил, хочу на PROD накатить, проверишь?». Или вдруг Заказчик пишет / звонит: «А у меня тут такое...». Конечно, отвлекаешься на задачи с большим приоритетом.

Но тут хорошо работает гибкий график, заказчики то обычно появляются часов в 10 утра, так что у меня есть свободное утро на поработать. Хотя есть у меня и заказчики в других часовых поясах, которые мне с 7 утра пишут. Знают, что могу ответить ツ

Какой идиот закрывал эту задачу? Ой...

Знаете, наверное, эту шуточку с баша?

xxx: Что за идиот написал этот код?
ххх: Ой, это ж я...

У нас есть чек-лист закрытия задачи, который писала я. Тестировщик:

1. проверяет вручную;
2. пишет автотесты;
3. пополняет документацию.

Иногда, конечно, автотест написать нельзя, или дока не нужна... Но чек-лист есть. Более того, я слежу за его выполнением: не написал доку? Reopen задачи. Так мы договорились еще на ретроспективе пару лет назад.

Сейчас у нас в команде есть три джуниора, им с этими пунктами бывает тяжело. Это я знаю проект, знаю доку, знаю, что и куда надо добавить. Они не всегда учитывают все места. Поэтому приходят консультироваться, или я дописываю в задачу «не забыть пополнить А и Б».

Так вот. Сегодня приходит мне вопрос от заказчика. Я иду в документацию, а документации на эту тему нет, только описание CR. Иду посмотреть в автотесты, а их тоже нет. Кто же, блин, закрывал эту задачу то, а? 

Копирую название CR, вставляю в JIRA... Хотя меня уже начинают терзать догадки, ведь это мой заказчик... Таки да! Задачу закрывала я. Проверила вручную. Тестов не делала, доку тоже. Утешает лишь то, что это было 4 года назад ツ 

Молодая была, зеленая... Пойду исправляться!

Fail test не должен прерывать сборку

Не отменяй меня!!

Этот пост прям накипел ツ

Сейчас читаю книгу «Непрерывное развертывание ПО» и там прочитала такой лайфхак:

Неуспешные тесты не должны отменять сборку. В некоторых системах настроено автоматом так, что при неудаче какой-то задачи сборка немедленно завершается. Это почти всегда плохое решение. Если процесс не прерывать, а только отмечать неудачу, то в конце мы увидим, какие задачи провалились. 

Проблема возникает вследствие того, что в проектах обычно выполняется много тестовых задач. Например, в тесте фиксации могут присутствовать набор модульных тестов, интеграционные тесты и предварительные дымовые. Если неудача любого завершит сборку, вы не узнаете результатов интеграционных тестов вплоть до следующей регистрации.

Итоги 2017 года

С прошедшим новым годом!

Не уверена, что это какая-то особая, волшебная черта, после которой ты резко займешься спортом, похудеешь, начнешь уделять больше времени семье, учебе, работе... Если хочешь что-то изменить, начинай сегодня, сейчас. Не завтра и не в понедельник.

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

Как пример: мои итоги 2016 года

Давайте, я начну, а вы подтягивайтесь =)

Итоги 2017

Работа

Что вспоминается по работе за год? Конечно, в первую очередь последние достижения — мы закрыли первую фазу проекта на 100 млн данных, причем сделали все в сжатые сроки и даже выполнив больше работы, чем изначально хотели! Приятно поучаствовать в таких проектах, сразу чувствуешь, что ты тоже не просто "так, офисный сотрудник", а что-то делаешь ツ

Еще у нас увеличился штат сотрудников. В нашей команде новый РМ, два аналитика и один тестировщик. Или два? Лере там годик то стукнул уже али как? В общем, команда растет и тут сразу несколько выводов:

• Можно гордиться тем, что двое из новичков — мои выпускники. точнее, выпускницы. (см «Поздравляем Таню с окончанием испытательного срока!»)
• У нас в этом году появилось мощное внутреннее обучение (а что делать, три новичка в команде), растет и развивается. Надеюсь, не заглохнет. Вообще обучение внутри команды — это очень круто!

А в рамках проекта «12 недель» я думала-думала и придумала себе такую фишку по работе: выписывать в блог что-то с работы. Один пост в неделю — что-то рабочее. Может, что-то полезное, или смешное, или просто случай из жизни... Кстати, отличная тема! На работу сразу по другому смотришь, ведь есть цель, найти что-то клевое, о чем можно рассказать. А кто ищет — тот найдет! Стараюсь и сейчас придерживаться этого правила.

Мой статьи с работы:

Панбагон. Дата записи к врачу undefined

Мне надо записаться ко врачу, зрение проверить. Идем на портал https://www.mos.ru/services/catalog/popular/, выбираем врача, смотрим на свободное время. Видим такую картинку

undefined в дате

Дату написать осилил, месяц (или что там рядом должно стоять?) нет...
Простенький баг, но давайте потренируемся оформлять по шаблону:

Квартальный календарь тестировщика 2018

Я тут себе квартальный календарик смастрячила, вот, делюсь ツ

Ссылки для скачивания

Новый календарь, как на картинке выше
Старый календарь, но с 2018 годом

Наша газета. Все выпуски 2017 года

Спортивный ХФЛабс!

См также:
Наша газета. Все выпуски 2016 года

В 2016 году мы завели свою собственную газету внутри офиса. Мы там пишем, что вообще происходило на неделе, а потом кто-то делает газету. В этом году кто ее только не делал — и Костя, и Лена, и Таня, и я (точнее, моя художница).

И все равно газет получилоь маловато... Сложный был год! Некогда всякими там газетами заниматься было, работу работали ツ. Но кое-что сделали, вот, зацените!

Мозг с препятствиями. 7 скрытых барьеров, которые мешают вам достигать целей

Ссылка на OZON
Мои заметки по книге — Предвзятость подтверждения.

Книга о том, что мешает нам достигать успеха. Вообще неплохая книга! Все четенько и по делу, изложено достаточно интересно. Структура книги четкая:

• Описание барьера;
• История из жизни, где он помешал;
• Как заметить;
• Скрытый подвох барьера;
• Побочные эффекты;
• Стратегии решения.

Всегда знаешь, что ожидать дальше и когда примерно закончится глава ツ

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

Так вот, о каких преградах рассказывает автор. Я буду в вольном переводе, чтобы не нарушать авторство:

1. Сомнение в себе.

Ах, я не смогу. У меня ничего не получится, поэтому не стоит даже начинать, не стоит даже пытаться!

Предвзятость подтверждения

Человеку хочется, чтобы его теории были правильными. Если мы уже составили мнение, то всеми силами пытаемся его защитить. Это такая ментальная ловушка, мы не замечаем вещей, которые опровергают теорию. То есть факты рассматриваем, но выборочно.

Про это название, «предвзятость подтверждения», я прочитала в книге «Мозг с препятствиями». Но слышала о ловушке уже давно. И видела ее тоже давно. Отлично проявляется при локализации багов, явно видно на новичках (студентах).

Например, сломалась регистрация через соцсети. Студент пробует через ВК — сломалось! Пробует через фб — сломалось! Ну все, можно ставить блокер-баг, регистрация вообще никакая не доступна, кошмар, все пропало. А на деле простая регистрация, по емейл, работает. И через нее регистрируются 99% пользователей (да да, не всегда люди предпочитают соцсети).

Или проверяет исправление опечаток — не исправилось! Ой! Пробует еще пару вариантов — не работает. Значит, опечатки в принчипе не исправляются. А на самом деле исправляются, но не все, что вполне логично.

Или адрес не распознался. Попробовали соседний дом — не работает. Ну все, вся Москва не работает ツ А на самом деле конкретная улица или конкретный район.

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

Но именно это отличает хорошего тестировщика от новичка: умение подвергнуть свою теорию сомнению и попробовать ее опровергнуть.

• Если не получилось — ну круто, ты исходно был прав. 
• Если получилось —  надо строить новую теорию, а не закрывать глаза на «плохой» факт.

Вот, как-то так =)