Завязался у меня диалог с коллегой. Коллега пишет, что можно тестировать и без тест кейсов. И что качественного тестирования можно добиться без них. На тест-кейсы нужно время тратить, а лучше бы его потратить на вдумчивое тестирование без них. Аргументы, которые я выделила из диалога с коллегой:
· нужно тратить время на написание тест-кейсов
· само тестирование по кейсам проходит не вдумчиво, ну а если и вдумчиво проходит, то зачем думать 2 раза при написании кейсов и потом еще при тестировании по кейсам.
Итак, мои аргументы и рабочие ситуации, когда конкретно мне помогают тест-кейсы.
1) Что ответить самой себе на вопрос: все ли я проверила?
Это заключение будет субъективным суждением, основанным на моих ощущениях и чувствах. И никаких подтверждений не будет. Можно доверять чьим-то личным суждениям, основанным на ощущениях? Я не доверяю. В моей практике были плачевные случаи, когда тестирование строилось на филингах (ощущениях). Только конкретные цифры позволяют судить все ли сделано.
2) Как не сбиться и точно помнить, что проверено в ходе тестирования, а что нет, если во время выполнения тест-кейсов:
· звонит коллега по работе с вопросом,
· начался митинг,
· закончился рабочий день,
· тестировщик пошел обедать, в туалет и много куда еще)
Мы все люди, в течении рабочего дня есть и регулярные митинги, и стихийные, когда просто коллега звонит и просит что-то показать. И в конце концов, я человек, который имеет ряд потребностей. Ну и рабочий день мой не бесконечен. Когда есть хотя бы чек лист, можно отметить где тестирование было прервано, и потом продолжить с того места. Как вспомнить и не делать двойную работу, если кейсов нет? Не понятно.
3) Что ответить начальству на вопрос: все ли протестировано?
То же самое, что и пункт 1: это заключение будет субъективным суждением, основанным на моих ощущениях и чувствах. И никаких подтверждений не будет. Можно доверять чьим-то личным суждениям, основанным на ощущениях? Я не доверяю. В моей практике были плачевные случаи, когда тестирование строилось на филингах (ощущениях). Только конкретные цифры позволяют судить все ли сделано.
4) Как сделать заключение о том, на сколько качественно сделана сторя?
Если результаты пройденных тест-кейсов входят в критерии качества задач, как ответить на этот вопрос?
5) Как проводить смоук для тасок типа рефакторинг (тех долг, и много разного рода тех задач)
Рефакторинг, тех таски - довольно частый тип задач в любом проекте. Девелопер с точки зрения бизнес логики не вносит никаких изменений, но есть изменения в коде. Как выделить смоук и проверить все работает или нет? Опять анализировать прошлые задачи и опять же, опираться на свои филинги при заключении, что смоук был проведен? Это опять субъективное суждение ничем не подтвержденное.
6) Как проводить регрессию перед релизом?
Релизы бывают разной частоты: где-то раз в год, где-то раз в полгода, а где-то раз в месяц и чаще. Как для релизов проводить регрессию? Перечитывать требования и каждое требование тестировать как в первый раз? Как сделать заключение, что регрессия прошла успешно и ее результаты достаточны, чтобы выходить в прод? Опять субъективные суждения?
7) Что ответить в случае бага с прода? Был ли этот кейс протестирован?
Никак не ответить на этот вопрос, потому что нет никаких подтверждений, что вообще хоть что-то было протестировано.
8) Если нужны документы для выхода в прод. Поддержка SDLC процессов.
Ряд компаний имеет свои стандарты по выходу в прод, и частенько нужно готовить пакет документов, который включает и пройденные тест-кейсы в том числе. Без тест-кейсов предоставлять будет нечего.
9) Как будет организована автоматизация? По каким кейсам или чему?
Это прямо открытый вопрос. Как должна работать автоматизация без тест-кейсов? Даже не знаю, что и комментировать тут.
Как понять, а что же было заавтомачено? Какие кейсы покрыты? В каком объеме?
10) Если приходит новый член команды: а) первые задачи, которые даются человеку это потестить по уже написанным кейсам, чтобы человек вошел в курс дела. б) как новый член команды осилит смоук и регрессию?
Стандартная техника онбординга новых людей: дать на тестирование либо регрессионные тесты, либо дать свеженаписанные кейсы на тестирование.
И как новый, неопытный тестировщик, справится с задачами проведения смоука, регрессии?
11) Если тестеровщик уходит в другой проект, другую компанию как передавать знания? Что делать новому человеку?
Тут комментировать нечего. Новому человеку придется просто перечитывать все предыдущие задачи, чтобы хоть как-то въехать в проект
12) Если на какое либо тестирование, в силу разных обстоятельств, зовут на помощь аналитиков, девелоперов, других членов команды, как они будут тестировать?
Такие кейсы бывают, и порой коллеги приходят на помощь. Гораздо проще, когда есть кейсы и люди просто по ним идут и все. Если кейсов нет, то хз какая помощь в итоге получится.
13) Если ПО сложное( разработка лекарств, проведение анализов) и для тестирования требуется тест дата, то куда ее складывать? Генерить тест дату и никуда не положить? И потом при последующем тестировании вспоминать и анализировать задачу опять и генерить новую тест дату?
Очень трудозатратно генерить тест дату каждый раз, когда нужно протестировать задачу. Гораздо проще, когда есть тест-кейсы, к ним прикреплена тест дата.
14) Если ПО сложное (разработка лекарств, проведение анализов) и один кейс занимает полчаса. Как самому помнить, что ты уже сделал, что делаешь сейчас, и что осталось проверить?
15) Если тестировщик ушел внезапно на больничный, как другой человек поймет, где остановился другой тестировщик?
У меня был конкретный случай, и не раз, когда человек уходил на больничный, а работа была сделана на половину. И нужно было продолжить тестирование другому человека. Как это делать без кейсов? Опять тратить время на разбор другому человеку.
16) Сможет ли человек спустя время вспомнить о чем была задача и протестировать ее смоуком?
Это вообще сомнительная история. В общем можно помнить о чем задача, но детали помнить мало кто будет. Опять читать и анализировать старые задачи.
17) Как новый человек сможет тестировать задачи, если ПО сложное, и нужно как-то по особенному готовить тест дату, либо приводить систему в определенное состояние?
Я порой по плохо написанным кейсам не могу пройти. Потому что системы порой такие сложные, что вообще не очевидно и не понятно, как создать тест дату или как привести систему в определенное состояние. И супер не эффективно тратиться время на поиск этой инфы.