Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Quality Assurance Guidelines for Mobile App Development

884 views

Published on

An overview of our QA guidelines. From review and automated testing to regression testing

Published in: Mobile
  • Could you use an extra $1750 a week? I'm guessing you could right? If you would like to see how you could make this type of money, right from the comfort of your own home, you absolutely need to check out this short free video. ■■■ http://scamcb.com/ezpayjobs/pdf
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • If you want to enjoy the Good Life: making money in the comfort of your own home with just your laptop, then this is for YOU... ●●● http://t.cn/AieXAuZz
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • D0WNL0AD FULL ▶ ▶ ▶ ▶ http://1lite.top/6qBko ◀ ◀ ◀ ◀
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Create Your Own Odds Playing The Lottery ♥♥♥ http://t.cn/Airf5UFH
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Watch My Free Video Packed with My Best Secrets Here ●●● https://tinyurl.com/t2onem4
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Quality Assurance Guidelines for Mobile App Development

  1. 1. Moqod quality assurance guidelines
  2. 2. quality standards
  3. 3. 02 Vision: At Moqod it’s our main goal to deliver high-quality software. Ideal world software quality standard is completely bug-free software. We strive to deliver bug-free software. Definition of a bug: Bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. (Wikipedia). key points
  4. 4. 03 Quality standards: Therefore software quality standard at Moqod is simple and straight forward - “Software functions as expected”. As expected means as specified and described in the project functional documents and artefacts. But this doesn't mean blindly following the docs. Because of continuous communication with the customer, “software functions as expected” also means - as expected by the customer and the end-user. key points
  5. 5. 04 The following points apply to all projects to ensure highest possible quality of the software products: ● Moqod employs a dedicated full-time QA engineer. ● QA engineer must be introduced to the project at the earliest stage possible. ● All issues must be reported and document to a tracking system! Otherwise the issues can be disregarded. This concerns all project stakeholders (dev team, QA engineers, PMs, Customers etc). general rules
  6. 6. 05 ● QA engineer at Moqod is the main quality gate. ● We praise proactive approach in solving problems. This includes: fast reaction on reported issues, self-driven problem solving, looking at all possible sources to quickly localize and solve a problem. ● We praise transparency through our whole workflow. The customer is in direct contact with the team and is encouraged to ask/answer questions from the team. ● Device, browser and OS compatibility will be stated in the project specification. The product will be tested in these environments. general rules
  7. 7. 06 software development quality gates at moqod Code review Automated test scripts (optional) Manual testing Regression tests (Manual and automated)
  8. 8. code review process
  9. 9. 08 Code review is the first step in delivering quality software. It helps to identify potential errors at early stages. Currently at Moqod P2P code review is in place. Code review is done in the following way: 1. All developers pair up. 2. Every day every developer spends up to one hour to review the code of his partner. One developer shows pull of changes during the last 24 hours and describes the tasks he had to resolve. His partner evaluates the solution and adds his comments or suggestions. Once the review is done, developers switch roles. 3. Every month tech lead reviews and when needed changes the pairs. code review process The main advantage of this approach is that the reviewer understands the context and all details of the solution from his partner.
  10. 10. Automated test scripts AWS Device Farm
  11. 11. 10 For the maximum coverage of test devices Moqod offers automated testing using Amazon Device Farm and automated test scripts. This is an optional item that can be added to a project quote. How this works: 1. Create a list of test cases for the app. Coverage to be discussed. 2. For iOS Apple UI automation is used as an instrument. For Android Robotium Framework. 3. These scripts will be run on AWS Device Farm to perform the test cases on the target devices. 4. Afterwards the test scenarios can be run at any time with a mouse click, automating regression tests. Important: AWS Device Farm uses real devices, so we get a coverage and environment close to real life. Automated test scripts AWS Device Farm
  12. 12. 12 It is highly recommended to cover backend (web API calls, database calls, front end and admin section) with unit tests and run these automatically on staging environment with every deploy. This ensures all APIs and so clients (mobile, front-end etc) will remain intact and will funcion properly. Otherwise, the problem can be identified at the moment changes are deployed to staging. API Unit tests
  13. 13. 13 Due to the specific nature of mobile development (data access, device location, different hardware and software environments etc) manual testing is the key component in QA process. During the manual testing we use various monkey scripts and monitoring tools for all mobile platforms. Manual testing process
  14. 14. rules and guidelines for manual testing process
  15. 15. 15 1. QA engineer reviews project documentation.
 a. Documentation is sufficient – go to step 2. b. Otherwise, the documentation is to be revised by the Customer and PM. 2. QA engineer estimates the amount of work needed for testing. 3. The team plans iterations and release dates for interim milestones and final release. Stage 1. QA Planning
  16. 16. 16 1. At the end of every iteration upon delivery of an interim milestone a testing round is held. a. Functional tests are executed on newly delivered features. b. Regression tests are executed on previously delivered features. Stage 2. Interim release testing
  17. 17. 17 2. The results of interim release test are: a. Delivery successful. QA engineer approves the release. The build is sent to customer together with a short report containing release notes. Go to step 3. b. Delivery failed. QA engineer rejects the release. The build is not sent to customer. A report with action plan is provided to customer. The release is sent back to dev team for the needed fixes. However, a PM can still provide the build to Customer to showcase the progress. Stage 2. Interim release testing
  18. 18. 18 3. Customer receives the build. Possible actions: a. Customer accepts the build and signs off the milestone as is. b. Customer rejects the delivery and the release is sent back to dev team for the needed fixes. c. Customer accepts the build and signs off the milestone, but with minor feedback and comments. This feedback is added to backlog for future releases. Stage 2. Interim release testing
  19. 19. 19 1. Upon reaching final milestone a complete acceptance test is executed on the product. QA engineer reviews all use cases to check against the actual functionality of the product. 2. GUI testing is held on the final delivery. All screen dimensions, fonts and colors need to be checked. Stage 3. Final release. Acceptance testing.
  20. 20. 20 3. The results of Acceptance testing can be: a. Release accepted by QA engineer. The build is sent to customer accompanying acceptance report. The report contains a list of all use cases and test results against the use cases (success/failed). The product is provided to customer for sign off. b. Release is rejected by QA engineer. The product is not provided to customer for acceptance. A report with further action plan is sent. Stage 3. Final release. Acceptance testing.
  21. 21. 21 4. Customer reviews the final product delivery: a. Customer accepts the delivery and signs off the project. The product is processed to Store upload or live environment. b. Customer accepts the delivery and signs off the project, but with some comment or improvements. The product will still be sent to store or live environment. The feedback will be taken into new version of the product as a separate statement of work c. Customer rejects the delivery and the release is sent back to dev team for the needed fixes. Stage 3. Final release. Acceptance testing.
  22. 22. QA Engineer responsibilities and authorities
  23. 23. 23 At Moqod a QA engineer is the main jury who is in charge to accept or reject the work. The list of responsibilities of a QA engineer is the following: ●  Accept/reject deliveries. ●  Help find the root cause of a problem. ●  Review and accept/reject project documentation. ●  Report to PM and dev team upon results of testing. ●  Set specific rules for QA process on projects. ●  Ensure all project stakeholders follow the rules and process. QA Engineer responsibilities and authorities
  24. 24. 01 MQD BV Amsterdam, the Netherlands +31 20 893 2331 info@moqod.com

×