Как да тествате приложението си преди пускане: практически план

За да тествате приложението си преди пускане, изброете малкото пътища, които потребителят трябва да може да завърши, изпълнете всеки от тях като напълно нов потребител на лаптоп и на телефон, след това опитайте начините, по които може да се обърка: празни данни, грешен вход, втори акаунт, бавна връзка. Тествайте внимателно всичко, свързано с пари или лични данни, и повторете основните пътища на живия URL след публикуване. Накрая наблюдавайте някой, който никога не е виждал приложението, как се опитва да го използва.

За това не са ви нужни екип за качество или рамка за тестване. Нужни са ви списък, час-два и дисциплината действително да минете през него.

Стъпка 1: Запишете пътищата, които имат значение

Път е задача от начало до край, която потребителят идва да изпълни. Повечето приложения имат три до шест, които наистина са важни. За приложение за резервации:

1. Регистрация и потвърждение на акаунта
2. Намиране на час и резервирането му
3. Отмяна на резервация
4. Плащане за абонамент за часове
5. Персонал: преглед на днешните резервации

Ако сте написали потребителски истории, техните критерии за приемане вече са вашите тестови случаи. Ако не, напишете по един ред за всеки път с това, как изглежда „успех“.

Подредете ги по приоритет. Пътищата, които носят пари или които всеки потребител минава (регистрация, вход, основното действие), се тестват първи и най-много.

Стъпка 2: Тествайте щастливия път като нов потребител

„Щастливият път“ е пътят, който върви точно както е замислен. Тествайте го така, както би го преживял непознат:

• Използвайте прозорец за private браузване, за да не сте влезли и да нямате запазени данни.
• Използвайте нов акаунт с реален имейл, който можете да проверите.
• Започнете от началната страница или от линк, а не от страница, която сте запазили в отметки, докато сте строили приложението.

Новите потребители нямат данни. Много грешки се появяват само когато списък е празен, профил няма снимка или още нищо не е купено. Вашият собствен акаунт, пълен с тестови данни, ги скрива.

Стъпка 3: Опитайте да го счупите

Сега повторете всеки път и направете умишлено грешното нещо.

Презареждането си заслужава специално внимание: ако приложението работи, когато кликате, но презареждането на по-дълбока страница показва 404, вижте как да поправите грешки 404 след публикуване.

Стъпка 4: Тествайте правата с два акаунта

Това е най-важният тест за всяко приложение с акаунти и този, който най-често се пропуска.

Създайте двама обикновени потребители, A и B, и (ако приложението ви ги има) администратор.

• Като A създайте запис. Влезте като B. Може ли B да го види, редактира или изтрие? Не трябва, освен ако не е така замислено.
• Като A копирайте URL на един от вашите записи. Влезте като B и отворете този URL директно.
• Като обикновен потребител отворете административните страници, като напишете техните URL адреси.
• Излезте напълно и опитайте същите адреси.

Ако намерите проблем тук, не пускайте, докато не се оправи. Проверката трябва да се извършва на сървъра, а не само със скриване на бутон. Нашият контролен списък за сигурност за приложения, създадени с AI е по-подробен.

Стъпка 5: Тествайте на реални устройства

Отворете приложението на истински телефон, не само в тесен прозорец на браузъра.

• Можете ли да докоснете всеки бутон без увеличение?
• Клавиатурата покрива ли полето, в което пишете?
• Таблиците и широкото съдържание се плъзгат ли или се пренасят, вместо да избутват страницата встрани?
• Текстът четлив ли е без събиране с пръсти?

Опитайте поне един iPhone (Safari) и един Android телефон (Chrome), ако можете да ги заемете. Safari особено има собствени особености с датите, видеото и елементите с фиксирана позиция.

Стъпка 6: Тествайте плащанията и имейлите от край до край

Всичко, което таксува карти или изпраща имейли, се нуждае от пълна проверка.

Плащания. Използвайте тестовия режим на вашия доставчик на плащания и тестовите номера на карти. Проверете успешно плащане, отхвърлена карта и отказано плащане. Уверете се, че поръчката или абонаментът се появяват в приложението след плащането, а не само в таблото на доставчика. Ако приложението ви разчита на webhook-ове (съобщения, които доставчикът на плащания изпраща към вашия сървър), проверете дали пристигат в публикуваното приложение, а не само в разработката. След това, преди пускане, превключете на живи ключове и направете една малка реална покупка, която ще върнете.

Имейли. Регистрирайте се с реални адреси при два или три различни доставчика. Проверете дали имейлите пристигат, не попадат в спама и дали всеки линк в тях сочи към живия домейн, а не към адрес от прегледа.

Стъпка 7: Проверете скоростта и грешките

• Отворете инструментите за разработчици в браузъра (с десен бутон → Inspect) и разгледайте таба Console на всяка основна страница. Червените грешки си заслужава да се оправят, дори да изглежда, че нищо не е счупено.
• Заредете сайта на телефон с мобилни данни, не през Wi-Fi. Ако първият екран отнема няколко секунди, проверете първо размерите на изображенията.
• Пуснете безплатен одит като Lighthouse в инструментите на Chrome за бърза оценка на производителността и достъпността.

Стъпка 8: Тествайте публикуваното приложение, не само прегледа

Прегледът и публикуваното приложение не са една и съща среда. Преди да съобщите на някого за пускането, повторете основните пътища на живия URL:

• Всички променливи на средата и тайни ключове ли са зададени за публикуваното приложение?
• Използва ли се правилната база данни, с данните, които очаквате?
• Пренасочванията при вход и линковете в имейлите използват ли живия домейн?
• Презареждането на дълбока страница зарежда ли се правилно?

Стъпка 9: Гледайте някой друг как го използва

Дайте на един или двама души цел („запазете час за йога в събота“), а не инструкции. Наблюдавайте, не помагайте, и записвайте къде се колебаят. Това е най-бързият начин да откриете объркващи формулировки и скрити бутони. За по-голяма версия на това вижте как да проведете бета тест.

Когато срещнат грешка, я запишете правилно, със стъпките, очаквания резултат и действителния резултат. Нашето ръководство за писане на добър доклад за грешка показва формата.

Използване на AI за помощ при тестването

Ако създавате с AI, можете да го помолите да помогне за планиране и провеждане на тестове:

Изброй основните потребителски пътища в това приложение и за всеки от тях — граничните случаи, които най-вероятно ще се счупят: празни състояния, невалиден вход, права и презареждане. Сложи го в контролен списък, който мога да следвам.

Влез с двама различни тестови потребители и провери дали потребител B може да вижда или променя нещо, създадено от A, включително като отвори директно URL адресите на записите на A. Докладвай какво откриваш, преди да поправяш каквото и да е.

Третирайте собствения доклад на AI за тестване като първо предварително преминаване. Все пак минете през пътищата за плащания и права сами.

Тестване в Mythex

В Mythex командата /test стартира App Testing: агентът управлява браузър срещу вашия жив преглед, кликва през страниците, прави снимки и докладва счупените потоци в чата. Работи най-добре с конкретен път, например „тествай регистрация и резервиране на час“. Оправяйте откритото с /fix или с обикновено съобщение, след което пуснете /test отново. App Testing използва прегледа, затова след публикуване проверявайте основните пътища на публикувания URL сами. Вижте App Testing в документацията и нашето ръководство за отстраняване на грешки в приложение, създадено с AI, когато нещо се провали.

Често срещани грешки

• Тестване само като себе си. Вашият администраторски акаунт с много данни скрива грешките при празни състояния и права.
• Тестване само на лаптоп. Много сайтове получават повечето посетители от телефон.
• Пропускане на втория акаунт. Изтичането на данни между потребители е най-сериозната грешка, с която едно приложение може да бъде пуснато.
• Доверяване на прегледа. Живото приложение има различни настройки; тествайте и него.
• Оправяне на грешки без повторно тестване на съседни части. Корекция на един формуляр може да счупи друг, който споделя код.

Контролен списък преди пускане

• Основните пътища са записани и подредени по приоритет
• Всеки път минава за нов потребител в private прозорец
• Празен, невалиден, дълъг и дублиран вход са обработени
• Презареждането работи на всяка страница
• Потребителите не могат да виждат или променят данните си един на друг, дори през URL
• Административните страници са блокирани за обикновени потребители и за посетители без вход
• Работи на реален iPhone и Android телефон
• Плащанията са тествани: успех, отказ, отмяна и приложението се обновява след това
• Имейлите пристигат, не попадат в спама и сочат към живия домейн
• Няма червени грешки в конзолата на основните страници
• Основните пътища са повторени на публикувания URL
• Поне един външен човек го е пробвал, докато сте наблюдавали

Въпроси