Тестирование: 20 принципов новичка

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

…а я решилась и проработала там почти год. Этот год стал для меня годом роста, прогресса, развития и новых, интереснейших открытий в 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 пункту причины недоверия вам станут ясны.
image
Инженеров по тестированию, тестеров, тестировщиков часто высмеивают, пародируют, сочиняют про нас демотиваторы и айтишные анекдоты. Значит, они нужны. Для стабильности работы программ, выпуска успешных релизов, отсутствия недовольства клиентов. Настоящий тестер никогда не отойдет в сторону от проблемы, он — часть команды и не важно, какой: модного agile или старой функциональной иерархии.

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

Similar posts

Comments 11

    +2
    Спасибо за такой воодушевляющий пост. Встреть я его на год раньше — понял (и принял) бы большинство этих пунктов значительно быстрее. Буду предлагать его всем новичкам.
      +2
      Спасибо! Увы или к счастью, к нам всё приходит с опытом.
        +1
        Как по мне, так к счастью. Есть одна фраза, которая существует в двух вариантах. Первый — «Умный учится на чужих ошибках, дурак — на своих». Но лично мне больше нравится второй — «Мудрый человек учится на чужих ошибках, умный — на своих, дурак не учится вообще. Если не удалось быть мудрым, не останься дураком.»
        Если нам с опытом что-то приходит, значит велик шанс, что мы не оказались в «третьем эшелоне знаний».
      0
      Полтора года на основы? А что это за институт?
        0
        Ответила в личные сообщения, иначе реклама получится какая-то. Кстати, полтора года для основ это не так и много, всего 500 часов вышло (для работающих людей все-таки), а там и С, и С++, и Java, и скриптовые языки. Плюс администрирование Unix, алгоритмизация, тестирование и проектирование ПО.
          0
          Спасибо.
          Да, с таким достойным перечнем времени надо побольше. Теперь я вам завидую.
            +1
            Поделитесь, пожалуйста, названием вуза. Я-то сам тестировщик, а вот друг очень хочет им стать.
          0
          Интересно, что побудило вас сменить спеицальность, помимо вовремя приобретенной новой профессии? Что было «не так» с оценкой рисков и бизнес-процессов?
            +1
            Было несколько причин:
            1. компания перешла в руки другому собственнику и бизнес процессы стали строиться по принципу «russian business», а софт стал покупаться не по принципу оптимальности и удобства, а по принципу откатов
            2. зарплата стала значительно ниже рынка, если тестировщиком я получила на треть больше
            3. в нашем городе (не столица) подобных вакансий практически нет, они занимаются своими людьми и очень быстро

            Однако могу сказать, что сейчас я работаю в маркетинге крупного IT-бизнеса и все полученные навыки в сфере информационных технологий удачно сочетались с профессиональным опытом и в итоге дают очень неплохие плоды.
              +1
              По поводу последнего совершенно согласна, в том числе и по собственному опыту, так что считаю что переквалифицироваться в тестировщика никогда не поздно :)
                0
                Это точно, тем более, что «взрослых» берут охотнее и сразу на должность инженера. У нас обычно тестировщики от 18 до 22 + тимлиды от 28. Серьезных ребят, понимающих дело, очень не хватает.

          Only users with full accounts can post comments. Log in, please.