Usein kysytyt kysymykset
Seuraavat ovat Guru99-yhteisön useimmin kysytyt kysymykset
- Etkö näe videoita?
- En saanut projektia varten sähköpostia
- Jos saan sovelluksessa virheen, kuka päättää vian vakavuuden ja tärkeysjärjestyksen?
- Mitä teet, jos Funct.Spec-tiedostoa tai järjestelmään liittyviä asiakirjoja ei ole?
- Mitä testaaja voi tehdä, jos hän havaitsee ohjelman keskeytysongelman muutama päivä ennen julkaisua?
- Miksi valitset ohjelmistojen laadunvarmistuksen alan?
Etkö näe videoita?
Kaikki tämän sivuston videot isännöidään osoitteessa YouTube ja upotettu tähän…
Olet luultavasti pääset verkkosivustolle paikasta, jossa YouTube on kielletty (yrityksesi, korkeakoulu tai maa, jossa YouTube on kielletty)
Yritä käyttää videoita rajoittamattomasta ympäristöstä.
Teet ÄLÄ täytyy rekisteröityä nähdäksesi videot.
En saanut projektia varten sähköpostia
Huomaa, että projektisähköpostit lähetetään 24 tunnin välein. Joten jos tilasit torstaina klo 10, saat seuraavan sähköpostin perjantaina klo 10.
Tarkista roskapostisi tai roskapostisi Maillaatikko. Jos käytät gmailia, tarkista Promovälilehti
Järjestelmässämme ei ole ominaisuutta sähköpostien uudelleenlähettämiseen. Jos et edelleenkään jäljitä sähköposteja, tilaa sisältö toisella sähköpostitunnuksella.
Jos saan sovelluksessa virheen, kuka päättää vian vakavuuden ja tärkeysjärjestyksen?
Vakavuus Vika määrittää ongelman tunnistava henkilö (testaaja), kun taas prioriteetin määrittää ongelman korjaamiseen osallistuva henkilö (kehittäjät).
Testaajana voit priorisoida viat, jotka testijohto yleensä tarkistaa. Kehittäjät päättävät analysoinnin jälkeen, onko kyseessä korkean prioriteetin vai matalan prioriteetin vika. Suurimman osan ajasta sen tekee kehittäjä, mutta myös testaaja voi osallistua siihen selittääkseen sen vakavuuden. Keskustelun jälkeen johtopäätökset päätyvät.
Vakavuus liittyy pohjimmiltaan sovelluksen tai tuotteen toimivuuteen. Tärkeintä on kuitenkin se, kuinka välittömästi kehittäjä voi korjata kyseisen bugin tai vian. Prioriteetti on luonteeltaan dynaaminen, ja se muuttuu skenaarion mukaan, kun taas vakavuus on luonteeltaan staattista.
Mitä aiot tehdä, jos järjestelmään ei ole toiminnallisia tietoja/asiakirjoja?
- Yritä ensin ymmärtää aluetta yritysanalyytikoiden tai pk-yritysten kanssa. Tee tutkiva testaus ymmärtääksesi järjestelmän.
- Jos hankkeella ei ole Business Analyst tai pk-yrityksiä, keskustele vastaavien järjestelmien parissa työskentelevien ihmisten kanssa.
- Ymmärtääksesi liiketoiminnan keskustele käyttäjäyhteisön kanssa
- Katso samanlaiset tuotetiedot Internetistä tai PMO:sta
- Etsi samantyyppistä sovellusohjelmistoa ja ymmärrä sen ominaisuudet
- Etsi tärkeitä liiketoimintaskenaarioita, vaihtoehtoisia asiakirjoja ja sovellusaiheisia artikkeleita
- Kysy kehittäjiltä selitys kaikista moduuleista
- Käyttäjähistoriatiedot, sovellus ja ominaisuudet
- Älä testaa sovellusta teknisesti, vaan ensin testaa sovellustasi vain käyttäjän näkökulmasta
Mitä testaaja voi tehdä, jos hän havaitsee ohjelman keskeytysongelman muutama päivä ennen julkaisua?
- Vahvista ja vahvista Vika uudelleen ja dokumentoi virhe tai vika, vaikutus ja mahdollinen ratkaisu, jos voit.
- Ota tämä esimiehen tietoon ja keskustele asiasta tiimin kanssa, sillä tällainen näyttelyn pysäyttäjä on tiimille tuntematon viikkoa ennen sen julkaisua, ei ole hyvä.
- Kun Vika saavuttaa esimiehesi ja korkeammat testausviranomaiset, saatat joutua esittämään näkemyksesi heille, joten ole perusteellinen, sillä se voi vaikuttaa julkaisuun.
- Jos keskustelu tukee sinua, on sinun aikasi nousta ja loistaa. Jos ei, sinulla on päivän oppitunti takeawayksi. Jatka oppimista.
Miksi valitset ohjelmistojen laadunvarmistuksen alan?
Laadukkaiden projektien tarjoamiseksi loppukäyttäjille tai asiakkaille testaus on pakollista riippumatta siitä, mitä koodausta se sisältää. Ohjelmiston laadunvarmistus ei vain kirjaa vikoja, vaan tarjoaa myös ratkaisuja niihin.
Laadunvarmistusalalla testaajan tulee olla tietoinen testattavan sovelluksen kaikista toiminnallisuuksista, jolloin hän tietää eri ympäristöissä kehitettävistä erilaisista sovelluksista, jopa ohjelmoinnin peruskäsitteitä. Tieto on laajempaa, kun teemme testausta, mutta se on kapeaa ohjelmoinnin aikana. Kehittäjä saattaa kehittää vain pientä osaa koko sovelluksesta eikä välttämättä ole tietoinen sovelluksesta kokonaisuudessaan. Tässä tapauksessa QA (testaajan) rooli tuntui kiinnostavammalta.