Как я и писал ранее «Примерно половина задач, от которых не прет программистов – весьма даже прет тестировщиков».
Александр проанализировал эту ситуацию и посвятил теме демотиваторов в области тестирования целый пост.
Я позволю себе так же прокомментировать каждую из задач.
Делать это я буду отдельными постами, потому что – я ленивый, писать большие посты – интернет отучил, да и мыслями собраться и продумать пример или вспомнить историю для каждой из предложенных задач стоит, пожалуй.
Задача №1. «Здесь не ступала нога разработчика…»
Часто, автоматизация невозможна, или очень сложна, и приходится ходить вручную по регрессионному набору. А из песни слова не выкинешь… Если есть тест-кейс – то уж будь любезен… И ходишь 25 билдов подряд по кейсам, которые к изменениям разработчиков не имеют отношения…
Иногда это необходимо, например в новом продукте, когда изменения могут приводить к неочевидным последствиям! Но чаще всего этот процесс можно оптимизировать!
Сразу небольшой дискляймер:
Когда выполняется глубокий анализ изменений в коде, когда у тестировщиков есть доступ к коду и когда регрессионные тесты прогоняются вручную – я не рассматриваю. Это для меня выглядит очень печально, но допускаю, что для этого есть весомые причины. Я их с удовольствием выслушаю в комментариях.
Случай, когда регрессионные тесты, одни и те же, релиз за релизом выявляют ошибки – я не берусь рассматривать, ибо это уже интересный повод для анализа, для разговоров с разработчиками. Это само по себе «некая движуха» и «некий экшин» которые могут быть интересны, т.к. это почему-то происходит. И это почему – один из главных вопросов, которые зрелый специалист задает себе.
Сложно оценить что такое регрессионное тестирование, не проведя сессии 2-3 таких испытаний. Здесь же сразу и знакомишься с парадоксом пестицида. Есть проблема скуки, и притом нет новых дефектов? Уважаемый тестировщик, а посмотри, так ли уж хороши регрессионные тесты?
Рассмотрим пример:
Есть у нас консоль, которая просит ввести два числа и сразу после второго числа выводит сумму введенных двух чисел. Мы знаем что в этом методе были сделаны изменения. Нам его надо протестировать.
Есть у нас старый добрый тест, который прогоняется уже три регрессии подряд:
- Ввести 120, нажать ввод.
- Ввести 5, нажать ввод.
- Ожидаемый результат: в третьем поле отображается сумма 125.
Не находит этот тест ошибок. Ну вот так вот – не находит. Хороший тест, правильный такой.
А теперь, во время тестирования, проверим такой вариант:
- Ввести 125, нажать ввод.
- Ввести 3, нажать ввод.
- Ожидаемый результат: в третьем поле отображается сумма 128.
Выполняем и видим на экране: -128
Обидно, правда?:)
Какой код это может вызывать?
Пожалуйста, пример консольного приложения для C# ниже (здесь показательна ошибка и то, что к ней ведет):
using System; namespace sum_mass { class Program { static void Main(string[] args) { sbyte Summ = 0; for (int i = 0; i < 2; i++) { int count = i+1; Console.WriteLine("Введите " + count + "-ое число"); Summ += sbyte.Parse(Console.ReadLine()); } Console.WriteLine("Сумма введенных чисел равна:" + Summ); Console.ReadKey(); } } }
Ошибка возникает из-за того, что для хранения суммы используется поле sbyte типа. Тип sbyte в C# может описывать значение от -128 до 127. И, при использовании значений больше или меньше этих чисел, мы «бегаем по кругу».
Почему это отловилось на этапе регрессионного тестирования? Хороший вопрос. Отличнейший. Но так бывает. И это повод пойти и пройти квест: «Менеджер, а что это такое и почему?».
В таком простом примере подобные исходы можно покрыть даже в регрессионном тестировании, но что будет если вместо простых чисел взять и оперировать бизнес-объектами?
Не появится ли множество вещей, которые можно проверять каждый раз по-разному, но следуя основной цели регрессионного тестирования – проверка уже протестированных участков программы на то, что ничего там не было сломано внесенными изменениями?
Здесь можно оставить свои комментарии. Выпуск подготовленплагином wordpress для subscribe.ru
Комментариев нет:
Отправить комментарий