Основы тестирования: 20 принципов новичка / Хабр

20 принципов новичка / Хабр

Все началось на офисной кухне со спора, который разгорелся между мной, менеджером по бизнес-процессам и рискам и моим коллегой из отдела технического сопровождения продаж. На тот момент он обучался на полуторагодичных курсах основ программирования в местном институте информационных технологий, а я просто анализировала процессы, просчитывала риски, обосновывала предложения по покупке софта. Он сидел напротив и рассказывал, как сложно учиться, как туго даются ему предметы и как он готов отчислиться, заплатив 50 с лишним тысяч. Я не знаю, что мне налили вместо чая, но я уверено и грубо сказала: «Знаешь, я тоже пойду с октября и ты увидишь, что мое полУтехническое образование и возраст 27 лет не помеха для освоения всего этого». Он покрутил у виска…
Не буду рассказывать про трудности обучения и успешной защиты своего полноценного, но весьма тривиального программного проекта на английском языке, а расскажу о последствиях моей учебы. В конце обучения я поняла, что работа мне поднадоела и хочется чего-то совершенно другого. Как известно, иногда мечты сбываются и нам предложили пройти трехмесячную стажировку в должности инженеров по тестированию с неплохим окладом в одной большой айтишной конторе. Нормальные люди отказались…

…а я решилась и проработала там почти год. Этот год стал для меня годом роста, прогресса, развития и новых, интереснейших открытий в IT- сфере. Сегодня я работаю в другом, не менее IT-шном месте, а опыт остался. И хочется им поделиться. На Хабре много статей про тестирование, про покрытие кода тестами, про автоматизацию и очень мало информации для новичков, которые только приходят в тестирование и очень хотят работать достойно и тоже дожить до написания автотестов и утилит. Для них я и изложу 20 принципов, которые мне удалось вынести из работы и которые позволили стать одним из лидеров команды в кратчайшие сроки.

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

2. Узнайте, кто ваш клиент или конечный пользователь. Сами станьте конечным пользователем. Не забывайте, что софтом могут пользоваться люди, абсолютно далекие от IT и стиль работы у них совершенно иной. Проверьте, что может менять сам пользователь, какие права доступа можно устанавливать и что в теории с этими правами можно сломать в программе.

3. Составьте карту устройств, с которыми может взаимодействовать софт, переберите сочетания этих устройств. Очевидно, что сегодня софт может работать на множестве устройств, работающих под различными операционными системами, с разными разрешениями экранов, системами органов управления и проч… Составьте для себя карту устройств, на которых запускается ваш софт, пропишите основные технические характеристики, продумайте возможные комбинации работы железа и ПО. Это значительно облегчит работу.

4. Разбейте программу на части. Мелочей не бывает. Изучите программу досконально: от кнопки выхода до самой последней функции. Вы должны знать принципы и зависимости работы всех связанных модулей, это тестирование окружения, которое позволяет выявлять огромное количество багов, которые при пропуске непременно становятся клиентскими. Например, был случай, что одна из версий программы не отзывалась на кнопку выхода, а закрывалась только крестиком. Баг был пропущен и вернулся с клиентским кейсом.

5. Узнайте о видах тестирования. Тут коллеги, книги и Википедия вам в помощь. Есть функциональное, регрессионное, санити, нагрузочное и проч. тестирование. Рано или поздно вы коснетесь всех видов и оцените преимущества каждого, поэтому знание принципов и секретов, накопленных предыдущими поколениями, не помешает.

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

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

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

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

10. Следите за логами, если они есть. Строго обязательно собирайте любые логи, которые умеет записывать тестируемая программа. Это необязательно многостраничные логи в консоли, это могут быть зависшие страницы в web, окна ошибок, строки с кодом ошибки. Если нет возможности скопировать или выгрузить информацию, делайте скриншот. Всю полученную информацию оформляйте в кейсе в виде вложений — разработчикам не придется узнавать у вас, что за окошко выпало. К тому же, если баг не воспроизводится, наличие скриншота или лога с падением — повод завести обоснованный кейс.

11. Мыслите широко. Помните о том, что ваш софт не живет своей жизнью в вакууме на отдельном чистом компьютере или гаджете и изучайте конкурентов, если это возможно. Вероятно, что-то неочевидное и примылившееся станет вам виднее со стороны после изучения чужого функционала. А может, вы просто сможете предложить реализовать дельную фичу.

12. Советуйтесь с коллегами: тестерами, разработчиками и менеджерами. Они — авторы, источники пользовательского и профессионального опыта. Если не знаете что-то специфичное (например, настройки оборудования), то лучше спросить у коллег, чем у Google – они это делали неоднократно и обязательно помогут. Поверьте, может быть хуже, если, например, ваше неправильно настроенное оборудование внезапно всем раздаст новые айпишники по DHCP.

13. Изучайте новые возможности тестирования. Читайте книги, сообщества (тот же Хабр), не останавливайтесь в своем развитии, пытайтесь писать простейшие скрипты, узнайте больше об автоматизации тестирования.

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

15. Если можно создать нагрузку — создайте ее. Под нагрузкой понимаются не только, к примеру, массовые звонки или присоединения, но и ситуации с большим количеством данных, несколькими пользователями и т.д… Попросите помочь коллег. Заведите больше тестовых данных, добавьте мультимедиа, если это нужно. Обратитесь к менеджерам — весьма вероятно, что у них есть ненужные тестовые клиентские данные, на которых можно протестировать софт в условиях, максимально приближенных к рабочим.

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

17. Изучайте и проверяйте документацию. Документация — это часть софта, которую тоже тестируют. Если вам не попался такой кейс, не радуйтесь, а, напротив, обязательно прочитайте ее — там вы увидите новые возможности работыы с софтом, а, возможно, встретите несоотвествия или откровенные ошибки.

18. Передавайте опыт. Так уж устроены отделы тестирования, что в них часто меняются люди. Обязательно помогите новому человеку: объясняя какой-то вопрос, вы не только закрепите свои знания, но еще и увидите решение, которое было близко, но не находилось.

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

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

Инженеров по тестированию, тестеров, тестировщиков часто высмеивают, пародируют, сочиняют про нас демотиваторы и айтишные анекдоты. Значит, они нужны. Для стабильности работы программ, выпуска успешных релизов, отсутствия недовольства клиентов. Настоящий тестер никогда не отойдет в сторону от проблемы, он — часть команды и не важно, какой: модного agile или старой функциональной иерархии.

Тестирование — это знания, ответственность и немного удачи. Так что удачи!

Как научиться тестировать ПО

Оригинальная публикация

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

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

Нужна ли тестировщику база в ИТ?

Откровенно скажем, желательна.

Большинство наших специалистов в той или иной форме увлекались ИТ с детства или как минимум учились в профильных вузах, т.е. уже имели какую-то базовую подготовку еще до прихода в тестирование. Часть из них начинали как разработчики (учились на разработчика) — отдельные “тестовые” направления еще лет 10 назад отсутствовали. Так что у нас перед глазами просто нет “антипримера” такого пути.

Сейчас в ИТ действительно много тех, кто такую подготовку не проходил. И им немного сложнее двигаться вперед. Чтобы справиться с задачами в тестировании, необходимо как минимум уметь поставить операционку, понимать, как развернуть тестовое приложение и необходимое окружение, как создать репозиторий в Git, погуглить ответы на свои вопросы, покопаться на специализированных ресурсах вроде Stackoverflow. По сути это и обеспечивает общая база по информатике.

Но и эти знания вполне можно освоить по книгам или курсам в интернете. Сегодня недостатка в источниках информации нет. Главное, чтобы была заинтересованность и время, которое можно на это выделить.

В тестировщики или в разработчики?

Тестирование тестированию рознь.

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

Автоматизатор тестирования уже ближе к разработчику. В базе знаний у каждого автоматизатора обычно значится как минимум один язык программирования — тот, на котором ведется разработка автотестов (это не всегда основной язык разработки на проекте). Занимаясь автоматизацией, также важно знать шаблоны проектирования и уметь применять общие принципы разработки — расширяемость, читаемость, легкость переиспользования. По сути автотест — это та же программа, которая должна соответствовать заранее заданному сценарию.

Чтобы начать работать автоматизатором, помимо знаний о тестировании в целом, необходимо иметь минимальные знания в объектно-ориентированном программировании, представлять, как написать простейший “Hello World!”.

Выбирая направление, вряд ли стоит смотреть на сиюминутную популярность специалистов на рынке труда. Средние показатели спроса и зарплат в ИТ — вещь очень специфическая, они зависят в том числе и от смежных знаний. Кто бы мог подумать, но специалисты по разработке на каком-нибудь Delphi сейчас в банковском секторе востребованы, несмотря на то, что в других отраслях язык не пользуется вообще никаким спросом. Здесь все работает по законам рынка: специалистов мало, а спрос на них остался, поскольку кому-то же надо поддерживать легаси.

Так и в тестировании. Сейчас есть спрос на JS-автоматизаторов. Он велик, потому что запросы у бизнеса большие, но еще не успели выучиться те люди, которые встали на данный путь с первым появлением интереса рынка. Как только они выучатся и пойдут работать, ситуация может измениться.

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

Что почитать?

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

Однако одну книгу наш отдел тестирования рекомендовал почти единогласно — “Тестирование Дот Ком” Романа Савина. Это самая известная книга по теме, которая просто и доступно вводит в курс основных понятий и процессов в ручном тестировании. И хотя она издана довольно давно, базовые знания, изложенные в ней, до сих пор актуальны. Пожалуй, ее читали процентов 80 всех тестировщиков в странах СНГ.

Другие рекомендации легко найти в распространенных в интернете “списках N книг для начинающего тестировщика”. Но в целом наша команда тестирования считает, что базы из книги Романа Савина будет достаточно для запуска дальнейшего процесса самообразования.

Стоит ли идти на курсы, тем более платные?

Мнение о курсах у наших специалистов неоднозначное.

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

Идти на курсы можно с одной из двух целей — либо закрыть какие-то пробелы в знаниях, либо закрепить уже известную информацию. В зависимости от целей усваиваться все будет по-разному. Но из-за обилия новых знаний осядет далеко не 100% полученной информации. С этой точки зрения самостоятельное обучение на конкретном проекте полезнее. Собранные сведения или найденный ответ точно задержатся в голове. Правда, на это уйдет немного больше времени.

Не все стены стоит пробивать своим лбом. И правильный баланс, где стоит послушать лектора на курсах, а где — попробовать что-то выучить самостоятельно, каждый определяет для себя сам. Этот баланс есть и в любой другой сфере: наверняка вы про себя уже знаете, легче вам учиться самостоятельно или слушать преподавателя.

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

Курсы, упомянутые в негативном ключе, мы здесь приводить не будем. Все зарабатывают, как могут, и профессиональное образование — это такой же бизнес, как и все остальное. Поэтому прежде чем платить кому-то деньги за освоение профессии, стоит потратить время на исследование рынка.

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

Хорошие курсы должны подразумевать не просто рассылку видеозаписей с последующем сбором домашнего задания. Необходима нормальная обратная связь с преподавателем или наставником, который объяснит, в чем ошибка, в каком направлении стоит двигаться, чтобы правильно решить поставленную задачу. А видеоролики можно посмотреть и бесплатно (а потом и задачки из интернета порешать).

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

Стоит ли ездить на конференции?

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

На некоторых конференциях можно встретить “базовые” доклады, позволяющие почерпнуть начальные знания в новом для себя сегменте, например в автоматизации. Но чаще это, конечно, информация для более опытных специалистов. В целом конференция — это, скорее, место для нетворкинга и получения смежных знаний (рядом со своей текущей специализацией, например на другом языке).

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

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

Где взять первый опыт?

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

В реальном проекте обучение пойдет гораздо эффективнее. Будут возникать конкретные проблемы, их решения можно искать в Google или на форумах. Путь, проложенный самостоятельно, в будущем сильно поможет. Естественно, путь этот стоит прокладывать не с нуля — поэтому мы выше и рассказывали о том, где стоит искать начальные знания.

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

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

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

На такие “дикие пляски” лучше идти более подготовленным специалистам, которые понимают, в чем здесь отступление от классических процессов. У человека без опыта работа в таком режиме породит только кашу в голове. Скорее всего, ничему хорошему он тут не научится.

В целом, если вам не повезло с местом работы, не обязательно срочно собирать вещи. Главное найти специалиста, на которого можно опереться в поисках правильных решений — эдакого ментора и советчика. Кстати, ментора не обязательно искать среди коллег. Это может быть и сторонний человек, который подскажет, что изучить и куда посмотреть. Правда, посторонний человек вряд ли будет погружен в тематику проекта. Общаясь с ними, вероятно, придется и про NDA вспомнить.

Джун, миддл, сениор. А есть ли путь дальше?

На своем проекте тестировщик обычно вынужден ограничиваться существующим стеком технологий. Смена стека, как и смелые эксперименты, обычно довольно затратна либо связана с изменением места работы. Однако и в рамках стека где-то до уровня сениора проблем вам хватит — это не один год упорного труда и самообразования.

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

Как и в разработке, в тестировании есть малая доля задач, которые подразумевают более глубокое знание, например, математики. Разговор о ней начинается там, где математика всплывает и в самой разработке — в высоких нагрузках и т.п. Это еще одно направление возможного роста для тех, у кого в голове могут укладываться действительно масштабные логические структуры (и кому скучно в стандартных задачах тестирования). Таких задач на рынке совсем немного. Но за счет них возможность дальнейшего саморазвития сохраняется и для тех, кто не хочет идти по управленческому пути развития.

Дополнительные ссылки

Материалы по тестированию есть на http://www.protesting.ru/. Там много теории и немного практики. Можно найти базовую информацию о том, какие бывают виды тестирования, что такое тест-кейс, тест-план и т.п. Правда, ресурс этот развивается с 2000-х годов, поэтому некоторая информация успела устареть. Но по базе здесь можно найти ценные примеры.

Форум на ресурсе https://software-testing.ru/forum/ — это своего рода аналог Хабра для тестировщиков (по большей части для автоматизаторов). Там много полезной информации именно начального уровня — на Хабре в разделе тестирования больше более продвинутых статей, а тексты для новичков появляются все реже и принимаются аудиторией все хуже.

Еще два неплохих источника информации: https://tproger.ru/digest/free-software-testing-books/ и https://automation-remarks.com/.

Спасибо специалистам по тестированию нашей компании за помощь при подготовке статьи!

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

Обсудить в форуме

Разработка через тестирование: улучшаем навыки / Хабр

Тестирование важный навык, которым должен обладать каждый разработчик. Тем не менее, некоторые делают это неохотно.

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

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

Предположим, вы создаете приложение для погоды. Вы писали код несколько дней или недель, поэтому знаете код от и до.

Теперь представим, что вы закончили работу над приложением и вернетесь к нему через несколько месяцев. Вы не будете помнить каждую деталь старого кода. Вы измените его… и черт возьми… что-то сломалось. Как вы это исправите? Посмотрите на каждый созданный файл и настроите его, чтобы он снова работал? Может и получится. Но изменив этот файл, вы сломаете что-то еще.

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

Каждая команда должна писать тесты, когда создает программное обеспечение или приложения. Вы же не хотите быть человеком, который не знает, как тестировать?

Да, написание тестов требует времени. Да, сначала сложно. Да, создавать приложения интереснее. Но тесты важны и экономят время, если они правильно реализованы.

Моя цель сегодня: улучшить навыки тестирования. Мы рассмотрим unit тестирование и разработку через тестирование с помощью Jest (инструмент тестирования JavaScript). Конечно, есть другие инструменты тестирования, которые вы можете использовать, например, Mocha и Chai.

Давайте начнем!

Unit тестирование

Когда вы решаете протестировать приложение, вы сталкиваетесь с различными типами тестирования: unit тестирование (модульное), интеграционные тесты и функциональные тесты. Остановимся на модульных тестах.

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

Преимущества модульного тестирования:

• Делает код стабильнее;
• Облегчает изменения реализации функции без изменения ее поведения;
• Документирует ваш код. Вы скоро поймете, для чего.
• Заставляет вас делать правильно проектировать. Действительно, плохо разработанный код часто сложнее тестировать.

Разработка через тестирование (TDD)

Чтобы понять и использовать разработку через тестирование, запомните эти 2 правила:

1. Пишите тест, который не проходит, до написания кода.
2. Затем пишите код, который сможет пройти тест.

Когда мы используем TDD, мы говорим о цикле “red, green, refactor”.

Red: вы пишите провальный тест без написания кода.

Green: пишите простейший код, который сможет пройти тест. Даже если код кажется вам наиглупейшим.

Refactor: рефакторинг кода, если необходим. Не беспокойтесь, если вы поменяете код и ваши юнит-тесты сломаются, если что-то пойдет не так.

Структурирование тестового файла

Jest предоставляет функции для структурирования тестов:

describe: используется для группировки ваших тестов и описания поведения вашей функции/модуля/класса. Он принимает два параметра. Первый — это строка, описывающая вашу группу. Второй — это функция обратного вызова, в которой у вас есть тестовые примеры или hook функции.

it или test: ваш модульный тест. Параметры такие же как и у describe. Должен быть описательным. Именование теста зависит от вас, но можно начинать с «Should».

beforeAll (afterAll): hook функция запускает до (и после) все тесты. Принимает один параметр, который является функцией, которую вы будете запускать до (и после) всех тестов.

beforeEach (afterEach): hook функция, которая выполняется до (и после) каждого теста. Принимает один параметр, который является функцией, которую вы будете запускать до (и после) каждого теста.

Перед тем, как писать любой тест, вы должны знать следующее:

Вы можете пропустить тест, используя .skip на describe и it: it.skip(…) или describe.skip(…). Используя .skip, вы говорите Jest игнорировать тест или группу.

Вы можете выбрать именно те тесты, которые хотите запустить, используя .only на describe и it: it.only(…) или describe.only(…). Это полезно, если у вас много тестов и вы хотите сосредоточиться только на одном или хотите «отладить» ваши тесты.

Настройка Jest

Чтобы показать вам те функции тестирования, которые мы рассматривали выше, нам нужно настроить Jest. Это очень просто.

Вам нужны только Node.js и npm или Yarn. Убедитесь, что вы используете последнюю версию Node.js, поскольку мы будем использовать ES6. Создайте новый каталог и инициализируйте его.

mkdir test-example && cd test-example
npm init -y
# OR
yarn init -y

-y отвечает “да” на все вопросы npm или yarn. Он должен был создать очень простой файл package.json.

Затем добавьте Jest в среду разработки

yarn add jest --dev

Затем добавьте следующий скрипт в ваш package.json:

"scripts": {
  "test": "jest"
}

yarn test будет запускать ваши тестовые файлы в каталоге. По умолчанию Jest распознает файлы, находящиеся внутри каталога __tests__, или файлы, которые заканчиваются на .spec.js, либо .test.js.

На этом все. Вы готовы писать первый тест.

Matchers (образцы)

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

expect(input).matcher(output)

Jest имеет много образцов, вот самый важный:

toBe: сравнивает strict equality (===).

expect(1 + 1).toBe(2)
let testsAreEssential = true
expect(testAreEssential).toBe(true)

toEqual: сравнивает значения между двумя переменными, массивами или объектами.

let arr = [1, 2]
arr.push(3)
expect(arr).toEqual([1, 2, 3])
let x= 1
x++
expect(x).toEqual(2)

toBeTruthy (toBeFalsy): указывает, истинно ли значение (или ложно).

expect(null).toBeFalsy()
expect(undefined).toBeFalsy()
expect(false).toBeFalsy()
expect("Hello world").toBeTruthy()
expect({foo: 'bar'}).toBeTruthy()

toContain: проверяет, содержит ли массив элемент.

expect(['Apple', 'Banana', 'Strawberry']).toContain('Apple')

toThrow: проверяет, вызывает ли функция ошибку.

function connect () {
  throw new ConnectionError()
}
expect(connect).toThrow(ConnectionError)

Первые тесты

Теперь мы собираемся написать наш первый тест и поиграть с нашими функциями. Сначала создайте в своем каталоге файл example.spec.js и вставьте следующее:

describe('Example', () => {
  beforeAll(() => {
    console.log('running before all tests')
  })
  afterAll(() => {
    console.log('running after all tests')
  })
  beforeEach(() => {
    console.log('running before each test')
  })
  afterEach(() => {
    console.log('running after each test')
  })
  it('Should do something', () => {
    console.log('first test')
  })
  it('Should do something else', () => {
    console.log('second test')
  })
})

Обратите внимание, что нам не нужно импортировать все функции, которые мы используем. Они уже предоставлены Jest.

Запустите yarn test:

Поскольку у вас нет утверждений в тестах, они пройдут. Вы видели разные инструкции console.log? Вы должны лучше понимать, как работают ваши функции и тестовые примеры.

Теперь удалите все hook функции и добавьте .skip в первый тест:

describe('Example', () => {
  it.skip('Should do something', () => {
    console.log('first test')
  })
  it('Should do something else', () => {
    console.log('second test')
  })
})

Запустите yarn test еще раз:

Ничего страшного, если первый тест работать не будет.

Добавьте третий тест и используйте .only:

describe('Example', () => {
  it('Should do something', () => {
    console.log('first test')
  })
  it('Should do something else', () => {
    console.log('second test')
  })
  it.only('Should do that', () => {
    console.log('third test')
  })
})

Еще раз запустим yarn test:

Во второй части статьи мы сделаем простую реализацию стека в JavaScript с помощью TDD.

Немного о простом. Тест-дизайн. Часть 1 / Хабр

Сегодня тестирование ПО, один из ключевых процессов создания продукта. Неважно, какую Вы используете методологию, подход, процесс, тестирование ПО так или иначе всегда существует в Вашем процессе. В последние годы (да даже наверное десятилетие) тестирование ПО сформировалось в отдельную область ИТ, которая постоянно развивается в мировом сообществе.

И да, сегодня мы поговорим именно об обычных ручных (функциональных) тестировщиках, без уклона в автоматизацию, нагрузку и другие технические виды тестирования!

Сейчас профессия ручного тестировщика – это одна из самых востребованных процессий ИТ и один из самых простых способов попасть в ИТ.

Почему?

Потому что тестировщики ничего не делают, им не нужны знания. Тестировать может каждый!

Потому что профессия ручного тестировщика на начальном этапе не требует специфических знаний и умений. Основное «знание» для тестировщика – это умение «разрушать» и аналитическое мышление. А главное – иметь нестандартный склад ума, находить нетривиальные решения поставленных задач. Некий монстр, умеющий крушить и ломать:)

Hard skills всегда можно научить, а вот soft skills к сожалению научить очень сложно, потому что это характер человека, его отношение к чему-либо и т.д. Обычно я косо смотрю на руководителей, которые набирают себе специалистов по ручному тестирования по hard skills. Зачем Вы это делаете??? (ответы можете оставить в комментариях) Ну да ладно, продолжим:)

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

Мы с вами рассмотрим самую интересную и увлекательную часть тестирования – подготовку к тестированию. Именно от этой части процесса тестирования зависит то, насколько качественно и правильно вы выполните само тестирования, найдете необходимые дефекты и обеспечите довольное лицо Заказчика (ну или продукт овнера) качество задачи после внедрения.

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

И в этом цикле статей поговорим об этом.

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

Выглядит это так:

• Зачем нам нужны техники тест-дизайна?
• Чтобы правильно определить проверки для тестирования.
• А используете ли Вы их в работе?
• В явном виде нет, мы сами определяем то, что нужно проверить.

Почему так происходит? Ведь техники тест-дизайна – это основа составления сценариев тестирования. Это тоже самое, что уметь водить машину, но при этом не знать ПДД. Почему же тестировщики не применяют их в работе?

Ответ прост.

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

Второе, при обучении техникам тест-дизайна, данный процесс очень формализуется, что выглядит, как необходимость тестировщику в своей работе все формализовать. А обычно это никому не надо времени на это ни у кого нет.

Если говорить простыми словами, то техники тест-дизайна – это совокупность правил, позволяющих правильно определить список проверок для тестирования. И самое важное, это использовать эти правила всегда и везде 🙂 уметь на интуитивном уровне применять данные правила. Именно умение «проводить аналитику в голове» отличает хорошего тестировщика!

В моей организации, как и общепринятых стандартах и практиках, задачами тест-дизайна являются:

• Анализ требований и рисков тестирования
• Определение проверок для тестирования
• Формализация проверок в виде тестовых сценариев
• Приоритезация проверок
• Определение подходов к тестированию

В этом цикле статей я постараюсь вам рассказать не только о техниках тест-дизайна, но и о том, как их ВСЕ (именно все вместе, а не конкретную одну или две) применять на практике, в том числе на примере функционала нашего банка. Как формировать проверки к тестированию с применением техник тест-дизайна для больших систем и процессов. И самое главное, вы получите ответ на то, в каких случаях и при каких проверках применять техники тест-дизайна.

Итак, начнем.

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

Это классы эквивалентности и граничные значения.

Что же такой классы эквивалентности?

Класс эквивалентности (Equivalence class) – это набор входных (или выходных) данных ПО, которые обрабатываются программой по одному алгоритму или приводят к одному результаты.

То есть, это некое множество значений, которое вы можете подставлять в программу и получать один и тот же результат. Результатом можем быть не только конкретные значения, действия программы, но и просто область применения. Поэтому, самые простые классы эквивалентности, на которые делятся проверки, это 2 основных класса: позитивные и негативные сценарии.

Они есть всегда. Каждый тестировщик делит проверки на эти классы, но не каждый тестировщик знает, почему он это делает. Ответ – классы эквивалентности.

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

Рассмотрим пример:

Система скорринга рассчитывает процентную ставку по кредиту для клиента исходя из его возраста, который вводится в форму:

• От 18 до 25 лет – 18%
• От 25 до 45 лет – 16 %
• Свыше 45 лет – 20%

Мы определяем 2 основных класса – это позитивные и негативные сценарии.

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

Далее мы делим класс позитивных сценариев 3 класса вводимых значений 18-24, 25-44 и 45 +

В классе негативных сценариев мы формируем значения, исходя из необходимости проверки отказов программы, поэтому мы имеем 0, 1-17, отрицательные значения, ввод символов и т.д.

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

Итого мы имеем.

• Позитивные проверки: Ввод значений: 19, 30, 48 (значения могут быть любыми из данного диапазона класса)
• Негативные проверки: 0, 3, -1, А и т.д.

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

Еще одна особенность классов эквивалентности – это их применение. Я выделяю 3 уровня применения техник тест-дизайна для подготовки к тестированию.

• Первый уровень – проверка элементов системы (например, полей, чекбоксов, кнопок и т.д.)
• Второй уровень – проверка логики работы системы при комбинации данных в элементах системы
• Третий уровень – проверка бизнес- процесса системы и логики работы программы.

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

Неотъемлемой часть проверки любого элемента является другая техника – граничные значения.

Граничные значения дополняют эквивалентные классы, тем самым полностью покрывая проверки элемента ПО.

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

Вроде все просто!

Вернемся к нашему примеру ранее.

Система скорринга рассчитывает процентную ставку по кредиту для клиента исходя из его возраста, который вводиться в форму:

• От 18 до 25 лет – 18%
• От 25 до 45 лет – 16 %
• Свыше 45 лет – 20%

Что же здесь будет границей?

Если вы подумали о длине поля на страничке Хабры, или об отпуске в теплых странах, хочу вас расстроить, это не так 🙂

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

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

В итоге мы имеем:

Границы наших классов: 17, 18, 19, 24, 25, 26, 44, 45, 46 и max.

Также, у нас есть негативный класс, это от 0 до 18. Поэтому тут мы тоже должны использовать для тестирования граничные значения: -1, 0, 1, 17,18

Далее исключаем повторяющиеся значения, и получаем значения для проверки элемента ввода данных.

-1, 0, 1, 17, 18, 19, 24, 25, 26, 44, 45, 46, max.

Значение max обычно уточняется у Заказчика или аналитика. Если не могут предоставить, то следует бросить его и не проверять необходимо подобрать значение, соответствующее здравому смыслу (вряд ли кто-то придет за кредитов в возрасте 100 лет).

Следующий шаг, это наложить граничные значения на значения классов эквивалентности, исключить лишние проверки, пользуясь правилом «достаточно одного значения для проверки одного класса» и финализировать список.

Если ранее у нас были 3 значения для 3-х классов, 19, 30 и 48, то после определения граничных значений, мы можем исключить из списка значения 30 и 48 и заменить их предграничными значениями, такими как 26 (вместо 30) и 46 (вместо 48).

Граничные значения определяются не только для числовых значений, но и для буквенных (например, границы алфавита и кодировки), даты и времени, смысловых значений. Граница числовых значений зависит от формата ввода, если у вас целые числа, например, 2, то граничные значения будут 1 и 3. Если дробные значения, то границы для числа 2 уже будут 1,9 (1,99) или 2,1 (2,01) и т.д.

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

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

Что ж, слишком легко??? Сейчас начнем разбирать более сложные техники, готовьтесь.

Техники тест-дизайна 2-го уровня отвечают за вариативность и комбинаторику данных при проверке ПО.

Основной техникой тест-дизайна parwise testing (попарное тестирование). Суть техники заключается в минимизации вариативности комбинаций проверок, достаточных для обеспечения высокого качества ПО.

Простыми словами, в данной технике применяется правило Парето, 80 % качества можно достичь всего 20% проверок комбинаций данных.

Данная техника была выведена путем более 15-тилетнего исследования IEEE в области анализа причин возникновения дефектов в системе. Результаты исследования показали, что 98% всех дефектов возникают при конфликте ПАР входных данных или ОДНОГО входного параметра.

Почему же была выбрана пара? Погрузимся в дебри математической статистики и теории вероятности, чтобы найти ответ.

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

Пусть выпадение значения 2 – это дефект, тогда вероятность появления дефекта при кидании кубика равна 1/6=0,167.

Если мы бросаем 2 кубика, то вероятность выпадения 2-х двоек (2 дефекта) становиться ниже и равна 0,167*0,167 = 0,028, для 3-х уже 0,005 и т.д.

Получается, что вероятность возникновения дефекта при комбинации 3-х и более параметров настолько мала, что ее можно отбросить.

Когда мы с вами тестируем программу, всегда есть n количество элементов, которые влияют на результат, например, форма заполнения данных по кредитной заявке. Там есть n количество полей, которые в совокупности дают результат. Именно комбинаторику данных при заполнении полей мы проверяем с помощью попарного тестирования.

Давайте рассмотрим на примере функциональности дистанционного оформления карты в банке.

Если мы внимательно посмотрим, то увидим с Вами пять полей заполнения данных:

• ФИО
• Дата рождения
• Мобильный телефон
• Серия номер паспорта
• Электронная почта,
• а также 2 чек-бокса.

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

Очень ВАЖНО, при использовании техники попарного тестирования, мы не говорим о результате тестирования. Нам важно проверить вариативность данных при заполнении заявки.

Итак,

Поле ФИО может принимать значения (классы):

• ФИО на русском
• Невалидное значение
• Пустое значение

Очень часто тестировщики не понимают, какие значения выбирать для данной техники, если они не ограничены возможностью ввода. Например, если у нас есть возможность выбора пола человека М или Ж, то тут все просто, есть 2 значения. Но когда у нас есть строка для ввода данных, то при попарном тестировании мы не проверяем корректность заполнения конкретного поля, т.к. эти проверки должны быть выполнены на первом уровне тест-дизайна (либо совместить их с попарным тестированием). Мы используем класс эквивалентности для данного поля, потому что нам не важно, какое именно это будет значение.

Идем дальше, дата рождения, также как и мобильный телефон, серия и номер паспорта можем иметь тоже 3 состояния:

• Валидное значение
• Невалидное значение
• Пустое значение

Т.к. электронная почта необязательно, то данное поле имеет 2 значения:

• Валидное значение
• Невалидное значение

Чек-боксы обычно имеют всего 2 состояния – Y или N.

Чтобы проверить все комбинации данной формы нам бы понадобилось сделать свыше 1000 тестов, но используя попарное тестирование нам достаточно всего 9 тестов!

Магия, не думаю:)

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

Мы берем ФИО и серия номер паспорта. Наша задача – перебрать все значения данной пары между собой:

После перебора одной пары, мы создаем другую пару и начинаем перебирать значения (например номер мобильного телефона)
Подключаем следующий элемент и так далее до полного заполнения всей таблицы, которая будет выглядеть так:

Таким образом мы получаем 9 тестов с конкретными классами эквивалентности, которые мы можем вводить для проверки работы вариативности данных для формы. Классы мы можем заполнять конкретными значениями, которым мы получаем с вами используя 1 уровень техник тест-дизайна.

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

Надеюсь было полезно!

требования и уровни / Хабр

Меня зовут Алексей Чумагин, я тестировщик в Provectus. В этой статье я расскажу, как формируются требования к качеству данных и какие могут быть уровни тестирования данных.

Upd:
В статье речь идет о больших (или не очень) данных, на основе анализа и агрегации, которых строятся разные процессы, выводятся закономерности для использования в дальнейшем анализе или для принятия решений. Данные могут быть собраны под конкретный проект с нуля, либо могут использоваться базы, собранные ранее для других проектов либо в коммерческих целях. Источники этих данных разнообразны и включают не только ввод операторами, но и автоматизированные и/или автоматические измерения, сохраняемые в базы системно или бессистемно (кучей, “потом придумаем что с этим делать”).

end-of-upd.

Почему тестирование данных важно

Данные играют все большую роль в принятии решений как в повседневной жизни, так и в бизнесе. Современные технологии и алгоритмы позволяют обрабатывать и хранить огромные массивы данных, преобразуя их в полезную информацию.

Что это за данные? Например, история вашего браузера, транзакции по вашей карте, точки перемещения какого-то девайса. Они обезличены, но эти данные все равно принадлежат определенному устройству. Если их собрать и обработать, то можно получить довольно интересную информацию о хозяине этого девайса. Например, куда он любит ходить, какой у него пол и возраст. Так постепенно мы «очеловечиваем» устройство и наделяем его какими-то характеристиками.

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

Всё это базируется на тех данных, которыми владеют разные компании и люди. Для эффективного использования этих данных нужно, чтобы они были достоверными и мы знали, что именно этому аккаунту принадлежат эти транзакции.

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

Что такое качество

Мне нравится такое определение: качество продукта — это мера удовлетворенности пользователя. Понятно, что всё зависит от контекста использования продукта. Если вы пользуетесь каким-нибудь известным продуктом, например, Facebook или Skype, то у вас одни требования к качеству. Вы будете мириться с какими-то ошибками, но всё равно продолжите пользоваться этим продуктом. А если вы являетесь заказчиком какой-то программы и заплатили за нее деньги, то требования к качеству будут выше. Вы будете придираться, смотреть какие-то мелочи. У разных людей разные представления о качестве, и у разных программ тоже свои требования к качеству.

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

Определение этих требований — непростая задача. Обычно требования к ПО формирует бизнес, и если мы спросим у бизнеса, какими должны быть данные, то можем получить ответ, что данные должны быть хорошими и чистыми. Задача тестировщика — выяснить или уточнить, что это за данные и по каким критериям мы определяем их качество и чистоту. Эти критерии нужно формализовать и зафиксировать, сделать измеряемыми.

Как формируются требования к качеству данных

Тестировщик начинает выяснять, что ему непонятно и что он хотел бы узнать об объекте тестирования. Тестировщик составляет список вопросов и начинает брать «интервью» у заказчика. Он, по идее, должен знать, какими должны быть данные. Например, я спрашиваю: допустимы ли пустые ячейки или повторяющиеся строки.

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

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

Что такое качественные данные

Качественные данные должны обладать несколькими характеристиками.

• Полнота — в записях нет пропусков, все ячейки должны быть заполненными. Данные должны нести как можно больше информации.
• Уникальность — среди данных не должно быть одинаковых записей.
• Достоверность — ради этого всё и затевается. Никто не хочет работать с данными, которым нельзя верить. Ячейки таблиц с качественными данными содержат то, что и должны содержать: IP-адрес, номер телефона и т.д.
• Точность. Если говорить о цифровых данных, то должно быть точное количество знаков. Например, 12 знаков после запятой. Данные должны быть близки к какому-то среднему значению.
• Согласованность — данные должны сохранять значения, независимо от способа их измерения.
• Своевременность — данные должны быть актуальны, особенно если они периодически обновляются. Например, каждый месяц количество данных должно увеличиваться. Данные не должны устаревать. Если мы говорим о банковских транзакциях, то нам интересно, чтобы они были, например, за последние полгода.

Уровни тестирования данных

Мы можем сгруппировать данные по так называемым слоям — здесь работает хорошая аналогия с пирамидой тестирования. Это распределение по количеству тестов на разных уровнях приложения.

• Unit-слой — это когда тестируется один модуль программы, чаще всего это одна функция или метод. Таких тестов должно быть больше всего. Unit-тест для данных — это когда мы определяем требования для каждой ячейки. Нет смысла тестировать дальше, если у нас есть ошибки на уровне ячеек. Если, например, в фамилии содержатся цифры, то какой смысл проверять что-то дальше? Возможно, там должны быть буквы, похожие на эти цифры. И тогда нам нужно всё исправлять и проверять следующий уровень, чтобы у нас всё было в единственном числе и не было дубликатов, если так сказано в требованиях.
• Integration-слой — это когда несколько кусков программы тестируются вместе. Слой API для данных — это когда мы говорим о всей таблице. Допустим, у нас могут быть дубликаты, но не больше ста штук. Если у нас город-миллионник, то на одной улице не может жить миллион человек. Поэтому если мы сделаем выборку по улице, то количество адресов должно быть десять тысяч или тысяча — это надо определить. А если у нас миллион, то с данными что-то не так.
• System-слой — это когда вся программа тестируется полностью. В случае с данными этот слой означает, что тестируется вся система. Здесь включается статистика. Например, мы говорим, что у нас не может быть больше 30% мужчин, рожденных после 1985 года. Или мы говорим, что 80% данных должны быть одного типа.

В заключение скажу, что тестирование данных — это сфера, которая предоставляет много возможностей для творчества и развития. Серебряной пули здесь нет: к тестированию данных можно применять разные подходы. Истина, как всегда, где-то посередине.

НОУ ИНТУИТ | Основы тестирования программного обеспечения

Форма обучения:

дистанционная

Стоимость самостоятельного обучения:

бесплатно

Доступ:

свободный

Документ об окончании:

Уровень:

Специалист

Длительность:

14:38:00

Студентов:

14950

Выпускников:

2122

Качество курса:

4.11 | 3.63

Курс посвящен обсуждению проблем контроля качества разработки программного обеспечения с позиций тестирования. Задачей курса, реализующейся через лекционный материал и практикум, является подготовка тестировщиков программного проекта.

Предлагаемый вашему вниманию курс обобщает опыт многолетней работы учебного центра «Политехник — Моторола» в Санкт-Петербургском государственном политехническом университете. Основные темы лекционного курса: основные понятия тестирования: терминология тестирования, различия тестирования и отладки, фазы и технология тестирования, проблемы тестирования, критерии выбора тестов: структурные, функциональные, стохастические, мутационный, оценки покрытия проекта, разновидности тестирования: модульное, интеграционное, системное, регрессионное, автоматизация тестирования, издержки тестирования, особенности процесса и технологии индустриального тестирования: планирование тестирования, подходы к разработке тестов, особенности ручной разработки и генерации тестов, автоматизация тестового цикла, документирование тестирования, обзоры и метрики, регрессионное тестирование: особенности и виды регрессионного тестирования, методы отбора тестов, оценка эффективности, терминологический словарь: содержит глоссарий терминологии тестирования в соответствии с IEEE Standard Glossary of Software Engineering.

ISBN: 978-5-9556-0027-7

Теги: MPR, sql, автоматизации тестирования, безопасность, выборочное регрессионное тестирование, интеграционное тестирование, интерфейсы, компоненты, методики, модульное тестирование, отбор тестов, потоки, протоколы, процедуры, разработка, регрессионное тестирование, серверы, системное тестирование, скрипты, спецификации, статус терминала, тестирование, фаза тестирования, элементы, эффективность

Предварительные курсы

Дополнительные курсы

2 часа 30 минут

—

Основные понятия тестирования

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

—

Критерии выбора тестов

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

—

Модульное и интеграционное тестирование

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

—

Автоматизация тестирования

Рассматривается структура тестового набора для автоматического прогона. Обсуждается структура инструментальной системы автоматизации тестирования. Сравниваются издержки и эффективность различных методов тестирования.

—

Особенности индустриального тестирования

Рассматриваются особенности подхода к обеспечению качества программного продукта средствами тестирования. Приводится пример и методика выбора критериев качества тестирования. Определяются фазы процесса тестирования и шаги тестового цикла, применяемые в индустриальном тестировании. Рассматривается структура документа «Тестовый план». Рассматриваются планируемые типы тестирования для различных частей продукта или для проверки различных характеристик продукта. Описываются подходы к тестированию спецификаций и сценариев. Приводится ручной подход и подход генерации тестовых наборов при разработке тестов. Сравниваются методы автоматизации исполнения тестов.

—

Документирование и оценка индустриального тестирования

Описываются особенности документирования тестовых процедур для ручных и автоматизированных тестов, описаний тестовых наборов и тестовых отчетов. Рассматривается жизненный цикл дефекта. Обсуждаются метрики, используемые при тестировании.

—

Простое написание тестов — это не TDD! / Хабр

Эта статья представляет собой хороший теоретический материал о TDD для тех, кто об этом ещё ничего не знает.

В мире разработки ПО существует общее заблуждение, что простое написание тестов равносильно разработке через тестирование.

Разработка через тестирование(TDD) даёт уверенность в работоспособности программы в любой момент времени и помогает всем её частям быть хорошо спроектированными, использоваться повторно и слабо связываться.

Что такое TDD?

В TDD есть 3 основных правила от дядюшки Боба:

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

Основы TDD

Базовый процесс следования TDD содержит 3 этапа: красный, зелёный и рефакторинг.

Красный

Красный этап состоит из написания теста, который не проходится. Только одного теста. Если ты не можешь остановиться и продолжаешь писать много тестов, займи идею из Getting Things Done и выкинь лишние мысли из головы, чтобы они не отвлекали тебя. Существует несколько разных способов, которые ты можешь использовать: создать список предстоящих дел на бумаге, нарисовать индексную карту, добавить серию TODO комментариев в свои файлы и многие другие. Для себя я определил, что физическое действие вычёркивания пунктика на бумаге или рисование галочки и сворачивание индексной карты пополам даёт мне большее ощущение завершённости дела.

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

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

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

Зелёный

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

Рефакторинг

Следующий шаг — это рефакторинг, реструктуризация и организация твоего кода. Этап рефакторинга может происходить в любой момент: после 1 красного/зелёного цикла, после четырёх или более. Так как у тебя есть по меньшей мере 1 зелёный тест, ты можешь переписывать код с лёгкостью и комфортом, зная, что твои тесты провалятся, если ты ошибёшься и потеряешь работащую функциональность.

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

Преимущества TDD

Рабочий код

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

Изменения без страха

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

Живая документация

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

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

Я всегда переживал, что одна из D в TDD не означает дизайн. Как я мельком упоминал ранее, практика TDD это не только написание тестов в попытке удостовериться, что программа работоспособна. TDD переворачивает разработку программ вверх ногами и заставляет думать о проблеме не изнутри, а снаружи.

Написание тестов заставляет тебя думать не о реализации — основное беспокойство связано с использованием объекта или функции. Так как мы проводим большое количество времени непосредственно взаимодействуя с объектами и функциями которые мы пишем, архитектура проявляется из кода сама.

Когда не TDD

Что если тебе нужно использовать новую библиотеку или фреймворк, а ты не знаешь как это сделать? Как ты можешь написать тест в первую очередь, если ты не знаешь с чего начать? Ответ прост — а ты не можешь. Создай новый проект и используй новую библиотеку отдельно от своего рабочего кода. Такие новые проекты называются костылями. Так как они не в твоём рабочем коде, ты не нарушаешь Правило №1 из трёх правил дядюшки Боба. Работай с ним пока ты не почувствуешь комфорт в использовании этой библиотеки. Когда узнаешь, как твоя библиотека работает, забудь костыли и возвращайся назад к своему рабочему коду и начинай с написания тестов.

Как бы то ни было, если ты не можешь использовать TDD, не забывай о важности написания тестов. Твои тесты послужат справкой для тебя и (если твой костыль в системе контроля версий) для тех, кто придёт после тебя. С помощью этих тестов ты можешь быстро вспомнить всё что ты изучил, и, оглядываясь назад, ты увидишь большой прогресс в своём мастерстве.

Что такое тестирование программного обеспечения? Более 100 бесплатных руководств по ручному тестированию

Полное руководство по тестированию программного обеспечения, включающее более 100 руководств по ручному тестированию с определением, типами, методами и подробностями процесса тестирования:

Что такое тестирование программного обеспечения?

Тестирование программного обеспечения — это процесс проверки и подтверждения функциональности приложения, чтобы определить, удовлетворяет ли оно указанным требованиям. Это процесс поиска дефектов в приложении и проверки того, где приложение работает в соответствии с требованиями конечного пользователя.

Что такое ручное тестирование?

Ручное тестирование — это процесс, в котором вы сравниваете поведение разработанного фрагмента кода (программного обеспечения, модуля, API, функции и т. Д.) С ожидаемым поведением (требованиями).

Список руководств по ручному тестированию программного обеспечения

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

Эта серия руководств обогатит ваши знания и, в свою очередь, улучшит ваши навыки тестирования.

Практика сквозного ручного тестирования Бесплатное обучение на реальном проекте:

Учебник № 1: Основы ручного тестирования программного обеспечения
Учебник № 2: Введение в Live Project
Учебное пособие № 3: Написание сценария тестирования
Учебник № 4: Написание документа плана тестирования с нуля
Учебное пособие № 5: Написание тестовых примеров из документа SRS
Учебник № 6: Выполнение теста
Учебник № 7: Отслеживание ошибок и тестирование Sign off
Учебник № 8: Курс тестирования программного обеспечения

Жизненный цикл тестирования программного обеспечения:

Учебное пособие № 1: STLC

Веб-тестирование:

Учебное пособие № 1: 84 Урок № 2: Кросс-браузерное тестирование

Управление тестовыми случаями:

Учебное пособие № 1: Тестовые случаи
Учебное пособие № 2: Образец шаблона тестового случая
Учебное пособие № 3: Матрица прослеживаемости требований (RTM)
Учебное пособие № 4: Тестовое покрытие
Учебное пособие № 5: Управление данными тестирования

Управление тестированием:

Учебное пособие № 1: Test Strategy
Tutorial # 2: Test Plan Template
Tutorial # 3: Test Estimation
Tutorial # 4: Инструменты управления тестированием
Tutorial # 5: HP ALM Tutorial
Tutorial # 6: Jira
Tutorial # 7: TestLink Tutorial

Test Techniques:

Tutorial # 1: Use Case Testing
Tutorial # 2: State Transition testing
Tutorial # 3: Boundary Value Analysis
Tutorial # 3: Boundary Value Analysis
# 4: Equivalence Partitioning
Учебное пособие №5: Методологии тестирования программного обеспечения
Учебное пособие №6: Методология Agile

Управление дефектами:

Учебное пособие № 1: Жизненный цикл ошибок
Учебное пособие № 2: Отчеты об ошибках
Учебное пособие № 3: Приоритет дефектов
Учебное пособие № 4: Учебное пособие по Bugzilla

Testing Function Tutorial # 1: Unit Testing
Tutorial # 2: Sanity and Smoke Testing
Tutorial # 3: Regression Testing
Tutorial # 4: System Testing
Tutorial # 5: Acceptance Testing
6: Integration Testing
Tutorial # 7: UAT User Acceptance Testing

Non-Functional Testing:

Tutorial # 1: Non-Functional Testing
Tutorial # 2: Performance Testing
3: Тестирование безопасности
Учебник № 4: Тестирование безопасности веб-приложений
Урок № 5: Тестирование удобства использования
Учебное пособие № 6: Тестирование совместимости
Учебное пособие № 7: Тестирование установки
Учебное пособие № 8: Тестирование документации

Типы тестирования программного обеспечения:

Учебное пособие № 1: Типы тестирования
Учебное пособие № : Тестирование черного ящика
Учебное пособие № 3: Тестирование базы данных
Учебное пособие № 4: Сквозное тестирование
Учебное пособие № 5: Исследовательское тестирование
Учебное пособие № 6: Инкрементное тестирование
Учебное пособие № 7: Доступность Тестирование
Учебное пособие № 8: Отрицательное тестирование
Учебное пособие № 9: Внутреннее тестирование
Учебное пособие № 10: Альфа-тестирование
Учебное пособие № 11: Бета-тестирование
Учебное пособие № 12: Альфа против -тестирования
Учебник № 13: Гамма-тестирование
Урок № 14: Тестирование ERP
Урок № 15: Статическое и динамическое тестирование
Учебное пособие rial # 16: Специальное тестирование
Учебник № 17: Тестирование локализации и интернационализации
Учебник № 18: Тестирование автоматизации
Учебник № 19: Тестирование белого ящика

Карьера в тестировании программного обеспечения:

Учебник 1: Выбор профессии по тестированию программного обеспечения
Учебное пособие № 2: Как получить задание по тестированию качества — полное руководство
Учебное пособие № 3: Варианты карьеры для тестировщиков
Учебное пособие № 4: Переход от не ИТ к тестированию программного обеспечения
Урок 5: Начни свою карьеру при ручном тестировании
Урок 6: Уроки, извлеченные за 10 лет тестирования
Урок 7: Выживание и прогресс в области тестирования

Подготовка к интервью:

Учебное пособие # 1: QA Resume Preparation
Tutorial # 2: Manual Testing Interview Questions
Tutorial # 3: Automation Testing In Вопросы-ответы
Учебник № 4: Вопросы для собеседования по обеспечению качества
Учебник № 5: Обработка любых собеседований
Учебник № 6: Тестирование работы в качестве новичка

Тестирование приложения в другом домене:

Учебное пособие № 1 : Тестирование банковских приложений
Учебное пособие № 2: Тестирование приложений для здравоохранения
Учебное пособие № 3: Тестирование платежного шлюза
Учебное пособие № 4: Система тестирования точек продаж (POS)
Учебное пособие № 5: Электронная коммерция Тестирование веб-сайтов

Сертификация QA:

Учебное пособие № 1: Руководство по сертификации тестирования программного обеспечения
Учебное пособие № 2: Руководство по сертификации CSTE
Учебное пособие № 3: Руководство по сертификации CSQA
Учебное пособие № 4 ISQA Руководство
Урок № 5: ISTQB Advanced

Расширенное ручное тестирование Темы:

Учебник l # 1: Cyclomatic Complexity
Tutorial # 2: Migration Testing
Tutorial # 3: Cloud Testing
Tutorial # 4: ETL Testing
Tutorial # 5: Метрики тестирования программного обеспечения
Tutorial # 6: Веб-службы

Приготовьтесь взглянуть на 1-е руководство в этой серии «Ручное тестирование» !!!

Введение в ручное тестирование программного обеспечения

Ручное тестирование — это процесс, в котором вы сравниваете поведение разработанного фрагмента кода (программного обеспечения, модуля, API, функции и т. Д.) против ожидаемого поведения (Требования).

А как узнать ожидаемое поведение?

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

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

Иногда это может быть пропущенное требование (неполное требование) или неявное требование (что-то, что не требует отдельного упоминания, но должно быть выполнено), и это тоже необходимо проверить.

Кроме того, требование не обязательно должно быть документированным. Вы можете хорошо знать функциональность программного обеспечения или даже догадываться, а затем тестировать по одному шагу за раз.Обычно мы называем это специальным тестированием или исследовательским тестированием.

Давайте внимательно рассмотрим:

Во-первых, давайте разберемся в одном факте — Независимо от того, сравниваете ли вы тестирование программного приложения или чего-то еще (скажем, автомобиля), концепция остается той же. Подход, инструменты и приоритеты могут различаться, но основная цель остается ОДНОЙ и ПРОСТОЙ, то есть сравнивать фактическое поведение с ожидаемым.

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

Но каковы качества успешного тестировщика? Вы можете прочитать о них по ссылке ниже:

Прочтите здесь => Качества высокоэффективных тестеров

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

Для тех, у кого нет времени читать статью, вот синопсис:

«Ваше любопытство, внимательность, дисциплина, логическое мышление, страсть к работе и способность анализировать вещи очень важны, чтобы быть деструктивным. и успешный тестировщик. Это сработало для меня, и я твердо верю, что это сработает и для вас. Если у вас уже есть эти качества, значит, это должно работать и на вас.”

Мы обсудили основные условия, необходимые для того, чтобы стать тестировщиком программного обеспечения. Теперь давайте разберемся, почему ручное тестирование существует и всегда будет существовать независимо с ростом автоматизации тестирования или без него.

Почему требуется ручное тестирование?

Знаете ли вы, что самое лучшее в работе тестировщиком, а также в ручном тестировании?

Дело в том, что здесь нельзя полагаться только на квалификацию. Вы должны иметь / развивать и улучшать свой мыслительный процесс.Это то, что на самом деле нельзя купить за несколько долларов. Вы сами должны над этим работать.

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

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

Давайте посмотрим на этот простой поток:

• Вы что-то делаете ( выполняете действия ), пока вы наблюдаете это с некоторым намерением (сравнивая с ожидаемым). Теперь ваше наблюдение (), навыков и дисциплина, выполнения вещей, входят в картину здесь.
• Вуаля! Что это было? Вы кое-что заметили. Вы заметили это, потому что вы уделяли идеального внимания деталям перед вами. Вы не позволите этому уйти, потому что вам любопытно .В вашем плане не было того, что произойдет что-то неожиданное / странное, вы заметите это и расследуете это дальше. Но теперь вы это делаете. Вы можете отпустить это. Но вы не должны упустить это.
• Вы счастливы, вы выяснили причину, шаги и сценарий. Теперь вы должным образом и конструктивно сообщите об этом команде разработчиков и другим заинтересованным сторонам в вашей команде. Вы можете сделать это с помощью какого-нибудь инструмента отслеживания дефектов или устно, но вы должны убедиться, что вы конструктивно сообщаете об этом .
• Ой! Что, если я так сделаю? Что если я введу правильное целое число, но с пробелами в начале? Что, если? … Что, если? … Что, если? Это не закончится легко, это не должно закончиться легко. Вы представите себе множества ситуаций и сценариев, и у вас действительно возникнет соблазн их выполнить.

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

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

Итак, вы действительно думаете, что эти действия можно полностью заменить чем-то еще? И актуальная сегодня тенденция — можно ли ее когда-нибудь заменить автоматизацией?

В SDLC с любой методологией разработки некоторые вещи всегда остаются неизменными. Как тестировщик, вы будете использовать требования, преобразовывая их в тестовые сценарии / тестовые примеры. Затем вы выполните эти тестовые примеры или напрямую автоматизируете их (я знаю, что некоторые компании это делают).

Когда вы автоматизируете это, вы постоянно сосредотачиваетесь на автоматизации написанных шагов.

Вернемся к формальной части, то есть выполнению тестовых примеров, написанных вручную.

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

На приведенном ниже изображении показано, как упрощается написание тестового примера:

Я заполняю форму, и я закончил с заполнением первого поля.Я слишком ленив, чтобы мышкой переключить фокус на следующее поле. Я нажимаю клавишу «Tab». Я закончил с заполнением следующего и последнего поля, теперь мне нужно нажать кнопку «Отправить», фокус по-прежнему находится на последнем поле.

Ой, я случайно нажал клавишу «Enter». Позвольте мне проверить, что случилось. ИЛИ есть кнопка отправки, я дважды щелкну по ней. Не удовлетворены. Я нажимаю на нее несколько раз слишком быстро.

Вы заметили? Существует так много возможных действий пользователя, как преднамеренных, так и непреднамеренных.

Вам не удастся написать все тестовые примеры, которые охватывают тестируемое приложение на 100%. Это должно происходить в исследовательском порядке.

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

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

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

Потребность в ручном тестировании, когда автоматизация приблизилась:

Автоматическое тестирование имеет свою долю славы в наши дни и будет еще больше в ближайшие годы, но оно просто не может заменить ручное тестирование QA (читайте человеческое / исследовательское тестирование).

Вы, должно быть, слышали раньше: « Вы не автоматизируете тестирование, вы автоматизируете проверку ».Это предложение многое говорит о том, где ручное QA-тестирование соотносится с автоматическим тестированием. Многие известные имена по всему миру писали и говорили на эту тему, поэтому я не буду особо на этом останавливаться.

Автоматизация не может заменить человеческое тестирование, потому что:

• Она требует суждений во время выполнения обо всем, что происходит на ваших глазах (пока вы тестируете), а в некоторых случаях и за кулисами.
• Требует ясного и постоянного наблюдения.
• Требует допроса.
• Требуется расследование.
• Это требует рассуждений.
• При тестировании требуются незапланированные действия.

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

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

Отдельно отметим, что даже если это действительно произойдет через несколько сотен лет, я могу точно представить картину ужасного мира. Эпоха трансформеров. 🙂

= >> Рекомендуемая литература — Лучшие компании, оказывающие услуги по ручному тестированию.

Как автоматизация поддерживает ручное тестирование?

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

В большинстве случаев развертывание все большего количества сотрудников не помогает в долгосрочной перспективе для этой задачи. Следовательно, тестировщик (руководитель тестирования / архитектор / менеджер) должен осторожно решить, что следует автоматизировать, а что следует делать вручную.

Становится чрезвычайно важным составление очень точных тестов / проверок, чтобы их можно было автоматизировать без каких-либо отклонений от первоначального ожидания и можно было использовать при регрессии продукта в рамках «непрерывного тестирования».

Примечание: Слово «непрерывный» из термина «непрерывное тестирование» подвергается условным и логическим вызовам, как и другие термины, которые мы использовали выше с тем же префиксом. «Непрерывный» в этом контексте означает «все чаще и чаще, быстрее, чем вчера». Хотя по значению, это может означать каждую секунду или нано-секунду.

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

Я специально использовал термин «критерии выхода из теста» выше. Наши костюмы для автоматизации больше не могут быть похожи на традиционные. Мы должны быть уверены, что если они потерпят неудачу, они потерпят неудачу быстро. А чтобы они быстро выходили из строя, необходимо автоматизировать критерии выхода.

Пример:

Допустим, имеется дефект блокировщика, при котором я не могу войти в Facebook.

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

Следующее, что вы, должно быть, слышали раньше — Вы не можете и не должны пытаться все автоматизировать.

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

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

Заключение

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

Признание важности ручного тестирования QA и понимание того, почему оно особенное, — это самый первый шаг к тому, чтобы стать отличным ручным тестером.

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

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

Мы будем рады услышать от вас. Не стесняйтесь выражать свои мысли / предложения в разделе комментариев ниже.

.

Основы тестирования программного обеспечения — Основы тестирования программного обеспечения

ОСНОВЫ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ — это то, чему посвящен весь этот сайт. Однако перед тем, как начать, вам необходимо освоить основы и . Итак, мы настоятельно рекомендуем вам прочитать следующие фундаментальные статьи, если вы только начинаете свое путешествие в мир тестирования программного обеспечения.

ИСКУССТВО И НАУКА ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

Последнее обновление: 12 сентября 2020 г., STF

.

101 Различия между основами тестирования программного обеспечения

Различия между основами тестирования программного обеспечения:

Статья создана для юных тестировщиков, которые готовятся к собеседованию. Поскольку более свежие ответы на все это немного сложно, но наверняка будет несколько вопросов из приведенного ниже списка, вам не нужно знать все ответы для приведенного ниже списка, но если вы знаете его намного лучше. Я чертовски уверен, что ни один веб-сайт, кроме «Справки по тестированию программного обеспечения», не отобразит это, поэтому я провел исследование и обнаружил 101 разницу в тестировании программного обеспечения.Это было основано на ручном тестировании, без автоматизированного тестирования. Если вы чувствуете, что что-то из этого было упущено в списке, прокомментируйте меня.

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

Основы тестирования программного обеспечения: объяснены различиями в условиях тестирования:

1) Разница между верификацией и валидацией

2) Разница между приоритетом и серьезностью

3) Разница между системой тестирование и интеграционное тестирование

4) Разница между повторным тестированием и регрессионным тестированием

5) Разница между нагрузочным тестированием и стресс-тестированием

6) Разница между альфа-тестированием и бета-тестированием

7) Разница между нагрузочным и объемным тестированием

8) Разница между функциональным тестированием и нефункциональным тестированием

9) Разница между тестированием локализации и тестированием глобализации.

10) Разница между интеграцией сверху вниз и интеграцией снизу вверх

11) Разница между статическим и динамическим тестированием

12) Разница между альфа-тестированием и бета-тестированием

13) Разница между отрицательным тестовым примером / тестированием и положительным тестом / testing

14) Разница между тестированием Smoke и тестированием работоспособности

15) Разница между тестированием базы данных и тестированием безопасности

16) Разница между тестированием основного продукта и тестированием конечного продукта

17) Разница между тестированием установки и тестированием удаления

18) Разница между веб-тестированием и тестированием приложений

19) Разница между тестированием системы и функциональным тестированием

20) Разница между тестированием графического интерфейса и функциональным тестированием

21) Разница между тестированием системы и сквозным тестированием

22) Разница между системным и приемочным испытаниями

23) Разница между нет Обычное тестирование и тестирование игр

24) Разница между тестированием черного ящика и тестированием белого ящика

25) Разница между тестовым стендом и тестовой оснасткой

26) Разница между превентивным подходом в тестировании и реактивным подходом в тестировании

27) Разница между Тестирование программного обеспечения и SQA

28) Разница между методом тестирования и техникой тестирования

29) Разница между блок-схемой данных и блок-схемой

30) Разница между инструментом тестирования и методикой тестирования

31) Разница между заглушкой и драйвером

32 ) Разница между идентификатором версии сборки и идентификатором версии программного обеспечения

33) Разница между компанией на основе продукта и компанией на основе проекта

34) Разница между процессом и проектом

35) Разница между анализом граничных значений и разделением эквивалентности

36) Разница между Тестирование ETL и БД

37) Разница между авторизацией и аутентификацией

38) Разница между V-моделью и моделью водопада

39) Разница между потоком бизнес-процессов и сценарием

40) Разница между функцией и процедурой

41) Разница между действием и транзакцией

42) Разница между реализацией и институционализацией

43) Разница между мерами и показателями

44) Разница между статическим и динамическим тестированием

45) Разница между временем отклика и пропускной способностью

46) Разница между автоматической и ручной корреляцией

47) Разница между стандартным журналом и Расширенный журнал

48) Разница между процессом и потоком

49) Разница между версией сборки и версией программного обеспечения

50) Разница между отчетом об ошибках и отслеживанием ошибок

51) Разница между тестовым сценарием и вариантом использования

52) Разница между Тестовый сценарий и тестовый пример

53) Разница между тестами Случай и вариант использования

54) Разница между вариантом использования и псевдокодом

55) Разница между двухуровневой архитектурой и трехуровневой архитектурой

56) Разница между риском и проблемой

57) Разница между обзором и пошаговым руководством

58) Разница между прохождением и проверкой

59) Разница между критериями входа и выхода

60) Разница между проверкой кода и прохождением кода

61) Разница между планом тестирования и стратегией тестирования

62) Разница между основным планом тестирования и План тестирования

63) Разница между тестированием и отладкой

64) Разница между проверкой и тестированием программного обеспечения

65) Разница между согласованной и несогласованной ошибкой

66) Разница между угадыванием ошибок и заполнением ошибок

67) Разница между ожидаемыми результат и фактический результат

68) Разница между официальной проверкой и неформальной проверкой

69) Di Разница между ручным тестированием и автоматическим тестированием

70) Разница между тестированием на совместимость и тестированием на совместимость

71) Разница между тестированием Gorilla и тестированием на обезьянах

72) Разница между инженером по тестированию программного обеспечения и специалистом по тестированию

73) Разница между HTTP и HTTPS

74) Разница между BDD и TDD

75) Разница между UAT и BAT

76) Разница между SDLC и STLC

77) Разница между SIT и IST

78) Разница между CASE и CAST

79) Разница между RTM и TRM

80) Разница между ABI и API

81) Разница между SRS и BRS

82) Разница между HLD и LLD

83) Разница между CMM и TMM

84) Разница между CMM и CMMI

85) Разница между ISTQB и ISEB

86) Разница между подходом, ориентированным на процесс, и подходом, ориентированным на людей

87) Разница Различие между скрытыми и замаскированными дефектами

88) Разница между разработкой и производством программного обеспечения

89) Разница между веб-сайтом и веб-приложением

90) Разница между сборкой и компиляцией

91) Разница между ревизией и версией (контроль)

92) Разница между матрицей прямой и обратной трассировки

93) Разница между проектом и проектом сопровождения

94) Разница между дизайном теста, тестовым набором и процедурой тестирования

95) Разница между клиент-серверным приложением, веб-приложением и Настольное приложение

96) Разница между QA, QC и тестированием программного обеспечения

97) Разница между сборкой, версией и выпуском

98) Разница между ошибкой, дефектом, ошибкой, ошибкой и отказом

99) Разница между ISO, CMMI, IEEE и Six sigma

100) Различия между программным обеспечением, приложением, программой и гаджетом

101) Разница между покрытием заявления, покрытием решений, покрытием кода и покрытием пути

.

Основы тестирования программного обеспечения — Вопросы и ответы на собеседование по тестированию программного обеспечения

Почему вопросы на собеседовании «Тестирование программного обеспечения — Основы тестирования программного обеспечения»?

В этом разделе вы можете выучить и попрактиковаться в вопросах собеседования на основе «Тестирование программного обеспечения — Основы тестирования программного обеспечения» и улучшить свои навыки, чтобы пройти собеседование, конкурсный экзамен и различные вступительные тесты (CAT, GATE, GRE, MAT, Bank Экзамен, железнодорожный экзамен и т. Д.) с полной уверенностью.

Где я могу получить вопросы и ответы на собеседовании «Тестирование ПО — Основы тестирования ПО» с пояснениями?

IndiaBIX предоставляет вам множество полностью решенных вопросов и ответов на собеседование «Тестирование программного обеспечения — Основы тестирования программного обеспечения» с пояснениями. Все студенты и первокурсники могут загрузить вопросы викторины «Тестирование ПО — Основы тестирования ПО» с ответами в виде файлов PDF и электронных книг. Решенные примеры с подробным описанием ответов, даны пояснения, которые легко понять.Посмотреть решение проблем с приятным ощущением и хорошим пользовательским интерфейсом; легко пройти все вопросы и ответы.

Как отвечать на вопросы собеседования «Тестирование ПО — Основы тестирования ПО»?

Вы можете легко ответить на вопросы собеседования по теме «Тестирование программного обеспечения — Основы тестирования программного обеспечения», выполнив упражнения, приведенные ниже.

1. Можете ли вы объяснить цикл PDCA и его место в тестировании?

   Тестирование программного обеспечения — важная часть процесса разработки программного обеспечения.В обычной разработке программного обеспечения есть четыре важных шага, также называемых, вкратце, циклом PDCA (Plan, Do, Check, Act).

   Давайте подробно рассмотрим четыре шага.

   1. План: Определите цель и план достижения этой цели.
   2. Выполнить / Выполнить: В зависимости от стратегии плана, принятой на этапе планирования, мы выполняем соответствующее выполнение на этом этапе.
   3. Проверка: Проверка / тестирование, чтобы убедиться, что мы движемся согласно плану и получаем желаемые результаты.
   4. Акт: Если во время цикла проверки обнаруживаются какие-либо проблемы, мы принимаем соответствующие меры и снова пересматриваем наш план.

   Таким образом, разработчики и другие заинтересованные стороны проекта выполняют «планирование и строительство», а тестировщики выполняют часть цикла проверки. Следовательно, тестирование программного обеспечения выполняется в контрольной части цикла PDCA.

2. В чем разница между тестированием белого, черного и серого ящиков?

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

   Белый ящик Тестирование — это стратегия тестирования, основанная на внутренних путях, структурах кода и реализации тестируемого программного обеспечения. Тестирование методом белого ящика обычно требует детальных навыков программирования.

   Существует еще один вид тестирования — серый ящик тестирование. В этом мы заглянем в тестируемую «коробку» ровно настолько, чтобы понять, как она была реализована.Затем мы закрываем ящик и используем наши знания, чтобы выбрать более эффективные тесты черного ящика.

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

3. Вы можете объяснить тестирование удобства использования?

   Юзабилити-тестирование — это методология тестирования, при которой конечного потребителя просят использовать программное обеспечение, чтобы увидеть, прост в использовании продукт, чтобы увидеть восприятие потребителем и время выполнения задачи. Лучший способ окончательно сформулировать точку зрения потребителя на удобство использования — это использовать на начальных этапах прототип или макет программного обеспечения. Предоставляя заказчику прототип перед началом разработки, мы подтверждаем, что с точки зрения пользователя мы ничего не упускаем.

4. Какие категории дефектов?

   Дефекты делятся на три основные категории:

   1. Неправильно: Требования выполнены неправильно. Этот дефект отличается от указанной в спецификации.
   2. Отсутствует: Заказчик предъявил требование, которое не было выполнено. Это отклонение от спецификаций, признак того, что спецификация не была реализована, или требование заказчика не было должным образом учтено.
   3. Дополнительно: Требование, включенное в продукт, не было выдвинуто конечным потребителем. Это всегда отклонение от спецификации, но может быть атрибутом, желаемым пользователем продукта. Тем не менее, это считается дефектом, поскольку это отклонение от существующих требований.

5. Как вы определяете политику тестирования?

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

   • Определение: Первый шаг, который необходимо сделать любой организации, — это определить одно уникальное определение для тестирования внутри организации, чтобы все придерживались одного и того же мышления.
   • Как достичь: Как мы собираемся достичь нашей цели? Будет ли комитет по тестированию, будут ли планы обязательного тестирования, которые необходимо выполнить, и т. Д.?
   • Оценить: После того, как тестирование внедрено в проект, как мы его оценим? Собираемся ли мы получить показатели дефектов по фазам, программистам и т. Д.Наконец, важно сообщить всем, как тестирование повысило ценность проекта?
   • Стандарты: И наконец, каких стандартов мы хотим достичь с помощью тестирования? Например, мы можем сказать, что более 20 дефектов на KLOC будут считаться ниже стандарта, и для этого необходимо провести проверку кода.

6. На каком основании составляется приемочная карта?

   В любом проекте приемочный документ обычно готовится с использованием следующих входных данных.Это может варьироваться от компании к компании и от проекта к проекту.

   1. Документ с требованиями: В этом документе указывается, что именно необходимо в проекте с точки зрения клиентов.
   2. Информация от клиента: Это могут быть обсуждения, неформальные беседы, электронные письма и т. Д.
   3. План проекта: План проекта, подготовленный менеджером проекта, также служит хорошим исходным материалом для завершения вашего приемочного испытания.

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

.