Blog

Test Expo 2017

Last Tuesday I attended TestExpo 2017.

Since I switched back into testing, I have tried to read more about the changes in this field so that I’m more informed and in a better position to make decisions about the direction we take for QA within my day job and my personal projects.

Why is going to conferences and events good in general?

As I mentioned in my previous post, Ways to keep up your development skills as a Test Engineer, going to events like conferences or  meet ups are great for improving your technical knowledge. But, they are also great environments to flex your social muscles and converse with your peers.

Learning to approach and make conversation with complete strangers is a soft skill that everyone should look to be improving. But more than that, it gets you out of your comfort zone of interacting with the same circle of people that you deal with everyday.

Putting yourself in uncomfortable situations makes you grow by building skills you wouldn’t normally use.

Being in a place where the majority of people are dedicated to improving the quality processes and products was definitely an unusual but brilliant feeling. As I tester, particularly in agile teams, you’re outnumbered by “sole” developers (those whose main role is development). This may lead to situations where you have to champion your opinions in order to get things changed for the better. So being in an environment so different to my day to day life instantly lifted some of my nerves.

Event Vendors

At these types of events there are always opportunities for sponsored partners or vendors promoting their products.

My advice for dealing with vendors is to find out exactly what they do and only give your contact details to those who have products that you know may be useful in the future to your goals. Otherwise you could open yourself up to a lot of LinkedIn requests. By all means take as much information away, but be clear that you’ll be assessing what they have and whether it’s inline with what you want to achieve. You’ll contact them, not the other way around. It sounds a bit harsh, but in all fairness, you don’t want to waste anyone’s time, yours or theirs if their product isn’t what you’re looking for.

The vendors at this event were very honest and helpful and I got some great information in the form of the World Quality Report 2017  from Sogeti.

TestExpo talks

The day was arranged into series of talks and a round table (group discussion) session.

There were three specialty tracks being covered during the day at the event: Testing, Agile and DevOps. After the keynotes were finished, you could decide to pick and choose between talks from other tracks which I found was great as your interests may not solely be about testing.

The programme list for the day can be found on their website.

I chose to attend the talks within the Testing track. In total I attended all but one of the day’s talks (I did manage to get hold of slides from the talk that I missed so I wasn’t too disappointed).

Best talks

My favourite talks of the day were:

  • Keynote: Becoming a Unicorn
  • The core competencies of a good tester

Both of these talks made me think the most and gave me a list of actionable tasks that I believe will make me a better test engineer.

Top takeaways

  • Make UI automation tests cover key user journeys and smoke tests  and ensure a good ROI
  • The values and benefits gained from good QA should be:
    • Intelligable
    • Trackable
    • Testable
  • You should aim to deliver quantifiable results that support the business values and it’s qualities.
  • Build dashboards to share throughout the company’s teams to share quantifiable results
  • The soft skills of QA engineer are just as important as their technical and analytical skills.

Overall

There was lots of actionable information for me to think of ways to improve the testing practices that I’m currently implementing. The content was a nice mix of beginner/refresher and new/intriguing tech. The attendees were very approachable and friendly and the venue, although a bit far out (near Heathrow!), was a lovely building.

I’d definitely recommend anyone with an interest in testing going next year!

How Important Is CI and CD For An Appreneur?

Here’s my next post which appeared first on Simple Programmer..

During the day, I work as a test engineer. But I also consider myself a developer—more specifically, an appreneur.

What is an appreneur? Why, it’s any entrepreneur trying to build a business via mobile applications. You could be producing templates for others to use, creating apps to sell directly on the app stores, or providing a number of other services reliant on mobile applications.

I work by myself, so I’m running a business solo. Most appreneurs work in this way, though a few have a small team of trusted contractors handling specialized jobs.

It’s important to find tools and processes to help you continue to maintain the quality of your app once it is launched. Especially if it’s just you; you want to spend more of your time and resources creating and launching new products than maintaining older ones.

You want to reduce the time you spend on individual tasks, improve the quality of your end product, and reduce the cost of your overall efforts, and you need to carefully consider what might be the right tools to help you do all that.

Continuous integration and continuous development have been used by project development teams for many years to make the development process more efficient and get better end results. Can we use the same processes as appreneurs?

As an appreneur, I’m the one responsible for the design, development, testing, and business activities involved in creating and releasing a product to market. Make no mistake, completing one of these projects is no small feat.

If you are an appreneur, you are probably trying to increase or update your range of apps being sold in the App Store, or expand your catalog into a new App Store ecosystem, or create a new sustainable revenue stream related to app development. It all depends on where you are in your business.

Regardless of what specific paths you are pursuing, you are certainly hard at work, juggling multiple activities and milestones and products for your business. Even if you have a small team of contractors, you’re still overseeing the whole thing. Add to that all the pressures and distractions of life, and you’re managing a lot.

Continuous integration and continuous deployment were designed to let teams function better and create a smoother workflow. Generally, they’re used when you’ve got a lot of people working on a product or project to decrease confusion, potential bottlenecks, and the possibility of releasing products with issues. With appreneurs, it’s just you or a small team—will these processes actually help?

Let’s look at what exactly continuous integration and continuous development are, discuss some of the advantages and drawbacks, and then talk about if they are right for you as a solo or small team appreneur.

What is Continuous Integration?

Continuous integration (CI) is the practice of merging development branches that have been verified into a single, shared repository several times a day. CI is used by established and professional businesses across various sectors.

Developers use CI to avoid integration hell, the problem where conflict resolving battles are waged against merging multiple code branches into one shared location.

The concept of CI was adopted into the practice of extreme programming (XP) (which was designed to improve software quality and responsiveness) to be used in combination with automated unit tests that would automatically run in the developer’s local environment before commits to the mainline branch would occur.

A commit is the act of moving your development code from your local repository to the remote repository. Once the code has all passed these automated tests (which are run on build servers), commits to mainline (which is the shared repository) are accepted.

These automated tests are run on build servers (usually set up by people with experience with CI and CD tools like DevOps or test engineers) after a build is successful.

This process helps avoid one developer’s work-in-progress breaking another developer’s features. It also means that developers can be more confident that if the tests fail, then their work won’t make it into the production environment or, worse, into their customers’ hands with bugs.

XP is not usually adopted by solo developers or small teams; it is generally used by larger, professional, established product teams. CI isn’t a process specifically for appreneurs developing apps, but it is a general practice that can be adopted by anyone developing software.

Common Tools for CI

At the time of writing, the most common CI tools are:

  • Jenkins
  • TeamCity
  • Travis CI
  • Go CD
  • Bamboo
  • GitLab CI
  • CircleCI
  • Codeship

For a more detailed explanation about all of the above tools, please see this excellent article on Code Maze.

What Is Continuous Deployment?

Continuous deployment (CD) continually releases updates to the production environment after changes to the product are verified by automated tests at various stages through the development process. It is also used by established and professional businesses across various sectors.

CD tools are used in a chain of events, so when one step in the workflow is successful, the next is kicked off. When that is successful, the next begins. This practice means that no manual intervention is necessary to deploy to production.

The process works step by step until it gets to the production environment. If at any point a step fails, the appropriate people are alerted and fixes are made to ensure the process starts and runs again successfully.

Using CD in conjunction with CI means that development teams should have less chance of releasing products with issues to customers.

Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements. Because it automates the process, it won’t be held up by errors or a forgotten step, and it also means that a failed step can’t be missed.

Again, CD isn’t specifically for appreneurs developing apps but can make you more self-sufficient in your deployment process to production.

Common Tools for CD

There are some useful tools that help with automated deployment. These tools are generally used by larger teams, but you can use them as a solo appreneur. Here are some of the most common CD tools:

  • Jenkins
  • ElectricFlow
  • Microsoft Visual Studio
  • Chef
  • Octopus Deploy
  • IBM UrbanCode
  • AWS CodeDeploy
  • DeployBot
  • Shippable
  • TeamCity
  • Codar
  • Distelli
  • XL Deploy
  • GoCD
  • Capistrano

For a more detailed explanation about these tools and others, please see this great list of CD and CI tools by DZone.

Fastlane

Automating other processes can be a big help, too. A tool that that I have found for mobile app developers which automates the app submission process is called Fastlane. Fastlane is open source, so it’s free to use. This tool can be used in conjunction with CI and CD to help push your apps through the submission process to production faster.

As the app submission process is so tiresome, even if you’re only submitting for one platform, it’s worth looking into Fastlane to save you time.

The Benefits and Drawbacks of CI and CD

Generally speaking, CI and CD are considered practices that most companies should use. Since that’s the case, should appreneurs try and implement these concepts, too?

Let’s look at some of the benefits and drawbacks of these practices and see whether it can work for us small timers.

The Benefits

Peace of mind
No need to worry about broken builds getting deployed because, providing you have the right tests in place, the build will fail and it won’t be released.

But if you have tests in place, how might the build still fail? Building software is always an iterative process. We are only human, so minor and even major bugs can slip through to the production environment if the majority of your code is not covered by tests.

The way to prevent the same bugs from reappearing is to write a new test to help identify when this situation will occur. So if the test fails, you will know that this bug is likely to occur again. You can then fix your code to make sure the test passes and the bug never again sees production.

New tests are automatically run
Any tests that you add during your development process are automatically picked up and run. You can also pass different parameters to run version tests in certain conditions.

Allows you to work with the minimum team size
You don’t need a full-time DevOps, release manager, and several testers to ensure your product’s quality level is maintained across environments. Once you put in place the relevant build chains, you can make sure your development and production releases are monitored by the minimum amount of people from different disciplines.

Flexible and trustworthy
If your team expands, you don’t need to worry that they won’t remember to run tests before they perform a commit to the master branch. If their commit fails, it doesn’t break everything for everyone else.

Easy to extend with templates
After you have come up with the perfect configuration for your project, you can create a template to reuse. As your project grows, you can use the template to create new build configurations.

The Drawbacks

Time to set CI/CD up
Once your CI and CD builds are done, you just have to maintain them. But until then, you’ll have to dedicate a bit of time to setting up the initial build configuration templates.

How much time? Well, that’ll all depend on how quickly you learn, how much experience you have with CI and CD tools, and what tools you select. So it’s pretty subjective, based on you.

There will be a learning curve
How steep your learning curve to overcome is will depend on how much experience you have with CI and CD tools.

You have to learn how to set up build configurations, link these to your code repository, write unit tests (if you haven’t been doing this already), integrate the tests into the builds, and possibly also add in a tool to output your level of code coverage after every build. Then once the build is created and passed, you have to learn to link the build’s output (probably the app executable) to the CD tool to push to your next step.

Maintenance
Those new shiny tools will get updated as well, so you’ll need to keep on top of the software updates and licenses. It may not be essential to upgrade to the latest version of everything, but ensure your tools are compatible with each other and that you keep an eye on the new features appearing in new versions.

Can be costly for the more popular tools
Let’s not forget that some of these tools aren’t free and some of them that do offer a free version are capped. So if you want the more costly option, make sure you have enough budgeted for these development costs.

Although the pricier options are sometimes preferred in larger companies because they come with a certain level of support that you don’t get when using free licenses, I find you can get quite far using a free license and having Google at your disposal. I would recommend that you try a free tool before spending money on a paid-for service. After all, using CI and CD tools may not be suitable for you or your project, so keep yourself and your budget in mind.

Builds can be fickle
During a previous role for my day job, when my team was new to TeamCity, we found that our builds were constantly failing. Again, this failure is part of the learning curve; it should also be considered in the time budget you need to put together a robust template. So if you find your builds are failing often, you’ll have to put more time aside to figure out why.

So: Should Appreneurs Use CI and CD?

There are some good points about using CI and CD—mainly that these processes enable an appreneur to remain self-sufficient for longer and makes you confident that your builds are stable and high quality all the way through to production.

But it does take a lot of work up front. And if you don’t have any previous experience with CI and CD tools, it will probably take you longer.

If you’re working with apps as a hobby and don’t have any previous experience with these tools, I wouldn’t recommend setting up a CI or CD process. The time you’ll take to learn the tools and maintain it all may not give you a great return.

But if this is the beginning of building a solid development base and practices for a long-term project, you really don’t have anything to lose.

Start with one process first, preferably CI. You can then build up your test suite to ensure a high level of code coverage (code covered by unit tests) and still control the release process to ensure nothing gets released accidentally while you’re still learning the tools. After you’re confident with your CI builds, pick a complimentary CD tool to help you build your solid foundation.

Anything you can do to make building your app business more efficient and your products more robust and higher quality can only be a good thing.

Setting up Istanbul on a Node project for Mac and Windows

When I took on this new role, one of my tasks was to ensure that we deliver high quality products.  In order to get an estimate of where we were currently at, I decided to look at implementing code coverage tools into the build processes so that we can gauge the level of quality we have on each product after each  successful build.

After watching the Testing JavaScript for Node.js with Mocha Pluralsight course (which I recommend for any .Net C# newbie to Mocha), I felt like I gained a good understanding of unit testing within node applications. And as an added bonus, the course even bolted on a short demo of a tool that I had been meaning to investigate. This was Istanbul.

Code Coverage with Istanbul

Istanbul is a Javascript code coverage tool that outputs the amount of code covered by unit tests in your project. It is an open source tool which is available on GitHub.

Setting Up

Whilst watching the video, I installed Istanbul into my small node project that I had been using throughout the course using npm install -g istanbul. This installed Istanbul globally to my Mac.

Next, I entered the command:

istanbul cover node_modules/.bin/_mocha -- tests/**/* (on Mac)

This is the command when trying to execute on a Windows machine:

istanbul cover node_modules/mocha/bin/_mocha -- tests/**/* (on Windows)

The Reports

After doing this, Mocha should run your tests. Appended onto the end, you’ll see a short output of the level of code coverage in the command line window that has been helpfully coloured in green or red (if other colours exist I haven’t seen them yet).

You will also now have a new directory within your project named “coverage”. In this directory, you’ll find a coverage report directory that contains a detailed HTML version of your application’s code coverage.

And that’s it!

I was very surprised how easy this was to set up and get running. The next step is to get this running on Team City! So that we can read the code coverage levels after every build and hopefully enforce a minimum level of code coverage so that whenever new features are written, if the amount of unit tests covering those new lines of code don’t increase, then we can fail the build to encourage developers to write more tests and increase the quality of their code.
<!–
Setting up for TC

  1. add to the artifacts path under general  settings the path where the html reports are output.

–>

Ways to keep up your development skills as a Test Engineer

Earlier this year I made the decision to switch back to being a QA Engineer. Due to the nature of the tech that I was now being exposed to, I wasn’t able to flex my coding muscles everyday like my previous role. I started to think that my programming skills would slowly dwindle if I didn’t do something about it, particularly the C# and .NET skills I’d spent the last two and a half years developing.

So, I endeavored to take up activities that would encourage, keep active and stretch my development skills. I have tried and keep them aligned somewhat with my new role so that I continue to improve in the field of testing as well.

If you find yourself in a similar position, here’s how you can do the same.

Before You Begin

Make sure you know what skills you’re going to be building. Have a list ready to work on or a certain project that you’re going to create so that at the end of your learning you have produced a tangible result. I use a Trello board to manage the tasks on my projects, but good old fashioned lists work just as well. Just make sure that they work for you.

Identify Your Free Time

Everyone has some time where they’re free. That morning commute where you’re sitting for 30 minutes, that walk to the bus stop that takes 15 minutes or even your lunch hour. See what I’m getting at? You just need to identify where your free time slots are, then find an appropriate action to do within that time.

Take your weekly calendar and block of these times. Seeing it highlighted in chunks can really open your eyes. Then figure out what you want to do to further your learning and what action would suit that time slot best.

Got a topic but don’t know how to progress? Having a varied selection of learning resources across different formats will mean that you can you easily slip in a bit of learning during any type of free time you have.

What You Can Do

Here’s some tasks that I recommend you try.

1. Read other developer’s code

Reading others developer’s code, especially those that are more experienced than you, can help you see how to write cleaner code.

The best thing you can do when reading others code is to try and understand why they have used the methods and patterns that they have. If after reading the code you can’t figure out the reason, why not ask them? Discussing a developer’s thought process when tackling a problem is a great way to gain insight into how you should approach a technical challenge.

Learning by yourself may take a long time. Talking with someone more experienced that have overcome the same issue could save you hours, months or even years or trial and error. So take advantage!

2. Get your work code reviewed

The feedback you get from someone external to the project (and especially those more experienced) can yield some valuable tips. You could learn how to improve your code to make it more efficient, readable, testable and durable over time.

3. Watch Pluralsight videos

Pluralsight is a online library of technical videos. I’ll be amazed if you can’t find a video here on any technical subject that you can Google.

The vast amount of videos on Pluralsight are being continually added to by professionals in their fields. Pluralsight also vets any new submissions from existing and new authors to ensure they keep the quality of their videos high.

I enjoy using Pluralsight because sometimes watching videos is easier to digest and concentrate on than reading a book cover to cover. And, when you read a technical book, you may not need every part of that book to understand the topic. Pluralsight videos are broken down into digestible chunks so you can consume short videos in small areas of your chosen topic quickly and easily.

Updating videos is also a lot easier than updating books, so you’re more likely to get up-to-date content in your topic on this platform. They also offer a download service so you can take your courses on the go and watch offline on any smartphone or tablet device.

Ok, so Pluralsight isn’t free no. But they do offer a ten day free trial to see whether you’d like it. And they have different subscription methods to ensure that you always have an option.

Why not take the free trial and see how you do. Pick a topic and see how much you can learn during your free trial.

4. Read technical books, news sites and technical blogs

Watching technical resources is great, but sometimes the information is only available in a text only.

Reading technical books that are timeless like Clean Code by Robert Martin aren’t available on any other format currently, so you have to read the book. Choose wisely what you spend your time reading as books usually take a lot more of your time than anything else to consume.

News sites are good because they offer the latest information to keep your skills and knowledge sharp and up-to-date in small articles.

Technical blogs are good at getting the opinions of those in the industry but make sure the content you read is good quality. Anyone can write a blog nowadays. I’m not saying good articles can’t be written by those less experienced in a subject. I suggest that if you are working from the advice of someone new to the area you’re studying, work through what they suggest to verify their work.

5. Listen to coding or development podcasts

Utilising the time you spend traveling from one location to another is the most overlooked part of your day to use to learn.

During this time, providing you know where you’re going and aren’t talking to someone or doing something else at the same time, you can listen to coding and/or development podcasts to help you improve your skills. I find most of these aren’t too coding heavy but more often discuss high level concepts, technical updates, short code-based questions (that require short answers) or soft skills for software developers. Some coding/development podcasts I listen to are the Xamarin podcast, Simple Programmer and Hanselminutes.

6. Write different types of test automation e.g. Unit, integration, UI

You should understand the different types of tests that you can create for different stages of development. But, I would also recommend trying to learn how to develop these tests as well within your company’s tech stack.

Being able to apply what you have learned is more important than just saying you know how to do it.

Regardless of your job role, you may find that you have the opportunity to add some unit tests or write an integration test. Unfortunately, I’ve found that this is completely dependant on the attitude of your company and the developers in your team. You are a developer too, so if you want to contribute to these types of tests, make sure your team are aware of your interest and figure out how to get started.

At the end of the day, being well versed in different types of automation testing will make you invaluable to any team and any company.

7. Attend conferences and events

These can be free or not. The cost of the event doesn’t necessarily correlate to what you’ll learn from the event.

If you don’t know where to start, check your local meetups for events.

Early in September, I attended the ASOS QA meetup event in London where Simon Stewart spoke about the future of Selenium. It was great. I learned a lot about the history of how Selenium came to be one of the most common automation testing frameworks. I also spoke with some really nice, passionate people about their roles in the field of testing.

You can learn lots from conferences and events, not only from the scheduled talks, but from the people also attending. If you do decide to go, try and speak to at least one new person and find out about them.

People going to conferences usually have the same goals, to network and learn. The problem is that many who attend are usually shy, so why not be the first one to be brave and start a conversation.

Also, don’t limit yourself to only testing events. Make sure you go to both testing and development ones. You have skills in both fields so it makes sense that you might get something out of both types of events.

Don’t put a limit on your learning resources or experiences. You don’t grow if you’re not stretched.

8. Write a blog about testing while you learn

John Sonmez says in his 10 steps to learn anything quickly course, that the best way to solidify what you’ve learned is to teach it to others. The fastest, lowest barrier and least intimidating way to teach people is to start a blog detailing what you’re learning.

First, start by picking your blog topic and ensure you pick something niche. For example, don’t write about video games, write about the presence of females in video games between 1990 to 2000 within the role-playing (RPG) genre (if anyone had started a blog about this I would definitely subscribe!).

Next, commit to a schedule. I know it’s hard to stick to schedules because you do so much in life, but this is where identifying the free gaps in your week can help. Pick one of those gaps and dedicate it to writing articles for your blog.

Most new blogs fail within the first three months. Having a schedule will make sure you keep your blog content fresh and interesting to encourage new and returning readers to keep visiting.

A clear focus for your blog will help you to filter out any ideas for posts that may divide your decisions about what you write about. Having a clear focus also helps your audience as they’ll know if they have a problem or want to learn about the most well-known female RPG character in 1995, then your blog is what they need to be reading.

It can be hard to continually think of subjects to write about whenever your schedule dictates. Why not keep a list of your topics so you can regularly pick from it so you don’t have to think about what you’re writing about next? This is what I do. I keep a Trello board because it’s easy to access from a desktop or my mobile when I’m planning my daily tasks on a commute. And it’s very simple to use and tailor to my workflows. It’s also free, so there’s no reason why you can’t give it a try.

9. Write your own code

Practice makes perfect. Figure out what you want to learn or what side project to be focusing on to help you progress in your goals. Then, you can start planning the classes or methods you’ll need. If you’re practicing test-driven development, you may want to start writing unit tests but if not you can start crafting a class and basic method and go from there. Being able to refactor your code is a skill that writing code a lot can build. So the faster you begin the faster your skills grow.

Don’t have a goal? Get one. Do anything even if it’s small so you can practice writing code. The hardest part is starting.

Start With Just One

Try to build a habit of doing this so it’s second nature and you feel like you’ve missed something if you don’t complete your task. Once you’re happy you’ve successfully worked it into your routine, start adding another into your schedule.

Even if you’re only able to enforce and keep up one new habit you’ll soon notice results. I can’t guarantee perfect results fast but I can tell you that when you start doing these things regularly, it will make to think differently about how you approach a task so that you apply what you have learned.

For more ways of keeping up your coding skills, John Sonnez has written a similar post that you may want to read.

And that’s the secret to keeping up your skills. To keep learning a little at a time and applying what you learn in practical ways.

This post was imported into WordPress in one click using Wordable.

Creating a Test Strategy from Scratch

Five months ago, I was tasked with probably my biggest challenge to date in my development career. I was asked to create and implement a test strategy for my company. The previous projects were tested before being released, but there were no dedicated members of the team whose specialty would to ensure a high level of quality. I was brought in to fill this gap.

Although I knew I was up to the challenge, I had to admit, I didn’t know where to begin. Various emotions from excitement to anxiety filled me. I was excited because I had the freedom to shape the practices and processes that will be used across the business and projects for the foreseeable future. I wasn’t answering to anyone, no one was second guessing me. Once I had researched the tools or processes I needed and came to my conclusion, that was it. I was being trusted to make the correct decisions to ensure that the level of quality across the projects internally and externally was high.

Determining the scope and challenges

During my first week I made it my main goal to get a good understanding of the systems and tech stack we were using. One thing that was helpful to me (and others that joined later), was when I spoke to the developers to get an overview of the systems that we were creating, I made easy to follow diagrams. These helped me better understand what I needed to test and which systems communicated with each other. Once I knew this I was able to  highlight what tests were needed, where they were needed and if we already had any tests in place.

After a few days of taking to the developers, finding out their wants and needs in terms of testing, figuring out what parts of the projects were being unit tested, what test runners, test frameworks etc were being used, I put together a current state of testing overview.

This outlined where we were, the challenges we were or would face if we continued with that and possible solutions.

Some challenges highlighted were:

  • Limited testing resources

I was only one person managing all the testing and QA efforts of the company.

  • New technology

Another was I had moved from a completely different tech stack. Although I had some background in this new tech stack, there would be a learning curve implementing a number of things.

  • New types of testing to learn

The product would require load testing, which I was interested in pursuing but again had no hands on experience with to date.

Devising my test strategy

So now that I knew where we were at and where we wanted to be I began crafting my test strategy document.

Googling led me to a few very key posts which helped me create the bare bones of my test strategy.

These are the ones that I found quite useful:

I began reading through each page and picking out the key points that would become the skeleton of my strategy document.

I started by dividing my strategy into the following sections:

  • Scope And Overview
  • Test Approach
  • Test Environment
  • Testing Tools
  • Release Control
  • Risk Analysis
  • Review and Approvals

With the document clearly divided up. I set about trying to fill in what I knew so far within each section. Then I could clearly see what was missing, what sections needed a lot more work and if any other supporting documents needed to be made in order to create a complete guide. Where there were already documents made I chose to either update or reused them if the information was still valid. There’s no point in making more work for yourself if you don’t have to!

How long did it take to write?

I had a deadline of getting this done by 28th April so I guess writing this document took me about six weeks to complete. Although, I wasn’t working on this all day everyday as I was trying to learn the tool and tech that I needed to test. I also had to hire another tester within my third week so going through the recruitment process, interview and managing this person was now embedded into my daily activities as well as daily manual testing, Scrum meetings and researching tools and processes. So I think despite it all, I didn’t do too badly to get it all written within that time.

Once the document was complete I had produced a Test Strategy document with the following sections:

  • Scope And Overview
    • What is Quality Assurance?
    • How should this Strategy be used?
    • Mission Statement
    • Testing activities carried out with timelines
  • Test Approach
    • Approaches
    • User Stories
    • No Acceptance/BDD Tests
    • Dashboards
    • Test Process
    • Test Workflow
    • Testing Levels
    • Roles and responsibilities of each team member
    • Types of Testing
    • API / Service (Integration) Testing
    • Acceptance Testing (BDD Tests)
    • System Testing/Regression Testing/User Acceptance Testing
    • Smoke Tests
    • Defect Raising and Fixing process
    • Internal
    • External
    • Automation Strategy
    • Test Schedule
    • Test Plans
    • Test Coverage Minimum Targets
    • Challenges to Consider
    • How can we test a virtual reality application?
    • How do we run the Unity unit tests on builds?
    • Scheduling
    • How will we manage other quality considerations?
  • Test Environment
    • Environments
      • Prism
      • I-Pass
    • Load Balancers – Immerse platform.
    • Service Locations
    • Product Domains
    • Backup of Test Data
    • Restore Strategy
      • Sign Off
      • Rollback Tools
  • Testing Tools
    • Automation
    • Manual
  • Release Control
    • Build Management Process
      • From Development to Production
      • Steps
    • Release Windows
    • Versioning
  • Risk Analysis
    • Likelihood
    • Impact
    • Potential Risks
    • Monitoring and Logging
  • Review and Approvals
    • Sign Off Process
    • Release Notes
    • Done Criteria

This document also spiralled off the following standalone pages:

  • Bug Template
  • Sign Off Process Template
  • Release Notes Template
  • Defect Submission Process – External
  • Defect Submission Process – Internal

So you can see, this was no small task!

How has this document helped?

With this document now in place, the company has a level of quality to strive towards and something concrete that everyone can refer back to if there are any queries about why we are using certain processes or tech.

What have I learned so far?

Building something from nothing is always going to be hard work. It will always take you longer than expected. So it’s important that you:

  • Have a clear deadline for you to work towards
  • Break things down into manageable chunks
  • Have a team or people that you can go to for help when you may need it

Once the test strategy was complete I took a short break. This was to let my mind relax so that when I went back to try and enforce the strategy I was refreshed and ready to tackle any new challenges that may arise.

Next steps

The test strategy is not a document that you write only once. It must be evaluated and reviewed to ensure that it still stays relevant and useful to your company. What I intend to do is to mark out dates on my calendar where I can sit down and update the original document to keep it in line with the developments of the business.

Another good idea that I think is working well, is to create a short overview documents that I and other members of the team can refer to regularly without having to search the entire strategy for the information.

This can list consists of basic goals for the next 3 months like code coverage levels to achieve or processes to put in place buy certain dates.

Make sure your overview document captures the short term goals and highlights where that puts you in the long term so that you can clearly see how you and your team are progressing.

This post was imported into WordPress in one click using Wordable.

Releasing Your App to the Store in Style Part 3

Here’s my next post which appeared first on Simple Programmer..

During the first two posts in this series on how to release your app to the App Store, I discussed the importance of configuring the first two screens of your App Store page.

In Releasing Your App to the Store in Style Part 1, I stepped through the App Information screen and why each setting (for example, the title and category) is important to help drive more users to your page.

In Releasing Your App to the Store in Style Part 2, I discussed how the price and where you make your app available could affect your sales, and also how you could use this to help with trialing your app on a smaller audience.

In this post, we’ll discuss what you need to configure before you can finally submit your app for review to Apple, before you plan for that all-important release date.

We’ll discuss each section of this screen in the order that they currently appear so you can read through this post and the screen at the same time from top to bottom without having to jump back and forth.

Let’s go!

Version Information

This section gives prospective users a first glimpse at your app. Sure, the icon may have drawn them in, but you need to have your best images here. If your images aren’t high quality, they will not convince viewers to download your app.

App Screenshots

For the current generation of Apple products, if your app runs on an iPhone, you must provide screenshots appropriate for a 5.5-inch display. The Apple guidelines state that “screenshots must be in the JPG or PNG format, and in the RGB color space. App previews must be in the M4V, MP4, or MOV format and can’t exceed 500 MB.”

You will upload screenshots for both iPhone and iPad in this section. If your app supports both iPhone and iPad, you need to add at least one screenshot for iPad. You are allowed up to five screenshots for iPhone and five more for iPad.

Read iOS Screenshot Specifications for more information on the guidelines you need to follow when creating your iOS screenshots.

Screenshot Options

You have a few options available when managing your screenshots in this section.

Media Manager

This option allows you to upload individual sets of screenshots for each iPhone or iPad size. You can also make any one device use the default 5.5-inch display screenshots by checking a checkbox next to each device section.

The benefit here is that if you have different designs for different devices, you can showcase both on the store to your users. A small downside is that it may take a little while longer to gather and format the screenshots to the correct sizes. But if you went to the trouble of creating new designs, why not put in the extra effort to make sure they’re seen by as many people as possible?

For more information about the Media Manager, read this Get Localization post.

Choose File

This option allows you to select the images you want to use for screenshots from your file system.

Delete All

This option will remove all screenshots and any App Preview files you have added to the 5.5-inch display section. It’ll save you from having to remove them individually. Being able to remove everything at once will be useful if you have updated the graphics of your app and want to change them all.

App Preview

An App Preview is a short video users watch right on the App Store that lets you demonstrate the features and functionality of your app. You are allowed only one app preview.

This preview video is a great marketing tool, but don’t do it if you can’t create a high-quality, effective video that equals the brilliance of your app itself. Users may overlook your app if they’re turned off by the video.

If you really want to make a video, but don’t have a large budget to hire someone, please, do it yourself only if you know you can produce something spectacular. If the video is low quality, that indicates that your app could also be of low quality. And that’s the last thing you want.

One idea for those with small budgets is to look for contractors on Fiverr. Most jobs start from £5 (extra services may increase the price, though) and you can get a few free revisions included in that cost to tweak your project if you’re not happy straight away. Just remember that the devil is in the details. The more details you provide, the better your chances will be that your first version comes back close to what you are happy to use.

In addition to being high quality and well-made, it needs, above all, to be short. Time is money, so make sure your star features are showcased quickly in your video. Between 15 and 30 seconds should be your target range. If you think your video may be too long, try it out on a few people and get their opinions before you spend time reducing the length.

Read App Preview Specifications for more information on the guidelines you need to follow when creating your App Preview.

Other Sizes

When you add in your iOS screenshots for the 5.5-inch display, these will be resized and used for the other sizes: 4.7-inch display, 4-inch display, and 3.5-inch display. Again, the benefit here is that if you have different designs for different devices, you can showcase both to your users on the store.

To add custom screenshots to the Other Sizes section, go to the Media Manager.

Promotional Text

Waiting for your app to be reviewed can take up to a week if you’re a new publisher to the Store.

However, promotional text gets updated to your App Store page straight away, bypassing the submission process. It lets you inform visitors to your page of any current app features quickly.

This text appears above your description on the App Store for those with devices running iOS 11 or later.

Description

After the images, the description provides the user with the greatest insight into your app and its features.

Overloading the reader with every little amazing feature your app has is not the best strategy. Giving someone too much information may leave them bored by the time they get to the end (if they don’t lose interest and switch to something else halfway through).

And giving them something too short may not intrigue them enough to download your app and see for themselves.

You need to find a balance where you deliver the best information in a short, snappy pitch. List your best features to catch the attention of those that skim-read.

This description will also be used for your Apple Watch app, so you may want to keep it as short as possible. It really depends on whether you mind having users scroll to read the full description in their Apple Watch.

You also need to be thoughtful in the words you use to describe your app. Use keywords in your description you think a potential user will search with to make it more likely that your app will show up in their search results.

Keywords

This field is like the description in that you fill it with keywords. However, unlike the description, you can put in words that you wouldn’t use to describe your app, but users may search with. For example, the Google Sheets app doesn’t contain the word “number” or “calculation” in its description, but as users are familiar with associating these words with this tool, they may use them when they search for that app.

Make sure you add at least one keyword into this field to improve the chances of your app being listed in search results. Separate your keywords with a comma. (No need to add a space! You’ll just be wasting precious characters.)

Picking relevant keywords for your app has become as important and as much of an art as picking the keywords for your website. For this reason, choosing your keywords now has its own name: App store optimization or ASO. Tools like Google Trends and Google Keyword Planner will help you figure out what terms users are searching with the most so that you can find the relevant keywords to add into your app to ensure it appropriately turns up in the most search results.

ASO can be incredibly complex; the best keywords to use will depend on your app. I suggest that you spend a bit of time on trying to select the best keywords using the tools I described above to get you started.

Support URL

Visible on the App Store beneath your description, the URL tells users where to go if they need support information for your app.

Marketing URL

Also visible beneath the description, this URL tells users where to visit in order to gain marketing information about your app. For example, you may want to provide more in-depth information about the features of the app, the background of why and how it was made, any information about you in relation to the app, etc.

iMessage App

The iMessage App allows you to create an app extension that lets your users interact with your app within Messages, extending the functionality of your app. Users can interact by creating and sharing content, adding stickers, making payments, and more, without ever leaving their conversations.

The iMessage framework is available in iOS 10 or later.

You can add screenshots to your iMessage App extension here in the same way as the iPhone and iPad version detailed above.

Read the iMessage page for more information about iMessage.

Apple Watch

Apple’s wearable device Apple Watch has grown in popularity since its release in April 2015. By developing an app that is compatible with Apple Watch, you open yourself up to a wider range of people.

As the display for Apple Watch is smaller than a normal phone display, you’ll need to design an icon that’s a suitable size but also ties into your app across other devices. Upload your icon in this section.

In this section, you also add in your screenshots for the Apple Watch app. You can have up to five screenshots for the Apple Watch (just like the iPhone/iPad sections). Similarly, the options for the Media Manager, Choose File, and Delete All are also the same. As mentioned earlier, there’s no separate section for the Apple Watch description, as it shares the description defined for the iPhone and iPad.

Read the Apple Watch Screenshot Specifications page for more information.

Build

The “build” is the application file that you have produced using your development tool. This is the section where you actually upload the build that will become the public version of your app. You can create the build using Xcode 6 (this is the current version stated) or later. If you are unfamiliar with Xcode, it’s a piece of software known as an integrated development environment (IDE) that can be used to develop apps for Mac, iPhone, iPad, Apple Watch, and Apple TV.

Now, you can use a number of different development tools, or IDEs, to create your iOS build. Once you have created your build, you will need to upload it to iTunes Connect. iTunes Connect is Apple’s portal for developers to manage their apps.

The easiest and latest way of uploading your build is via the Application Loader 3.0 (this is the current version stated) or later. The Application Loader is a hassle-free graphical user interface, which connects to your iTunes Developer account and allows you to upload a new build or add new in-app purchases to a project.

Once you have created your release build, you select this IPA file from the Application Loader, and it will verify that your app is correctly configured to upload. If there are any issues with the information that you have provided, you will be shown these details so that you can fix it. Once uploaded, you will see it in iTunes Connect under the Build section.

This section also shows the build version extracted from the build file you uploaded and the date you uploaded the file.

If you included any assets within your build, these are also extracted and shown here. For example, if you included your app icon, you will see it shown above the version number on the left.

General App Information

App Store Icon

This icon is the first piece of content from your app that users will come into contact with, so you need to make sure it’s high quality. You also may want to ensure that the image is representative of your app’s core functionality so the audience will know intuitively what the app is about.

For example, the App icon for Google Docs is a document with lines on it. Most software users associate this image with a file, piece of paper with text, or document, which automatically suggests the functionality of the app. Linking your app icon and app functionality will lower the barrier to entry and help you retain users.

The icon uploaded here will be used on the App Store. It must be in the JPG or PNG format, with a minimum resolution of at least 72 DPI, and in the RGB color space. It must not contain layers or rounded corners. Your app icon must also be 1024 x 1024.

For more information, please see App Icon Specifications.

Version

This is the current build version number of the app that you are adding. It is advised that the numbering format follow standard software conventions (usually “major.minor”).

Rating

This section is related to the age rating for your app, not the entertainment tagging that users provide. The rating is automatically calculated for you to make sure that all apps are rated objectively.

To get your app automatically rated, you read through a list of categories and check either none (no examples of this occur within your app), infrequent/mild (only some examples occur within your app), or frequent/intense (many examples of this occur within your app) to each option.

Once you have entered an option for all categories, the system will calculate an appropriate age rating based on your answers.

Copyright

This is the name of the person (or entity) that owns exclusive rights to your app. The year the rights were obtained are placed before this name.

Trade Representative Contact Information

This section outlines the contact details of the trade representative contact for your app. It is to provide additional information for the Korean App Store. If you’re a hobbyist or a solopreneur, your contact information will be provided here. If not, you should list whoever handles your business’s external communications.

If you wish for this information to appear on the Korean App Store, then check the box next to the text “Display Trade Representative Contact Information on the Korean App Store.”

If you provide your details in this field, your information will be displayed in the Korean App Store. If you don’t wish to show your contact details in the Store (which is perfectly understandable), you can choose to omit your details. This shouldn’t prevent you from having your app in the Korean App Store, but you should double-check with an Apple representative to confirm.

By default, your contact information is placed within these fields. If you remove your details, you may find that they default back to using your real contact details. The only way to remove your details is to add something like “no address” into these fields. Again, I’m not sure how this will affect your submission and being displayed in the Korean App Store, so you should seek advice from an Apple representative.

If you don’t want your app to be available in the Korean App Store, you need to disable the app within the territories section in the previous screen, “Pricing and Availability.”

Routing App Coverage File

If you would like to specify the geographic regions supported by your app, you can do so by providing a file in the format GeoJSON and uploading the separate GeoJSON file in this section.

Game Center

This option includes your app within Game Center. If you have added in functionality to your app that makes use of the Game Center features, once you enable this option, your build properties that relate to Game Center will be extracted and displayed here.

App Review Information

Sign-in Information

If you give users the option to sign into your app using a particular social media channel, Apple will need a social media account to test this, enter your app, and test its functionality.

In order to proceed through the review process, your username and password credentials for any social media accounts you want to be tied to your app must be valid and active for the entire review process. If they aren’t, your app will be denied and you’ll have to start again.

If you want users to sign into your app, check the “Sign-in required” checkbox and provide a username and password in the hidden fields.

Contact Information

You need to include the contact information of the person the App Review team should contact if they have any questions or need additional information during this process.

Notes

This section can be used to provide any additional information about your app that can help during the review process. Include any information that may be needed to test your app, such as app-specific settings. Providing these here may speed up your review.

Version Release

After the app has been approved, Apple can release the app straight away if you check the option “Automatically release this version.” However, most publishers that aren’t hobbyists usually have a marketing strategy with a whole release timeline etched in stone so that they can build anticipation for their product.

If this kind of plan is what you have in mind (albeit maybe on a smaller scale), you may want to choose the option “Manually release this version.” To delay the release of the app until a certain date after it has been approved, you can choose the option “Automatically release this version after App Review, no earlier than [provide your chosen date].”

The earliest date your app will be made available on the App Store is based on your current time zone. If the App Review process isn’t complete by this date, the version will be made available directly after it has been approved. So if you want to maintain control over the release of your app, make sure you allow for ample time between submitting for review and getting your app approved.

Once you have submitted your app, it will be set to the “Processing for App Store” state. While your app is in that state, you can’t get new promotional codes, invite new testers, or reject your app. You can upload a new build, though, in case you missed something small but significant.

After it has been approved, the app will move to the “Pending Developer Release” state. Once it is in this state, you’re able to generate and give out promotional codes, continue beta testing, or reject the release and submit a new build (because, you know, accidents can happen).

So that’s it!

I’ve shared with you everything that I’ve learned so far about how to create a great App Store page.

Having this page configured to a high quality will put you ahead of the competition. You’ll drive more traffic to your page and downloads of your app will increase. But actions make all the difference. Make sure that you put what you’ve learned into practice as soon as possible.

Once your page is live, it’s important to check how your page is doing by looking at the analytics surrounding your page.

The algorithms that Apple and Google use when listing your app within search results change all the time to make sure that no one publisher remains on top.

Because of this fact, you will need to adjust the content of your page accordingly to try and make sure you keep getting a high amount of pageviews and hopefully downloads.

It’s not easy sailing from here, but you’ve done a great job in getting this far.

Good luck with your release!

Releasing Your App to the Store in Style Part 2

Here’s my next post which appeared first on Simple Programmer..

Configuring a great App Store page is usually one of the last stages in the app development life cycle. Because it comes at the end, it is sometimes overlooked, or the information is added in a slapdash sort of way, without much time or attention dedicated to the content.

However, even if you have created a great app, no one will find it if you don’t put some thought and attention into the screens on the Developer Dashboard that make up your App Store page. And even if by some sheer stroke of luck, a few people manage to find your store page, if what they see and read doesn’t convince them to download your app, all your efforts will have been for nothing.

Two key aspects of configuring a winning App Store page are getting the pricing and the availability right.

The price of your app can make it more or less appealing to users, depending on who your audience is and what platforms (iOS or Android) you release to.

And availability of your app can also affect your sales and analytics results. If you release to too wide an audience when your app hasn’t been tailored for all locations, you may hinder your app’s progress.

You must find that balance and use your findings to guide how you configure your App Store page.

In this post, we’ll delve into how to set Pricing and Availability—as shown below—in a way that gives your app the best possible start in life.

You’ll learn to set up the price, set up a price change schedule (if necessary), and set the availability of your app.

Setting Your Price

You should already know from your chosen business model whether you want to sell your app for a fixed cost or price it as free. You would have gained all of this information from the idea validation and research stages of development, and from audience feedback and competitive analysis.

We tend to equate price with quality, so your initial instinct may be to price high and at a fixed cost. This strategy has been known to work on the Apple App Store, as the typical user of iOS devices prefers high quality. But if you try to use the same technique on Google Play, you may find that users are less likely to buy your app. This is because apps in the Play Store usually sell for lower prices or are free, without this being indicative of their quality.

Please be aware that if you decide to sell your app, you must have a Paid Application agreement.

What is a Paid Application agreement?

The Paid Application agreement is a contract you have to review in order to sell apps. You don’t need to submit anything to Apple in order to be compliant with this agreement. It’s simply an online form that you complete with the necessary bank and tax details.

In order to review the agreement, sign into the Apple Developer Account page and select Agreements, Tax, and Banking.

Under Request Contracts, click Request for the iOS Paid Applications contract type. An agreement will appear.

After you review the agreement, check that you have read and agreed to the contract, then click Submit.

The iOS Paid Applications contract will now be displayed under Contracts In Process. You then need to set up your Contact Info, Bank Info, and Tax Info in order to get your sales paid into your account.

For further steps on the Paid Application agreement, please read this step-by-step guide.

What’s the best price for my app?

Only you can decide that, but there are things you can research to guide your decision. Look at similar apps currently on the App Store to help you figure out an appropriate cost for your app. If you can, try to find out how many downloads these competitive apps have had. When pricing your app, take into consideration how long it took you to create your app and how much effort you have put into creating it.

Get feedback from your target audience to gather their opinions about what they would pay for your app. Ask strangers for their opinions over direct friends or family. Strangers won’t care so much about your feelings and are more likely to give you their honest opinion and thoughts. If you’re not a social butterfly, talk to friends of friends, colleagues at work, or online users via groups such as Facebook groups or forums. Ask these people a specific set of questions that will help you justify your price model.

Use the feedback you gain from your target audience and competitive analysis to come up with a price that’s suitable for your users.

Before you set your price …

You should take a look at the All Prices and Currencies link, which takes you to the pricing matrix that details the pricing tiers for each territory. A territory is a country where the Apple App Store can distribute apps.

Pricing tiers are what you use to set your app price. Each tier is of a different value. The lowest tier is Tier 0. This is the tier you select if your app is going to be priced as free.

There are 87 pricing tiers and seven alternate tiers available for you to pick from. The pricing tiers are set by Apple, and they vary across territories.

How do you set a price?

In the Price Schedule section, you will see that you already have a default value set to Tier 0. The Start Date will be today’s date, and the End Date will be “No End Date.”

Select Plan a Price Change to change these defaults.

You will then be presented with a table where you can set the Pricing Tier, Start Date, and End Date for your pricing change.

The Start Date is the date that this new price will come into effect on the App Store. The price changes at the beginning of the day. To make the price change immediately, select “Today.”
The End Date is the date that this price reverts back to the prior value (if you’re setting it for the first time, this will be the default of Tier 0). Selecting “No End Date” will set this price permanently. Prices change at the start of the day. One-day sales have to end at the start of the next day.

Promotional Pricing

You also have the option to configure any promotional pricing periods. For example, if you have a launch price of 99p (or USD $0.99), then you can schedule this so that after a month it increases to £1.99.

Price changes and promotional offers are something that are good to have planned prior to configuring your App Store page.

It’s important to understand how to use price changes to build up scarcity by lowering the price for short periods. But you must be careful, as many users equate price with your level of quality. Ensure your full price reflects what you think is the accurate value of your product.

A good example would be to run a Summer Sale promotion and cut the price of your app by 25 percent for one week. By advertising that the sale is only on for a short length of time but not stating when it will end, your app may get more downloads, as buyers will be uncertain when the original price will be reinstated. However, if you do feel compelled to advertise a certain time period, don’t state anything longer than three days. If you do, buyers will think they have time to come back to it later. The next thing you know, more than three days have gone by, the sale is over, and those who were keen on downloading your app are no longer interested, because they didn’t get a reminder that the sale was ending. Again, make sure you plan this carefully.

Keep in mind also that too many price changes may lead users to believe that you don’t know what you’re doing or that your product just isn’t worth the higher price. Also, if your users know your app frequently lowers in price, they may decide to strategically wait until it drops, in order to get a bargain.

Lay out a plan for when and why you will schedule a price change. Use your marketing channels—Facebook page, website, et cetera—in order to properly communicate these changes. If a special occasion like Christmas is coming up, consider lowering the price for a set period and posting when you’re having the sale.

Availability

Availability is where your app will be available. Setting this means you determine which territories your app will be available in. You can select individual options from the 155 territories currently supporting the App Store or by choosing Select All, which will highlight all territories.

Yes, you may think that in order to get the most amount of traffic, you should make your app available to the maximum amount of users. But if you plan to serve only a specific market, or are releasing your early versions to gain feedback, you may want to limit your audience to certain territories.

Companies like Supercell are known to carry out this type of strategy. They frequently do soft launches in Canada to test their ideas and see if what they have just created is a hit, is a miss, or needs a bit more work. If they have a hit, they then open the app up to all of the other territories. If not, they move on to the next idea. Their soft launches differ in length of time, and in whether they release to iOS and Android simultaneously, or one following the other if the initial release receives good enough results.

Volume Purchase Program

This program gives certain groups, like academic institutions, the option to gain a discount when purchasing large volumes and multiple copies of your app.

If your app targets clients that have multiple devices, you may want to have this option. Places like schools and businesses have multiple smartphones and portable devices; therefore, every device would have an individual app. Giving a discount could encourage your clients to buy your product.

These are the options you can choose from in this section:

  • Available with a volume discount for educational institutions
  • Available with no discount
  • Available privately as a custom B2B app

Bitcode Auto-Recompilation

Bitcode refers to the type of code that is sent to iTunes Connect. This is known by its full name of “LLVM Bitcode.” Sometimes Apple automatically rebuilds apps that include bitcode to improve hardware support or optimize Apple’s software—for example, to downsize executable sizes. If Apple needs to alter your executable, then they can do this without a new build being uploaded.
If you want to retain full control of your app, you can opt out of using bitcode. To do this, select the option: “Don’t use bitcode auto-recompilation.” Checking the box means that you have opted out of having your app auto-recompiled.

However, you may want to consider granting permission of this feature. If you disable bitcode auto-recompilation, a few things may happen:

  • Your app may be unavailable for some devices.
  • Your app (including when it’s within an app bundle) may become unavailable whenever apps must be recompiled.
  • If your app is unavailable on the App Store, then Universal Purchase, re-downloading, and Family Sharing won’t work unless all platform versions have been approved.

To make sure your app remains available on the App Store, you need to upload a new build of your app that contains bitcode, test it, and submit that build with a new app version to App Review.

To read more about bitcode, see Apple’s support page.

Where to next?

You now have a thorough understanding of how to set up pricing and determine where your app will be available.

In this post, I’ve taken you through:

  • Pricing tiers and how to set a price for your app
  • The reasons you might choose to make your app free or sell it at a fixed price
  • Paid Application agreements
  • Promotional pricing
  • Apple territories and availability
  • The volume purchase program
  • Bitcode auto-recompilation

Your App Store page is beginning to take shape.

Releasing Your App to the Store in Style Part 1

Here’s my next post which appeared first on Simple Programmer..

It seems like everyone’s making apps these days, and maybe you want to be part of it, too.

Maybe it’s to help you build that passive income you’ve always wanted, maybe it’s a hobby, or maybe you just want to cross it off your bucket list.

It’s hard to believe App Stores have only been around since 2008, a year after the release of the first iPhone in 2007. At that point there were only over 800 apps in the App Store. Now, there are over 2.2 million iOS apps in the App Store alone (as of May 2017).

Knowing there’s massive competition, you still want to go ahead and release an app yourself. That’s great. A little competition never hurt anyone.

You’ve done the hard work of designing, developing, and testing your app, and you’re ready to upload your build.

So how do you get your new, well-built, and well-designed app noticed in an ecosystem where everything is fighting for attention already?

First off, put together a really great store page to make sure when it’s seen, it gets downloaded. A catchy title and making sure it’s placed in the right category can get you far, but there are a few more things you can do to improve your app’s chances of getting discovered.

A quick note before we begin…

Developing an app requires an overall knowledge of the different areas within the Developer Console, so before releasing it to the App Store, you’ll need to have already done the following things:

  • Used XCode to create your build
  • Created debug, development, test, and release builds
  • Signed builds
  • Created provisioning profiles
  • Fully tested your app
  • Created an Apple Developer account for iOS (be aware this requires a yearly purchase of $99)

If you’ve already done all these, then you’re ready to go.

Getting Started

You should know from your app’s design and development stages,what devices you’re targeting, as this will have informs the design. Therefore, you should also know which resolutions and sizes you’ll need to create images and app icons. Refer back to your documentation if you can’t remember the specifics.

There are a number of configuration screens that you’ll need to complete when preparing your app for release.

You should also know which languages and countries your app will be available in, because the translations should either be included in the initial release, or planned for at a later stage in your production schedule.

The Developer Console

The Developer Console is the dashboard for setting up the information about your app and managing your App Store account.

There are many areas to the Developer Console. Once you have an account, make sure you explore all the areas, familiarizing yourself with what you can do and anything more you need to do to set up.

The section you’ll mostly work within when releasing your app is the My Apps section.

Every app you release to the store has an individual place in this section. Once you have created a new app in this area, you are ready to begin.

The details that make up your App Store page come directly from the App Store information you include here. And your App Store page only includes the information you include on these screens, so you need to be thorough. These details can be visible on your page—like the description, title, and screenshots—or work in the background—like keywords.

Double-check before you submit your app for review, as submissions from new developers could take up to a week to pass submission. If you have to make changes to this information, you have to start again from day one.

Configuring your App Information

Once you’re familiar with the Developer Console, you need to configure, and then add settings and the details for your app.

The details within the App Information section will be used across all devices that this app serves. Once your app is released, any changes you make to the App Information will be reflected in the next version of your app that you release.

Localizable Information

These are all of the details of your app that can be translated into languages other than your primary language.

Name

This is the name that the buyer/consumer/customer will see on the App Store page. Making your app name easy to spell and related to the functionality of the app means that you’ll have less to explain about the main features of your app. A good example of this is Snapchat.

Ensure your app name isn’t longer than 50 characters. In fact, sometimes two short words are better than a single long word, as (from your testing) you’ll know that the words wrap. Overall though, one short word is the best option for a name.

Privacy Policy URL

This URL links to your privacy policy. You may not think you need one if this is just a hobby or you’re doing this for fun, and you may be right. But it all depends on your app’s target audience and content.

If you have any of the following features, or target these audiences, you need a privacy policy:

  • An app for children
  • If you offer free subscriptions
  • If you offer subscriptions that auto-renew
  • You allow account registrations
  • You access a user’s existing account

If you collect user- or device-related data, you are only recommended to have a privacy policy.

Primary Localised Language

This setting is very important, however it’s not subtitled, and your attention isn’t really drawn to it as it is with other sections on this screen.

You can also set your primary localised languages here via a drop down.

General Information

Bundle ID

This is the ID that you used in Xcode. Be aware, it can’t be changed after you upload your first build. So get it right!

You have the option to register a new ID or chose the iOS Wildcard App ID option. You usually use the wildcard option for apps that don’t use app-specific functions like in-app purchasing or Game Center. You can read more about Wildcards App Ids in the Apple Developer library.

SKU

This is a unique identifier for your app. Don’t worry, it’s not visible on the Store so you can use any obscure ID you wish. Just make sure you keep a note of it if it’s that unusual.

Getting into the habit of creating SKUs in a specific format is a good idea, so that even if it’s not clear to someone outside of your team, you’ll be able to look at your SKU ID and know what it relates to without looking it up. For example, you may choose to use the first three letters of your app name in capitals, and then maybe the date it was first released. It’s really up to you.

Apple ID

This ID is automatically generated and assigned to your app. It’s arbitrary, so don’t try and make sense of it. But you may want to keep a note of it somewhere easily accessible. It’ll save you logging back into the app store and going to this page in order to find it.

Languages

Primary Language

This is simply a read-only text field set by the localizable primary language you already set. I know it’s confusing having language defined in two places, but it’s the way this screen is laid out at the moment.

You need to set up the primary language in which the app will be used. Additionally, you have to set up the languages for which the app will be localised.

If your localized language isn’t available, then the content served will be from the primary language.

If you can’t find a supported language you would like to use, see the FAQ.

Category

Now you must define what category your app is best suited to.

What’s the main function of your app? Does it provide entertainment, improve your productivity, or make it easy to keep up with the activities of your favourite charity?

You could try and classify your app in a category that you know is popular in the hopes of it getting discovered, but this kind of classification may mean that those looking in the correct category for your app will miss it. It’s up to you to decide what’s more important.

If you’re not sure about what to choose or have other questions, you can see the App Store Category Definitions.

So, you’re analysing your app to see which category will suit it best. But what if you think it could fit into more than one? Well, you’re in luck. You have the option to assign a primary category and an optional secondary category.

The primary and secondary categories are currently as follows:

  • Books
  • Business
  • Catalogs
  • Education
  • Entertainment
  • Finance
  • Food & Drink
  • Games
  • Health & Fitness
  • Lifestyle
  • Magazines & Newspapers
  • Medical
  • Music
  • Navigation
  • News
  • Photo & Video
  • Productivity
  • Reference
  • Shopping
  • Social Networking
  • Sports
  • Stickers
  • Travel
  • Utilities
  • Weather

License Agreement

Here you can set Apple’s Standard License Agreement or edit it to best suit your project’s or team’s purpose. The License Agreement is in place to detail who has ownership of the product from the End User’s perspective, i.e., the person who downloads your app. This differs from the Privacy Policy, because in a privacy policy you as the developer define what you are doing with the information you gather through your app, in order to protect and enforce the rights of the users of your app. By contrast, the License Agreement arguably works more to protect the interests of the app developer.

Rating

An age rating is required, as it classifies the minimum age of the audience that can use your app. The age rating of the app is based on the most mature rating required across all devices.

The current list of age ratings that you can clarify your app under is as follows:

  • No Rating
  • 4+
  • 9+
  • 12+
  • 17+

Additional Information

This section allows you to preview your app and see how the details you have set up will look on the App Store.

It’s a good idea to see how the settings you have chosen are depicted and positioned on the App Store page before it goes live. For example, it could be that when you preview it, details in an image you’ve taken look a lot smaller and are only visible when you open the full size image. This may not be good for catching the eyes of those just browsing for a new app on their smart phones.

If you find something that looks incorrect, you can always go back and update the details, even after you submit your app for review.

What’s your next step?

So, now you have been introduced to the Apple Developer Dashboard. You have a basic understanding of how to configure the App Information screen in the My Apps section in order to start building an attractive and informative App Store page.

So now what do you do with this initial knowledge of the App Store? Why not build upon it?

There are still two more screens left to populate with information before you submit your app for review.

In my next post, I’ll share what information you need to supply on the next screens to build a great App Store page.

Why Testing Could Be the Most Important Stage When Developing

Here’s my next post which appeared first on Simple Programmer..

Testing is an area of development where, at different stages of the development cycle, the product or service to be tested is measured against set criteria. These criteria check that the product or service fulfils the original spec, goal, or intended use.

Testing can be carried out manually by individuals, or automatically by computer systems. If a feature fails testing, it needs to be reworked, then retested.

Features fail testing when the actual results of tests don’t match up with the expected outcomes. The more safety-critical the system under test, the more important it is to adhere to a well-defined approach to testing.

However, just because your system doesn’t carry health or safety risks, doesn’t mean you should skimp on professional test efforts. Your end user invests their money and precious time into your product, so it’s up to you to deliver the most robust version possible.

Why “any old” Testing won’t do

The general view of testers on projects has improved considerably in the last 10 years, as the testing role has become more technical. But besides being technically skilled, great testers are highly analytical, methodical, logical, and thorough; they are investigative by nature and good communicators.

Especially in the case of video games testing, those external to the industry and field underestimate the skills needed to test projects. Because games are seen as recreational activities, those outside of the games industry assume a tester’s job is to play games all day. That couldn’t be further from the truth.

Although games testing may not employ more technical types of testing, such as automated, performance, load, or security testing, good games testers use multiple other skills to help them solve problems.

For example, on one game project I tested, I had to perform graphical checks on an area. The area was divided into squares, but the boundaries of that square weren’t visible. I could only check where I was by inputting a command. So I wrote a small script to help me perform the checks. I set the square coordinates to test so that whenever I moved out of the area, the on-screen character would shout, alerting me I had gone too far. This type of thinking—finding ways to ensure your task gets done more effectively—is what professional testing can provide.

Professional testing takes into account different test techniques and strategies. For example, test techniques can be reactive or proactive. Reactive testing aims to quickly resolve defects as they happen, to ensure the minimum negative impact on customers. Proactive techniques aim to implement testing as early on in development as possible, in order to catch and fix bugs before they become a problem.

Another test strategy could be one using risk-based testing. This is where the approach of the project is determined by the level of risk that could occur.

What makes these test strategies professional is that they are known about and intentionally used in a project. Sure, a non-professional tester could also decide to plan out their test cases based on the impact of the project, but they wouldn’t necessarily be aware of why that would be better than other approaches, or that it even is a test approach.

Professional testing will:

  • Increase the quality of your product
  • Decrease the likelihood of production bugs
  • Increase the likelihood bugs will be caught in pre-production environments

Good testing ensures that the number of defects your target audience comes across is very low.

Professional testers, developers, and even those on the product team know testing should occur throughout the development life cycle. This constant review ensures that critical and major bugs are caught early on, when they are cheapest to fix.

It’s Wise to Invest in Great Testing Resources

Investing in great resources may mean investing in great tools or people.

Putting your money into people, whether that’s offering a salary that will attract more experienced candidates, increasing the salary, or offering training to your currently employed testers, is worthwhile. When people are shown respect and given chances to excel, they give back with dedication, loyalty, and hard work.

Providing the proper tools to help support your team to uphold the quality of testing is also a good idea. There’s no point in having a great team if they will be limited by their tools. I know there are lots of great free and open source tools out there (like Selenium and NUnit), but sometimes spending that little bit more can move you forward tremendously.

Testing is the Gatekeeper of Quality

The buck stops with testing. The people on the testing team need to know their part to play and that they sign off on the level of quality with which the product ships. Your team needs to understand that the quality of the brand is determined by the product that is shipped and not by what it was intended to be. The time and money a customer invests in your project should be paid back by making sure you release only the highest quality product.

Your Efforts are in the Public eye

The public doesn’t know about the difference between the waterfall and agile development life cycles, or other technical strategies. You may have testing efforts taking place throughout your entire development cycle, but this will be known only to your team.

The public and your customers are probably aware, however, that products have testers. So if products ship with bugs, they are likely to blame the testing effort over anything else.

Testing Helps Uphold Brand Image

Having a high-quality product is beneficial to any brand. It suggests a commitment to quality throughout your processes and company, whether a high level of quality is specifically spelled out within your brand guidelines or not.

Your brand image is fragile. Negative press from a buggy product can shatter your solid, high-quality image in a much shorter time than it took to build. For example, as much as I love Windows and Visual Studio, historically, Microsoft is known to release buggy software. I know people who update to the latest major version of Windows only after the first patch is released, because they don’t want to deal with the inevitable bugs that will unfold (I must say that since Windows 10 and the release of Visual Studio 2017, Microsoft’s image has improved, at least in my perception).

Rebuilding your brand’s image will take twice as long and be twice as hard if you let it slip.

Make Time and Budget for Good Testing

The quality of a product is determined by a lot of factors. A quality experience is created not only by the design, user experience, and functionality of a product, but by the amount of bugs users don’t encounter. Bugs hinder users’ progress and give them a bad experience with your product.

Basic testing can be done by anyone, but professional testing is needed to ensure a high level of quality, which will in turn uphold your brand’s image. Don’t skimp on testing with your project; it could be your downfall!

Adding Reports and Screenshots to Your Protractor Tests

If you fancy sticking it out with Protractor (unlike I did), I highly suggest you add jasmine  2 html reporter to your test projects.

The Jasmine part

Adding Jasmine will give you a little report in the command window listing all tests that have been run, including which have passed and which have failed.

To add this to your project run this command via npm:

npm install protractor-jasmine2-html-reporter --save (--save will save to project dependencies in package.json)

Note: Make sure you have a package.json file in your project. This details the packages required for your project. If you built your project from scratch you may not have it yet.

The HTML-Reporter part

This produces HTML reports of your test results. You can state the save path of these files within the conf.js file as a parameter in the Jasmine2HtmlReporter.

Add this to your conf.js file to register protractor-jasmine2-html-reporter in jasmine:

exports.config = {
// ...
onPrepare: function () {
// output HTML page and creates screenshots
let Jasmine2HtmlReporter = require('protractor-jasmine2-html-reporter');
jasmine.getEnv().addReporter(
new Jasmine2HtmlReporter({
savePath: 'target/'+ + '/Screenshots'
})
);
}
}

Overall, using Jasmine defintely makes it easier to interpret the results from your tests. And, although pretty basic, the HTML reporter can be styled to produce great looking results in case they need to be shown to anyone unable to run the tests via commandline or used in larger reports.