Home

Автор: Урида (Uridah)

Оригинал статьи: https://qafrenzy.wordpress.com/2016/12/21/never-failing-testing-hack-know-the-software-system/

Перевод: Ольга Алифанова

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

Покопайтесь в нем

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

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

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

Копайте глубже

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

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

Коммуникация и обратная связь

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

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

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

Учитывайте предыдущий опыт

Я имею в виду все и вся, что происходило с системой ранее. Краши, баги, изменения, фичи – все, что менялось в ПО. Суть совета в том, чтобы атаковать эти "горячие точки". Учитывайте эти изменения и тщательнее тестируйте рядышком с ними, чтобы убедиться, что они ничего не сломали. Здесь возможны различные подходы в зависимости от системы. Один из них, довольно неплохой и широко используемый – автоматизация регресс-набора тестов и их запуск каждый раз, когда в ПО заходит баг-фикс или изменение.

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

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