День тестировщика-2019: баги не пройдут!

Война с букашками

Сейчас даже первоклассник знает, что ошибка, обнаруженная в программе, называется багом. Традиционно принято толковать термин баг (bug) как “жук”, “букашка” в переводе с английского (но это не точно – ниже расскажем, почему))). Баг в программном обеспечении продуцирует дефект ПО, который может привести к сбою программы.

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

Учение о том, как бороться с багами, построено на пяти принципах, один из ("Избыточное тестирование невозможно") которых признаёт, что баг – это часть мироустройства, как Солнце и крепатура после первой тренировки. Поэтому баги вечны, как и война с ними.

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

В зависимости от степени зловредности бага, он может влиять на систему по-разному. На этом и строится классификация багов:

• Blocker – блокирующий: особо вредный тип, который считает багом сам факт работы приложения; это именно он причина крэшей сразу после запуска программы;
• Critical – критически пакостный баг: затрудняет работу программы чуть больше чем полностью, либо серьезно нарушает бизнес-логику приложения; подлежит безжалостной и незамедлительной ликвидации;
• Major – баг с чувством особой значимости: ведет себя так, как будто он в программе основной и сам решает, как и чему работать, и что в бизнес-логике приложения (по его мнению) стоит изменить; его ликвидируют, как правило, быстро, не считаясь с его мнением о поведении продукта;
• Minor – мелкий баг, который есть, но работу программы сильно не нарушает; часто в эту категорию относят баги в дизайне или контенте;
• Trivial – просто мелочь пузатая; на работе приложения не сказывается, дизайн сильно не ломает; его можно исправлять в последнюю очередь; к таким багам обычно относят очепятки и ашипки в контенте или небольшие несоответствия дизайна мокапу (толщина линий, тип шрифта и пр.).

Отдельная категория – это не баг, а фича. По легенде, эта классическая фраза была придумана ленивым разрабом как отмазка, чтобы не фиксить баг. Заодно она позволяет прокачать ЧСВ девелопера до заоблачных высот, как бы намекая на недалекость юзера, неспособного отличить фичу от дефекта.

Почему они баги?

Боевые действия против багов называются дебаггингом – от английского debugging: отладка, исправление. В современной лексике этот термин трактуется как избавление от букашки, с отсылкой на апокрифическую историю, датированную то ли 1945, то ли 1946, то ли 1947 годом – археологи путаются в показаниях.

Сходятся в одном: в отчет об эксперименте с компьютером Mark II Aiken Relay Calculator от 9 сентября [одного из вышеперечисленных годов] гарвардские ученые вклеили скотчем останки мотылька, сопроводив комментарием: Первый случай, когда жук действительно был обнаружен (First actual case of bug being found).

Фразу эту приписывают одной из участниц исследовательской группы Грейс Хоппер (Grace Hopper), женщине с легендарной биографией и внушительным списком личных достижений в области программирования. Удивительная была личность, коммодор американского флота, писавшая компьютерные программы, придумавшая первый компилятор и разработавшая концепцию, которая легла в основу знаменитого языка программирования COBOL. Но сейчас не о ней речь.

Вернемся к нашим букашкам. Короче, несчастное чешуекрылое обвинили в том, что именно в нем причина постоянных сбоев компьютера Mark II – мол, застрял крыльями в реле, замкнул систему, комп сдох, ой, всё. И почему-то история происхождения терминов bug и debugging в массовом сознании неразрывно связана с контр-адмиралом Удивительной Грейс, как ее ласково называют соотечественники, а сам день, когда насекомое совершило суицид в стенах Гарварда, объявили праздником всех, кто причастен к проверке систем, программ и приложений на работоспособность и поиску багов. В общем, 9 сентября отважные багоборцы с полным правом могут купаться в фонтанах и вытворять всякие всякости, как заведено по традиции.

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

Есть и третий вариант этимологии слова баг. Между нами, он выглядит наиболее логичным , да и англоязычная Википедия думает так же. По слухам из достоверных источников, в мифологии древних британцев задача пугать маленьких детей лежала на специально прокачанном под этот функционал существе из рода фейри (fairy) – Bugaboo, или Bugbear, или же просто Bug. Телесных повреждений детям он не наносил, в доме беспорядка не учинял – просто парню не очень повезло с внешностью. Ну, там, шерсть клочьями, горящие глаза, острые зубы, когти-с… Да, не Крис Хемсворт, но не всем же счастье! В общем, пока славянских карапузов пугали бабайкой, британская малышня визжала в ужасе, едва заслышав имя Бага.

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

Тестировщик или QA?

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

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

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

Часто багоборцев называют тестировщиками. Но правильнее все же именовать их QA – от англоязычной аббревиатуры выражения Quality Assurance. Его можно перевести как обеспечение надлежащего качества. То есть человек, занимающийся QA, не просто находит баги, классифицирует их, описывает в баг-репортах и отправляет на исправление разработчикам. Работа QA – сложная и многогранная. Для того, чтобы ею успешно заниматься, надо знать как минимум основы программирования, HTML и CSS, архитектуры систем, работы БД (владение SQL просто маст хэв), нужно разбираться в специфике отрасли, для которой делается продукт (игры, финтек и т.д.), понимать, что такое кроссплатформенность, обладать аналитическим складом ума и хорошей интуицией, да и креативность не будет лишней. А из soft skills, необходимых в работе QA, обязательны внимательность, способность концентрироваться, пунктуальность, аккуратность. Очень важна коммуникабельность: чтобы еще на стадии согласования ТЗ задать заказчику все уточняющие вопросы об ожидаемом поведении элементов программы – например, куда ведет форма обратной связи, что произойдет при нажатии кнопки, где разместить дополнительную информацию и пр. Во взаимодействии с разработчиками критически необходима настойчивость и тактичность, – чтобы деликатно пояснить с аргументами, что найден именно баг, а не фича, и убедить девелопера исправить ошибку.

Тестирование бывает мануальным – и тут, кажется, все понятно: используешь глазки-ручки, всё свое. На первых порах можно даже не углубляться в специальные предметные дисциплины, хотя знание не бывает лишним. А вот если заниматься автоматизированным тестированием, тут точно не обойтись без специальной подготовки, поскольку написание автотестов очень сильно напоминает программирование (только тс-с-с, не говорите этого настоящим программистам! ;).

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

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

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

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

С днем тестировщика всех! Happy QA Day!