История одного бага

Краткое введение.

Не так давно запустили новый интернет магазин покупки продуктов. Проект писался с нуля. Не практически с нуля, а именно с нуля. Набрали отдел аналитиков, тестировщиков и программистов. Вроде что тут такого интернет магазин? Их очень много. Нет их просто до до сраки много в интернете. Но данный проект отличался некоторыми сложностями. Например, помимо витрины магазина (несмотря на то, что я давно работаю в тестировании слово витрина для меня было новое, и поэтому для таких как я - витрина это то, что видит конечный пользователь) необходимо было сделать бек офис, систему склада, приложение для терминала курьера и еще кучу софта для персонала. Всего порядка 5 систем. Было много разнообразных дефектов. Но самый интересный я опишу ниже.

Непонятный дефект

Для начала мы решили запустится на очень узкую аудиторию, а конкретнее только внутри компании. Компания большая. В нашей столице более 2000 человек. Отестировали, выкатили. С учетом того, что у нас было всего 3 тестировщика (напоминаю, всего 5 систем)  до идеала было далеко. Сама история...

День 1

В 22:37 получаю письмо от технического директора, что кнопка "положить в корзину" не работает. Звучит довольно странно... Данный функционал покрыт тестами. Вручную проверялся неоднократно. Проверяю вручную еще раз. Все работает!!! С учетом того, что проект был на старте, фиксов довольно много просим почистить кэш и на этом успокаиваемся.

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

День 2

Техдир продолжает утверждать, что у него до сих пор с ноутбука не работает кнопка положить в корзину. Все предварительные процедуры по чистке выполнены. Посмеялись... Проверили еще раз.  Но звучало довольно странно. Пытаемся повторить данный дефект уже умами всего отдела + нескольких разработчиков. Все в порядке. Смотрим в отчеты Allure. Тоже все прекрасно. 

День 3

Шеф начинает покалывать, что все равно ничего не работает. Предложил принести ноутбук. Мы соглашаемся (ну как бы глупо было отказываться).

День 4 - Развязка

Ура. Ноутбук у нас. Начинаем смотреть... Нажимаем на кнопку добавить в корзину - реакция 0 ампер. Смотрим в разных браузерах. 

• Firefox - ок.
• Chrome - fail.
• IE - ок.

Какие могут быть варианты? 

• Старая версия - не подтвердилась
• Левые плагины - не подтвердилась
• Выключили антивирус (это была последняя надежда) - и.. ну не работает кнопка.

Подключили всех. Кто-то заметил, что экран сенсорный. Шутки ради решили нажать пальцем на кнопку положить в корзину. Вауля! Товар в корзине. Мышкой не получается, тыкая по экрану получается. Посмеялись (реально смешно было). Оказалось, что javascript определял тип устройства и отрабатывал по разному для тач устройств и для обычных. А здесь попался трансформер. Баг исправлен, но было очень познавательно.

Регистрация и Email ы, партнерские сети

Совсем недавно прочитал статью по поводу проверки регистрации не прибегая к новым почтовым ящикам. Идея состоит в том что если у меня ящик test@test.ru, то прибегая к простому + n где n целое число - можно по факту регистрировать новых пользователей на один и тот же ящик. Что это фитча или баг?

 Но есть одно большое НО. Многие компании для увеличения аудитории своих сайтов - прибегают к помощи партнерских сетей. Выставляя за оплату например регистрацию  в своем сервисе, магазине, онлайн игре. Не важно. Регистрация так регистрация. Запускаем регистрацию - прибавляя в конце своего адреса + i делая это в цикле.
 Конечно я утрирую и это легко все вычислить и дать по шапке тому кто это делает. Но зачем доводить до такого? Если можно просто проверку на уровне разработки.
Если кто то не верит может проверить в принципе на любой онлайн игре или сервисе.

Можно убедится на примерах.

Сервис

Онлайн игра

Мое мнение - это баг. Баг о котором знают многие. Но почему то не хотят исправлять, ссылаясь на то что это фитча.
  

Автоматизация багов. Быть или не быть?

Всем добрый день!
Писатель из меня, мягко говоря не очень. Но все таки решил поделиться своими мыслями. Не судите строго)

Любая компания хочет постоянно улучшать свой продукт. Где-то функцию новую добавить, где то изменить логику старой. И вот буквально через год, из маленькой "системки", написанной на php, вырастает огромный ресурс с кучей интегрированных систем.
И вот тут должны появиться тестировщики.  При чем они должны сразу включиться в работу! И не только найти новые баги, но и не дать повториться старым.

Я убежден на 99%, что тестировщики - это люди. И как все люди,  они могут что-то забыть протестировать. Не буду спорить - это плохо. Но к нашему счастью у нас есть инструменты для автоматизированного тестирования, которые сокращают время тестирования и помогают протестировать те вещи, про которые забыли...

Наверняка, когда пишите тесты - то многие методы используете довольно часто. Например: зайти в систему, проверить на ошибки страницу, кликнуть на кнопку создать и так далее и тому подобное. Т.е. набор тестов проверяет самые стандартные вещи. Наши тесты через какое то время стали проходить на УРА! Я придерживаюсь мнения: "Нет систем без багов. Есть плохо протестированные".Решил посмотреть трекер проекта... И увидел, что наши тесты  не находят самые тривиальные баги, которые могли бы найти, стоило бы их чуток поменять. Можно конечно говорить о том, что тесты должны писаться по тест кейсами тест планам. Это совершенно правильно! Но садится и быстро писать тест кейсы и тест планы - это слишком долго, а ждать качества никто не будет. Нет ТЗ на доработки, нет тест планов, нет обдуманных автотестов. Но качество в срок нужно...

Мы стали автоматизировать баги. Процесс поставлен следующим образом:
1) Ручник находит баг и отдает его автоматизатору.
2) Автоматизатор вместе с ручником оценивают стоит ли автоматизировать его (зачастую случается, что баг мелкий и не критичный, но для его атоматизации требуется много времени)
3) Смотрят: мог ли баг проявится еще в каком либо месте.
4) Пишем тесты на баг. Пока тесты не проходят - баг не исправлен.


P.S. Что мне это дало?  

       

Из плюсов

• При выкладке на бой, после прохождения стандартных тестов + тестов на баги - я довольно комфортно себя чувствую. Сразу видно, что программисты забыли выкатить, где не прописали.
• Эффект пестицида сразу исчез)
• Повышает квалификацию в автотестах
• Пропускается гораздо меньше багов и продукт качественнее
• Как ни странно, программисты остались довольны от такого нововведения, хотя процесс далек от совершенства

Из минусов

• Тесты нужно поддерживать. Если компания динамично развивается, то нужно иметь 3-4 "авто - человека"
• Иногда это нерационально. Баг копеечный, а времени ка автоматизацию уходит масса
• Лишние тесты нужно исключать. Представьте, что будет через год? 1000 тестов? Да они будут проходить только рабочий день.

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

Вопросы для собеседования тестировщиков

Добрый день Всем!

Работаю на протяжении года в развивающейся фирме. Отдел тестирования вырос с одного человека до 5. И продолжает расти. Собеседований было куча! Вопросы естественно одни и те же. Не думаю что для кого то я открою Америку, но я для себя отметил следующие критерии для поиска людей.

ТТ - теория тестирования. Здесь я кандидата спрашиваю - что такое тестирование в целом, какие виды тестирования он знает. И так далее.
АТ - автоматизация тестирования. Здесь могут быть тестовые задачи на написание кода на каком либо языке (предпочтительно JAVA). Чаще всего написать авто тест для логина в приложение.
SQL - здесь избитая задача на соединение двух таблиц и вывода информации из них.
ТП -  умение писать тест -кейсы или тест планы. Чаще всего прошу придумать сценарии для тестирования калькулятора. Заметил интересную штуку. Когда спрашиваю, что должно быть в результате деления на 0 - 4 человека из 10 говорят 0, 2 человека говорят, что должно получится число которое делят. И только 4 человека говорят фразу на ноль делить нельзя. 
ЛГ - задача на логику + даю несколько скриншотов, которые содержат один или несколько багов.

А что вы спрашиваете на собеседованиях?

Нагрузочное тестирование и Selenium

  Приходит ко мне программист и говорит: "Можешь ли ты сделать нагрузочный тест", но такой, что если будут какие то ошибки, то писать их в лог. А еще хотелось бы что бы твой тест, который уже есть прошли одновременно несколько пользователей.  

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

Я хочу показать свою реализацию, которая, возможно, многим автоматизаторам и программистам покажется глупой и нелепой. Но для тех кто не сталкивался может помочь.

Прочитав статью я приступил. 

Создал класс  Load. 

public class Load extends Thread{

 test t = new test();

 public void run() {

 try {                                                                                            

            try {

                t.setUp();

                t.test();

                t.tearDown();

            } catch (Exception ex) {

                Logger.getLogger(Load.class.getName()).log(Level.SEVERE, null, ex);

            }

           Thread.sleep(400);

        } catch (InterruptedException ex) {

            Logger.getLogger(Load.class.getName()).log(Level.SEVERE, null, ex);

     }

  }

}

Затем в main создал массив объектов Load 

 Load ld[] = new Load[50];

А далее грузите как хотите

 for (int k=1;k<=50;k++){

     ld[k] = new Load();

     try{

     ld[k].start();

     }

Результат данного теста можно было наблюдать только на сервере (слушатели и вывод я не писал). 

Более подробно и грамотно  нагрузочное тестирование с помощью Selenium рассматривается тут

Тестировщик - это врач диагност в IT?

Сейчас очень модны медицинские сериалы. Доктор Хаус, Клиника, Женский доктор,  Интерны, Склифософский и еще куча подобных сериалов. Работая в IT области, я решил сопоставить  медицину и IT. Если говорить конкретно, то к какой области медицины можно отнести непосредственно тестирование.  Не будем ходить вокруг на около, а вспомним книгу  Сема Канера "Тестирование программного обеспечения. "Представьте, что с вашим здоровьем что-то не в порядке. Вы приходите к врачу, и он проводит целый ряд анализов. Однако врач ничего не находит — он утверждает, что вы здоровы. Хороший ли он диагност? Если вы в самом деле больны, остается признать, что врач некомпетентен, а дорогостоящие анализы были пустой тратой сил, времени и денег. При тестиро­вании диагност — это вы, а программа (абсолютно наверняка) — больной пациент. Так найдите же, что с ней не так!

Давайте выясним, действительно ли это так?

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

Анализируем.

1) Программа = пациент - я думаю с этим можно согласится, за исключением того, что человеческий организм в большинстве своем имеет одинаковое строение, в отличие от тестируемых программ.

2) Описание дефекта = это по сути симптомы. Тоже вынужден согласится с этим определением, более того при желании можно сделать классификацию этих дефектов.

3) ???? = Диагноз. Что есть диагноз? Очень интересный вопрос. Я пришел первый раз в кампанию, нашел свой первый баг, при этом видя программу чуть ли не первый раз! Как я могу поставить конкретную причину бага? 

Тут можно поспорить... Есть логи, есть debug, которым тетстировщик, в идеале должен уметь пользоваться. Т.е. по сути это те же инструменты, которые есть у врача для проведения анализов и выявления точного заболевания. К чему я написал кучу непонятного текста? К тому, что тестировщик в состоянии поставить конкретную причину бага. Т.е. ???? = Причина бага.

Другой вопрос на сколько быстро инженер по тестированию определит причину бага. Тут опыт работы с конкретным проектом, и опыт работы с инструментами.

Подобно врачу, тестировщик должен смотреть на симптомы бага, так же как врач смотрит  на симптомы человека. Если этих симптомов не достаточно, то врач назначает анализы, а тестировщик использует дополнительные инструменты. Тестировщик должен изучать проект, что бы знать его досконально. Представьте себе врача, который не знает, из чего состоит человек? Страшно да?  А теперь тестировщика, который не знает проект?  Не так страшно, особенно когда вы его только взяли на работу. Но если через 2 – 3 месяца  не знает, как работает функционал – это вызывает вопросы, и за тестирование становится уже страшно.  

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